Commit 0e63e252 authored by Mike Lewis's avatar Mike Lewis

edits per my review

parent 4f3a9be1
......@@ -6,11 +6,11 @@ AMIs provided with each release.
## Introduction
GitLab on AWS can leverage many of the services that are already
configurable with High Availability (HA). These services have a lot of
flexibility and are able to adopt to most companies, best of all is the
ability to automate both vertical and horizontal scaling.
configurable with GitLab High Availability (HA). These services offer a great deal of
flexibility and can be adapted to the needs of most companies, while enabling the
automation of both vertical and horizontal scaling.
In this guide we'll go through a basic HA setup where we'll start by
In this guide, we'll go through a basic HA setup where we'll start by
configuring our Virtual Private Cloud and subnets to later integrate
services such as RDS for our database server and ElastiCache as a Redis
cluster to finally manage them within an auto scaling group with custom
......@@ -18,12 +18,12 @@ scaling policies.
## Requirements
A basic familiarity with AWS and EC2 is assumed. In particular, you will need:
In addition to having a basic familiarity with [AWS](https://docs.aws.amazon.com/) and [Amazon EC2](https://docs.aws.amazon.com/ec2/), you will need:
- [An AWS account](https://console.aws.amazon.com/console/home)
- [Create or upload](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)
an SSH key to connect to the instance via SSH
- A domain name under which GitLab will be reached
- [To create or upload an SSH key](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)
to connect to the instance via SSH
- A domain name for the GitLab instance
## Architecture
......@@ -33,7 +33,7 @@ Below is the diagram of the architecture.
## Costs
Here's a list of the services we will use and their costs:
Here's a list of the services we will use, with links to pricing information:
- **EC2**: GitLab will deployed on shared hardware which means
[on-demand pricing](https://aws.amazon.com/ec2/pricing/on-demand)
......@@ -54,17 +54,17 @@ Here's a list of the services we will use and their costs:
## Creating an IAM EC2 instance role and profile
To minimize the permissions of the user, we'll create a new IAM role with
limited access:
To minimize the permissions of the user, we'll create a new [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)
role with limited access:
1. Navigate to the IAM dashboard https://console.aws.amazon.com/iam/home and
click on **Create role**.
1. Create a new role by choosing to **AWS service > EC2**. Once done, click on
click **Create role**.
1. Create a new role by choosing to **AWS service > EC2**. Once done, click
**Next: Permissions**.
![Create role](img/create_iam_role.png)
1. Choose **AmazonEC2FullAccess** and **AmazonS3FullAccess** and click on **Next: Review**.
1. Choose **AmazonEC2FullAccess** and **AmazonS3FullAccess**, then click **Next: Review**.
1. Give the role the name `GitLabAdmin` and click **Create role**.
![Create role](img/create_iam_role_review.png)
......@@ -73,15 +73,15 @@ limited access:
We'll start by creating a VPC for our GitLab cloud infrastructure, then
we can create subnets to have public and private instances in at least
two AZs. Public subnets will require a Route Table keep and an associated
two [Availability Zones (AZs)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html). Public subnets will require a Route Table keep and an associated
Internet Gateway.
### VPC
### Creating the Virtual Private Cloud (VPC)
Let's create a VPC:
We'll now create a VPC, a virtual networking environment that you'll control:
1. Navigate to https://console.aws.amazon.com/vpc/home
1. Select **Your VPCs** from the left menu and then click on **Create VPC**.
1. Navigate to https://console.aws.amazon.com/vpc/home.
1. Select **Your VPCs** from the left menu and then click **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.
......@@ -99,7 +99,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 on **Create subnet**. Give it a descriptive name tag based on the IP,
1. Click **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,
and at the IPv4 CIDR block let's give it a 24 subnet `10.0.0.0/24`:
......@@ -126,11 +126,11 @@ to associate an Internet Gateway. On the same VPC dashboard:
### Internet Gateway
Now, still on the same dashboard head over to Internet Gateways and
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 on **Create internet gateway**, give it the name `gitlab-gateway` and
1. Click **Create internet gateway**, give it the name `gitlab-gateway` and
click **Create**.
1. Select it from the table, and then under the **Actions** dropdown choose
"Attach to VPC".
......@@ -168,7 +168,7 @@ Now that we're done with the network, let's create a security group.
The security group is basically the firewall:
1. Select **Security Groups** from the left menu.
1. Click on **Create Security Group** and fill in the details. Give it a name,
1. Click **Create Security Group** and fill in the details. Give it a name,
add a description, and choose the VPC we created previously
1. Select the security group from the list and at the the bottom select the
Inbound Rules tab. You will need to open the SSH, HTTP, and HTTPS ports. Set
......@@ -181,7 +181,7 @@ The security group is basically the firewall:
host or CIDR block. In that case, change the SSH source to be custom and give
it the IP you want to SSH from.
1. When done, click on **Save**.
1. When done, click **Save**.
## PostgreSQL with RDS
......@@ -194,7 +194,7 @@ create the actual RDS instance.
1. Navigate to the RDS dashboard and select **Subnet Groups** from the left menu.
1. Give it a name (`gitlab-rds-group`), a description, and choose the VPC from
the VPC dropdown.
1. Click on "Add all the subnets related to this VPC" and
1. Click "Add all the subnets related to this VPC" and
remove the public ones, we only want the **private subnets**.
In the end, you should see `10.0.1.0/24` and `10.0.3.0/24` (as
we defined them in the [subnets section](#subnets)).
......@@ -206,7 +206,7 @@ create the actual RDS instance.
Now, it's time to create the database:
1. Select **Instances** from the left menu and click on **Create database**.
1. Select **Instances** from the left menu and click **Create database**.
1. Select PostgreSQL and click **Next**.
1. Since this is a production server, let's choose "Production". Click **Next**.
1. Let's see the instance specifications:
......@@ -225,7 +225,7 @@ Now, it's time to create the database:
1. The rest of the settings on this page request a DB isntance identifier, username
and a master password. We've chosen to use `gitlab-db-ha`, `gitlab` and a
very secure password respectively. Keep these in hand for later.
1. Click on **Next** to proceed to the advanced settings.
1. Click **Next** to proceed to the advanced settings.
1. Make sure to choose our gitlab VPC, our subnet group, set public accessibility to
**No**, and to leave it to create a new security group. The only additional
change which will be helpful is the database name for which we can use
......@@ -274,7 +274,7 @@ To set up Redis:
![ElastiCache subnet](img/ec_subnet.png)
1. Select **Redis** on the left menu and click on **Create** to create a new
1. Select **Redis** on the left menu and click **Create** to create a new
Redis cluster. Depending on your load, you can choose whether to enable
cluster mode or not. Even without cluster mode on, you still get the
chance to deploy Redis in multi availability zones. In this guide, we chose
......@@ -317,7 +317,7 @@ On the EC2 dashboard, look for Load Balancer on the left column:
1. In the "Listeners" section, make sure it has HTTP and HTTPS.
1. In the "Availability Zones" section, select the `gitlab-vpc` we have created
and associate the **public subnets**.
1. Click on the **Configure Security Settings** to go to the next section to
1. Click **Configure Security Settings** to go to the next section to
select the TLS certificate. When done, go to the next step.
1. In the "Security Groups" section, create a new one by giving it a name
(`gitlab-loadbalancer-sec-group`) and allow both HTTP ad HTTPS traffic
......@@ -328,7 +328,7 @@ On the EC2 dashboard, look for Load Balancer on the left column:
1. Leave the "Register Targets" section as is, and finally review the settings
and create the ELB.
After the Load Balancer is up and running, you can re-visit your Security
After the Load Balancer is up and running, you can revisit your Security
Groups to improve access only through the ELB and any other requirement
you might have.
......@@ -340,7 +340,7 @@ configure the PostgreSQL and Redis connections.
The Auto Scaling Group option is available through the EC2 dashboard on the left
sidebar.
1. Click on the **Create Auto Scaling group** button.
1. Click **Create Auto Scaling group**.
1. Create a new launch configuration.
### Choose the AMI
......@@ -348,15 +348,15 @@ sidebar.
Choose the AMI:
1. Go to the Community AMIs and search for `GitLab EE <version>`
where `<version>` the latest version as seen in the
where `<version>` the latest version as seen on the
[releases page](https://about.gitlab.com/releases/).
![Choose AMI](img/choose_ami.png)
### Choose instance type
### Choose an instance type
Based on [GitLab's requirements](../requirements.md#hardware-requirements), the
instance type should be at least `c4.xlarge`. This is enough to accommodate 100 users:
instance type should be at least `c4.xlarge`, which is enough to accommodate 100 users.
1. Choose the `c4.xlarge` instance.
1. Click **Next: Configure Instance Details**
......@@ -365,7 +365,7 @@ instance type should be at least `c4.xlarge`. This is enough to accommodate 100
In this step we'll configure some details:
1. Give it a name (`gitlab-autoscaling`).
1. Enter a name (`gitlab-autoscaling`).
1. Select the IAM role we created.
1. Optionally, enable CloudWatch and the EBS-optimized instance settings.
1. In the "Advanced Details" section, set the IP address type to
......@@ -383,7 +383,7 @@ You will be able to [set up that volume later](#setting-up-the-ebs-volume).
As a last step, configure the security group:
1. Select the existing load balancer security group we [have created](#load-balancer).
1. Select the existing load balancer security group we have [created](#load-balancer).
1. Select **Review**.
### Review and launch
......@@ -403,7 +403,7 @@ We are now able to start creating our Auto Scaling Group:
1. Choose the ELB health check.
1. Click **Next: Configure scaling policies**.
This is the really great part of Auto Scaling, we get to choose when AWS
This is the really great part of Auto Scaling; we get to choose when AWS
launches new instances and when it removes them. 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
......@@ -416,7 +416,7 @@ auto scaling group.
You'll notice that after we save the configuration, AWS starts launching our two
instances in different AZs and without a public IP which is exactly what
we where aiming for.
we intended.
## After deployment
......@@ -437,10 +437,10 @@ find the `external_url 'http://gitlab.example.com'` option and change it
to the domain you will be using or the public IP address of the current
instance to test the configuration.
For a more detailed description about configuring GitLab read [Configuring GitLab for HA](../../administration/high_availability/gitlab.md)
For a more detailed description about configuring GitLab, see [Configuring GitLab for HA](../../administration/high_availability/gitlab.md)
Now look for the GitLab database settings and uncomment as necessary. In
our current case we'll specify the adapter, encoding, host, db name,
our current case we'll specify the database adapter, encoding, host, name,
username, and password:
```ruby
......@@ -480,7 +480,7 @@ sudo gitlab-rake gitlab:check
sudo gitlab-ctl status
```
If everything looks good copy the Elastic IP over to your browser and
If everything looks good, copy the Elastic IP over to your browser and
test the instance manually.
### Setting up the EBS volume
......@@ -488,8 +488,8 @@ test the instance manually.
The EBS volume will host the Git repositories data:
1. First, format the `/dev/xvdb` volume and then mount it under the directory
that the data will live, for example `/mnt/gitlab-data/`.
1. Tell GitLab to store its data to the new directory by editing
where the data will be stored. For example, `/mnt/gitlab-data/`.
1. Tell GitLab to store its data in the new directory by editing
`/etc/gitlab/gitlab.rb` with your editor:
```ruby
......@@ -504,9 +504,9 @@ The EBS volume will host the Git repositories data:
sudo gitlab-ctl reconfigure
```
To add more than one data volumes, follow the same steps.
To add more than one data volume, follow the same steps.
Read more on [storing Git data in an alternative directory](../../administration/repository_storage_paths.md).
You can read more about [storing Git data in an alternative directory](../../administration/repository_storage_paths.md).
### Setting up Gitaly
......@@ -528,7 +528,7 @@ The S3 object storage can be used for various GitLab objects:
After you SSH into the instance, configure the domain name:
1. Open `/etc/gitlab/gitlab.rb` with your favorite editor.
1. Open `/etc/gitlab/gitlab.rb` with your preferred editor.
1. Edit the `external_url` value:
```ruby
......@@ -577,15 +577,15 @@ and restore its Git data, database, attachments, LFS objects, etc.
Some important things to know:
- The backup/restore tool does not store some configuration files, like secrets, you'll
need to [do it yourself](../../raketasks/backup_restore.md#storing-configuration-files).
- The backup/restore tool does not store some configuration files, like secrets; you'll
need to [handle this yourself](../../raketasks/backup_restore.md#storing-configuration-files).
- By default, the backup files are stored locally, but you can
[backup GitLab using S3](../../raketasks/backup_restore.md#using-amazon-s3).
- You can exclude [specific directories form the backup](../../raketasks/backup_restore.md#excluding-specific-directories-from-the-backup).
- You can [exclude specific directories form the backup](../../raketasks/backup_restore.md#excluding-specific-directories-from-the-backup).
### Backing up GitLab
To backup GitLab:
To back up GitLab:
1. SSH into your instance.
1. Take a backup:
......@@ -596,8 +596,8 @@ To backup GitLab:
### Restoring GitLab from a backup
To restore GitLab, first check the [restore documentation](../../raketasks/backup_restore.md#restore)
and mainly the restore prerequisites. Then, follow the steps under the
To restore GitLab, first review the [restore documentation](../../raketasks/backup_restore.md#restore),
and primarily the restore prerequisites. Then, follow the steps under the
[Omnibus installations section](../../raketasks/backup_restore.md#restore-for-omnibus-installations).
## Updating GitLab
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment