5.7. Configuring image registry repository mirroring
Setting up container registry repository mirroring enables you to do the following:
- Configure your OpenShift Container Platform cluster to redirect requests to pull images from a repository on a source image registry and have it resolved by a repository on a mirrored image registry.
- Identify multiple mirrored repositories for each target repository, to make sure that if one mirror is down, another can be used.
The attributes of repository mirroring in OpenShift Container Platform include:
- Image pulls are resilient to registry downtimes.
- Clusters in restricted networks can pull images from critical locations, such as quay.io, and have registries behind a company firewall provide the requested images.
- A particular order of registries is tried when an image pull request is made, with the permanent registry typically being the last one tried.
The mirror information you enter is added to the
/etc/containers/registries.conffile on every node in the OpenShift Container Platform cluster.
- When a node makes a request for an image from the source repository, it tries each mirrored repository in turn until it finds the requested content. If all mirrors fail, the cluster tries the source repository. If successful, the image is pulled to the node.
Setting up repository mirroring can be done in the following ways:
At OpenShift Container Platform installation:
By pulling container images needed by OpenShift Container Platform and then bringing those images behind your company’s firewall, you can install OpenShift Container Platform into a datacenter that is in a restricted network.
After OpenShift Container Platform installation:
Even if you don’t configure mirroring during OpenShift Container Platform installation, you can do so later using the
The following procedure provides a post-installation mirror configuration, where you create an
ImageContentSourcePolicy object that identifies:
- The source of the container image repository you want to mirror.
- A separate entry for each mirror repository you want to offer the content requested from the source repository.
You can only configure global pull secrets for clusters that have an
ImageContentSourcePolicy object. You cannot add a pull secret to a project.
Access to the cluster as a user with the
Configure mirrored repositories, by either:
- Setting up a mirrored repository with Red Hat Quay, as described in Red Hat Quay Repository Mirroring. Using Red Hat Quay allows you to copy images from one repository to another and also automatically sync those repositories repeatedly over time.
Using a tool such as
skopeoto copy images manually from the source directory to the mirrored repository.
For example, after installing the skopeo RPM package on a Red Hat Enterprise Linux (RHEL) 7 or RHEL 8 system, use the
skopeocommand as shown in this example:
$ skopeo copy \ docker://registry.access.redhat.com/ubi8/ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455ebaa6 \ docker://example.io/example/ubi-minimal
In this example, you have a container image registry that is named
example.iowith an image repository named
exampleto which you want to copy the
registry.access.redhat.com. After you create the registry, you can configure your OpenShift Container Platform cluster to redirect requests made of the source repository to the mirrored repository.
- Log in to your OpenShift Container Platform cluster.
ImageContentSourcePolicyfile (for example,
registryrepomirror.yaml), replacing the source and mirrors with your own registry and repository pairs and images:
apiVersion: operator.openshift.io/v1alpha1 kind: ImageContentSourcePolicy metadata: name: ubi8repo spec: repositoryDigestMirrors: - mirrors: - example.io/example/ubi-minimal 1 source: registry.access.redhat.com/ubi8/ubi-minimal 2 - mirrors: - example.com/example/ubi-minimal source: registry.access.redhat.com/ubi8/ubi-minimal
Create the new
$ oc create -f registryrepomirror.yaml
ImageContentSourcePolicyobject is created, the new settings are deployed to each node and the cluster starts using the mirrored repository for requests to the source repository.
To check that the mirrored configuration settings, are applied, do the following on one of the nodes.
List your nodes:
$ oc get node
NAME STATUS ROLES AGE VERSION ip-10-0-137-44.ec2.internal Ready worker 7m v1.18.3 ip-10-0-138-148.ec2.internal Ready master 11m v1.18.3 ip-10-0-139-122.ec2.internal Ready master 11m v1.18.3 ip-10-0-147-35.ec2.internal Ready,SchedulingDisabled worker 7m v1.18.3 ip-10-0-153-12.ec2.internal Ready worker 7m v1.18.3 ip-10-0-154-10.ec2.internal Ready master 11m v1.18.3
You can see that scheduling on each worker node is disabled as the change is being applied.
Start the debugging process to access the node:
$ oc debug node/ip-10-0-147-35.ec2.internal
Starting pod/ip-10-0-147-35ec2internal-debug ... To use host binaries, run `chroot /host`
Access the node’s files:
sh-4.2# chroot /host
/etc/containers/registries.conffile to make sure the changes were made:
sh-4.2# cat /etc/containers/registries.conf
unqualified-search-registries = ["registry.access.redhat.com", "docker.io"] [[registry]] location = "registry.access.redhat.com/ubi8/" insecure = false blocked = false mirror-by-digest-only = true prefix = "" [[registry.mirror]] location = "example.io/example/ubi8-minimal" insecure = false [[registry.mirror]] location = "example.com/example/ubi8-minimal" insecure = false
Pull an image digest to the node from the source and check if it is resolved by the mirror.
ImageContentSourcePolicyobjects support image digests only, not image tags.
sh-4.2# podman pull --log-level=debug registry.access.redhat.com/ubi8/ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455ebaa6
Troubleshooting repository mirroring
If the repository mirroring procedure does not work as described, use the following information about how repository mirroring works to help troubleshoot the problem.
- The first working mirror is used to supply the pulled image.
- The main registry is only used if no other mirror works.
From the system context, the
Insecureflags are used as fallback.
The format of the
/etc/containers/registries.conffile has changed recently. It is now version 2 and in TOML format.