Accessing the registry

You can access the registry directly to invoke 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 podman login command. The operations you can perform depend on your user permissions, as described in the following sections.

You have access to the cluster as a user with the cluster-admin role.
You must have configured an identity provider (IDP).
For pulling images, for example when using the podman pull command, the user must have the registry-viewer role. To add this role, run the following command:
For writing or pushing images, for example when using the podman push command:
- The user must have the registry-editor role. To add this role, run the following command:
```
$ oc policy add-role-to-user registry-editor <user_name>
```
- Your cluster must have an existing project where the images can be pushed to.

Accessing the 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 name:
```
$ oc get nodes
```
```
$ oc debug nodes/<node_name>
```
To enable access to tools such as oc and podman on the node, change your root directory to /host:
```
sh-4.2# chroot /host
```

sh-4.2# oc login -u kubeadmin -p <password_from_install_log> https://api-int.<cluster_name>.<base_domain>:6443

You should see a message confirming login, such as:

Login Succeeded!

Perform podman pull and podman push operations against your registry:
1. Pull an arbitrary image:
```
sh-4.2# podman pull <name.io>/<image>
```
2. Tag the new image with the form <registry_ip>:<port>/<project>/<image>. The project name must appear in this pull specification for OKD to correctly place and later access the image in the registry:

As a cluster administrator, you can list the image registry pods running in the openshift-image-registry project and check their status.

Prerequisites

You have access to the cluster as a user with the cluster-admin role.

Procedure

List the pods in the openshift-image-registry project and view their status:
```
$ oc get pods -n openshift-image-registry
```

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:

$ oc logs deployments/image-registry -n openshift-image-registry

Example 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

The OpenShift Container Registry provides an endpoint for . 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

You can access the metrics by running a metrics query using a cluster role.

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:
EOF

Add this role to a user, run the following command:

Metrics query

Get the user token.
```
openshift:
$ oc whoami -t
```

Run a metrics query in node or inside a pod, for example:

Example 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

Additional resources

For more information on allowing pods in a project to reference images in another project, see .
A can access the registry until deleted. See Removing the kubeadmin user for more information.