Azure Red Hat OpenShift can build images from your source code, deploy them, and manage their lifecycle. To enable this, Azure Red Hat OpenShift provides an internal, integrated container image registry that can be deployed in your Azure Red Hat OpenShift environment to locally manage images.
Azure Red Hat OpenShift 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.
Azure Red Hat OpenShift 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 Azure Red Hat OpenShift registry. In this situation Azure Red Hat OpenShift will fetch tags from the remote registry upon imagestream creation.
Refreshing the fetched tags is as simple as running
<stream>. When new images are detected, the previously-described build and
deployment reactions occur.
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 Azure Red Hat OpenShift like any remote container image registry.
All container images available through the Red Hat Container Catalog are hosted
on an image registry,
registry.redhat.io, requires authentication for access to
images and hosted content on Azure Red Hat OpenShift. Following the move to the new
registry, the existing registry will be available for a period of time.
Azure Red Hat OpenShift pulls images from
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 Azure Red Hat OpenShift, it
is not supported for production deployments. Restrict this authentication method
to stand-alone projects outside Azure Red Hat OpenShift.
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
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.