This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.Registry
Configuring registries for OpenShift Container Platform 4.2
概要
第1章 Image Registry リンクのコピーリンクがクリップボードにコピーされました!
1.1. Integrated OpenShift Container Platform registry リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform provides a built in container image registry which 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 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.
Additional resources
第2章 Image Registry Operator in OpenShift Container Platform リンクのコピーリンクがクリップボードにコピーされました!
The Image Registry Operator installs a single instance of the OpenShift Container Platform registry, and it manages all configuration of the registry, including setting up registry storage.
Storage is only automatically configured when you install an installer-provisioned infrastructure cluster on AWS, GCP, Azure, or OpenStack.
After the control plane deploys, the Operator will create a default configs.imageregistry.operator.openshift.io
resource instance based on configuration detected in the cluster.
If insufficient information is available to define a complete configs.imageregistry.operator.openshift.io
resource, the incomplete resource will be defined and the operator will update the resource status with information about what is missing.
The Image Registry Operator runs in the openshift-image-registry
namespace, and manages the registry instance in that location as well. All configuration and workload resources for the registry reside in that namespace.
2.1. Image Registry Operator configuration parameters リンクのコピーリンクがクリップボードにコピーされました!
The configs.imageregistry.operator.openshift.io
resource offers the following configuration parameters.
Parameter | Description |
---|---|
|
|
|
Sets |
| 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 false. |
| Array of additional routes to create. You provide the hostname and certificate for the route. |
| Replica count for the registry. |
2.2. Enable the Image Registry default route with the Custom Resource Definition リンクのコピーリンクがクリップボードにコピーされました!
In OpenShift Container Platform, the Registry
Operator controls the registry feature. The Operator is defined by the configs.imageregistry.operator.openshift.io
Custom Resource Definition (CRD).
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}}'
$ oc patch configs.imageregistry.operator.openshift.io/cluster --type merge -p '{"spec":{"defaultRoute":true}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3. Configuring a ConfigMap for the Image Registry Operator リンクのコピーリンクがクリップボードにコピーされました!
In addition to the configs.imageregistry.operator.openshift.io
and secret resources, configuration is provided to the Operator by a separate ConfigMap resource located within the openshift-image-registry
namespace.
Prerequisites
- The CAs must be PEM-encoded.
Procedure
You can create a ConfigMap in the openshift-config
namespace and use its name in AdditionalTrustedCA
in the image.config.openshift.io
resource to provide additional CAs that should be trusted when contacting external registries.
The key is the host name of a registry with the port for which this CA is to be trusted.
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
$ 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
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Check your image inside the
image-registry
pod:oc rsh image-registry-xxxxx ls /etc/pki/ca-trust/source/anchors
$ oc rsh image-registry-xxxxx sh-4.2 $ ls /etc/pki/ca-trust/source/anchors <external_registry_address> image-registry.openshift-image-registry.svc..5000 image-registry.openshift-image-registry.svc.cluster.local..5000
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Image registry CA example
- 1
- If the registry has the port, such as
registry-with-port.example.com:5000
,:
should be replaced with..
.
2.4. Configuring a secret for the Image Registry Operator リンクのコピーリンクがクリップボードにコピーされました!
In addition to the configs.imageregistry.operator.openshift.io
and ConfigMap resources, configuration is provided to the Operator by a separate secret resource located within the openshift-image-registry
namespace.
The image-registry-private-configuration-user
secret provides credentials needed for storage access and management. It overrides the default credentials used by the Operator, if default credentials were found.
Procedure
Create an OpenShift Container Platform secret that contains the required keys.
oc create secret generic image-registry-private-configuration-user --from-file=KEY1=value1 --from-literal=KEY2=value2 --namespace openshift-image-registry
$ oc create secret generic image-registry-private-configuration-user --from-file=KEY1=value1 --from-literal=KEY2=value2 --namespace openshift-image-registry
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5. Additional resources リンクのコピーリンクがクリップボードにコピーされました!
第3章 Configuring registry storage リンクのコピーリンクがクリップボードにコピーされました!
3.1. Configuring registry storage for AWS user-provisioned infrastructure リンクのコピーリンクがクリップボードにコピーされました!
3.1.1. Configuring a secret for the Image Registry Operator リンクのコピーリンクがクリップボードにコピーされました!
In addition to the configs.imageregistry.operator.openshift.io
and ConfigMap resources, configuration is provided to the Operator by a separate secret resource located within the openshift-image-registry
namespace.
The image-registry-private-configuration-user
secret provides credentials needed for storage access and management. It overrides the default credentials used by the Operator, if default credentials were found.
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
$ 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
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.1.2. Configuring registry storage for AWS with user-provisioned infrastructure リンクのコピーリンクがクリップボードにコピーされました!
During installation, your cloud credentials are sufficient to create an 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
- A cluster on AWS with user-provisioned infrastructure.
For S3 on AWS 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
:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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 リンクのコピーリンクがクリップボードにコピーされました!
The following configuration parameters are available for AWS S3 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 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. |
| 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. |
3.2. Configuring registry storage for GCP user-provisioned infrastructure リンクのコピーリンクがクリップボードにコピーされました!
3.2.1. Configuring a secret for the Image Registry Operator リンクのコピーリンクがクリップボードにコピーされました!
In addition to the configs.imageregistry.operator.openshift.io
and ConfigMap resources, configuration is provided to the Operator by a separate secret resource located within the openshift-image-registry
namespace.
The image-registry-private-configuration-user
secret provides credentials needed for storage access and management. It overrides the default credentials used by the Operator, if default credentials were found.
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
$ oc create secret generic image-registry-private-configuration-user --from-file=REGISTRY_STORAGE_GCS_KEYFILE=<path_to_keyfile> --namespace openshift-image-registry
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.2.2. Registry storage for GCP with user-provisioned infrastructure リンクのコピーリンクがクリップボードにコピーされました!
You must set up the storage medium manually and configure the settings in the registry CRD.
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 リンクのコピーリンクがクリップボードにコピーされました!
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 registry storage for bare metal リンクのコピーリンクがクリップボードにコピーされました!
3.3.1. Configuring registry storage for bare metal リンクのコピーリンクがクリップボードにコピーされました!
As a cluster administrator, following installation you must configure your registry to use storage.
Prerequisites
- Cluster administrator permissions.
- A cluster on bare metal.
- Provision persistent storage for your cluster, such as Red Hat OpenShift Container Storage. To deploy a private image registry, your storage must provide ReadWriteMany access mode.
- Must have "100Gi" capacity.
Procedure
-
To configure your registry to use storage, change the
spec.storage.pvc
in theconfigs.imageregistry/cluster
resource. Verify you do not have a registry Pod:
oc get pod -n openshift-image-registry
$ oc get pod -n openshift-image-registry
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記If the storage type is
emptyDIR
, the replica number cannot be greater than1
. If the storage type isNFS
, and you want to scale up the registry Pod by settingreplica>1
you must enable theno_wdelay
mount option. For example:cat /etc/exports /mnt/data *(rw,sync,no_wdelay,no_root_squash,insecure,fsid=0) sh-4.3# exportfs -rv exporting *:/mnt/data
# cat /etc/exports /mnt/data *(rw,sync,no_wdelay,no_root_squash,insecure,fsid=0) sh-4.3# exportfs -rv exporting *:/mnt/data
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Check the registry configuration:
oc edit configs.imageregistry.operator.openshift.io
$ oc edit configs.imageregistry.operator.openshift.io storage: pvc: claim:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Leave the
claim
field blank to allow the automatic creation of animage-registry-storage
PVC.Check the
clusteroperator
status:oc get clusteroperator image-registry
$ oc get clusteroperator image-registry
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3.2. Additional resources リンクのコピーリンクがクリップボードにコピーされました!
For more details on configuring registry storage for bare metal, see Recommended configurable storage technology.
3.4. Configuring registry storage for vSphere リンクのコピーリンクがクリップボードにコピーされました!
3.4.1. Configuring registry storage for VMware vSphere リンクのコピーリンクがクリップボードにコピーされました!
As a cluster administrator, following installation you must configure your registry to use storage.
Prerequisites
- Cluster administrator permissions.
- A cluster on VMware vSphere.
A provisioned persistent volume (PV) with
ReadWriteMany
access mode, such asNFS
.重要vSphere volumes do not support the
ReadWriteMany
access mode. You must use a different storage backend, such asNFS
, to configure the registry storage.- Must have "100Gi" capacity.
Procedure
-
To configure your registry to use storage, change the
spec.storage.pvc
in theconfigs.imageregistry/cluster
resource. Verify you do not have a registry Pod:
oc get pod -n openshift-image-registry
$ oc get pod -n openshift-image-registry
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記If the storage type is
emptyDIR
, the replica number cannot be greater than1
. If the storage type isNFS
, and you want to scale up the registry Pod by settingreplica>1
you must enable theno_wdelay
mount option. For example:cat /etc/exports /mnt/data *(rw,sync,no_wdelay,no_root_squash,insecure,fsid=0) sh-4.3# exportfs -rv exporting *:/mnt/data
# cat /etc/exports /mnt/data *(rw,sync,no_wdelay,no_root_squash,insecure,fsid=0) sh-4.3# exportfs -rv exporting *:/mnt/data
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Check the registry configuration:
oc edit configs.imageregistry.operator.openshift.io
$ oc edit configs.imageregistry.operator.openshift.io storage: pvc: claim:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Leave the
claim
field blank to allow the automatic creation of animage-registry-storage
PVC.Optional: Add a new storage class to a PV:
Create the PV:
oc create -f -
$ oc create -f -
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get pv
$ oc get pv
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create the PVC:
oc create -n openshift-image-registry -f -
$ oc create -n openshift-image-registry -f -
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get pvc -n openshift-image-registry
$ oc get pvc -n openshift-image-registry
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Finally, add the name of your PVC:
oc edit configs.imageregistry.operator.openshift.io -o yaml
$ oc edit configs.imageregistry.operator.openshift.io -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow storage: pvc: claim: image-registry-pvc
storage: pvc: claim: image-registry-pvc
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Creating a custom PVC allows you to leave the
claim
field blank for default automatic creation of animage-registry-storage
PVC.
Check the
clusteroperator
status:oc get clusteroperator image-registry
$ oc get clusteroperator image-registry
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.4.2. Additional resources リンクのコピーリンクがクリップボードにコピーされました!
For more details on configuring registry storage for vSphere, see Recommended configurable storage technology.
第4章 Registry options リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform can build images from your source code, deploy them, and manage their lifecycle. To enable this, OpenShift Container Platform provides an internal, integrated container image registry that can be deployed in your OpenShift Container Platform environment to locally manage images.
4.1. Integrated OpenShift Container Platform registry リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform provides a built in container image registry which 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 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.
4.2. Third party registries リンクのコピーリンクがクリップボードにコピーされました!
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.
Refreshing the fetched tags is as simple as running oc import-image <stream>
. When new images are detected, the previously-described build and deployment reactions occur.
4.2.1. Authentication リンクのコピーリンクがクリップボードにコピーされました!
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.
4.3. Red Hat Quay registries リンクのコピーリンクがクリップボードにコピーされました!
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.
4.4. Authentication enabled Red Hat registry リンクのコピーリンクがクリップボードにコピーされました!
All container images available through the Red Hat Container Catalog are hosted on an image registry, registry.redhat.io
.
The registry, registry.redhat.io
, requires authentication for access to images and hosted content on OpenShift Container Platform. Following the move to the new registry, the existing registry will be available for a period of time.
OpenShift Container Platform pulls images from registry.redhat.io
, so you must configure your cluster to use it.
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
access.redhat.com
. 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.
You can use podman login
with your credentials, either username and password or authentication token, to access content on the new registry.
All imagestreams point to the new registry. Because the registry requires authentication for access, the Samples Operator creates the samples-registry-credentials
secret.
You must place your credentials in two places:
- OpenShift namespace. Your credentials must exist in the OpenShift namespace so that the imagestreams in the OpenShift namespace can import.
- Your host. Your credentials must exist on your host because Kubernetes uses the credentials from your host when it goes to pull images.
第5章 Accessing the registry リンクのコピーリンクがクリップボードにコピーされました!
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
commands. This allows you to push images to or pull them from the integrated registry directly using operations like podman push
or podman pull
. To do so, you must be logged in to the registry using the oc login
command. The operations you can perform depend on your user permissions, as described in the following sections.
Prerequisites
- You must have configured an identity provider (IDP).
For pulling images, for example when using the
podman pull
command, the user must have theregistry-viewer
role. To add this role:oc policy add-role-to-user registry-viewer <user_name>
$ oc policy add-role-to-user registry-viewer <user_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow For writing or pushing images, for example when using the
podman push
command, the user must have theregistry-editor
role. To add this role:oc policy add-role-to-user registry-editor <user_name>
$ oc policy add-role-to-user registry-editor <user_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.1. Accessing registry directly from the cluster リンクのコピーリンクがクリップボードにコピーされました!
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 address:
oc get nodes oc debug nodes/<node_address>
$ oc get nodes $ oc debug nodes/<node_address>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow In order to have access to tools such as
oc
andpodman
on the node, run the following command:chroot /host
sh-4.2# chroot /host
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Log in to the container image registry by using your access token:
oc login -u kubeadmin -p <password_from_install_log> https://api-int.<cluster_name>.<base_domain>:6443 podman login -u kubeadmin -p $(oc whoami -t) image-registry.openshift-image-registry.svc:5000
sh-4.4# oc login -u kubeadmin -p <password_from_install_log> https://api-int.<cluster_name>.<base_domain>:6443 sh-4.4# podman login -u kubeadmin -p $(oc whoami -t) image-registry.openshift-image-registry.svc:5000
Copy to Clipboard Copied! Toggle word wrap Toggle overflow You should see a message confirming login, such as:
Login Succeeded!
Login Succeeded!
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記You 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
podman pull
andpodman push
operations against your registry:重要You 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
latest
)Pull an arbitrary image:
podman pull name.io/image
$ podman pull name.io/image
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Tag the new image with the form
<registry_ip>:<port>/<project>/<image>
. The project name must appear in this pull specification for OpenShift Container Platform to correctly place and later access the image in the registry:podman tag name.io/image image-registry.openshift-image-registry.svc:5000/openshift/image
$ podman tag name.io/image image-registry.openshift-image-registry.svc:5000/openshift/image
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記You must have the
system:image-builder
role for the specified project, which allows the user to write or push an image. Otherwise, thepodman push
in the next step will fail. To test, you can create a new project to push the image.Push the newly-tagged image to your registry:
podman push image-registry.openshift-image-registry.svc:5000/openshift/image
$ podman push image-registry.openshift-image-registry.svc:5000/openshift/image
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2. Viewing the registry’s contents リンクのコピーリンクがクリップボードにコピーされました!
As an administrator, you can view your registry’s contents.
Prerequisites
- Log in as administrator.
Procedure
Check the pods under project
openshift-image-registry
:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3. Viewing registry logs リンクのコピーリンクがクリップボードにコピーされました!
You can view the logs for the registry by using the oc logs
command.
Procedure
Use the
oc logs
command with deployments to view the logs for the container image registry:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4. Accessing registry metrics リンクのコピーリンクがクリップボードにコピーされました!
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:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Add this role to a user, run the following command:
oc adm policy add-cluster-role-to-user prometheus-scraper <username>
$ oc adm policy add-cluster-role-to-user prometheus-scraper <username>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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 ...
openshift: version: 1.0 metrics: enabled: true ...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Additional resources
-
A
kubeadmin
can access the registry until deleted. See Removing the kubeadmin user for more information. - For more information on configuring an identity provider, see Understanding identity provider configuration.
第6章 Exposing the registry リンクのコピーリンクがクリップボードにコピーされました!
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.
6.1. Exposing a secure registry manually リンクのコピーリンクがクリップボードにコピーされました!
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 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
parameter in the configs.imageregistry.operator.openshift.io
resource or by using custom routes.
To expose the registry using DefaultRoute
:
Set
DefaultRoute
toTrue
:oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge
$ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Log in with Podman:
HOST=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}') podman login -u $(oc whoami) -p $(oc whoami -t) --tls-verify=false $HOST
$ HOST=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}') $ podman login -u $(oc whoami) -p $(oc whoami -t) --tls-verify=false $HOST
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
--tls-verify=false
is 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 image-registry \ --cert=</path/to/tls.crt> \ --key=</path/to/tls.key>
$ oc create secret tls public-route-tls \ -n image-registry \ --cert=</path/to/tls.crt> \ --key=</path/to/tls.key>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Only set
secretName
if you are providing a custom TLS configuration for the registry’s route.
Legal Notice
リンクのコピーリンクがクリップボードにコピーされました!
Copyright © 2025 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 Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
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.