public/rancher-docs
1
0
Fork 0
mirror of https://github.com/rancher/rancher-docs.git synced 2026-09-28 22:18:52 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #4045 from bashofmann/k3s-registries-mirror-rewrites

Browse Source 
[K3s] Document registry mirror rewrite configuration
This commit is contained in:
Jen Travinski
2022-04-25 09:17:06 -04:00
committed by GitHub
parent af26bd9d37 24060cd7e4
commit d4c3e29082
1 changed files with 32 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/k3s/latest/en/installation/private-registry/_index.md
+32 -11
View File
@@ -32,22 +32,43 @@ mirrors:
Each mirror must have a name and set of endpoints. When pulling an image from a registry, containerd will try these endpoint URLs one by one, and use the first working one. Each mirror must have a name and set of endpoints. When pulling an image from a registry, containerd will try these endpoint URLs one by one, and use the first working one.
#### Rewrites
Each mirror can have a set of rewrites. Rewrites can change the tag of an image based on a regular expression. This is useful if the organization/project structure in the mirror registry is different to the upstream one.
For example, the following configuration would transparently pull the image `docker.io/rancher/coredns-coredns:1.6.3` from `registry.example.com:5000/mirrorproject/rancher-images/coredns-coredns:1.6.3`:
```
mirrors:
docker.io:
endpoint:
- "https://registry.example.com:5000"
rewrite:
"^rancher/(.*)": "mirrorproject/rancher-images/$1"
```
The image will still be stored under the original name so that a `crictl image ls` will show `docker.io/rancher/coredns-coredns:1.6.3` as available on the node, even though the image was pulled from the mirrored registry with a different name.
### Configs ### Configs
The configs section defines the TLS and credential configuration for each mirror. For each mirror you can define `auth` and/or `tls`. The TLS part consists of: The `configs` section defines the TLS and credential configuration for each mirror. For each mirror you can define `auth` and/or `tls`.
Directive | Description The `tls` part consists of:
----------|------------
`cert_file` | The client certificate path that will be used to authenticate with the registry
`key_file` | The client key path that will be used to authenticate with the registry
`ca_file` | Defines the CA certificate path to be used to verify the registry's server cert file
`insecure_skip_verify` | Boolean that defines if TLS verification should be skipped for the registry
The credentials consist of either username/password or authentication token: | Directive | Description |
|------------------------|--------------------------------------------------------------------------------------|
| `cert_file` | The client certificate path that will be used to authenticate with the registry |
| `key_file` | The client key path that will be used to authenticate with the registry |
| `ca_file` | Defines the CA certificate path to be used to verify the registry's server cert file |
| `insecure_skip_verify` | Boolean that defines if TLS verification should be skipped for the registry |
- username: user name of the private registry basic auth The `auth` part consists of either username/password or authentication token:
- password: user password of the private registry basic auth
- auth: authentication token of the private registry basic auth | Directive | Description |
|------------|---------------------------------------------------------|
| `username` | user name of the private registry basic auth |
| `password` | user password of the private registry basic auth |
| `auth` | authentication token of the private registry basic auth |
Below are basic examples of using private registries in different modes: Below are basic examples of using private registries in different modes: