# Configuration of Container Registries ## Supported registries Argo CD Image Updater comes with out of the box support for most container registries that implement the Docker registry v2 API. It has been successfully tested against the following popular registries: * Docker Hub (`docker.io`) * Docker Registry v2 reference implementation (on-premise) * Red Hat Quay (`quay.io` and on-premise) * JFrog Artifactory (`jfrog.io` and on-premise) * GitHub Container Registry (`ghcr.io`) * GitHub Packages Registry (`docker.pkg.github.com`) * GitLab Container Registry (`registry.gitlab.com`) * Google Container Registry (`gcr.io`) Chances are, that it will work out of the box for other registries as well. If you have a registry that doesn't work with Argo CD Image Updater, please let us know. ## When to configure a custom registry? Generally, there is no need to configure custom registries. Image Updater will infer the registry from the image slug, e.g. if you are using an image that is defined as `ghcr.io/somerepo/someimage`, Image Updater will infer the registry from the `ghcr.io` prefix and use the Docker registry at `https://ghcr.io/v2`. However, there may be reasons when you need to configure a custom registry, or adapt the default settings to your requirements: * Your registry uses a self-signed (or not publicly known) TLS certificate, and you want to either turn off TLS certificate verification or provide a custom CA certificate to be used for verification * Your registry has its API endpoint at a different location. One notable example is Docker Hub, which uses `docker.io` as image prefix but the registry is at `registry-1.docker.io`. However, this quirk related to Docker Hub has been accounted for in Argo CD Image Updater, so you won't have to configure Docker Hub as a custom registry. * You want to use a certain registry with deviations from the default settings, such as setting a custom rate limit, or configuring global credentials for accessing that registry. * Your cluster's container engine is set up to use a different registry than `docker.io` as the default so that it does not pull images from Docker Hub when no prefix is specified, but e.g. from an on-premise registry. ## Can I use my registry without further configuration? There is an easy way to find out by running the argocd-image-updater CLI in [test mode](../install/testing.md). You can run the CLI either from your workstation (if the registry is reachable from there) or from the pod deployed to your cluster. Assuming you have an image at `myregistry.com/somerepo/someimage`, and you want to find out if Argo CD Image Updater could possibly connect to that specific registry at `myregistry.com` and gather information about the image, run the following command: ``` argocd-image-updater test myregistry.com/somerepo/someimage ``` You may also want to pass some options to that command to set the appropriate [update strategy](../basics/update-strategies.md) or [credentials](../basics/authentication.md) to access the registry. The `argocd-image-updater test` command won't perform any modifications to your cluster or your workloads. ## Configuring custom registries ### Configuration format Registries are configured in a configuration file in YAML syntax. That YAML must have a top level key of `registries`, which holds a list of registries to be configured. Each item in the list represents a single registry. You can add as many registries as you like. The following properties can be set to configure a registry. Most of these properties are optional, unless otherwise stated: * `name` (mandatory) - The symbolic name for your registry. Can be any string, used only for informational purposes. Default value: _none_ Example value: `My Custom Registry` * `prefix` - (mandatory) The lookup prefix for this registry. Must match a DNS name, and must be unique in the configuration. Default value: _none_ Example value: `docker.io` * `api_url` - The URL to the API of the Docker registry. Must be a HTTP or HTTPS URL. Default value: _none_ Example value: `https://registry-1.docker.io` * `defaultns`- Some registries (notably Docker Hub) have a default namespace, which can be specified here. Default value: _none_ Example value: `library` * `default` - If set to true, use this registry as the default registry. Default value: `false` Example value: `true` * `credentials` - A string describing the credential source to use when accessing this registry and no other credentials are configured on the image level. For more information, refer to [Authenticating to container registries](../../basics/authentication/#auth-registries). Default value: _none_ Example value: `pullsecret:argocd/dockerhub-secret` * `credsexpire` - Whether and when credentials should expire and be re-fetched. Must be specified as _Duration_ value, with an integer value and a unit suffix, i.e. `s` for seconds, `m` for minutes, or `h` for hours. Default value: _none (no expiry)_ Example value: `5h` * `insecure` - Whether to turn off verification of the registry's TLS certificate. As the name implies, it's insecure and should not be used in production environments Default value: `false` Example value: `true` * `limit` - The rate limit (max. number of requests per second) to use for this registry, specified as integer. Default value: `20` Example value: `100` The following is an example that configures two registries. ```bash export REGISTRY_SECRET="login:password" ``` ```yaml registries: - name: Docker Hub prefix: docker.io api_url: https://registry-1.docker.io credentials: secret:foo/bar#creds defaultns: library default: true - name: RedHat Quay api_url: https://quay.io prefix: quay.io insecure: yes credentials: env:REGISTRY_SECRET ``` When running Argo CD Image Updater from the command line (e.g. using the `test` command), the path to this YAML file can be specified with the command line parameter `--registries-conf-path `. If you are running Argo CD Image Updater as a Kubernetes workload, you will need to tie that up in the `argocd-image-updater-config` ConfigMap, as a multi line string under the `registries.conf` key, e.g.: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: argocd-image-updater-config data: registries.conf: | registries: - name: Docker Hub prefix: docker.io api_url: https://registry-1.docker.io credentials: secret:foo/bar#creds defaultns: library default: true - name: RedHat Quay api_url: https://quay.io prefix: quay.io insecure: yes credentials: env:REGISTRY_SECRET ``` !!!note Argo CD Image Updater pod must be restarted for changes to the registries configuration to take effect. There are plans to change this behaviour so that changes will be reload automatically in a future release. ### Configuring a default registry !!!warning When you change the default registry for Argo CD Image Updater, make sure it matches the default registry set up in your cluster. If the default registries mismatch between the Argo CD Image Updater and your cluster, it is going to break your workloads. Most container engines will follow Docker's approach and use Docker Hub as the default registry when no registry is specified in the image's reference. For example, in most environments, the two image references `argoproj/argocd` and `docker.io/argoproj/argocd` are semantically the same, and would refer to the same image stored in Docker Hub's registry. You can configure the default registry if your cluster's container engine is configured to use a different default registry than `docker.io`, which is the default for Argo CD Image Updater in the standard configuration. In order to set another registry to be used as default, you will have to set the registry's `default` property to `true`, e.g. the following: ```yaml registries: - name: RedHat Quay api_url: https://quay.io prefix: quay.io default: true ``` would make `quay.io` the default registry, so `argoproj/argocd` would become synonymous to `quay.io/argoproj/argocd`. Please note that you can only configure one registry as the default registry. If you set `default` to `true` for more than one registry's configuration, Argo CD Image Updater will not load that configuration. Also note, as stated previously, Docker Hub (i.e. `docker.io`) is the default used by Image Updater without any additional configuration. ### Configuring a registry's default namespace Some registries provide a default namespace, that is, a namespace that doesn't have to be specified in the image's slug. A good example for that is the implicit `library` namespace on Docker Hub, that allows you to pull an image from that library by just specifying the name of the image. Consider e.g. the command `docker pull nginx`, which will pull from `docker.io/library/nginx`. If your registry supports a default namespace and you would like this to be used with Image Updater, you can configure this by setting the `defaultns` property of the registry to the name of the namespace to use as the default. The canonical example for Docker Hub would be: ```yaml registries: - name: Docker Hub api_url: https://registry-1.docker.io prefix: docker.io defaultns: library ``` ### Configuring a request rate limit for your registry Some registries might be picky about how many requests per time they let you perform from a client's connection. In order to play nicely, and to prevent Image Updater from triggering rate limit failures on your registry, you can set a rate limit for each of the registries you are using. The rate limit can currently be configured as _requests per second_ allowed and is specified via the `limit` configuration property. It takes an integer as argument. For example, the following connection would cap requests to `quay.io` to 10 per second: ```yaml registries: - name: RedHat Quay api_url: https://quay.io prefix: quay.io limit: 10 ``` Please note that the limit considers all HTTP requests sent to the registry. For inspecting a single tag of any given image, Image Updater may require performing multiple requests to the registry. The default for all registries is 20 requests per second. If your registry doesn't impose limits upon you, raising this limit may significantly speed up Argo CD Image Updater. But please be considerate and careful before you increase the limit. ### Configuring default credentials for container registries If you require authentication for accessing your registry, you can configure a set of default credentials to use. If you have configured the credentials on the registry level, it will be reused for any image processed from that registry, unless an image configuration overrides it. A benefit of having the credentials configured at the registry level is Registry credentials are configured using the `credentials` property of a registry's configuration. ### Credentials caching By default, credentials specified in registry configuration are read once on startup and then cached until `argocd-image-updater` is restarted. There are two strategies to overcome this: * Use per-image credentials in annotations - credentials will be read from their source every time an image update cycle is performed, and your credentials will always be up-to-date (i.e. if you update a secret). * Specify credential expiry time in the registry configuration - if set, the registry credentials will have a defined lifetime, and will be re-read from the source after expiration. This can be especially useful if you generate credentials with a script which returns a token with a limited lifetime, i.e. for getting EKS credentials from the aws CLI. For example, if the token has a lifetime of 12 hours, you can set `credsexpire: 12h` and Argo CD Image Updater will get a new token after 12 hours.