Add latest changes from gitlab-org/gitlab@16-7-stable-eev16.7.0-rc42

1 files changed, 18 insertions, 20 deletions

diff --git a/doc/administration/geo/replication/container_registry.md b/doc/administration/geo/replication/container_registry.md
index 65ecba0d04a..b9bee753089 100644
--- a/doc/administration/geo/replication/container_registry.md
+++ b/doc/administration/geo/replication/container_registry.md
@@ -1,17 +1,16 @@
 ---
 stage: Systems
 group: Geo
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
-type: howto
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Container Registry for a secondary site **(PREMIUM SELF)**
+# Container registry for a secondary site **(PREMIUM SELF)**
 
-You can set up a Container Registry on your **secondary** Geo site that mirrors the one on the **primary** Geo site.
+You can set up a container registry on your **secondary** Geo site that mirrors the one on the **primary** Geo site.
 
 NOTE:
-The Container Registry replication is used only for disaster recovery purposes. We do not recommend
-pulling the Container Registry data from the secondary. For a feature proposal to implement it in the
+The container registry replication is used only for disaster recovery purposes. We do not recommend
+pulling the container registry data from the secondary. For a feature proposal to implement it in the
 future, see [Geo: Accelerate container images by serving read request from secondary site](https://gitlab.com/gitlab-org/gitlab/-/issues/365864) for details.
 
 ## Supported container registries
@@ -40,7 +39,7 @@ For more information on supported registry storage drivers see
 
 Read the [Load balancing considerations](https://docs.docker.com/registry/deploying/#load-balancing-considerations)
 when deploying the Registry, and how to set up the storage driver for the GitLab integrated
-[Container Registry](../../packages/container_registry.md#use-object-storage).
+[container registry](../../packages/container_registry.md#use-object-storage).
 
 ### Registries that support OCI artifacts
 
@@ -55,26 +54,26 @@ The following registries support OCI artifacts:
 
 For more information, see the [OCI Distribution Specification](https://github.com/opencontainers/distribution-spec).
 
-## Configure Container Registry replication
+## Configure container registry replication
 
 You can enable a storage-agnostic replication so it
 can be used for cloud or local storage. Whenever a new image is pushed to the
 **primary** site, each **secondary** site pulls it to its own container
 repository.
 
-To configure Container Registry replication:
+To configure container registry replication:
 
 1. Configure the [**primary** site](#configure-primary-site).
 1. Configure the [**secondary** site](#configure-secondary-site).
-1. Verify Container Registry [replication](#verify-replication).
+1. Verify container registry [replication](#verify-replication).
 
 ### Configure **primary** site
 
-Make sure that you have Container Registry set up and working on
+Make sure that you have container registry set up and working on
 the **primary** site before following the next steps.
 
-To be able to replicate new container images, the Container Registry must send notification events to the
-**primary** site for every push. The token shared between the Container Registry and the web nodes on the
+To be able to replicate new container images, the container registry must send notification events to the
+**primary** site for every push. The token shared between the container registry and the web nodes on the
 **primary** is used to make communication more secure.
 
 1. SSH into your GitLab **primary** server and login as root (for GitLab HA, you only need a Registry node):
@@ -124,17 +123,17 @@ To be able to replicate new container images, the Container Registry must send n
 
 ### Configure **secondary** site
 
-Make sure you have Container Registry set up and working on
+Make sure you have container registry set up and working on
 the **secondary** site before following the next steps.
 
 The following steps should be done on each **secondary** site you're
 expecting to see the container images replicated.
 
 Because we need to allow the **secondary** site to communicate securely with
-the **primary** site Container Registry, we need to have a single key
+the **primary** site container registry, we need to have a single key
 pair for all the sites. The **secondary** site uses this key to
 generate a short-lived JWT that is pull-only-capable to access the
-**primary** site Container Registry.
+**primary** site container registry.
 
 For each application and Sidekiq node on the **secondary** site:
 
@@ -164,11 +163,10 @@ For each application and Sidekiq node on the **secondary** site:
 
 ### Verify replication
 
-To verify Container Registry replication is working, on the **secondary** site:
+To verify container registry replication is working, on the **secondary** site:
 
-1. On the left sidebar, select **Search or go to**.
-1. Select **Admin Area**.
-1. On the left sidebar, select **Geo > Nodes**.
+1. On the left sidebar, at the bottom, select **Admin Area**.
+1. Select **Geo > Nodes**.
    The initial replication, or "backfill", is probably still in progress.
 
 You can monitor the synchronization process on each Geo site from the **primary** site's **Geo Nodes** dashboard in your browser.