Chapter 9. Image configuration resources (Classic)
Use the following procedure to configure image registries.
9.1. Image controller configuration parameters
The image.config.openshift.io/cluster
resource holds cluster-wide information about how to handle images. The canonical, and only valid name is cluster
. Its spec
offers the following configuration parameters.
Parameters such as DisableScheduledImport
, MaxImagesBulkImportedPerRepository
, MaxScheduledImportsPerMinute
, ScheduledImageImportMinimumIntervalSeconds
, InternalRegistryHostname
are not configurable.
Parameter | Description |
---|---|
|
Limits the container image registries from which normal users can import images. Set this list to the registries that you trust to contain valid images, and that you want applications to be able to import from. Users with permission to create images or Every element of this list contains a location of the registry specified by the registry domain name.
|
|
A reference to a config map containing additional CAs that should be trusted during
The namespace for this config map is |
|
Provides the hostnames for the default external image registry. The external hostname should be set only when the image registry is exposed externally. The first value is used in |
| Contains configuration that determines how the container runtime should treat individual registries when accessing images for builds and pods. For instance, whether or not to allow insecure access. It does not contain configuration for the internal cluster registry.
Either |
When the allowedRegistries
parameter is defined, all registries, including registry.redhat.io
and quay.io
registries and the default OpenShift image registry, are blocked unless explicitly listed. When using the parameter, to prevent pod failure, add all registries including the registry.redhat.io
and quay.io
registries and the internalRegistryHostname
to the allowedRegistries
list, as they are required by payload images within your environment. For disconnected clusters, mirror registries should also be added.
The status
field of the image.config.openshift.io/cluster
resource holds observed values from the cluster.
Parameter | Description |
---|---|
|
Set by the Image Registry Operator, which controls the |
|
Set by the Image Registry Operator, provides the external hostnames for the image registry when it is exposed externally. The first value is used in |
9.2. Configuring image registry settings
You can configure image registry settings by editing the image.config.openshift.io/cluster
custom resource (CR). When changes to the registry are applied to the image.config.openshift.io/cluster
CR, the Machine Config Operator (MCO) performs the following sequential actions:
- Cordons the node
- Applies changes by restarting CRI-O
Uncordons the node
NoteThe MCO does not restart nodes when it detects changes.
Procedure
Edit the
image.config.openshift.io/cluster
custom resource:$ oc edit image.config.openshift.io/cluster
The following is an example
image.config.openshift.io/cluster
CR:apiVersion: config.openshift.io/v1 kind: Image 1 metadata: annotations: release.openshift.io/create-only: "true" creationTimestamp: "2019-05-17T13:44:26Z" generation: 1 name: cluster resourceVersion: "8302" selfLink: /apis/config.openshift.io/v1/images/cluster uid: e34555da-78a9-11e9-b92b-06d6c7da38dc spec: allowedRegistriesForImport: 2 - domainName: quay.io insecure: false additionalTrustedCA: 3 name: myconfigmap registrySources: 4 allowedRegistries: - example.com - quay.io - registry.redhat.io - image-registry.openshift-image-registry.svc:5000 - reg1.io/myrepo/myapp:latest insecureRegistries: - insecure.com status: internalRegistryHostname: image-registry.openshift-image-registry.svc:5000
- 1
Image
: Holds cluster-wide information about how to handle images. The canonical, and only valid name iscluster
.- 2
allowedRegistriesForImport
: Limits the container image registries from which normal users may import images. Set this list to the registries that you trust to contain valid images, and that you want applications to be able to import from. Users with permission to create images orImageStreamMappings
from the API are not affected by this policy. Typically only cluster administrators have the appropriate permissions.- 3
additionalTrustedCA
: A reference to a config map containing additional certificate authorities (CA) that are trusted during image stream import, pod image pull,openshift-image-registry
pullthrough, and builds. The namespace for this config map isopenshift-config
. The format of the config map is to use the registry hostname as the key, and the PEM certificate as the value, for each additional registry CA to trust.- 4
registrySources
: Contains configuration that determines whether the container runtime allows or blocks individual registries when accessing images for builds and pods. Either theallowedRegistries
parameter or theblockedRegistries
parameter can be set, but not both. You can also define whether or not to allow access to insecure registries or registries that allow registries that use image short names. This example uses theallowedRegistries
parameter, which defines the registries that are allowed to be used. The insecure registryinsecure.com
is also allowed. TheregistrySources
parameter does not contain configuration for the internal cluster registry.
NoteWhen the
allowedRegistries
parameter is defined, all registries, including the registry.redhat.io and quay.io registries and the default OpenShift image registry, are blocked unless explicitly listed. If you use the parameter, to prevent pod failure, you must add theregistry.redhat.io
andquay.io
registries and theinternalRegistryHostname
to theallowedRegistries
list, as they are required by payload images within your environment. Do not add theregistry.redhat.io
andquay.io
registries to theblockedRegistries
list.When using the
allowedRegistries
,blockedRegistries
, orinsecureRegistries
parameter, you can specify an individual repository within a registry. For example:reg1.io/myrepo/myapp:latest
.Insecure external registries should be avoided to reduce possible security risks.
To check that the changes are applied, list your nodes:
$ oc get nodes
Example output
NAME STATUS ROLES AGE VERSION ip-10-0-137-182.us-east-2.compute.internal Ready,SchedulingDisabled worker 65m v1.30.3 ip-10-0-139-120.us-east-2.compute.internal Ready,SchedulingDisabled control-plane 74m v1.30.3 ip-10-0-176-102.us-east-2.compute.internal Ready control-plane 75m v1.30.3 ip-10-0-188-96.us-east-2.compute.internal Ready worker 65m v1.30.3 ip-10-0-200-59.us-east-2.compute.internal Ready worker 63m v1.30.3 ip-10-0-223-123.us-east-2.compute.internal Ready control-plane 73m v1.30.3
9.2.1. Adding specific registries
You can add a list of registries, and optionally an individual repository within a registry, that are permitted for image pull and push actions by editing the image.config.openshift.io/cluster
custom resource (CR). Red Hat OpenShift Service on AWS applies the changes to this CR to all nodes in the cluster.
When pulling or pushing images, the container runtime searches the registries listed under the registrySources
parameter in the image.config.openshift.io/cluster
CR. If you created a list of registries under the allowedRegistries
parameter, the container runtime searches only those registries. Registries not in the list are blocked.
When the allowedRegistries
parameter is defined, all registries, including the registry.redhat.io
and quay.io
registries and the default OpenShift image registry, are blocked unless explicitly listed. If you use the parameter, to prevent pod failure, add the registry.redhat.io
and quay.io
registries and the internalRegistryHostname
to the allowedRegistries
list, as they are required by payload images within your environment. For disconnected clusters, mirror registries should also be added.
Procedure
Edit the
image.config.openshift.io/cluster
custom resource:$ oc edit image.config.openshift.io/cluster
The following is an example
image.config.openshift.io/cluster
CR with an allowed list:apiVersion: config.openshift.io/v1 kind: Image metadata: annotations: release.openshift.io/create-only: "true" creationTimestamp: "2019-05-17T13:44:26Z" generation: 1 name: cluster resourceVersion: "8302" selfLink: /apis/config.openshift.io/v1/images/cluster uid: e34555da-78a9-11e9-b92b-06d6c7da38dc spec: registrySources: 1 allowedRegistries: 2 - example.com - quay.io - registry.redhat.io - reg1.io/myrepo/myapp:latest - image-registry.openshift-image-registry.svc:5000 status: internalRegistryHostname: image-registry.openshift-image-registry.svc:5000
- 1
- Contains configurations that determine how the container runtime should treat individual registries when accessing images for builds and pods. It does not contain configuration for the internal cluster registry.
- 2
- Specify registries, and optionally a repository in that registry, to use for image pull and push actions. All other registries are blocked.
NoteEither the
allowedRegistries
parameter or theblockedRegistries
parameter can be set, but not both.The Machine Config Operator (MCO) watches the
image.config.openshift.io/cluster
resource for any changes to the registries. When the MCO detects a change, it drains the nodes, applies the change, and uncordons the nodes. After the nodes return to theReady
state, the allowed registries list is used to update the image signature policy in the/etc/containers/policy.json
file on each node.
If your cluster uses the registrySources.insecureRegistries
parameter, ensure that any insecure registries are included in the allowed list.
For example:
spec: registrySources: insecureRegistries: - insecure.com allowedRegistries: - example.com - quay.io - registry.redhat.io - insecure.com - image-registry.openshift-image-registry.svc:5000
9.2.2. Blocking specific registries
You can block any registry, and optionally an individual repository within a registry, by editing the image.config.openshift.io/cluster
custom resource (CR). Red Hat OpenShift Service on AWS applies the changes to this CR to all nodes in the cluster.
When pulling or pushing images, the container runtime searches the registries listed under the registrySources
parameter in the image.config.openshift.io/cluster
CR. If you created a list of registries under the blockedRegistries
parameter, the container runtime does not search those registries. All other registries are allowed.
To prevent pod failure, do not add the registry.redhat.io
and quay.io
registries to the blockedRegistries
list, as they are required by payload images within your environment.
Procedure
Edit the
image.config.openshift.io/cluster
custom resource:$ oc edit image.config.openshift.io/cluster
The following is an example
image.config.openshift.io/cluster
CR with a blocked list:apiVersion: config.openshift.io/v1 kind: Image metadata: annotations: release.openshift.io/create-only: "true" creationTimestamp: "2019-05-17T13:44:26Z" generation: 1 name: cluster resourceVersion: "8302" selfLink: /apis/config.openshift.io/v1/images/cluster uid: e34555da-78a9-11e9-b92b-06d6c7da38dc spec: registrySources: 1 blockedRegistries: 2 - untrusted.com - reg1.io/myrepo/myapp:latest status: internalRegistryHostname: image-registry.openshift-image-registry.svc:5000
- 1
- Contains configurations that determine how the container runtime should treat individual registries when accessing images for builds and pods. It does not contain configuration for the internal cluster registry.
- 2
- Specify registries, and optionally a repository in that registry, that should not be used for image pull and push actions. All other registries are allowed.
NoteEither the
blockedRegistries
registry or theallowedRegistries
registry can be set, but not both.The Machine Config Operator (MCO) watches the
image.config.openshift.io/cluster
resource for any changes to the registries. When the MCO detects a change, it drains the nodes, applies the change, and uncordons the nodes. After the nodes return to theReady
state, changes to the blocked registries appear in the/etc/containers/registries.conf
file on each node.
9.2.3. Allowing insecure registries
You can add insecure registries, and optionally an individual repository within a registry, by editing the image.config.openshift.io/cluster
custom resource (CR). Red Hat OpenShift Service on AWS applies the changes to this CR to all nodes in the cluster.
Registries that do not use valid SSL certificates or do not require HTTPS connections are considered insecure.
Insecure external registries should be avoided to reduce possible security risks.
Procedure
Edit the
image.config.openshift.io/cluster
custom resource:$ oc edit image.config.openshift.io/cluster
The following is an example
image.config.openshift.io/cluster
CR with an insecure registries list:apiVersion: config.openshift.io/v1 kind: Image metadata: annotations: release.openshift.io/create-only: "true" creationTimestamp: "2019-05-17T13:44:26Z" generation: 1 name: cluster resourceVersion: "8302" selfLink: /apis/config.openshift.io/v1/images/cluster uid: e34555da-78a9-11e9-b92b-06d6c7da38dc spec: registrySources: 1 insecureRegistries: 2 - insecure.com - reg4.io/myrepo/myapp:latest allowedRegistries: - example.com - quay.io - registry.redhat.io - insecure.com 3 - reg4.io/myrepo/myapp:latest - image-registry.openshift-image-registry.svc:5000 status: internalRegistryHostname: image-registry.openshift-image-registry.svc:5000
- 1
- Contains configurations that determine how the container runtime should treat individual registries when accessing images for builds and pods. It does not contain configuration for the internal cluster registry.
- 2
- Specify an insecure registry. You can specify a repository in that registry.
- 3
- Ensure that any insecure registries are included in the
allowedRegistries
list.
NoteWhen the
allowedRegistries
parameter is defined, all registries, including the registry.redhat.io and quay.io registries and the default OpenShift image registry, are blocked unless explicitly listed. If you use the parameter, to prevent pod failure, add all registries including theregistry.redhat.io
andquay.io
registries and theinternalRegistryHostname
to theallowedRegistries
list, as they are required by payload images within your environment. For disconnected clusters, mirror registries should also be added.The Machine Config Operator (MCO) watches the
image.config.openshift.io/cluster
CR for any changes to the registries, then drains and uncordons the nodes when it detects changes. After the nodes return to theReady
state, changes to the insecure and blocked registries appear in the/etc/containers/registries.conf
file on each node.
9.2.4. Adding registries that allow image short names
You can add registries to search for an image short name by editing the image.config.openshift.io/cluster
custom resource (CR). Red Hat OpenShift Service on AWS applies the changes to this CR to all nodes in the cluster.
An image short name enables you to search for images without including the fully qualified domain name in the pull spec. For example, you could use rhel7/etcd
instead of registry.access.redhat.com/rhe7/etcd
.
You might use short names in situations where using the full path is not practical. For example, if your cluster references multiple internal registries whose DNS changes frequently, you would need to update the fully qualified domain names in your pull specs with each change. In this case, using an image short name might be beneficial.
When pulling or pushing images, the container runtime searches the registries listed under the registrySources
parameter in the image.config.openshift.io/cluster
CR. If you created a list of registries under the containerRuntimeSearchRegistries
parameter, when pulling an image with a short name, the container runtime searches those registries.
Using image short names with public registries is strongly discouraged because the image might not deploy if the public registry requires authentication. Use fully-qualified image names with public registries.
Red Hat internal or private registries typically support the use of image short names.
If you list public registries under the containerRuntimeSearchRegistries
parameter (including the registry.redhat.io
, docker.io
, and quay.io
registries), you expose your credentials to all the registries on the list, and you risk network and registry attacks. Because you can only have one pull secret for pulling images, as defined by the global pull secret, that secret is used to authenticate against every registry in that list. Therefore, if you include public registries in the list, you introduce a security risk.
You cannot list multiple public registries under the containerRuntimeSearchRegistries
parameter if each public registry requires different credentials and a cluster does not list the public registry in the global pull secret.
For a public registry that requires authentication, you can use an image short name only if the registry has its credentials stored in the global pull secret.
The Machine Config Operator (MCO) watches the image.config.openshift.io/cluster
resource for any changes to the registries. When the MCO detects a change, it drains the nodes, applies the change, and uncordons the nodes. After the nodes return to the Ready
state, if the containerRuntimeSearchRegistries
parameter is added, the MCO creates a file in the /etc/containers/registries.conf.d
directory on each node with the listed registries. The file overrides the default list of unqualified search registries in the /etc/containers/registries.conf
file. There is no way to fall back to the default list of unqualified search registries.
The containerRuntimeSearchRegistries
parameter works only with the Podman and CRI-O container engines. The registries in the list can be used only in pod specs, not in builds and image streams.
Procedure
Edit the
image.config.openshift.io/cluster
custom resource:$ oc edit image.config.openshift.io/cluster
The following is an example
image.config.openshift.io/cluster
CR:apiVersion: config.openshift.io/v1 kind: Image metadata: annotations: release.openshift.io/create-only: "true" creationTimestamp: "2019-05-17T13:44:26Z" generation: 1 name: cluster resourceVersion: "8302" selfLink: /apis/config.openshift.io/v1/images/cluster uid: e34555da-78a9-11e9-b92b-06d6c7da38dc spec: allowedRegistriesForImport: - domainName: quay.io insecure: false additionalTrustedCA: name: myconfigmap registrySources: containerRuntimeSearchRegistries: 1 - reg1.io - reg2.io - reg3.io allowedRegistries: 2 - example.com - quay.io - registry.redhat.io - reg1.io - reg2.io - reg3.io - image-registry.openshift-image-registry.svc:5000 ... status: internalRegistryHostname: image-registry.openshift-image-registry.svc:5000
NoteWhen the
allowedRegistries
parameter is defined, all registries, including theregistry.redhat.io
andquay.io
registries and the default OpenShift image registry, are blocked unless explicitly listed. If you use this parameter, to prevent pod failure, add all registries including theregistry.redhat.io
andquay.io
registries and theinternalRegistryHostname
to theallowedRegistries
list, as they are required by payload images within your environment. For disconnected clusters, mirror registries should also be added.
9.2.5. Configuring additional trust stores for image registry access
The image.config.openshift.io/cluster
custom resource can contain a reference to a config map that contains additional certificate authorities to be trusted during image registry access.
Prerequisites
- The certificate authorities (CA) must be PEM-encoded.
Procedure
You can create a config map in the openshift-config
namespace and use its name in AdditionalTrustedCA
in the image.config.openshift.io
custom resource to provide additional CAs that should be trusted when contacting external registries.
The config map key is the hostname of a registry with the port for which this CA is to be trusted, and the PEM certificate content is the value, for each additional registry CA to trust.
Image registry CA config map example
apiVersion: v1
kind: ConfigMap
metadata:
name: my-registry-ca
data:
registry.example.com: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
registry-with-port.example.com..5000: | 1
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
- 1
- If the registry has the port, such as
registry-with-port.example.com:5000
,:
should be replaced with..
.
You can configure additional CAs with the following procedure.
To configure an additional CA:
$ oc create configmap registry-config --from-file=<external_registry_address>=ca.crt -n openshift-config
$ oc edit image.config.openshift.io cluster
spec: additionalTrustedCA: name: registry-config
9.3. Understanding image registry repository mirroring
Setting up container registry repository mirroring enables you to perform the following tasks:
- Configure your Red Hat OpenShift Service on AWS 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.
Repository mirroring in Red Hat OpenShift Service on AWS includes the following attributes:
- Image pulls are resilient to registry downtimes.
- Clusters in disconnected environments 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.conf
file on every node in the Red Hat OpenShift Service on AWS 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 Red Hat OpenShift Service on AWS installation:
By pulling container images needed by Red Hat OpenShift Service on AWS and then bringing those images behind your company’s firewall, you can install Red Hat OpenShift Service on AWS into a data center that is in a disconnected environment.
After Red Hat OpenShift Service on AWS installation:
If you did not configure mirroring during Red Hat OpenShift Service on AWS installation, you can do so postinstallation by using any of the following custom resource (CR) objects:
-
ImageDigestMirrorSet
(IDMS). This object allows you to pull images from a mirrored registry by using digest specifications. The IDMS CR enables you to set a fall back policy that allows or stops continued attempts to pull from the source registry if the image pull fails. -
ImageTagMirrorSet
(ITMS). This object allows you to pull images from a mirrored registry by using image tags. The ITMS CR enables you to set a fall back policy that allows or stops continued attempts to pull from the source registry if the image pull fails. -
ImageContentSourcePolicy
(ICSP). This object allows you to pull images from a mirrored registry by using digest specifications. The ICSP CR always falls back to the source registry if the mirrors do not work.
ImportantUsing an
ImageContentSourcePolicy
(ICSP) object to configure repository mirroring is a deprecated feature. Deprecated functionality is still included in Red Hat OpenShift Service on AWS and continues to be supported; however, it will be removed in a future release of this product and is not recommended for new deployments. If you have existing YAML files that you used to createImageContentSourcePolicy
objects, you can use theoc adm migrate icsp
command to convert those files to anImageDigestMirrorSet
YAML file. For more information, see "Converting ImageContentSourcePolicy (ICSP) files for image registry repository mirroring" in the following section.-
Each of these custom resource objects identify the following information:
- 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.
For new clusters, you can use IDMS, ITMS, and ICSP CRs objects as desired. However, using IDMS and ITMS is recommended.
If you upgraded a cluster, any existing ICSP objects remain stable, and both IDMS and ICSP objects are supported. Workloads using ICSP objects continue to function as expected. However, if you want to take advantage of the fallback policies introduced in the IDMS CRs, you can migrate current workloads to IDMS objects by using the oc adm migrate icsp
command as shown in the Converting ImageContentSourcePolicy (ICSP) files for image registry repository mirroring section that follows. Migrating to IDMS objects does not require a cluster reboot.
If your cluster uses an ImageDigestMirrorSet
, ImageTagMirrorSet
, or ImageContentSourcePolicy
object to configure repository mirroring, you can use only global pull secrets for mirrored registries. You cannot add a pull secret to a project.
9.3.1. Configuring image registry repository mirroring
You can create postinstallation mirror configuration custom resources (CR) to redirect image pull requests from a source image registry to a mirrored image registry.
Prerequisites
-
Access to the cluster as a user with the
dedicated-admin
role.
Procedure
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
skopeo
to copy images manually from the source repository 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
skopeo
command as shown in this example:$ skopeo copy --all \ docker://registry.access.redhat.com/ubi9/ubi-minimal:latest@sha256:5cf... \ docker://example.io/example/ubi-minimal
In this example, you have a container image registry that is named
example.io
with an image repository namedexample
to which you want to copy theubi9/ubi-minimal
image fromregistry.access.redhat.com
. After you create the mirrored registry, you can configure your Red Hat OpenShift Service on AWS cluster to redirect requests made of the source repository to the mirrored repository.
Create a postinstallation mirror configuration CR, by using one of the following examples:
Create an
ImageDigestMirrorSet
orImageTagMirrorSet
CR, as needed, replacing the source and mirrors with your own registry and repository pairs and images:apiVersion: config.openshift.io/v1 1 kind: ImageDigestMirrorSet 2 metadata: name: ubi9repo spec: imageDigestMirrors: 3 - mirrors: - example.io/example/ubi-minimal 4 - example.com/example/ubi-minimal 5 source: registry.access.redhat.com/ubi9/ubi-minimal 6 mirrorSourcePolicy: AllowContactingSource 7 - mirrors: - mirror.example.com/redhat source: registry.example.com/redhat 8 mirrorSourcePolicy: AllowContactingSource - mirrors: - mirror.example.com source: registry.example.com 9 mirrorSourcePolicy: AllowContactingSource - mirrors: - mirror.example.net/image source: registry.example.com/example/myimage 10 mirrorSourcePolicy: AllowContactingSource - mirrors: - mirror.example.net source: registry.example.com/example 11 mirrorSourcePolicy: AllowContactingSource - mirrors: - mirror.example.net/registry-example-com source: registry.example.com 12 mirrorSourcePolicy: AllowContactingSource
- 1
- Indicates the API to use with this CR. This must be
config.openshift.io/v1
. - 2
- Indicates the kind of object according to the pull type:
-
ImageDigestMirrorSet
: Pulls a digest reference image. -
ImageTagMirrorSet
: Pulls a tag reference image.
-
- 3
- Indicates the type of image pull method, either:
-
imageDigestMirrors
: Use for anImageDigestMirrorSet
CR. -
imageTagMirrors
: Use for anImageTagMirrorSet
CR.
-
- 4
- Indicates the name of the mirrored image registry and repository.
- 5
- Optional: Indicates a secondary mirror repository for each target repository. If one mirror is down, the target repository can use the secondary mirror.
- 6
- Indicates the registry and repository source, which is the repository that is referred to in an image pull specification.
- 7
- Optional: Indicates the fallback policy if the image pull fails:
-
AllowContactingSource
: Allows continued attempts to pull the image from the source repository. This is the default. -
NeverContactSource
: Prevents continued attempts to pull the image from the source repository.
-
- 8
- Optional: Indicates a namespace inside a registry, which allows you to use any image in that namespace. If you use a registry domain as a source, the object is applied to all repositories from the registry.
- 9
- Optional: Indicates a registry, which allows you to use any image in that registry. If you specify a registry name, the object is applied to all repositories from a source registry to a mirror registry.
- 10
- Pulls the image
registry.example.com/example/myimage@sha256:…
from the mirrormirror.example.net/image@sha256:..
. - 11
- Pulls the image
registry.example.com/example/image@sha256:…
in the source registry namespace from the mirrormirror.example.net/image@sha256:…
. - 12
- Pulls the image
registry.example.com/myimage@sha256
from the mirror registryexample.net/registry-example-com/myimage@sha256:…
.
Create an
ImageContentSourcePolicy
custom resource, replacing the source and mirrors with your own registry and repository pairs and images:apiVersion: operator.openshift.io/v1alpha1 kind: ImageContentSourcePolicy metadata: name: mirror-ocp spec: repositoryDigestMirrors: - mirrors: - mirror.registry.com:443/ocp/release 1 source: quay.io/openshift-release-dev/ocp-release 2 - mirrors: - mirror.registry.com:443/ocp/release source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
Create the new object:
$ oc create -f registryrepomirror.yaml
After the object is created, the Machine Config Operator (MCO) drains the nodes for
ImageTagMirrorSet
objects only. The MCO does not drain the nodes forImageDigestMirrorSet
andImageContentSourcePolicy
objects.To check that the mirrored configuration settings are applied, do the following on one of the nodes.
List your nodes:
$ oc get node
Example output
NAME STATUS ROLES AGE VERSION ip-10-0-137-44.ec2.internal Ready worker 7m v1.30.3 ip-10-0-138-148.ec2.internal Ready master 11m v1.30.3 ip-10-0-139-122.ec2.internal Ready master 11m v1.30.3 ip-10-0-147-35.ec2.internal Ready worker 7m v1.30.3 ip-10-0-153-12.ec2.internal Ready worker 7m v1.30.3 ip-10-0-154-10.ec2.internal Ready master 11m v1.30.3
Start the debugging process to access the node:
$ oc debug node/ip-10-0-147-35.ec2.internal
Example output
Starting pod/ip-10-0-147-35ec2internal-debug ... To use host binaries, run `chroot /host`
Change your root directory to
/host
:sh-4.2# chroot /host
Check the
/etc/containers/registries.conf
file to make sure the changes were made:sh-4.2# cat /etc/containers/registries.conf
The following output represents a
registries.conf
file where postinstallation mirror configuration CRs were applied. The final two entries are markeddigest-only
andtag-only
respectively.Example output
unqualified-search-registries = ["registry.access.redhat.com", "docker.io"] short-name-mode = "" [[registry]] prefix = "" location = "registry.access.redhat.com/ubi9/ubi-minimal" 1 [[registry.mirror]] location = "example.io/example/ubi-minimal" 2 pull-from-mirror = "digest-only" 3 [[registry.mirror]] location = "example.com/example/ubi-minimal" pull-from-mirror = "digest-only" [[registry]] prefix = "" location = "registry.example.com" [[registry.mirror]] location = "mirror.example.net/registry-example-com" pull-from-mirror = "digest-only" [[registry]] prefix = "" location = "registry.example.com/example" [[registry.mirror]] location = "mirror.example.net" pull-from-mirror = "digest-only" [[registry]] prefix = "" location = "registry.example.com/example/myimage" [[registry.mirror]] location = "mirror.example.net/image" pull-from-mirror = "digest-only" [[registry]] prefix = "" location = "registry.example.com" [[registry.mirror]] location = "mirror.example.com" pull-from-mirror = "digest-only" [[registry]] prefix = "" location = "registry.example.com/redhat" [[registry.mirror]] location = "mirror.example.com/redhat" pull-from-mirror = "digest-only" [[registry]] prefix = "" location = "registry.access.redhat.com/ubi9/ubi-minimal" blocked = true 4 [[registry.mirror]] location = "example.io/example/ubi-minimal-tag" pull-from-mirror = "tag-only" 5
- 1
- Indicates the repository that is referred to in a pull spec.
- 2
- Indicates the mirror for that repository.
- 3
- Indicates that the image pull from the mirror is a digest reference image.
- 4
- Indicates that the
NeverContactSource
parameter is set for this repository. - 5
- Indicates that the image pull from the mirror is a tag reference image.
Pull an image to the node from the source and check if it is resolved by the mirror.
sh-4.2# podman pull --log-level=debug registry.access.redhat.com/ubi9/ubi-minimal@sha256:5cf...
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
Insecure
flags are used as fallback. -
The format of the
/etc/containers/registries.conf
file has changed recently. It is now version 2 and in TOML format.
9.3.2. Converting ImageContentSourcePolicy (ICSP) files for image registry repository mirroring
Using an ImageContentSourcePolicy
(ICSP) object to configure repository mirroring is a deprecated feature. This functionality is still included in Red Hat OpenShift Service on AWS and continues to be supported; however, it will be removed in a future release of this product and is not recommended for new deployments.
ICSP objects are being replaced by ImageDigestMirrorSet
and ImageTagMirrorSet
objects to configure repository mirroring. If you have existing YAML files that you used to create ImageContentSourcePolicy
objects, you can use the oc adm migrate icsp
command to convert those files to an ImageDigestMirrorSet
YAML file. The command updates the API to the current version, changes the kind
value to ImageDigestMirrorSet
, and changes spec.repositoryDigestMirrors
to spec.imageDigestMirrors
. The rest of the file is not changed.
Because the migration does not change the registries.conf
file, the cluster does not need to reboot.
For more information about ImageDigestMirrorSet
or ImageTagMirrorSet
objects, see "Configuring image registry repository mirroring" in the previous section.
Prerequisites
-
Access to the cluster as a user with the
dedicated-admin
role. -
Ensure that you have
ImageContentSourcePolicy
objects on your cluster.
Procedure
Use the following command to convert one or more
ImageContentSourcePolicy
YAML files to anImageDigestMirrorSet
YAML file:$ oc adm migrate icsp <file_name>.yaml <file_name>.yaml <file_name>.yaml --dest-dir <path_to_the_directory>
where:
<file_name>
-
Specifies the name of the source
ImageContentSourcePolicy
YAML. You can list multiple file names. --dest-dir
-
Optional: Specifies a directory for the output
ImageDigestMirrorSet
YAML. If unset, the file is written to the current directory.
For example, the following command converts the
icsp.yaml
andicsp-2.yaml
file and saves the new YAML files to theidms-files
directory.$ oc adm migrate icsp icsp.yaml icsp-2.yaml --dest-dir idms-files
Example output
wrote ImageDigestMirrorSet to idms-files/imagedigestmirrorset_ubi8repo.5911620242173376087.yaml wrote ImageDigestMirrorSet to idms-files/imagedigestmirrorset_ubi9repo.6456931852378115011.yaml
Create the CR object by running the following command:
$ oc create -f <path_to_the_directory>/<file-name>.yaml
where:
<path_to_the_directory>
-
Specifies the path to the directory, if you used the
--dest-dir
flag. <file_name>
-
Specifies the name of the
ImageDigestMirrorSet
YAML.
- Remove the ICSP objects after the IDMS objects are rolled out.