Registry
Configuring registries for OpenShift Container Platform
Abstract
Chapter 1. OpenShift Container Platform registry overview Copy linkLink copied to clipboard!
OpenShift Container Platform can build images from your source code, deploy them, and manage their lifecycle. It provides an internal, integrated container image registry that can be deployed in your OpenShift Container Platform environment to locally manage images. This overview contains reference information and links for registries commonly used with OpenShift Container Platform, with a focus on the internal image registry.
1.1. Glossary of common terms for OpenShift Container Platform registry Copy linkLink copied to clipboard!
This glossary defines the common terms that are used in the registry content.
- container
- Lightweight and executable images that consist software and all its dependencies. Because containers virtualize the operating system, you can run containers in data center, a public or private cloud, or your local host.
- Image Registry Operator
-
The Image Registry Operator runs in the
openshift-image-registrynamespace, and manages the registry instance in that location. - image repository
- An image repository is a collection of related container images and tags identifying images.
- mirror registry
- The mirror registry is a registry that holds the mirror of OpenShift Container Platform images.
- namespace
- A namespace isolates groups of resources within a single cluster.
- OpenShift Container Platform registry
- OpenShift Container Platform registry is the registry provided by OpenShift Container Platform to manage images.
- pod
- The pod is the smallest logical unit in Kubernetes. A pod is comprised of one or more containers to run in a worker node.
- private registry
- A registry is a server that implements the container image registry API. A private registry is a registry that requires authentication to allow users access its contents.
- public registry
- A registry is a server that implements the container image registry API. A public registry is a registry that serves its contently publicly.
- Quay.io
- A public Red Hat Quay Container Registry instance provided and maintained by Red Hat, that serves most of the container images and Operators to OpenShift Container Platform clusters.
- registry authentication
- To push and pull images to and from private image repositories, the registry needs to authenticate its users with credentials.
- route
- Exposes a service to allow for network access to pods from users and applications outside the OpenShift Container Platform instance.
- scale down
- To decrease the number of replicas.
- scale up
- To increase the number of replicas.
- service
- A service exposes a running application on a set of pods.
1.2. Integrated OpenShift Container Platform registry Copy linkLink copied to clipboard!
OpenShift Container Platform provides a built-in container image registry that runs as a standard workload on the cluster. The registry is configured and managed by an infrastructure Operator. It provides an out-of-the-box solution for users to manage the images that run their workloads, and runs on top of the existing cluster infrastructure. This registry can be scaled up or down like any other cluster workload and does not require specific infrastructure provisioning. In addition, it is integrated into the cluster user authentication and authorization system, which means that access to create and retrieve images is controlled by defining user permissions on the image resources.
The registry is typically used as a publication target for images built on the cluster, as well as being a source of images for workloads running on the cluster. When a new image is pushed to the registry, the cluster is notified of the new image and other components can react to and consume the updated image.
Image data is stored in two locations. The actual image data is stored in a configurable storage location, such as cloud storage or a filesystem volume. The image metadata, which is exposed by the standard cluster APIs and is used to perform access control, is stored as standard API resources, specifically images and imagestreams.
1.3. Third-party registries Copy linkLink copied to clipboard!
OpenShift Container Platform can create containers using images from third-party registries, but it is unlikely that these registries offer the same image notification support as the integrated OpenShift Container Platform registry. In this situation, OpenShift Container Platform will fetch tags from the remote registry upon imagestream creation. To refresh the fetched tags, run
oc import-image <stream>
1.3.1. Authentication Copy linkLink copied to clipboard!
OpenShift Container Platform can communicate with registries to access private image repositories using credentials supplied by the user. This allows OpenShift Container Platform to push and pull images to and from private repositories.
1.3.1.1. Registry authentication with Podman Copy linkLink copied to clipboard!
Some container image registries require access authorization. Podman is an open source tool for managing containers and container images and interacting with image registries. You can use Podman to authenticate your credentials, pull the registry image, and store local images in a local file system. The following is a generic example of authenticating the registry with Podman.
Procedure
- Use the Red Hat Ecosystem Catalog to search for specific container images from the Red Hat Repository and select the required image.
- Click Get this image to find the command for your container image.
Login by running the following command and entering your username and password to authenticate:
$ podman login registry.redhat.io Username:<your_registry_account_username> Password:<your_registry_account_password>Download the image and save it locally by running the following command:
$ podman pull registry.redhat.io/<repository_name>
1.4. Red Hat Quay registries Copy linkLink copied to clipboard!
If you need an enterprise-quality container image registry, Red Hat Quay is available both as a hosted service and as software you can install in your own data center or cloud environment. Advanced registry features in Red Hat Quay include geo-replication, image scanning, and the ability to roll back images.
Visit the Quay.io site to set up your own hosted Quay registry account. After that, follow the Quay Tutorial to log in to the Quay registry and start managing your images.
You can access your Red Hat Quay registry from OpenShift Container Platform like any remote container image registry.
1.5. Authentication enabled Red Hat registry Copy linkLink copied to clipboard!
All container images available through the Container images section of the Red Hat Ecosystem Catalog are hosted on an image registry,
registry.redhat.io
The registry,
registry.redhat.io
OpenShift Container Platform pulls images from
registry.redhat.io
The new registry uses standard OAuth mechanisms for authentication, with the following methods:
- Authentication token. Tokens, which are generated by administrators, are service accounts that give systems the ability to authenticate against the container image registry. Service accounts are not affected by changes in user accounts, so the token authentication method is reliable and resilient. This is the only supported authentication option for production clusters.
-
Web username and password. This is the standard set of credentials you use to log in to resources such as . While it is possible to use this authentication method with OpenShift Container Platform, it is not supported for production deployments. Restrict this authentication method to stand-alone projects outside OpenShift Container Platform.
access.redhat.com
You can use
podman login
All imagestreams point to the new registry, which uses the installation pull secret to authenticate.
You must place your credentials in either of the following places:
-
openshiftnamespace. Your credentials must exist in thenamespace so that the imagestreams in theopenshiftnamespace can import.openshift - Your host. Your credentials must exist on your host because Kubernetes uses the credentials from your host when it goes to pull images.
Chapter 2. Image Registry Operator in OpenShift Container Platform Copy linkLink copied to clipboard!
2.1. Image Registry on cloud platforms and OpenStack Copy linkLink copied to clipboard!
The Image Registry Operator installs a single instance of the OpenShift Container Platform registry, and manages all registry configuration, including setting up registry storage.
Storage is only automatically configured when you install an installer-provisioned infrastructure cluster on AWS, GCP, Azure, or OpenStack.
When you install or upgrade an installer-provisioned infrastructure cluster on AWS or Azure, the Image Registry Operator sets the
spec.storage.managementState
Managed
spec.storage.managementState
Unmanaged
After the control plane deploys, the Operator will create a default
configs.imageregistry.operator.openshift.io
If insufficient information is available to define a complete
configs.imageregistry.operator.openshift.io
The Image Registry Operator runs in the
openshift-image-registry
The Image Registry Operator’s behavior for managing the pruner is orthogonal to the
managementState
ClusterOperator
Managed
Pruning
However, the
managementState
-
: the
Managedflag for the image pruner is set to--prune-registry.true -
: the
Removedflag for the image pruner is set to--prune-registry, meaning it only prunes image metatdata in etcd.false -
: the
Unmanagedflag for the image pruner is set to--prune-registry.false
2.2. Image Registry on bare metal and vSphere Copy linkLink copied to clipboard!
2.2.1. Image registry removed during installation Copy linkLink copied to clipboard!
On platforms that do not provide shareable object storage, the OpenShift Image Registry Operator bootstraps itself as
Removed
openshift-installer
After installation, you must edit the Image Registry Operator configuration to switch the
managementState
Removed
Managed
The Prometheus console provides an
ImageRegistryRemoved
"Image Registry has been removed.
ImageStreamTags
BuildConfigs
DeploymentConfigs
ImageStreamTags
Managed
2.3. Image Registry Operator configuration parameters Copy linkLink copied to clipboard!
The
configs.imageregistry.operator.openshift.io
| Parameter | Description |
|---|---|
|
|
|
|
| Sets
The supported values for
|
|
| Value needed by the registry to secure uploads, generated by default. |
|
| Defines the Proxy to be used when calling master API and upstream registries. |
|
|
|
|
| Indicates whether the registry instance should reject attempts to push new images or delete existing ones. |
|
| API Request Limit details. Controls how many parallel requests a given registry instance will handle before queuing additional requests. |
|
| Determines whether or not an external route is defined using the default hostname. If enabled, the route uses re-encrypt encryption. Defaults to
|
|
| Array of additional routes to create. You provide the hostname and certificate for the route. |
|
| Replica count for the registry. |
|
| Controls whether to route all data through the registry, rather than redirecting to the back end. Defaults to
|
|
| The Image Registry Operator sets the
|
2.4. Enable the Image Registry default route with the Custom Resource Definition Copy linkLink copied to clipboard!
In OpenShift Container Platform, the
Registry
configs.imageregistry.operator.openshift.io
If you need to automatically enable the Image Registry default route, patch the Image Registry Operator CRD.
Procedure
Patch the Image Registry Operator CRD:
$ oc patch configs.imageregistry.operator.openshift.io/cluster --type merge -p '{"spec":{"defaultRoute":true}}'
2.5. Configuring additional trust stores for image registry access Copy linkLink copied to clipboard!
The
image.config.openshift.io/cluster
Prerequisites
- The certificate authorities (CA) must be PEM-encoded.
Procedure
You can create a config map in the
openshift-config
AdditionalTrustedCA
image.config.openshift.io
The config map key is the hostname of a registry with the port for which this CA is to be trusted, and the base64-encoded certificate 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: |
-----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 clusterspec: additionalTrustedCA: name: registry-config
2.6. Configuring storage credentials for the Image Registry Operator Copy linkLink copied to clipboard!
In addition to the
configs.imageregistry.operator.openshift.io
openshift-image-registry
The
image-registry-private-configuration-user
Procedure
Create an OpenShift Container Platform secret that contains the required keys.
$ oc create secret generic image-registry-private-configuration-user --from-literal=KEY1=value1 --from-literal=KEY2=value2 --namespace openshift-image-registry
Chapter 3. Setting up and configuring the registry Copy linkLink copied to clipboard!
3.1. Configuring the registry for AWS user-provisioned infrastructure Copy linkLink copied to clipboard!
3.1.1. Configuring a secret for the Image Registry Operator Copy linkLink copied to clipboard!
In addition to the
configs.imageregistry.operator.openshift.io
openshift-image-registry
The
image-registry-private-configuration-user
For S3 on AWS storage, the secret is expected to contain two keys:
-
REGISTRY_STORAGE_S3_ACCESSKEY -
REGISTRY_STORAGE_S3_SECRETKEY
Procedure
Create an OpenShift Container Platform secret that contains the required keys.
$ oc create secret generic image-registry-private-configuration-user --from-literal=REGISTRY_STORAGE_S3_ACCESSKEY=myaccesskey --from-literal=REGISTRY_STORAGE_S3_SECRETKEY=mysecretkey --namespace openshift-image-registry
3.1.2. Configuring registry storage for AWS with user-provisioned infrastructure Copy linkLink copied to clipboard!
During installation, your cloud credentials are sufficient to create an Amazon S3 bucket and the Registry Operator will automatically configure storage.
If the Registry Operator cannot create an S3 bucket and automatically configure storage, you can create an S3 bucket and configure storage with the following procedure.
Prerequisites
- You have a cluster on AWS with user-provisioned infrastructure.
For Amazon S3 storage, the secret is expected to contain two keys:
-
REGISTRY_STORAGE_S3_ACCESSKEY -
REGISTRY_STORAGE_S3_SECRETKEY
-
Procedure
Use the following procedure if the Registry Operator cannot create an S3 bucket and automatically configure storage.
- Set up a Bucket Lifecycle Policy to abort incomplete multipart uploads that are one day old.
Fill in the storage configuration in
:configs.imageregistry.operator.openshift.io/cluster$ oc edit configs.imageregistry.operator.openshift.io/clusterExample configuration
storage: s3: bucket: <bucket-name> region: <region-name>
To secure your registry images in AWS, block public access to the S3 bucket.
3.1.3. Image Registry Operator configuration parameters for AWS S3 Copy linkLink copied to clipboard!
The following configuration parameters are available for AWS S3 registry storage.
ImageRegistryConfigStorageS3
| Parameter | Description |
|---|---|
|
| Bucket is the bucket name in which you want to store the registry’s data. It is optional and is generated if not provided. |
|
| Region is the AWS region in which your bucket exists. It is optional and is set based on the installed AWS Region. |
|
| RegionEndpoint is the endpoint for S3 compatible storage services. It is optional and defaults based on the Region that is provided. |
|
| VirtualHostedStyle enables using S3 virtual hosted style bucket paths with a custom RegionEndpoint. It is optional and defaults to false. Set this parameter to deploy OpenShift Container Platform to hidden regions. |
|
| Encrypt specifies whether or not the registry stores the image in encrypted format. It is optional and defaults to false. |
|
| KeyID is the KMS key ID to use for encryption. It is optional. Encrypt must be true, or this parameter is ignored. |
|
| CloudFront configures Amazon Cloudfront as the storage middleware in a registry. It is optional. |
When the value of the
regionEndpoint
regionEndpoint: http://rook-ceph-rgw-ocs-storagecluster-cephobjectstore.openshift-storage.svc.cluster.local
3.2. Configuring the registry for GCP user-provisioned infrastructure Copy linkLink copied to clipboard!
3.2.1. Configuring a secret for the Image Registry Operator Copy linkLink copied to clipboard!
In addition to the
configs.imageregistry.operator.openshift.io
openshift-image-registry
The
image-registry-private-configuration-user
For GCS on GCP storage, the secret is expected to contain one key whose value is the contents of a credentials file provided by GCP:
-
REGISTRY_STORAGE_GCS_KEYFILE
Procedure
Create an OpenShift Container Platform secret that contains the required keys.
$ oc create secret generic image-registry-private-configuration-user --from-file=REGISTRY_STORAGE_GCS_KEYFILE=<path_to_keyfile> --namespace openshift-image-registry
3.2.2. Registry storage for GCP with user-provisioned infrastructure Copy linkLink copied to clipboard!
You must set up the storage medium manually and configure the settings in the registry custom resource (CR).
Prerequisites
- A cluster on GCP with user-provisioned infrastructure.
- To configure registry storage for GCP, you need to provide Registry Operator cloud credentials.
For GCS on GCP storage, the secret is expected to contain one key whose value is the contents of a credentials file provided by GCP:
-
REGISTRY_STORAGE_GCS_KEYFILE
-
3.2.3. Image Registry Operator configuration parameters for GCP GCS Copy linkLink copied to clipboard!
Procedure
The following configuration parameters are available for GCP GCS registry storage.
| Parameter | Description |
|---|---|
|
| Bucket is the bucket name in which you want to store the registry’s data. It is optional and is generated if not provided. |
|
| Region is the GCS location in which your bucket exists. It is optional and is set based on the installed GCS Region. |
|
| ProjectID is the Project ID of the GCP project that this bucket should be associated with. It is optional. |
|
| KeyID is the KMS key ID to use for encryption. It is optional because buckets are encrypted by default on GCP. This allows for the use of a custom encryption key. |
3.3. Configuring the registry for OpenStack user-provisioned infrastructure Copy linkLink copied to clipboard!
You can configure the registry of a cluster that runs on your own Red Hat OpenStack Platform (RHOSP) infrastructure.
3.3.1. Configuring the Image Registry Operator to trust Swift storage Copy linkLink copied to clipboard!
You must configure the Image Registry Operator to trust Red Hat OpenStack Platform (RHOSP) Swift storage.
Procedure
From a command line, enter the following command to change the value of the
field in thespec.disableRedirectobject toconfig.imageregistry:true$ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"disableRedirect":true}}'
3.3.2. Configuring a secret for the Image Registry Operator Copy linkLink copied to clipboard!
In addition to the
configs.imageregistry.operator.openshift.io
openshift-image-registry
The
image-registry-private-configuration-user
For Swift on Red Hat OpenStack Platform (RHOSP) storage, the secret is expected to contain the following two keys:
-
REGISTRY_STORAGE_SWIFT_USER -
REGISTRY_STORAGE_SWIFT_PASSWORD
Procedure
Create an OpenShift Container Platform secret that contains the required keys.
$ oc create secret generic image-registry-private-configuration-user --from-literal=REGISTRY_STORAGE_SWIFT_USER=<username> --from-literal=REGISTRY_STORAGE_SWIFT_PASSWORD=<password> -n openshift-image-registry
3.3.3. Registry storage for RHOSP with user-provisioned infrastructure Copy linkLink copied to clipboard!
You must set up the storage medium manually and configure the settings in the registry custom resource (CR).
Prerequisites
- A cluster on Red Hat OpenStack Platform (RHOSP) with user-provisioned infrastructure.
- To configure registry storage for RHOSP, you need to provide Registry Operator cloud credentials.
For Swift on RHOSP storage, the secret is expected to contain the following two keys:
-
REGISTRY_STORAGE_SWIFT_USER -
REGISTRY_STORAGE_SWIFT_PASSWORD
-
3.3.4. Image Registry Operator configuration parameters for RHOSP Swift Copy linkLink copied to clipboard!
The following configuration parameters are available for Red Hat OpenStack Platform (RHOSP) Swift registry storage.
| Parameter | Description |
|---|---|
|
| This value is optional. |
|
| This value is optional. |
|
| This value is optional. |
|
| This value is optional. |
|
| This value is optional. |
|
| This value is optional. |
|
| This value is optional. |
|
| This value is optional. |
3.4. Configuring the registry for Azure user-provisioned infrastructure Copy linkLink copied to clipboard!
3.4.1. Configuring a secret for the Image Registry Operator Copy linkLink copied to clipboard!
In addition to the
configs.imageregistry.operator.openshift.io
openshift-image-registry
The
image-registry-private-configuration-user
For Azure registry storage, the secret is expected to contain one key whose value is the contents of a credentials file provided by Azure:
-
REGISTRY_STORAGE_AZURE_ACCOUNTKEY
Procedure
Create an OpenShift Container Platform secret that contains the required key.
$ oc create secret generic image-registry-private-configuration-user --from-literal=REGISTRY_STORAGE_AZURE_ACCOUNTKEY=<accountkey> --namespace openshift-image-registry
3.4.2. Configuring registry storage for Azure Copy linkLink copied to clipboard!
During installation, your cloud credentials are sufficient to create Azure Blob Storage, and the Registry Operator automatically configures storage.
Prerequisites
- A cluster on Azure with user-provisioned infrastructure.
- To configure registry storage for Azure, provide Registry Operator cloud credentials.
For Azure storage the secret is expected to contain one key:
-
REGISTRY_STORAGE_AZURE_ACCOUNTKEY
-
Procedure
- Create an Azure storage container.
Fill in the storage configuration in
:configs.imageregistry.operator.openshift.io/cluster$ oc edit configs.imageregistry.operator.openshift.io/clusterExample configuration
storage: azure: accountName: <storage-account-name> container: <container-name>
3.4.3. Configuring registry storage for Azure Government Copy linkLink copied to clipboard!
During installation, your cloud credentials are sufficient to create Azure Blob Storage, and the Registry Operator automatically configures storage.
Prerequisites
- A cluster on Azure with user-provisioned infrastructure in a government region.
- To configure registry storage for Azure, provide Registry Operator cloud credentials.
For Azure storage, the secret is expected to contain one key:
-
REGISTRY_STORAGE_AZURE_ACCOUNTKEY
-
Procedure
- Create an Azure storage container.
Fill in the storage configuration in
:configs.imageregistry.operator.openshift.io/cluster$ oc edit configs.imageregistry.operator.openshift.io/clusterExample configuration
storage: azure: accountName: <storage-account-name> container: <container-name> cloudName: AzureUSGovernmentCloud1 - 1
cloudNameis the name of the Azure cloud environment, which can be used to configure the Azure SDK with the appropriate Azure API endpoints. Defaults toAzurePublicCloud. You can also setcloudNametoAzureUSGovernmentCloud,AzureChinaCloud, orAzureGermanCloudwith sufficient credentials.
3.5. Configuring the registry for RHOSP Copy linkLink copied to clipboard!
3.5.1. Configuring an image registry with custom storage on clusters that run on RHOSP Copy linkLink copied to clipboard!
After you install a cluster on Red Hat OpenStack Platform (RHOSP), you can use a Cinder volume that is in a specific availability zone for registry storage.
Procedure
Create a YAML file that specifies the storage class and availability zone to use. For example:
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: custom-csi-storageclass provisioner: cinder.csi.openstack.org volumeBindingMode: WaitForFirstConsumer allowVolumeExpansion: true parameters: availability: <availability_zone_name>NoteOpenShift Container Platform does not verify the existence of the availability zone you choose. Verify the name of the availability zone before you apply the configuration.
From a command line, apply the configuration:
$ oc apply -f <storage_class_file_name>Example output
storageclass.storage.k8s.io/custom-csi-storageclass createdCreate a YAML file that specifies a persistent volume claim (PVC) that uses your storage class and the
namespace. For example:openshift-image-registryapiVersion: v1 kind: PersistentVolumeClaim metadata: name: csi-pvc-imageregistry namespace: openshift-image-registry1 annotations: imageregistry.openshift.io: "true" spec: accessModes: - ReadWriteOnce volumeMode: Filesystem resources: requests: storage: 100Gi2 storageClassName: <your_custom_storage_class>3 From a command line, apply the configuration:
$ oc apply -f <pvc_file_name>Example output
persistentvolumeclaim/csi-pvc-imageregistry createdReplace the original persistent volume claim in the image registry configuration with the new claim:
$ oc patch configs.imageregistry.operator.openshift.io/cluster --type 'json' -p='[{"op": "replace", "path": "/spec/storage/pvc/claim", "value": "csi-pvc-imageregistry"}]'Example output
config.imageregistry.operator.openshift.io/cluster patchedOver the next several minutes, the configuration is updated.
Verification
To confirm that the registry is using the resources that you defined:
Verify that the PVC claim value is identical to the name that you provided in your PVC definition:
$ oc get configs.imageregistry.operator.openshift.io/cluster -o yamlExample output
... status: ... managementState: Managed pvc: claim: csi-pvc-imageregistry ...Verify that the status of the PVC is
:Bound$ oc get pvc -n openshift-image-registry csi-pvc-imageregistryExample output
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE csi-pvc-imageregistry Bound pvc-72a8f9c9-f462-11e8-b6b6-fa163e18b7b5 100Gi RWO custom-csi-storageclass 11m
3.6. Configuring the registry for bare metal Copy linkLink copied to clipboard!
3.6.1. Image registry removed during installation Copy linkLink copied to clipboard!
On platforms that do not provide shareable object storage, the OpenShift Image Registry Operator bootstraps itself as
Removed
openshift-installer
After installation, you must edit the Image Registry Operator configuration to switch the
managementState
Removed
Managed
The Prometheus console provides an
ImageRegistryRemoved
"Image Registry has been removed.
ImageStreamTags
BuildConfigs
DeploymentConfigs
ImageStreamTags
Managed
3.6.2. Changing the image registry’s management state Copy linkLink copied to clipboard!
To start the image registry, you must change the Image Registry Operator configuration’s
managementState
Removed
Managed
Procedure
Change
Image Registry Operator configuration frommanagementStatetoRemoved. For example:Managed$ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"managementState":"Managed"}}'
3.6.3. Image registry storage configuration Copy linkLink copied to clipboard!
The Image Registry Operator is not initially available for platforms that do not provide default storage. After installation, you must configure your registry to use storage so that the Registry Operator is made available.
Instructions are shown for configuring a persistent volume, which is required for production clusters. Where applicable, instructions are shown for configuring an empty directory as the storage location, which is available for only non-production clusters.
Additional instructions are provided for allowing the image registry to use block storage types by using the
Recreate
3.6.4. Configuring registry storage for bare metal and other manual installations Copy linkLink copied to clipboard!
As a cluster administrator, following installation you must configure your registry to use storage.
Prerequisites
-
You have access to the cluster as a user with the role.
cluster-admin - You have a cluster that uses manually-provisioned Red Hat Enterprise Linux CoreOS (RHCOS) nodes, such as bare metal.
You have provisioned persistent storage for your cluster, such as Red Hat OpenShift Container Storage.
ImportantOpenShift Container Platform supports
access for image registry storage when you have only one replica.ReadWriteOnceaccess also requires that the registry uses theReadWriteOncerollout strategy. To deploy an image registry that supports high availability with two or more replicas,Recreateaccess is required.ReadWriteMany- Must have 100Gi capacity.
Procedure
To configure your registry to use storage, change the
in thespec.storage.pvcresource.configs.imageregistry/clusterNoteWhen using shared storage, review your security settings to prevent outside access.
Verify that you do not have a registry pod:
$ oc get pod -n openshift-image-registry -l docker-registry=defaultExample output
No resourses found in openshift-image-registry namespaceNoteIf you do have a registry pod in your output, you do not need to continue with this procedure.
Check the registry configuration:
$ oc edit configs.imageregistry.operator.openshift.ioExample output
storage: pvc: claim:Leave the
field blank to allow the automatic creation of anclaimPVC.image-registry-storageCheck the
status:clusteroperator$ oc get clusteroperator image-registryExample output
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE image-registry 4.7 True False False 6h50mEnsure that your registry is set to managed to enable building and pushing of images.
Run:
$ oc edit configs.imageregistry/clusterThen, change the line
managementState: Removedto
managementState: Managed
3.6.5. Configuring storage for the image registry in non-production clusters Copy linkLink copied to clipboard!
You must configure storage for the Image Registry Operator. For non-production clusters, you can set the image registry to an empty directory. If you do so, all images are lost if you restart the registry.
Procedure
To set the image registry storage to an empty directory:
$ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"storage":{"emptyDir":{}}}}'WarningConfigure this option for only non-production clusters.
If you run this command before the Image Registry Operator initializes its components, the
command fails with the following error:oc patchError from server (NotFound): configs.imageregistry.operator.openshift.io "cluster" not foundWait a few minutes and run the command again.
3.6.6. Configuring block registry storage Copy linkLink copied to clipboard!
To allow the image registry to use block storage types during upgrades as a cluster administrator, you can use the
Recreate
Block storage volumes are supported but not recommended for use with the image registry on production clusters. An installation where the registry is configured on block storage is not highly available because the registry cannot have more than one replica.
Procedure
To set the image registry storage as a block storage type, patch the registry so that it uses the
rollout strategy and runs with only one (Recreate) replica:1$ oc patch config.imageregistry.operator.openshift.io/cluster --type=merge -p '{"spec":{"rolloutStrategy":"Recreate","replicas":1}}'- Provision the PV for the block storage device, and create a PVC for that volume. The requested block volume uses the ReadWriteOnce (RWO) access mode.
- Edit the registry configuration so that it references the correct PVC.
3.7. Configuring the registry for vSphere Copy linkLink copied to clipboard!
3.7.1. Image registry removed during installation Copy linkLink copied to clipboard!
On platforms that do not provide shareable object storage, the OpenShift Image Registry Operator bootstraps itself as
Removed
openshift-installer
After installation, you must edit the Image Registry Operator configuration to switch the
managementState
Removed
Managed
The Prometheus console provides an
ImageRegistryRemoved
"Image Registry has been removed.
ImageStreamTags
BuildConfigs
DeploymentConfigs
ImageStreamTags
Managed
3.7.2. Changing the image registry’s management state Copy linkLink copied to clipboard!
To start the image registry, you must change the Image Registry Operator configuration’s
managementState
Removed
Managed
Procedure
Change
Image Registry Operator configuration frommanagementStatetoRemoved. For example:Managed$ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"managementState":"Managed"}}'
3.7.2.1. Image registry storage configuration Copy linkLink copied to clipboard!
The Image Registry Operator is not initially available for platforms that do not provide default storage. After installation, you must configure your registry to use storage so that the Registry Operator is made available.
Instructions are shown for configuring a persistent volume, which is required for production clusters. Where applicable, instructions are shown for configuring an empty directory as the storage location, which is available for only non-production clusters.
Additional instructions are provided for allowing the image registry to use block storage types by using the
Recreate
3.7.3. Configuring registry storage for VMware vSphere Copy linkLink copied to clipboard!
As a cluster administrator, following installation you must configure your registry to use storage.
Prerequisites
- Cluster administrator permissions.
- A cluster on VMware vSphere.
Persistent storage provisioned for your cluster, such as Red Hat OpenShift Container Storage.
ImportantOpenShift Container Platform supports
access for image registry storage when you have only one replica.ReadWriteOnceaccess also requires that the registry uses theReadWriteOncerollout strategy. To deploy an image registry that supports high availability with two or more replicas,Recreateaccess is required.ReadWriteMany- Must have "100Gi" capacity.
Testing shows issues with using the NFS server on RHEL as storage backend for core services. This includes the OpenShift Container Registry and Quay, Prometheus for monitoring storage, and Elasticsearch for logging storage. Therefore, using RHEL NFS to back PVs used by core services is not recommended.
Other NFS implementations on the marketplace might not have these issues. Contact the individual NFS implementation vendor for more information on any testing that was possibly completed against these OpenShift Container Platform core components.
Procedure
To configure your registry to use storage, change the
in thespec.storage.pvcresource.configs.imageregistry/clusterNoteWhen using shared storage, review your security settings to prevent outside access.
Verify that you do not have a registry pod:
$ oc get pod -n openshift-image-registry -l docker-registry=defaultExample output
No resourses found in openshift-image-registry namespaceNoteIf you do have a registry pod in your output, you do not need to continue with this procedure.
Check the registry configuration:
$ oc edit configs.imageregistry.operator.openshift.ioExample output
storage: pvc: claim:1 - 1
- Leave the
claimfield blank to allow the automatic creation of animage-registry-storagepersistent volume claim (PVC). The PVC is generated based on the default storage class. However, be aware that the default storage class might provide ReadWriteOnce (RWO) volumes, such as a RADOS Block Device (RBD), which can cause issues when replicating to more than one replica.
Check the
status:clusteroperator$ oc get clusteroperator image-registryExample output
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE image-registry 4.7 True False False 6h50m
3.7.4. Configuring storage for the image registry in non-production clusters Copy linkLink copied to clipboard!
You must configure storage for the Image Registry Operator. For non-production clusters, you can set the image registry to an empty directory. If you do so, all images are lost if you restart the registry.
Procedure
To set the image registry storage to an empty directory:
$ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"storage":{"emptyDir":{}}}}'WarningConfigure this option for only non-production clusters.
If you run this command before the Image Registry Operator initializes its components, the
command fails with the following error:oc patchError from server (NotFound): configs.imageregistry.operator.openshift.io "cluster" not foundWait a few minutes and run the command again.
3.7.5. Configuring block registry storage for VMware vSphere Copy linkLink copied to clipboard!
To allow the image registry to use block storage types such as vSphere Virtual Machine Disk (VMDK) during upgrades as a cluster administrator, you can use the
Recreate
Block storage volumes are supported but not recommended for use with image registry on production clusters. An installation where the registry is configured on block storage is not highly available because the registry cannot have more than one replica.
Procedure
To set the image registry storage as a block storage type, patch the registry so that it uses the
rollout strategy and runs with onlyRecreatereplica:1$ oc patch config.imageregistry.operator.openshift.io/cluster --type=merge -p '{"spec":{"rolloutStrategy":"Recreate","replicas":1}}'Provision the PV for the block storage device, and create a PVC for that volume. The requested block volume uses the ReadWriteOnce (RWO) access mode.
Create a
file with the following contents to define a VMware vSpherepvc.yamlobject:PersistentVolumeClaimkind: PersistentVolumeClaim apiVersion: v1 metadata: name: image-registry-storage1 namespace: openshift-image-registry2 spec: accessModes: - ReadWriteOnce3 resources: requests: storage: 100Gi4 - 1
- A unique name that represents the
PersistentVolumeClaimobject. - 2
- The namespace for the
PersistentVolumeClaimobject, which isopenshift-image-registry. - 3
- The access mode of the persistent volume claim. With
ReadWriteOnce, the volume can be mounted with read and write permissions by a single node. - 4
- The size of the persistent volume claim.
Create the
object from the file:PersistentVolumeClaim$ oc create -f pvc.yaml -n openshift-image-registry
Edit the registry configuration so that it references the correct PVC:
$ oc edit config.imageregistry.operator.openshift.io -o yamlExample output
storage: pvc: claim:1 - 1
- Creating a custom PVC allows you to leave the
claimfield blank for the default automatic creation of animage-registry-storagePVC.
For instructions about configuring registry storage so that it references the correct PVC, see Configuring the registry for vSphere.
Chapter 4. Accessing the registry Copy linkLink copied to clipboard!
Use the following sections for instructions on accessing the registry, including viewing logs and metrics, as well as securing and exposing the registry.
You can access the registry directly to invoke
podman
podman push
podman pull
podman login
4.1. Prerequisites Copy linkLink copied to clipboard!
- You must have configured an identity provider (IDP).
For pulling images, for example when using the
command, the user must have thepodman pullrole. To add this role, run the following command:registry-viewer$ oc policy add-role-to-user registry-viewer <user_name>For writing or pushing images, for example when using the
command:podman pushThe user must have the
role. To add this role, run the following command:registry-editor$ oc policy add-role-to-user registry-editor <user_name>- Your cluster must have an existing project where the images can be pushed to.
4.2. Accessing registry directly from the cluster Copy linkLink copied to clipboard!
You can access the registry from inside the cluster.
Procedure
Access the registry from the cluster by using internal routes:
Access the node by getting the node’s name:
$ oc get nodes$ oc debug nodes/<node_name>To enable access to tools such as
andocon the node, change your root directory topodman:/hostsh-4.2# chroot /hostLog in to the container image registry by using your access token:
sh-4.2# oc login -u kubeadmin -p <password_from_install_log> https://api-int.<cluster_name>.<base_domain>:6443sh-4.2# podman login -u kubeadmin -p $(oc whoami -t) image-registry.openshift-image-registry.svc:5000You should see a message confirming login, such as:
Login Succeeded!NoteYou can pass any value for the user name; the token contains all necessary information. Passing a user name that contains colons will result in a login failure.
Since the Image Registry Operator creates the route, it will likely be similar to
.default-route-openshift-image-registry.<cluster_name>Perform
andpodman pulloperations against your registry:podman pushImportantYou can pull arbitrary images, but if you have the system:registry role added, you can only push images to the registry in your project.
In the following examples, use:
Expand Component Value <registry_ip>
172.30.124.220<port>
5000<project>
openshift<image>
image<tag>
omitted (defaults to
)latestPull an arbitrary image:
sh-4.2# podman pull name.io/imageTag the new image with the form
. The project name must appear in this pull specification for OpenShift Container Platform to correctly place and later access the image in the registry:<registry_ip>:<port>/<project>/<image>sh-4.2# podman tag name.io/image image-registry.openshift-image-registry.svc:5000/openshift/imageNoteYou must have the
role for the specified project, which allows the user to write or push an image. Otherwise, thesystem:image-builderin the next step will fail. To test, you can create a new project to push the image.podman pushPush the newly tagged image to your registry:
sh-4.2# podman push image-registry.openshift-image-registry.svc:5000/openshift/image
4.3. Checking the status of the registry pods Copy linkLink copied to clipboard!
As a cluster administrator, you can list the image registry pods running in the
openshift-image-registry
Prerequisites
-
You have access to the cluster as a user with the role.
cluster-admin
Procedure
List the pods in the
project and view their status:openshift-image-registry$ oc get pods -n openshift-image-registryExample output
NAME READY STATUS RESTARTS AGE cluster-image-registry-operator-764bd7f846-qqtpb 1/1 Running 0 78m image-registry-79fb4469f6-llrln 1/1 Running 0 77m node-ca-hjksc 1/1 Running 0 73m node-ca-tftj6 1/1 Running 0 77m node-ca-wb6ht 1/1 Running 0 77m node-ca-zvt9q 1/1 Running 0 74m
4.4. Viewing registry logs Copy linkLink copied to clipboard!
You can view the logs for the registry by using the
oc logs
Procedure
Use the
command with deployments to view the logs for the container image registry:oc logs$ oc logs deployments/image-registry -n openshift-image-registryExample output
2015-05-01T19:48:36.300593110Z time="2015-05-01T19:48:36Z" level=info msg="version=v2.0.0+unknown" 2015-05-01T19:48:36.303294724Z time="2015-05-01T19:48:36Z" level=info msg="redis not configured" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002 2015-05-01T19:48:36.303422845Z time="2015-05-01T19:48:36Z" level=info msg="using inmemory layerinfo cache" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002 2015-05-01T19:48:36.303433991Z time="2015-05-01T19:48:36Z" level=info msg="Using OpenShift Auth handler" 2015-05-01T19:48:36.303439084Z time="2015-05-01T19:48:36Z" level=info msg="listening on :5000" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002
4.5. Accessing registry metrics Copy linkLink copied to clipboard!
The OpenShift Container Registry provides an endpoint for Prometheus metrics. Prometheus is a stand-alone, open source systems monitoring and alerting toolkit.
The metrics are exposed at the /extensions/v2/metrics path of the registry endpoint.
Procedure
There are two ways in which you can access the metrics, running a metrics query or using the cluster role.
Metrics query
Run a metrics query, for example:
$ curl --insecure -s -u <user>:<secret> \1 https://image-registry.openshift-image-registry.svc:5000/extensions/v2/metrics | grep imageregistry | head -n 20Example output
# HELP imageregistry_build_info A metric with a constant '1' value labeled by major, minor, git commit & git version from which the image registry was built. # TYPE imageregistry_build_info gauge imageregistry_build_info{gitCommit="9f72191",gitVersion="v3.11.0+9f72191-135-dirty",major="3",minor="11+"} 1 # HELP imageregistry_digest_cache_requests_total Total number of requests without scope to the digest cache. # TYPE imageregistry_digest_cache_requests_total counter imageregistry_digest_cache_requests_total{type="Hit"} 5 imageregistry_digest_cache_requests_total{type="Miss"} 24 # HELP imageregistry_digest_cache_scoped_requests_total Total number of scoped requests to the digest cache. # TYPE imageregistry_digest_cache_scoped_requests_total counter imageregistry_digest_cache_scoped_requests_total{type="Hit"} 33 imageregistry_digest_cache_scoped_requests_total{type="Miss"} 44 # HELP imageregistry_http_in_flight_requests A gauge of requests currently being served by the registry. # TYPE imageregistry_http_in_flight_requests gauge imageregistry_http_in_flight_requests 1 # HELP imageregistry_http_request_duration_seconds A histogram of latencies for requests to the registry. # TYPE imageregistry_http_request_duration_seconds summary imageregistry_http_request_duration_seconds{method="get",quantile="0.5"} 0.01296087 imageregistry_http_request_duration_seconds{method="get",quantile="0.9"} 0.014847248 imageregistry_http_request_duration_seconds{method="get",quantile="0.99"} 0.015981195 imageregistry_http_request_duration_seconds_sum{method="get"} 12.260727916000022- 1
<user>can be arbitrary, but<secret>must match the value specified in the registry configuration.
Cluster role
Create a cluster role if you do not already have one to access the metrics:
$ cat <<EOF | oc create -f - apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: prometheus-scraper rules: - apiGroups: - image.openshift.io resources: - registry/metrics verbs: - get EOFAdd this role to a user, run the following command:
$ oc adm policy add-cluster-role-to-user prometheus-scraper <username>Access the metrics using cluster role. The part of the configuration file responsible for metrics should look like this:
openshift: version: 1.0 metrics: enabled: true ...
Chapter 5. Exposing the registry Copy linkLink copied to clipboard!
By default, the OpenShift Container Platform registry is secured during cluster installation so that it serves traffic through TLS. Unlike previous versions of OpenShift Container Platform, the registry is not exposed outside of the cluster at the time of installation.
5.1. Exposing a default registry manually Copy linkLink copied to clipboard!
Instead of logging in to the default OpenShift Container Platform registry from within the cluster, you can gain external access to it by exposing it with a route. This external access enables you to log in to the registry from outside the cluster using the route address and to tag and push images to an existing project by using the route host.
Prerequisites:
The following prerequisites are automatically performed:
- Deploy the Registry Operator.
- Deploy the Ingress Operator.
Procedure
You can expose the route by using the
defaultRoute
configs.imageregistry.operator.openshift.io
To expose the registry using the
defaultRoute
Set
todefaultRoute:true$ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=mergeGet the default registry route:
$ HOST=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')Get the certificate of the Ingress Operator:
$ oc get secret -n openshift-ingress router-certs-default -o go-template='{{index .data "tls.crt"}}' | base64 -d | sudo tee /etc/pki/ca-trust/source/anchors/${HOST}.crt > /dev/nullEnable the cluster’s default certificate to trust the route using the following commands:
$ sudo update-ca-trust enableLog in with podman using the default route:
$ sudo podman login -u kubeadmin -p $(oc whoami -t) $HOST
5.2. Exposing a secure registry manually Copy linkLink copied to clipboard!
Instead of logging in to the OpenShift Container Platform registry from within the cluster, you can gain external access to it by exposing it with a route. This allows you to log in to the registry from outside the cluster using the route address, and to tag and push images to an existing project by using the route host.
Prerequisites:
The following prerequisites are automatically performed:
- Deploy the Registry Operator.
- Deploy the Ingress Operator.
Procedure
You can expose the route by using
DefaultRoute
configs.imageregistry.operator.openshift.io
To expose the registry using
DefaultRoute
Set
toDefaultRoute:True$ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=mergeLog in with
:podman$ HOST=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')$ podman login -u kubeadmin -p $(oc whoami -t) --tls-verify=false $HOST1 - 1
--tls-verify=falseis needed if the cluster’s default certificate for routes is untrusted. You can set a custom, trusted certificate as the default certificate with the Ingress Operator.
To expose the registry using custom routes:
Create a secret with your route’s TLS keys:
$ oc create secret tls public-route-tls \ -n openshift-image-registry \ --cert=</path/to/tls.crt> \ --key=</path/to/tls.key>This step is optional. If you do not create a secret, the route uses the default TLS configuration from the Ingress Operator.
On the Registry Operator:
spec: routes: - name: public-routes hostname: myregistry.mycorp.organization secretName: public-route-tls ...NoteOnly set
if you are providing a custom TLS configuration for the registry’s route.secretName
Legal Notice
Copy linkLink copied to clipboard!
Copyright © Red Hat
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of the OpenJS Foundation.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.