diff --git a/_topic_maps/_topic_map_rosa.yml b/_topic_maps/_topic_map_rosa.yml index bdf669133e..437d83c89e 100644 --- a/_topic_maps/_topic_map_rosa.yml +++ b/_topic_maps/_topic_map_rosa.yml @@ -903,8 +903,6 @@ Topics: File: configuring-registry-operator - Name: Accessing the registry File: accessing-the-registry -# - Name: Exposing the registry -# File: securing-exposing-registry --- Name: Operators Dir: operators diff --git a/_topic_maps/_topic_map_rosa_hcp.yml b/_topic_maps/_topic_map_rosa_hcp.yml index e93dff044f..942b2df8cd 100644 --- a/_topic_maps/_topic_map_rosa_hcp.yml +++ b/_topic_maps/_topic_map_rosa_hcp.yml @@ -1145,6 +1145,17 @@ Topics: - Name: Installing OADP on ROSA with STS File: backing-up-applications --- +Name: Registry +Dir: registry +Distros: openshift-rosa-hcp +Topics: +- Name: Registry overview + File: index +- Name: Image Registry Operator in Red Hat OpenShift Service on AWS + File: configuring-registry-operator +- Name: Accessing the registry + File: accessing-the-registry +--- Name: Nodes Dir: nodes Distros: openshift-rosa-hcp diff --git a/modules/registry-authentication-enabled-registry-overview.adoc b/modules/registry-authentication-enabled-registry-overview.adoc index 21bf481c5d..239410707b 100644 --- a/modules/registry-authentication-enabled-registry-overview.adoc +++ b/modules/registry-authentication-enabled-registry-overview.adoc @@ -36,12 +36,12 @@ to stand-alone projects outside {product-title}. 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, which uses the installation pull secret to authenticate. +All image streams point to the new registry, which uses the installation pull secret to authenticate. You must place your credentials in either of the following places: * *`openshift` namespace*. Your credentials must exist in the `openshift` -namespace so that the imagestreams in the `openshift` namespace can import. +namespace so that the image streams 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. diff --git a/modules/registry-checking-the-status-of-registry-pods.adoc b/modules/registry-checking-the-status-of-registry-pods.adoc index 734309365e..280798baa5 100644 --- a/modules/registry-checking-the-status-of-registry-pods.adoc +++ b/modules/registry-checking-the-status-of-registry-pods.adoc @@ -6,22 +6,22 @@ [id="checking-the-status-of-registry-pods_{context}"] = Checking the status of the registry pods -ifndef::openshift-dedicated,openshift-rosa[] +ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] As a cluster administrator, -endif::openshift-dedicated,openshift-rosa[] -ifdef::openshift-dedicated,openshift-rosa[] +endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] As an administrator with the `dedicated-admin` role, -endif::openshift-dedicated,openshift-rosa[] +endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] you can list the image registry pods running in the `openshift-image-registry` project and check their status. .Prerequisites -ifndef::openshift-dedicated,openshift-rosa[] +ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] * You have access to the cluster as a user with the `cluster-admin` role. -endif::openshift-dedicated,openshift-rosa[] -ifdef::openshift-dedicated,openshift-rosa[] +endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] * You have access to the cluster as a user with the `dedicated-admin` role. -endif::openshift-dedicated,openshift-rosa[] +endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] .Procedure @@ -36,7 +36,6 @@ $ oc get pods -n openshift-image-registry [source,terminal] ---- 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 diff --git a/modules/registry-common-terms.adoc b/modules/registry-common-terms.adoc index 4bedd0ce71..1f320efa6f 100644 --- a/modules/registry-common-terms.adoc +++ b/modules/registry-common-terms.adoc @@ -9,10 +9,17 @@ 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. +Lightweight and executable images that consist of software and all its dependencies. Because containers virtualize the operating system, you can run containers in a data center, a public or private cloud, or your local host. +ifdef::openshift-rosa,openshift-rosa-hcp[] Image Registry Operator:: +ifdef::openshift-rosa-hcp[] +The Image Registry Operator runs in the `CONTROL_PLANE_NAMESPACE` of the management cluster, and manages the registry instance in openshift-image-registry of the cluster. +endif::openshift-rosa-hcp[] +ifdef::openshift-rosa[] The Image Registry Operator runs in the `openshift-image-registry` namespace, and manages the registry instance in that location. +endif::openshift-rosa[] +endif::openshift-rosa,openshift-rosa-hcp[] image repository:: An image repository is a collection of related container images and tags identifying images. @@ -33,7 +40,7 @@ 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 {product-title} clusters. +A public Red Hat Quay Container Registry instance provided and maintained by Red Hat, which serves most of the container images and Operators to {product-title} clusters. {product-registry}:: {product-registry} is the registry provided by {product-title} to manage images. diff --git a/modules/registry-integrated-openshift-registry.adoc b/modules/registry-integrated-openshift-registry.adoc index 13fb1654ff..2d95297fac 100644 --- a/modules/registry-integrated-openshift-registry.adoc +++ b/modules/registry-integrated-openshift-registry.adoc @@ -25,4 +25,4 @@ 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. +and image streams. diff --git a/modules/registry-third-party-registries.adoc b/modules/registry-third-party-registries.adoc index fb7a9af140..f3233cb11b 100644 --- a/modules/registry-third-party-registries.adoc +++ b/modules/registry-third-party-registries.adoc @@ -6,7 +6,7 @@ [id="registry-third-party-registries_{context}"] = Third-party registries -{product-title} 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 {product-registry}. In this situation, {product-title} will fetch tags from the remote registry upon imagestream creation. To refresh the fetched tags, run `oc import-image `. When new images are detected, the previously described build and deployment reactions occur. +{product-title} 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 {product-registry}. In this situation, {product-title} will fetch tags from the remote registry upon image stream creation. To refresh the fetched tags, run `oc import-image `. When new images are detected, the previously described build and deployment reactions occur. [id="authentication_{context}"] == Authentication diff --git a/registry/accessing-the-registry.adoc b/registry/accessing-the-registry.adoc index 04496cbdd6..d4f8812feb 100644 --- a/registry/accessing-the-registry.adoc +++ b/registry/accessing-the-registry.adoc @@ -6,7 +6,7 @@ include::_attributes/common-attributes.adoc[] toc::[] -ifndef::openshift-dedicated,openshift-rosa[] +ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] Use the following sections for instructions on accessing the registry, including viewing logs and metrics, as well as securing and exposing the registry. @@ -15,13 +15,13 @@ 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. -endif::openshift-dedicated,openshift-rosa[] +endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -ifdef::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] In {product-title}, Red Hat Site Reliability Engineering (SRE) manages the registry for you. However, you can check the status of the registry pods and view the registry logs. -endif::openshift-dedicated,openshift-rosa[] +endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -ifndef::openshift-dedicated,openshift-rosa[] +ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] == Prerequisites * You have access to the cluster as a user with the `cluster-admin` role. @@ -43,17 +43,17 @@ $ oc policy add-role-to-user registry-editor ---- + ** Your cluster must have an existing project where the images can be pushed to. -endif::openshift-dedicated,openshift-rosa[] +endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -ifndef::openshift-dedicated,openshift-rosa[] +ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] include::modules/registry-accessing-directly.adoc[leveloffset=+1] -endif::openshift-dedicated,openshift-rosa[] +endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] include::modules/registry-checking-the-status-of-registry-pods.adoc[leveloffset=+1] include::modules/registry-viewing-logs.adoc[leveloffset=+1] -ifndef::openshift-dedicated,openshift-rosa[] +ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] include::modules/registry-accessing-metrics.adoc[leveloffset=+1] [id="accessing-the-registry-additional-resources"] @@ -66,4 +66,4 @@ xref:../authentication/remove-kubeadmin.adoc[Removing the kubeadmin user] for more information. * For more information on configuring an identity provider, see xref:../authentication/understanding-identity-provider.adoc[Understanding identity provider configuration]. -endif::openshift-dedicated,openshift-rosa[] +endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] diff --git a/registry/configuring-registry-operator.adoc b/registry/configuring-registry-operator.adoc index 80409f810c..fbc66f4d16 100644 --- a/registry/configuring-registry-operator.adoc +++ b/registry/configuring-registry-operator.adoc @@ -7,31 +7,36 @@ include::_attributes/common-attributes.adoc[] toc::[] [id="image-registry-on-cloud"] -ifndef::openshift-dedicated,openshift-rosa[] +ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] == Image Registry on cloud platforms and OpenStack -endif::openshift-dedicated,openshift-rosa[] -ifdef::openshift-dedicated,openshift-rosa[] +endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] == Image Registry on {product-title} -endif::openshift-dedicated,openshift-rosa[] +endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] The Image Registry Operator installs a single instance of the {product-registry}, and manages all registry configuration, including setting up registry storage. -ifndef::openshift-dedicated,openshift-rosa[] +ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] [NOTE] ==== Storage is only automatically configured when you install an installer-provisioned infrastructure cluster on AWS, Azure, GCP, {ibm-name}, or OpenStack. When you install or upgrade an installer-provisioned infrastructure cluster on AWS, Azure, GCP, {ibm-name}, or OpenStack, the Image Registry Operator sets the `spec.storage.managementState` parameter to `Managed`. If the `spec.storage.managementState` parameter is set to `Unmanaged`, the Image Registry Operator takes no action related to storage. ==== -endif::openshift-dedicated,openshift-rosa[] +endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -After the control plane deploys, the Operator creates a default `configs.imageregistry.operator.openshift.io` resource instance based on configuration detected in the cluster. +After the control plane deploys in the management cluster, the Operator creates 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 is defined and the Operator updates the resource status with information about what is missing. +ifdef::openshift-rosa-hcp[] +The Image Registry Operator runs in the `CONTROL_PLANE_NAMESPACE` of the management cluster, and manages the registry instance in openshift-image-registry namespace of the cluster. All configuration and workload resources for the registry reside in that namespace. +endif::openshift-rosa-hcp[] +ifdef::openshift-rosa[] 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. +endif::openshift-rosa[] -ifndef::openshift-dedicated,openshift-rosa[] +ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] [IMPORTANT] ==== The Image Registry Operator's behavior for managing the pruner is orthogonal to the `managementState` specified on the `ClusterOperator` object for the Image Registry Operator. If the Image Registry Operator is not in the `Managed` state, the image pruner can still be configured and managed by the `Pruning` custom resource. @@ -41,9 +46,9 @@ However, the `managementState` of the Image Registry Operator alters the behavio * `Managed`: the `--prune-registry` flag for the image pruner is set to `true`. * `Removed`: the `--prune-registry` flag for the image pruner is set to `false`, meaning it only prunes image metadata in etcd. ==== -endif::openshift-dedicated,openshift-rosa[] +endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -ifndef::openshift-dedicated,openshift-rosa[] +ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] [id="image-registry-on-bare-metal-vsphere"] == Image Registry on bare metal, Nutanix, and vSphere @@ -77,4 +82,4 @@ include::modules/registry-operator-config-resources-storage-credentials.adoc[lev * xref:../registry/configuring_registry_storage/configuring-registry-storage-osp.adoc#configuring-registry-storage-openstack[Configuring the registry for {rh-openstack}] * xref:../registry/configuring_registry_storage/configuring-registry-storage-rhodf.adoc#configuring-registry-storage-rhodf[Configuring the registry for Red Hat OpenShift Data Foundation] * xref:../registry/configuring_registry_storage/configuring-registry-storage-nutanix.adoc#configuring-registry-storage-nutanix[Configuring the registry for Nutanix] -endif::openshift-dedicated,openshift-rosa[] \ No newline at end of file +endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] \ No newline at end of file