프로덕션 수준 GitLab 시작하기
- 프로덕션 수준 Linux 패키지 설치 시작하기
- 프로덕션 수준 Cloud Native Hybrid GitLab 시작하기
소개
요구 사항
아키텍처
AWS 비용
IAM EC2 인스턴스 역할 및 프로필 생성
- IAM 정책 생성
- IAM 역할 생성
네트워크 구성
- 가상 사설 클라우드(VPC) 생성
- 서브넷
- 인터넷 게이트웨이
- NAT 게이트웨이 생성
- 라우트 테이블
  - 공개 라우트 테이블
  - 개인 라우트 테이블
로드 밸런서
- 로드 밸런서를 위한 DNS 구성
RDS와 함께하는 PostgreSQL
- RDS 보안 그룹
- RDS 서브넷 그룹
- 데이터베이스 생성
Redis와 ElastiCache
- Redis 보안 그룹 생성
- Redis 서브넷 그룹
- Redis 클러스터 생성
배치 호스트 설정
- 배치 호스트 A 생성
  - 배치 호스트 A에 Elastic IP 할당
  - 인스턴스에 SSH로 접속할 수 있는지 확인
- Bastion Host B 생성
- SSH 에이전트 포워딩 사용
GitLab 설치 및 사용자 지정 AMI 생성
- GitLab 설치
- 사용자 정의 구성 추가
- IP 허용 목록
- 프록시 프로토콜
- 처음 로그인하기
- 커스텀 AMI 생성
오토 스케일링 그룹 내에 GitLab 배포
- 실행 템플릿 생성
- 자동 크기 조정 그룹 생성
Prometheus를 사용한 상태 검사 및 모니터링
GitLab Runner
백업 및 복원
- GitLab 백업하기
- 백업에서 GitLab 복원하기
GitLab 업데이트
AWS에서 공식 GitLab 생성 AMI ID 찾기
결론
문제 해결
- 인스턴스가 상태 검사에 실패하고 있습니다.
- “요청하신 변경이 거부되었습니다 (422)”
- 일부 작업 로그가 오브젝트 스토리지에 업로드되지 않음

AWS(아마존 웹 서비스)에서 GitLab POC 설치하기

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

이 페이지는 공식 Linux 패키지를 사용하여 AWS에서 GitLab의 일반적인 구성에 대한 안내를 제공합니다. 필요에 맞게 조정해야 합니다.

1,000명 이하의 사용자가 있는 조직의 경우, 권장되는 AWS 설치 방법은 EC2 단일 박스를 실행하여 Linux 패키지 설치를 수행하고 데이터를 백업하기 위한 스냅샷 전략을 구현하는 것입니다. 자세한 내용은 20 RPS 또는 1,000 사용자 레퍼런스 아키텍처를 참조하세요.

프로덕션 수준 GitLab 시작하기

이 문서는 개념 증명 인스턴스에 대한 설치 가이드입니다. 이는 레퍼런스 아키텍처가 아니며 고가용성 구성으로 이어지지 않습니다.

대신 GitLab Environment Toolkit (GET)를 사용하는 것이 강력히 권장됩니다.

이 가이드를 정확히 따라하면 Non-HA의 40 RPS 또는 2,000 사용자 레퍼런스 아키텍처의 스케일 다운 버전과 거의 동일한 개념 증명 인스턴스가 생성됩니다. 2K 레퍼런스 아키텍처는 주로 비용과 복잡성을 낮추면서 일부 확장성을 제공하기 위해 설계되었기 때문에 HA가 아닙니다. 60 RPS 또는 3,000 사용자 레퍼런스 아키텍처는 GitLab HA의 가장 작은 사이즈입니다. HA를 달성하기 위해 Gitaly Cluster를 사용하는 것을 포함하여 추가 서비스 역할이 있습니다.

GitLab은 두 가지 주요 유형의 레퍼런스 아키텍처를 유지하고 테스트합니다. Linux 패키지 아키텍처는 인스턴스 컴퓨팅에서 구현되는 반면, Cloud Native Hybrid 아키텍처는 Kubernetes 클러스터의 사용을 극대화합니다. Cloud Native Hybrid 레퍼런스 아키텍처 사양은 Linux 패키지 아키텍처를 설명하는 레퍼런스 아키텍처 크기 페이지에 대한 부록 섹션입니다. 예를 들어, 60 RPS 또는 3,000 사용자 Cloud Native 레퍼런스 아키텍처는 Cloud Native Hybrid reference architecture with Helm Charts (alternative)라는 제목의 하위 섹션에 있습니다.

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

Infrastructure as Code 도구 GitLab Environment Tool (GET)은 AWS에서 Linux 패키지를 사용하는 빌드를 위한 가장 좋은 출발점입니다. 특히 HA 구성을 목표로 할 경우 더욱 그렇습니다. 모든 것을 자동화하지는 않지만 Gitaly Cluster와 같은 복잡한 설정을 완료합니다. 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와 같은 서비스를 통합하여, 마지막으로 사용자 지정 스케일링 정책이 있는 자동 스케일링 그룹에서 이를 관리하는 다중 노드 설정을 설명합니다.

요구 사항

AWS 및 Amazon EC2에 대한 기본적인 이해 외에, 다음이 필요합니다:

AWS 계정
인스턴스에 SSH를 통해 연결하기 위한 SSH 키 생성 또는 업로드
GitLab 인스턴스를 위한 도메인 이름
도메인을 보호하기 위한 SSL/TLS 인증서. 이미 소유하고 있지 않다면, AWS Certificate Manager(ACM)를 통해 무료 공개 SSL/TLS 인증서를 요청하여 Elastic Load Balancer와 함께 사용할 수 있습니다.

참고: ACM을 통해 제공된 인증서의 유효성을 검증하는 데 몇 시간이 걸릴 수 있습니다. 나중에 지연을 피하려면 가능한 한 빨리 인증서를 요청하세요.

아키텍처

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

AWS 비용

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

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

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

Amazon S3 객체 저장소를 사용하고 있으므로, EC2 인스턴스는 S3 버킷에 대한 읽기, 쓰기 및 나열 권한이 필요합니다. GitLab 구성에 AWS 키를 내장하는 것을 피하기 위해, 이 접근 권한을 부여하기 위해 IAM 역할을 사용합니다. IAM 역할에 연결할 IAM 정책을 생성해야 합니다:

IAM 정책 생성

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

정책 생성을 선택하고, 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-*"
        }
    ]
}

다음을 선택하여 정책을 검토합니다. 정책에 이름을 부여하세요(우리는 gl-s3-policy를 사용합니다), 그리고 정책 생성을 선택합니다.

IAM 역할 생성

IAM 대시보드에서 왼쪽 메뉴에서 Roles를 선택하고
Create role을 선택합니다.
Trusted entity type에서 AWS service를 선택합니다. Use case에서 드롭다운 목록과 라디오 버튼 모두에 대해 EC2를 선택하고 Next를 선택합니다.
정책 필터에서 위에서 생성한 gl-s3-policy를 검색하고 선택한 후 Next를 선택합니다.
역할에 이름을 부여합니다(우리는 GitLabS3Access를 사용합니다). 필요하면 태그를 추가합니다. Create role을 선택합니다.

우리는 나중에 런치 템플릿을 생성할 때 이 역할을 사용합니다.

네트워크 구성

우리는 GitLab 클라우드 인프라를 위해 VPC를 생성한 후
공용 및 비공유 인스턴스를 두 개 이상의 가용 영역(AZs)에 생성합니다.
공용 서브넷은 라우트 테이블을 유지하고 연관된 인터넷 게이트웨이가 필요합니다.

가상 사설 클라우드(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`	public	`us-west-2a`	`10.0.0.0/24`
`gitlab-private-10.0.1.0`	private	`us-west-2a`	`10.0.1.0/24`
`gitlab-public-10.0.2.0`	public	`us-west-2b`	`10.0.2.0/24`
`gitlab-private-10.0.3.0`	private	`us-west-2b`	`10.0.3.0/24`

모든 서브넷이 생성된 후 두 개의 공용 서브넷에 대해 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 Gateways를 이용합니다:

VPC 대시보드로 가서 왼쪽 메뉴 모음에서 NAT Gateways를 선택합니다.
Create NAT Gateway를 선택하고 다음을 완료합니다:
1. Subnet: 드롭다운 목록에서 gitlab-public-10.0.0.0을 선택합니다.
2. Elastic IP Allocation ID: 기존 Elastic IP를 입력하거나 Allocate Elastic IP address를 선택하여 NAT 게이트웨이에 새 IP를 할당합니다.
3. 필요한 경우 태그를 추가합니다.
4. 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 애플리케이션 서버에 80 및 443 포트에서 들어오는 트래픽을 고르게 분산하기 위해 로드 밸런서를 생성합니다. 이후 생성할 스케일링 정책에 따라 인스턴스가 필요에 따라 로드 밸런서에 추가되거나 제거됩니다. 또한, 로드 밸런서는 우리의 인스턴스에 대한 상태 검사를 수행합니다. 우리의 환경에서 SSL/TLS를 처리하는 다양한 방법이 있지만, 이번 POC에서는 백엔드 SSL 없이 로드 밸런서에서 SSL을 종료합니다.

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

로드 밸런서 생성을 선택합니다.
네트워크 로드 밸런서를 선택하고 생성을 선택합니다.
로드 밸런서 이름을 gitlab-loadbalancer로 설정하고 다음 추가 옵션을 설정합니다:
- 스킴: 인터넷 연결을 선택합니다.
- IP 주소 유형: IPv4를 선택합니다.
- VPC: 드롭다운 목록에서 gitlab-vpc를 선택합니다.
- 매핑: 목록에서 둘 다 공개 서브넷을 선택하여 로드 밸런서가 두 개의 가용 영역으로 트래픽을 라우팅할 수 있도록 합니다.
로드 밸런서에 대한 보안 그룹을 추가하여 트래픽 제어를 위한 방화벽 역할을 하도록 합니다. 보안 그룹 섹션에서 새 보안 그룹 생성을 선택하고, 이름(우리는 gitlab-loadbalancer-sec-group을 사용)과 설명을 입력하며, 어디서든 HTTP 및 HTTPS 트래픽(0.0.0.0/0, ::/0)을 허용합니다. 또한 SSH 트래픽도 허용하고, 사용자 지정 소스를 선택하여 신뢰할 수 있는 단일 IP 주소 또는 CIDR 표기법의 IP 주소 범위를 추가하여 사용자가 SSH를 통해 Git 작업을 수행할 수 있도록 합니다.

리스너 및 라우팅 섹션에서 22, 80, 및 443 포트에 대한 리스너를 설정하고 다음 타겟 그룹을 염두에 둡니다.

프로토콜	포트	타겟 그룹
TCP	80	`gitlab-loadbalancer-ssh-target`
TCP	22	`gitlab-loadbalancer-http-target`
TLC	443	`gitlab-loadbalancer-http-target`

포트 443의 TLS 리스너에 대해 보안 정책 설정에서:
1. 정책 이름: 드롭다운 목록에서 미리 정의된 보안 정책을 선택합니다. AWS 문서에서 네트워크 로드 밸런서를 위한 미리 정의된 SSL 보안 정책을 확인할 수 있습니다. GitLab 코드베이스에서 지원되는 SSL 암호 및 프로토콜의 목록을 확인하세요.
2. 기본 SSL/TLS 서버 인증서: ACM에서 SSL/TLS 인증서를 선택하거나 IAM에 인증서를 업로드합니다.

생성한 각 리스너에 대해 타겟 그룹을 생성하고 이전 표를 기반으로 할당해야 합니다. EC2 인스턴스를 아직 생성하지 않았으므로 타겟을 등록할 필요는 없습니다. EC2 인스턴스는 이후 오토 스케일링 그룹 설정의 일부로 생성되고 할당됩니다.
1. 타겟 그룹 생성을 선택합니다. 타겟 유형으로 인스턴스를 선택합니다.
2. 각 리스너에 대해 적절한 타겟 그룹 이름을 선택합니다:
  - gitlab-loadbalancer-http-target - 포트 80의 TCP 프로토콜
  - gitlab-loadbalancer-ssh-target - 포트 22의 TCP 프로토콜
3. IP 주소 유형으로 IPv4를 선택합니다.
4. VPC 드롭다운 목록에서 gitlab-vpc를 선택합니다.
5. gitlab-loadbalancer-http-target의 상태 검사에 대해 준비 상태 검사 엔드포인트를 사용해야 합니다. 상태 검사 엔드포인트에 대한 IP 허용 목록에 VPC IP 주소 범위(CIDR)을 추가해야 합니다.
6. gitlab-loadbalancer-ssh-target의 상태 검사에서는 TCP를 선택합니다.
  - gitlab-loadbalancer-http-target을 포트 80 및 443 리스너에 할당합니다.
  - gitlab-loadbalancer-ssh-target을 포트 22 리스너에 할당합니다.
7. 일부 속성은 타겟 그룹이 이미 생성된 후에만 구성할 수 있습니다. 요구 사항에 따라 구성할 수 있는 몇 가지 기능이 있습니다.
  - 클라이언트 IP 보존은 기본적으로 타겟 그룹에 대해 활성화되어 있습니다. 이는 로드 밸런서에 연결된 클라이언트의 IP가 GitLab 애플리케이션에서 보존되도록 합니다. 필요에 따라 이를 활성화/비활성화할 수 있습니다.
  - 프록시 프로토콜은 기본적으로 타겟 그룹에 대해 비활성화되어 있습니다. 이는 로드 밸런서가 프록시 프로토콜 헤더에 추가 정보를 보낼 수 있게 합니다. 이를 활성화하려면 내부 로드 밸런서, NGINX 등 다른 환경 구성 요소도 적절히 구성되어야 합니다. 이번 POC에서는 나중에 GitLab 노드에서만 활성화하면 됩니다.
로드 밸런서 생성을 선택합니다.

로드 밸런서가 실행 중이면, NLB를 통한 액세스를 구체화하기 위해 보안 그룹을 재방문할 수 있습니다.

로드 밸런서를 위한 DNS 구성

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

기존의 호스티드 존을 선택하거나, 도메인이 없는 경우 Create Hosted Zone을 선택하고, 도메인 이름을 입력한 후 Create를 선택합니다.
Create record를 선택하고 다음 값을 제공합니다:
1. Name: 도메인 이름(기본값을 사용) 또는 서브도메인을 입력합니다.
2. Type: A - IPv4 address를 선택합니다.
3. Alias: 기본값은 disabled입니다. 이 옵션을 활성화합니다.
4. Route traffic to: Alias to Network Load Balancer를 선택합니다.
5. Region: Network Load Balancer가 위치한 리전을 선택합니다.
6. Choose network load balancer: 이전에 생성한 Network Load Balancer를 선택합니다.
7. Routing Policy: Simple을 사용하지만, 사용 사례에 따라 다른 정책을 선택할 수 있습니다.
8. Evaluate Target Health: 이를 No로 설정하지만, 로드 밸런서가 대상 건강을 기반으로 트래픽을 라우팅하도록 선택할 수 있습니다.
9. Create를 선택합니다.
Route 53을 통해 도메인을 등록한 경우, 작업이 완료됩니다. 다른 도메인 등록업체를 사용한 경우, 도메인 등록업체에서 DNS 레코드를 업데이트해야 합니다. 다음을 수행해야 합니다:
1. Hosted zones를 선택하고 위에서 추가한 도메인을 선택합니다.
2. NS 레코드 목록이 표시됩니다. 도메인 등록업체의 관리자 패널에서 이들 각각을 도메인의 DNS 레코드로 NS 레코드로 추가합니다. 이 단계는 도메인 등록업체에 따라 다를 수 있습니다. 문제가 발생하면, Google에서 “name of your registrar” add DNS records를 검색하면 특정 도메인 등록업체에 대한 도움말 기사를 찾을 수 있을 것입니다.

이 작업을 수행하는 단계는 사용하는 등록업체에 따라 다르며, 이 가이드의 범위를 넘어서는 내용입니다.

RDS와 함께하는 PostgreSQL

우리의 데이터베이스 서버는 Amazon RDS for PostgreSQL을 사용하며, 여기에 대한 다중 AZ를 제공합니다 결과적으로 이중화를 위해 사용됩니다 (Aurora는 지원되지 않음). 먼저 보안 그룹과 서브넷 그룹을 만든 후, 실제 RDS 인스턴스를 생성합니다.

RDS 보안 그룹

데이터베이스에 대한 보안 그룹이 필요하며, 이는 나중에 배포하는 인스턴스에서 수신 트래픽을 허용해야 합니다 gitlab-loadbalancer-sec-group:

EC2 대시보드에서 왼쪽 메뉴에서 Security Groups를 선택합니다.
Create security group을 선택합니다.
이름을 입력합니다(우리는 gitlab-rds-sec-group을 사용하며), 설명을 추가하고 VPC 드롭다운 목록에서 gitlab-vpc를 선택합니다.
Inbound rules 섹션에서 Add rule을 선택하고 다음을 설정합니다:
1. Type: PostgreSQL 규칙을 검색하여 선택합니다.
2. Source type: “Custom”으로 설정합니다.
3. Source: 이전에 생성한 gitlab-loadbalancer-sec-group을 선택합니다.
완료되면 Create security group을 선택합니다.

RDS 서브넷 그룹

RDS 대시보드로 이동하여 왼쪽 메뉴에서 Subnet Groups를 선택합니다.
Create DB Subnet Group을 선택합니다.
Subnet group details에서 이름을 입력합니다(우리는 gitlab-rds-group을 사용하며), 설명을 추가하고 VPC 드롭다운 목록에서 gitlab-vpc를 선택합니다.
Availability Zones 드롭다운 목록에서 구성한 서브넷을 포함하는 가용 영역을 선택합니다. 우리의 경우, eu-west-2a와 eu-west-2b를 추가합니다.
Subnets 드롭다운 목록에서 두 개의 프라이빗 서브넷(10.0.1.0/24 및 10.0.3.0/24)을 선택합니다. 이는 서브넷 섹션에서 정의한 대로입니다.
준비가 되면 Create를 선택합니다.

데이터베이스 생성

경고:
버스트 가능 인스턴스(t 클래스 인스턴스)를 데이터베이스에 사용하지 마십시오. 이는 지속적인 고부하 기간 동안 CPU 크레딧이 소진되어 성능 문제를 일으킬 수 있습니다.

이제 데이터베이스를 생성할 시간입니다:

RDS 대시보드로 이동하여 왼쪽 메뉴에서 Databases를 선택하고 Create database를 선택합니다.
데이터베이스 생성 방법으로 Standard Create를 선택합니다.
데이터베이스 엔진으로 PostgreSQL을 선택하고, 데이터베이스 요구 사항에서 정의된 GitLab 버전에 대한 최소 PostgreSQL 버전을 선택합니다.
이는 생산 서버이므로, Templates 섹션에서 Production을 선택합니다.
Availability & durability에서 Multi-AZ DB instance를 선택하여 다른 가용 영역에 대기 RDS 인스턴스가 프로비저닝되도록 합니다.
Settings에서 다음을 사용합니다:
- DB 인스턴스 식별자에 gitlab-db-ha 사용.
- 마스터 사용자 이름에 gitlab 사용.
- 마스터 비밀번호로 매우 안전한 비밀번호 사용.
나중에 필요하므로 이들을 기록해 두십시오.
DB 인스턴스 크기로 Standard classes를 선택하고 드롭다운 목록에서 요구 사항을 충족하는 인스턴스 크기를 선택합니다. 우리는 db.m5.large 인스턴스를 사용합니다.
Storage에서 다음을 구성합니다:
1. 저장소 유형 드롭다운 목록에서 Provisioned IOPS (SSD)를 선택합니다. Provisioned IOPS (SSD) 저장소는 이 용도에 가장 적합합니다(비용 절감을 위해 General Purpose (SSD)를 선택할 수도 있습니다). Amazon RDS 저장소에서 더 읽어보세요.
2. 저장소를 할당하고 프로비저닝된 IOPS를 설정합니다. 우리는 각각 최소값 100과 1000을 사용합니다.
3. 스토리지 자동 스케일링을 활성화합니다(선택 사항) 및 최대 스토리지 임계값을 설정합니다.
Connectivity에서 다음을 구성합니다:
1. Virtual Private Cloud (VPC) 드롭다운 목록에서 이전에 생성한 VPC(gitlab-vpc)를 선택합니다.
2. DB subnet group에서 이전에 생성한 서브넷 그룹(gitlab-rds-group)을 선택합니다.
3. 공용 액세스를 No로 설정합니다.
4. VPC security group에서 Choose existing을 선택하고 위에서 생성한 gitlab-rds-sec-group을 드롭다운 목록에서 선택합니다.
5. Additional configuration에서 데이터베이스 포트를 기본값 5432로 둡니다.
Database authentication에서 Password authentication을 선택합니다.
Additional configuration 섹션을 확장하고 다음을 완료합니다:
1. 초기 데이터베이스 이름. 우리는 gitlabhq_production을 사용합니다.
2. 선호하는 백업 설정을 구성합니다.
3. 여기서 우리가 하는 유일한 다른 변경 사항은 Maintenance에서 자동 마이너 버전 업데이트를 비활성화하는 것입니다.
4. 다른 모든 설정은 그대로 두거나 필요에 따라 조정합니다.
5. 만족스러우면 Create database를 선택합니다.

이제 데이터베이스가 생성되었으므로 Redis를 ElastiCache로 설정하는 단계로 넘어갑니다.

Redis와 ElastiCache

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

Redis 보안 그룹 생성

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

Redis 서브넷 그룹

AWS 콘솔에서 ElastiCache 대시보드로 이동합니다.
왼쪽 메뉴에서 서브넷 그룹으로 가서 새로운 서브넷 그룹을 생성합니다(우리는 gitlab-redis-group이라고 이름 짓습니다).
앞서 생성한 VPC(gitlab-vpc)를 선택하고 선택한 서브넷 테이블이 프라이빗 서브넷만 포함하도록 합니다.
준비가 되면 생성을 선택합니다.

Redis 클러스터 생성

ElastiCache 대시보드로 돌아갑니다.
왼쪽 메뉴에서 Redis 캐시를 선택하고 Redis 캐시 생성을 선택하여 새로운 Redis 클러스터를 생성합니다.
배포 옵션에서 자신의 캐시 설계를 선택합니다.
생성 방법에서 클러스터 캐시를 선택합니다.
클러스터 모드에서 지원되지 않는 비활성화를 선택합니다. 클러스터 모드가 없더라도 여러 가용 영역에 Redis를 배포할 수 있습니다.
클러스터 정보에서 클러스터 이름을 지정합니다(gitlab-redis) 및 설명을 추가합니다.
위치에서 AWS Cloud를 선택하고 Multi-AZ 옵션을 활성화합니다.
클러스터 설정 섹션에서:
1. 엔진 버전으로, GitLab 버전에 대해 정의된 Redis 버전을 선택합니다 Redis 요구 사항.
2. 포트는 6379로 그대로 두는데, 이는 우리가 위에서 사용한 Redis 보안 그룹의 포트입니다.
3. 노드 유형을 선택합니다(최소 cache.t3.medium, 필요에 따라 조정) 및 복제본 수를 선택합니다.
연결 설정 섹션에서:
1. 네트워크 유형: IPv4
2. 서브넷 그룹: 기존 서브넷 그룹 선택을 선택하고 우리가 이전에 생성한 gitlab-redis-group을 선택합니다.
가용 영역 배치 섹션에서:
1. 선호하는 가용 영역을 수동으로 선택하고 “Replica 2” 아래에서 다른 두 영역과 다른 영역을 선택합니다.
다음을 선택합니다.
보안 설정에서 보안 그룹을 편집하고 우리가 이전에 생성한 gitlab-redis-sec-group을 선택합니다. 다음을 선택합니다.
나머지 설정은 기본값으로 두거나 원하는 대로 편집합니다.
완료되면 생성을 선택합니다.

배치 호스트 설정

우리의 GitLab 인스턴스가 프라이빗 서브넷에 있기 때문에, 구성 변경 및 업그레이드 수행과 같은 작업을 위해 SSH로 이러한 인스턴스에 연결할 방법이 필요합니다. 이를 수행하는 한 가지 방법은 배치 호스트를 사용하는 것으로, 때때로 점프 박스라고도 합니다.

배치 호스트를 유지 관리하고 싶지 않다면, 인스턴스에 대한 접근을 위해 AWS Systems Manager Session Manager를 설정할 수 있습니다. 이는 이 문서의 범위를 벗어납니다.

배치 호스트 A 생성

EC2 대시보드로 이동하여 인스턴스 시작을 선택합니다.
이름 및 태그 섹션에서 이름을 Bastion Host A로 설정합니다.
최신 Ubuntu Server LTS (HVM) AMI를 선택합니다. GitLab 문서에서 최신 지원 OS 버전을 확인하세요.
인스턴스 유형을 선택합니다. 우리는 t2.micro를 사용하며, 배치 호스트를 다른 인스턴스에 SSH로 접속하는 데만 사용합니다.
키 쌍 섹션에서 새 키 쌍 생성을 선택합니다.
1. 키 쌍에 이름을 줍니다(우리는 bastion-host-a를 사용하며, bastion-host-a.pem 파일을 나중에 사용할 수 있도록 저장합니다).
네트워크 설정 섹션을 편집합니다:
1. VPC에서 드롭다운 목록에서 gitlab-vpc를 선택합니다.
2. 서브넷에서 이전에 생성한 퍼블릭 서브넷(gitlab-public-10.0.0.0)을 선택합니다.
3. 공용 IP 자동 할당에서 사용 안 함이 선택되어 있는지 확인합니다. Elastic IP 주소는 다음 섹션에서 호스트에 할당됩니다.
4. 방화벽에서 보안 그룹 생성을 선택하고, 보안 그룹 이름을 입력합니다(우리는 bastion-sec-group을 사용합니다) 및 설명을 추가합니다.
5. 우리는 모든 곳에서 SSH 접근을 허용합니다(0.0.0.0/0). 보다 엄격한 보안을 원하신다면, 단일 IP 주소 또는 CIDR 표기법으로 IP 주소 범위를 지정하세요.
스토리지에 대해서는 모든 것을 기본값으로 두고 8 GB 루트 볼륨만 추가합니다. 우리는 이 인스턴스에 아무것도 저장하지 않습니다.
모든 설정을 검토하고, 만족스러우면 인스턴스 시작을 선택합니다.

배치 호스트 A에 Elastic IP 할당

EC2 대시보드로 이동하여 네트워크 및 보안을 선택합니다.
Elastic IPs를 선택하고 Network border group을 us-west-2로 설정합니다.
할당을 선택합니다.
생성된 Elastic IP 주소를 선택합니다.
작업을 선택하고 Elastic IP 주소 연결을 선택합니다.
리소스 유형에서 인스턴스를 선택하고 인스턴스 드롭다운 목록에서 Bastion Host A 호스트를 선택합니다.
연결을 선택합니다.

인스턴스에 SSH로 접속할 수 있는지 확인

EC2 대시보드에서 왼쪽 메뉴의 인스턴스를 선택합니다.
인스턴스 목록에서 Bastion Host A를 선택합니다.
연결을 선택하고 연결 지침을 따릅니다.
성공적으로 연결할 수 있다면, 이중화용으로 두 번째 배치 호스트 설정으로 이동합시다.

Bastion Host B 생성

위의 단계를 따라 다음 변경 사항으로 EC2 인스턴스를 생성합니다:
1. 서브넷에서 이전에 생성한 두 번째 공용 서브넷(gitlab-public-10.0.2.0)을 선택합니다.
2. 태그 추가 섹션에서 Key: Name과 Value: Bastion Host B를 설정하여 두 개의 인스턴스를 쉽게 식별할 수 있도록 합니다.
3. 보안 그룹에서 위에서 생성한 기존 bastion-sec-group을 선택합니다.

SSH 에이전트 포워딩 사용

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

배스천 호스트에 개인 키 파일을 저장하는 것은 바람직하지 않습니다. 이를 해결하기 위해 클라이언트에서 SSH 에이전트 포워딩을 사용하세요.

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

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

다른 클라이언트에 대해 SSH 에이전트 포워딩을 사용하는 방법에 대한 단계별 가이드는 Securely Connect to Linux Instances Running in a Private Amazon VPC를 참조하세요.

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

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

GitLab 설치

EC2 대시보드에서:

“AWS에서 공식 GitLab 생성 AMI ID 찾기“라는 제목의 섹션을 사용하여 올바른 AMI를 찾아 Launch를 선택합니다.
이름 및 태그 섹션에서 이름을 GitLab으로 설정합니다.
인스턴스 유형 드롭다운 목록에서 워크로드에 따라 인스턴스 유형을 선택합니다. 하드웨어 요구 사항을 참고하여 귀하의 요구에 맞는 유형을 선택하세요 (최소 c5.2xlarge, 이는 100명의 사용자를 수용하기에 충분합니다).
키 페어 섹션에서 새 키 페어 생성을 선택합니다.
1. 키 페어 이름을 지정하고(우리는 gitlab을 사용합니다) 나중에 사용할 gitlab.pem 파일을 저장합니다.
네트워크 설정 섹션에서:
1. VPC: 이전에 생성한 gitlab-vpc를 선택합니다.
2. 서브넷: 이전에 생성한 서브넷 목록에서 gitlab-private-10.0.1.0을 선택합니다.
3. 자동 공용 IP 할당: 비활성화를 선택합니다.
4. 방화벽: 기존 보안 그룹 선택을 선택하고 이전에 생성한 gitlab-loadbalancer-sec-group을 선택합니다.
스토리지는 루트 볼륨이 기본적으로 8 GiB이며, 이곳에 데이터를 저장하지 않기 때문에 충분해야 합니다.
모든 설정을 검토하고 만족하면 인스턴스 시작을 선택합니다.

사용자 정의 구성 추가

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

Let’s Encrypt 비활성화

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

/etc/gitlab/gitlab.rb를 열고 비활성화합니다:
```
letsencrypt['enable'] = false
```
파일을 저장하고 변경 사항을 적용하려면 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

PostgreSQL에 필요한 확장 설치

GitLab 인스턴스에서 RDS 인스턴스에 연결하여 접근을 확인하고 필요한 pg_trgm 및 btree_gist 확장을 설치합니다.

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

콜론 및 포트 번호는 포함하지 마세요:

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

psql 프롬프트에서 확장을 생성한 후 세션을 종료합니다:

psql (10.9)
도움말은 "help"를 입력하세요.

gitlab=# CREATE EXTENSION pg_trgm;
gitlab=# CREATE EXTENSION btree_gist;
gitlab=# \q

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

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

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

# 내장 Postgres 비활성화
 postgresql['enable'] = false

# 연결 세부 정보 입력
gitlab_rails['db_adapter'] = "postgresql"
gitlab_rails['db_encoding'] = "unicode"
gitlab_rails['db_database'] = "gitlabhq_production"
gitlab_rails['db_username'] = "gitlab"
gitlab_rails['db_password'] = "mypassword"
gitlab_rails['db_host'] = "<rds-endpoint>"

다음으로, 호스트를 추가하고 포트의 주석을 제거하여 Redis 섹션을 구성해야 합니다:

# 내장 Redis 비활성화
redis['enable'] = false

# 연결 세부 정보 입력
gitlab_rails['redis_host'] = "<redis-endpoint>"
gitlab_rails['redis_port'] = 6379

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

Gitaly 설정하기

경고:

이 아키텍처에서는 단일 Gitaly 서버가 단일 실패 지점을 생성합니다.

이 제한을 제거하려면 Gitaly Cluster를 사용하세요.

Gitaly는 Git 리포지토리에 대한 고급 RPC 액세스를 제공하는 서비스입니다.

이 서비스는 이전에 구성한 프라이빗 서브넷 중 하나의 별도 EC2 인스턴스에서 활성화 및 구성해야 합니다.

Gitaly를 설치할 EC2 인스턴스를 생성해 보겠습니다:

EC2 대시보드에서 인스턴스 시작을 선택합니다.
이름 및 태그 섹션에서 이름을 Gitaly로 설정합니다.
AMI를 선택합니다. 이 예제에서는 최신 Ubuntu Server LTS (HVM), SSD 볼륨 유형을 선택합니다. GitLab 문서에서 최신 지원 OS 버전을 확인하세요.
인스턴스 유형을 선택합니다. 우리는 m5.xlarge를 선택합니다.
키 쌍 섹션에서 새 키 쌍 생성을 선택합니다.
1. 키 쌍 이름을 지정합니다(우리는 gitaly를 사용) 및 나중에 사용할 수 있도록 gitaly.pem 파일을 저장합니다.
네트워크 설정 섹션에서:
1. VPC에서 드롭다운 목록에서 gitlab-vpc를 선택합니다.
2. 서브넷에서 이전에 생성한 프라이빗 서브넷(gitlab-private-10.0.1.0)을 선택합니다.
3. 공용 IP 자동 할당에서 비활성화가 선택되어 있는지 확인합니다.
4. 방화벽에서 보안 그룹 생성을 선택하고 보안 그룹 이름을 입력합니다(우리는 gitlab-gitaly-sec-group을 사용) 및 설명을 추가합니다.
  1. 사용자 지정 TCP 규칙을 만들고 포트 범위에 포트 8075를 추가합니다. 소스에서 gitlab-loadbalancer-sec-group을 선택합니다.
  2. 또한 bastion-sec-group에서 SSH에 대한 인바운드 규칙을 추가하여 Bastion 호스트에서 SSH 에이전트 포워딩을 통해 연결할 수 있습니다.
루트 볼륨 크기를 20 GiB로 늘리고 볼륨 유형을 Provisioned IOPS SSD (io1)으로 변경합니다. (볼륨 크기는 임의의 값입니다. 리포지토리 저장 요구 사항에 맞게 충분히 큰 볼륨을 생성하세요.)
1. IOPS를 1000으로 설정합니다(20 GiB x 50 IOPS). GiB당 최대 50 IOPS를 프로비저닝할 수 있습니다. 더 큰 볼륨을 선택하면 IOPS를 그에 맞게 증가시킵니다. git과 같이 많은 소규모 파일이 직렬로 기록되는 워크로드는 성능이 뛰어난 스토리지가 필요하므로 Provisioned IOPS SSD (io1)를 선택하는 것이 좋습니다.
모든 설정을 검토하고 괜찮다면 인스턴스 시작을 선택합니다.

참고:

구성 및 리포지토리 데이터를 루트 볼륨에 저장하는 대신, 리포지토리 저장을 위해 추가 EBS 볼륨을 추가할 수도 있습니다. 위와 동일한 가이드를 따르세요. Amazon EBS 가격을 확인하세요. GitLab의 성능에 부정적인 영향을 미칠 수 있으므로 EFS 사용을 권장하지 않습니다. 추가 세부 사항은 관련 문서를 검토할 수 있습니다.

이제 EC2 인스턴스가 준비되었으니 문서에 따라 GitLab을 설치하고 Gitaly를 별도의 서버에서 설정하세요. 위에서 생성한 GitLab 인스턴스에서 해당 문서의 클라이언트 설정 단계를 수행하세요.

프록시 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 객체, 업로드, 병합 요청 차이, 컨테이너 레지스트리 이미지 등을 저장하기 위해 Amazon S3 버킷을 사용합니다. 우리의 문서에는 이러한 데이터 유형 각각에 대한 객체 저장소 구성 지침과 GitLab에서 객체 저장소를 사용하는 다른 정보가 포함되어 있습니다.

참고: 우리가 이전에 만든 AWS IAM 프로파일을 사용하기 때문에, 객체 저장소를 구성할 때 AWS 액세스 키와 비밀 액세스 키/값 쌍을 생략해야 합니다. 대신, 위에서 링크된 객체 저장소 문서에 보여준 대로 'use_iam_profile' => true를 구성에 사용하세요.

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
```

프록시 프로토콜

이전에 생성한 로드 밸런서에서 프록시 프로토콜이 활성화되어 있다면, 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
```

처음 로그인하기

로드 밸런서를 설정할 때 사용한 도메인 이름을 사용하여 이제 브라우저에서 GitLab에 방문할 수 있습니다.

GitLab을 설치한 방법에 따라 다르지만, 비밀번호를 다른 방법으로 변경하지 않았다면 기본 비밀번호는 다음 중 하나입니다:

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

기본 비밀번호를 변경하려면 기본 비밀번호로 root 사용자로 로그인한 후 사용자 프로필에서 비밀번호를 변경하세요.

우리의 오토 스케일링 그룹이 새로운 인스턴스를 시작하면, 사용자 이름 root와 새로 생성된 비밀번호로 로그인할 수 있습니다.

커스텀 AMI 생성

EC2 대시보드에서:

우리가 이전에 생성한 GitLab 인스턴스를 선택합니다.
작업을 선택하고, 이미지 및 템플릿으로 스크롤한 후 이미지 생성을 선택합니다.
이미지에 이름과 설명을 제공하세요(우리는 두 개 모두 GitLab-Source를 사용합니다).
나머지는 기본값 그대로 두고 이미지 생성을 선택합니다.

이제 다음 단계에서 사용할 우리의 커스텀 AMI가 생성되었습니다.

오토 스케일링 그룹 내에 GitLab 배포

실행 템플릿 생성

EC2 대시보드에서:

왼쪽 메뉴에서 실행 템플릿을 선택하고 실행 템플릿 생성을 선택합니다.
실행 템플릿의 이름을 입력합니다(우리는 gitlab-launch-template을 사용합니다).
실행 템플릿 내용을 선택하고 내 AMI 탭을 선택합니다.
내가 소유한를 선택하고 위에서 생성한 GitLab-Source 커스텀 AMI를 선택합니다.
필요에 가장 적합한 인스턴스 유형을 선택합니다(최소 c5.2xlarge).
키 쌍 섹션에서 새 키 쌍 만들기를 선택합니다.
1. 키 쌍 이름을 입력합니다(우리는 gitlab-launch-template을 사용합니다)하고, 나중에 사용할 수 있도록 gitlab-launch-template.pem 파일을 저장합니다.
루트 볼륨은 기본적으로 8 GiB이며, 그곳에 데이터를 저장하지 않으므로 충분해야 합니다. 보안 그룹 구성을 선택합니다.
기존 보안 그룹 선택을 체크한 후, 우리가 이전에 생성한 gitlab-loadbalancer-sec-group을 선택합니다.
네트워크 설정 섹션에서:
1. 방화벽: 기존 보안 그룹 선택을 선택하고, 우리가 이전에 생성한 gitlab-loadbalancer-sec-group을 선택합니다.
고급 세부정보 섹션에서:
1. IAM 인스턴스 프로필: 우리가 이전에 생성한 GitLabS3Access 역할을 선택합니다.
모든 설정을 검토하고, 만족스러우면 실행 템플릿 생성을 선택합니다.

자동 크기 조정 그룹 생성

EC2 대시보드에서:

왼쪽 메뉴에서 Auto scaling groups를 선택하고 Create Auto Scaling group을 선택합니다.
Group name을 입력합니다(우리는 gitlab-auto-scaling-group을 사용합니다).
Launch template에서 우리가 이전에 만든 런치 템플릿을 선택합니다. Next를 선택합니다.
네트워크 설정 섹션에서:
1. VPC에서 드롭다운 목록에서 gitlab-vpc를 선택합니다.
2. Availability Zones and subnets에서 우리가 이전에 만든 개인 서브넷(gitlab-private-10.0.1.0 및 gitlab-private-10.0.3.0)을 선택합니다.
3. Next를 선택합니다.
로드 밸런싱 설정 섹션에서:
1. Attach to an existing load balancer를 선택합니다.
2. Existing load balancer target groups 드롭다운 목록에서 우리가 이전에 만든 대상 그룹을 선택합니다.
3. Health Check Type에서 Turn on Elastic Load Balancing health checks 옵션을 체크합니다. 우리는 Health Check Grace Period를 기본값인 300 초로 유지합니다.
4. Next를 선택합니다.
Group size에서 Desired capacity를 2로 설정합니다.
크기 조정 설정 섹션에서:
1. No scaling policies를 선택합니다. 정책은 나중에 구성됩니다.
2. Min desired capacity: 2로 설정합니다.
3. Max desired capacity: 4로 설정합니다.
4. Next를 선택합니다.
마지막으로, 알림 및 태그를 적절하게 구성하고, 변경 사항을 검토한 후 자동 크기 조정 그룹을 생성합니다.
자동 크기 조정 그룹이 생성된 후, Cloudwatch에서 스케일 업 및 다운 정책을 생성하고 이를 할당해야 합니다.
1. 우리가 이전에 만든 EC2 인스턴스 By Auto Scaling Group의 메트릭에 대해 CPUUtilization의 알람을 생성합니다.
2. 다음 조건을 사용하여 스케일 업 정책을 생성합니다:
  1. CPUUtilization이 60% 이상일 때 Add 1 용량 단위를 추가합니다.
  2. Scaling policy name을 Scale Up Policy로 설정합니다.
1. 다음 조건을 사용하여 스케일 다운 정책을 생성합니다:
  1. CPUUtilization이 45% 이하일 때 Remove 1 용량 단위를 제거합니다.
  2. Scaling policy name을 Scale Down Policy로 설정합니다.
1. 우리가 이전에 만든 자동 크기 조정 그룹에 새로운 동적 크기 조정 정책을 할당합니다.

자동 크기 조정 그룹이 생성되면, 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을 복원하려면, 먼저 복원 문서를 검토하고, 주로 복원 전제 조건을 확인합니다. 그런 다음, 리눅스 패키지 설치 섹션 아래의 단계를 따릅니다.

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는 널리 분산된 개발 팀을 위한 솔루션입니다.
리눅스 패키지 - GitLab 인스턴스를 관리하는 데 알아야 할 모든 것.
라이선스 추가하기: 라이선스와 함께 모든 GitLab Enterprise Edition 기능을 활성화합니다.
가격 책정: 다양한 티어의 가격.

문제 해결

인스턴스가 상태 검사에 실패하고 있습니다.

인스턴스가 로드 밸런서의 상태 검사에 실패하는 경우, 이전에 구성한 상태 검사 엔드포인트에서 상태 200을 반환하고 있는지 확인하십시오. 상태 302와 같은 리디렉션을 포함한 다른 모든 상태는 상태 검사가 실패하게 만듭니다.

상태 검사가 통과하기 전에 로그인 엔드포인트에서 자동 리디렉션을 방지하기 위해 root 사용자에 비밀번호를 설정해야 할 수도 있습니다.

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

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

일부 작업 로그가 오브젝트 스토리지에 업로드되지 않음

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

증분 로그 기록을 활성화하십시오.

AWS(아마존 웹 서비스)에서 GitLab POC 설치하기

프로덕션 수준 GitLab 시작하기

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

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

소개

요구 사항

아키텍처

AWS 비용

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

IAM 정책 생성

IAM 역할 생성

네트워크 구성

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

서브넷

인터넷 게이트웨이

NAT 게이트웨이 생성

라우트 테이블

공개 라우트 테이블

개인 라우트 테이블

로드 밸런서

로드 밸런서를 위한 DNS 구성

RDS와 함께하는 PostgreSQL

RDS 보안 그룹

RDS 서브넷 그룹

데이터베이스 생성

Redis와 ElastiCache

Redis 보안 그룹 생성

Redis 서브넷 그룹

Redis 클러스터 생성

배치 호스트 설정

배치 호스트 A 생성

배치 호스트 A에 Elastic IP 할당

인스턴스에 SSH로 접속할 수 있는지 확인

Bastion Host B 생성

SSH 에이전트 포워딩 사용

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

GitLab 설치

사용자 정의 구성 추가

Let’s Encrypt 비활성화

PostgreSQL에 필요한 확장 설치

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

Gitaly 설정하기

프록시 SSL 지원 추가

승인된 SSH 키의 빠른 조회

호스트 키 구성

Amazon S3 객체 저장소

IP 허용 목록

프록시 프로토콜

처음 로그인하기

커스텀 AMI 생성

오토 스케일링 그룹 내에 GitLab 배포

실행 템플릿 생성

자동 크기 조정 그룹 생성

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

GitLab Runner

백업 및 복원

GitLab 백업하기

백업에서 GitLab 복원하기

GitLab 업데이트

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

결론

문제 해결

인스턴스가 상태 검사에 실패하고 있습니다.

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

일부 작업 로그가 오브젝트 스토리지에 업로드되지 않음

도움말

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

도움받기