diff options
Diffstat (limited to 'doc/install/aws/index.md')
| -rw-r--r-- | doc/install/aws/index.md | 104 |
1 files changed, 52 insertions, 52 deletions
diff --git a/doc/install/aws/index.md b/doc/install/aws/index.md index b41ee07fd52..00c55e98484 100644 --- a/doc/install/aws/index.md +++ b/doc/install/aws/index.md @@ -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**.  -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**.  @@ -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:  -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 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 |