Add latest changes from gitlab-org/gitlab@15-1-stable-eev15.1.0-rc42

16 files changed, 141 insertions, 289 deletions

diff --git a/doc/install/aws/eks_clusters_aws.md b/doc/install/aws/eks_clusters_aws.md
index fe436a03cb5..342740994a1 100644
--- a/doc/install/aws/eks_clusters_aws.md
+++ b/doc/install/aws/eks_clusters_aws.md
@@ -1,5 +1,5 @@
 ---
-stage: Enablement
+stage: Systems
 group: Distribution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
diff --git a/doc/install/aws/gitlab_hybrid_on_aws.md b/doc/install/aws/gitlab_hybrid_on_aws.md
index 055cb4c3efb..bc811cab3bf 100644
--- a/doc/install/aws/gitlab_hybrid_on_aws.md
+++ b/doc/install/aws/gitlab_hybrid_on_aws.md
@@ -1,5 +1,5 @@
 ---
-stage: Enablement
+stage: Systems
 group: Distribution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
@@ -168,7 +168,7 @@ If EKS node autoscaling is employed, it is likely that your average loading will
 | Gitaly Instances (in ASG)                                    | 12 vCPU, 45GB<br />(across 3 nodes)                          | **m5.xlarge** x 3 nodes<br />(48 vCPU, 180 GB)          | $0.192 x 3 = $0.58/hr           | $0.192 x 3 = $0.58/hr           |
 |                                                              | The GitLab Reference architecture for 2K is not Highly Available and therefore has a single Gitaly no Praefect. AWS Quick Starts MUST be HA, so it implements Prafect from the 3K Ref Architecture to meet that requirement |                                                         |                                 |                                 |
 | Praefect (Instances in ASG with load balancer)               | 6 vCPU, 10 GB<br />([across 3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections)) | **c5.large** x 3 nodes<br />(6 vCPU, 12 GB)             | $0.09 x 3 = $0.21/hr            | $0.09 x 3 = $0.21/hr            |
-| Praefect PostgreSQL(1) (AWS RDS)                             | 6 vCPU, 5.4 GB<br />([across 3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections)) | N/A Reuses GitLab PostgreSQL                            | $0                              | $0                              |
+| Praefect PostgreSQL(1) (AWS RDS)                             | 6 vCPU, 5.4 GB<br />([across 3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections)) | Not applicable; reuses GitLab PostgreSQL                            | $0                              | $0                              |
 | Internal Load Balancing Node                                 | 2 vCPU, 1.8 GB                                               | AWS ELB                                                 | $0.10/hr                        | $0.10/hr                        |
 
 ### 3K Cloud Native Hybrid on EKS
@@ -222,7 +222,7 @@ If EKS node autoscaling is employed, it is likely that your average loading will
 | **<u>Gitaly Cluster</u>** [Details](gitlab_sre_for_aws.md#gitaly-sre-considerations) |                                                              |                                                         |                                 |                                                              |
 | Gitaly Instances (in ASG)                                    | 12 vCPU, 45GB<br />([across 3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections)) | **m5.large** x 3 nodes<br />(12 vCPU, 48 GB)            | $0.192 x 3 = $0.58/hr           | [Gitaly & Praefect Must Have an Uneven Node Count for HA](gitlab_sre_for_aws.md#gitaly-and-praefect-elections) |
 | Praefect (Instances in ASG with load balancer)               | 6 vCPU, 5.4 GB<br />([across 3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections)) | **c5.large** x 3 nodes<br />(6 vCPU, 12 GB)             | $0.09 x 3 = $0.21/hr            | [Gitaly & Praefect Must Have an Uneven Node Count for HA](gitlab_sre_for_aws.md#gitaly-and-praefect-elections) |
-| Praefect PostgreSQL(1) (Amazon RDS)                             | 6 vCPU, 5.4 GB<br />([across 3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections)) | N/A Reuses GitLab PostgreSQL                            | $0                              |                                                              |
+| Praefect PostgreSQL(1) (Amazon RDS)                             | 6 vCPU, 5.4 GB<br />([across 3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections)) | Not applicable; reuses GitLab PostgreSQL                            | $0                              |                                                              |
 | Internal Load Balancing Node                                 | 2 vCPU, 1.8 GB                                               | AWS ELB                                                 | $0.10/hr                        | $0.10/hr                                                     |
 
 ### 5K Cloud Native Hybrid on EKS
@@ -276,7 +276,7 @@ If EKS node autoscaling is employed, it is likely that your average loading will
 | **<u>Gitaly Cluster</u>** [Details](gitlab_sre_for_aws.md#gitaly-sre-considerations) |                                                              |                                                         |                                 |                                                              |
 | Gitaly Instances (in ASG)                                    | 24 vCPU, 90GB<br />([across 3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections)) | **m5.2xlarge** x 3 nodes<br />(24 vCPU, 96GB)           | $0.384 x 3 = $1.15/hr           | [Gitaly & Praefect Must Have an Uneven Node Count for HA](gitlab_sre_for_aws.md#gitaly-and-praefect-elections) |
 | Praefect (Instances in ASG with load balancer)               | 6 vCPU, 5.4 GB<br />([across 3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections)) | **c5.large** x 3 nodes<br />(6 vCPU, 12 GB)             | $0.09 x 3 = $0.21/hr            | [Gitaly & Praefect Must Have an Uneven Node Count for HA](gitlab_sre_for_aws.md#gitaly-and-praefect-elections) |
-| Praefect PostgreSQL(1) (Amazon RDS)                             | 6 vCPU, 5.4 GB<br />([across 3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections)) | N/A Reuses GitLab PostgreSQL                            | $0                              |                                                              |
+| Praefect PostgreSQL(1) (Amazon RDS)                             | 6 vCPU, 5.4 GB<br />([across 3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections)) | Not applicable; reuses GitLab PostgreSQL                            | $0                              |                                                              |
 | Internal Load Balancing Node                                 | 2 vCPU, 1.8 GB                                               | AWS ELB                                                 | $0.10/hr                        | $0.10/hr                                                     |
 
 ### 10K Cloud Native Hybrid on EKS
@@ -329,7 +329,7 @@ If EKS node autoscaling is employed, it is likely that your average loading will
 | **<u>Gitaly Cluster</u>** [Details](gitlab_sre_for_aws.md#gitaly-sre-considerations) |  |  |  |  |
 | Gitaly Instances (in ASG) | 48 vCPU, 180GB<br />([across 3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections)) | **m5.4xlarge** x 3 nodes<br />(48 vCPU, 180 GB) | $0.77 x 3 = $2.31/hr | [Gitaly & Praefect Must Have an Uneven Node Count for HA](gitlab_sre_for_aws.md#gitaly-and-praefect-elections) |
 | Praefect (Instances in ASG with load balancer) | 6 vCPU, 5.4 GB<br />([across 3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections)) | **c5.large** x 3 nodes<br />(6 vCPU, 12 GB) | $0.09 x 3 = $0.21/hr | [Gitaly & Praefect Must Have an Uneven Node Count for HA](gitlab_sre_for_aws.md#gitaly-and-praefect-elections) |
-| Praefect PostgreSQL(1) (Amazon RDS) | 6 vCPU, 5.4 GB<br />([across 3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections)) | N/A Reuses GitLab PostgreSQL | $0 |  |
+| Praefect PostgreSQL(1) (Amazon RDS) | 6 vCPU, 5.4 GB<br />([across 3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections)) | Not applicable; reuses GitLab PostgreSQL | $0 |  |
 | Internal Load Balancing Node | 2 vCPU, 1.8 GB | AWS ELB | $0.10/hr | $0.10/hr |
 
 ### 50K Cloud Native Hybrid on EKS
@@ -382,7 +382,7 @@ If EKS node autoscaling is employed, it is likely that your average loading will
 | **<u>Gitaly Cluster</u>** [Details](gitlab_sre_for_aws.md#gitaly-sre-considerations) |                                                              |                                                           |                                 |                                                              |
 | Gitaly Instances (in ASG)                                    | 64 vCPU, 240GB x [3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections) | **m5.16xlarge** x 3 nodes<br />(64 vCPU, 256 GB each)     | $3.07 x 3 = $9.21/hr            | [Gitaly & Praefect Must Have an Uneven Node Count for HA](gitlab_sre_for_aws.md#gitaly-and-praefect-elections) |
 | Praefect (Instances in ASG with load balancer)               | 4 vCPU, 3.6 GB x [3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections) | **c5.xlarge** x 3 nodes<br />(4 vCPU, 8 GB each)          | $0.17 x 3 = $0.51/hr            | [Gitaly & Praefect Must Have an Uneven Node Count for HA](gitlab_sre_for_aws.md#gitaly-and-praefect-elections) |
-| Praefect PostgreSQL(1) (AWS RDS)                             | 2 vCPU, 1.8 GB x [3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections) | N/A Reuses GitLab PostgreSQL                              | $0                              |                                                              |
+| Praefect PostgreSQL(1) (AWS RDS)                             | 2 vCPU, 1.8 GB x [3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections) | Not applicable; reuses GitLab PostgreSQL                              | $0                              |                                                              |
 | Internal Load Balancing Node                                 | 2 vCPU, 1.8 GB                                               | AWS ELB                                                   | $0.10/hr                        | $0.10/hr                                                     |
 
 ## Helpful Resources
diff --git a/doc/install/aws/gitlab_sre_for_aws.md b/doc/install/aws/gitlab_sre_for_aws.md
index 2114ed51128..cb7703835fa 100644
--- a/doc/install/aws/gitlab_sre_for_aws.md
+++ b/doc/install/aws/gitlab_sre_for_aws.md
@@ -1,5 +1,5 @@
 ---
-stage: Enablement
+stage: Systems
 group: Distribution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 comments: false
diff --git a/doc/install/aws/index.md b/doc/install/aws/index.md
index ee7279d72cd..f54bc979152 100644
--- a/doc/install/aws/index.md
+++ b/doc/install/aws/index.md
@@ -1,5 +1,5 @@
 ---
-stage: Enablement
+stage: Systems
 group: Distribution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 comments: false
diff --git a/doc/install/aws/manual_install_aws.md b/doc/install/aws/manual_install_aws.md
index 8b827d05b57..25973220170 100644
--- a/doc/install/aws/manual_install_aws.md
+++ b/doc/install/aws/manual_install_aws.md
@@ -1,5 +1,5 @@
 ---
-stage: Enablement
+stage: Systems
 group: Distribution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
@@ -83,8 +83,8 @@ As we'll be using [Amazon S3 object storage](#amazon-s3-object-storage), our EC2
 
 ### Create an IAM Policy
 
-1. Navigate to the IAM dashboard and click on **Policies** in the left menu.
-1. Click **Create policy**, select the `JSON` tab, and add a policy. We want to [follow security best practices and grant _least privilege_](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege), giving our role only the permissions needed to perform the required actions.
+1. Navigate to the IAM dashboard and select **Policies** in the left menu.
+1. Select **Create policy**, select the `JSON` tab, and add a policy. We want to [follow security best practices and grant _least privilege_](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege), giving our role only the permissions needed to perform the required actions.
    1. Assuming you prefix the S3 bucket names with `gl-` as shown in the diagram, add the following policy:
 
    ```json
@@ -114,17 +114,17 @@ As we'll be using [Amazon S3 object storage](#amazon-s3-object-storage), our EC2
    }
    ```
 
-1. Click **Review policy**, give your policy a name (we'll use `gl-s3-policy`), and click **Create policy**.
+1. Select **Review policy**, give your policy a name (we'll use `gl-s3-policy`), and select **Create policy**.
 
 ### Create an IAM Role
 
-1. Still on the IAM dashboard, click on **Roles** in the left menu, and
-   click **Create role**.
-1. Create a new role by selecting **AWS service > EC2**, then click
+1. Still on the IAM dashboard, select **Roles** in the left menu, and
+   select **Create role**.
+1. Create a new role by selecting **AWS service > EC2**, then select
    **Next: Permissions**.
-1. In the policy filter, search for the `gl-s3-policy` we created above, select it, and click **Tags**.
-1. Add tags if needed and click **Review**.
-1. Give the role a name (we'll use `GitLabS3Access`) and click **Create Role**.
+1. In the policy filter, search for the `gl-s3-policy` we created above, select it, and select **Tags**.
+1. Add tags if needed and select **Review**.
+1. Give the role a name (we'll use `GitLabS3Access`) and select **Create Role**.
 
 We'll use this role when we [create a launch configuration](#create-a-launch-configuration) later on.
 
@@ -140,14 +140,14 @@ Internet Gateway.
 We'll now create a VPC, a virtual networking environment that you'll control:
 
 1. Sign in to [Amazon Web Services](https://console.aws.amazon.com/vpc/home).
-1. Select **Your VPCs** from the left menu and then click **Create VPC**.
+1. Select **Your VPCs** from the left menu and then select **Create VPC**.
    At the "Name tag" enter `gitlab-vpc` and at the "IPv4 CIDR block" enter
    `10.0.0.0/16`. If you don't require dedicated hardware, you can leave
-   "Tenancy" as default. Click **Yes, Create** when ready.
+   "Tenancy" as default. Select **Yes, Create** when ready.
 
    ![Create VPC](img/create_vpc.png)
 
-1. Select the VPC, click **Actions**, click **Edit DNS resolution**, and enable DNS resolution. Hit **Save** when done.
+1. Select the VPC, select **Actions**, select **Edit DNS resolution**, and enable DNS resolution. Hit **Save** when done.
 
 ### Subnets
 
@@ -160,7 +160,7 @@ We will create private and public subnets to match load balancers and
 RDS instances as well:
 
 1. Select **Subnets** from the left menu.
-1. Click **Create subnet**. Give it a descriptive name tag based on the IP,
+1. Select **Create subnet**. Give it a descriptive name tag based on the IP,
    for example `gitlab-public-10.0.0.0`, select the VPC we created previously, select an availability zone (we'll use `us-west-2a`),
    and at the IPv4 CIDR block let's give it a 24 subnet `10.0.0.0/24`:
 
@@ -176,7 +176,7 @@ RDS instances as well:
    | `gitlab-private-10.0.3.0` | private | `us-west-2b`      | `10.0.3.0/24` |
 
 1. Once all the subnets are created, enable **Auto-assign IPv4** for the two public subnets:
-   1. Select each public subnet in turn, click **Actions**, and click **Modify auto-assign IP settings**. Enable the option and save.
+   1. Select each public subnet in turn, select **Actions**, and select **Modify auto-assign IP settings**. Enable the option and save.
 
 ### Internet Gateway
 
@@ -184,8 +184,8 @@ Now, still on the same dashboard, go to Internet Gateways and
 create a new one:
 
 1. Select **Internet Gateways** from the left menu.
-1. Click **Create internet gateway**, give it the name `gitlab-gateway` and
-   click **Create**.
+1. Select **Create internet gateway**, give it the name `gitlab-gateway` and
+   select **Create**.
 1. Select it from the table, and then under the **Actions** dropdown choose
    "Attach to VPC".
 
@@ -197,12 +197,12 @@ create a new one:
 
 Instances deployed in our private subnets need to connect to the internet for updates, but should not be reachable from the public internet. To achieve this, we'll make use of [NAT Gateways](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) deployed in each of our public subnets:
 
-1. Navigate to the VPC dashboard and click on **NAT Gateways** in the left menu bar.
-1. Click **Create NAT Gateway** and complete the following:
+1. Navigate to the VPC dashboard and select **NAT Gateways** in the left menu bar.
+1. Select **Create NAT Gateway** and complete the following:
    1. **Subnet**: Select `gitlab-public-10.0.0.0` from the dropdown.
-   1. **Elastic IP Allocation ID**: Enter an existing Elastic IP or click **Allocate Elastic IP address** to allocate a new IP to your NAT gateway.
+   1. **Elastic IP Allocation ID**: Enter an existing Elastic IP or select **Allocate Elastic IP address** to allocate a new IP to your NAT gateway.
    1. Add tags if needed.
-   1. Click **Create NAT Gateway**.
+   1. Select **Create NAT Gateway**.
 
 Create a second NAT gateway but this time place it in the second public subnet, `gitlab-public-10.0.2.0`.
 
@@ -215,23 +215,23 @@ We need to create a route table for our public subnets to reach the internet via
 On the VPC dashboard:
 
 1. Select **Route Tables** from the left menu.
-1. Click **Create Route Table**.
+1. Select **Create Route Table**.
 1. At the "Name tag" enter `gitlab-public` and choose `gitlab-vpc` under "VPC".
-1. Click **Create**.
+1. Select **Create**.
 
 We now need to add our internet gateway as a new target and have
 it receive traffic from any destination.
 
 1. Select **Route Tables** from the left menu and select the `gitlab-public`
    route to show the options at the bottom.
-1. Select the **Routes** tab, click **Edit routes > Add route** and set `0.0.0.0/0`
+1. Select the **Routes** tab, select **Edit routes > Add route** and set `0.0.0.0/0`
    as the destination. In the target column, select the `gitlab-gateway` we created previously.
    Hit **Save routes** once done.
 
 Next, we must associate the **public** subnets to the route table:
 
-1. Select the **Subnet Associations** tab and click **Edit subnet associations**.
-1. Check only the public subnets and click **Save**.
+1. Select the **Subnet Associations** tab and select **Edit subnet associations**.
+1. Check only the public subnets and select **Save**.
 
 #### Private Route Tables
 
@@ -251,7 +251,7 @@ We'll create a load balancer to evenly distribute inbound traffic on ports `80`
 
 On the EC2 dashboard, look for Load Balancer in the left navigation bar:
 
-1. Click the **Create Load Balancer** button.
+1. Select **Create Load Balancer**.
    1. Choose the **Classic Load Balancer**.
    1. Give it a name (we'll use `gitlab-loadbalancer`) and for the **Create LB Inside** option, select `gitlab-vpc` from the dropdown menu.
    1. In the **Listeners** section, set the following listeners:
@@ -259,20 +259,20 @@ On the EC2 dashboard, look for Load Balancer in the left navigation bar:
         - TCP port 22 for both load balancer and instance protocols and ports
         - HTTPS port 443 for load balancer protocol and ports, forwarding to HTTP port 80 on the instance (we will configure GitLab to listen on port 80 [later in the guide](#add-support-for-proxied-ssl))
    1. In the **Select Subnets** section, select both public subnets from the list so that the load balancer can route traffic to both availability zones.
-1. We'll add a security group for our load balancer to act as a firewall to control what traffic is allowed through. Click **Assign Security Groups** and select **Create a new security group**, give it a name
+1. We'll add a security group for our load balancer to act as a firewall to control what traffic is allowed through. Select **Assign Security Groups** and select **Create a new security group**, give it a name
    (we'll use `gitlab-loadbalancer-sec-group`) and description, and allow both HTTP and HTTPS traffic
    from anywhere (`0.0.0.0/0, ::/0`). Also allow SSH traffic, select a custom source, and add a single trusted IP address or an IP address range in CIDR notation. This will allow users to perform Git actions over SSH.
-1. Click **Configure Security Settings** and set the following:
+1. Select **Configure Security Settings** and set the following:
    1. Select an SSL/TLS certificate from ACM or upload a certificate to IAM.
    1. Under **Select a Cipher**, pick a predefined security policy from the dropdown. You can see a breakdown of [Predefined SSL Security Policies for Classic Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html) in the AWS docs. Check the GitLab codebase for a list of [supported SSL ciphers and protocols](https://gitlab.com/gitlab-org/gitlab/-/blob/9ee7ad433269b37251e0dd5b5e00a0f00d8126b4/lib/support/nginx/gitlab-ssl#L97-99).
-1. Click **Configure Health Check** and set up a health check for your EC2 instances.
+1. Select **Configure Health Check** and set up a health check for your EC2 instances.
    1. For **Ping Protocol**, select HTTP.
    1. For **Ping Port**, enter 80.
-   1. For **Ping Path** - we recommend that you [use the Readiness check endpoint](../../administration/load_balancer.md#readiness-check). You'll need to add [the VPC IP Address Range (CIDR)](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-groups.html#elb-vpc-nacl) to the [IP Allowlist](../../administration/monitoring/ip_whitelist.md) for the [Health Check endpoints](../../user/admin_area/monitoring/health_check.md)
+   1. For **Ping Path** - we recommend that you [use the Readiness check endpoint](../../administration/load_balancer.md#readiness-check). You'll need to add [the VPC IP Address Range (CIDR)](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-groups.html#elb-vpc-nacl) to the [IP allowlist](../../administration/monitoring/ip_whitelist.md) for the [Health Check endpoints](../../user/admin_area/monitoring/health_check.md)
    1. Keep the default **Advanced Details** or adjust them according to your needs.
-1. Click **Add EC2 Instances** - don't add anything as we will create an Auto Scaling Group later to manage instances for us.
-1. Click **Add Tags** and add any tags you need.
-1. Click **Review and Create**, review all your settings, and click **Create** if you're happy.
+1. Select **Add EC2 Instances** - don't add anything as we will create an Auto Scaling Group later to manage instances for us.
+1. Select **Add Tags** and add any tags you need.
+1. Select **Review and Create**, review all your settings, and select **Create** if you're happy.
 
 After the Load Balancer is up and running, you can revisit your Security
 Groups to refine the access only through the ELB and any other requirements
@@ -280,19 +280,19 @@ you might have.
 
 ### Configure DNS for Load Balancer
 
-On the Route 53 dashboard, click **Hosted zones** in the left navigation bar:
+On the Route 53 dashboard, select **Hosted zones** in the left navigation bar:
 
-1. Select an existing hosted zone or, if you do not already have one for your domain, click **Create Hosted Zone**, enter your domain name, and click **Create**.
-1. Click **Create Record Set** and provide the following values:
+1. Select an existing hosted zone or, if you do not already have one for your domain, select **Create Hosted Zone**, enter your domain name, and select **Create**.
+1. Select **Create Record Set** and provide the following values:
     1. **Name:** Use the domain name (the default value) or enter a subdomain.
     1. **Type:** Select **A - IPv4 address**.
     1. **Alias:** Defaults to **No**. Select **Yes**.
     1. **Alias Target:** Find the **ELB Classic Load Balancers** section and select the classic load balancer we created earlier.
     1. **Routing Policy:** We'll use **Simple** but you can choose a different policy based on your use case.
     1. **Evaluate Target Health:** We'll set this to **No** but you can choose to have the load balancer route traffic based on target health.
-    1. Click **Create**.
+    1. Select **Create**.
 1. If you registered your domain through Route 53, you're done. If you used a different domain registrar, you need to update your DNS records with your domain registrar. You'll need to:
-   1. Click on **Hosted zones** and select the domain you added above.
+   1. Select **Hosted zones** and select the domain you added above.
    1. You'll see a list of `NS` records. From your domain registrar's administrator panel, add each of these as `NS` records to your domain's DNS records. These steps may vary between domain registrars. If you're stuck, Google **"name of your registrar" add DNS records** and you should find a help article specific to your domain registrar.
 
 The steps for doing this vary depending on which registrar you use and is beyond the scope of this guide.
@@ -308,22 +308,22 @@ create the actual RDS instance.
 We need a security group for our database that will allow inbound traffic from the instances we'll deploy in our `gitlab-loadbalancer-sec-group` later on:
 
 1. From the EC2 dashboard, select **Security Groups** from the left menu bar.
-1. Click **Create security group**.
+1. Select **Create security group**.
 1. Give it a name (we'll use `gitlab-rds-sec-group`), a description, and select the `gitlab-vpc` from the **VPC** dropdown.
-1. In the **Inbound rules** section, click **Add rule** and set the following:
+1. In the **Inbound rules** section, select **Add rule** and set the following:
    1. **Type:** search for and select the **PostgreSQL** rule.
    1. **Source type:** set as "Custom".
    1. **Source:** select the `gitlab-loadbalancer-sec-group` we created earlier.
-1. When done, click **Create security group**.
+1. When done, select **Create security group**.
 
 ### RDS Subnet Group
 
 1. Navigate to the RDS dashboard and select **Subnet Groups** from the left menu.
-1. Click on **Create DB Subnet Group**.
+1. Select **Create DB Subnet Group**.
 1. Under **Subnet group details**, enter a name (we'll use `gitlab-rds-group`), a description, and choose the `gitlab-vpc` from the VPC dropdown.
 1. From the **Availability Zones** dropdown, select the Availability Zones that include the subnets you've configured. In our case, we'll add `eu-west-2a` and `eu-west-2b`.
 1. From the **Subnets** dropdown, select the two private subnets (`10.0.1.0/24` and `10.0.3.0/24`) as we defined them in the [subnets section](#subnets).
-1. Click **Create** when ready.
+1. Select **Create** when ready.
 
 ### Create the database
 
@@ -332,7 +332,7 @@ Avoid using burstable instances (t class instances) for the database as this cou
 
 Now, it's time to create the database:
 
-1. Navigate to the RDS dashboard, select **Databases** from the left menu, and click **Create database**.
+1. Navigate to the RDS dashboard, select **Databases** from the left menu, and select **Create database**.
 1. Select **Standard Create** for the database creation method.
 1. Select **PostgreSQL** as the database engine and select the minimum PostgreSQL version as defined for your GitLab version in our [database requirements](../../install/requirements.md#postgresql-requirements).
 1. Since this is a production server, let's choose **Production** from the **Templates** section.
@@ -355,7 +355,7 @@ Now, it's time to create the database:
    1. Configure your preferred backup settings.
    1. The only other change we'll make here is to disable auto minor version updates under **Maintenance**.
    1. Leave all the other settings as is or tweak according to your needs.
-   1. Once you're happy, click **Create database**.
+   1. Once you're happy, select **Create database**.
 
 Now that the database is created, let's move on to setting up Redis with ElastiCache.
 
@@ -368,24 +368,24 @@ persistence and is used to store session data, temporary cache information, and
 
 1. Navigate to the EC2 dashboard.
 1. Select **Security Groups** from the left menu.
-1. Click **Create security group** and fill in the details. Give it a name (we'll use `gitlab-redis-sec-group`),
+1. Select **Create security group** and fill in the details. Give it a name (we'll use `gitlab-redis-sec-group`),
    add a description, and choose the VPC we created previously
-1. In the **Inbound rules** section, click **Add rule** and add a **Custom TCP** rule, set port `6379`, and set the "Custom" source as the `gitlab-loadbalancer-sec-group` we created earlier.
-1. When done, click **Create security group**.
+1. In the **Inbound rules** section, select **Add rule** and add a **Custom TCP** rule, set port `6379`, and set the "Custom" source as the `gitlab-loadbalancer-sec-group` we created earlier.
+1. When done, select **Create security group**.
 
 ### Redis Subnet Group
 
 1. Navigate to the ElastiCache dashboard from your AWS console.
 1. Go to **Subnet Groups** in the left menu, and create a new subnet group (we'll name ours `gitlab-redis-group`).
-   Make sure to select our VPC and its [private subnets](#subnets). Click
-   **Create** when ready.
+   Make sure to select our VPC and its [private subnets](#subnets).
+1. Select **Create** when ready.
 
    ![ElastiCache subnet](img/ec_subnet.png)
 
 ### Create the Redis Cluster
 
 1. Navigate back to the ElastiCache dashboard.
-1. Select **Redis** on the left menu and click **Create** to create a new
+1. Select **Redis** on the left menu and select **Create** to create a new
    Redis cluster. Do not enable **Cluster Mode** as it is [not supported](../../administration/redis/replication_and_failover_external.md#requirements). Even without cluster mode on, you still get the
    chance to deploy Redis in multiple availability zones.
 1. In the settings section:
@@ -404,7 +404,7 @@ persistence and is used to store session data, temporary cache information, and
 1. In the security settings, edit the security groups and choose the
    `gitlab-redis-sec-group` we had previously created.
 1. Leave the rest of the settings to their default values or edit to your liking.
-1. When done, click **Create**.
+1. When done, select **Create**.
 
 ## Setting up Bastion Hosts
 
@@ -418,29 +418,29 @@ If you do not want to maintain bastion hosts, you can set up [AWS Systems Manage
 
 ### Create Bastion Host A
 
-1. Navigate to the EC2 Dashboard and click on **Launch instance**.
+1. Navigate to the EC2 Dashboard and select **Launch instance**.
 1. Select the **Ubuntu Server 18.04 LTS (HVM)** AMI.
 1. Choose an instance type. We'll use a `t2.micro` as we'll only use the bastion host to SSH into our other instances.
-1. Click **Configure Instance Details**.
+1. Select **Configure Instance Details**.
    1. Under **Network**, select the `gitlab-vpc` from the dropdown menu.
    1. Under **Subnet**, select the public subnet we created earlier (`gitlab-public-10.0.0.0`).
    1. Double check that under **Auto-assign Public IP** you have **Use subnet setting (Enable)** selected.
-   1. Leave everything else as default and click **Add Storage**.
+   1. Leave everything else as default and select **Add Storage**.
 1. For storage, we'll leave everything as default and only add an 8GB root volume. We won't store anything on this instance.
-1. Click **Add Tags** and on the next screen click **Add Tag**.
+1. Select **Add Tags** and on the next screen select **Add Tag**.
    1. We'll only set `Key: Name` and `Value: Bastion Host A`.
-1. Click **Configure Security Group**.
+1. Select **Configure Security Group**.
    1. Select **Create a new security group**, enter a **Security group name** (we'll use `bastion-sec-group`), and add a description.
    1. We'll enable SSH access from anywhere (`0.0.0.0/0`). If you want stricter security, specify a single IP address or an IP address range in CIDR notation.
-   1. Click **Review and Launch**
-1. Review all your settings and, if you're happy, click **Launch**.
-1. Acknowledge that you have access to an existing key pair or create a new one. Click **Launch Instance**.
+   1. Select **Review and Launch**
+1. Review all your settings and, if you're happy, select **Launch**.
+1. Acknowledge that you have access to an existing key pair or create a new one. Select **Launch Instance**.
 
 Confirm that you can SSH into the instance:
 
-1. On the EC2 Dashboard, click on **Instances** in the left menu.
+1. On the EC2 Dashboard, select **Instances** in the left menu.
 1. Select **Bastion Host A** from your list of instances.
-1. Click **Connect** and follow the connection instructions.
+1. Select **Connect** and follow the connection instructions.
 1. If you are able to connect successfully, let's move on to setting up our second bastion host for redundancy.
 
 ### Create Bastion Host B
@@ -466,16 +466,16 @@ From the EC2 dashboard:
 
 1. Use the section below titled "[Find official GitLab-created AMI IDs on AWS](#find-official-gitlab-created-ami-ids-on-aws)" to find the correct AMI to launch.
 1. After clicking **Launch** on the desired AMI, select an instance type based on your workload. Consult the [hardware requirements](../../install/requirements.md#hardware-requirements) to choose one that fits your needs (at least `c5.xlarge`, which is sufficient to accommodate 100 users).
-1. Click **Configure Instance Details**:
+1. Select **Configure Instance Details**:
    1. In the **Network** dropdown, select `gitlab-vpc`, the VPC we created earlier.
    1. In the **Subnet** dropdown, select `gitlab-private-10.0.1.0` from the list of subnets we created earlier.
    1. Double check that **Auto-assign Public IP** is set to `Use subnet setting (Disable)`.
-   1. Click **Add Storage**.
+   1. Select **Add Storage**.
    1. The root volume is 8GiB by default and should be enough given that we won't store any data there.
-1. Click **Add Tags** and add any tags you may need. In our case, we'll only set `Key: Name` and `Value: GitLab`.
-1. Click **Configure Security Group**. Check **Select an existing security group** and select the `gitlab-loadbalancer-sec-group` we created earlier.
-1. Click **Review and launch** followed by **Launch** if you're happy with your settings.
-1. Finally, acknowledge that you have access to the selected private key file or create a new one. Click **Launch Instances**.
+1. Select **Add Tags** and add any tags you may need. In our case, we'll only set `Key: Name` and `Value: GitLab`.
+1. Select **Configure Security Group**. Check **Select an existing security group** and select the `gitlab-loadbalancer-sec-group` we created earlier.
+1. Select **Review and launch** followed by **Launch** if you're happy with your settings.
+1. Finally, acknowledge that you have access to the selected private key file or create a new one. Select **Launch Instances**.
 
 ### Add custom configuration
 
@@ -501,7 +501,7 @@ Since we're adding our SSL certificate at the load balancer, we do not need the
 
 From your GitLab instance, connect to the RDS instance to verify access and to install the required `pg_trgm` and `btree_gist` extensions.
 
-To find the host or endpoint, navigate to **Amazon RDS > Databases** and click on the database you created earlier. Look for the endpoint under the **Connectivity & security** tab.
+To find the host or endpoint, navigate to **Amazon RDS > Databases** and select the database you created earlier. Look for the endpoint under the **Connectivity & security** tab.
 
 Do not to include the colon and port number:
 
@@ -580,23 +580,23 @@ It should be enabled and configured on a separate EC2 instance in one of the
 
 Let's create an EC2 instance where we'll install Gitaly:
 
-1. From the EC2 dashboard, click **Launch instance**.
+1. From the EC2 dashboard, select **Launch instance**.
 1. Choose an AMI. In this example, we'll select the **Ubuntu Server 18.04 LTS (HVM), SSD Volume Type**.
 1. Choose an instance type. We'll pick a `c5.xlarge`.
-1. Click **Configure Instance Details**.
+1. Select **Configure Instance Details**.
    1. In the **Network** dropdown, select `gitlab-vpc`, the VPC we created earlier.
    1. In the **Subnet** dropdown, select `gitlab-private-10.0.1.0` from the list of subnets we created earlier.
    1. Double check that **Auto-assign Public IP** is set to `Use subnet setting (Disable)`.
-   1. Click **Add Storage**.
+   1. Select **Add Storage**.
 1. Increase the Root volume size to `20 GiB` and change the **Volume Type** to `Provisioned IOPS SSD (io1)`. (This is an arbitrary size. Create a volume big enough for your repository storage requirements.)
    1. For **IOPS** set `1000` (20 GiB x 50 IOPS). You can provision up to 50 IOPS per GiB. If you select a larger volume, increase the IOPS accordingly. Workloads where many small files are written in a serialized manner, like `git`, requires performant storage, hence the choice of `Provisioned IOPS SSD (io1)`.
-1. Click on **Add Tags** and add your tags. In our case, we'll only set `Key: Name` and `Value: Gitaly`.
-1. Click on **Configure Security Group** and let's **Create a new security group**.
+1. Select **Add Tags** and add your tags. In our case, we'll only set `Key: Name` and `Value: Gitaly`.
+1. Select **Configure Security Group** and let's **Create a new security group**.
    1. Give your security group a name and description. We'll use `gitlab-gitaly-sec-group` for both.
    1. Create a **Custom TCP** rule and add port `8075` to the **Port Range**. For the **Source**, select the `gitlab-loadbalancer-sec-group`.
    1. Also add an inbound rule for SSH from the `bastion-sec-group` so that we can connect using [SSH Agent Forwarding](#use-ssh-agent-forwarding) from the Bastion hosts.
-1. Click **Review and launch** followed by **Launch** if you're happy with your settings.
-1. Finally, acknowledge that you have access to the selected private key file or create a new one. Click **Launch Instances**.
+1. Select **Review and launch** followed by **Launch** if you're happy with your settings.
+1. Finally, acknowledge that you have access to the selected private key file or create a new one. Select **Launch Instances**.
 
 NOTE:
 Instead of storing configuration _and_ repository data on the root volume, you can also choose to add an additional EBS volume for repository storage. Follow the same guidance as above. See the [Amazon EBS pricing](https://aws.amazon.com/ebs/pricing/). We do not recommend using EFS as it may negatively impact the performance of GitLab. You can review the [relevant documentation](../../administration/nfs.md#avoid-using-cloud-based-file-systems) for more details.
@@ -679,9 +679,9 @@ When our [auto scaling group](#create-an-auto-scaling-group) spins up new instan
 On the EC2 dashboard:
 
 1. Select the `GitLab` instance we [created earlier](#install-gitlab).
-1. Click on **Actions**, scroll down to **Image** and click **Create Image**.
+1. Select **Actions**, scroll down to **Image** and select **Create Image**.
 1. Give your image a name and description (we'll use `GitLab-Source` for both).
-1. Leave everything else as default and click **Create Image**
+1. Leave everything else as default and select **Create Image**
 
 Now we have a custom AMI that we'll use to create our launch configuration the next step.
 
@@ -691,21 +691,21 @@ Now we have a custom AMI that we'll use to create our launch configuration the n
 
 From the EC2 dashboard:
 
-1. Select **Launch Configurations** from the left menu and click **Create launch configuration**.
+1. Select **Launch Configurations** from the left menu and select **Create launch configuration**.
 1. Select **My AMIs** from the left menu and select the `GitLab` custom AMI we created above.
-1. Select an instance type best suited for your needs (at least a `c5.xlarge`) and click **Configure details**.
+1. Select an instance type best suited for your needs (at least a `c5.xlarge`) and select **Configure details**.
 1. Enter a name for your launch configuration (we'll use `gitlab-ha-launch-config`).
 1. **Do not** check **Request Spot Instance**.
 1. From the **IAM Role** dropdown, pick the `GitLabAdmin` instance role we [created earlier](#create-an-iam-ec2-instance-role-and-profile).
-1. Leave the rest as defaults and click **Add Storage**.
-1. The root volume is 8GiB by default and should be enough given that we won't store any data there. Click **Configure Security Group**.
+1. Leave the rest as defaults and select **Add Storage**.
+1. The root volume is 8GiB by default and should be enough given that we won't store any data there. Select **Configure Security Group**.
 1. Check **Select and existing security group** and select the `gitlab-loadbalancer-sec-group` we created earlier.
-1. Click **Review**, review your changes, and click **Create launch configuration**.
-1. Acknowledge that you have access to the private key or create a new one. Click **Create launch configuration**.
+1. Select **Review**, review your changes, and select **Create launch configuration**.
+1. Acknowledge that you have access to the private key or create a new one. Select **Create launch configuration**.
 
 ### Create an auto scaling group
 
-1. As soon as the launch configuration is created, you'll see an option to **Create an Auto Scaling group using this launch configuration**. Click that to start creating the auto scaling group.
+1. After the launch configuration is created, select **Create an Auto Scaling group using this launch configuration** to start creating the auto scaling group.
 1. Enter a **Group name** (we'll use `gitlab-auto-scaling-group`).
 1. For **Group size**, enter the number of instances you want to start with (we'll enter `2`).
 1. Select the `gitlab-vpc` from the **Network** dropdown.
@@ -713,7 +713,7 @@ From the EC2 dashboard:
 1. Expand the **Advanced Details** section and check the **Receive traffic from one or more load balancers** option.
 1. From the **Classic Load Balancers** dropdown, select the load balancer we created earlier.
 1. For **Health Check Type**, select **ELB**.
-1. We'll leave our **Health Check Grace Period** as the default `300` seconds. Click **Configure scaling policies**.
+1. We'll leave our **Health Check Grace Period** as the default `300` seconds. Select **Configure scaling policies**.
 1. Check **Use scaling policies to adjust the capacity of this group**.
 1. For this group we'll scale between 2 and 4 instances where one instance will be added if CPU
 utilization is greater than 60% and one instance is removed if it falls
diff --git a/doc/install/azure/index.md b/doc/install/azure/index.md
index 780dfe17dac..0d621217dd8 100644
--- a/doc/install/azure/index.md
+++ b/doc/install/azure/index.md
@@ -1,5 +1,5 @@
 ---
-stage: Enablement
+stage: Systems
 group: Distribution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 description: 'Learn how to spin up a pre-configured GitLab VM on Microsoft Azure.'
@@ -15,7 +15,7 @@ Enterprise Edition in a single Virtual Machine (VM).
 
 ## Prerequisite
 
-You'll need an account on Azure. Use of the following methods to obtain an account:
+You need an account on Azure. Use of the following methods to obtain an account:
 
 - If you or your company already have an account with a subscription, use that account.
   If not, you can [open your own Azure account for free](https://azure.microsoft.com/en-us/free/).
@@ -155,7 +155,7 @@ to assign a descriptive DNS name to the VM:
 1. Enter a descriptive DNS name for your instance in the **DNS name label** field,
    for example `gitlab-prod`. This makes the VM accessible at
    `gitlab-prod.eastus.cloudapp.azure.com`.
-1. Select **Save** for the changes to take effect.
+1. Select **Save**.
 
 Eventually, most users want to use their own domain name. For you to do this, you need to add a DNS `A` record
 with your domain registrar that points to the public IP address of your Azure VM.
diff --git a/doc/install/cloud_native/index.md b/doc/install/cloud_native/index.md
index 45d484b045a..f3265500877 100644
--- a/doc/install/cloud_native/index.md
+++ b/doc/install/cloud_native/index.md
@@ -1,5 +1,5 @@
 ---
-stage: Enablement
+stage: Systems
 group: Distribution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 comments: false
diff --git a/doc/install/digitaloceandocker.md b/doc/install/digitaloceandocker.md
index c0b9b280d92..86ccf194786 100644
--- a/doc/install/digitaloceandocker.md
+++ b/doc/install/digitaloceandocker.md
@@ -1,150 +1,11 @@
 ---
-stage: Enablement
-group: Distribution
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+redirect_to: 'docker.md'
+remove_date: '2022-08-29'
 ---
 
-# Digital Ocean and Docker Machine test environment **(FREE SELF)**
+This document was moved to [another location](docker.md).
 
-This guide is for quickly testing different versions of GitLab and not
-recommended for ease of future upgrades or keeping the data you create.
-
-## Initial setup
-
-This guide configures a Digital Ocean droplet and sets up Docker
-locally on either macOS or Linux.
-
-### On macOS
-
-#### Install Docker Desktop
-
-- <https://www.docker.com/products/docker-desktop>
-
-### On Linux
-
-#### Install Docker Engine
-
-- <https://docs.docker.com/engine/installation/linux/>
-
-#### Install Docker Machine
-
-- <https://docs.docker.com/machine/install-machine/>
-
-NOTE:
-The rest of the steps are identical for macOS and Linux.
-
-## Create new Docker host
-
-1. Login to Digital Ocean.
-1. Generate a new API token at <https://cloud.digitalocean.com/settings/api/tokens>.
-
-   This command creates a new Digital Ocean droplet called `gitlab-test-env-do` that acts as a Docker host.
-
-   NOTE:
-   4GB is the minimum requirement for a Docker host that runs more than one GitLab instance.
-
-   - RAM: 4GB
-   - Name: `gitlab-test-env-do`
-   - Driver: `digitalocean`
-
-1. Set the DO token:
-
-   ```shell
-   export DOTOKEN=<your generated token>
-   ```
-
-1. Create the machine:
-
-   ```shell
-   docker-machine create \
-     --driver digitalocean \
-     --digitalocean-access-token=$DOTOKEN \
-     --digitalocean-size "4gb" \
-       gitlab-test-env-do
-   ```
-
-Resource: <https://docs.docker.com/machine/drivers/digital-ocean/>.
-
-## Creating GitLab test instance
-
-### Connect your shell to the new machine
-
-This example creates a GitLab EE 8.10.8 instance.
-
-First connect the Docker client to the Docker host you created previously.
-
-```shell
-eval "$(docker-machine env gitlab-test-env-do)"
-```
-
-You can add this to your `~/.bash_profile` file to ensure the `docker` client uses the `gitlab-test-env-do` Docker host
-
-### Create new GitLab container
-
-- HTTP port: `8888`
-- SSH port: `2222`
-  - Set `gitlab_shell_ssh_port` using `--env GITLAB_OMNIBUS_CONFIG`
-- Hostname: IP of Docker host
-- Container name: `gitlab-test-8.10`
-- GitLab version: **EE** `8.10.8-ee.0`
-
-#### Set up container settings
-
-```shell
-export SSH_PORT=2222
-export HTTP_PORT=8888
-export VERSION=8.10.8-ee.0
-export NAME=gitlab-test-8.10
-```
-
-#### Create container
-
-```shell
-docker run --detach \
---env GITLAB_OMNIBUS_CONFIG="external_url 'http://$(docker-machine ip gitlab-test-env-do):$HTTP_PORT'; gitlab_rails['gitlab_shell_ssh_port'] = $SSH_PORT;" \
---hostname $(docker-machine ip gitlab-test-env-do) \
--p $HTTP_PORT:$HTTP_PORT -p $SSH_PORT:22 \
---name $NAME \
-gitlab/gitlab-ee:$VERSION
-```
-
-### Connect to the GitLab container
-
-#### Retrieve the Docker host IP
-
-```shell
-docker-machine ip gitlab-test-env-do
-# example output: 192.168.151.134
-```
-
-Browse to: `http://192.168.151.134:8888/`.
-
-#### Execute interactive shell/edit configuration
-
-```shell
-docker exec -it $NAME /bin/bash
-```
-
-```shell
-# example commands
-root@192:/# vi /etc/gitlab/gitlab.rb
-root@192:/# gitlab-ctl reconfigure
-```
-
-### Resources
-
-- <https://docs.gitlab.com/omnibus/docker/>.
-- <https://docs.docker.com/machine/get-started/>.
-- <https://docs.docker.com/machine/reference/ip/>.
-
-<!-- ## Troubleshooting
-
-Include any troubleshooting steps that you can foresee. If you know beforehand what issues
-one might have when setting this up, or when something is changed, or on upgrading, it's
-important to describe those, too. Think of things that may go wrong and include them here.
-This is important to minimize requests for support, and to avoid doc comments with
-questions that you know someone might ask.
-
-Each scenario can be a third-level heading, e.g. `### Getting error message X`.
-If you have none to add when creating a doc, leave this section in place
-but commented out to help encourage others to add to it in the future. -->
+<!-- This redirect file can be deleted after <2022-08-29>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/install/docker.md b/doc/install/docker.md
index d5ca2c2e29f..058233520ca 100644
--- a/doc/install/docker.md
+++ b/doc/install/docker.md
@@ -1,5 +1,5 @@
 ---
-stage: Enablement
+stage: Systems
 group: Distribution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
@@ -449,14 +449,14 @@ web browser under `<hostIP>:8929` and push using SSH under the port `2289`.
 A `docker-compose.yml` example that uses different ports can be found in the
 [Docker compose](#install-gitlab-using-docker-compose) section.
 
-## Update
+## Upgrade
 
-In most cases, updating GitLab is as easy as downloading the newest Docker
+In most cases, upgrading GitLab is as easy as downloading the newest Docker
 [image tag](#use-tagged-versions-of-gitlab).
 
-### Update GitLab using Docker Engine
+### Upgrade GitLab using Docker Engine
 
-To update GitLab that was [installed using Docker Engine](#install-gitlab-using-docker-engine):
+To upgrade GitLab that was [installed using Docker Engine](#install-gitlab-using-docker-engine):
 
 1. Take a [backup](#back-up-gitlab).
 1. Stop the running container:
@@ -493,17 +493,17 @@ To update GitLab that was [installed using Docker Engine](#install-gitlab-using-
    gitlab/gitlab-ee:latest
    ```
 
-On the first run, GitLab will reconfigure and update itself.
+On the first run, GitLab will reconfigure and upgrade itself.
 
-Refer to the GitLab [Update recommendations](../policy/maintenance.md#upgrade-recommendations)
+Refer to the GitLab [Upgrade recommendations](../policy/maintenance.md#upgrade-recommendations)
 when upgrading between major versions.
 
-### Update GitLab using Docker compose
+### Upgrade GitLab using Docker compose
 
-To update GitLab that was [installed using Docker Compose](#install-gitlab-using-docker-compose):
+To upgrade GitLab that was [installed using Docker Compose](#install-gitlab-using-docker-compose):
 
 1. Take a [backup](#back-up-gitlab).
-1. Download the newest release and update your GitLab instance:
+1. Download the newest release and upgrade your GitLab instance:
 
    ```shell
    docker-compose pull
@@ -517,7 +517,7 @@ To update GitLab that was [installed using Docker Compose](#install-gitlab-using
 
 You can convert an existing Docker-based GitLab Community Edition (CE) container
 to a GitLab [Enterprise Edition](https://about.gitlab.com/pricing/) (EE) container
-using the same approach as [updating the version](#update).
+using the same approach as [upgrading the version](#upgrade).
 
 We recommend you convert from the same version of CE to EE (for example, CE 14.1 to EE 14.1).
 This is not explicitly necessary, and any standard upgrade (for example, CE 14.0 to EE 14.1) should work.
@@ -643,7 +643,7 @@ sudo setfacl -mR default:group:docker:rwx $GITLAB_HOME
 The default group is `docker`. If you changed the group, be sure to update your
 commands.
 
-### /dev/shm mount not having enough space in Docker container
+### `/dev/shm` mount not having enough space in Docker container
 
 GitLab comes with a Prometheus metrics endpoint at `/-/metrics` to expose a
 variety of statistics on the health and performance of GitLab. The files
diff --git a/doc/install/google_cloud_platform/index.md b/doc/install/google_cloud_platform/index.md
index 76c1da74108..b63ab8d4e2b 100644
--- a/doc/install/google_cloud_platform/index.md
+++ b/doc/install/google_cloud_platform/index.md
@@ -1,5 +1,5 @@
 ---
-stage: Enablement
+stage: Systems
 group: Distribution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 description: 'Learn how to install a GitLab instance on Google Cloud Platform.'
@@ -13,7 +13,7 @@ NOTE:
 To deploy production-ready GitLab on
 Google Kubernetes Engine,
 you can follow Google Cloud Platform's
-[Click to Deploy steps](https://github.com/GoogleCloudPlatform/click-to-deploy/blob/master/k8s/gitlab/README.md)
+[`Click to Deploy` steps](https://github.com/GoogleCloudPlatform/click-to-deploy/blob/master/k8s/gitlab/README.md)
 It's an alternative to using a GCP VM, and uses
 the [Cloud native GitLab Helm chart](https://docs.gitlab.com/charts/).
 
diff --git a/doc/install/index.md b/doc/install/index.md
index 52bc9062adc..413c5116c14 100644
--- a/doc/install/index.md
+++ b/doc/install/index.md
@@ -1,5 +1,5 @@
 ---
-stage: Enablement
+stage: Systems
 group: Distribution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 comments: false
@@ -45,7 +45,6 @@ methods, the majority which use the Linux packages:
 | [AWS (HA)](aws/index.md)                                      | Install GitLab on AWS using the community AMIs provided by GitLab. |
 | [Google Cloud Platform (GCP)](google_cloud_platform/index.md) | Install GitLab on a VM in GCP. |
 | [Azure](azure/index.md)                                       | Install GitLab from Azure Marketplace. |
-| [DigitalOcean](https://about.gitlab.com/blog/2016/04/27/getting-started-with-gitlab-and-digitalocean/) | Install GitLab on DigitalOcean. You can also [test GitLab on DigitalOcean using Docker Machine](digitaloceandocker.md). |
 
 ## Next steps
 
diff --git a/doc/install/installation.md b/doc/install/installation.md
index e53ced6c88a..cc2e57aac96 100644
--- a/doc/install/installation.md
+++ b/doc/install/installation.md
@@ -1,5 +1,5 @@
 ---
-stage: Enablement
+stage: Systems
 group: Distribution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
@@ -117,7 +117,7 @@ Install the required packages (needed to compile Ruby and native extensions to R
 ```shell
 sudo apt-get install -y build-essential zlib1g-dev libyaml-dev libssl-dev libgdbm-dev libre2-dev \
   libreadline-dev libncurses5-dev libffi-dev curl openssh-server libxml2-dev libxslt-dev \
-  libcurl4-openssl-dev libicu-dev logrotate rsync python-docutils pkg-config cmake runit-systemd
+  libcurl4-openssl-dev libicu-dev logrotate rsync python3-docutils pkg-config cmake runit-systemd
 ```
 
 If you want to use Kerberos for user authentication, install `libkrb5-dev`
@@ -211,7 +211,7 @@ sudo apt-get install -y libimage-exiftool-perl
 ## 2. Ruby
 
 The Ruby interpreter is required to run GitLab.
-See the [requirements section of this page](#software-requirements) for the minimum
+See the [requirements section](#software-requirements) for the minimum
 Ruby requirements.
 
 The use of Ruby version managers such as [`RVM`](https://rvm.io/), [`rbenv`](https://github.com/rbenv/rbenv) or [`chruby`](https://github.com/postmodern/chruby) with GitLab
@@ -226,9 +226,9 @@ Download Ruby and compile it:
 
 ```shell
 mkdir /tmp/ruby && cd /tmp/ruby
-curl --remote-name --location --progress-bar "https://cache.ruby-lang.org/pub/ruby/2.7/ruby-2.7.5.tar.gz"
-echo '2755b900a21235b443bb16dadd9032f784d4a88f143d852bc5d154f22b8781f1 ruby-2.7.5.tar.gz' | sha256sum -c - && tar xzf ruby-2.7.5.tar.gz
-cd ruby-2.7.5
+curl --remote-name --location --progress-bar "https://cache.ruby-lang.org/pub/ruby/2.7/ruby-2.7.6.tar.gz"
+echo 'e7203b0cc09442ed2c08936d483f8ac140ec1c72e37bb5c401646b7866cb5d10 ruby-2.7.6.tar.gz' | sha256sum -c - && tar xzf ruby-2.7.6.tar.gz
+cd ruby-2.7.6
 
 ./configure --disable-install-rdoc --enable-shared
 make
@@ -246,11 +246,11 @@ page](https://go.dev/dl).
 # Remove former Go installation folder
 sudo rm -rf /usr/local/go
 
-curl --remote-name --location --progress-bar "https://go.dev/dl/go1.16.10.linux-amd64.tar.gz"
-echo '414cd18ce1d193769b9e97d2401ad718755ab47816e13b2a1cde203d263b55cf  go1.16.10.linux-amd64.tar.gz' | shasum -a256 -c - && \
-  sudo tar -C /usr/local -xzf go1.16.10.linux-amd64.tar.gz
+curl --remote-name --location --progress-bar "https://go.dev/dl/go1.17.10.linux-amd64.tar.gz"
+echo '87fc728c9c731e2f74e4a999ef53cf07302d7ed3504b0839027bd9c10edaa3fd  go1.17.10.linux-amd64.tar.gz' | shasum -a256 -c - && \
+  sudo tar -C /usr/local -xzf go1.17.10.linux-amd64.tar.gz
 sudo ln -sf /usr/local/go/bin/{go,gofmt} /usr/local/bin/
-rm go1.16.10.linux-amd64.tar.gz
+rm go1.17.10.linux-amd64.tar.gz
 ```
 
 ## 4. Node
@@ -859,7 +859,7 @@ You can set the Administrator/root password and email by supplying them in envir
 sudo -u git -H bundle exec rake gitlab:setup RAILS_ENV=production GITLAB_ROOT_PASSWORD=yourpassword GITLAB_ROOT_EMAIL=youremail GITLAB_LICENSE_FILE="/path/to/license"
 ```
 
-### Secure secrets.yml
+### Secure `secrets.yml`
 
 The `secrets.yml` file stores encryption keys for sessions and secure variables.
 Backup `secrets.yml` someplace safe, but don't store it in the same place as your database backups.
diff --git a/doc/install/next_steps.md b/doc/install/next_steps.md
index 5d8c61cad44..4defb62d254 100644
--- a/doc/install/next_steps.md
+++ b/doc/install/next_steps.md
@@ -1,5 +1,5 @@
 ---
-stage: Enablement
+stage: Systems
 group: Distribution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
@@ -56,7 +56,7 @@ installation.
 
 ## Cross-repository Code Search
 
-- [Advanced Search](../integration/elasticsearch.md): Leverage [Elasticsearch](https://www.elastic.co/) or [OpenSearch](https://opensearch.org/) for
+- [Advanced Search](../integration/advanced_search/elasticsearch.md): Leverage [Elasticsearch](https://www.elastic.co/) or [OpenSearch](https://opensearch.org/) for
   faster, more advanced code search across your entire GitLab instance.
 
 ## Scaling and replication
diff --git a/doc/install/openshift_and_gitlab/index.md b/doc/install/openshift_and_gitlab/index.md
index 364c27f089f..6bce71e84c1 100644
--- a/doc/install/openshift_and_gitlab/index.md
+++ b/doc/install/openshift_and_gitlab/index.md
@@ -1,5 +1,5 @@
 ---
-stage: Enablement
+stage: Systems
 group: Distribution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
diff --git a/doc/install/relative_url.md b/doc/install/relative_url.md
index 831e33870bd..6c60ee09d78 100644
--- a/doc/install/relative_url.md
+++ b/doc/install/relative_url.md
@@ -1,5 +1,5 @@
 ---
-stage: Enablement
+stage: Systems
 group: Distribution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
diff --git a/doc/install/requirements.md b/doc/install/requirements.md
index 83fce2f00f6..d01860cb24f 100644
--- a/doc/install/requirements.md
+++ b/doc/install/requirements.md
@@ -1,5 +1,5 @@
 ---
-stage: Enablement
+stage: Systems
 group: Distribution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
@@ -13,15 +13,7 @@ the minimum requirements needed to install and use GitLab.
 
 ### Supported Linux distributions
 
-- Ubuntu (18.04/20.04)
-- Debian (9/10/11)
-- AlmaLinux (8)
-- CentOS (7)
-- openSUSE Leap (15.3)
-- SUSE Linux Enterprise Server (12 SP2/12 SP5)
-- Red Hat Enterprise Linux (use the AlmaLinux or CentOS instructions)
-- Scientific Linux (use the CentOS instructions)
-- Oracle Linux (use the CentOS instructions)
+See the [list of supported operating systems](../administration/package_information/supported_os.md#supported-operating-systems).
 
 For the installation options, see [the main installation page](index.md).
 
@@ -121,8 +113,8 @@ the following table) as these were used for development and testing:
 |----------------|----------------------------|
 | 13.0           | 11                         |
 | 14.0           | 12.10                      |
-| 15.0           | 12.0                       |
-| 16.0 (planned) | 13.0                       |
+| 15.0           | 12.10                      |
+| 16.0 (planned) | 13.6                       |
 
 You must also ensure the following extensions are loaded into every
 GitLab database. [Read more about this requirement, and troubleshooting](postgresql_extensions.md).