프로덕션 수준의 GitLab 시작하기
- 프로덕션 수준의 리눅스 패키지 설치 시작하기
- 프로덕션 수준의 클라우드 네이티브 하이브리드 GitLab 시작하기
소개
요구 사항
AWS 비용
- IAM 정책 생성
- IAM 역할 생성
네트워크 구성
로드 밸런서
- 로드 밸런서를 위한 DNS 구성
RDS와 함께 PostgreSQL
Redis with ElastiCache
베스천 호스트 설정
GitLab 설치 및 사용자 정의 AMI 생성
자동 스케일링 그룹 내에서 GitLab 배포
- 런치 구성 생성
- 자동 스케일링 그룹 생성
Prometheus를 사용한 상태 체크 및 모니터링
GitLab Runner
백업 및 복원
- GitLab 백업
- 백업에서 GitLab 복원
GitLab 업데이트
공식 GitLab 생성 AMI ID 검색
결론
문제 해결

Amazon Web Services(AWS)에서 GitLab POC 설치

Tier: Free, Premium, Ultimate Offering: Self-managed

이 페이지는 AWS에서 공식 Linux 패키지를 사용하여 GitLab의 일반적인 구성 방법을 안내합니다. 여러분은 필요에 맞게 사용자 정의해야 합니다.

::노트:: 1,000명 이하의 조직을 위한 권장 AWS 설치 방법은 EC2 단일 박스 Linux package installation을 시작하고 데이터를 백업하기 위해 스냅샷 전략을 구현하는 것입니다. 자세한 내용은 1,000 user reference architecture를 참조하세요.

프로덕션 수준의 GitLab 시작하기

::노트:: 이 문서는 개념 증명 인스턴스의 설치 가이드입니다. 이것은 참조 아키텍처가 아니며, 고가용성 구성으로 이어지지 않습니다.

이 안내서를 정확하게 따르면 2K 참조 아키텍처의 비 고가용성(Non-HA) 두 가용 영역 구현의 축소된 버전에 대략적으로 해당하는 개념 증명 인스턴스가 생성됩니다. 2K 참조 아키텍처는 비 고가용성 구성이 아니며 주로 비용과 복잡성을 낮추면서 일부 확장을 제공하기 위한 것입니다. 3000 User Reference Architecture는 GitLab HA인 가장 작은 크기입니다. HA를 달성하기 위한 추가 서비스 역할이 있으며, 특히 Git 리포지터리 저장을 위한 HA를 달성하기 위해 Gitaly 클러스터를 사용하고 삼중 장애 조치를 지정합니다.

GitLab은 주로 두 가지 참조 아키텍처 유형을 유지 및 테스트합니다. 리눅스 패키지 아키텍처는 인스턴스 컴퓨팅에 구현되며 클라우드 네이티브 하이브리드 아키텍처는 Kubernetes 클러스터의 사용을 극대화합니다. 클라우드 네이티브 하이브리드 참조 아키텍처 사양은 리눅스 패키지 아키텍처를 설명하는 참조 아키텍처 크기 페이지의 부록 섹션입니다. 예를 들어, 3000 User Cloud Native 참조 아키텍처는 3000 User Reference Architecture 페이지의 Cloud Native Hybrid reference architecture with Helm Charts (alternative) 하위 섹션에 있습니다.

프로덕션 수준의 리눅스 패키지 설치 시작하기

인프라스트럭처 코드 도구 GitLab Environment Tool (GET)은 AWS에서 Linux 패키지를 사용하여 구축하는 최적의 장소입니다. 특히 HA 설정을 타깃팅하는 경우입니다. 모든 것을 자동화하지는 않지만, 복잡한 설정(예: Gitaly Cluster)을 완료합니다. GET는 오픈 소스이므로 누구나 이를 기반으로 빌드하고 개선에 기여할 수 있습니다.

프로덕션 수준의 클라우드 네이티브 하이브리드 GitLab 시작하기

GitLab Environment Toolkit (GET)은 개인의 Terraform과 Ansible 스크립트입니다. 이러한 스크립트는 선택된 클라우드 제공업체에 Linux 패키지 또는 클라우드 네이티브 하이브리드 환경을 배포하는 데 도움이 됩니다. 또한 GitLab 개발자가 GitLab Dedicated에 사용합니다.

GitLab Environment Toolkit을 사용하여 AWS에 클라우드 네이티브 하이브리드 환경을 배포할 수 있습니다. 그러나 이것은 필수가 아닐 수 있으며 모든 유효한 순열을 지원하지 않을 수 있습니다. 그렇지만, 이 스크립트들은 주어진 그대로 제시되며, 이에 따라 적응할 수 있습니다.

소개

우리의 설정에서는 주로 Linux 패키지를 사용하지만, AWS의 네이티브 서비스도 활용합니다. Linux 패키지에 번들로 제공되는 PostgreSQL 및 Redis 대신에 우리는 Amazon RDS와 ElastiCache를 사용합니다.

이 안내서에서는 VPC와 서브넷 설정을 통해 시작하여 RDS와 ElastiCache와 같은 서비스를 통합한 다음 최종적으로 사용자 정의 스케일링 정책이 있는 자동 스케일링 그룹에서 관리하는 멀티 노드 설정을 진행합니다.

요구 사항

AWS와 Amazon EC2에 대한 기본적인 이해 외에도 다음이 필요합니다.

AWS 계정
SSH 키를 생성하거나 업로드하고 SSH를 통해 인스턴스에 연결합니다.(EC2 Key Pairs)
GitLab 인스턴스에 대한 도메인 이름
도메인을 보호하기 위한 SSL/TLS 인증서. 이미 소유하고 있지 않은 경우 AWS Certificate Manager(ACM)에서 무료 공용 SSL/TLS 인증서를 제공할 수 있습니다. 프로덕션된 인증서가 검증되는 데에는 몇 시간이 소요될 수 있습니다. 나중에 지연을 피하기 위해 가능한 한 빨리 인증서를 요청하십시오.

::아키텍처:: 아래는 권장 아키텍처의 다이어그램입니다.

AWS 비용

GitLab은 다음과 같은 AWS 서비스를 사용합니다. 링크를 통해 가격 정보를 확인할 수 있습니다.

EC2: 공유 하드웨어에 배포된 GitLab에 온디맨드 요금이 적용됩니다. 공유 또는 예약 인스턴스에서 GitLab을 실행하려면 EC2 요금 페이지에서 이에 대한 비용 정보를 확인하세요.
S3: GitLab은 백업, 아티팩트 및 LFS 객체를 저장하기 위해 S3를 사용합니다.
ELB: 클래식 로드 밸런서는 GitLab 인스턴스로의 요청을 라우팅하는 데 사용됩니다.
RDS: PostgreSQL을 사용하는 Amazon 관계형 데이터베이스 서비스(가격 페이지)입니다.
ElastiCache: 인-메모리 캐시 환경(가격 페이지)으로 Redis 구성을 제공하는 데 사용됩니다.

IAM EC2 인스턴스 역할 및 프로필 생성

Amazon S3 object storage를 사용하기 때문에 EC2 인스턴스는 우리의 S3 버킷에 대한 읽기, 쓰기, 디렉터리 권한이 있어야 합니다. GitLab 구성에서 AWS 키를 삽입하지 않기 위해, 이 접근 권한을 가진 IAM 역할을 만들어야 합니다. 우리는 IAM 정책을 만들어야 합니다.

IAM 정책 생성

IAM 대시보드로 이동하여 왼쪽 메뉴에서 정책(Policies)을 선택합니다.

정책 생성(Create policy) 을 선택하고, JSON 탭을 선택하여 정책을 추가합니다. 보안 모범 사례를 따르고 _최소한의 특권(least privilege)_을 부여하여 필요한 작업만 수행할 수 있도록 역할에 권한을 부여합니다.

다이어그램에 표시된 대로 S3 버킷 이름에 gl- 접두사를 추가한다고 가정했을 때, 다음 정책을 추가합니다:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:DeleteObject",
                "s3:PutObjectAcl"
            ],
            "Resource": "arn:aws:s3:::gl-*/*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:AbortMultipartUpload",
                "s3:ListMultipartUploadParts",
                "s3:ListBucketMultipartUploads"
            ],
            "Resource": "arn:aws:s3:::gl-*"
        }
    ]
}

정책 검토(Review policy)를 선택하고, 정책에 이름을 지정합니다 (여기서는 gl-s3-policy를 사용) 그리고 정책 생성(Create policy)를 선택합니다.

IAM 역할 생성

여전히 IAM 대시보드에 있는데, 왼쪽 메뉴에서 역할(Roles)을 선택하고, 역할 생성(Create role)을 선택합니다.
AWS 서비스 > EC2를 선택하여 새 역할을 만든 후, 다음: 권한(Next: Permissions)을 선택합니다.
정책 필터에서 위에서 만든 gl-s3-policy를 검색한 후 선택한 다음 태그(Tags)를 선택합니다.
필요한 경우 태그를 추가하고 검토(Review)를 선택합니다.
역할에 이름을 지정합니다 (여기서는 GitLabS3Access를 사용)하고 역할 생성(Create Role)를 선택합니다.

나중에 출시 구성(launch configuration)을 생성할 때 이 역할을 사용합니다.

네트워크 구성

먼저 GitLab 클라우드 인프라를 위한 VPC를 생성한 후 적어도 두 개의 가용 영역(AZ)에서 공개 및 개인 인스턴스를 보유하기 위해 서브넷을 생성합니다. 공개 서브넷에는 라우팅 테이블을 유지하고 연결된 인터넷 게이트웨이가 필요합니다.

가상 사설 클라우드 (VPC) 생성

이제 제어할 수 있는 가상 네트워킹 환경인 VPC를 생성합니다:

Amazon Web Services에 로그인합니다.
왼쪽 메뉴에서 Your VPCs를 선택한 후 VPC 생성(Create VPC)를 선택합니다. “Name tag”에 gitlab-vpc를 입력하고, “IPv4 CIDR 블록”에 10.0.0.0/16를 입력합니다. 전용 하드웨어가 필요하지 않은 경우 기본 설정으로 두십시오. 준비가 되면 예, 생성(Yes, Create)를 선택합니다.
VPC를 선택하고, 작업(Actions)을 선택한 후 DNS 해결 편집(Edit DNS resolution)을 선택하여 DNS 해결을 활성화합니다. 완료되면 저장(Save)를 선택합니다.

서브넷

이제 다른 가용 영역에 서브넷을 생성합니다. 각 서브넷이 방금 생성한 VPC에 연결되어 있고, CIDR 블록이 겹치지 않도록합니다. 이렇게 함으로써 신뢰성을 위해 멀티 AZ를 활성화할 수 있습니다.

로드 밸런서 및 RDS 인스턴스와 일치하도록 공용 및 개인 서브넷을 만듭니다:

왼쪽 메뉴에서 서브넷(Subnets)을 선택합니다.
서브넷 생성(Create subnet)을 선택합니다. IP를 기반으로 서술적인 이름 태그를 붙여준 후, 이전에 생성한 VPC를 선택하고 가용 영역을 선택하고 IPv4 CIDR 블록을 24 서브넷 10.0.0.0/24로 지정합니다.

모든 서브넷을 만들기 위해 동일한 단계를 따릅니다:

이름 태그	유형	가용 영역	CIDR 블록
`gitlab-public-10.0.0.0`	공용	`us-west-2a`	`10.0.0.0/24`
`gitlab-private-10.0.1.0`	개인	`us-west-2a`	`10.0.1.0/24`
`gitlab-public-10.0.2.0`	공용	`us-west-2b`	`10.0.2.0/24`
`gitlab-private-10.0.3.0`	개인	`us-west-2b`	`10.0.3.0/24`

모든 서브넷을 만든 후, 두 개의 공용 서브넷에 대해 IPv4 자동 할당을 활성화하십시오:
1. 각 공용 서브넷을 차례로 선택하고, 작업(Actions)을 선택한 후 자동 할당 IP 설정 수정(Modify auto-assign IP settings)을 선택하여 옵션을 활성화하고 저장합니다.

인터넷 게이트웨이

이제 여전히 같은 대시보드에서, 인터넷 게이트웨이로 이동하여 새로 만듭니다:

왼쪽 메뉴에서 인터넷 게이트웨이(Internet Gateways)를 선택합니다.
인터넷 게이트웨이 생성(Create internet gateway)를 선택하고, gitlab-gateway라는 이름을 지정한 후 생성(Create)을 선택합니다.
테이블에서 선택한 후 작업(Actions) 드롭다운 디렉터리에서 “VPC에 연결(Attach to VPC)”을 선택합니다.
디렉터리에서 gitlab-vpc를 선택하고 연결(Attach)을 선택합니다.

NAT 게이트웨이 작성

개인 서브넷에 배포된 인스턴스는 업데이트를 위해 인터넷에 연결해야하지만 공개 인터넷에서 접근할 수 없어야합니다. 이를 위해 각 공용 서브넷에 배치된 NAT 게이트웨이를 사용합니다:

VPC 대시보드로 이동하여 왼쪽 메뉴에서 NAT 게이트웨이를 선택합니다.
NAT 게이트웨이 생성(Create NAT Gateway)를 선택하고 다음을 완료합니다:
1. 서브넷: 드롭다운 디렉터리에서 gitlab-public-10.0.0.0을 선택합니다.
2. 탄력적 IP 할당 ID(Elastic IP Allocation ID): 기존 탄력적 IP를 입력하거나 새 IP를 할당하기 위해 탄력적 IP 주소 할당(Elastic IP address)를 선택합니다.
3. 필요한 경우 태그를 추가합니다.
4. NAT 게이트웨이 생성(Create NAT Gateway)를 선택합니다.

두 번째 NAT 게이트웨이를 만드십시오. 이번에는 두 번째 공용 서브넷인 gitlab-public-10.0.2.0에 배치합니다.

라우트 테이블

퍼블릭 라우트 테이블

이전 단계에서 생성한 인터넷 게이트웨이를 통해 퍼블릭 서브넷이 인터넷에 연결할 수 있도록 퍼블릭 서브넷을 위한 라우트 테이블을 생성해야 합니다.

VPC 대시보드에서:

왼쪽 메뉴에서 라우트 테이블을 선택합니다.
라우트 테이블 생성을 선택합니다.
“이름 태그”에 gitlab-public을 입력하고 “VPC”에서 gitlab-vpc를 선택합니다.
생성을 선택합니다.

이제 인터넷 게이트웨이를 새 타겟으로 추가하고 어떠한 목적지에서든지 트래픽을 받을 수 있도록 설정해야 합니다.

왼쪽 메뉴에서 라우트 테이블을 선택하고 gitlab-public 라우트를 선택하여 하단에 옵션을 표시합니다.
라우트 탭을 선택한 후, 경로 편집 > 경로 추가를 선택하고 대상열에 이전에 만든 gitlab-gateway를 선택합니다. 완료했으면 경로 저장을 선택합니다.

다음으로 퍼블릭 서브넷을 라우트 테이블에 연결해야 합니다:

서브넷 연결 탭을 선택하고 서브넷 연결 편집을 선택합니다.
공용 서브넷만 확인하고 저장을 선택합니다.

프라이빗 라우트 테이블

각 프라이빗 서브넷의 인스턴스가 해당 가용 영역의 공용 서브넷에있는 NAT 게이트웨이를 통해 인터넷에 연결할 수 있도록 두 개의 프라이빗 라우트 테이블을 생성해야 합니다.

위와 동일한 단계를 따라 두 개의 프라이빗 라우트 테이블을 생성합니다. 이름을 gitlab-private-a 및 gitlab-private-b로 지정합니다.
그런 다음, 각 프라이빗 라우트 테이블에 새 경로를 추가해야 합니다. 목적지는 0.0.0.0/0이고 대상은 이전에 만든 NAT 게이트웨이 중 하나여야 합니다.
1. gitlab-private-a 라우트 테이블의 새 경로에 gitlab-public-10.0.0.0에서 생성한 NAT 게이트웨이를 대상으로 추가합니다.
2. 마찬가지로, gitlab-private-b의 새 경로에 gitlab-public-10.0.2.0에있는 NAT 게이트웨이를 대상으로 추가합니다.
마지막으로 각 프라이빗 서브넷을 해당 프라이빗 라우트 테이블에 연결해야 합니다.
1. gitlab-private-10.0.1.0을 gitlab-private-a에 연결합니다.
2. gitlab-private-10.0.3.0을 gitlab-private-b에 연결합니다.

로드 밸런서

우리는 GitLab 애플리케이션 서버에 들어오는 트래픽을 포트 80 및 443에서 고르게 분산하는 로드 밸런서를 생성합니다. 우리가 나중에 자동 스케일링 그룹을 생성하는 대로 인스턴스가 필요에 따라 로드 밸런서에 추가되거나 제거됩니다. 추가로, 로드 밸런서는 인스턴스에 대한 상태 체크를 수행합니다.

EC2 대시보드에서 왼쪽 네이게이션 바에서 로드 밸런서를 찾습니다:

로드 밸런서 생성을 선택합니다.
1. 클래식 로드 밸런서를 선택합니다.
2. 이름을 지정합니다(여기서는 gitlab-loadbalancer를 사용) 및 내부에 LB 생성 옵션에서 드롭다운 디렉터리에서 gitlab-vpc를 선택합니다.
3. 리스너 섹션에서 다음 리스너를 설정합니다:
  - 로드 밸런서 및 인스턴스 프로토콜 및 포트에 대해 HTTP 포트 80
  - 로드 밸런서 및 인스턴스 프로토콜 및 포트에 대해 TCP 포트 22
  - HTTPS 포트 443에 대해 로드 밸런서 프로토콜과 포트를 설정하고 인스턴스에서 HTTP 포트 80으로 포워딩(나중에 가이드에서 GitLab의 포트 80 리스닝 구성)
4. 서브넷 선택 섹션에서 로드 밸런서가 두 가용 영역으로 트래픽을 경로로 설정하도록 공용 서브넷을 모두 선택합니다.
로드 밸런서에 대한 트래픽을 제어하는 방화벽으로 사용할 보안 그룹을 추가합니다. 보안 그룹 할당을 선택하고 새 보안 그룹 생성을 선택하여 이름을 지정합니다(여기서는 gitlab-loadbalancer-sec-group를 사용) 및 설명을 추가하고 어디서든지(HTTP 및 HTTPS 트래픽에 대해서0.0.0.0/0, ::/0)에서 HTTP 및 HTTPS 트래픽을 허용합니다. 또한 SSH 트래픽을 허용하고 사용자 지정 소스를 선택하고 CIDR 표기법에서 신뢰할 수 있는 단일 IP 주소 또는 IP 주소 범위를 추가합니다. 이로써 사용자가 SSH를 통해 Git 작업을 수행할 수 있습니다.
보안 설정 구성을 선택하고 다음을 설정합니다:
1. ACM에서 SSL/TLS 인증서를 선택하거나 IAM에 인증서를 업로드합니다.
2. Cipher 선택에서 드롭다운 디렉터리에서 사전 정의된 보안 정책을 선택합니다. AWS 문서에서 클래식 로드 밸런서를 위한 사전 정의된 SSL 보안 정책을 확인할 수 있습니다. GitLab 코드베이스에서 지원되는 SSL 암호 및 프로토콜 디렉터리을 확인할 수 있습니다.
상태 체크 구성을 선택하고 EC2 인스턴스에 대한 상태 체크를 설정합니다.
1. 핑 프로토콜에서 HTTP를 선택합니다.
2. 핑 포트에 80을 입력합니다.
3. 핑 경로 - 권장 사항은 준비 상태 확인 엔드포인트를 사용하는 것입니다. VPC IP 주소 범위(CIDR)를 IP 허용 디렉터리에 추가해야 하며 상태 체크 엔드포인트에 대한 공용 IP 주소입니다.
4. 기본 고급 세부 정보를 유지하거나 필요에 따라 조정합니다.
EC2 인스턴스 추가 - 우리가 나중에 인스턴스를 관리하기 위해 자동 스케일링 그룹을 생성하기로 했으므로 아무것도 추가하지 않습니다.
태그 추가 및 필요한 태그를 추가합니다.
검토 및 생성을 선택하고 모든 설정을 검토한 후, 행복하다면 생성을 선택합니다.

로드 밸런서가 작동한 후에 보안 그룹을 검토하여 ELB를 통한 액세스 및 기타 요구 사항을 다듬을 수 있습니다.

로드 밸런서를 위한 DNS 구성

Route 53 대시 보드에서 왼쪽 탐색 모음에서 호스팅된 영역을 선택합니다:

기존 호스팅된 영역을 선택하거나, 도메인을 위해 이미 영역을 보유하고 있지 않은 경우 호스팅 영역 생성을 선택하고 도메인 이름을 입력한 후 생성을 선택합니다.
레코드 집합 생성을 선택하고 다음 값을 제공합니다:
1. 이름: 도메인 이름(기본값) 또는 서브도메인을 입력합니다.
2. 유형: A - IPv4 주소를 선택합니다.
3. 에일리어스: 기본값은 아니요입니다. 예를 선택합니다.
4. 에일리어스 대상: ELB 클래식 로드 밸런서 섹션에서 앞에서 생성한 클래식 로드 밸런서를 찾아 선택합니다.
5. 라우팅 정책: 우리는 간단한을 사용하지만 사용 사례에 따라 다른 정책을 선택할 수 있습니다.
6. 대상 상태 평가: 우리는 이것을 아니요로 설정하지만, 대상 상태에 따라 로드 밸런서가 트래픽을 라우팅하도록 선택할 수 있습니다.
7. 생성을 선택합니다.
Route 53을 통해 도메인을 등록했다면 완료되었습니다. 다른 도메인 등록기를 사용했으면 도메인 등록기의 DNS 레코드를 업데이트해야 합니다. 다음을 수행해야 합니다:
1. 호스팅된 영역을 선택하고 위에서 추가한 도메인을 선택합니다.
2. NS 레코드 디렉터리이 표시됩니다. 도메인 등록기의 관리자 패널에서 각각을 도메인의 DNS 레코드로 추가합니다. 이러한 단계는 도메인 등록기마다 다를 수 있습니다. 도움이 필요하면 구글에서 “등록기 이름” DNS 레코드 추가를 검색하여 해당 도메인 등록기에 특화된 도움말 기사를 찾을 수 있습니다.

이를 수행하는 방법은 사용하는 등록기에 따라 다양하며, 이 가이드의 범위를 벗어납니다.

RDS와 함께 PostgreSQL

데이터베이스 서버에서는 다중 AZ를 제공하는 Amazon RDS for PostgreSQL을 사용합니다(아우로라는 지원되지 않음). 먼저 보안 그룹과 서브넷 그룹을 생성한 후 실제 RDS 인스턴스를 생성합니다.

RDS 보안 그룹

나중에 배포할 인스턴스에서 들어오는 트래픽을 허용하는 데이터베이스용 보안 그룹이 필요합니다:

EC2 대시 보드에서 왼쪽 메뉴 바에서 보안 그룹을 선택합니다.
보안 그룹 생성을 선택합니다.
이름을 지정(여기서는 gitlab-rds-sec-group을 사용), 설명을 입력하고 VPC 드롭다운 디렉터리에서 gitlab-vpc를 선택합니다.
들어오는 규칙 섹션에서 규칙 추가를 선택하고 다음을 설정합니다:
1. 유형: PostgreSQL 규칙을 검색하여 선택합니다.
2. 소스 유형: “사용자 정의”로 설정합니다.
3. 소스: 앞에서 생성한 gitlab-loadbalancer-sec-group을 선택합니다.
완료되면 보안 그룹 생성을 선택합니다.

RDS 서브넷 그룹

RDS 대시 보드로 이동하여 왼쪽 메뉴에서 서브넷 그룹을 선택합니다.
DB 서브넷 그룹 생성을 선택합니다.
서브넷 그룹 세부정보에서 이름을 입력하고(여기서는 gitlab-rds-group을 사용), 설명을 입력하고, VPC 드롭다운 디렉터리에서 gitlab-vpc를 선택합니다.
가용 영역 드롭다운 디렉터리에서 구성한 서브넷을 포함하는 가용 영역을 선택합니다. 여기서는 eu-west-2a와 eu-west-2b를 추가합니다.
서브넷 드롭다운 디렉터리에서 서브넷 섹션에서 정의한 두 개의 개인 서브넷(10.0.1.0/24 및 10.0.3.0/24)을 선택합니다.
준비되면 생성을 선택합니다.

데이터베이스 생성

지속적으로 과도한 부하 기간에 CPU 크레딧이 소진될 수 있으므로 데이터베이스에 대한 버스터블 인스턴스(t 클래스 인스턴스) 사용을 피하십시오.

이제 데이터베이스를 만들어 봅시다:

RDS 대시 보드로 이동하여 왼쪽 메뉴에서 데이터베이스를 선택하고 데이터베이스 생성을 선택합니다.
데이터베이스 생성 방법으로 표준 생성을 선택합니다.
데이터베이스 엔진으로 PostgreSQL을 선택하고 우리의 데이터베이스 요구 사항에서 GitLab 버전에 정의된 최소 PostgreSQL 버전을 선택합니다.
이는 프로덕션 서버이므로 템플릿 섹션에서 프로덕션을 선택합니다.
설정에서 다음을 사용합니다:
- DB 인스턴스 식별자로 gitlab-db-ha를 사용합니다.
- 마스터 사용자 이름으로 gitlab을 사용합니다.
- 마스터 암호에는 매우 안전한 암호를 사용합니다.
나중에 필요한대로 이러한 정보를 메모해 두세요.
DB 인스턴스 크기에는 드롭다운 디렉터리에서 요구 사항을 충족하는 인스턴스 크기를 선택합니다. 여기서는 db.m4.large 인스턴스를 사용합니다.
리포지터리에서 다음을 구성합니다:
1. 저장 유형 드롭다운 디렉터리에서 요청된 IOPS(SSD)를 선택합니다. 요청된 IOPS(SSD) 리포지터리는 이 용도에 가장 적합합니다(비용을 줄이려면 범용(SSD)을 선택할 수도 있습니다). 자세한 내용은 Amazon RDS용 스토리지에서 확인하세요.
2. 리포지터리 할당량과 요청된 IOPS를 설정합니다. 여기서는 각각 최소 값 100과 1000을 사용합니다.
3. 리포지터리 자동 확장(선택 사항)을 활성화하고 최대 리포지터리 한도를 설정합니다.
가용성 및 내구성에서 다음을 선택합니다:
1. 다른 가용 영역에서 대기 중인 RDS 인스턴스를 만들려면 대기 중인 인스턴스 생성을 선택합니다.
연결성에서 다음을 구성합니다:
1. Virtual Private Cloud (VPC) 드롭다운 디렉터리에서 앞에서 생성한 VPC(gitlab-vpc)를 선택합니다.
2. 추가 연결성 구성 섹션을 확장하고 앞에서 생성한 서브넷 그룹(gitlab-rds-group)을 선택합니다.
3. 공용 접근성을 아니요로 설정합니다.
4. VPC 보안 그룹에서 기존 선택을 선택하고 드롭다운 디렉터리에서 앞에서 생성한 gitlab-rds-sec-group을 선택합니다.
5. 데이터베이스 포트는 기본값 5432로 유지합니다.
데이터베이스 인증에서 암호 인증을 선택합니다.
추가 구성을 확장하고 다음을 완료합니다:
1. 초기 데이터베이스 이름을 설정합니다. 여기서는 gitlabhq_production을 사용합니다.
2. 선호하는 백업 설정을 구성합니다.
3. 여기서 변경하는 유일한 다른 사항은 Maintenance 아래에서 자동 마이너 버전 업데이트를 비활성화하는 것입니다.
4. 다른 모든 설정은 기본 값으로 유지하거나 필요에 따라 조정합니다.
5. 만족하면 데이터베이스 생성을 선택합니다.

이제 데이터베이스가 생성되었으니, ElastiCache와 함께 Redis를 설정하는 방법으로 넘어갑시다.

Redis with ElastiCache

ElastiCache는 인메모리 호스팅 캐싱 솔루션입니다. Redis는 자체 지속성을 유지하며 GitLab 애플리케이션의 세션 데이터, 임시 캐시 정보, 백그라운드 작업 대기열을 저장하는 데 사용됩니다.

Redis 보안 그룹 생성

EC2 대시보드로 이동합니다.
왼쪽 메뉴에서 보안 그룹을 선택합니다.
보안 그룹 생성을 선택하고 세부 정보를 입력합니다. 이름(여기서는 gitlab-redis-sec-group)을 지정하고 설명을 추가하고 이전에 생성한 VPC를 선택합니다.
수신 규칙 섹션에서 규칙 추가를 선택하고 사용자 정의 TCP 규칙을 추가하고 포트를 6379로 설정한 후 “사용자 정의” 소스를 이전에 생성한 gitlab-loadbalancer-sec-group으로 설정합니다.
완료되면 보안 그룹 생성을 선택합니다.

Redis 서브넷 그룹

AWS 콘솔에서 ElastiCache 대시보드로 이동합니다.
왼쪽 메뉴에서 서브넷 그룹으로 이동하고 새로운 서브넷 그룹을 생성합니다(여기서는 gitlab-redis-group로 지정). 우리의 VPC 및 해당 프라이빗 서브넷을 선택하십시오.
준비가 되면 생성을 선택합니다.

Redis 클러스터 생성

ElastiCache 대시보드로 돌아갑니다.
왼쪽 메뉴에서 Redis를 선택하고 새로운 Redis 클러스터를 생성하려면 생성을 선택합니다. 클러스터 모드를 활성화하지 않습니다. 이는 지원되지 않음을 참고하십시오. 클러스터 모드가 비활성화되어 있더라도 여전히 여러 가용 영역에 Redis를 배포할 수 있습니다.
설정 섹션에서:
1. 클러스터에 이름(gitlab-redis)과 설명을 지정합니다.
2. 버전은 최신 버전을 선택합니다.
3. 포트는 6379로 남겨두십시오. 왜냐하면 이것이 우리가 위에서 사용한 Redis 보안 그룹입니다.
4. 노드 유형(적어도 cache.t3.medium, 하지만 필요에 맞게 조정)과 레플리카 수를 선택합니다.
고급 설정 섹션에서:
1. 멀티-AZ 자동 장애 조치 옵션을 선택합니다.
2. 이전에 생성한 서브넷 그룹을 선택합니다.
3. 선호하는 가용 영역을 매뉴얼으로 선택하고 “레플리카 2”에서 다른 영역을 선택합니다.
보안 설정에서 보안 그룹을 편집하고 이전에 생성한 gitlab-redis-sec-group을 선택합니다.
나머지 설정은 기본값으로 두거나 원하는 대로 수정합니다.
준비가 되면 생성을 선택합니다.

베스천 호스트 설정

GitLab 인스턴스가 프라이빗 서브넷에 있기 때문에 구성 변경 및 업그레이드와 같은 작업에 SSH로 이러한 인스턴스에 연결할 방법이 필요합니다. 이를 위해서 bastion host 또는 점프 박스라고도 불리는 방법이 있습니다.

베스천 호스트를 유지하고 싶지 않은 경우 AWS Systems Manager Session Manager를 인스턴스 액세스에 설정할 수 있습니다. 이는 이 문서의 범위를 벗어나는 내용입니다.

Bastion Host A 생성

EC2 대시보드로 이동하고 인스턴스 시작을 선택합니다.
Ubuntu Server 18.04 LTS (HVM) AMI를 선택합니다.
인스턴스 유형을 선택합니다. 우리는 베스천 호스트를 다른 인스턴스에 SSH로만 사용하기 때문에 t2.micro를 사용합니다.
인스턴스 세부 정보 구성을 선택합니다.
1. 네트워크에서 드롭다운 디렉터리에서 gitlab-vpc를 선택합니다.
2. 서브넷에서 이전에 만든 퍼블릭 서브넷(gitlab-public-10.0.0.0)을 선택합니다.
3. 자동 할당 퍼블릭 IP에서 서브넷 설정 사용(활성화)이 선택되었는지 확인합니다.
4. 다른 모든 것은 기본값으로 둔 채 스토리지 추가를 선택합니다.
스토리지에 대해서는 모든 것을 기본값으로 두고 루트 볼륨에만 8GB를 추가합니다. 우리는 이 인스턴스에 아무것도 저장하지 않습니다.
태그 추가를 선택하고 다음 화면에서 태그 추가를 선택합니다.
1. 우리는 키: 이름 및 값: Bastion Host A만 설정합니다.
보안 그룹 구성을 선택합니다.
1. 새 보안 그룹 생성을 선택하고 보안 그룹 이름을 입력하고 설명을 추가합니다.
2. SSH 액세스를 어디서나(0.0.0.0/0)로 구성합니다. 더 엄격한 보안을 원하는 경우 CIDR 표기법으로 단일 IP 주소 또는 IP 주소 범위를 지정합니다.
3. 검토 및 시작을 선택합니다.
모든 설정을 검토하고 만족하다면 시작을 선택합니다.
기존 키 페어에 액세스할 수 있거나 새 키 페어를 생성한다는 사실을 인정합니다. 인스턴스 시작을 선택합니다.

인스턴스에 SSH로 연결할 수 있는지 확인합니다:

EC2 대시보드에서 왼쪽 메뉴에서 인스턴스를 선택합니다.
인스턴스 디렉터리에서 Bastion Host A를 선택합니다.
연결을 선택하고 연결 지침에 따릅니다.
성공적으로 연결할 수 있다면 우리의 두 번째 베스천 호스트 설정으로 넘어갑시다.

Bastion Host B 생성

다음과 같이 위와 같은 단계에 따라 EC2 인스턴스를 생성하십시오:
1. 서브넷에서 두 번째로 만든 퍼블릭 서브넷(gitlab-public-10.0.2.0)을 선택합니다.
2. 태그 추가 섹션에서 키: 이름 및 값: Bastion Host B로 설정하여 두 가지 인스턴스를 쉽게 식별할 수 있습니다.
3. 보안 그룹에서 위에서 생성한 기존 bastion-sec-group을 선택하십시오.

SSH 에이전트 포워딩 사용

Linux에서 실행 중인 EC2 인스턴스는 SSH 인증을 위해 개인 키 파일을 사용합니다. SSH 클라이언트와 클라이언트에 저장된 개인 키 파일을 사용하여 베스천 호스트에 연결합니다. 개인 키 파일이 베스천 호스트에 존재하지 않기 때문에 프라이빗 서브넷에 있는 인스턴스에 연결할 수 없습니다.

베스천 호스트에 대한 개인 키 파일을 저장하는 것은 좋지 않은 아이디어입니다. 이를 극복하기 위해 클라이언트에서 SSH 에이전트 포워딩을 사용합니다. Linux 인스턴스에 연결하기 위한 단계별 안내는 프라이빗 Amazon VPC에서 Linux 인스턴스에 안전하게 연결를 참조하십시오.

GitLab 설치 및 사용자 정의 AMI 생성

나중에 사용할 런치 구성에서 사전 구성된 사용자 정의 GitLab AMI가 필요합니다. 시작점으로는 공식 GitLab AMI를 사용하여 GitLab 인스턴스를 생성합니다. 그런 다음 PostgreSQL, Redis 및 Gitaly에 대한 사용자 정의 구성을 추가합니다. 공식 GitLab AMI 대신 원하는 EC2 인스턴스를 생성하고 매뉴얼으로 GitLab을 설치하는 것도 가능합니다.

GitLab 설치

EC2 대시 보드에서:

“AWS에서 공식 GitLab-created AMI ID 찾기“라는 섹션 아래에서 올바른 AMI를 찾아 런치합니다.
원하는 AMI에서 런치를 선택한 후 워크로드에 기초하여 인스턴스 유형을 선택합니다. 하드웨어 요구 사항을 확인하여 필요한 것을 선택합니다(최소한 c5.xlarge, 100명의 사용자를 수용할 수 있는 사이즈).
인스턴스 구성 세부 사항 구성을 선택합니다:
1. 네트워크 드롭다운 디렉터리에서 앞서 만든 VPC인 gitlab-vpc를 선택합니다.
2. 서브넷 드롭다운 디렉터리에서 앞서 만든 서브넷 디렉터리에서 gitlab-private-10.0.1.0을 선택합니다.
3. 자동 할당 퍼블릭 IP가 서브넷 설정 사용(비활성화)로 설정되어 있는지 확인합니다.
4. 스토리지 추가를 선택합니다.
5. 루트 볼륨은 기본적으로 8GiB이며 여기에는 데이터를 저장하지 않기 때문에 충분합니다.
태그 추가를 선택하고 필요한 경우 원하는 태그를 추가합니다. 우리의 경우 Key: Name 및 Value: GitLab만 설정합니다.
보안 그룹 구성을 선택합니다. 기존 보안 그룹 선택을 선택하고 이전에 만든 gitlab-loadbalancer-sec-group을 선택합니다.
설정에 만족하면 검토 및 런치를 선택한 후 설정을 완료하려면 런치를 선택합니다.
마지막으로 선택한 개인 키 파일에 액세스할 수 있다는 것을 확인하거나 새로 생성합니다. 인스턴스 런치를 선택합니다.

사용자 정의 구성 추가

Bastion Host A를 통해 SSH 에이전트 포워딩을 사용하여 GitLab 인스턴스에 연결합니다. 연결한 후 다음과 같은 사용자 정의 구성을 추가합니다.

Let’s Encrypt 비활성화

로드 밸런서에서 SSL 인증서를 추가하기 때문에 GitLab 내장 Let’s Encrypt 지원이 필요하지 않습니다. https 도메인을 사용할 때 Let’s Encrypt가 기본적으로 활성화되므로, 명시적으로 비활성화해야 합니다:

/etc/gitlab/gitlab.rb를 열고 다음과 같이 설정을 변경하세요:
```
letsencrypt['enable'] = false
```
파일을 저장하고 변경 사항이 적용되도록 다시 구성합니다:
```
sudo gitlab-ctl reconfigure
```

PostgreSQL에 필요한 확장 기능 설치

GitLab 인스턴스에서 RDS 인스턴스에 연결하여 앞으로 사용할 pg_trgm 및 btree_gist 확장 기능을 설치하고 액세스를 확인합니다.

호스트 또는 엔드포인트를 찾으려면 Amazon RDS > 데이터베이스로 이동하여 이전에 생성한 데이터베이스를 선택하고 Connectivity & security 탭에서 엔드포인트를 찾습니다.

콜론과 포트 번호는 포함시키지 마세요:

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=# CREATE EXTENSION btree_gist;
gitlab=# \q

GitLab이 PostgreSQL 및 Redis에 연결하도록 구성

/etc/gitlab/gitlab.rb를 편집하고 external_url 'http://<도메인>' 옵션을 찾아 사용 중인 https 도메인으로 변경합니다.

GitLab 데이터베이스 설정을 찾아 필요한 경우 주석을 해제합니다. 우리의 현재 경우에는 데이터베이스 어댑터, 인코딩, 호스트, 이름, 사용자 이름, 비밀번호를 지정합니다:

# 내장 Postgres 비활성화
postgresql['enable'] = false
   
# 연결 세부 정보 채우기
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>"

마지막으로 Redis 섹션을 추가하여 호스트를 추가하고 포트를 주석 해제합니다:

# 내장 Redis 비활성화
redis['enable'] = false
   
# 연결 세부 정보 채우기
gitlab_rails['redis_host'] = "<redis-endpoint>"
gitlab_rails['redis_port'] = 6379

변경 사항이 적용되도록 GitLab을 다시 구성합니다:
```
sudo gitlab-ctl reconfigure
```
모든 것이 올바르게 설정되었는지 확인하기 위해 확인 및 서비스 상태를 실행할 수도 있습니다:
```
sudo gitlab-rake gitlab:check
sudo gitlab-ctl status
```

Gitaly 설정

이 아키텍처에서 단일 Gitaly 서버를 사용하면 단일 장애 지점이 생깁니다. 이 제한을 제거하기 위해 Gitaly 클러스터를 사용하십시오.

Gitaly는 Git 리포지터리에 대한 고수준 RPC 액세스를 제공하는 서비스입니다. 이를 위해 이전에 구성한 private subnets 중 하나에서 별도의 EC2 인스턴스에 Gitaly를 활성화하고 구성해야 합니다.

Gitaly를 설치할 EC2 인스턴스를 만들어봅시다:

EC2 대시보드에서 인스턴스 시작을 선택합니다.
AMI를 선택합니다. 여기서는 Ubuntu Server 18.04 LTS (HVM), SSD Volume Type을 선택합니다.
인스턴스 유형을 선택합니다. c5.xlarge를 선택합니다.
구성 세부 정보 구성를 선택합니다.
1. 네트워크 드롭다운 디렉터리에서 앞서 만든 VPC인 gitlab-vpc를 선택합니다.
2. 서브넷 드롭다운 디렉터리에서 앞서 만든 서브넷 디렉터리에서 gitlab-private-10.0.1.0을 선택합니다.
3. 자동 할당 퍼블릭 IP가 서브넷 설정 사용(비활성화)로 설정되어 있는지 확인합니다.
4. 스토리지 추가를 선택합니다.
루트 볼륨 크기를 20GiB로 증가하고 구성 세부 사항 구성을 선택합니다. 볼륨 유형을 Provisioned IOPS SSD (io1)로 변경합니다. (이는 임의의 크기입니다. 리포지터리 저장 요구 사항에 충분한 용량으로 볼륨을 생성합니다.)
1. IOPS에 1000을 설정합니다 (20 GiB x 50 IOPS). GiB당 최대 50 IOPS까지 프로비저닝할 수 있습니다. 더 큰 볼륨을 선택하는 경우 IOPS도 상당히 증가시킵니다. git과 같이 많은 소규모 파일이 직렬로 쓰이는 워크로드는 성능이 요구되므로 Provisioned IOPS SSD (io1)를 선택합니다.
태그 추가를 선택하고 태그를 추가합니다. 우리의 경우 Key: Name과 Value: Gitaly만 설정합니다.
보안 그룹 구성을 선택하고 새 보안 그룹 생성을 선택합니다.
1. 보안 그룹 이름과 설명을 지정합니다. 우리는 두 곳 모두 gitlab-gitaly-sec-group을 사용합니다.
2. 사용자 지정 TCP 규칙을 생성하고 포트 범위에 8075를 추가합니다. 소스에서 gitlab-loadbalancer-sec-group를 선택합니다.
3. Bastion 호스트에서 SSH 에이전트 포워딩 사용하기 위해 SSH에 대한 인바운드 규칙도 추가합니다.
설정에 만족하면 검토 및 런치를 선택하고 설정을 완료하려면 런치를 선택합니다.
마지막으로 선택한 개인 키 파일에 액세스할 수 있다는 것을 확인하거나 새로 생성합니다. 인스턴스 런치를 선택합니다.

루트 볼륨에 구성과 리포지터리 데이터를 모두 저장하는 대신 리포지터리 스토리지용 추가 EBS 볼륨을 추가할 수도 있습니다. 위와 동일한 지침을 따릅니다. Amazon EBS 요금을 확인하십시오. GitLab의 성능에 부정적인 영향을 미칠 수 있으므로 EFS를 사용하는 것은 권장하지 않습니다. 더 자세한 내용은 관련 문서를 확인하세요.

이제 EC2 인스턴스를 준비했으므로 문서를 따라 GitLab을 설치하고 별도의 서버에 Gitaly를 설정합니다. 해당 문서에서 클라이언트 설정 단계를 만들었던 GitLab 인스턴스에서 수행합니다.

Proxied SSL 지원 추가

SSL을 로드 밸런서에서 종료하고, 프록시 SSL을 지원하기 위해 /etc/gitlab/gitlab.rb에서 이러한 단계를 따르세요.

gitlab.rb 파일을 저장한 후 sudo gitlab-ctl reconfigure를 실행하는 것을 잊지 마세요.

허가된 SSH 키의 빠른 조회

GitLab에 액세스할 수 있는 사용자의 공개 SSH 키는 /var/opt/gitlab/.ssh/authorized_keys에 저장됩니다. 일반적으로 모든 인스턴스가 이 파일에 액세스할 수 있도록 공유 스토리지를 사용합니다. 그러나 여기서는 공유 스토리지가 없기 때문에, SSH 사용자를 데이터베이스의 인덱스 조회를 통해 승인하는 방식으로 구성을 업데이트합니다.

authorized_keys 파일 대신 데이터베이스에서 조회하는 방식으로 변경하려면 빠른 SSH 키 조회 설정의 지침을 따르세요.

빠른 조회를 구성하지 않으면 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.

호스트 키 구성

일반적으로 주 서버의 /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 객체 리포지터리

공유 스토리지로 NFS를 사용하지 않기 때문에, 백업, 아티팩트, LFS 객체, 업로드, Merge Request 차이, 컨테이너 레지스트리 이미지 등을 저장하기 위해 Amazon S3 버킷을 사용합니다. 저희의 설명서에는 GitLab과 객체 리포지터리를 사용하는 방법에 대한 구성 지침과 이러한 데이터 유형에 대한 다른 정보가 포함되어 있습니다.

이전에 만든 AWS IAM 프로필을 사용하므로 객체 리포지터리를 구성할 때 AWS 액세스 키 및 비밀 액세스 키/값 쌍은 생략해야 합니다. 대신, 위에 링크된 객체 리포지터리 설명서에 나와 있는 대로 설정에서 'use_iam_profile' => true를 사용하세요.

gitlab.rb 파일을 저장한 후 sudo gitlab-ctl reconfigure를 실행하는 것을 잊지 마세요.

이로써 GitLab 인스턴스의 구성 변경이 완료되었습니다. 다음으로, 이 인스턴스를 기반으로 사용할 사용자 지정 AMI를 생성합니다.

처음으로 로그인

로드 밸런서의 DNS 구성 시 사용한 도메인 이름을 사용하여 이제 브라우저에서 GitLab에 방문할 수 있어야 합니다.

GitLab을 설치한 방법에 따라 암호를 변경하지 않았다면 기본 암호는 다음 중 하나일 수 있습니다:

공식 GitLab AMI를 사용한 경우 인스턴스 ID
/etc/gitlab/initial_root_password에 24시간 동안 저장된 임의로 생성된 암호

기본 암호를 변경하려면 root 사용자로 로그인하여 사용자 프로필에서 암호를 변경하세요.

자동 스케일링 그룹에서 새 인스턴스를 생성하는 경우, root 사용자로 로그인하고 새로 생성된 암호로 로그인할 수 있습니다.

사용자 지정 AMI 생성

EC2 대시보드에서:

이전에 생성한 GitLab 인스턴스를 선택합니다.
작업을 선택하고 이미지로 스크롤한 후 이미지 생성을 선택합니다.
이미지에 이름과 설명을 입력하세요 (저희는 둘 다 GitLab-Source를 사용합니다).
나머지 항목은 기본값으로 유지하고 이미지 생성을 선택합니다.

이제 우리는 사용할 사용자 지정 AMI를 가지고 있으며, 다음 단계에서 우리의 런치 구성을 생성하는 데 사용할 것입니다.

자동 스케일링 그룹 내에서 GitLab 배포

런치 구성 생성

EC2 대시보드에서:

왼쪽 메뉴에서 런치 구성 생성을 선택합니다.
내 AMI을 선택하고 위에서 생성한 GitLab 사용자 지정 AMI를 선택합니다.
필요에 맞게 가장 적합한 인스턴스 유형을 선택하고 세부 정보 구성을 선택합니다.
런치 구성에 이름을 입력하세요 (저희는 gitlab-ha-launch-config를 사용합니다).
Spot 인스턴스 요청 확인란을 체크하지 않습니다.
IAM 역할 드롭다운 디렉터리에서 이전에 만든 GitLabAdmin 인스턴스 역할을 선택합니다.
나머지 항목은 기본값으로 유지하고 스토리지 추가를 선택합니다.
루트 볼륨은 기본적으로 8GiB이며, 여기에 데이터를 저장하지 않는 한 충분합니다. 보안 그룹 구성을 선택합니다.
기존 보안 그룹 선택 확인란을 선택하고 앞에서 생성한 gitlab-loadbalancer-sec-group을 선택합니다.
검토를 선택하고 변경 사항을 검토한 후 런치 구성 생성을 선택합니다.
개인 키에 대한 액세스 권한을 인증하거나 새로운 키를 생성하고 런치 구성 생성을 선택합니다.

자동 스케일링 그룹 생성

런치 구성이 생성된 후, 이 런치 구성을 사용하여 자동 스케일링 그룹 생성을 선택하여 자동 스케일링 그룹 생성을 시작합니다.
그룹 이름을 입력하세요 (저희는 gitlab-auto-scaling-group을 사용합니다).
그룹 크기에는 시작할 인스턴스 수를 입력하세요 (저희는 2를 입력합니다).
네트워크 드롭다운 디렉터리에서 gitlab-vpc를 선택하세요.
이전에 생성한 비공개 서브넷을 추가하세요.
고급 세부 사항 섹션을 확장하고 하나 이상의 로드 밸런서에서 트래픽 수신 옵션을 선택합니다.
고전형 로드 밸런서 드롭다운 디렉터리에서 이전에 생성한 로드 밸런서를 선택하세요.
건강 상태 확인 유형에서 ELB를 선택하세요.
건강 상태 확인 유예 기간은 기본값인 300초로 둡니다. 스케일링 정책 구성을 선택합니다.
이 그룹에 대한 용량 조정을 위한 스케일링 정책 사용 확인란을 선택합니다.
이 그룹에서 CPU 사용률이 60%보다 클 경우 인스턴스를 1대 추가하고, 45%보다 작아지면 1대 제거하는 방식으로 인스턴스를 2~4대 사이에서 조정합니다.

마지막으로, 알림 및 태그를 구성하고 변경 사항을 검토한 후 자동 스케일링 그룹을 생성하십시오.

자동 스케일링 그룹이 생성되면 EC2 대시보드에서 새 인스턴스가 생성되는 것을 확인할 수 있습니다. 또한 새 인스턴스가 로드 밸런서에 추가되는 것을 확인할 수 있습니다. 인스턴스가 건강 상태 확인을 통과하면 로드 밸런서로부터 트래픽을 수신할 수 있게 준비가 된 상태입니다.

인스턴스가 자동 스케일링 그룹에 의해 생성되었으므로, 매뉴얼으로 생성한 인스턴스를 다시 확인하고 종료할 수 있습니다. 사용자 지정 AMI를 만들기 위해 이 인스턴스가 필요했을 뿐입니다.

Prometheus를 사용한 상태 체크 및 모니터링

Amazon의 Cloudwatch 외에도 다양한 서비스에서 활성화할 수 있지만, GitLab은 Prometheus를 기반으로 한 자체 통합 모니터링 솔루션을 제공합니다. 세부 정보는 GitLab Prometheus를 참조하세요.

또한 GitLab에는 여러 상태 체크 엔드포인트가 있어 핑하여 리포트를 받을 수 있습니다.

GitLab Runner

만약 GitLab CI/CD를 활용하려면 적어도 하나의 runner를 설정해야 합니다.

AWS에서 자동 스케일링하는 GitLab Runner 구성에 대해 자세히 알아보세요.

백업 및 복원

GitLab은 Git 데이터, 데이터베이스, 첨부 파일, LFS 오브젝트 등을 백업하고 복원하는 도구를 제공합니다.

알아야 할 중요한 사항:

백업/복원 도구는 일부 설정 파일(비밀 정보 등)을 저장하지 않습니다. 이를 직접 구성해야 합니다.
기본적으로 백업 파일은 로컬에 저장되지만 Amazon S3를 사용하여 GitLab을 백업할 수 있습니다.
특정 디렉터리를 백업에서 제외할 수 있습니다.

GitLab 백업

GitLab을 백업하려면:

인스턴스에 SSH로 연결합니다.
백업을 수행합니다:
```
sudo gitlab-backup create
```

GitLab 12.1 및 이전 버전의 경우 gitlab-rake gitlab:backup:create를 사용하세요.

백업에서 GitLab 복원

GitLab을 복원하려면, 먼저 복원 문서 및 주로 복원 전제 조건을 검토하세요. 그런 다음 리눅스 패키지 설치 섹션의 단계를 따릅니다.

GitLab 업데이트

GitLab은 매월 릴리스 날짜에 새 버전을 릴리스합니다. 새 버전이 릴리스되면 GitLab 인스턴스를 업데이트할 수 있습니다:

인스턴스에 SSH로 연결합니다.
백업을 수행합니다:
```
sudo gitlab-backup create
```

GitLab 12.1 및 이전 버전의 경우 gitlab-rake gitlab:backup:create를 사용하세요.

리포지터리를 업데이트하고 GitLab을 설치합니다:
```
sudo apt update
sudo apt install gitlab-ee
```

몇 분 후 새 버전이 실행되게 될 것입니다.

공식 GitLab 생성 AMI ID 검색

GitLab 릴리스를 AMI로 사용하는 방법에 대해 더 자세히 알아보세요.

결론

이 가이드에서는 주로 확장 및 일부 중복 옵션에 대해 다루었으며, 실행 환경에 따라 다를 수 있습니다.

모든 솔루션은 비용/복잡성과 가용성 사이의 교역 관계가 있음을 명심하세요. 더 많은 가용성을 원할수록 해결책이 더 복잡해지고, 해결책이 더 복잡할수록 설정 및 유지에 더 많은 작업이 필요합니다.

이 외의 자료를 읽어보고 추가 자료를 요청하려면 이슈를 열어주세요:

GitLab 확장: GitLab은 여러 유형의 클러스터링을 지원합니다.
Geo 복제: Geo는 널리 분산된 개발 팀을 위한 솔루션입니다.
리눅스 패키지: GitLab 인스턴스를 관리하는 데 알아야 할 모든 것.
라이선스 추가: 라이선스로 모든 GitLab 엔터프라이즈 버전 기능을 활성화합니다.
가격: 다양한 티어에 대한 가격정책.

문제 해결

인스턴스의 상태 체크 실패

인스턴스가 로드 밸런서의 상태 체크에 실패하는 경우, 이전에 구성한 상태 체크 엔드포인트에서 200 상태를 반환하는지 확인하세요. 이외의 다른 상태(302와 같은 리디렉션 포함)는 상태 체크 실패의 원인이 됩니다.

상태 체크가 통과되기 전에 로그인 엔드포인트에서 자동 리디렉트를 막기 위해 root 사용자에게 암호를 설정해야 할 수 있습니다.

“요청한 변경이 거부되었습니다 (422)”

웹 인터페이스를 통해 비밀번호를 설정하려고 할 때 이 페이지를 보게 되면, gitlab.rb의 external_url이 요청을 보낸 도메인과 일치하는지 확인하고 변경한 후에 sudo gitlab-ctl reconfigure을 실행하세요.

일부 작업 로그가 개체 리포지터리에 업로드되지 않음

GitLab 배포가 하나 이상의 노드로 확장되면 일부 작업 로그가 개체 리포지터리에 올바르게 업로드되지 않을 수 있습니다. CI에서 개체 리포지터리를 사용하기 위해 증분 로깅이 필요합니다.

이미 활성화되어 있지 않은 경우 증분 로깅을 활성화하세요.

Amazon Web Services(AWS)에서 GitLab POC 설치

프로덕션 수준의 GitLab 시작하기

프로덕션 수준의 리눅스 패키지 설치 시작하기

프로덕션 수준의 클라우드 네이티브 하이브리드 GitLab 시작하기

소개

요구 사항

AWS 비용

IAM 정책 생성

IAM 역할 생성

네트워크 구성

가상 사설 클라우드 (VPC) 생성

서브넷

인터넷 게이트웨이

NAT 게이트웨이 작성

라우트 테이블

퍼블릭 라우트 테이블

프라이빗 라우트 테이블

로드 밸런서

로드 밸런서를 위한 DNS 구성

RDS와 함께 PostgreSQL

RDS 보안 그룹

RDS 서브넷 그룹

데이터베이스 생성

Redis with ElastiCache

Redis 보안 그룹 생성

Redis 서브넷 그룹

Redis 클러스터 생성

베스천 호스트 설정

Bastion Host A 생성

Bastion Host B 생성

SSH 에이전트 포워딩 사용

GitLab 설치 및 사용자 정의 AMI 생성

GitLab 설치

사용자 정의 구성 추가

Let’s Encrypt 비활성화

PostgreSQL에 필요한 확장 기능 설치

GitLab이 PostgreSQL 및 Redis에 연결하도록 구성

Gitaly 설정

Proxied SSL 지원 추가

허가된 SSH 키의 빠른 조회

호스트 키 구성

Amazon S3 객체 리포지터리

처음으로 로그인

사용자 지정 AMI 생성

자동 스케일링 그룹 내에서 GitLab 배포

런치 구성 생성

자동 스케일링 그룹 생성

Prometheus를 사용한 상태 체크 및 모니터링

GitLab Runner

백업 및 복원

GitLab 백업

백업에서 GitLab 복원

GitLab 업데이트

공식 GitLab 생성 AMI ID 검색

결론

문제 해결

인스턴스의 상태 체크 실패

“요청한 변경이 거부되었습니다 (422)”

일부 작업 로그가 개체 리포지터리에 업로드되지 않음

도움말

기능 사용 가능성과 제품 평가판

도움받기