Docs feedback: Update Installing GitLab HA on Amazon Web Services (AWS)

Installing GitLab HA on Amazon Web Services (AWS

I'm working through this doc to set up a test environment running GitLab HA on AWS. I'm taking notes of areas that can be improved on or updated.

• The diagram is dated. The AWS architecture icons have changed since the diagram was made.
• The architecture shows a "Read-only Gitaly server" running in a separate AZ from the "Primary Gitaly server". I've confirmed with the Gitaly group that a read-only Gitaly server is not possible.
• The AWS UI has changed in some places, for example, for https://docs.gitlab.com/ee/install/aws/index.html#creating-the-database, step 1 to "select Instances from the left menu..." should now read "select Databases.
• The step for Installing the pg_trgm extension for PostgreSQL is not possible at this stage. We have no access to the RDS instance and the GitLab instance doesn’t exist yet. This gets done again later in the doc when we actually have GitLab installed on an EC2 instance.
• For Configuring GitLab to connect with postgres and Redis we need to SSH into the GitLab server and edit gitlab.rb. The problem is, GitLab is deployed in a private subnet and the instance has no public IP address. This means we need a Bastion host (Jump Box to some) in a public subnet from where we can SSH into the server.
  • If we don't want to maintain Bastion hosts (or for a more secure way to connect to instances) investigate AWS Systems Manager Session Manager. It looks awesome but may be beyond the scope of this document.
• Because the GitLab instance(s) is in a private subnet, there's no outbound Internet access. We'll need a NAT Gateway in the public subnet to allow outbound (and return) traffic for things like package updates, etc.
• Look into creating an autoscaling group from an existing instance. We'd spin up a GitLab instance, perform all our config changes and then autoscale based on that already-configured instance.
  • One solution is to create a new AMI from the already-configured "primary" server and then using that to launch new instances in the autoscaling group.
  • Autoscaling is probably not necessary for a basic HA setup. It should perhaps be mentioned as a possibility if a customer wants a scaled architecture.
• The setup has an EBS volume for each GitLab server. You can only attach an EBS volume to one instance at a time. So, using round-robin load balancing, if a user connects to instance A and creates a project they will not have access to that project when the load balancer directs them to instance B on a future visit as the Git data will be on the EBS volume attached to instance A.
  • we need either an NFS server or one Gitaly node where all app nodes write to. Once Gitaly HA is available we'll have a better solution.
• Use a Service Gateway to connect to S3 and keep traffic inside the VPC
  • This is optional and actually beyond the scope of the doc.
• Add security group creation for RDS before creating the database section
  • Remove RDS and Redis Security Group section.
• Link to configuring [Amazon Simple Email System (AWS SES)] (https://docs.gitlab.com/omnibus/settings/smtp.html#amazon-simple-email-system-aws-ses) for email.
  • This optional. By default mail is sent via Sendmail so email works out-of-the-box.

This is what I've come across to far. I will update this list as I go and prepare an MR to submit changes to the doc. I have already started building a new architecture diagram.

/cc @tatkins