이 페이지는 공식 Linux 패키지를 사용하여 AWS에서 GitLab을 구성하는 일반적인 방법을 안내합니다. 필요에 맞게 맞춤 설정하시기 바랍니다.

1,000명 이하의 조직에는 EC2 단일 서버 Linux 패키지 설치를 시작하고 데이터 백업을 위한 스냅샷 전략을 구현하는 것이 권장 AWS 설치 방법입니다. 자세한 내용은 20 RPS 또는 1,000 사용자 레퍼런스 아키텍처를 참조하세요.

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

이 문서는 개념 검증(POC) 인스턴스를 위한 설치 가이드입니다. 레퍼런스 아키텍처가 아니며 고가용성 구성 결과를 제공하지 않습니다. 대신 GitLab Environment Toolkit (GET)을 사용하는 것을 강력히 권장합니다.

이 가이드를 그대로 따르면 Non-HA 40 RPS 또는 2,000 사용자 레퍼런스 아키텍처의 축소된 버전인 2가용 영역 구현과 유사한 POC 인스턴스가 생성됩니다. 2K 레퍼런스 아키텍처는 주로 비용과 복잡성을 낮게 유지하면서 일부 스케일링을 제공하기 위한 것이므로 HA가 아닙니다. 60 RPS 또는 3,000 사용자 레퍼런스 아키텍처가 GitLab HA를 지원하는 최소 규모입니다.

GitLab은 두 가지 주요 유형의 레퍼런스 아키텍처를 유지 관리하고 테스트합니다. Linux 패키지 아키텍처는 인스턴스 컴퓨팅에서 구현되고 Cloud Native Hybrid 아키텍처는 Kubernetes 클러스터 사용을 최대화합니다.

프로덕션 수준 Linux 패키지 설치 시작하기#

Infrastructure as Code 도구인 GitLab Environment Tool (GET)은 AWS에서 Linux 패키지를 사용하여 구축할 때, 특히 HA 설정을 목표로 할 때 시작하기 가장 좋은 곳입니다. 모든 것을 자동화하지는 않지만 Gitaly Cluster (Praefect)와 같은 복잡한 설정을 처리합니다. GET은 오픈 소스이므로 누구나 이를 기반으로 구축하고 개선 사항을 기여할 수 있습니다.

프로덕션 수준 Cloud Native Hybrid GitLab 시작하기#

GitLab Environment Toolkit (GET)은 의견이 반영된 Terraform 및 Ansible 스크립트 세트입니다. 이 스크립트는 선택된 클라우드 공급자에서 Linux 패키지 또는 Cloud Native Hybrid 환경 배포를 지원하며 GitLab 개발자가 GitLab Dedicated에 사용합니다.

소개#

이 설정에서 주로 Linux 패키지를 사용하지만 기본 AWS 서비스도 활용합니다. Linux 패키지에 번들된 PostgreSQL 및 Redis 대신 Amazon RDS와 ElastiCache를 사용합니다.

이 가이드에서는 Virtual Private Cloud와 서브넷 구성부터 시작하여 데이터베이스 서버용 RDS 및 Redis 클러스터용 ElastiCache와 같은 서비스를 통합하고 최종적으로 사용자 정의 스케일링 정책으로 Auto Scaling Group에서 관리하는 다중 노드 설정을 진행합니다.

요구 사항#

AWS와 Amazon EC2에 대한 기본 지식 외에도 다음이 필요합니다:

• AWS 계정

• SSH를 통해 인스턴스에 연결하기 위한 SSH 키 생성 또는 업로드

• GitLab 인스턴스용 도메인 이름

• 도메인 보안을 위한 SSL/TLS 인증서. 아직 없다면 생성할 로드 밸런서에 사용하기 위해 AWS Certificate Manager(ACM)를 통해 무료 공개 SSL/TLS 인증서를 프로비저닝할 수 있습니다.

ACM을 통해 프로비저닝된 인증서의 유효성 검사에는 몇 시간이 걸릴 수 있습니다. 나중에 지연을 방지하려면 가능한 한 빨리 인증서를 요청하세요.

아키텍처#

다음 다이어그램은 권장 아키텍처를 보여줍니다.

AWS 비용#

GitLab은 다음 AWS 서비스를 사용하며 가격 정보 링크가 포함되어 있습니다:

• EC2: GitLab은 공유 하드웨어에 배포되며 온디맨드 가격이 적용됩니다. 전용 또는 예약 인스턴스에서 GitLab을 실행하려면 비용에 대한 정보를 EC2 가격 페이지에서 확인하세요.

• S3: GitLab은 백업, 아티팩트, LFS 객체를 저장하는 데 S3(가격 페이지)를 사용합니다.

• NLB: GitLab 인스턴스로 요청을 라우팅하는 데 사용되는 Network Load Balancer(가격 페이지).

• RDS: PostgreSQL을 사용하는 Amazon Relational Database Service(가격 페이지).

• ElastiCache: Redis 구성을 제공하는 데 사용되는 인메모리 호스팅 캐싱 솔루션(가격 페이지).

IAM EC2 인스턴스 역할 및 프로파일 생성#

Amazon S3 객체 스토리지를 사용하므로 EC2 인스턴스에는 S3 버킷에 대한 읽기, 쓰기, 목록 조회 권한이 있어야 합니다. GitLab 구성에 AWS 키를 포함시키지 않기 위해 GitLab 인스턴스에 이 액세스를 허용하는 IAM 역할을 사용합니다. IAM 역할에 연결할 IAM 정책을 생성해야 합니다:

IAM 정책 생성#

• IAM 대시보드로 이동하여 왼쪽 메뉴에서 Policies를 선택합니다.

• Create policy를 선택하고 JSON 탭을 선택한 다음 정책을 추가합니다. 최소 권한 부여 보안 모범 사례를 따르고 역할에 필요한 작업만 수행하는 데 필요한 권한만 부여합니다.

다이어그램과 같이 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-*"
        }
    ]
}

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

IAM 역할 생성#

• IAM 대시보드에서 왼쪽 메뉴의 Roles를 선택하고 Create role을 선택합니다.

• Trusted entity type에서 AWS service를 선택합니다. Use case에서 드롭다운 목록과 라디오 버튼 모두에서 EC2를 선택하고 Next를 선택합니다.

• 정책 필터에서 이전에 생성한 gl-s3-policy를 검색하여 선택하고 Next를 선택합니다.

• 역할에 이름을 지정합니다(여기서는 GitLabS3Access 사용). 필요한 경우 태그를 추가합니다. Create role을 선택합니다.

나중에 시작 템플릿을 생성할 때 이 역할을 사용합니다.

GitLab은 AWS Instance Metadata Service 버전 2(IMDSv2)를 지원합니다. GitLab은 사용 가능할 때 IMDSv2를 자동으로 사용하고 필요한 경우 IMDSv1으로 폴백합니다. 보안 강화를 위해 EC2 인스턴스에서 IMDSv2를 안전하게 요구할 수 있습니다.

네트워크 구성#

GitLab 클라우드 인프라를 위한 VPC를 생성한 다음 최소 두 개의 가용 영역(AZ)에 공개 및 사설 인스턴스를 위한 서브넷을 생성합니다. 공개 서브넷에는 Route Table과 연결된 Internet Gateway가 필요합니다.

Virtual Private Cloud (VPC) 생성#

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

• Amazon Web Services에 로그인합니다.

• 왼쪽 메뉴에서 Your VPCs를 선택한 다음 Create VPC를 선택합니다. "Name tag"에 gitlab-vpc를 입력하고 "IPv4 CIDR block"에 10.0.0.0/16을 입력합니다. 전용 하드웨어가 필요하지 않으면 "Tenancy"를 기본값으로 둘 수 있습니다. 준비되면 Create VPC를 선택합니다.

• VPC를 선택하고 Actions를 선택한 다음 Edit VPC Settings를 선택하고 Enable DNS resolution을 체크합니다. 완료되면 Save를 선택합니다.

서브넷#

이제 서로 다른 가용 영역에 서브넷을 생성합니다. 각 서브넷이 방금 생성한 VPC에 연결되어 있고 CIDR 블록이 겹치지 않는지 확인하세요. 이를 통해 중복성을 위한 Multi-AZ를 활성화할 수도 있습니다.

로드 밸런서와 RDS 인스턴스에 맞는 사설 및 공개 서브넷을 생성합니다:

• 왼쪽 메뉴에서 Subnets를 선택합니다.

• Create subnet을 선택합니다. IP를 기반으로 설명적인 이름 태그를 지정하고(예: gitlab-public-10.0.0.0), 이전에 생성한 VPC를 선택하고, 가용 영역을 선택하고(여기서는 us-west-2a 사용), IPv4 CIDR 블록에 24 서브넷 10.0.0.0/24를 지정합니다:

• 동일한 단계를 반복하여 모든 서브넷을 생성합니다:

• 모든 서브넷이 생성되면 두 공개 서브넷에 대해 Auto-assign IPv4를 활성화합니다:

각 공개 서브넷을 차례로 선택하고 Actions를 선택한 다음 Edit subnet settings를 선택합니다. Enable auto-assign public IPv4 address 옵션을 체크하고 저장합니다.

Internet Gateway#

같은 대시보드에서 Internet Gateways로 이동하여 새로운 게이트웨이를 생성합니다:

• 왼쪽 메뉴에서 Internet Gateways를 선택합니다.

• Create internet gateway를 선택하고 이름을 gitlab-gateway로 지정한 다음 Create를 선택합니다.

• 테이블에서 선택하고 Actions 드롭다운 목록에서 "Attach to VPC"를 선택합니다.

• 목록에서 gitlab-vpc를 선택하고 Attach를 클릭합니다.

NAT Gateway 생성#

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

• VPC 대시보드로 이동하여 왼쪽 메뉴 바에서 NAT Gateways를 선택합니다.

• Create NAT Gateway를 선택하고 다음을 완료합니다:

Subnet: 드롭다운 목록에서 gitlab-public-10.0.0.0을 선택합니다.

• Elastic IP Allocation ID: 기존 Elastic IP를 입력하거나 Allocate Elastic IP address를 선택하여 NAT Gateway에 새 IP를 할당합니다.

• 필요한 경우 태그를 추가합니다.

• Create NAT Gateway를 선택합니다.

두 번째 NAT Gateway를 생성하되 이번에는 두 번째 공개 서브넷인 gitlab-public-10.0.2.0에 배치합니다.

라우팅 테이블#

공개 라우팅 테이블#

공개 서브넷이 이전 단계에서 생성한 인터넷 게이트웨이를 통해 인터넷에 접근할 수 있도록 라우팅 테이블을 생성해야 합니다.

VPC 대시보드에서:

• 왼쪽 메뉴에서 Route Tables를 선택합니다.

• Create Route Table을 선택합니다.

• "Name tag"에 gitlab-public을 입력하고 "VPC" 아래에서 gitlab-vpc를 선택합니다.

• Create를 선택합니다.

이제 인터넷 게이트웨이를 새 대상으로 추가하고 모든 목적지에서 트래픽을 받도록 해야 합니다.

• 왼쪽 메뉴에서 Route Tables를 선택하고 gitlab-public 라우팅을 선택하여 하단에 옵션을 표시합니다.

• Routes 탭을 선택하고 Edit routes > Add route를 선택한 다음 목적지로 0.0.0.0/0을 설정합니다. 대상 열에서 Internet Gateway를 선택하고 이전에 생성한 gitlab-gateway를 선택합니다. 완료되면 Save changes를 선택합니다.

다음으로 공개 서브넷을 라우팅 테이블에 연결해야 합니다:

• Subnet Associations 탭을 선택하고 Edit subnet associations를 선택합니다.

• 공개 서브넷만 체크하고 Save associations를 선택합니다.

사설 라우팅 테이블#

각 사설 서브넷의 인스턴스가 동일한 가용 영역의 해당 공개 서브넷에 있는 NAT Gateway를 통해 인터넷에 접근할 수 있도록 두 개의 사설 라우팅 테이블도 생성해야 합니다.

• 이전 단계를 따라 두 개의 사설 라우팅 테이블을 생성합니다. 이름을 gitlab-private-a와 gitlab-private-b로 지정합니다.

• 다음으로 목적지가 0.0.0.0/0이고 대상이 이전에 생성한 NAT Gateway 중 하나인 새 라우팅을 각 사설 라우팅 테이블에 추가합니다.

gitlab-public-10.0.0.0에 생성한 NAT Gateway를 gitlab-private-a 라우팅 테이블의 새 라우팅 대상으로 추가합니다.

• 마찬가지로 gitlab-public-10.0.2.0의 NAT Gateway를 gitlab-private-b의 새 라우팅 대상으로 추가합니다.

• 마지막으로 각 사설 서브넷을 사설 라우팅 테이블에 연결합니다.

gitlab-private-10.0.1.0을 gitlab-private-a와 연결합니다.

• gitlab-private-10.0.3.0을 gitlab-private-b와 연결합니다.

로드 밸런서#

포트 80과 443의 인바운드 트래픽을 GitLab 애플리케이션 서버 전반에 고르게 분산시키기 위해 로드 밸런서를 생성합니다. 나중에 생성하는 스케일링 정책에 따라 인스턴스가 로드 밸런서에서 추가되거나 제거됩니다. 또한 로드 밸런서는 인스턴스에 대한 헬스 체크를 수행합니다. 환경에서 SSL/TLS를 처리하는 다양한 방법이 있지만, 이 POC에서는 백엔드 SSL 없이 로드 밸런서에서 SSL을 종료합니다.

EC2 대시보드에서 왼쪽 탐색 바의 Load Balancers를 찾습니다:

• Create Load Balancer를 선택합니다.

• Network Load Balancer를 선택하고 Create를 선택합니다.

• Load Balancer 이름을 gitlab-loadbalancer로 설정합니다. 다음 추가 옵션을 설정합니다:

Scheme: Internet-facing 선택

• IP address type: IPv4 선택

• VPC: 드롭다운 목록에서 gitlab-vpc를 선택합니다.

• Mapping: 로드 밸런서가 두 가용 영역 모두로 트래픽을 라우팅할 수 있도록 목록에서 두 공개 서브넷을 선택합니다.

• 트래픽을 제어하기 위한 방화벽으로 로드 밸런서용 보안 그룹을 추가합니다. Security Group 섹션에서 create a new security group를 선택하고 이름(gitlab-loadbalancer-sec-group)과 설명을 지정한 다음 HTTP와 HTTPS 트래픽을 어디서나(0.0.0.0/0, ::/0) 허용합니다. 또한 SSH 트래픽을 허용하고, 사용자 정의 소스를 선택한 다음 신뢰할 수 있는 단일 IP 주소 또는 CIDR 표기법의 IP 주소 범위를 추가합니다. 이를 통해 사용자가 SSH를 통해 Git 작업을 수행할 수 있습니다.

• Listeners and routing 섹션에서 다음 대상 그룹을 고려하여 포트 22, 80, 443에 대한 리스너를 설정합니다.

포트 443의 TLS 리스너에서 Security Policy 설정 아래:

Policy name: 드롭다운 목록에서 미리 정의된 보안 정책을 선택합니다. AWS 문서에서 Network Load Balancer용 사전 정의된 SSL 보안 정책 분류를 확인할 수 있습니다. 지원되는 SSL 암호 및 프로토콜 목록은 GitLab 코드베이스를 확인하세요.

• Default SSL/TLS server certificate: ACM에서 SSL/TLS 인증서를 선택하거나 IAM에 인증서를 업로드합니다.

• 생성한 각 리스너에 대해 대상 그룹을 생성하고 이전 표를 기반으로 할당해야 합니다. 아직 EC2 인스턴스를 생성하지 않았으므로 대상을 등록할 필요가 없습니다. EC2 인스턴스는 나중에 Auto Scaling Group 설정의 일부로 생성되고 할당됩니다.

Create target group을 선택합니다. 대상 유형으로 Instances를 선택합니다.

• 각 리스너에 적합한 Target group name을 선택합니다:

gitlab-loadbalancer-http-target - 포트 80의 TCP 프로토콜

• gitlab-loadbalancer-ssh-target - 포트 22의 TCP 프로토콜

• IP 주소 유형으로 IPv4를 선택합니다.

• VPC 드롭다운 목록에서 gitlab-vpc를 선택합니다.

• gitlab-loadbalancer-http-target 헬스 체크의 경우 Readiness 체크 엔드포인트를 사용해야 합니다. 헬스 체크 엔드포인트를 위해 IP 허용 목록에 VPC IP 주소 범위(CIDR)을 추가해야 합니다.

• gitlab-loadbalancer-ssh-target 헬스 체크의 경우 TCP를 선택합니다.

gitlab-loadbalancer-http-target을 포트 80과 443 리스너 모두에 할당합니다.

• gitlab-loadbalancer-ssh-target을 포트 22 리스너에 할당합니다.

• 일부 속성은 대상 그룹이 이미 생성된 후에만 구성할 수 있습니다. 다음은 요구 사항에 따라 구성할 수 있는 몇 가지 기능입니다.

Client IP 보존은 대상 그룹에 기본적으로 활성화되어 있습니다. 이를 통해 로드 밸런서에 연결된 클라이언트의 IP를 GitLab 애플리케이션에 보존할 수 있습니다. 요구 사항에 따라 활성화 또는 비활성화할 수 있습니다.

• Proxy Protocol은 대상 그룹에 기본적으로 비활성화되어 있습니다. 이를 통해 로드 밸런서가 프록시 프로토콜 헤더에 추가 정보를 보낼 수 있습니다. 활성화하려면 내부 로드 밸런서, NGINX 등과 같은 다른 환경 구성 요소도 구성해야 합니다. 이 POC에서는 나중에 GitLab 노드에서만 활성화하면 됩니다.

• Create load balancer를 선택합니다.

로드 밸런서가 가동되고 실행되면 보안 그룹을 다시 검토하여 NLB를 통해서만 액세스하도록 제한하고 다른 요구 사항을 반영할 수 있습니다.

로드 밸런서용 DNS 구성#

Route 53 대시보드의 왼쪽 탐색 바에서 Hosted zones를 선택합니다:

• 기존 hosted zone을 선택하거나, 도메인에 대한 hosted zone이 아직 없는 경우 Create Hosted Zone을 선택하고 도메인 이름을 입력한 다음 Create를 선택합니다.

• Create record를 선택하고 다음 값을 제공합니다:

Name: 도메인 이름(기본값)을 사용하거나 서브도메인을 입력합니다.

• Type: A - IPv4 address를 선택합니다.

• Alias: 기본값은 disabled입니다. 이 옵션을 활성화합니다.

• Route traffic to: Alias to Network Load Balancer를 선택합니다.

• Region: Network Load Balancer가 있는 리전을 선택합니다.

• Choose network load balancer: 이전에 생성한 Network Load Balancer를 선택합니다.

• Routing Policy: 여기서는 Simple을 사용하지만 사용 사례에 따라 다른 정책을 선택할 수 있습니다.

• Evaluate Target Health: 여기서는 No로 설정하지만 대상 상태에 따라 로드 밸런서가 트래픽을 라우팅하도록 선택할 수 있습니다.

• Create를 선택합니다.

• Route 53을 통해 도메인을 등록한 경우 완료입니다. 다른 도메인 등록 기관을 사용한 경우 해당 도메인 등록 기관에서 DNS 레코드를 업데이트해야 합니다. 다음을 수행해야 합니다:

Hosted zones를 선택하고 이전에 추가한 도메인을 선택합니다.

• NS 레코드 목록이 표시됩니다. 도메인 등록 기관의 관리자 패널에서 이 각각을 도메인의 DNS 레코드에 NS 레코드로 추가합니다. 이 단계는 도메인 등록 기관마다 다를 수 있습니다.

이 단계는 사용하는 등록 기관에 따라 다르며 이 가이드의 범위를 벗어납니다.

PostgreSQL과 RDS#

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

RDS 보안 그룹#

나중에 gitlab-loadbalancer-sec-group에 배포하는 인스턴스에서 인바운드 트래픽을 허용하는 데이터베이스용 보안 그룹이 필요합니다:

• EC2 대시보드에서 왼쪽 메뉴 바의 Security Groups를 선택합니다.

• Create security group을 선택합니다.

• 이름(gitlab-rds-sec-group)과 설명을 지정하고 VPC 드롭다운 목록에서 gitlab-vpc를 선택합니다.

• Inbound rules 섹션에서 Add rule을 선택하고 다음을 설정합니다:

Type: PostgreSQL 규칙을 검색하여 선택합니다.

• Source type: "Custom"으로 설정합니다.

• Source: 이전에 생성한 gitlab-loadbalancer-sec-group을 선택합니다.

• 완료되면 Create security group을 선택합니다.

RDS 서브넷 그룹#

• RDS 대시보드로 이동하여 왼쪽 메뉴에서 Subnet Groups를 선택합니다.

• Create DB Subnet Group을 선택합니다.

• Subnet group details 아래에 이름(gitlab-rds-group)과 설명을 입력하고 VPC 드롭다운 목록에서 gitlab-vpc를 선택합니다.

• Availability Zones 드롭다운 목록에서 구성한 서브넷이 포함된 가용 영역을 선택합니다. 여기서는 eu-west-2a와 eu-west-2b를 추가합니다.

• Subnets 드롭다운 목록에서 서브넷 섹션에서 정의한 두 개의 사설 서브넷(10.0.1.0/24 및 10.0.3.0/24)을 선택합니다.

• 준비되면 Create를 선택합니다.

데이터베이스 생성#

버스터블 인스턴스(t 클래스 인스턴스)는 지속적인 높은 부하 기간 동안 CPU 크레딧이 소진되어 성능 문제가 발생할 수 있으므로 데이터베이스에 사용하지 마세요.

이제 데이터베이스를 생성할 차례입니다:

• RDS 대시보드로 이동하고, 왼쪽 메뉴에서 Databases를 선택한 다음 Create database를 선택합니다.

• 데이터베이스 생성 방법으로 Standard Create를 선택합니다.

• 데이터베이스 엔진으로 PostgreSQL을 선택하고 데이터베이스 요구 사항에 정의된 GitLab 버전에 맞는 최소 PostgreSQL 버전을 선택합니다.

• 프로덕션 서버이므로 Templates 섹션에서 Production을 선택합니다.

• Availability & durability 아래에서 Multi-AZ DB instance를 선택하여 다른 가용 영역에 대기 RDS 인스턴스를 프로비저닝합니다.

• Settings 아래에서 다음을 사용합니다:

DB 인스턴스 식별자로 gitlab-db-ha를 사용합니다.

• 마스터 사용자 이름으로 gitlab을 사용합니다.

• 마스터 비밀번호로 매우 안전한 비밀번호를 사용합니다.

나중에 필요하므로 이를 메모해 두세요.

• DB 인스턴스 크기의 경우 Standard classes를 선택하고 드롭다운 목록에서 요구 사항에 맞는 인스턴스 크기를 선택합니다. 여기서는 db.m5.large 인스턴스를 사용합니다.

• Storage 아래에서 다음을 구성합니다:

스토리지 유형 드롭다운 목록에서 **Provisioned IOPS (SSD)**를 선택합니다. Provisioned IOPS (SSD) 스토리지는 이 용도에 가장 적합합니다(비용을 줄이기 위해 General Purpose (SSD)를 선택할 수 있습니다). Amazon RDS 스토리지에서 더 자세히 알아보세요.

• 스토리지를 할당하고 프로비저닝된 IOPS를 설정합니다. 최솟값인 100과 1000을 사용합니다.

• 스토리지 자동 스케일링을 활성화하고(선택 사항) 최대 스토리지 임계값을 설정합니다.

• Connectivity 아래에서 다음을 구성합니다:

Virtual Private Cloud (VPC) 드롭다운 목록에서 이전에 생성한 VPC(gitlab-vpc)를 선택합니다.

• DB subnet group 아래에서 이전에 생성한 서브넷 그룹(gitlab-rds-group)을 선택합니다.

• 공개 액세스를 No로 설정합니다.

• VPC security group 아래에서 Choose existing을 선택하고 드롭다운 목록에서 이전에 생성한 gitlab-rds-sec-group을 선택합니다.

• Additional configuration에서 데이터베이스 포트를 기본값 5432로 둡니다.

• Database authentication에서 Password authentication을 선택합니다.

• Additional configuration 섹션을 확장하고 다음을 완료합니다:

초기 데이터베이스 이름으로 gitlabhq_production을 사용합니다.

• 원하는 백업 설정을 구성합니다.

• Maintenance 아래에서 자동 마이너 버전 업데이트를 비활성화합니다.

• 다른 모든 설정은 그대로 두거나 필요에 맞게 조정합니다.

• 완료되면 Create database를 선택합니다.

데이터베이스가 생성되었으므로 이제 ElastiCache로 Redis를 설정합니다.

ElastiCache로 Redis 설정#

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

Redis 보안 그룹 생성#

• EC2 대시보드로 이동합니다.

• 왼쪽 메뉴에서 Security Groups를 선택합니다.

• Create security group을 선택하고 세부 정보를 입력합니다. 이름(gitlab-redis-sec-group)을 지정하고 설명을 추가한 다음 이전에 생성한 VPC(gitlab-vpc)를 선택합니다.

• Inbound rules 섹션에서 Add rule을 선택하고 Custom TCP 규칙을 추가한 다음 포트 6379를 설정하고 "Custom" 소스를 이전에 생성한 gitlab-loadbalancer-sec-group으로 설정합니다.

• 완료되면 Create security group을 선택합니다.

Redis 서브넷 그룹#

• AWS 콘솔에서 ElastiCache 대시보드로 이동합니다.

• 왼쪽 메뉴의 Subnet Groups로 이동하고 새 서브넷 그룹을 생성합니다(여기서는 gitlab-redis-group으로 이름 지정). 이전에 생성한 VPC(gitlab-vpc)를 선택하고 선택된 서브넷 테이블에 사설 서브넷만 포함되어 있는지 확인합니다.

• 준비되면 Create를 선택합니다.

Redis 클러스터 생성#

• ElastiCache 대시보드로 돌아갑니다.

• 왼쪽 메뉴에서 Redis caches를 선택하고 Create Redis cache를 선택하여 새 Redis 클러스터를 생성합니다.

• Deployment option 아래에서 Design your own cache를 선택합니다.

• Creation method 아래에서 Cluster cache를 선택합니다.

• Cluster mode 아래에서 지원되지 않으므로 Disabled를 선택합니다. 클러스터 모드가 없어도 여전히 여러 가용 영역에 Redis를 배포할 수 있습니다.

• Cluster info 아래에서 클러스터에 이름(gitlab-redis)과 설명을 지정합니다.

• Location 아래에서 AWS Cloud를 선택하고 Multi-AZ 옵션을 활성화합니다.

• Cluster settings 섹션에서:

Engine version의 경우 Redis 요구 사항에 정의된 GitLab 버전에 맞는 Redis 버전을 선택합니다.

• 이전에 Redis 보안 그룹에서 사용한 것이므로 포트를 6379로 둡니다.

• 노드 유형(최소 cache.t3.medium, 필요에 따라 조정)과 복제본 수를 선택합니다.

• Connectivity settings 섹션에서:

Network type: IPv4

• Subnet groups: Choose existing subnet group을 선택하고 이전에 생성한 gitlab-redis-group을 선택합니다.

• Availability Zone placements 섹션에서:

기본 가용 영역을 수동으로 선택하고 "Replica 2" 아래에서 다른 두 개와 다른 영역을 선택합니다.

• Next를 선택합니다.

• 보안 설정에서 보안 그룹을 편집하고 이전에 생성한 gitlab-redis-sec-group을 선택합니다. Next를 선택합니다.

• 나머지 설정은 기본값으로 두거나 원하는 대로 편집합니다.

• 완료되면 Create를 선택합니다.

Bastion Host 설정#

GitLab 인스턴스가 사설 서브넷에 있으므로 구성 변경 및 업그레이드 수행과 같은 작업을 위해 SSH로 이러한 인스턴스에 연결하는 방법이 필요합니다. 이를 위한 한 가지 방법은 점프 박스라고도 하는 bastion host를 사용하는 것입니다.

Bastion host를 유지 관리하지 않으려면 인스턴스 액세스를 위한 AWS Systems Manager Session Manager를 설정할 수 있습니다. 이는 이 문서의 범위를 벗어납니다.

Bastion Host A 생성#

• EC2 대시보드로 이동하여 Launch instance를 선택합니다.

• Name and tags 섹션에서 Name을 Bastion Host A로 설정합니다.

• 최신 Ubuntu Server LTS (HVM) AMI를 선택합니다. 최신 지원되는 OS 버전을 위해 GitLab 문서를 확인하세요.

• 인스턴스 유형을 선택합니다. bastion host를 다른 인스턴스에 SSH로 접속하는 데만 사용하므로 t2.micro를 사용합니다.

• Key pair 섹션에서 Create new key pair를 선택합니다.

키 페어에 이름을 지정하고(bastion-host-a 사용) 나중에 사용할 수 있도록 bastion-host-a.pem 파일을 저장합니다.

• Network settings 섹션을 편집합니다:

VPC 아래에서 드롭다운 목록에서 gitlab-vpc를 선택합니다.

• Subnet 아래에서 이전에 생성한 공개 서브넷(gitlab-public-10.0.0.0)을 선택합니다.

• Auto-assign Public IP 아래에서 Disabled가 선택되어 있는지 확인합니다. 다음 섹션에서 호스트에 Elastic IP 주소를 할당합니다.

• Firewall 아래에서 Create security group을 선택하고 Security group name을 입력(bastion-sec-group 사용)하고 설명을 추가합니다.

• 어디서나(0.0.0.0/0) SSH 액세스를 활성화합니다. 보안을 강화하려면 단일 IP 주소 또는 CIDR 표기법의 IP 주소 범위를 지정합니다.

• 스토리지의 경우 모든 것을 기본값으로 두고 8GB 루트 볼륨만 추가합니다. 이 인스턴스에는 데이터를 저장하지 않습니다.

• 모든 설정을 검토하고 완료되면 Launch Instance를 선택합니다.

Bastion Host A에 Elastic IP 할당#

• EC2 대시보드로 이동하여 Network & Security를 선택합니다.

• Elastic IPs를 선택하고 Network border group을 us-west-2로 설정합니다.

• Allocate를 선택합니다.

• 생성된 Elastic IP 주소를 선택합니다.

• Actions를 선택하고 Associate Elastic IP address를 선택합니다.

• Resource Type 아래에서 Instance를 선택하고 Instance 드롭다운 목록에서 Bastion Host A 호스트를 선택합니다.

• Associate를 선택합니다.

인스턴스에 SSH 접속 확인#

• EC2 대시보드에서 왼쪽 메뉴의 Instances를 선택합니다.

• 인스턴스 목록에서 Bastion Host A를 선택합니다.

• Connect를 선택하고 연결 지침을 따릅니다.

• 성공적으로 연결할 수 있으면 중복성을 위해 두 번째 bastion host 설정으로 진행합니다.

Bastion Host B 생성#

• 이전에 사용한 것과 동일한 단계에 따라 EC2 인스턴스를 생성하되 다음 변경 사항을 적용합니다:

Subnet의 경우 이전에 생성한 두 번째 공개 서브넷(gitlab-public-10.0.2.0)을 선택합니다.

• Add Tags 섹션에서 Key: Name과 Value: Bastion Host B를 설정하여 두 인스턴스를 구분합니다.

• 보안 그룹의 경우 이전에 생성한 기존 bastion-sec-group을 선택합니다.

SSH Agent Forwarding 사용#

Linux를 실행하는 EC2 인스턴스는 SSH 인증에 개인 키 파일을 사용합니다. SSH 클라이언트와 클라이언트에 저장된 개인 키 파일을 사용하여 bastion host에 연결합니다. 개인 키 파일이 bastion host에 없으므로 사설 서브넷의 인스턴스에 연결할 수 없습니다.

개인 키 파일을 bastion host에 저장하는 것은 좋지 않습니다. 이를 해결하려면 클라이언트에서 SSH Agent Forwarding을 사용합니다.

예를 들어, 명령줄 ssh 클라이언트는 다음과 같이 -A 스위치로 Agent Forwarding을 사용합니다:

ssh -A user@<bastion-public-IP-address>

다른 클라이언트에서 SSH Agent Forwarding을 사용하는 방법에 대한 단계별 가이드는 개인 Amazon VPC에서 실행 중인 Linux 인스턴스에 안전하게 연결을 참조하세요.

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

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

GitLab 설치#

EC2 대시보드에서:

• 올바른 AMI를 찾기 위해 AWS에서 공식 GitLab 생성 AMI ID 찾기 섹션을 사용하고 Launch를 선택합니다.

• Name and tags 섹션에서 Name을 GitLab으로 설정합니다.

• Instance type 드롭다운 목록에서 워크로드에 따른 인스턴스 유형을 선택합니다. 적절한 인스턴스를 선택하려면 하드웨어 요구 사항을 참조하세요(100명의 사용자를 수용하기에 충분한 최소 c5.2xlarge).

• Key pair 섹션에서 Create new key pair를 선택합니다.

키 페어에 이름을 지정하고(gitlab 사용) 나중에 사용할 수 있도록 gitlab.pem 파일을 저장합니다.

• Network settings 섹션에서:

VPC: 이전에 생성한 VPC인 gitlab-vpc를 선택합니다.

• Subnet: 이전에 생성한 서브넷 목록에서 gitlab-private-10.0.1.0을 선택합니다.

• Auto-assign Public IP: Disable을 선택합니다.

• Firewall: Select existing security group을 선택하고 이전에 생성한 gitlab-loadbalancer-sec-group을 선택합니다.

• 스토리지의 경우 루트 볼륨은 기본적으로 8GiB이며 데이터를 저장하지 않으므로 충분합니다.

• 모든 설정을 검토하고 완료되면 Launch Instance를 선택합니다.

사용자 정의 구성 추가#

SSH Agent Forwarding을 사용하여 Bastion Host A를 통해 GitLab 인스턴스에 연결합니다. 연결되면 다음 사용자 정의 구성을 추가합니다:

Let's Encrypt 비활성화#

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

• /etc/gitlab/gitlab.rb를 열고 비활성화합니다:

letsencrypt['enable'] = false

• 파일을 저장하고 변경 사항을 적용하기 위해 reconfigure를 실행합니다:

sudo gitlab-ctl reconfigure

PostgreSQL에 필요한 확장 기능 설치#

GitLab 인스턴스에서 RDS 인스턴스에 연결하여 액세스를 확인하고 필요한 pg_trgm 및 btree_gist 확장 기능을 설치합니다.

호스트 또는 엔드포인트를 찾으려면 Amazon RDS > Databases로 이동하여 이전에 생성한 데이터베이스를 선택합니다. 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

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

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

• 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>"

• 다음으로 호스트를 추가하고 포트를 주석 해제하여 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

• 마지막으로 변경 사항을 적용하기 위해 GitLab을 reconfigure합니다:

sudo gitlab-ctl reconfigure

• 모든 것이 올바르게 설정되었는지 확인하기 위해 체크와 서비스 상태를 실행할 수도 있습니다:

sudo gitlab-rake gitlab:check
sudo gitlab-ctl status

Gitaly 설정#

이 아키텍처에서 단일 Gitaly 서버는 단일 장애 지점을 생성합니다. 이 제한을 제거하려면 Gitaly Cluster (Praefect)를 사용하세요.

Gitaly는 Git 저장소에 대한 고수준 RPC 액세스를 제공하는 서비스입니다. 이전에 구성한 사설 서브넷 중 하나에 있는 별도의 EC2 인스턴스에서 활성화하고 구성해야 합니다.

Gitaly를 설치할 EC2 인스턴스를 생성합니다:

• EC2 대시보드에서 Launch instance를 선택합니다.

• Name and tags 섹션에서 Name을 Gitaly로 설정합니다.

• AMI를 선택합니다. 이 예에서는 최신 Ubuntu Server LTS (HVM), SSD Volume Type을 선택합니다. 최신 지원되는 OS 버전을 위해 GitLab 문서를 확인하세요.

• 인스턴스 유형을 선택합니다. m5.xlarge를 선택합니다.

• Key pair 섹션에서 Create new key pair를 선택합니다.

키 페어에 이름을 지정하고(gitaly 사용) 나중에 사용할 수 있도록 gitaly.pem 파일을 저장합니다.

• Network settings 섹션에서:

VPC 아래에서 드롭다운 목록에서 gitlab-vpc를 선택합니다.

• Subnet 아래에서 이전에 생성한 사설 서브넷(gitlab-private-10.0.1.0)을 선택합니다.

• Auto-assign Public IP 아래에서 Disable이 선택되어 있는지 확인합니다.

• Firewall 아래에서 Create security group을 선택하고 Security group name을 입력(gitlab-gitaly-sec-group)하고 설명을 추가합니다.

Custom TCP 규칙을 생성하고 Port Range에 포트 8075를 추가합니다. Source에서 gitlab-loadbalancer-sec-group을 선택합니다.

• 또한 SSH Agent Forwarding을 사용하여 Bastion host에서 연결할 수 있도록 bastion-sec-group에서 SSH에 대한 인바운드 규칙을 추가합니다.

• 루트 볼륨 크기를 20GiB로 늘리고 Volume Type을 Provisioned IOPS SSD (io1)로 변경합니다. (볼륨 크기는 임의의 값입니다. 저장소 스토리지 요구 사항에 맞는 충분히 큰 볼륨을 생성하세요.)

IOPS에 1000(20GiB x 50 IOPS)을 설정합니다. GiB당 최대 50 IOPS를 프로비저닝할 수 있습니다. 더 큰 볼륨을 선택하는 경우 IOPS를 그에 맞게 늘리세요. git과 같이 직렬화된 방식으로 많은 작은 파일이 작성되는 워크로드는 성능이 좋은 스토리지를 필요로 하므로 Provisioned IOPS SSD (io1)을 선택합니다.

• 모든 설정을 검토하고 완료되면 Launch Instance를 선택합니다.

루트 볼륨에 구성 및 저장소 데이터를 저장하는 대신 저장소 스토리지를 위한 추가 EBS 볼륨을 추가할 수도 있습니다. 이전과 동일한 안내를 따르세요. Amazon EBS 가격 페이지를 참조하세요.

이제 EC2 인스턴스가 준비되었으므로 자체 서버에서 GitLab을 설치하고 Gitaly를 설정하는 문서를 따르세요. 해당 문서의 클라이언트 설정 단계는 이전에 생성한 GitLab 인스턴스에서 수행합니다.

Elastic File System (EFS)#

GitLab의 성능에 부정적인 영향을 줄 수 있으므로 EFS를 사용하지 않는 것을 권장합니다. 자세한 내용은 클라우드 기반 파일 시스템 사용 방지 문서를 참조하세요.

EFS를 사용하기로 결정한 경우 PosixUser 속성이 생략되거나 Gitaly가 설치된 시스템의 git 사용자의 UID 및 GID로 올바르게 지정되어 있는지 확인하세요. UID와 GID는 다음 명령으로 가져올 수 있습니다:

# UID
$ id -u git

# GID
$ id -g git

또한 특히 서로 다른 자격 증명을 지정하는 경우 여러 액세스 포인트를 구성해서는 안 됩니다. Gitaly 이외의 애플리케이션이 Gitaly 스토리지 디렉터리의 권한을 조작하여 Gitaly가 올바르게 작동하지 못할 수 있습니다.

프록시 SSL 지원 추가#

로드 밸런서에서 SSL을 종료하므로 /etc/gitlab/gitlab.rb에서 이를 구성하려면 프록시 SSL 지원의 단계를 따르세요.

gitlab.rb 파일에 변경 사항을 저장한 후 sudo gitlab-ctl reconfigure를 실행하세요.

승인된 SSH 키의 빠른 조회#

GitLab에 액세스할 수 있는 사용자의 공개 SSH 키는 /var/opt/gitlab/.ssh/authorized_keys에 저장됩니다. 일반적으로 사용자가 SSH를 통해 Git 작업을 수행할 때 모든 인스턴스가 이 파일에 액세스할 수 있도록 공유 스토리지를 사용합니다. 설정에 공유 스토리지가 없으므로 GitLab 데이터베이스에서 인덱싱된 조회를 통해 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를 사용하지 않으므로 Amazon S3 버킷을 사용하여 백업, 아티팩트, LFS 객체, 업로드, 머지 리퀘스트 diff, 컨테이너 레지스트리 이미지 등을 저장합니다. 문서에는 이러한 각 데이터 유형에 대한 객체 스토리지 구성 방법과 GitLab에서 객체 스토리지 사용에 대한 기타 정보가 포함되어 있습니다.

이전에 생성한 AWS IAM 프로파일을 사용하므로 객체 스토리지를 구성할 때 AWS 액세스 키와 시크릿 액세스 키/값 쌍을 생략하세요. 대신 이전에 링크된 객체 스토리지 문서에 표시된 것처럼 구성에서 'use_iam_profile' => true를 사용합니다.

IAM 역할을 S3 액세스에 사용할 때 GitLab은 IMDSv1과 IMDSv2를 모두 지원하며 사용 가능할 때 IMDSv2를 자동으로 사용합니다.

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

---

이것으로 GitLab 인스턴스의 구성 변경이 완료됩니다. 다음으로 시작 구성과 Auto Scaling Group에 사용할 이 인스턴스를 기반으로 사용자 정의 AMI를 생성합니다.

IP 허용 목록#

이전에 생성한 gitlab-vpc의 VPC IP 주소 범위(CIDR)를 헬스 체크 엔드포인트의 IP 허용 목록에 추가해야 합니다.

• /etc/gitlab/gitlab.rb를 편집합니다:

gitlab_rails['monitoring_whitelist'] = ['127.0.0.0/8', '10.0.0.0/16']

• GitLab을 reconfigure합니다:

sudo gitlab-ctl reconfigure

Proxy Protocol#

이전에 생성한 로드 밸런서에서 Proxy Protocol이 활성화된 경우 gitlab.rb 파일에서도 이를 활성화해야 합니다.

• /etc/gitlab/gitlab.rb를 편집합니다:

nginx['proxy_protocol'] = true
nginx['real_ip_trusted_addresses'] = [ "127.0.0.0/8", "IP_OF_THE_PROXY/32"]

• GitLab을 reconfigure합니다:

sudo gitlab-ctl reconfigure

최초 로그인#

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

GitLab 설치 방법에 따라 그리고 다른 방법으로 비밀번호를 변경하지 않은 경우 기본 비밀번호는 다음 중 하나입니다:

• 공식 GitLab AMI를 사용한 경우 인스턴스 ID.

• /etc/gitlab/initial_root_password에 24시간 동안 저장되는 무작위로 생성된 비밀번호.

기본 비밀번호를 변경하려면 기본 비밀번호로 root 사용자로 로그인하고 사용자 프로파일에서 비밀번호를 변경합니다.

Auto Scaling Group이 새 인스턴스를 가동하면 사용자 이름 root와 새로 생성된 비밀번호로 로그인할 수 있습니다.

사용자 정의 AMI 생성#

EC2 대시보드에서:

• 이전에 생성한 GitLab 인스턴스를 선택합니다.

• Actions를 선택하고 Image and templates로 스크롤한 다음 Create image를 선택합니다.

• 이미지에 이름과 설명을 지정합니다(여기서는 둘 다 GitLab-Source 사용).

• 다른 모든 것은 기본값으로 두고 Create Image를 선택합니다.

이제 다음 단계에서 시작 구성을 생성하는 데 사용할 사용자 정의 AMI가 있습니다.

Auto Scaling Group 내에 GitLab 배포#

시작 템플릿 생성#

EC2 대시보드에서:

• 왼쪽 메뉴에서 Launch Templates를 선택하고 create launch template을 선택합니다.

• 시작 템플릿의 이름을 입력합니다(여기서는 gitlab-launch-template 사용).

• Launch template contents를 선택하고 My AMIs 탭을 선택합니다.

• Owned by me를 선택하고 이전에 생성한 GitLab-Source 사용자 정의 AMI를 선택합니다.

• 필요에 맞는 인스턴스 유형을 선택합니다(최소 c5.2xlarge).

• Key pair 섹션에서 Create new key pair를 선택합니다.

키 페어에 이름을 지정하고(gitlab-launch-template 사용) 나중에 사용할 수 있도록 gitlab-launch-template.pem 파일을 저장합니다.

• 루트 볼륨은 기본적으로 8GiB이며 데이터를 저장하지 않으므로 충분합니다. Configure Security Group을 선택합니다.

• Select and existing security group을 체크하고 이전에 생성한 gitlab-loadbalancer-sec-group을 선택합니다.

• Network settings 섹션에서:

Firewall: Select existing security group을 선택하고 이전에 생성한 gitlab-loadbalancer-sec-group을 선택합니다.

• Advanced details 섹션에서:

IAM instance profile: 이전에 생성한 GitLabS3Access 역할을 선택합니다.

• 모든 설정을 검토하고 완료되면 Create launch template을 선택합니다.

Auto Scaling Group 생성#

EC2 대시보드에서:

• 왼쪽 메뉴에서 Auto scaling groups를 선택하고 Create Auto Scaling group을 선택합니다.

• Group name을 입력합니다(여기서는 gitlab-auto-scaling-group 사용).

• Launch template 아래에서 이전에 생성한 시작 템플릿을 선택합니다. Next를 선택합니다.

• Network settings 섹션에서:

VPC 아래에서 드롭다운 목록에서 gitlab-vpc를 선택합니다.

• Availability Zones and subnets 아래에서 이전에 생성한 사설 서브넷(gitlab-private-10.0.1.0 및 gitlab-private-10.0.3.0)을 선택합니다.

• Next를 선택합니다.

• Load Balancing settings 섹션에서:

Attach to an existing load balancer를 선택합니다.

• Existing load balancer target groups 드롭다운 목록에서 이전에 생성한 대상 그룹을 선택합니다.

• Health Check Type에서 Turn on Elastic Load Balancing health checks 옵션을 체크합니다. Health Check Grace Period는 기본값인 300초로 둡니다.

• Next를 선택합니다.

• Group size에서 Desired capacity를 2로 설정합니다.

• Scaling settings 섹션에서:

No scaling policies를 선택합니다. 정책은 나중에 구성합니다.

• Min desired capacity: 2로 설정합니다.

• Max desired capacity: 4로 설정합니다.

• Next를 선택합니다.

• 마지막으로 알림과 태그를 원하는 대로 구성하고 변경 사항을 검토한 다음 Auto Scaling Group을 생성합니다.

• Auto Scaling Group이 생성된 후 Cloudwatch에서 스케일 업 및 다운 정책을 생성하고 할당해야 합니다.

이전에 생성한 Auto Scaling Group의 EC2 인스턴스에 대한 CPUUtilization 지표로 경보를 생성합니다.

• 다음 조건을 사용하여 스케일 업 정책을 생성합니다:

CPUUtilization이 60% 이상일 때 용량 유닛 1개 추가.

• Scaling policy name을 Scale Up Policy로 설정합니다.

• 다음 조건을 사용하여 스케일 다운 정책을 생성합니다:

CPUUtilization이 45% 이하일 때 용량 유닛 1개 제거.

• Scaling policy name을 Scale Down Policy로 설정합니다.

• 이전에 생성한 Auto Scaling Group에 새 동적 스케일링 정책을 할당합니다.

Auto Scaling Group이 생성되면 EC2 대시보드에서 새 인스턴스가 가동되는 것을 볼 수 있습니다. 또한 로드 밸런서에 새 인스턴스가 추가되는 것을 볼 수 있습니다. 인스턴스가 헬스 체크를 통과하면 로드 밸런서에서 트래픽을 받을 준비가 됩니다.

인스턴스는 Auto Scaling Group에 의해 생성되므로 인스턴스로 돌아가서 이전에 수동으로 생성한 인스턴스를 종료합니다. 이 인스턴스는 사용자 정의 AMI를 생성하기 위해서만 필요했습니다.

Prometheus를 통한 헬스 체크 및 모니터링#

다양한 서비스에서 활성화할 수 있는 Amazon CloudWatch 외에도 GitLab은 Prometheus를 기반으로 하는 자체 통합 모니터링 솔루션을 제공합니다. 설정 방법에 대한 자세한 내용은 GitLab Prometheus를 참조하세요.

GitLab에는 ping하고 보고서를 받을 수 있는 다양한 헬스 체크 엔드포인트도 있습니다.

GitLab Runner#

GitLab CI/CD를 활용하려면 최소 하나의 Runner를 설정해야 합니다.

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

백업 및 복구#

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

알아야 할 중요한 사항:

• 백업/복구 도구는 시크릿과 같은 일부 구성 파일을 저장하지 않습니다. 직접 구성해야 합니다.

• 기본적으로 백업 파일은 로컬에 저장되지만 S3를 사용하여 GitLab을 백업할 수 있습니다.

• 백업에서 특정 디렉터리를 제외할 수 있습니다.

GitLab 백업하기#

GitLab을 백업하려면:

• 인스턴스에 SSH로 접속합니다.

• 백업을 수행합니다:

sudo gitlab-backup create

백업에서 GitLab 복구하기#

GitLab을 복구하려면 먼저 복구 문서와 복구 전제 조건을 검토하세요. 그런 다음 Linux 패키지 설치 섹션 아래의 단계를 따르세요.

GitLab 업데이트#

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

• 인스턴스에 SSH로 접속합니다.

• 백업을 수행합니다:

sudo gitlab-backup create

• 저장소를 업데이트하고 GitLab을 설치합니다:

sudo apt update
sudo apt install gitlab-ee

몇 분 후에 새 버전이 실행되어야 합니다.

AWS에서 공식 GitLab 생성 AMI ID 찾기#

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

결론#

이 가이드에서는 주로 스케일링과 일부 중복성 옵션을 다루었으며, 실제 결과는 다를 수 있습니다.

모든 솔루션에는 비용/복잡성과 가용 시간 사이의 트레이드오프가 있다는 점을 기억하세요. 더 높은 가용 시간을 원할수록 솔루션은 더 복잡해집니다. 솔루션이 복잡할수록 설정 및 유지 관리에 더 많은 작업이 필요합니다.

다음 리소스를 읽어보시고 추가 자료 요청을 위해 자유롭게 이슈를 열어 보세요:

• GitLab 스케일링: GitLab은 여러 가지 다양한 클러스터링 유형을 지원합니다.

• Geo 복제: Geo는 광범위하게 분산된 개발 팀을 위한 솔루션입니다.

• Linux 패키지 - GitLab 인스턴스 관리에 대해 알아야 할 모든 것.

• 라이선스 추가: 라이선스로 모든 GitLab Enterprise Edition 기능을 활성화합니다.

• 가격: 다양한 티어의 가격.

트러블슈팅#

인스턴스가 헬스 체크에 실패하는 경우#

인스턴스가 로드 밸런서의 헬스 체크에 실패하는 경우 이전에 구성한 헬스 체크 엔드포인트에서 상태 200을 반환하는지 확인합니다. 상태 302와 같은 리다이렉트를 포함한 다른 모든 상태는 헬스 체크가 실패하게 합니다.

헬스 체크가 통과하기 전에 로그인 엔드포인트의 자동 리다이렉트를 방지하려면 root 사용자의 비밀번호를 설정해야 할 수 있습니다.

메시지: 요청한 변경이 거부되었습니다 (422)#

웹 인터페이스를 통해 비밀번호를 설정하려고 할 때 이 페이지가 표시되면 gitlab.rb의 external_url이 요청을 보내는 도메인과 일치하는지 확인하고 변경 후 sudo gitlab-ctl reconfigure를 실행합니다.

일부 작업 로그가 객체 스토리지에 업로드되지 않는 경우#

GitLab 배포가 두 개 이상의 노드로 스케일 업되면 일부 작업 로그가 객체 스토리지에 제대로 업로드되지 않을 수 있습니다. CI가 객체 스토리지를 사용하려면 증분 로깅이 필요합니다.