이 페이지는 공식 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를 지원하는 최소 규모입니다. 이 규모는 Git 리포지터리 스토리지를 위한 HA를 달성하기 위해 Gitaly Cluster (Praefect)를 사용하고 삼중 이중화를 지정하는 등 HA를 달성하기 위한 추가 서비스 역할이 있습니다.

GitLab은 두 가지 주요 유형의 레퍼런스 아키텍처를 유지 관리하고 테스트합니다. Linux 패키지 아키텍처는 인스턴스 컴퓨팅에서 구현되고 Cloud Native Hybrid 아키텍처는 쿠버네티스 클러스터 사용을 최대화합니다. Cloud Native Hybrid 레퍼런스 아키텍처 사양은 Linux 패키지 아키텍처 설명으로 시작하는 레퍼런스 아키텍처 크기 페이지의 부록 섹션입니다. 예를 들어, 60 RPS 또는 3,000 사용자 Cloud Native 레퍼런스 아키텍처는 60 RPS 또는 3,000 사용자 레퍼런스 아키텍처 페이지의 Helm Charts를 사용한 Cloud Native Hybrid 레퍼런스 아키텍처(대안) 하위 섹션에 있습니다.

프로덕션 수준 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 등에 사용합니다.

GitLab Environment Toolkit을 사용하여 AWS에 Cloud Native Hybrid 환경을 배포할 수 있습니다. 그러나 필수는 아니며 모든 유효한 조합을 지원하지 않을 수도 있습니다. 스크립트는 있는 그대로 제공되며 필요에 맞게 조정할 수 있습니다.

소개#

이 설정에서 주로 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 인증서. 아직 없다면 생성할 Elastic Load Balancer에 사용하기 위해 AWS Certificate Manager(ACM)를 통해 무료 공개 SSL/TLS 인증서를 프로비저닝할 수 있습니다.

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

아키텍처#

다음 다이어그램은 권장 아키텍처를 설명합니다.

[

](/19.1/install/aws/img/aws_ha_architecture_diagram_v17_0.png)

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-*"
        }
    ]
}

외부 프로세스가 S3 버킷의 오브젝트에 태그를 지정하는 경우(예: AWS GuardDuty 맬웨어 방지), 소스 버킷의 오브젝트 수준 Action 목록에 s3:GetObjectTagging을 추가하고 대상 버킷에 s3:PutObjectTagging을 추가하세요. 이 권한이 없으면 태그가 지정된 오브젝트를 복사할 때 GitLab CopyObject 작업이 AccessDenied로 실패합니다.

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 Version 2(IMDSv2)를 지원합니다. GitLab은 사용 가능한 경우 자동으로 IMDSv2를 사용하고, 필요한 경우 IMDSv1로 폴백합니다. 보안 강화를 위해 EC2 인스턴스에서 IMDSv2를 안전하게 요구할 수 있습니다.

네트워크 구성#

GitLab 클라우드 인프라를 위한 VPC를 생성하는 것부터 시작합니다. 그런 다음 최소 두 개의 가용 영역(AZ)에서 퍼블릭 및 프라이빗 인스턴스를 갖기 위한 서브넷을 생성할 수 있습니다. 퍼블릭 서브넷에는 라우팅 테이블과 연결된 인터넷 게이트웨이가 필요합니다.

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를 선택합니다.

[

](/19.1/install/aws/img/create_vpc_v17_0.png)

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

서브넷#

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

로드 밸런서 및 RDS 인스턴스와도 일치시키기 위해 프라이빗 및 퍼블릭 서브넷을 생성합니다:

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

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

[

](/19.1/install/aws/img/create_subnet_v17_0.png)

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

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

각 퍼블릭 서브넷을 순서대로 선택하고 Actions를 선택한 후 Edit subnet settings를 선택합니다. Enable auto-assign public IPv4 address 옵션을 체크하고 저장합니다.

인터넷 게이트웨이#

이제 동일한 대시보드에서 인터넷 게이트웨이로 이동하여 새 게이트웨이를 생성합니다:

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

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

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

[

](/19.1/install/aws/img/create_gateway_v17_0.png)

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

NAT 게이트웨이 생성#

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

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

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

Availability mode: Zonal을 선택합니다.

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

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

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

• Create NAT Gateway를 선택합니다.

두 번째 NAT 게이트웨이를 생성하되 이번에는 두 번째 퍼블릭 서브넷 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 게이트웨이를 통해 인터넷에 접근할 수 있도록 두 개의 프라이빗 라우팅 테이블도 생성해야 합니다.

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

• 다음으로, 대상이 0.0.0.0/0이고 타깃이 이전에 생성한 NAT 게이트웨이 중 하나인 새 경로를 각 프라이빗 라우팅 테이블에 추가합니다.

gitlab-public-10.0.0.0에 생성한 NAT 게이트웨이를 gitlab-private-a 라우팅 테이블의 새 경로 타깃으로 추가합니다.

• 마찬가지로, gitlab-public-10.0.2.0에 있는 NAT 게이트웨이를 gitlab-private-b의 새 경로 타깃으로 추가합니다.

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

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

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

로드 밸런서#

GitLab 애플리케이션 서버 전체에 인바운드 트래픽을 고르게 분산하기 위해 로드 밸런서를 생성합니다. 나중에 생성할 스케일링 정책에 따라 필요에 따라 로드 밸런서에서 인스턴스가 추가되거나 제거됩니다. 또한 로드 밸런서는 인스턴스에 대한 헬스 체크를 수행합니다.

AWS는 이 아키텍처에 두 가지 접근 방식을 제공합니다:

• Network Load Balancer(NLB) 전용: 소규모 배포에 적합한 더 간단한 설정입니다. NLB는 모든 트래픽(포트 22의 SSH, 포트 80의 HTTP, 포트 443의 HTTPS)을 Rails 노드로 직접 처리하며, NLB에서 SSL/TLS 종료가 이루어집니다.

• 하이브리드 NLB->ALB 접근 방식: 관심사를 분리하는 더 확장 가능한 설정입니다. NLB는 TCP 트래픽(포트 22의 SSH)을 처리하고, Application Load Balancer(ALB)는 SSL/TLS 종료와 함께 HTTP/HTTPS 트래픽을 처리합니다. 이 접근 방식은 AWS WAF 통합과 더 나은 트래픽 관리를 가능하게 합니다.

배포에 가장 적합한 접근 방식을 선택하세요:

NLB 전용:

graph TB subgraph Diagram1["NLB Only"] U1["Users"] NLB1["Network Load Balancer
(Port 22, 80, 443)"] R1A["Rails Node 1
(Port 22, 80)"] R1B["Rails Node 2
(Port 22, 80)"]

  U1 -->|SSH| NLB1
  U1 -->|HTTP| NLB1
  U1 -->|HTTPS| NLB1
  NLB1 -->|Port 22| R1A
  NLB1 -->|Port 22| R1B
  NLB1 -->|"Port 80, 443"| R1A
  NLB1 -->|"Port 80, 443"| R1B

end

하이브리드 NLB/ALB:

graph TB subgraph Diagram2["Hybrid NLB/ALB"] U2["Users"] NLB2["Network Load Balancer
(Port 22, 443)"] ALB["Application Load Balancer
(Port 443)"] R2A["Rails Node 1
(Port 22, 80)"] R2B["Rails Node 2
(Port 22, 80)"]

    U2 -->|SSH| NLB2
    U2 -->|HTTPS| NLB2
    NLB2 -->|Port 22| R2A
    NLB2 -->|Port 22| R2B
    NLB2 -->|Port 443| ALB
    ALB -->|Port 80| R2A
    ALB -->|Port 80| R2B
end

Network Load Balancer(NLB) 전용

이 섹션에서는 단일 Network Load Balancer가 모든 트래픽 유형을 처리하고, SSH, HTTP 및 HTTPS를 Rails 노드로 직접 라우팅하는 더 간단한 NLB 전용 접근 방식을 설명합니다.

이 아키텍처에는 보안 그룹이 필요합니다:

• NLB 보안 그룹 (gitlab-nlb-sec-group):

인바운드: 어디서나 TCP 포트 22 (또는 SSH에 대한 신뢰할 수 있는 IP 범위로 제한)

• 인바운드: 어디서나 TCP 포트 80

• 인바운드: 어디서나 TCP 포트 443

• 아웃바운드: 모든 트래픽

이 보안 그룹을 생성하려면:

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

• Create security group을 선택합니다.

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

• 위에서 지정한 대로 인바운드 규칙을 추가합니다.

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

타깃 그룹을 생성합니다:

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

SSH 타깃 그룹에 대해 Create target group을 선택합니다:

Next를 두 번 선택한 다음 Create target group을 선택합니다. 타깃은 나중에 등록합니다.

HTTP 타깃 그룹에 대해 다시 Create target group을 선택합니다:

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

Next를 선택하고 Register Later를 선택한 다음 Next를 두 번 선택하고 Create target group을 선택합니다.

Network Load Balancer를 생성합니다:

EC2 대시보드에서 왼쪽 탐색 바의 Load Balancers를 찾아 Create Load Balancer를 선택합니다.

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

다음 설정으로 로드 밸런서를 구성합니다:

Listeners and routing 섹션에서 다음을 구성합니다:

포트 443의 TLS 리스너의 경우 Security Policy 설정에서:

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

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

Create load balancer를 선택합니다.

gitlab-nlb-ssh-target 및 gitlab-nlb-http-target 타깃 그룹의 타깃은 이 가이드의 뒷부분에서 생성하는 Auto Scaling Group에서 인스턴스가 시작될 때 자동으로 등록됩니다.

하이브리드 NLB->ALB 접근 방식

이 섹션에서는 Network Load Balancer가 SSH 트래픽을 처리하고 Application Load Balancer가 HTTP/HTTPS 트래픽을 처리하는 하이브리드 접근 방식을 설명합니다. NLB는 TCP 포트 22(SSH)를 Rails 노드로 직접 라우팅하고 TCP 포트 443(HTTPS)을 ALB로 라우팅하며, ALB는 SSL/TLS를 종료하고 HTTP 트래픽을 포트 80의 Rails 노드로 라우팅합니다. 이 접근 방식은 AWS WAF 통합과 관심사의 더 나은 분리를 가능하게 합니다.

이 아키텍처에는 세 가지 보안 그룹이 필요합니다:

NLB 보안 그룹 (gitlab-nlb-sec-group):

인바운드: 어디서나 TCP 포트 22 (또는 SSH에 대한 신뢰할 수 있는 IP 범위로 제한)

• 인바운드: 어디서나 TCP 포트 443 (또는 HTTPS에 대한 신뢰할 수 있는 IP 범위로 제한)

• 아웃바운드: gitlab-rails-sec-group으로 TCP 포트 22

• 아웃바운드: gitlab-alb-sec-group으로 TCP 포트 443

ALB 보안 그룹 (gitlab-alb-sec-group):

인바운드: gitlab-nlb-sec-group에서 TCP 포트 443

• 인바운드: gitlab-rails-sec-group에서 TCP 포트 80

• 아웃바운드: gitlab-rails-sec-group으로 TCP 포트 80

Rails 보안 그룹 (gitlab-rails-sec-group):

인바운드: gitlab-nlb-sec-group에서 TCP 포트 22

• 인바운드: gitlab-alb-sec-group에서 TCP 포트 80

이 보안 그룹을 생성하려면:

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

• SSH 타깃 그룹에 대해 Create security group을 선택합니다:

• 각각에 설명적인 이름과 설명을 지정하고 VPC 드롭다운 목록에서 gitlab-vpc를 선택합니다.

• 위에서 지정한 대로 인바운드 규칙을 추가합니다. 소스를 선택할 때 Security group을 선택하고 드롭다운에서 적절한 보안 그룹을 선택합니다.

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

타깃 그룹을 생성합니다:

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

다음 설정으로 NLB SSH 타깃 그룹을 생성합니다:

Next를 두 번 선택한 다음 Create target group을 선택합니다. 타깃은 나중에 등록합니다.

NLB에서 ALB로의 타깃 그룹에 대해 다시 Create target group을 선택합니다:

Next를 선택하고 Application Load Balancer에 대해 Register Later를 선택한 다음 Next를 선택하고 Create target group을 선택합니다.

ALB HTTP 타깃 그룹에 대해 다시 Create target group을 선택합니다:

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

Next를 선택하고 Register Later를 선택한 다음 Next를 두 번 선택하고 Create target group을 선택합니다.

Application Load Balancer를 생성합니다:

EC2 대시보드에서 왼쪽 탐색 바의 Load Balancers를 찾아 Create Load Balancer를 선택합니다.

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

다음 설정으로 로드 밸런서를 구성합니다:

Listeners and routing 섹션에서 다음을 구성합니다:

HTTPS 리스너의 경우 ACM 인증서를 선택하고 적절한 보안 정책을 선택합니다(Application Load Balancer용 사전 정의 SSL 보안 정책 참조).

Create load balancer를 선택합니다.

Network Load Balancer를 생성합니다:

EC2 대시보드에서 왼쪽 탐색 바의 Load Balancers를 찾아 Create Load Balancer를 선택합니다.

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

다음 설정으로 로드 밸런서를 구성합니다:

Listeners and routing 섹션에서 다음을 구성합니다:

Create load balancer를 선택합니다.

ALB를 NLB의 타깃으로 등록합니다:

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

• gitlab-nlb-alb-target 타깃 그룹을 선택합니다.

• Targets 탭에서 Register targets를 선택합니다.

• gitlab-alb Application Load Balancer를 선택하고 Register pending targets를 선택합니다.

• Save를 선택합니다.

gitlab-nlb-ssh-target 및 gitlab-alb-http-target 타깃 그룹의 타깃은 이 가이드의 뒷부분에서 생성하는 Auto Scaling Group에서 인스턴스가 시작될 때 자동으로 등록됩니다.

NLB 로드 밸런서가 가동되어 실행 중이면 보안 그룹을 재검토하여 NLB를 통해서만 액세스를 제한하고 필요한 다른 요구 사항을 적용할 수 있습니다.

일부 속성은 로드 밸런서가 생성된 후에만 구성할 수 있습니다. 요구 사항에 따라 구성할 수 있는 몇 가지 기능은 다음과 같습니다:

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

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

로드 밸런서용 DNS 구성#

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

• 기존 호스팅 영역을 선택하거나 도메인에 대한 호스팅 영역이 없는 경우 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 레코드로 추가합니다. 이 단계는 도메인 등록 기관마다 다를 수 있습니다. 막혔다면 Google에서 "등록 기관 이름" add DNS records를 검색하면 해당 도메인 등록 기관에 대한 도움말을 찾을 수 있습니다.

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

RDS를 사용한 PostgreSQL#

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

RDS 보안 그룹#

나중에 gitlab-nlb-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: 로드 밸런서 접근 방식에 따라 적절한 보안 그룹을 선택합니다:

NLB 전용: gitlab-nlb-sec-group

• 하이브리드 NLB->ALB: gitlab-rails-sec-group

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

RDS 서브넷 그룹#

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

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

• Subnet group details에서 이름(여기서는 gitlab-rds-group 사용), 설명을 입력하고 VPC 드롭다운 목록에서 gitlab-vpc를 선택합니다.

• Availability Zones 드롭다운 목록에서 구성한 서브넷이 포함된 가용 영역을 선택합니다. 여기서는 us-west-2a와 us-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에서 다른 가용 영역에 스탠바이 RDS 인스턴스를 프로비저닝하기 위해 Multi-AZ DB instance를 선택합니다.

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" 소스를 설정합니다:

NLB 전용: gitlab-nlb-sec-group

• 하이브리드 NLB->ALB: gitlab-rails-sec-group

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

Redis 서브넷 그룹#

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

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

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

[

](/19.1/install/aws/img/ec_subnet_v17_0.png)

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 옵션을 활성화합니다.

클러스터 설정 섹션에서:

엔진 버전은 Redis 요구 사항에서 GitLab 버전에 대해 정의된 Redis 버전을 선택합니다.

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

• 노드 유형(최소 cache.t3.medium이지만 필요에 맞게 조정)과 복제본 수를 선택합니다.

연결 설정 섹션에서:

Network type: IPv4

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

가용 영역 배치 섹션에서:

선호하는 가용 영역을 수동으로 선택하고 "Replica 2"에서 다른 두 영역과 다른 영역을 선택합니다.

[

](/19.1/install/aws/img/ec_az_v17_0.png)

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 파일을 저장합니다.

• 네트워크 설정 섹션을 편집합니다:

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 주소 범위를 지정합니다.

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

• 모든 설정을 검토하고 만족스러우면 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 에이전트 포워딩 사용#

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

프라이빗 키 파일을 bastion host에 저장하는 것은 좋지 않습니다. 이 문제를 해결하기 위해 클라이언트에서 SSH 에이전트 포워딩을 사용합니다.

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

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

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

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

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

GitLab 설치#

EC2 대시보드에서:

• 아래의 AWS에서 공식 GitLab이 생성한 AMI ID 찾기 섹션을 사용하여 올바른 AMI를 찾고 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을 선택하고 로드 밸런서 접근 방식에 따라 적절한 보안 그룹을 선택합니다:

NLB 전용: gitlab-nlb-sec-group과 bastion-sec-group

• 하이브리드 NLB->ALB: gitlab-rails-sec-group과 bastion-sec-group

bastion-sec-group은 SSH 에이전트 포워딩을 사용하여 관리 및 구성 작업을 위해 bastion host에서 SSH 액세스를 허용합니다.

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

• 모든 설정을 검토하고 만족스러우면 Launch Instance를 선택합니다.

사용자 정의 구성 추가#

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

Let's Encrypt 비활성화#

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

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

letsencrypt['enable'] = false

파일을 저장하고 변경 사항이 적용되도록 재구성합니다:

sudo gitlab-ctl reconfigure

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

gitlab 사용자에게 rds_superuser 권한이 있는 경우 GitLab이 필요한 확장 기능을 자동으로 설치할 수 있습니다. 이 경우 아래의 수동 단계가 필요하지 않습니다.

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

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

-h의 경우 RDS 엔드포인트 호스트 이름만 사용하고 후행 콜론과 포트 번호를 생략합니다:

sudo /opt/gitlab/embedded/bin/psql -U gitlab -h <rds-endpoint> -d gitlabhq_production

그런 다음 CREATE EXTENSION을 사용하여 각 필요한 확장 기능을 설치합니다:

CREATE EXTENSION IF NOT EXISTS btree_gist;
CREATE EXTENSION IF NOT EXISTS ...;

\dx로 설치된 확장 기능을 확인합니다.

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

/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

# Adjust based on your Redis setting
gitlab_rails['redis_ssl'] = true

마지막으로 변경 사항이 적용되도록 GitLab을 재구성합니다:

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 파일을 저장합니다.

• 네트워크 설정 섹션에서:

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의 경우 로드 밸런서 접근 방식에 따라 적절한 보안 그룹을 선택합니다:

NLB 전용: gitlab-nlb-sec-group

• 하이브리드 NLB->ALB: gitlab-rails-sec-group

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

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

IOPS는 1000으로 설정합니다(20 GiB 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)#

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

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

# UID
id -u git

# GID
id -g git

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

프록시 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를 사용하지 않으므로 백업, 아티팩트, LFS 오브젝트, 업로드, 머지 리퀘스트 diff, 컨테이너 레지스트리 이미지 등을 저장하기 위해 Amazon S3 버킷을 사용합니다. 문서에는 이러한 각 데이터 유형에 대한 오브젝트 스토리지 구성 방법과 GitLab에서 오브젝트 스토리지 사용에 대한 기타 정보가 있습니다.

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

S3 액세스에 IAM 역할을 사용하는 경우 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을 재구성합니다:

sudo gitlab-ctl reconfigure

프록시 프로토콜#

이전에 생성한 로드 밸런서에서 프록시 프로토콜이 활성화된 경우 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을 재구성합니다:

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 파일을 저장합니다.

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

Select existing security group을 체크하고 로드 밸런서 접근 방식에 따라 적절한 보안 그룹을 선택합니다:

NLB 전용: gitlab-nlb-sec-group과 bastion-sec-group

• 하이브리드 NLB->ALB: gitlab-rails-sec-group과 bastion-sec-group

bastion-sec-group은 SSH 에이전트 포워딩을 사용하여 관리 및 구성 작업을 위해 bastion host에서 SSH 액세스를 허용합니다.

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를 선택합니다.

네트워크 설정 섹션에서:

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

• Availability Zones and subnets에서 이전에 생성한 프라이빗 서브넷(gitlab-private-10.0.1.0과 gitlab-private-10.0.3.0)을 선택합니다.

• Next를 선택합니다.

로드 밸런싱 설정 섹션에서:

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

• Existing load balancer target groups 드롭다운 목록에서 로드 밸런서 접근 방식에 따라 적절한 타깃 그룹을 선택합니다:

NLB 전용: gitlab-nlb-ssh-target과 gitlab-nlb-http-target을 선택합니다.

• 하이브리드 NLB->ALB: gitlab-nlb-ssh-target과 gitlab-alb-http-target을 선택합니다. Auto Scaling Group은 시작된 모든 인스턴스를 이 타깃 그룹에 자동으로 등록합니다.

• Health Check Type의 경우 Turn on Elastic Load Balancing health checks 옵션을 체크합니다. Health Check Grace Period는 기본값 300초로 유지합니다.

• Next를 선택합니다.

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

스케일링 설정 섹션에서:

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로 설정합니다.

[

](/19.1/install/aws/img/scale_up_policy_v17_0.png)

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

CPUUtilization이 45% 이하일 때 용량 단위를 1 제거합니다.

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

[

](/19.1/install/aws/img/scale_down_policy_v17_0.png)

• 이전에 생성한 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를 활용하려면 최소 하나의 러너를 설정해야 합니다.

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 찾기#

AMI로서의 GitLab 릴리즈 사용 방법에 대해 자세히 읽어보세요.

결론#

이 가이드에서 주로 스케일링과 일부 중복성 옵션을 살펴보았으며 실제 상황은 다를 수 있습니다.

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

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

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

• Geo 복제: Geo는 널리 분산된 개발 팀을 위한 솔루션입니다.

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

• 라이선스 추가: 라이선스로 모든 GitLab Enterprise Edition 기능을 활성화하세요.

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

문제 해결#

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

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

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

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

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

일부 job 로그가 오브젝트 스토리지에 업로드되지 않는 경우#

GitLab 배포가 하나 이상의 노드로 스케일 업되면 일부 job 로그가 오브젝트 스토리지에 제대로 업로드되지 않을 수 있습니다. CI에서 오브젝트 스토리지를 사용하려면 증분 로깅이 필요합니다.