# Installing GitLab on Amazon Web Services (AWS)
> 原文:[https://docs.gitlab.com/ee/install/aws/](https://docs.gitlab.com/ee/install/aws/)
* [Introduction](#introduction)
* [Requirements](#requirements)
* [Architecture](#architecture)
* [AWS costs](#aws-costs)
* [Create an IAM EC2 instance role and profile](#create-an-iam-ec2-instance-role-and-profile)
* [Create an IAM Policy](#create-an-iam-policy)
* [Create an IAM Role](#create-an-iam-role)
* [Configuring the network](#configuring-the-network)
* [Creating the Virtual Private Cloud (VPC)](#creating-the-virtual-private-cloud-vpc)
* [Subnets](#subnets)
* [Internet Gateway](#internet-gateway)
* [Create NAT Gateways](#create-nat-gateways)
* [Route Tables](#route-tables)
* [Public Route Table](#public-route-table)
* [Private Route Tables](#private-route-tables)
* [Load Balancer](#load-balancer)
* [Configure DNS for Load Balancer](#configure-dns-for-load-balancer)
* [PostgreSQL with RDS](#postgresql-with-rds)
* [RDS Security Group](#rds-security-group)
* [RDS Subnet Group](#rds-subnet-group)
* [Create the database](#create-the-database)
* [Redis with ElastiCache](#redis-with-elasticache)
* [Create a Redis Security Group](#create-a-redis-security-group)
* [Redis Subnet Group](#redis-subnet-group)
* [Create the Redis Cluster](#create-the-redis-cluster)
* [Setting up Bastion Hosts](#setting-up-bastion-hosts)
* [Create Bastion Host A](#create-bastion-host-a)
* [Create Bastion Host B](#create-bastion-host-b)
* [Use SSH Agent Forwarding](#use-ssh-agent-forwarding)
* [Install GitLab and create custom AMI](#install-gitlab-and-create-custom-ami)
* [Install GitLab](#install-gitlab)
* [Add custom configuration](#add-custom-configuration)
* [Disable Let’s Encrypt](#disable-lets-encrypt)
* [Install the `pg_trgm` extension for PostgreSQL](#install-the-pg_trgm-extension-for-postgresql)
* [Configure GitLab to connect to PostgreSQL and Redis](#configure-gitlab-to-connect-to-postgresql-and-redis)
* [Set up Gitaly](#set-up-gitaly)
* [Add Support for Proxied SSL](#add-support-for-proxied-ssl)
* [Fast lookup of authorized SSH keys](#fast-lookup-of-authorized-ssh-keys)
* [Configure host keys](#configure-host-keys)
* [Amazon S3 object storage](#amazon-s3-object-storage)
* [Create custom AMI](#create-custom-ami)
* [Deploy GitLab inside an auto scaling group](#deploy-gitlab-inside-an-auto-scaling-group)
* [Create a launch configuration](#create-a-launch-configuration)
* [Create an auto scaling group](#create-an-auto-scaling-group)
* [Log in for the first time](#log-in-for-the-first-time)
* [Health check and monitoring with Prometheus](#health-check-and-monitoring-with-prometheus)
* [GitLab Runners](#gitlab-runners)
* [Backup and restore](#backup-and-restore)
* [Backing up GitLab](#backing-up-gitlab)
* [Restoring GitLab from a backup](#restoring-gitlab-from-a-backup)
* [Updating GitLab](#updating-gitlab)
* [Conclusion](#conclusion)
* [Troubleshooting](#troubleshooting)
* [Instances are failing health checks](#instances-are-failing-health-checks)
* [“The change you requested was rejected (422)”](#the-change-you-requested-was-rejected-422)
# Installing GitLab on Amazon Web Services (AWS)[](#installing-gitlab-on-amazon-web-services-aws "Permalink")
該頁面提供了 AWS 上 GitLab 通用配置的演練. 您應該對其進行自定義以滿足您的需求.
**注意:**對于擁有 1,000 個或更少用戶的組織,建議的 AWS 安裝方法是啟動 EC2 單框[Omnibus 安裝](https://about.gitlab.com/install/)并實施快照策略以備份數據. 有關更多信息,請參見[1,000 個用戶參考體系結構](../../administration/reference_architectures/1k_users.html) .
## Introduction[](#introduction "Permalink")
在大多數情況下,我們將在我們的設置中使用 Omnibus GitLab,但我們還將利用本機 AWS 服務. 代替使用 Omnibus 捆綁的 PostgreSQL 和 Redis,我們將使用 AWS RDS 和 ElastiCache.
在本指南中,我們將進行多節點設置,首先將配置虛擬私有云和子網,以稍后集成服務(例如用于數據庫服務器的 RDS 和作為 Redis 集群的 ElastiCache)以最終在一個具有自定義縮放策略的自動縮放組.
## Requirements[](#requirements "Permalink")
除了基本了解[AWS](https://docs.aws.amazon.com/)和[Amazon EC2 之外](https://docs.aws.amazon.com/ec2/) ,您還需要:
* [An AWS account](https://console.aws.amazon.com/console/home)
* [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
* GitLab 實例的域名
* SSL / TLS 證書以保護您的域. 如果您還不擁有該證書,則可以通過[AWS Certificate Manager](https://aws.amazon.com/certificate-manager/) (ACM)設置免費的公共 SSL / TLS 證書,以與我們將創建的[Elastic Load Balancer](#load-balancer)一起使用.
**注意:**驗證通過 ACM 設置的證書可能需要幾個小時. 為避免以后出現延遲,請盡快申請您的證書.
## Architecture[](#architecture "Permalink")
下面是推薦架構的示意圖.
[](img/aws_ha_architecture_diagram.png)
## AWS costs[](#aws-costs "Permalink")
以下是我們將使用的 AWS 服務的列表,以及指向定價信息的鏈接:
* **EC2** :GitLab 將部署在共享硬件上,這意味著將[按需定價](https://aws.amazon.com/ec2/pricing/on-demand/) . 如果要在專用或保留實例上運行它,請參閱[EC2 定價頁面](https://aws.amazon.com/ec2/pricing/)以獲取有關費用的更多信息.
* **S3** :我們將使用 S3 來存儲備份,工件,LFS 對象等.請參閱[Amazon S3 定價](https://aws.amazon.com/s3/pricing/) .
* **ELB** :經典負載均衡器將用于將請求路由到 GitLab 實例. 請參閱[Amazon ELB 定價](https://aws.amazon.com/elasticloadbalancing/pricing/) .
* **RDS** :將使用使用 PostgreSQL 的 Amazon Relational Database Service. 請參閱[Amazon RDS 定價](https://aws.amazon.com/rds/postgresql/pricing/) .
* **ElastiCache** :內存緩存環境將用于提供 Redis 配置. 請參閱[Amazon ElastiCache 定價](https://aws.amazon.com/elasticache/pricing/) .
## Create an IAM EC2 instance role and profile[](#create-an-iam-ec2-instance-role-and-profile "Permalink")
由于我們將使用[Amazon S3 對象存儲](#amazon-s3-object-storage) ,因此我們的 EC2 實例需要具有對 S3 存儲桶的讀取,寫入和列出權限. 為了避免將 AWS Key 嵌入我們的 GitLab 配置中,我們將利用[IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)允許 GitLab 實例具有此訪問權限. 我們需要創建一個 IAM 策略以附加到我們的 IAM 角色:
### Create an IAM Policy[](#create-an-iam-policy "Permalink")
1. 導航到 IAM 儀表板,然后單擊左側菜單中的" **策略** ".
2. 單擊**創建策略** ,選擇`JSON`選項卡,然后添加策略. 我們希望[遵循安全最佳實踐并授予*最少的特權*](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) ,僅向我們的角色授予執行所需操作所需的權限.
1. 假設如圖所示,在 S3 存儲桶名稱前添加`gl-`作為前綴,請添加以下策略:
```
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:AbortMultipartUpload", "s3:CompleteMultipartUpload", "s3:ListBucket", "s3:PutObject", "s3:GetObject", "s3:DeleteObject", "s3:PutObjectAcl" ], "Resource": [ "arn:aws:s3:::gl-*/*" ] } ] }
```
1. 點擊**審核政策** ,為您的政策命名(我們將使用`gl-s3-policy` ),然后點擊**創建政策** .
### Create an IAM Role[](#create-an-iam-role "Permalink")
1. 仍在 IAM 儀表板上,單擊左側菜單中的**角色** ,然后單擊**創建角色** .
2. 通過選擇**AWS 服務> EC2**來創建新角色,然后單擊**下一步:權限** .
3. 在策略過濾器中,搜索我們在上面創建的`gl-s3-policy` ,選擇它,然后點擊**標簽** .
4. 根據需要添加標簽,然后單擊" **查看"** .
5. 為角色命名(我們將使用`GitLabS3Access` ),然后點擊**創建角色** .
稍后[創建啟動配置](#create-a-launch-configuration)時,將使用此角色.
## Configuring the network[](#configuring-the-network "Permalink")
我們將從為 GitLab 云基礎架構創建 VPC 開始,然后我們可以創建子網以在至少兩個[可用區(AZ)中](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html)具有公共實例和私有實例. 公共子網將需要保留路由表和關聯的 Internet 網關.
### Creating the Virtual Private Cloud (VPC)[](#creating-the-virtual-private-cloud-vpc "Permalink")
現在,我們將創建一個 VPC,一個您可以控制的虛擬網絡環境:
1. 導航至[https://console.aws.amazon.com/vpc/home](https://console.aws.amazon.com/vpc/home) .
2. 從左側菜單中選擇**您的 VPC** ,然后單擊**創建 VPC** . 在"名稱標簽"中輸入`gitlab-vpc` ,在" IPv4 CIDR 塊"中輸入`10.0.0.0/16` . 如果不需要專用硬件,則可以將" Tenancy"保留為默認設置. 單擊**是,**準備好后**創建** .
[](img/create_vpc.png)
3. 選擇 VPC,單擊" **操作"** ,單擊" **編輯 DNS 解析"** ,然后啟用 DNS 解析. 完成后點擊**保存** .
### Subnets[](#subnets "Permalink")
現在,讓我們在不同的可用區中創建一些子網. 確保每個子網都與我們剛剛創建的 VPC 相關聯,并且 CIDR 塊不會重疊. 這也將使我們能夠啟用多可用區以實現冗余.
我們還將創建專用和公用子網以匹配負載均衡器和 RDS 實例:
1. 從左側菜單中選擇**子網** .
2. 單擊**創建子網** . 給它一個基于 IP 的描述性名稱標簽,例如`gitlab-public-10.0.0.0` ,選擇我們之前創建的 VPC,選擇一個可用區(我們將使用`us-west-2a` ),并在 IPv4 CIDR 塊上讓我們給它一個 24 個子網`10.0.0.0/24` :
[](img/create_subnet.png)
3. 請按照相同的步驟創建所有子網:
| 名稱標簽 | Type | 可用區 | CIDR 塊 |
| --- | --- | --- | --- |
| `gitlab-public-10.0.0.0` | public | `us-west-2a` | `10.0.0.0/24` |
| `gitlab-private-10.0.1.0` | private | `us-west-2a` | `10.0.1.0/24` |
| `gitlab-public-10.0.2.0` | public | `us-west-2b` | `10.0.2.0/24` |
| `gitlab-private-10.0.3.0` | private | `us-west-2b` | `10.0.3.0/24` |
4. 創建所有子網后,請為兩個公共子網啟用**自動分配 IPv4** :
1. 依次選擇每個公共子網,單擊" **操作"** ,然后單擊" **修改自動分配 IP 設置"** . 啟用該選項并保存.
### Internet Gateway[](#internet-gateway "Permalink")
現在,仍然在同一儀表板上,轉到 Internet 網關并創建一個新的網關:
1. 從左側菜單中選擇" **Internet 網關** ".
2. 單擊**創建互聯網網關** ,為其命名為`gitlab-gateway` ,然后單擊**創建** .
3. 從表中選擇它,然后在" **操作"**下拉菜單下選擇"附加到 VPC".
[](img/create_gateway.png)
4. 從列表中選擇`gitlab-vpc` ,然后點擊**Attach** .
### Create NAT Gateways[](#create-nat-gateways "Permalink")
部署在我們專用子網中的實例需要連接到 Internet 進行更新,但不能從公共 Internet 到達. 為此,我們將利用部署在每個公共子網中的[NAT 網關](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) :
1. 導航到 VPC 儀表板,然后單擊左側菜單欄中的**NAT 網關** .
2. 單擊**創建 NAT 網關,**然后完成以下操作:
1. **子網** :從下拉列表中選擇`gitlab-public-10.0.0.0` .
2. **彈性 IP 分配 ID** :輸入現有的彈性 IP 或單擊**分配彈性 IP 地址,**以將新 IP 分配給您的 NAT 網關.
3. 如果需要,添加標簽.
4. 單擊**創建 NAT 網關** .
創建第二個 NAT 網關,但這一次將其放置在第二個公共子網`gitlab-public-10.0.2.0` .
### Route Tables[](#route-tables "Permalink")
#### Public Route Table[](#public-route-table "Permalink")
我們需要為公共子網創建路由表,以通過上一步中創建的 Internet 網關訪問 Internet.
在 VPC 儀表板上:
1. 從左側菜單中選擇**路由表** .
2. Click **創建路由表**.
3. 在"名稱標簽"中,輸入`gitlab-public` , `gitlab-vpc`在" VPC"下選擇`gitlab-vpc` .
4. Click **Create**.
現在,我們需要將我們的 Internet 網關添加為新目標,并使其接收來自任何目的地的流量.
1. 從左側菜單中選擇" **路由表"** ,然后選擇`gitlab-public`路由以在底部顯示選項.
2. 選擇" **路線"**選項卡,單擊" **編輯路線">"添加路線",**然后將`0.0.0.0/0`設置為目的地. 在目標列中,選擇我們之前創建的`gitlab-gateway` . 完成后,點擊**保存路線** .
接下來,我們必須將**公共**子網關聯到路由表:
1. Select the **子網關聯** tab and click **編輯子網關聯**.
2. 僅檢查公共子網,然后單擊" **保存"** .
#### Private Route Tables[](#private-route-tables "Permalink")
我們還需要創建兩個私有路由表,以便每個私有子網中的實例都可以通過同一可用性區域中相應公共子網中的 NAT 網關到達 Internet.
1. 請按照與上述相同的步驟創建兩個專用路由表. 將它們`gitlab-private-a`命名為`gitlab-private-a`和`gitlab-private-b` .
2. Next, add a new route to each of the private route tables where the destination is `0.0.0.0/0` and the target is one of the NAT gateways we created earlier.
1. 將我們在`gitlab-public-10.0.0.0`創建的 NAT 網關添加為`gitlab-private-a`路由表中新路由的目標.
2. 同樣,在`gitlab-public-10.0.2.0`添加 NAT 網關作為`gitlab-private-b`新路由的目標.
3. 最后,將每個專用子網與專用路由表相關聯.
1. 將`gitlab-private-10.0.1.0` `gitlab-private-a`與`gitlab-private-a` .
2. 將`gitlab-private-10.0.3.0`與`gitlab-private-b` .
## Load Balancer[](#load-balancer "Permalink")
我們將創建一個負載平衡器,以在我們的 GitLab 應用程序服務器之間平均分配端口`80`和`443`上的入站流量. 根據我們稍后將創建的[擴展策略](#create-an-auto-scaling-group) ,實例將根據需要添加到負載均衡器中或從負載均衡器中刪除. 此外,負載平衡將對我們的實例執行運行狀況檢查.
在 EC2 儀表板上,在左側導航欄中查找 Load Balancer:
1. 單擊**創建負載均衡器**按鈕.
1. 選擇**經典負載均衡器** .
2. 給它`gitlab-loadbalancer` (我們將使用`gitlab-loadbalancer` ),并在**Create LB Inside**選項中,從下拉菜單中選擇`gitlab-vpc` .
3. 在" **偵聽器"**部分中,設置以下偵聽器:
* 負載均衡器和實例協議以及端口的 HTTP 端口 80
* 負載均衡器和實例協議以及端口的 TCP 端口 22
* HTTPS 端口 443(用于負載均衡器協議和端口),轉發到實例上的 HTTP 端口 80(我們將[在指南](#add-support-for-proxied-ssl)中將 GitLab 配置為偵聽端口 80)
4. 在" **選擇子網"**部分中,從列表中選擇兩個公共子網,以便負載均衡器可以將流量路由到兩個可用區域.
2. 我們將為負載均衡器添加一個安全組,以充當防火墻來控制允許通過的流量. 單擊**分配安全組,**然后選擇**創建新的安全組** ,為其命名(我們將使用`gitlab-loadbalancer-sec-group` )和說明,并允許來自任何地方的 HTTP 和 HTTPS 通信( `0.0.0.0/0, ::/0` ). 還允許 SSH 流量,選擇自定義來源,并以 CIDR 表示法添加單個受信任的 IP 地址或 IP 地址范圍. 這將允許用戶通過 SSH 執行 Git 操作.
3. 單擊**配置安全設置,**然后進行以下設置:
1. 從 ACM 中選擇一個 SSL / TLS 證書或將一個證書上傳到 IAM.
2. 在" **選擇密碼"下** ,從下拉列表中選擇預定義的安全策略. 您可以在 AWS 文檔中[查看 Classic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html)的[預定義 SSL 安全策略](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html)明細. 檢查 GitLab 代碼庫以獲取[受支持的 SSL 密碼和協議](https://gitlab.com/gitlab-org/gitlab/-/blob/9ee7ad433269b37251e0dd5b5e00a0f00d8126b4/lib/support/nginx/gitlab-ssl#L97-99)的列表.
4. 單擊" **配置**運行狀況檢查",然后為您的 EC2 實例設置運行狀況檢查.
1. 對于" **Ping 協議"** ,選擇" HTTP".
2. 對于**Ping 端口** ,輸入 80\.
3. 對于**Ping Path** ,輸入`/users/sign_in` . (我們使用`/users/sign_in`因為它是不需要授權的公共端點.)
4. 保留默認的" **高級詳細信息"**或根據需要進行調整.
5. 單擊**添加 EC2 實例** -不要添加任何內容,因為稍后我們將創建一個 Auto Scaling 組來為我們管理實例.
6. 單擊**添加標簽,**然后添加您需要的任何標簽.
7. 單擊" **查看并創建"** ,查看所有設置,如果滿意,請單擊" **創建"** .
在負載均衡器啟動并運行后,您可以重新訪問安全組以僅通過 ELB 和您可能具有的任何其他要求來完善訪問.
### Configure DNS for Load Balancer[](#configure-dns-for-load-balancer "Permalink")
在 Route 53 儀表板上,單擊左側導航欄中的" **托管區域** ":
1. 選擇一個現有的托管區域,或者,如果您的域還沒有一個,請單擊**創建托管區域** ,輸入您的域名,然后單擊**創建** .
2. 單擊**創建記錄集,**并提供以下值:
1. **名稱:**使用域名(默認值)或輸入一個子域.
2. **類型:**選擇**A-IPv4 地址** .
3. **別名:**默認為**No.** 選擇**是** .
4. **別名目標:**找到" **ELB 經典負載均衡器"**部分,然后選擇我們之前創建的經典負載均衡器.
5. **路由策略:**我們將使用" **簡單",**但您可以根據用例選擇其他策略.
6. **評估目標健康狀況:**我們將其設置為" **否",**但是您可以選擇讓負載均衡器根據目標健康狀況來路由流量.
7. 點擊**創建** .
3. 如果您通過 Route 53 注冊了域,那么您就完成了. 如果您使用了其他域名注冊商,則需要使用域名注冊商更新 DNS 記錄. 您需要:
1. 單擊**托管區域,**然后選擇您在上面添加的域.
2. 您將看到`NS`記錄列表. 在您的域名注冊商的管理面板中,將每一個作為`NS`記錄添加到您域的 DNS 記錄中. 這些步驟在域注冊商之間可能會有所不同. 如果您陷入困境,則 Google **"您的注冊商名稱"會添加 dns 記錄** ,您應該會找到針對您的域名注冊商的幫助文章.
根據您使用的注冊商的不同,執行此操作的步驟也有所不同,這超出了本指南的范圍.
## PostgreSQL with RDS[](#postgresql-with-rds "Permalink")
對于我們的數據庫服務器,我們將使用提供多可用區以實現冗余的 Amazon RDS. 首先,我們將創建一個安全組和子網組,然后將創建實際的 RDS 實例.
### RDS Security Group[](#rds-security-group "Permalink")
我們需要一個用于數據庫的安全組,該安全組將允許稍后將在`gitlab-loadbalancer-sec-group`部署的實例的入站流量:
1. 在 EC2 儀表板中,從左側菜單欄中選擇" **安全組** ".
2. Click **創建安全組**.
3. 給它起一個名字(我們將使用`gitlab-rds-sec-group` ),一個描述,并從**VPC**下拉列表中選擇`gitlab-vpc` .
4. 在" **入站規則"**部分中,單擊" **添加規則"**并進行以下設置:
1. **鍵入:**搜索并選擇**PostgreSQL**規則.
2. **來源類型:**設置為"自定義".
3. **來源:**選擇我們之前創建的`gitlab-loadbalancer-sec-group` .
5. 完成后,點擊**創建安全組** .
### RDS Subnet Group[](#rds-subnet-group "Permalink")
1. 導航到 RDS 儀表板,然后從左側菜單中選擇" **子網組** ".
2. 單擊**創建數據庫子網組** .
3. 在" **子網組詳細信息"下** ,輸入名稱(我們將使用`gitlab-rds-group` ),描述,然后從 VPC 下拉列表中選擇`gitlab-vpc` .
4. 從" **可用區"**下拉列表中,選擇包括您已配置的子網的可用區. 在本例中,我們將添加`eu-west-2a`和`eu-west-2b` .
5. 從**子網**下拉列表中,選擇兩個專用子網( `10.0.1.0/24`和`10.0.3.0/24` ,因為我們在定義它們) [的子網部分](#subnets) .
6. 準備好后,單擊**創建** .
### Create the database[](#create-the-database "Permalink")
**危險:**避免對數據庫使用易爆實例(t 類實例),因為由于 CPU 信用在持續的高負載期間用盡而可能導致性能問題.
現在,該創建數據庫了:
1. 導航到 RDS 儀表板,從左側菜單中選擇" **數據庫** ",然后單擊" **創建數據庫"** .
2. 選擇**標準創建**作為數據庫創建方法.
3. 選擇**PostgreSQL**作為數據庫引擎,然后選擇在[數據庫要求中](../../install/requirements.html#postgresql-requirements)為您的 GitLab 版本定義的最低 PostgreSQL 版本.
4. 由于這是生產服務器,因此我們從" **模板"**部分中選擇" **生產** ".
5. 在**"設置"下** ,設置數據庫實例標識符,主用戶名和主密碼. 我們將分別使用`gitlab-db-ha` , `gitlab`和一個非常安全的密碼. 記下這些內容,稍后我們將需要它們.
6. 對于數據庫實例大小,請選擇" **標準類",**然后從下拉菜單中選擇一個滿足您要求的實例大小. 我們將使用`db.m4.large`實例.
7. 在" **存儲"下** ,配置以下內容:
1. 從存儲類型下拉菜單中選擇" **Provisioned IOPS(SSD)** ". 預置 IOPS(SSD)存儲最適合此用途(盡管您可以選擇 General Purpose(SSD)來降低成本). 在[Amazon RDS 的存儲中](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html)閱讀有關它的更多信息.
2. 分配存儲并設置預配置的 IOPS. 我們將分別使用最小值`100`和`1000` .
3. 啟用存儲自動縮放(可選)并設置最大存儲閾值.
8. 在" **可用性和持久性"下** ,選擇" **創建備用實例"**以在另一個可用[區中](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)配置備用 RDS 實例.
9. 在" **連接性"下** ,配置以下內容:
1. 從**虛擬私有云(VPC)**下拉菜單中選擇我們之前創建的 VPC( `gitlab-vpc` ).
2. 展開**其他連接配置**部分,然后選擇我們之前創建的子網組( `gitlab-rds-group` ).
3. 設置公眾了解**沒有** .
4. 在**VPC 安全組下** ,選擇**選擇現有,**然后從下拉列表中選擇我們在上面創建的`gitlab-rds-sec-group` .
5. 將數據庫端口保留為默認值`5432` .
10. 對于**數據庫身份驗證** ,選擇**密碼身份驗證** .
11. 展開**其他配置**部分,并完成以下操作:
1. 初始數據庫名稱. 我們將使用`gitlabhq_production` .
2. 配置您的首選備份設置.
3. 我們將在此處進行的唯一其他更改是禁用" **維護"**下的自動次要版本更新.
4. 保留所有其他設置不變或根據需要進行調整.
5. 滿意后,點擊**創建數據庫** .
現在已經創建了數據庫,讓我們繼續使用 ElastiCache 設置 Redis.
## Redis with ElastiCache[](#redis-with-elasticache "Permalink")
ElastiCache 是??一個內存托管的緩存解決方案. Redis 保持其自身的持久性,并用于為 GitLab 應用程序存儲會話數據,臨時緩存信息和后臺作業隊列.
### Create a Redis Security Group[](#create-a-redis-security-group "Permalink")
1. 導航到 EC2 儀表板.
2. 從左側菜單中選擇" **安全組** ".
3. 單擊**創建安全組,**然后填寫詳細信息. 給它`gitlab-redis-sec-group` (我們將使用`gitlab-redis-sec-group` ),添加描述,然后選擇我們之前創建的 VPC
4. 在" **入站規則"**部分中,單擊" **添加規則"**并添加一個" **自定義 TCP"**規則,設置端口`6379` ,并將"自定義"源設置為我們之前創建的`gitlab-loadbalancer-sec-group` .
5. 完成后,點擊**創建安全組** .
### Redis Subnet Group[](#redis-subnet-group "Permalink")
1. 從您的 AWS 控制臺導航到 ElastiCache 儀表板.
2. 轉到左側菜單中的" **子網組** ",然后創建一個新的子網組(我們將其命名為`gitlab-redis-group` ). 確保選擇我們的 VPC 及其[專用子網](#subnets) . 準備好后,單擊**創建** .
[](img/ec_subnet.png)
### Create the Redis Cluster[](#create-the-redis-cluster "Permalink")
1. 導航回到 ElastiCache 儀表板.
2. 在左側菜單上選擇**Redis** ,然后單擊**創建**以創建新的 Redis 集群. 不要啟用**集群模式,**因為它[不受支持](../../administration/redis/replication_and_failover_external.html#requirements) . 即使沒有啟用群集模式,您仍然有機會在多個可用性區域中部署 Redis.
3. 在設置部分:
1. 為集群命名( `gitlab-redis` )和描述.
2. 對于版本,選擇最新的`5.0`系列(例如`5.0.6` ).
3. 將端口保留為`6379`因為這是我們在上面的 Redis 安全組中使用的端口.
4. 選擇節點類型(至少為`cache.t3.medium` ,但根據需要進行調整)和副本數.
4. 在高級設置部分:
1. 選擇多可用區自動故障轉移選項.
2. 選擇我們之前創建的子網組.
3. 手動選擇首選的可用區域,然后在"副本 2"下選擇與其他兩個區域不同的區域.
[](img/ec_az.png)
5. 在安全設置中,編輯安全組,然后選擇我們之前創建的`gitlab-redis-sec-group` .
6. 將其余設置保留為默認值,或根據自己的喜好進行編輯.
7. 完成后,點擊**創建** .
## Setting up Bastion Hosts[](#setting-up-bastion-hosts "Permalink")
由于我們的 GitLab 實例將位于專用子網中,因此我們需要一種通過 SSH 連接到這些實例以進行配置更改,執行升級等的方法.一種方法是通過[堡壘主機](https://en.wikipedia.org/wiki/Bastion_host) ,有時也稱為跳轉框.
**提示:**如果您不想維護堡壘主機,則可以設置[AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html)來訪問實例. 這超出了本文檔的范圍.
### Create Bastion Host A[](#create-bastion-host-a "Permalink")
1. 導航到 EC2 儀表板,然后單擊**Launch instance** .
2. 選擇**Ubuntu Server 18.04 LTS(HVM)** AMI.
3. 選擇一個實例類型. 我們將使用`t2.micro`因為我們僅使用堡壘主機將 SSH SSH 到我們的其他實例中.
4. Click **配置實例詳細信息**.
1. 在" **網絡"下** ,從下拉菜單中選擇`gitlab-vpc` .
2. 在" **子網"下** ,選擇我們之前創建的公共子網( `gitlab-public-10.0.0.0` ).
3. 仔細檢查是否在" **自動分配公用 IP"下**選擇了" **使用子網設置"("啟用")** .
4. 將其他所有內容保留為默認值,然后單擊" **添加存儲"** .
5. 對于存儲,我們將所有內容保留為默認設置,僅添加 8GB 根卷. 我們不會在此實例上存儲任何內容.
6. 單擊**添加標簽** ,然后在下一個屏幕上單擊**添加標簽** .
1. 我們只設置`Key: Name`和`Value: Bastion Host A`
7. Click **配置安全組**.
1. 選擇**創建新的安全組** ,輸入**安全組名稱** (我們將使用`bastion-sec-group` ),然后添加描述.
2. 我們將從任何地方( `0.0.0.0/0` )啟用 SSH 訪問. 如果需要更嚴格的安全性,請以 CIDR 表示法指定單個 IP 地址或 IP 地址范圍.
3. Click **審查并啟動**
8. Review all your settings and, if you’re happy, click **Launch**.
9. 確認您有權訪問現有的密鑰對或創建一個新的密鑰對. 單擊**啟動實例** .
確認您可以通過 SSH 進入實例:
1. 在 EC2 儀表板上,單擊左側菜單中的**Instances** .
2. 從實例列表中選擇**Bastion HostA** .
3. 單擊**連接,**然后按照連接說明進行操作.
4. 如果能夠成功連接,讓我們繼續設置第二個堡壘主機以實現冗余.
### Create Bastion Host B[](#create-bastion-host-b "Permalink")
1. 按照與上述相同的步驟創建 EC2 實例,并進行以下更改:
1. 對于**Subnet** ,選擇我們之前創建的第二個公共子網( `gitlab-public-10.0.2.0` ).
2. 在" **添加標簽"**部分下,我們將設置" `Key: Name`和`Value: Bastion Host B`以便我們可以輕松識別兩個實例.
3. 對于安全組,選擇我們上面創建的現有`bastion-sec-group` .
### Use SSH Agent Forwarding[](#use-ssh-agent-forwarding "Permalink")
運行 Linux 的 EC2 實例使用私鑰文件進行 SSH 身份驗證. 您將使用 SSH 客戶端和存儲在客戶端上的私鑰文件連接到堡壘主機. 由于私有密鑰文件不存在于堡壘主機上,因此您將無法連接到私有子網中的實例.
在堡壘主機上存儲私鑰文件是一個壞主意. 要解決此問題,請在客戶端上使用 SSH 代理轉發. 有關如何使用 SSH 代理轉發的分步指南,請參閱[安全連接到在私有 Amazon VPC 中運行的 Linux 實例](https://aws.amazon.com/blogs/security/securely-connect-to-linux-instances-running-in-a-private-amazon-vpc/) .
## Install GitLab and create custom AMI[](#install-gitlab-and-create-custom-ami "Permalink")
我們將需要預先配置的自定義 GitLab AMI,以便稍后在我們的啟動配置中使用. 首先,我們將使用官方的 GitLab AMI 創建 GitLab 實例. 然后,我們將為 PostgreSQL,Redis 和 Gitaly 添加自定義配置. 如果愿意,您也可以使用自己選擇的 EC2 實例啟動并[手動安裝 GitLab](https://about.gitlab.com/install/) ,而不是使用官方的 GitLab AMI.
### Install GitLab[](#install-gitlab "Permalink")
從 EC2 儀表板:
1. 單擊**啟動實例,**然后從左側菜單中選擇**社區 AMI** .
2. 在搜索欄中,搜索`GitLab EE <version>` ,其中`<version>`是[發行頁面](https://about.gitlab.com/releases/)上顯示的最新版本. 選擇最新的補丁程序版本,例如`GitLab EE 12.9.2` .
3. 根據您的工作量選擇一個實例類型. 請查閱[硬件要求,](../../install/requirements.html#hardware-requirements)以選擇適合您需求的[硬件](../../install/requirements.html#hardware-requirements) (至少`c5.xlarge` ,足以容納 100 位用戶).
4. Click **配置實例詳細信息**:
1. 在" **網絡"**下拉列表中,選擇`gitlab-vpc` ,這是我們之前創建的 VPC.
2. 在" **子網"**下拉列表中,從我們先前創建的**子網**列表中選擇`gitlab-private-10.0.1.0` .
3. 仔細檢查是否將" **自動分配公用 IP"**設置為" `Use subnet setting (Disable)` .
4. Click **添加存儲**.
5. 默認情況下,根卷為 8GiB,并且在我們不會在其中存儲任何數據的情況下,根卷應該足夠.
5. 單擊**添加標簽,**然后添加您可能需要的任何標簽. 在本例中,我們將僅設置`Key: Name`和`Value: GitLab` .
6. 單擊**配置安全組** . 選中**選擇現有安全組,**然后選擇我們之前創建的`gitlab-loadbalancer-sec-group` .
7. 如果對設置滿意,請單擊**查看并啟動,**然后單擊**啟動** .
8. 最后,確認您有權訪問所選的私鑰文件或創建一個新的私鑰文件. 單擊**啟動實例** .
### Add custom configuration[](#add-custom-configuration "Permalink")
使用[SSH 代理轉發](#use-ssh-agent-forwarding)通過**Bastion Host A**連接到您的 GitLab 實例. 連接后,添加以下自定義配置:
#### Disable Let’s Encrypt[](#disable-lets-encrypt "Permalink")
由于我們要在負載均衡器中添加 SSL 證書,因此我們不需要 GitLab 對 Let's Encrypt 的內置支持. 自 GitLab 10.7 起,使用`https`域時[,默認情況下啟用](https://docs.gitlab.com/omnibus/settings/ssl.html)加密[功能](https://docs.gitlab.com/omnibus/settings/ssl.html) ,因此我們需要顯式禁用它:
1. 打開`/etc/gitlab/gitlab.rb`并禁用它:
```
letsencrypt['enable'] = false
```
2. 保存文件并重新配置以使更改生效:
```
sudo gitlab-ctl reconfigure
```
#### Install the `pg_trgm` extension for PostgreSQL[](#install-the-pg_trgm-extension-for-postgresql "Permalink")
在您的 GitLab 實例中,連接到 RDS 實例以驗證訪問權限并安裝所需的`pg_trgm`擴展.
要查找主機或終端節點,請導航至**Amazon RDS>數據庫** ,然后單擊您之前創建的數據庫. 在" **連接性和安全性"**選項卡下查找端點.
不要包括冒號和端口號:
```
sudo /opt/gitlab/embedded/bin/psql -U gitlab -h <rds-endpoint> -d gitlabhq_production
```
在`psql`提示符下,創建擴展,然后退出會話:
```
psql (10.9)
Type "help" for help.
gitlab=# CREATE EXTENSION pg_trgm;
gitlab=# \q
```
#### Configure GitLab to connect to PostgreSQL and Redis[](#configure-gitlab-to-connect-to-postgresql-and-redis "Permalink")
1. 編輯`/etc/gitlab/gitlab.rb` ,找到`external_url 'http://<domain>'`選項并將其更改為您將使用的`https`域.
2. 查找 GitLab 數據庫設置,并根據需要取消注釋. 在當前情況下,我們將指定數據庫適配器,編碼,主機,名稱,用戶名和密碼:
```
# Disable the built-in Postgres
postgresql['enable'] = false
# Fill in the connection details
gitlab_rails['db_adapter'] = "postgresql"
gitlab_rails['db_encoding'] = "unicode"
gitlab_rails['db_database'] = "gitlabhq_production"
gitlab_rails['db_username'] = "gitlab"
gitlab_rails['db_password'] = "mypassword"
gitlab_rails['db_host'] = "<rds-endpoint>"
```
3. 接下來,我們需要通過添加主機并取消注釋端口來配置 Redis 部分:
```
# Disable the built-in Redis
redis['enable'] = false
# Fill in the connection details
gitlab_rails['redis_host'] = "<redis-endpoint>"
gitlab_rails['redis_port'] = 6379
```
4. 最后,重新配置 GitLab 以使更改生效:
```
sudo gitlab-ctl reconfigure
```
5. 您可能還會發現運行檢查和服務狀態以確保一切均已正確設置很有用:
```
sudo gitlab-rake gitlab:check
sudo gitlab-ctl status
```
#### Set up Gitaly[](#set-up-gitaly "Permalink")
**注意:**在這種體系結構中,只有一臺 Gitaly 服務器會造成單點故障. 使用[Gitaly Cluster](../../administration/gitaly/praefect.html)可以消除此限制.
Gitaly 是一項服務,它提供對 Git 存儲庫的高級 RPC 訪問. 應該在我們之前配置的[專用子網](#subnets)之一中的單獨 EC2 實例上啟用和配置它.
讓我們創建一個安裝 Gitaly 的 EC2 實例:
1. 在 EC2 儀表板中,單擊**啟動實例** .
2. 選擇一個 AMI. 在此示例中,我們將選擇**Ubuntu Server 18.04 LTS(HVM),SSD Volume Type** .
3. Choose an instance type. We’ll pick a **c5.xlarge**.
4. Click **配置實例詳細信息**.
1. 在" **網絡"**下拉列表中,選擇`gitlab-vpc` ,這是我們之前創建的 VPC.
2. 在" **子網"**下拉列表中,從我們先前創建的**子網**列表中選擇`gitlab-private-10.0.1.0` .
3. 仔細檢查是否將" **自動分配公用 IP"**設置為" `Use subnet setting (Disable)` .
4. Click **添加存儲**.
5. 將根卷大小增加到`20 GiB` ,并將**卷類型**更改為`Provisoned IOPS SSD (io1)` . (這是一個任意大小.創建一個足以滿足您的存儲庫存儲需求的卷.)
1. 對于**IOPS**設置`1000` (20 GiB x 50 IOPS). 每個 GiB 最多可以配置 50 IOPS. 如果選擇更大的音量,請相應地增加 IOPS. 以串行方式寫入許多小文件的工作負載(如`git` )需要高性能的存儲,因此選擇`Provisoned IOPS SSD (io1)` .
6. 單擊**添加標簽**并添加您的標簽. 在本例中,我們將僅設置`Key: Name`和`Value: Gitaly` .
7. 單擊" **配置安全組",**然后**創建一個新的安全組** .
1. 給您的安全組一個名稱和描述. 我們將同時使用`gitlab-gitaly-sec-group` .
2. 創建一個**自定義 TCP**規則,并將端口`8075`添加到" **端口范圍"中** . 對于**Source** ,選擇`gitlab-loadbalancer-sec-group` .
3. 還要從`bastion-sec-group`添加 SSH 的入站規則,以便我們可以使用來自堡壘主機的[SSH 代理轉發](#use-ssh-agent-forwarding)進行連接.
8. 如果對設置滿意,請單擊**查看并啟動,**然后單擊**啟動** .
9. 最后,確認您有權訪問所選的私鑰文件或創建一個新的私鑰文件. 單擊**啟動實例** .
**注意:**除了將配置*和*存儲庫數據存儲在根卷上之外,您還可以選擇添加其他 EBS 卷用于存儲庫存儲. 請遵循上述相同的指導. 請參閱[Amazon EBS 定價](https://aws.amazon.com/ebs/pricing/) . 我們不建議使用 EFS,因為它可能會對 GitLab 的性能產生負面影響. 您可以查看[相關文檔](../../administration/high_availability/nfs.html#avoid-using-awss-elastic-file-system-efs)以了解更多詳細信息.
現在我們已經準備好我們的 EC2 實例,請按照[文檔安裝 GitLab 并在其自己的服務器上設置 Gitaly](../../administration/gitaly/index.html#run-gitaly-on-its-own-server) . 在[我們](#install-gitlab)上面[創建](#install-gitlab)的[GitLab 實例](#install-gitlab)上,從該文檔執行客戶端設置步驟.
#### Add Support for Proxied SSL[](#add-support-for-proxied-ssl "Permalink")
當我們在[負載均衡器](#load-balancer)處終止 SSL 時,請按照[支持代理的 SSL 中](https://docs.gitlab.com/omnibus/settings/nginx.html)的步驟在`/etc/gitlab/gitlab.rb`進行配置.
將更改保存到`gitlab.rb`文件后,切記要運行`sudo gitlab-ctl reconfigure` .
#### Fast lookup of authorized SSH keys[](#fast-lookup-of-authorized-ssh-keys "Permalink")
允許訪問 GitLab 的用戶的公共 SSH 密鑰存儲在`/var/opt/gitlab/.ssh/authorized_keys` . 通常,我們會使用共享存儲,以便當用戶通過 SSH 執行 Git 操作時,所有實例都能夠訪問該文件. 由于我們的設置中沒有共享存儲,因此我們將更新配置,以通過 GitLab 數據庫中的索引查找來授權 SSH 用戶.
按照[通過 GitLab Shell 設置快速查找中](../../administration/operations/fast_ssh_key_lookup.html#setting-up-fast-lookup-via-gitlab-shell)的說明,從使用`authorized_keys`文件切換到數據庫.
如果不配置快速查找,則通過 SSH 進行的 Git 操作將導致以下錯誤:
```
Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
```
#### Configure host keys[](#configure-host-keys "Permalink")
通常,我們將手動將主應用程序服務器上`/etc/ssh/`的內容(主密鑰和公共密鑰)復制到所有輔助服務器上的`/etc/ssh` . 這樣可以防止在訪問負載均衡器后面的群集中的服務器時出現虛假的中間人攻擊警報.
我們將通過創建靜態主機密鑰作為自定義 AMI 的一部分來自動執行此操作. 由于每次 EC2 實例啟動時也會旋轉這些主機密鑰,因此將它們"硬編碼"到我們的自定義 AMI 中是一種方便的解決方法.
在您的 GitLab 實例上運行以下命令:
```
sudo mkdir /etc/ssh_static
sudo cp -R /etc/ssh/* /etc/ssh_static
```
在`/etc/ssh/sshd_config`更新以下內容:
```
# HostKeys for protocol version 2
HostKey /etc/ssh_static/ssh_host_rsa_key
HostKey /etc/ssh_static/ssh_host_dsa_key
HostKey /etc/ssh_static/ssh_host_ecdsa_key
HostKey /etc/ssh_static/ssh_host_ed25519_key
```
#### Amazon S3 object storage[](#amazon-s3-object-storage "Permalink")
由于我們不使用 NFS 進行共享存儲,因此我們將使用[Amazon S3](https://aws.amazon.com/s3/)存儲桶來存儲備份,工件,LFS 對象,上傳,合并請求差異,容器注冊表映像等等. 我們的文檔包括[有關如何](../../administration/object_storage.html)為每種數據類型[配置對象存儲的說明](../../administration/object_storage.html) ,以及有關在 GitLab 中使用對象存儲的其他信息.
**注意:**由于我們使用的是之前創建的[AWS IAM 配置文件](#create-an-iam-role) ,因此在配置對象存儲時,請確保省略 AWS 訪問密鑰和秘密訪問密鑰/值對. 而是在您的配置中使用`'use_iam_profile' => true` ,如上面鏈接的對象存儲文檔中所示.
將更改保存到`gitlab.rb`文件后,切記要運行`sudo gitlab-ctl reconfigure` .
**注意:** GitLab 的當前一項功能仍需要共享目錄(NFS),即[GitLab Pages](../../user/project/pages/index.html) . 目前[正在進行的工作](https://gitlab.com/gitlab-org/gitlab-pages/-/issues/196) ,以消除支持 GitLab 頁面需要 NFS.
* * *
到此,我們的 GitLab 實例的配置更改結束了. 接下來,我們將基于該實例創建自定義 AMI,以用于我們的啟動配置和自動縮放組.
### Create custom AMI[](#create-custom-ami "Permalink")
在 EC2 儀表板上:
1. 選擇我們[之前創建](#install-gitlab)的`GitLab`實例.
2. 單擊" **操作"** ,向下滾動到" **圖像"** ,然后單擊" **創建圖像"** .
3. 給您的圖像起一個名稱和描述(我們將同時使用`GitLab-Source` ).
4. 將其他所有內容保留為默認值,然后單擊**創建圖像**
現在,我們有了一個定制的 AMI,將用于下一步創建啟動配置.
## Deploy GitLab inside an auto scaling group[](#deploy-gitlab-inside-an-auto-scaling-group "Permalink")
### Create a launch configuration[](#create-a-launch-configuration "Permalink")
從 EC2 儀表板:
1. 從左側菜單中選擇**啟動配置** ,然后單擊**創建啟動配置** .
2. 從左側菜單中選擇**我的 AMI** ,然后選擇我們在上面創建的`GitLab`自定義 AMI.
3. 選擇最適合您需求的實例類型(至少為`c5.xlarge` ),然后單擊**配置詳細信息** .
4. 輸入啟動配置的名稱(我們將使用`gitlab-ha-launch-config` ).
5. **不要** check **請求競價型實例**.
6. 從**IAM 角色**下拉列表中,選擇我們[之前創建](#create-an-iam-ec2-instance-role-and-profile)的`GitLabAdmin`實例角色.
7. 將其余的保留為默認值,然后單擊" **添加存儲"** .
8. 默認情況下,根卷為 8GiB,并且在我們不會在其中存儲任何數據的情況下,根卷應該足夠. 單擊**配置安全組** .
9. 選中**選擇和現有安全組,**然后選擇我們之前創建的`gitlab-loadbalancer-sec-group` .
10. 點擊**查看** ,查看您的更改,然后點擊**創建啟動配置** .
11. 確認您有權訪問私鑰或創建一個新私鑰. 單擊**創建啟動配置** .
### Create an auto scaling group[](#create-an-auto-scaling-group "Permalink")
1. 創建啟動配置后,您將看到一個**使用此啟動配置創建 Auto Scaling 組**的選項. 單擊以開始創建自動縮放組.
2. 輸入一個**組名** (我們將使用`gitlab-auto-scaling-group` ).
3. 對于**Group size** ,輸入您要開始的實例數(我們將輸入`2` ).
4. 從" **網絡"**下拉列表中選擇`gitlab-vpc` .
5. 添加[我們先前創建的](#subnets)兩個專用[子網](#subnets) .
6. 展開" **高級詳細信息"**部分,然后選中" **從一個或多個負載平衡器接收流量"**選項.
7. 從**經典負載均衡器**下拉列表中,選擇我們之前創建的負載均衡器.
8. For **健康檢查類型**, select **ELB**.
9. 我們將" **健康檢查寬限期"**保留為默認的`300`秒. 單擊" **配置擴展策略"** .
10. Check **使用擴展策略來調整該組的容量**.
11. 對于該組,我們將在 2 到 4 個實例之間擴展,如果 CPU 利用率大于 60%將添加一個實例,如果 CPU 利用率小于 45%則刪除一個實例.
[](img/policies.png)
1. 最后,根據需要配置通知和標簽,查看更改并創建自動縮放組.
創建自動伸縮組后,您將在 EC2 儀表板中看到新實例. 您還將看到新實例添加到您的負載均衡器. 一旦實例通過健康檢查,它們就準備開始從負載平衡器接收流量.
由于我們的實例是由自動縮放組創建的,因此請返回您的實例并終止[我們在上面手動創建](#install-gitlab)的[實例](#install-gitlab) . 我們只需要該實例即可創建我們的自定義 AMI.
### Log in for the first time[](#log-in-for-the-first-time "Permalink")
現在,使用[為負載均衡器](#configure-dns-for-load-balancer)設置[DNS](#configure-dns-for-load-balancer)時使用的域名,您現在應該能夠在瀏覽器中訪問 GitLab. 首次要求您為在 GitLab 實例上具有管理員權限的`root`用戶設置密碼.
設置后,使用用戶名`root`和新創建的密碼登錄.
## Health check and monitoring with Prometheus[](#health-check-and-monitoring-with-prometheus "Permalink")
除了可以在各種服務上啟用的 Amazon Cloudwatch 之外,GitLab 還提供了自己的基于 Prometheus 的集成監控解決方案. 有關如何設置的更多信息,請訪問[GitLab Prometheus 文檔.](../../administration/monitoring/prometheus/index.html)
GitLab 還具有各種[運行狀況檢查端點](../../user/admin_area/monitoring/health_check.html) ,您可以對其進行 ping 操作并獲取報告.
## GitLab Runners[](#gitlab-runners "Permalink")
如果要利用[GitLab CI / CD](../../ci/README.html) ,則必須至少設置一個[GitLab Runner](https://docs.gitlab.com/runner/) .
閱讀有關[在 AWS](https://docs.gitlab.com/runner/configuration/runner_autoscale_aws/)上配置[自動縮放 GitLab Runner 的](https://docs.gitlab.com/runner/configuration/runner_autoscale_aws/)更多信息.
## Backup and restore[](#backup-and-restore "Permalink")
GitLab 提供[了一個備份](../../raketasks/backup_restore.html#back-up-gitlab)和還原其 Git 數據,數據庫,附件,LFS 對象等的工具.
一些重要的事情要知道:
* 備份/還原工具**不**存儲某些配置文件,例如機密. 您需要[自己配置](../../raketasks/backup_restore.html#storing-configuration-files) .
* 默認情況下,備份文件存儲在本地,但是您可以[使用 S3 備份 GitLab](../../raketasks/backup_restore.html#using-amazon-s3) .
* 您可以[從備份中排除特定目錄](../../raketasks/backup_restore.html#excluding-specific-directories-from-the-backup) .
### Backing up GitLab[](#backing-up-gitlab "Permalink")
備份 GitLab:
1. SSH 進入您的實例.
2. 備份:
```
sudo gitlab-backup create
```
**注意:**對于 GitLab 12.1 和更早版本,請使用`gitlab-rake gitlab:backup:create` .
### Restoring GitLab from a backup[](#restoring-gitlab-from-a-backup "Permalink")
To restore GitLab, first review the [restore documentation](../../raketasks/backup_restore.html#restore-gitlab), and primarily the restore prerequisites. Then, follow the steps under the [Omnibus installations section](../../raketasks/backup_restore.html#restore-for-omnibus-gitlab-installations).
## Updating GitLab[](#updating-gitlab "Permalink")
GitLab 于 22 日每月發布一個新版本. 每當發布新版本時,您都可以更新您的 GitLab 實例:
1. SSH 進入您的實例
2. 備份:
```
sudo gitlab-backup create
```
**注意:**對于 GitLab 12.1 和更早版本,請使用`gitlab-rake gitlab:backup:create` .
1. 更新存儲庫并安裝 GitLab:
```
sudo apt update
sudo apt install gitlab-ee
```
幾分鐘后,新版本應已啟動并正在運行.
## Conclusion[](#conclusion "Permalink")
在本指南中,我們主要進行了縮放和一些冗余選項,您的里程可能會有所不同.
請記住,所有解決方案都需要在成本/復雜性和正常運行時間之間進行權衡. 您想要的正常運行時間越長,解決方案就越復雜. 解決方案越復雜,設置和維護該解決方案所涉及的工作就越多.
通讀以下其他資源,并隨時[提出問題](https://gitlab.com/gitlab-org/gitlab/-/issues/new)以請求其他材料:
* [擴展 GitLab](../../administration/reference_architectures/index.html) :GitLab 支持幾種不同類型的集群.
* [Geo 復制](../../administration/geo/replication/index.html) :Geo 是面向廣泛分布的開發團隊的解決方案.
* [Omnibus GitLab-](https://docs.gitlab.com/omnibus/)您需要了解的有關管理 GitLab 實例的所有信息.
* [上載許可證](../../user/admin_area/license.html) : [使用許可證](../../user/admin_area/license.html)激活所有的 GitLab Enterprise Edition 功能.
* [定價](https://about.gitlab.com/pricing/) :不同層級的定價.
## Troubleshooting[](#troubleshooting "Permalink")
### Instances are failing health checks[](#instances-are-failing-health-checks "Permalink")
如果您的實例未通過負載均衡器的運行狀況檢查,請驗證它們是否從我們之前配置的運行狀況檢查終結點返回狀態`200` . 任何其他狀態,包括重定向(例如狀態`302` ),都會導致運行狀況檢查失敗.
您可能必須在`root`用戶上設置密碼,以防止在運行狀況檢查通過之前在登錄端點上進行自動重定向.
### “The change you requested was rejected (422)”[](#the-change-you-requested-was-rejected-422 "Permalink")
如果你看到這個頁面,試圖設置通過網絡界面輸入密碼時,請確保`external_url`在`gitlab.rb`你正在從一個請求域,并運行匹配`sudo gitlab-ctl reconfigure`進行任何更改之后.
- GitLab Docs
- Installation
- Requirements
- GitLab cloud native Helm Chart
- Install GitLab with Docker
- Installation from source
- Install GitLab on Microsoft Azure
- Installing GitLab on Google Cloud Platform
- Installing GitLab on Amazon Web Services (AWS)
- Analytics
- Code Review Analytics
- Productivity Analytics
- Value Stream Analytics
- Kubernetes clusters
- Adding and removing Kubernetes clusters
- Adding EKS clusters
- Adding GKE clusters
- Group-level Kubernetes clusters
- Instance-level Kubernetes clusters
- Canary Deployments
- Cluster Environments
- Deploy Boards
- GitLab Managed Apps
- Crossplane configuration
- Cluster management project (alpha)
- Kubernetes Logs
- Runbooks
- Serverless
- Deploying AWS Lambda function using GitLab CI/CD
- Securing your deployed applications
- Groups
- Contribution Analytics
- Custom group-level project templates
- Epics
- Manage epics
- Group Import/Export
- Insights
- Issues Analytics
- Iterations
- Public access
- SAML SSO for GitLab.com groups
- SCIM provisioning using SAML SSO for GitLab.com groups
- Subgroups
- Roadmap
- Projects
- GitLab Secure
- Security Configuration
- Container Scanning
- Dependency Scanning
- Dependency List
- Static Application Security Testing (SAST)
- Secret Detection
- Dynamic Application Security Testing (DAST)
- GitLab Security Dashboard
- Offline environments
- Standalone Vulnerability pages
- Security scanner integration
- Badges
- Bulk editing issues and merge requests at the project level
- Code Owners
- Compliance
- License Compliance
- Compliance Dashboard
- Create a project
- Description templates
- Deploy Keys
- Deploy Tokens
- File finder
- Project integrations
- Integrations
- Atlassian Bamboo CI Service
- Bugzilla Service
- Custom Issue Tracker service
- Discord Notifications service
- Enabling emails on push
- GitHub project integration
- Hangouts Chat service
- Atlassian HipChat
- Irker IRC Gateway
- GitLab Jira integration
- Mattermost Notifications Service
- Mattermost slash commands
- Microsoft Teams service
- Mock CI Service
- Prometheus integration
- Redmine Service
- Slack Notifications Service
- Slack slash commands
- GitLab Slack application
- Webhooks
- YouTrack Service
- Insights
- Issues
- Crosslinking Issues
- Design Management
- Confidential issues
- Due dates
- Issue Boards
- Issue Data and Actions
- Labels
- Managing issues
- Milestones
- Multiple Assignees for Issues
- Related issues
- Service Desk
- Sorting and ordering issue lists
- Issue weight
- Associate a Zoom meeting with an issue
- Merge requests
- Allow collaboration on merge requests across forks
- Merge Request Approvals
- Browser Performance Testing
- How to create a merge request
- Cherry-pick changes
- Code Quality
- Load Performance Testing
- Merge Request dependencies
- Fast-forward merge requests
- Merge when pipeline succeeds
- Merge request conflict resolution
- Reverting changes
- Reviewing and managing merge requests
- Squash and merge
- Merge requests versions
- Draft merge requests
- Members of a project
- Migrating projects to a GitLab instance
- Import your project from Bitbucket Cloud to GitLab
- Import your project from Bitbucket Server to GitLab
- Migrating from ClearCase
- Migrating from CVS
- Import your project from FogBugz to GitLab
- Gemnasium
- Import your project from GitHub to GitLab
- Project importing from GitLab.com to your private GitLab instance
- Import your project from Gitea to GitLab
- Import your Jira project issues to GitLab
- Migrating from Perforce Helix
- Import Phabricator tasks into a GitLab project
- Import multiple repositories by uploading a manifest file
- Import project from repo by URL
- Migrating from SVN to GitLab
- Migrating from TFVC to Git
- Push Options
- Releases
- Repository
- Branches
- Git Attributes
- File Locking
- Git file blame
- Git file history
- Repository mirroring
- Protected branches
- Protected tags
- Push Rules
- Reduce repository size
- Signing commits with GPG
- Syntax Highlighting
- GitLab Web Editor
- Web IDE
- Requirements Management
- Project settings
- Project import/export
- Project access tokens (Alpha)
- Share Projects with other Groups
- Snippets
- Static Site Editor
- Wiki
- Project operations
- Monitor metrics for your CI/CD environment
- Set up alerts for Prometheus metrics
- Embedding metric charts within GitLab-flavored Markdown
- Embedding Grafana charts
- Using the Metrics Dashboard
- Dashboard YAML properties
- Metrics dashboard settings
- Panel types for dashboards
- Using Variables
- Templating variables for metrics dashboards
- Prometheus Metrics library
- Monitoring AWS Resources
- Monitoring HAProxy
- Monitoring Kubernetes
- Monitoring NGINX
- Monitoring NGINX Ingress Controller
- Monitoring NGINX Ingress Controller with VTS metrics
- Alert Management
- Error Tracking
- Tracing
- Incident Management
- GitLab Status Page
- Feature Flags
- GitLab CI/CD
- GitLab CI/CD pipeline configuration reference
- GitLab CI/CD include examples
- Introduction to CI/CD with GitLab
- Getting started with GitLab CI/CD
- How to enable or disable GitLab CI/CD
- Using SSH keys with GitLab CI/CD
- Migrating from CircleCI
- Migrating from Jenkins
- Auto DevOps
- Getting started with Auto DevOps
- Requirements for Auto DevOps
- Customizing Auto DevOps
- Stages of Auto DevOps
- Upgrading PostgreSQL for Auto DevOps
- Cache dependencies in GitLab CI/CD
- GitLab ChatOps
- Cloud deployment
- Docker integration
- Building Docker images with GitLab CI/CD
- Using Docker images
- Building images with kaniko and GitLab CI/CD
- GitLab CI/CD environment variables
- Predefined environment variables reference
- Where variables can be used
- Deprecated GitLab CI/CD variables
- Environments and deployments
- Protected Environments
- GitLab CI/CD Examples
- Test a Clojure application with GitLab CI/CD
- Using Dpl as deployment tool
- Testing a Phoenix application with GitLab CI/CD
- End-to-end testing with GitLab CI/CD and WebdriverIO
- DevOps and Game Dev with GitLab CI/CD
- Deploy a Spring Boot application to Cloud Foundry with GitLab CI/CD
- How to deploy Maven projects to Artifactory with GitLab CI/CD
- Testing PHP projects
- Running Composer and NPM scripts with deployment via SCP in GitLab CI/CD
- Test and deploy Laravel applications with GitLab CI/CD and Envoy
- Test and deploy a Python application with GitLab CI/CD
- Test and deploy a Ruby application with GitLab CI/CD
- Test and deploy a Scala application to Heroku
- GitLab CI/CD for external repositories
- Using GitLab CI/CD with a Bitbucket Cloud repository
- Using GitLab CI/CD with a GitHub repository
- GitLab Pages
- GitLab Pages
- GitLab Pages domain names, URLs, and baseurls
- Create a GitLab Pages website from scratch
- Custom domains and SSL/TLS Certificates
- GitLab Pages integration with Let's Encrypt
- GitLab Pages Access Control
- Exploring GitLab Pages
- Incremental Rollouts with GitLab CI/CD
- Interactive Web Terminals
- Optimizing GitLab for large repositories
- Metrics Reports
- CI/CD pipelines
- Pipeline Architecture
- Directed Acyclic Graph
- Multi-project pipelines
- Parent-child pipelines
- Pipelines for Merge Requests
- Pipelines for Merged Results
- Merge Trains
- Job artifacts
- Pipeline schedules
- Pipeline settings
- Triggering pipelines through the API
- Review Apps
- Configuring GitLab Runners
- GitLab CI services examples
- Using MySQL
- Using PostgreSQL
- Using Redis
- Troubleshooting CI/CD
- GitLab Package Registry
- GitLab Container Registry
- Dependency Proxy
- GitLab Composer Repository
- GitLab Conan Repository
- GitLab Maven Repository
- GitLab NPM Registry
- GitLab NuGet Repository
- GitLab PyPi Repository
- API Docs
- API resources
- .gitignore API
- GitLab CI YMLs API
- Group and project access requests API
- Appearance API
- Applications API
- Audit Events API
- Avatar API
- Award Emoji API
- Project badges API
- Group badges API
- Branches API
- Broadcast Messages API
- Project clusters API
- Group clusters API
- Instance clusters API
- Commits API
- Container Registry API
- Custom Attributes API
- Dashboard annotations API
- Dependencies API
- Deploy Keys API
- Deployments API
- Discussions API
- Dockerfiles API
- Environments API
- Epics API
- Events
- Feature Flags API
- Feature flag user lists API
- Freeze Periods API
- Geo Nodes API
- Group Activity Analytics API
- Groups API
- Import API
- Issue Boards API
- Group Issue Boards API
- Issues API
- Epic Issues API
- Issues Statistics API
- Jobs API
- Keys API
- Labels API
- Group Labels API
- License
- Licenses API
- Issue links API
- Epic Links API
- Managed Licenses API
- Markdown API
- Group and project members API
- Merge request approvals API
- Merge requests API
- Project milestones API
- Group milestones API
- Namespaces API
- Notes API
- Notification settings API
- Packages API
- Pages domains API
- Pipeline schedules API
- Pipeline triggers API
- Pipelines API
- Project Aliases API
- Project import/export API
- Project repository storage moves API
- Project statistics API
- Project templates API
- Projects API
- Protected branches API
- Protected tags API
- Releases API
- Release links API
- Repositories API
- Repository files API
- Repository submodules API
- Resource label events API
- Resource milestone events API
- Resource weight events API
- Runners API
- SCIM API
- Search API
- Services API
- Application settings API
- Sidekiq Metrics API
- Snippets API
- Project snippets
- Application statistics API
- Suggest Changes API
- System hooks API
- Tags API
- Todos API
- Users API
- Project-level Variables API
- Group-level Variables API
- Version API
- Vulnerabilities API
- Vulnerability Findings API
- Wikis API
- GraphQL API
- Getting started with GitLab GraphQL API
- GraphQL API Resources
- API V3 to API V4
- Validate the .gitlab-ci.yml (API)
- User Docs
- Abuse reports
- User account
- Active sessions
- Deleting a User account
- Permissions
- Personal access tokens
- Profile preferences
- Threads
- GitLab and SSH keys
- GitLab integrations
- Git
- GitLab.com settings
- Infrastructure as code with Terraform and GitLab
- GitLab keyboard shortcuts
- GitLab Markdown
- AsciiDoc
- GitLab Notification Emails
- GitLab Quick Actions
- Autocomplete characters
- Reserved project and group names
- Search through GitLab
- Advanced Global Search
- Advanced Syntax Search
- Time Tracking
- GitLab To-Do List
- Administrator Docs
- Reference architectures
- Reference architecture: up to 1,000 users
- Reference architecture: up to 2,000 users
- Reference architecture: up to 3,000 users
- Reference architecture: up to 5,000 users
- Reference architecture: up to 10,000 users
- Reference architecture: up to 25,000 users
- Reference architecture: up to 50,000 users
- Troubleshooting a reference architecture set up
- Working with the bundled Consul service
- Configuring PostgreSQL for scaling
- Configuring GitLab application (Rails)
- Load Balancer for multi-node GitLab
- Configuring a Monitoring node for Scaling and High Availability
- NFS
- Working with the bundled PgBouncer service
- Configuring Redis for scaling
- Configuring Sidekiq
- Admin Area settings
- Continuous Integration and Deployment Admin settings
- Custom instance-level project templates
- Diff limits administration
- Enable and disable GitLab features deployed behind feature flags
- Geo nodes Admin Area
- GitLab Pages administration
- Health Check
- Job logs
- Labels administration
- Log system
- PlantUML & GitLab
- Repository checks
- Repository storage paths
- Repository storage types
- Account and limit settings
- Service templates
- System hooks
- Changing your time zone
- Uploads administration
- Abuse reports
- Activating and deactivating users
- Audit Events
- Blocking and unblocking users
- Broadcast Messages
- Elasticsearch integration
- Gitaly
- Gitaly Cluster
- Gitaly reference
- Monitoring GitLab
- Monitoring GitLab with Prometheus
- Performance Bar
- Usage statistics
- Object Storage
- Performing Operations in GitLab
- Cleaning up stale Redis sessions
- Fast lookup of authorized SSH keys in the database
- Filesystem Performance Benchmarking
- Moving repositories managed by GitLab
- Run multiple Sidekiq processes
- Sidekiq MemoryKiller
- Switching to Puma
- Understanding Unicorn and unicorn-worker-killer
- User lookup via OpenSSH's AuthorizedPrincipalsCommand
- GitLab Package Registry administration
- GitLab Container Registry administration
- Replication (Geo)
- Geo database replication
- Geo with external PostgreSQL instances
- Geo configuration
- Using a Geo Server
- Updating the Geo nodes
- Geo with Object storage
- Docker Registry for a secondary node
- Geo for multiple nodes
- Geo security review (Q&A)
- Location-aware Git remote URL with AWS Route53
- Tuning Geo
- Removing secondary Geo nodes
- Geo data types support
- Geo Frequently Asked Questions
- Geo Troubleshooting
- Geo validation tests
- Disaster Recovery (Geo)
- Disaster recovery for planned failover
- Bring a demoted primary node back online
- Automatic background verification
- Rake tasks
- Back up and restore GitLab
- Clean up
- Namespaces
- Maintenance Rake tasks
- Geo Rake Tasks
- GitHub import
- Import bare repositories
- Integrity check Rake task
- LDAP Rake tasks
- Listing repository directories
- Praefect Rake tasks
- Project import/export administration
- Repository storage Rake tasks
- Generate sample Prometheus data
- Uploads migrate Rake tasks
- Uploads sanitize Rake tasks
- User management
- Webhooks administration
- X.509 signatures
- Server hooks
- Static objects external storage
- Updating GitLab
- GitLab release and maintenance policy
- Security
- Password Storage
- Custom password length limits
- Restrict allowed SSH key technologies and minimum length
- Rate limits
- Webhooks and insecure internal web services
- Information exclusivity
- How to reset your root password
- How to unlock a locked user from the command line
- User File Uploads
- How we manage the TLS protocol CRIME vulnerability
- User email confirmation at sign-up
- Security of running jobs
- Proxying assets
- CI/CD Environment Variables
- Contributor and Development Docs
- Contribute to GitLab
- Community members & roles
- Implement design & UI elements
- Issues workflow
- Merge requests workflow
- Code Review Guidelines
- Style guides
- GitLab Architecture Overview
- CI/CD development documentation
- Database guides
- Database Review Guidelines
- Database Review Guidelines
- Migration Style Guide
- What requires downtime?
- Understanding EXPLAIN plans
- Rake tasks for developers
- Mass inserting Rails models
- GitLab Documentation guidelines
- Documentation Style Guide
- Documentation structure and template
- Documentation process
- Documentation site architecture
- Global navigation
- GitLab Docs monthly release process
- Telemetry Guide
- Usage Ping Guide
- Snowplow Guide
- Experiment Guide
- Feature flags in development of GitLab
- Feature flags process
- Developing with feature flags
- Feature flag controls
- Document features deployed behind feature flags
- Frontend Development Guidelines
- Accessibility & Readability
- Ajax
- Architecture
- Axios
- Design Patterns
- Frontend Development Process
- DropLab
- Emojis
- Filter
- Frontend FAQ
- GraphQL
- Icons and SVG Illustrations
- InputSetter
- Performance
- Principles
- Security
- Tooling
- Vuex
- Vue
- Geo (development)
- Geo self-service framework (alpha)
- Gitaly developers guide
- GitLab development style guides
- API style guide
- Go standards and style guidelines
- GraphQL API style guide
- Guidelines for shell commands in the GitLab codebase
- HTML style guide
- JavaScript style guide
- Migration Style Guide
- Newlines style guide
- Python Development Guidelines
- SCSS style guide
- Shell scripting standards and style guidelines
- Sidekiq debugging
- Sidekiq Style Guide
- SQL Query Guidelines
- Vue.js style guide
- Instrumenting Ruby code
- Testing standards and style guidelines
- Flaky tests
- Frontend testing standards and style guidelines
- GitLab tests in the Continuous Integration (CI) context
- Review Apps
- Smoke Tests
- Testing best practices
- Testing levels
- Testing Rails migrations at GitLab
- Testing Rake tasks
- End-to-end Testing
- Beginner's guide to writing end-to-end tests
- End-to-end testing Best Practices
- Dynamic Element Validation
- Flows in GitLab QA
- Page objects in GitLab QA
- Resource class in GitLab QA
- Style guide for writing end-to-end tests
- Testing with feature flags
- Translate GitLab to your language
- Internationalization for GitLab
- Translating GitLab
- Proofread Translations
- Merging translations from CrowdIn
- Value Stream Analytics development guide
- GitLab subscription
- Activate GitLab EE with a license