edits per my review
This commit is contained in:
parent
4f3a9be1f6
commit
0e63e2522e
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue