Amazon Web Services(AWS)에 GitLab POC 설치

요약

이 페이지는 공식 Linux 패키지를 사용해 AWS에 GitLab을 구성하는 일반적인 방법을 단계별로 안내합니다. 사용자가 1,000명 이하인 조직에서는 EC2 단일 박스에 Linux 패키지 설치를 수행하고 데이터 백업을 위한 스냅샷 전략을 적용하는 방식을 AWS 설치 방법으로 권장합니다.

이 페이지는 공식 Linux 패키지를 사용해 AWS에 GitLab을 구성하는 일반적인 방법을 단계별로 안내합니다. 환경에 맞게 조정해 사용합니다.

Note

사용자가 1,000명 이하인 조직에서는 EC2 단일 박스에 Linux 패키지 설치를 수행하고 데이터 백업을 위한 스냅샷 전략을 적용하는 방식을 AWS 설치 방법으로 권장합니다.

프로덕션 등급 GitLab 시작하기#

Note

이 문서는 개념 증명(Proof of Concept) 단계의 안내서입니다. 이 문서만으로는 고가용성 구성이 완성되지 않습니다.

이 가이드를 그대로 따르면 HA가 아닌 인스턴스가 만들어집니다. AWS에서 프로덕션 등급으로 배포하려면 참조 아키텍처에서 규모에 맞는 구성을 확인합니다. 참조 아키텍처는 Linux 패키지(VM 기반)와 클라우드 네이티브(Kubernetes) 배포 유형을 모두 다룹니다.

개요#

이 구성에서는 대부분 Linux 패키지를 사용하지만 AWS의 네이티브 서비스도 함께 활용합니다. Linux 패키지에 번들된 PostgreSQL과 Redis 대신 Amazon RDS와 ElastiCache를 사용합니다.

이 가이드에서는 다중 노드 구성을 다룹니다. 먼저 Virtual Private Cloud와 서브넷을 구성한 다음, 데이터베이스 서버용 RDS와 Redis 클러스터용 ElastiCache 같은 서비스를 통합하고, 마지막으로 사용자 지정 스케일링 정책을 적용한 오토 스케일링 그룹에서 이들을 관리합니다.

요구 사항#

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

AWS 계정
SSH로 인스턴스에 접속하기 위한 SSH 키 생성 또는 업로드
GitLab 인스턴스용 도메인 이름
도메인을 보호할 SSL/TLS 인증서. 보유한 인증서가 없다면 AWS Certificate Manager(ACM)에서 무료 퍼블릭 SSL/TLS 인증서를 발급받아 이후에 생성하는 Elastic Load Balancer에 사용할 수 있습니다.

Note

ACM에서 발급하는 인증서는 검증에 몇 시간이 걸릴 수 있습니다. 이후 단계에서 지연되지 않도록 인증서를 가능한 한 빨리 요청합니다.

아키텍처#

권장 아키텍처는 다음 다이어그램과 같습니다.

가용 영역 2개로 축소한 비 HA AWS 아키텍처.

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 키를 직접 넣지 않기 위해 IAM 역할을 사용해 GitLab 인스턴스에 이 접근 권한을 부여합니다. 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-*"
        }
    ]
}

[!note] 외부 프로세스가 S3 버킷의 객체에 태그를 지정하는 경우(예: AWS GuardDuty Malware Protection) 소스 버킷에는 객체 수준 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을 선택합니다.

이 역할은 이후 시작 템플릿 생성 단계에서 사용합니다.

Note

GitLab은 AWS Instance Metadata Service Version 2(IMDSv2)를 지원합니다. GitLab은 IMDSv2를 사용할 수 있으면 자동으로 사용하고, 필요하면 IMDSv1로 대체합니다. 보안 강화를 위해 EC2 인스턴스에서 IMDSv2를 필수로 지정해도 문제가 없습니다.

네트워크 구성#

먼저 GitLab 클라우드 인프라용 VPC를 생성한 다음, 최소 두 개의 가용 영역(Availability Zone, 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를 선택합니다.
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를 지정합니다.

같은 방법으로 모든 서브넷을 생성합니다.

이름 태그	유형	가용 영역	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`

모든 서브넷을 생성한 다음, 두 퍼블릭 서브넷에서 Auto-assign IPv4를 활성화합니다.
1. 각 퍼블릭 서브넷을 차례로 선택하고 Actions, Edit subnet settings를 선택합니다. Enable auto-assign public IPv4 address 옵션을 선택하고 저장합니다.

인터넷 게이트웨이#

이제 같은 대시보드에서 Internet Gateways로 이동해 새 게이트웨이를 생성합니다.

왼쪽 메뉴에서 Internet Gateways를 선택합니다.
Create internet gateway를 선택하고 이름을 gitlab-gateway로 지정한 다음 Create를 선택합니다.
표에서 해당 게이트웨이를 선택한 다음 Actions 드롭다운 목록에서 "Attach to VPC" 를 선택합니다.
목록에서 gitlab-vpc를 선택하고 Attach를 선택합니다.

NAT 게이트웨이 생성#

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

VPC 대시보드로 이동해 왼쪽 메뉴 바에서 NAT Gateways를 선택합니다.
Create NAT Gateway를 선택하고 다음을 입력합니다.
1. Availability mode: Zonal을 선택합니다.
2. Subnet: 드롭다운 목록에서 gitlab-public-10.0.0.0을 선택합니다.
3. Elastic IP Allocation ID: 기존 탄력적 IP를 입력하거나 Allocate Elastic IP address를 선택해 NAT 게이트웨이에 새 IP를 할당합니다.
4. 필요하면 태그를 추가합니다.
5. 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 게이트웨이 중 하나인 새 경로를 추가합니다.
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 애플리케이션 서버에 인바운드 트래픽을 고르게 분산하기 위해 로드 밸런서를 생성합니다. 이후에 생성하는 스케일링 정책에 따라 필요한 만큼 인스턴스가 로드 밸런서에 추가되거나 제거됩니다. 또한 로드 밸런서는 인스턴스에 상태 검사를 수행합니다.

이 아키텍처에서 AWS는 두 가지 방식을 제공합니다.

Network Load Balancer(NLB) 단독: 소규모 배포에 적합한 단순한 구성입니다. NLB가 모든 트래픽(포트 22의 SSH, 포트 80의 HTTP, 포트 443의 HTTPS)을 Rails 노드로 직접 전달하며, SSL/TLS는 NLB에서 종료됩니다.
NLB->ALB 하이브리드 방식: 역할을 분리해 확장성을 높인 구성입니다. NLB는 TCP 트래픽(포트 22의 SSH)을 처리하고, Application Load Balancer(ALB)가 SSL/TLS 종료와 함께 HTTP/HTTPS 트래픽을 처리합니다. 이 방식에서는 AWS WAF 연동과 세밀한 트래픽 관리가 가능합니다.

배포 환경에 가장 적합한 방식을 선택합니다.

NLB 단독:

Mermaid 다이어그램 (15줄)

소스 코드 보기

graph TB
    subgraph Diagram1["NLB Only"]
      U1["Users"]
      NLB1["Network Load Balancer<br/>(Port 22, 80, 443)"]
      R1A["Rails Node 1<br/>(Port 22, 80)"]
      R1B["Rails Node 2<br/>(Port 22, 80)"]
  U1 --&gt;|SSH| NLB1
  U1 --&gt;|HTTP| NLB1
  U1 --&gt;|HTTPS| NLB1
  NLB1 --&gt;|Port 22| R1A
  NLB1 --&gt;|Port 22| R1B
  NLB1 --&gt;|"Port 80, 443"| R1A
  NLB1 --&gt;|"Port 80, 443"| R1B

end

NLB/ALB 하이브리드:

Mermaid 다이어그램 (16줄)

소스 코드 보기

graph TB
    subgraph Diagram2["Hybrid NLB/ALB"]
        U2["Users"]
        NLB2["Network Load Balancer<br/>(Port 22, 443)"]
        ALB["Application Load Balancer<br/>(Port 443)"]
        R2A["Rails Node 1<br/>(Port 22, 80)"]
        R2B["Rails Node 2<br/>(Port 22, 80)"]
    U2 --&gt;|SSH| NLB2
    U2 --&gt;|HTTPS| NLB2
    NLB2 --&gt;|Port 22| R2A
    NLB2 --&gt;|Port 22| R2B
    NLB2 --&gt;|Port 443| ALB
    ALB --&gt;|Port 80| R2A
    ALB --&gt;|Port 80| R2B
end</code></pre></details></div>



이 절에서는 단일 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 Target Group을 위해 Create target group을 선택합니다.



설정
값




Target type
Instances


Target group name
gitlab-nlb-ssh-target


Protocol
TCP


Port
22


VPC
gitlab-vpc


Health check protocol
TCP



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


HTTP Target Group을 위해 Create target group을 다시 선택합니다.



설정
값




Target type
Instances


Target group name
gitlab-nlb-http-target


Protocol
TCP


Port
80


VPC
gitlab-vpc


Health check protocol
HTTP


Health check path
/-/readiness




[!note]
상태 검사 엔드포인트를 위해 VPC IP 주소 범위(CIDR)를 IP 허용 목록에 추가해야 합니다.

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


네트워크 로드 밸런서를 생성합니다.


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


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


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



설정
값




Load Balancer name
gitlab-nlb


Scheme
Internet-facing


IP address type
IPv4


VPC
gitlab-vpc


Mapping
두 퍼블릭 서브넷을 모두 선택


Security group
gitlab-nlb-sec-group





Listeners and routing 섹션에서 다음과 같이 구성합니다.



프로토콜
포트
타깃 그룹




TCP
22
gitlab-nlb-ssh-target


TCP
80
gitlab-nlb-http-target


TLS
443
gitlab-nlb-http-target



포트 443의 TLS 리스너는 Security Policy 설정에서 다음을 지정합니다.

Policy name: 드롭다운 목록에서 사전 정의된 보안 정책을 선택합니다. AWS 문서의 Predefined SSL Security Policies for Network Load Balancers를 참고합니다. 지원되는 SSL 암호 및 프로토콜 목록은 GitLab 코드베이스에서 확인합니다.
Default SSL/TLS server certificate: ACM의 SSL/TLS 인증서를 선택하거나 IAM에 인증서를 업로드합니다.



Create load balancer를 선택합니다.


Note
gitlab-nlb-ssh-target과 gitlab-nlb-http-target 타깃 그룹의 타깃은 이 가이드 뒷부분에서 생성하는 오토 스케일링 그룹에서 인스턴스가 시작될 때 자동으로 등록됩니다.



이 절에서는 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 Target Group을 위해 Create security group을 선택합니다.
각각에 알아보기 쉬운 이름과 설명을 지정하고 VPC 드롭다운 목록에서 gitlab-vpc를 선택합니다.
위에 명시한 인바운드 규칙을 추가합니다. 소스를 선택할 때는 Security group을 선택하고 드롭다운에서 해당 보안 그룹을 선택합니다.
완료되면 Create security group을 선택합니다.

타깃 그룹을 생성합니다.


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


다음 설정으로 NLB SSH Target Group을 생성합니다.



설정
값




Target type
Instances


Target group name
gitlab-nlb-ssh-target


Protocol
TCP


Port
22


VPC
gitlab-vpc


Health check protocol
TCP



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


NLB to ALB Target Group을 위해 Create target group을 다시 선택합니다.



설정
값




Target type
Application Load Balancer


Target group name
gitlab-nlb-alb-target


Protocol
TCP


Port
443


VPC
gitlab-vpc


Health check protocol
HTTPS


Health check path
/-/readiness



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


ALB HTTP Target Group을 위해 Create target group을 다시 선택합니다.



설정
값




Target type
Instance


Target group name
gitlab-alb-http-target


Protocol
HTTP


Port
80


VPC
gitlab-vpc


Protocol version
HTTP1.1


Health check protocol
HTTP


Health check path
/-/readiness




[!note]
상태 검사 엔드포인트를 위해 VPC IP 주소 범위(CIDR)를 IP 허용 목록에 추가해야 합니다.

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


애플리케이션 로드 밸런서를 생성합니다.


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


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


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



설정
값




Load Balancer name
gitlab-alb


Scheme
Internet-facing


IP address type
IPv4


VPC
gitlab-vpc


Mapping
두 퍼블릭 서브넷 gitlab-public-10.0.0.0과 gitlab-public-10.0.2.0을 모두 선택


Security group
gitlab-alb-sec-group





Listeners and routing 섹션에서 다음과 같이 구성합니다.



프로토콜
포트
작업
타깃 그룹




HTTPS
443
Forward to
gitlab-alb-http-target



HTTPS 리스너에는 ACM 인증서를 선택하고 적절한 보안 정책을 선택합니다(Predefined SSL Security Policies for Application Load Balancers 참고).


Create load balancer를 선택합니다.


네트워크 로드 밸런서를 생성합니다.


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


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


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



설정
값




Load Balancer name
gitlab-nlb


Scheme
Internet-facing


IP address type
IPv4


VPC
gitlab-vpc


Mapping
두 퍼블릭 서브넷 gitlab-public-10.0.0.0과 gitlab-public-10.0.2.0을 모두 선택


Security group
gitlab-nlb-sec-group





Listeners and routing 섹션에서 다음과 같이 구성합니다.



프로토콜
포트
타깃 그룹




TCP
22
gitlab-nlb-ssh-target


TCP
443
gitlab-nlb-alb-target





Create load balancer를 선택합니다.


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

EC2 대시보드의 왼쪽 메뉴 바에서 Target Groups를 선택합니다.
gitlab-nlb-alb-target 타깃 그룹을 선택합니다.
Targets 탭에서 Register targets를 선택합니다.
gitlab-alb Application Load Balancer를 선택하고 Register pending targets를 선택합니다.
Save를 선택합니다.

Note
gitlab-nlb-ssh-target과 gitlab-alb-http-target 타깃 그룹의 타깃은 이 가이드 뒷부분에서 생성하는 오토 스케일링 그룹에서 인스턴스가 시작될 때 자동으로 등록됩니다.



NLB 로드 밸런서가 실행된 뒤에는 보안 그룹을 다시 확인해 NLB를 통한 접근만 허용하도록 조정하고 그 밖의 요구 사항을 반영할 수 있습니다.
일부 속성은 로드 밸런서를 생성한 뒤에만 구성할 수 있습니다. 요구 사항에 따라 구성할 수 있는 기능은 다음과 같습니다.

클라이언트 IP 보존은 타깃 그룹에서 기본으로 활성화되어 있습니다. 이 기능을 사용하면 로드 밸런서에 연결한 클라이언트의 IP가 GitLab 애플리케이션에 그대로 전달됩니다. 요구 사항에 따라 활성화하거나 비활성화할 수 있습니다.
프록시 프로토콜은 타깃 그룹에서 기본으로 비활성화되어 있습니다. 이 기능을 사용하면 로드 밸런서가 프록시 프로토콜 헤더에 추가 정보를 담아 전송합니다. 활성화하려면 내부 로드 밸런서, NGINX 등 환경의 다른 구성 요소도 함께 구성해야 합니다. 이 개념 증명에서는 이후 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 레코드로 추가합니다. 이 절차는 등록 기관마다 다를 수 있습니다. 진행이 어렵다면 "등록 기관 이름" add DNS records로 검색해 해당 기관의 도움말 문서를 확인합니다.



이 작업의 구체적인 절차는 사용하는 등록 기관에 따라 다르며 이 가이드의 범위를 벗어납니다.
RDS 기반 PostgreSQL#
데이터베이스 서버로는 이중화를 위해 다중 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를 선택합니다.

데이터베이스 생성#
Warning
데이터베이스에는 버스터블 인스턴스(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)를 선택할 수도 있습니다). 자세한 내용은 Storage for 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 애플리케이션의 세션 데이터, 임시 캐시 정보, 백그라운드 job 큐를 저장하는 데 사용됩니다.
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를 선택합니다.



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


배스천 호스트 설정#
GitLab 인스턴스가 프라이빗 서브넷에 있으므로, 구성 변경이나 업그레이드 같은
작업을 위해 SSH로 이 인스턴스에 접속할 방법이 필요합니다. 한 가지 방법은
점프 박스라고도 부르는 배스천 호스트를
사용하는 것입니다.
Note
배스천 호스트를 운영하고 싶지 않다면 인스턴스 접근에 AWS Systems Manager Session Manager를 설정할 수 있습니다. 이는 이 문서의 범위를 벗어납니다.

배스천 호스트 A 생성#

EC2 대시보드로 이동해 Launch instance를 선택합니다.
Name and tags 섹션에서 Name을 Bastion Host A로 설정합니다.
최신 Ubuntu Server LTS (HVM) AMI를 선택합니다. 지원되는 최신 OS 버전은 GitLab 문서에서 확인합니다.
인스턴스 유형을 선택합니다. 배스천 호스트는 다른 인스턴스에 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로 선택되어 있는지 확인합니다. 탄력적 IP 주소는 다음 절에서 호스트에 할당합니다.
Firewall에서 Create security group을 선택하고 Security group name을 입력한 다음(여기서는 bastion-sec-group을 사용합니다) 설명을 추가합니다.
여기서는 모든 위치(0.0.0.0/0)에서 SSH 접근을 허용합니다. 보안을 더 강화하려면 단일 IP 주소나 CIDR 표기법의 IP 주소 범위를 지정합니다.


스토리지는 모두 기본값으로 두고 8 GB 루트 볼륨만 추가합니다. 이 인스턴스에는 아무것도 저장하지 않습니다.
모든 설정을 검토한 다음 문제가 없으면 Launch Instance를 선택합니다.

배스천 호스트 A에 탄력적 IP 할당#

EC2 대시보드로 이동해 Network & Security를 선택합니다.
Elastic IPs를 선택하고 Network border group을 us-west-2로 설정합니다.
Allocate를 선택합니다.
생성된 탄력적 IP 주소를 선택합니다.
Actions를 선택하고 Associate Elastic IP address를 선택합니다.
Resource Type에서 Instance를 선택하고 Instance 드롭다운 목록에서 Bastion Host A 호스트를 선택합니다.
Associate를 선택합니다.

인스턴스에 SSH로 접속되는지 확인#

EC2 대시보드의 왼쪽 메뉴에서 Instances를 선택합니다.
인스턴스 목록에서 Bastion Host A를 선택합니다.
Connect를 선택하고 연결 안내를 따릅니다.
정상적으로 접속된다면 이중화를 위한 두 번째 배스천 호스트 설정으로 넘어갑니다.

배스천 호스트 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 클라이언트와 클라이언트에 저장된 프라이빗 키 파일로 배스천 호스트에 접속합니다. 배스천 호스트에는 프라이빗 키 파일이 없으므로 프라이빗 서브넷의 인스턴스에는 접속할 수 없습니다.
배스천 호스트에 프라이빗 키 파일을 저장하는 것은 바람직하지 않습니다. 대신 클라이언트에서 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 드롭다운 목록에서 워크로드에 맞는 인스턴스 유형을 선택합니다. 하드웨어 요구 사항을 참고해 필요에 맞는 유형을 고릅니다(최소 c5.2xlarge 이며, 이 유형은 사용자 100명을 수용하기에 충분합니다).
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 only: gitlab-nlb-sec-group과 bastion-sec-group
Hybrid NLB->ALB: gitlab-rails-sec-group과 bastion-sec-group

bastion-sec-group은 SSH 에이전트 포워딩을 사용하는 관리 및 설정 작업을 위해 배스천 호스트에서의 SSH 접근을 허용합니다.



스토리지의 경우 루트 볼륨은 기본값이 8 GiB 이며, 여기에 데이터를 저장하지 않으므로 이 정도면 충분합니다.
모든 설정을 검토한 뒤 문제가 없으면 Launch Instance를 선택합니다.

커스텀 설정 추가#
SSH 에이전트 포워딩을 사용해 Bastion Host A를 거쳐 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에 필요한 확장 설치#
Note
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로 확인합니다.
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

# 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 설정#
Warning
이 아키텍처에서는 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에는 로드 밸런서 방식에 맞는 보안 그룹을 선택합니다.

NLB only: gitlab-nlb-sec-group
Hybrid NLB->ALB: gitlab-rails-sec-group


배스천 호스트에서 SSH 에이전트 포워딩으로 연결할 수 있도록 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를 선택합니다.

Note
설정과 리포지터리 데이터를 루트 볼륨에 저장하는 대신 리포지터리 스토리지용 EBS 볼륨을 추가로 붙일 수도 있습니다. 이때도
앞에서 설명한 지침을 동일하게 따릅니다. Amazon EBS 요금 페이지를 참고합니다.

EC2 인스턴스가 준비되었으므로 이제 GitLab을 설치하고 Gitaly를 전용 서버에 설정하는 문서를 따릅니다. 해당 문서의 클라이언트 설정 단계는 앞서 생성한 GitLab 인스턴스에서 수행합니다.
Elastic File System (EFS)#
Warning
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을 로드 밸런서에서 종료하므로 프록시된 SSL 지원 문서의 단계를 따라 /etc/gitlab/gitlab.rb에 설정합니다.
gitlab.rb 파일의 변경 사항을 저장한 뒤에는 sudo gitlab-ctl reconfigure를 실행합니다.
인가된 SSH 키 빠른 조회#
GitLab 접근이 허용된 사용자의 공개 SSH 키는 /var/opt/gitlab/.ssh/authorized_keys에 저장됩니다. 일반적으로는 공유 스토리지를 사용해 사용자가 SSH로 Git 작업을 수행할 때 모든 인스턴스가 이 파일에 접근할 수 있게 합니다. 이번 구성에는 공유 스토리지가 없으므로 GitLab 데이터베이스의 인덱스 조회로 SSH 사용자를 인증하도록 설정을 변경합니다.
빠른 SSH 키 조회 설정의 안내를 따라 authorized_keys 파일 대신 데이터베이스를 사용하도록 전환합니다.
빠른 조회를 설정하지 않으면 SSH를 통한 Git 작업에서 다음 오류가 발생합니다.
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

호스트 키 설정#
보통은 기본 애플리케이션 서버의 /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 문서에는 이러한 데이터 유형별 오브젝트 스토리지 설정 방법과 GitLab에서 오브젝트 스토리지를 사용하는 방법에 관한 정보가 담겨 있습니다.
Note
앞서 생성한 AWS IAM 프로필을 사용하므로 오브젝트 스토리지를 설정할 때 AWS 액세스 키와 시크릿 액세스 키 값 쌍은 생략합니다. 대신 앞서 링크한 오브젝트 스토리지 문서에 나온 것처럼 설정에 'use_iam_profile' => true를 사용합니다.
S3 접근에 IAM 권한을 사용할 때 GitLab은 IMDSv1과 IMDSv2를 모두 지원하며, IMDSv2를 사용할 수 있으면 자동으로 이를 사용합니다.

gitlab.rb 파일의 변경 사항을 저장한 뒤에는 sudo gitlab-ctl reconfigure를 실행합니다.

이것으로 GitLab 인스턴스의 설정 변경이 끝났습니다. 다음으로 이 인스턴스를 기반으로 커스텀 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



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을 재구성합니다.
sudo gitlab-ctl reconfigure



처음 로그인#
로드 밸런서의 DNS 설정 때 사용한 도메인 이름으로 이제 브라우저에서 GitLab에 접속할 수 있습니다.
GitLab 설치 방식에 따라, 그리고 다른 방법으로 비밀번호를 변경하지 않았다면 기본 비밀번호는 다음 중 하나입니다.

공식 GitLab AMI를 사용한 경우 인스턴스 ID
/etc/gitlab/initial_root_password에 24시간 동안 저장되는 무작위 생성 비밀번호

기본 비밀번호를 변경하려면 기본 비밀번호로 root 사용자로 로그인한 뒤 사용자 프로필에서 변경합니다.
오토 스케일링 그룹이 새 인스턴스를 띄우면 사용자 이름 root와 새로 만든 비밀번호로 로그인할 수 있습니다.
커스텀 AMI 생성#
EC2 대시보드에서 다음을 수행합니다.

앞서 생성한 GitLab 인스턴스를 선택합니다.
Actions를 선택하고 아래로 스크롤해 Image and templates에서 Create image를 선택합니다.
이미지에 이름과 설명을 입력합니다(여기서는 둘 다 GitLab-Source를 사용합니다).
나머지는 기본값으로 두고 Create Image를 선택합니다

이제 다음 단계에서 시작 구성을 만드는 데 사용할 커스텀 AMI가 준비되었습니다.
오토 스케일링 그룹에 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 only: gitlab-nlb-sec-group과 bastion-sec-group
Hybrid NLB->ALB: gitlab-rails-sec-group과 bastion-sec-group

bastion-sec-group은 SSH 에이전트 포워딩을 사용하는 관리 및 설정 작업을 위해 배스천 호스트에서의 SSH 접근을 허용합니다.


Advanced details 섹션에서 다음을 수행합니다.

IAM instance profile: 앞서 생성한 GitLabS3Access 권한을 선택합니다.



모든 설정을 검토한 뒤 문제가 없으면 Create launch template을 선택합니다.


오토 스케일링 그룹 생성#
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 드롭다운 목록에서 로드 밸런서 방식에 맞는 타깃 그룹을 선택합니다.

NLB only: gitlab-nlb-ssh-target과 gitlab-nlb-http-target을 선택합니다
Hybrid NLB->ALB: gitlab-nlb-ssh-target과 gitlab-alb-http-target을 선택합니다
오토 스케일링 그룹은 시작된 모든 인스턴스를 이 타깃 그룹에 자동으로 등록합니다.


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



마지막으로 알림과 태그를 필요에 맞게 설정하고 변경 사항을 검토한 뒤 오토 스케일링
그룹을 생성합니다.


오토 스케일링 그룹을 생성한 뒤에는 Cloudwatch에서 스케일 업·다운 정책을 만들고 할당해야 합니다.

앞서 생성한 By Auto Scaling Group 기준 EC2 인스턴스 지표의 CPUUtilization에 대한 경보를 생성합니다.
다음 조건으로 스케일 업 정책을 생성합니다.

CPUUtilization 이 60% 이상이면 용량 단위를 1 만큼 Add 합니다.
Scaling policy name을 Scale Up Policy로 설정합니다.





다음 조건으로 스케일 다운 정책을 생성합니다.

CPUUtilization 이 45% 이하이면 용량 단위를 1 만큼 Remove 합니다.
Scaling policy name을 Scale Down Policy로 설정합니다.





새로 만든 동적 스케일링 정책을 앞서 생성한 오토 스케일링 그룹에 할당합니다.



오토 스케일링 그룹이 생성되면 EC2 대시보드에서 새 인스턴스가 시작되는 것을 확인할 수 있습니다. 새 인스턴스가 로드 밸런서에 추가되는 것도 확인할 수 있습니다. 인스턴스가 상태 확인을 통과하면 로드 밸런서에서 트래픽을 받을 준비가 됩니다.
인스턴스가 오토 스케일링 그룹으로 생성되므로 인스턴스 목록으로 돌아가 앞서 직접 생성한 인스턴스를 종료합니다. 이 인스턴스는 커스텀 AMI를 만드는 데만 필요했습니다.
Prometheus를 사용한 상태 확인 및 모니터링#
여러 서비스에서 활성화할 수 있는 Amazon CloudWatch 외에도
GitLab은 Prometheus 기반의 자체 통합 모니터링 솔루션을 제공합니다.
설정 방법에 관한 자세한 내용은
GitLab Prometheus를 참고합니다.
GitLab에는 핑을 보내 보고를 받을 수 있는 여러 상태 확인 엔드포인트도
있습니다.
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 찾기#
자세한 내용은 GitLab 릴리스를 AMI로 사용하는 방법을 참고합니다.
맺음말#
이 가이드에서는 주로 확장과 일부 이중화 옵션을 다루었습니다.
모든 솔루션에는 비용·복잡도와 가동 시간 사이의 트레이드오프가 있다는 점을
기억합니다. 가동 시간을 높이려 할수록 솔루션은 복잡해집니다.
그리고 솔루션이 복잡해질수록 구축과 유지 관리에 드는 작업도
많아집니다.
다음 자료도 함께 읽어 보고, 추가 자료가 필요하면
이슈를 등록해
요청합니다.

GitLab 확장:
GitLab은 여러 유형의 클러스터링을 지원합니다.
Geo 복제:
Geo는 넓게 분산된 개발 팀을 위한 솔루션입니다.
Linux 패키지 - GitLab 인스턴스 관리에 관해
알아야 할 모든 내용입니다.
라이선스 추가:
라이선스로 GitLab Enterprise Edition의 모든 기능을 활성화합니다.
요금제: 티어별 요금 정보입니다.

문제 해결#
인스턴스가 상태 확인에 실패합니다#
인스턴스가 로드 밸런서의 상태 확인에 실패한다면 앞서 설정한 상태 확인 엔드포인트가 상태 코드 200을 반환하는지 확인합니다. 상태 코드 302와 같은 리다이렉트를 포함해 다른 상태 코드가 반환되면 상태 확인은 실패합니다.
상태 확인이 통과하기 전에 로그인 엔드포인트에서 자동 리다이렉트가 발생하지 않도록 root 사용자에게 비밀번호를 설정해야 할 수 있습니다.
메시지: The change you requested was rejected (422)#
웹 인터페이스에서 비밀번호를 설정할 때 이 페이지가 나타난다면 gitlab.rb의 external_url 이 요청을 보내는 도메인과 일치하는지 확인하고, 변경한 뒤에는 sudo gitlab-ctl reconfigure를 실행합니다.
일부 job 로그가 오브젝트 스토리지에 업로드되지 않습니다#
GitLab 배포를 두 개 이상의 노드로 확장하면 일부 job 로그가 오브젝트 스토리지에 제대로 업로드되지 않을 수 있습니다. CI가 오브젝트 스토리지를 사용하려면 증분 로깅이 필요합니다.
아직 활성화하지 않았다면 증분 로깅을 활성화합니다.

설정	값
Target type	Instances
Target group name	`gitlab-nlb-ssh-target`
Protocol	TCP
Port	22
VPC	`gitlab-vpc`
Health check protocol	TCP

설정	값
Target type	Instances
Target group name	`gitlab-nlb-http-target`
Protocol	TCP
Port	80
VPC	`gitlab-vpc`
Health check protocol	HTTP
Health check path	`/-/readiness`

설정	값
Load Balancer name	`gitlab-nlb`
Scheme	Internet-facing
IP address type	IPv4
VPC	`gitlab-vpc`
Mapping	두 퍼블릭 서브넷을 모두 선택
Security group	`gitlab-nlb-sec-group`

프로토콜	포트	타깃 그룹
TCP	22	`gitlab-nlb-ssh-target`
TCP	80	`gitlab-nlb-http-target`
TLS	443	`gitlab-nlb-http-target`

설정	값
Target type	Instances
Target group name	`gitlab-nlb-ssh-target`
Protocol	TCP
Port	22
VPC	`gitlab-vpc`
Health check protocol	TCP

설정	값
Target type	Application Load Balancer
Target group name	`gitlab-nlb-alb-target`
Protocol	TCP
Port	443
VPC	`gitlab-vpc`
Health check protocol	HTTPS
Health check path	`/-/readiness`

설정	값
Target type	Instance
Target group name	`gitlab-alb-http-target`
Protocol	HTTP
Port	80
VPC	`gitlab-vpc`
Protocol version	HTTP1.1
Health check protocol	HTTP
Health check path	`/-/readiness`

설정	값
Load Balancer name	`gitlab-alb`
Scheme	Internet-facing
IP address type	IPv4
VPC	`gitlab-vpc`
Mapping	두 퍼블릭 서브넷 `gitlab-public-10.0.0.0`과 `gitlab-public-10.0.2.0`을 모두 선택
Security group	`gitlab-alb-sec-group`

프로토콜	포트	작업	타깃 그룹
HTTPS	443	Forward to	`gitlab-alb-http-target`

설정	값
Load Balancer name	`gitlab-nlb`
Scheme	Internet-facing
IP address type	IPv4
VPC	`gitlab-vpc`
Mapping	두 퍼블릭 서브넷 `gitlab-public-10.0.0.0`과 `gitlab-public-10.0.2.0`을 모두 선택
Security group	`gitlab-nlb-sec-group`

프로토콜	포트	타깃 그룹
TCP	22	`gitlab-nlb-ssh-target`
TCP	443	`gitlab-nlb-alb-target`

홈/GitLab/설치/Aws

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

GitLab v19.4

Tier: Free, Premium, Ultimate
Offering: GitLab Self-Managed

원문 보기
번역일: 2026-09-18

요약
이 페이지는 공식 Linux 패키지를 사용해 AWS에 GitLab을 구성하는 일반적인 방법을 단계별로 안내합니다. 사용자가 1,000명 이하인 조직에서는 EC2 단일 박스에 Linux 패키지 설치를 수행하고 데이터 백업을 위한 스냅샷 전략을 적용하는 방식을 AWS 설치 방법으로 권장합니다.

이 페이지는 공식 Linux 패키지를 사용해 AWS에 GitLab을 구성하는 일반적인 방법을 단계별로 안내합니다. 환경에 맞게 조정해 사용합니다.


Note
사용자가 1,000명 이하인 조직에서는 EC2 단일 박스에 Linux 패키지 설치를 수행하고
데이터 백업을 위한 스냅샷 전략을 적용하는 방식을 AWS 설치 방법으로
권장합니다.

프로덕션 등급 GitLab 시작하기#
Note
이 문서는 개념 증명(Proof of Concept) 단계의 안내서입니다. 이 문서만으로는 고가용성 구성이
완성되지 않습니다.

이 가이드를 그대로 따르면 HA가 아닌 인스턴스가 만들어집니다. AWS에서 프로덕션 등급으로 배포하려면
참조 아키텍처에서 규모에 맞는 구성을
확인합니다. 참조 아키텍처는 Linux 패키지(VM 기반)와 클라우드 네이티브(Kubernetes) 배포 유형을
모두 다룹니다.
개요#
이 구성에서는 대부분 Linux 패키지를 사용하지만 AWS의 네이티브 서비스도 함께 활용합니다. Linux 패키지에 번들된 PostgreSQL과 Redis 대신 Amazon RDS와 ElastiCache를 사용합니다.
이 가이드에서는 다중 노드 구성을 다룹니다. 먼저 Virtual Private Cloud와
서브넷을 구성한 다음, 데이터베이스 서버용 RDS와 Redis 클러스터용
ElastiCache 같은 서비스를 통합하고, 마지막으로 사용자 지정 스케일링
정책을 적용한 오토 스케일링 그룹에서 이들을
관리합니다.
요구 사항#
AWS와 Amazon EC2에 대한 기본적인 이해와 함께 다음이 필요합니다.

AWS 계정
SSH로 인스턴스에 접속하기 위한
SSH 키 생성 또는 업로드
GitLab 인스턴스용 도메인 이름
도메인을 보호할 SSL/TLS 인증서. 보유한 인증서가 없다면 AWS Certificate Manager(ACM)에서 무료 퍼블릭 SSL/TLS 인증서를 발급받아 이후에 생성하는 Elastic Load Balancer에 사용할 수 있습니다.

Note
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 키를 직접 넣지 않기 위해 IAM 역할을 사용해 GitLab 인스턴스에 이 접근 권한을 부여합니다. 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-*"
        }
    ]
}


[!note]
외부 프로세스가 S3 버킷의 객체에 태그를 지정하는 경우(예: AWS GuardDuty Malware
Protection) 소스 버킷에는 객체 수준 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을 선택합니다.

이 역할은 이후 시작 템플릿 생성 단계에서 사용합니다.
Note
GitLab은 AWS Instance Metadata Service Version 2(IMDSv2)를 지원합니다. GitLab은 IMDSv2를 사용할 수 있으면 자동으로 사용하고, 필요하면 IMDSv1로 대체합니다. 보안 강화를 위해
EC2 인스턴스에서 IMDSv2를 필수로 지정해도 문제가 없습니다.

네트워크 구성#
먼저 GitLab 클라우드 인프라용 VPC를 생성한 다음, 최소 두 개의
가용 영역(Availability Zone, 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를 선택합니다.



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를 지정합니다.



같은 방법으로 모든 서브넷을 생성합니다.



이름 태그
유형
가용 영역
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





모든 서브넷을 생성한 다음, 두 퍼블릭 서브넷에서 Auto-assign IPv4를 활성화합니다.

각 퍼블릭 서브넷을 차례로 선택하고 Actions, Edit subnet settings를 선택합니다. Enable auto-assign public IPv4 address 옵션을 선택하고 저장합니다.



인터넷 게이트웨이#
이제 같은 대시보드에서 Internet Gateways로 이동해
새 게이트웨이를 생성합니다.


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


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


표에서 해당 게이트웨이를 선택한 다음 Actions 드롭다운 목록에서
"Attach to VPC" 를 선택합니다.



목록에서 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: 기존 탄력적 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-private-a 라우팅 테이블의 새 경로에는 gitlab-public-10.0.0.0에 생성한 NAT 게이트웨이를 타깃으로 추가합니다.
마찬가지로 gitlab-private-b의 새 경로에는 gitlab-public-10.0.2.0의 NAT 게이트웨이를 타깃으로 추가합니다.


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

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 노드로 직접 전달하며, SSL/TLS는 NLB에서 종료됩니다.
NLB->ALB 하이브리드 방식: 역할을 분리해 확장성을 높인 구성입니다. NLB는 TCP 트래픽(포트 22의 SSH)을 처리하고, Application Load Balancer(ALB)가 SSL/TLS 종료와 함께 HTTP/HTTPS 트래픽을 처리합니다. 이 방식에서는 AWS WAF 연동과 세밀한 트래픽 관리가 가능합니다.

배포 환경에 가장 적합한 방식을 선택합니다.


NLB 단독:
Mermaid 다이어그램 (15줄)
소스 코드 보기
graph TB
    subgraph Diagram1["NLB Only"]
      U1["Users"]
      NLB1["Network Load Balancer<br/>(Port 22, 80, 443)"]
      R1A["Rails Node 1<br/>(Port 22, 80)"]
      R1B["Rails Node 2<br/>(Port 22, 80)"]
  U1 --&gt;|SSH| NLB1
  U1 --&gt;|HTTP| NLB1
  U1 --&gt;|HTTPS| NLB1
  NLB1 --&gt;|Port 22| R1A
  NLB1 --&gt;|Port 22| R1B
  NLB1 --&gt;|"Port 80, 443"| R1A
  NLB1 --&gt;|"Port 80, 443"| R1B

end



NLB/ALB 하이브리드:
Mermaid 다이어그램 (16줄)
소스 코드 보기
graph TB
    subgraph Diagram2["Hybrid NLB/ALB"]
        U2["Users"]
        NLB2["Network Load Balancer<br/>(Port 22, 443)"]
        ALB["Application Load Balancer<br/>(Port 443)"]
        R2A["Rails Node 1<br/>(Port 22, 80)"]
        R2B["Rails Node 2<br/>(Port 22, 80)"]
    U2 --&gt;|SSH| NLB2
    U2 --&gt;|HTTPS| NLB2
    NLB2 --&gt;|Port 22| R2A
    NLB2 --&gt;|Port 22| R2B
    NLB2 --&gt;|Port 443| ALB
    ALB --&gt;|Port 80| R2A
    ALB --&gt;|Port 80| R2B
end</code></pre></details></div>




이 절에서는 단일 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 Target Group을 위해 Create target group을 선택합니다.



설정
값




Target type
Instances


Target group name
gitlab-nlb-ssh-target


Protocol
TCP


Port
22


VPC
gitlab-vpc


Health check protocol
TCP



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


HTTP Target Group을 위해 Create target group을 다시 선택합니다.



설정
값




Target type
Instances


Target group name
gitlab-nlb-http-target


Protocol
TCP


Port
80


VPC
gitlab-vpc


Health check protocol
HTTP


Health check path
/-/readiness




[!note]
상태 검사 엔드포인트를 위해 VPC IP 주소 범위(CIDR)를 IP 허용 목록에 추가해야 합니다.

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


네트워크 로드 밸런서를 생성합니다.


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


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


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



설정
값




Load Balancer name
gitlab-nlb


Scheme
Internet-facing


IP address type
IPv4


VPC
gitlab-vpc


Mapping
두 퍼블릭 서브넷을 모두 선택


Security group
gitlab-nlb-sec-group





Listeners and routing 섹션에서 다음과 같이 구성합니다.



프로토콜
포트
타깃 그룹




TCP
22
gitlab-nlb-ssh-target


TCP
80
gitlab-nlb-http-target


TLS
443
gitlab-nlb-http-target



포트 443의 TLS 리스너는 Security Policy 설정에서 다음을 지정합니다.

Policy name: 드롭다운 목록에서 사전 정의된 보안 정책을 선택합니다. AWS 문서의 Predefined SSL Security Policies for Network Load Balancers를 참고합니다. 지원되는 SSL 암호 및 프로토콜 목록은 GitLab 코드베이스에서 확인합니다.
Default SSL/TLS server certificate: ACM의 SSL/TLS 인증서를 선택하거나 IAM에 인증서를 업로드합니다.



Create load balancer를 선택합니다.


Note
gitlab-nlb-ssh-target과 gitlab-nlb-http-target 타깃 그룹의 타깃은 이 가이드 뒷부분에서 생성하는 오토 스케일링 그룹에서 인스턴스가 시작될 때 자동으로 등록됩니다.



이 절에서는 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 Target Group을 위해 Create security group을 선택합니다.
각각에 알아보기 쉬운 이름과 설명을 지정하고 VPC 드롭다운 목록에서 gitlab-vpc를 선택합니다.
위에 명시한 인바운드 규칙을 추가합니다. 소스를 선택할 때는 Security group을 선택하고 드롭다운에서 해당 보안 그룹을 선택합니다.
완료되면 Create security group을 선택합니다.

타깃 그룹을 생성합니다.


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


다음 설정으로 NLB SSH Target Group을 생성합니다.



설정
값




Target type
Instances


Target group name
gitlab-nlb-ssh-target


Protocol
TCP


Port
22


VPC
gitlab-vpc


Health check protocol
TCP



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


NLB to ALB Target Group을 위해 Create target group을 다시 선택합니다.



설정
값




Target type
Application Load Balancer


Target group name
gitlab-nlb-alb-target


Protocol
TCP


Port
443


VPC
gitlab-vpc


Health check protocol
HTTPS


Health check path
/-/readiness



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


ALB HTTP Target Group을 위해 Create target group을 다시 선택합니다.



설정
값




Target type
Instance


Target group name
gitlab-alb-http-target


Protocol
HTTP


Port
80


VPC
gitlab-vpc


Protocol version
HTTP1.1


Health check protocol
HTTP


Health check path
/-/readiness




[!note]
상태 검사 엔드포인트를 위해 VPC IP 주소 범위(CIDR)를 IP 허용 목록에 추가해야 합니다.

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


애플리케이션 로드 밸런서를 생성합니다.


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


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


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



설정
값




Load Balancer name
gitlab-alb


Scheme
Internet-facing


IP address type
IPv4


VPC
gitlab-vpc


Mapping
두 퍼블릭 서브넷 gitlab-public-10.0.0.0과 gitlab-public-10.0.2.0을 모두 선택


Security group
gitlab-alb-sec-group





Listeners and routing 섹션에서 다음과 같이 구성합니다.



프로토콜
포트
작업
타깃 그룹




HTTPS
443
Forward to
gitlab-alb-http-target



HTTPS 리스너에는 ACM 인증서를 선택하고 적절한 보안 정책을 선택합니다(Predefined SSL Security Policies for Application Load Balancers 참고).


Create load balancer를 선택합니다.


네트워크 로드 밸런서를 생성합니다.


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


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


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



설정
값




Load Balancer name
gitlab-nlb


Scheme
Internet-facing


IP address type
IPv4


VPC
gitlab-vpc


Mapping
두 퍼블릭 서브넷 gitlab-public-10.0.0.0과 gitlab-public-10.0.2.0을 모두 선택


Security group
gitlab-nlb-sec-group





Listeners and routing 섹션에서 다음과 같이 구성합니다.



프로토콜
포트
타깃 그룹




TCP
22
gitlab-nlb-ssh-target


TCP
443
gitlab-nlb-alb-target





Create load balancer를 선택합니다.


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

EC2 대시보드의 왼쪽 메뉴 바에서 Target Groups를 선택합니다.
gitlab-nlb-alb-target 타깃 그룹을 선택합니다.
Targets 탭에서 Register targets를 선택합니다.
gitlab-alb Application Load Balancer를 선택하고 Register pending targets를 선택합니다.
Save를 선택합니다.

Note
gitlab-nlb-ssh-target과 gitlab-alb-http-target 타깃 그룹의 타깃은 이 가이드 뒷부분에서 생성하는 오토 스케일링 그룹에서 인스턴스가 시작될 때 자동으로 등록됩니다.



NLB 로드 밸런서가 실행된 뒤에는 보안 그룹을 다시 확인해 NLB를 통한 접근만 허용하도록 조정하고 그 밖의 요구 사항을 반영할 수 있습니다.
일부 속성은 로드 밸런서를 생성한 뒤에만 구성할 수 있습니다. 요구 사항에 따라 구성할 수 있는 기능은 다음과 같습니다.

클라이언트 IP 보존은 타깃 그룹에서 기본으로 활성화되어 있습니다. 이 기능을 사용하면 로드 밸런서에 연결한 클라이언트의 IP가 GitLab 애플리케이션에 그대로 전달됩니다. 요구 사항에 따라 활성화하거나 비활성화할 수 있습니다.
프록시 프로토콜은 타깃 그룹에서 기본으로 비활성화되어 있습니다. 이 기능을 사용하면 로드 밸런서가 프록시 프로토콜 헤더에 추가 정보를 담아 전송합니다. 활성화하려면 내부 로드 밸런서, NGINX 등 환경의 다른 구성 요소도 함께 구성해야 합니다. 이 개념 증명에서는 이후 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 레코드로 추가합니다. 이 절차는 등록 기관마다 다를 수 있습니다. 진행이 어렵다면 "등록 기관 이름" add DNS records로 검색해 해당 기관의 도움말 문서를 확인합니다.



이 작업의 구체적인 절차는 사용하는 등록 기관에 따라 다르며 이 가이드의 범위를 벗어납니다.
RDS 기반 PostgreSQL#
데이터베이스 서버로는 이중화를 위해 다중 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를 선택합니다.

데이터베이스 생성#
Warning
데이터베이스에는 버스터블 인스턴스(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)를 선택할 수도 있습니다). 자세한 내용은 Storage for 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 애플리케이션의 세션 데이터, 임시 캐시 정보, 백그라운드 job 큐를 저장하는 데 사용됩니다.
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를 선택합니다.



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


배스천 호스트 설정#
GitLab 인스턴스가 프라이빗 서브넷에 있으므로, 구성 변경이나 업그레이드 같은
작업을 위해 SSH로 이 인스턴스에 접속할 방법이 필요합니다. 한 가지 방법은
점프 박스라고도 부르는 배스천 호스트를
사용하는 것입니다.
Note
배스천 호스트를 운영하고 싶지 않다면 인스턴스 접근에 AWS Systems Manager Session Manager를 설정할 수 있습니다. 이는 이 문서의 범위를 벗어납니다.

배스천 호스트 A 생성#

EC2 대시보드로 이동해 Launch instance를 선택합니다.
Name and tags 섹션에서 Name을 Bastion Host A로 설정합니다.
최신 Ubuntu Server LTS (HVM) AMI를 선택합니다. 지원되는 최신 OS 버전은 GitLab 문서에서 확인합니다.
인스턴스 유형을 선택합니다. 배스천 호스트는 다른 인스턴스에 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로 선택되어 있는지 확인합니다. 탄력적 IP 주소는 다음 절에서 호스트에 할당합니다.
Firewall에서 Create security group을 선택하고 Security group name을 입력한 다음(여기서는 bastion-sec-group을 사용합니다) 설명을 추가합니다.
여기서는 모든 위치(0.0.0.0/0)에서 SSH 접근을 허용합니다. 보안을 더 강화하려면 단일 IP 주소나 CIDR 표기법의 IP 주소 범위를 지정합니다.


스토리지는 모두 기본값으로 두고 8 GB 루트 볼륨만 추가합니다. 이 인스턴스에는 아무것도 저장하지 않습니다.
모든 설정을 검토한 다음 문제가 없으면 Launch Instance를 선택합니다.

배스천 호스트 A에 탄력적 IP 할당#

EC2 대시보드로 이동해 Network & Security를 선택합니다.
Elastic IPs를 선택하고 Network border group을 us-west-2로 설정합니다.
Allocate를 선택합니다.
생성된 탄력적 IP 주소를 선택합니다.
Actions를 선택하고 Associate Elastic IP address를 선택합니다.
Resource Type에서 Instance를 선택하고 Instance 드롭다운 목록에서 Bastion Host A 호스트를 선택합니다.
Associate를 선택합니다.

인스턴스에 SSH로 접속되는지 확인#

EC2 대시보드의 왼쪽 메뉴에서 Instances를 선택합니다.
인스턴스 목록에서 Bastion Host A를 선택합니다.
Connect를 선택하고 연결 안내를 따릅니다.
정상적으로 접속된다면 이중화를 위한 두 번째 배스천 호스트 설정으로 넘어갑니다.

배스천 호스트 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 클라이언트와 클라이언트에 저장된 프라이빗 키 파일로 배스천 호스트에 접속합니다. 배스천 호스트에는 프라이빗 키 파일이 없으므로 프라이빗 서브넷의 인스턴스에는 접속할 수 없습니다.
배스천 호스트에 프라이빗 키 파일을 저장하는 것은 바람직하지 않습니다. 대신 클라이언트에서 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 드롭다운 목록에서 워크로드에 맞는 인스턴스 유형을 선택합니다. 하드웨어 요구 사항을 참고해 필요에 맞는 유형을 고릅니다(최소 c5.2xlarge 이며, 이 유형은 사용자 100명을 수용하기에 충분합니다).
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 only: gitlab-nlb-sec-group과 bastion-sec-group
Hybrid NLB->ALB: gitlab-rails-sec-group과 bastion-sec-group

bastion-sec-group은 SSH 에이전트 포워딩을 사용하는 관리 및 설정 작업을 위해 배스천 호스트에서의 SSH 접근을 허용합니다.



스토리지의 경우 루트 볼륨은 기본값이 8 GiB 이며, 여기에 데이터를 저장하지 않으므로 이 정도면 충분합니다.
모든 설정을 검토한 뒤 문제가 없으면 Launch Instance를 선택합니다.

커스텀 설정 추가#
SSH 에이전트 포워딩을 사용해 Bastion Host A를 거쳐 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에 필요한 확장 설치#
Note
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로 확인합니다.
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

# 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 설정#
Warning
이 아키텍처에서는 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에는 로드 밸런서 방식에 맞는 보안 그룹을 선택합니다.

NLB only: gitlab-nlb-sec-group
Hybrid NLB->ALB: gitlab-rails-sec-group


배스천 호스트에서 SSH 에이전트 포워딩으로 연결할 수 있도록 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를 선택합니다.

Note
설정과 리포지터리 데이터를 루트 볼륨에 저장하는 대신 리포지터리 스토리지용 EBS 볼륨을 추가로 붙일 수도 있습니다. 이때도
앞에서 설명한 지침을 동일하게 따릅니다. Amazon EBS 요금 페이지를 참고합니다.

EC2 인스턴스가 준비되었으므로 이제 GitLab을 설치하고 Gitaly를 전용 서버에 설정하는 문서를 따릅니다. 해당 문서의 클라이언트 설정 단계는 앞서 생성한 GitLab 인스턴스에서 수행합니다.
Elastic File System (EFS)#
Warning
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을 로드 밸런서에서 종료하므로 프록시된 SSL 지원 문서의 단계를 따라 /etc/gitlab/gitlab.rb에 설정합니다.
gitlab.rb 파일의 변경 사항을 저장한 뒤에는 sudo gitlab-ctl reconfigure를 실행합니다.
인가된 SSH 키 빠른 조회#
GitLab 접근이 허용된 사용자의 공개 SSH 키는 /var/opt/gitlab/.ssh/authorized_keys에 저장됩니다. 일반적으로는 공유 스토리지를 사용해 사용자가 SSH로 Git 작업을 수행할 때 모든 인스턴스가 이 파일에 접근할 수 있게 합니다. 이번 구성에는 공유 스토리지가 없으므로 GitLab 데이터베이스의 인덱스 조회로 SSH 사용자를 인증하도록 설정을 변경합니다.
빠른 SSH 키 조회 설정의 안내를 따라 authorized_keys 파일 대신 데이터베이스를 사용하도록 전환합니다.
빠른 조회를 설정하지 않으면 SSH를 통한 Git 작업에서 다음 오류가 발생합니다.
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

호스트 키 설정#
보통은 기본 애플리케이션 서버의 /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 문서에는 이러한 데이터 유형별 오브젝트 스토리지 설정 방법과 GitLab에서 오브젝트 스토리지를 사용하는 방법에 관한 정보가 담겨 있습니다.
Note
앞서 생성한 AWS IAM 프로필을 사용하므로 오브젝트 스토리지를 설정할 때 AWS 액세스 키와 시크릿 액세스 키 값 쌍은 생략합니다. 대신 앞서 링크한 오브젝트 스토리지 문서에 나온 것처럼 설정에 'use_iam_profile' => true를 사용합니다.
S3 접근에 IAM 권한을 사용할 때 GitLab은 IMDSv1과 IMDSv2를 모두 지원하며, IMDSv2를 사용할 수 있으면 자동으로 이를 사용합니다.

gitlab.rb 파일의 변경 사항을 저장한 뒤에는 sudo gitlab-ctl reconfigure를 실행합니다.

이것으로 GitLab 인스턴스의 설정 변경이 끝났습니다. 다음으로 이 인스턴스를 기반으로 커스텀 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



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을 재구성합니다.
sudo gitlab-ctl reconfigure



처음 로그인#
로드 밸런서의 DNS 설정 때 사용한 도메인 이름으로 이제 브라우저에서 GitLab에 접속할 수 있습니다.
GitLab 설치 방식에 따라, 그리고 다른 방법으로 비밀번호를 변경하지 않았다면 기본 비밀번호는 다음 중 하나입니다.

공식 GitLab AMI를 사용한 경우 인스턴스 ID
/etc/gitlab/initial_root_password에 24시간 동안 저장되는 무작위 생성 비밀번호

기본 비밀번호를 변경하려면 기본 비밀번호로 root 사용자로 로그인한 뒤 사용자 프로필에서 변경합니다.
오토 스케일링 그룹이 새 인스턴스를 띄우면 사용자 이름 root와 새로 만든 비밀번호로 로그인할 수 있습니다.
커스텀 AMI 생성#
EC2 대시보드에서 다음을 수행합니다.

앞서 생성한 GitLab 인스턴스를 선택합니다.
Actions를 선택하고 아래로 스크롤해 Image and templates에서 Create image를 선택합니다.
이미지에 이름과 설명을 입력합니다(여기서는 둘 다 GitLab-Source를 사용합니다).
나머지는 기본값으로 두고 Create Image를 선택합니다

이제 다음 단계에서 시작 구성을 만드는 데 사용할 커스텀 AMI가 준비되었습니다.
오토 스케일링 그룹에 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 only: gitlab-nlb-sec-group과 bastion-sec-group
Hybrid NLB->ALB: gitlab-rails-sec-group과 bastion-sec-group

bastion-sec-group은 SSH 에이전트 포워딩을 사용하는 관리 및 설정 작업을 위해 배스천 호스트에서의 SSH 접근을 허용합니다.


Advanced details 섹션에서 다음을 수행합니다.

IAM instance profile: 앞서 생성한 GitLabS3Access 권한을 선택합니다.



모든 설정을 검토한 뒤 문제가 없으면 Create launch template을 선택합니다.


오토 스케일링 그룹 생성#
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 드롭다운 목록에서 로드 밸런서 방식에 맞는 타깃 그룹을 선택합니다.

NLB only: gitlab-nlb-ssh-target과 gitlab-nlb-http-target을 선택합니다
Hybrid NLB->ALB: gitlab-nlb-ssh-target과 gitlab-alb-http-target을 선택합니다
오토 스케일링 그룹은 시작된 모든 인스턴스를 이 타깃 그룹에 자동으로 등록합니다.


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



마지막으로 알림과 태그를 필요에 맞게 설정하고 변경 사항을 검토한 뒤 오토 스케일링
그룹을 생성합니다.


오토 스케일링 그룹을 생성한 뒤에는 Cloudwatch에서 스케일 업·다운 정책을 만들고 할당해야 합니다.

앞서 생성한 By Auto Scaling Group 기준 EC2 인스턴스 지표의 CPUUtilization에 대한 경보를 생성합니다.
다음 조건으로 스케일 업 정책을 생성합니다.

CPUUtilization 이 60% 이상이면 용량 단위를 1 만큼 Add 합니다.
Scaling policy name을 Scale Up Policy로 설정합니다.





다음 조건으로 스케일 다운 정책을 생성합니다.

CPUUtilization 이 45% 이하이면 용량 단위를 1 만큼 Remove 합니다.
Scaling policy name을 Scale Down Policy로 설정합니다.





새로 만든 동적 스케일링 정책을 앞서 생성한 오토 스케일링 그룹에 할당합니다.



오토 스케일링 그룹이 생성되면 EC2 대시보드에서 새 인스턴스가 시작되는 것을 확인할 수 있습니다. 새 인스턴스가 로드 밸런서에 추가되는 것도 확인할 수 있습니다. 인스턴스가 상태 확인을 통과하면 로드 밸런서에서 트래픽을 받을 준비가 됩니다.
인스턴스가 오토 스케일링 그룹으로 생성되므로 인스턴스 목록으로 돌아가 앞서 직접 생성한 인스턴스를 종료합니다. 이 인스턴스는 커스텀 AMI를 만드는 데만 필요했습니다.
Prometheus를 사용한 상태 확인 및 모니터링#
여러 서비스에서 활성화할 수 있는 Amazon CloudWatch 외에도
GitLab은 Prometheus 기반의 자체 통합 모니터링 솔루션을 제공합니다.
설정 방법에 관한 자세한 내용은
GitLab Prometheus를 참고합니다.
GitLab에는 핑을 보내 보고를 받을 수 있는 여러 상태 확인 엔드포인트도
있습니다.
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 찾기#
자세한 내용은 GitLab 릴리스를 AMI로 사용하는 방법을 참고합니다.
맺음말#
이 가이드에서는 주로 확장과 일부 이중화 옵션을 다루었습니다.
모든 솔루션에는 비용·복잡도와 가동 시간 사이의 트레이드오프가 있다는 점을
기억합니다. 가동 시간을 높이려 할수록 솔루션은 복잡해집니다.
그리고 솔루션이 복잡해질수록 구축과 유지 관리에 드는 작업도
많아집니다.
다음 자료도 함께 읽어 보고, 추가 자료가 필요하면
이슈를 등록해
요청합니다.

GitLab 확장:
GitLab은 여러 유형의 클러스터링을 지원합니다.
Geo 복제:
Geo는 넓게 분산된 개발 팀을 위한 솔루션입니다.
Linux 패키지 - GitLab 인스턴스 관리에 관해
알아야 할 모든 내용입니다.
라이선스 추가:
라이선스로 GitLab Enterprise Edition의 모든 기능을 활성화합니다.
요금제: 티어별 요금 정보입니다.

문제 해결#
인스턴스가 상태 확인에 실패합니다#
인스턴스가 로드 밸런서의 상태 확인에 실패한다면 앞서 설정한 상태 확인 엔드포인트가 상태 코드 200을 반환하는지 확인합니다. 상태 코드 302와 같은 리다이렉트를 포함해 다른 상태 코드가 반환되면 상태 확인은 실패합니다.
상태 확인이 통과하기 전에 로그인 엔드포인트에서 자동 리다이렉트가 발생하지 않도록 root 사용자에게 비밀번호를 설정해야 할 수 있습니다.
메시지: The change you requested was rejected (422)#
웹 인터페이스에서 비밀번호를 설정할 때 이 페이지가 나타난다면 gitlab.rb의 external_url 이 요청을 보내는 도메인과 일치하는지 확인하고, 변경한 뒤에는 sudo gitlab-ctl reconfigure를 실행합니다.
일부 job 로그가 오브젝트 스토리지에 업로드되지 않습니다#
GitLab 배포를 두 개 이상의 노드로 확장하면 일부 job 로그가 오브젝트 스토리지에 제대로 업로드되지 않을 수 있습니다. CI가 오브젝트 스토리지를 사용하려면 증분 로깅이 필요합니다.
아직 활성화하지 않았다면 증분 로깅을 활성화합니다.