상업용 GitLab 시작하기
- 생산 용량 Linux 패키지 설치 시작하기
- 생산 용량 클라우드 네이티브 하이브리드 GitLab 시작하기
소개
요구 사항
아키텍처
AWS 비용
IAM EC2 인스턴스 역할 및 프로필 생성
- IAM 정책 생성
- IAM 역할 생성
네트워크 구성
- Virtual Private Cloud (VPC) 생성
- 서브넷
- 인터넷 게이트웨이
- NAT 게이트웨이 생성
- 경로 테이블
  - 공용 경로 테이블
  - 프라이빗 라우트 테이블
로드 밸런서
- 로드 밸런서용 DNS 구성
RDS를 사용한 PostgreSQL
- RDS 보안 그룹
- RDS 서브넷 그룹
- 데이터베이스 생성
ElastiCache에서의 Redis
- Redis 보안 그룹 생성
- Redis 서브넷 그룹
- Redis 클러스터 생성
베스천 호스트 설정
- 베스천 호스트 A 생성
- Bastion Host B 만들기
- SSH 에이전트 포워딩 사용하기
GitLab 설치 및 사용자 정의 AMI 생성
- GitLab 설치
- 사용자 정의 구성 추가
- 처음으로 로그인
- 사용자 지정 AMI 생성
auto scaling 그룹 안에서 GitLab 배포
- 시작 구성 만들기
- 자동 확장 그룹 만들기
Prometheus를 사용한 헬스 체크 및 모니터링
GitLab Runner
백업 및 복원
- GitLab 백업
- 백업에서 GitLab 복원하기
GitLab 업데이트
공식 GitLab 생성 AMI ID AWS에서 찾기
결론
문제 해결
- 인스턴스의 상태 확인에 실패하는 경우
- “요청한 변경 사항이 거부되었습니다 (422)”
- 일부 작업 로그가 객체 저장소에 업로드되지 않음

Amazon Web Services(AWS)에 GitLab POC 설치

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

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

1,000명 이하의 사용자를 보유한 조직의 경우 권장되는 AWS 설치 방법은 EC2 단일 박스 Linux 패키지 설치 및 데이터 백업을 위한 스냅숏 전략을 구현하는 것입니다. 자세한 내용은 1,000명 이하 사용자 참조 아키텍처에서 확인하십시오.

상업용 GitLab 시작하기

본 문서는 개념 증명 인스턴스의 설치 가이드입니다. 참조 아키텍처가 아니며 고가용성 구성을 보장하지 않습니다.

이 가이드를 정확하게 따르면 대략 비고가용성(Non-HA) 2가용 영역 구현의 축소된 버전에 상응하는 개념 증명 인스턴스가 생성됩니다. 2K 참조 아키텍처는 비고가용성이 아니며 복잡성과 비용을 낮추면서 일부 확장을 제공하기 위해 주로 만들어졌습니다. 3,000명 사용자 참조 아키텍처는 GitLab HA가 되는 가장 작은 크기로, 주로 Git 저장소 저장을 위해 Gitaly Cluster를 사용하여 HA를 달성하고 3중 재접속을 명시합니다.

GitLab은 두 가지 주요 유형의 참조 아키텍처를 유지 및 테스트합니다. Linux 패키지 아키텍처는 인스턴스 컴퓨트에 구현되고, Cloud Native Hybrid 아키텍처는 Kubernetes 클러스터의 사용을 극대화합니다. Cloud Native Hybrid 참조 아키텍처 사양은 Linux 패키지 아키텍처를 설명하는 참조 아키텍처 크기 페이지의 부록 섹션입니다. 예를 들어, 3000명 사용자 클라우드 네이티브 참조 아키텍처는 3000명 참조 아키텍처 페이지의 Helm 차트(대안)로 Cloud Native Hybrid 참조 아키텍처에 위치해 있습니다.

생산 용량 Linux 패키지 설치 시작하기

인프라스트럭처 자동화 도구인 GitLab Environment Tool (GET)은 AWS의 Linux 패키지에 사용하면 가장 좋습니다. 특히 HA 설정을 대상으로 하는 경우입니다. 모든 것을 자동화하지는 않지만 Gitaly Cluster와 같이 복잡한 설정을 완료합니다. GET는 오픈 소스이므로 누구나 기여하고 개선할 수 있습니다.

생산 용량 클라우드 네이티브 하이브리드 GitLab 시작하기

GitLab Environment Toolkit (GET)은 일련의 의견이 강한 Terraform 및 Ansible 스크립트입니다. 이러한 스크립트는 선택한 클라우드 제공 업체에서 Linux 패키지 또는 클라우드 네이티브 하이브리드 환경을 배포하는 데 도움이 되며, GitLab 개발자들이 GitLab Dedicated에 사용합니다.

GitLab Environment Toolkit을 사용하여 AWS에 클라우드 네이티브 하이브리드 환경을 배포할 수 있습니다. 그러나 필수는 아니며 모든 유효한 순열을 지원하지 않을 수 있습니다. 그렇지만 스크립트는 그대로 제공되며 필요에 따라 적절하게 수정할 수 있습니다.

소개

대부분의 경우, Linux 패키지를 사용하여 설정하지만, AWS의 기본 서비스를 활용하기도 합니다. Linux 패키지에 번들된 PostgreSQL과 Redis 대신 Amazon RDS와 ElastiCache를 사용합니다.

이 가이드에서는 가상 개인 클라우드 및 서븍넷을 구성한 후 데이터베이스 서버로 RDS 등 서비스를 통합하고 Redis 클러스터로 ElastiCache 서비스를 관리하여 사용자 정의 확장 정책을 적용하며 자동 스케일링 그룹으로 관리하는 다중 노드 설치를 진행합니다.

요구 사항

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

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(가격 페이지)를 사용합니다.
ELB: Classic Load Balancer(가격 페이지)로, GitLab 인스턴스로의 요청을 라우팅하는 데 사용됩니다.
RDS: PostgreSQL을 사용하는 Amazon Relational Database Service (가격 페이지).
ElastiCache: Redis 구성을 제공하기 위해 사용되는 인-메모리 캐시 환경(가격 페이지).

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

Amazon S3 객체 저장소를 사용하기 때문에, EC2 인스턴스는 S3 버킷에 대한 읽기, 쓰기 및 목록 권한을 갖춰야 합니다. GitLab 구성에 AWS 키를 임베드하지 않으려면, 이러한 액세스를 허용하기 위해 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 대시보드에 있는 경우, 좌측 메뉴에서 역할을 선택하고 역할 생성을 선택합니다.
AWS 서비스 > EC2를 선택하여 새 역할을 만든 후, 다음: 권한을 선택합니다.
정책 필터에서 위에서 생성한 gl-s3-policy를 검색한 후 선택한 후, 태그를 선택합니다.
필요한 경우 태그를 추가한 후 검토를 선택합니다.
역할에 이름을 지정한 후(여기서는 GitLabS3Access를 사용), 역할 생성을 선택합니다.

나중에 발표 구성 시에 이 역할을 사용합니다.

네트워크 구성

GitLab 클라우드 인프라를 위한 VPC를 생성하여 시작하고, 적어도 두 개의 가용 영역(AZ)에서 공용 및 사설 인스턴스를 갖도록 서브넷을 생성할 수 있습니다. 공용 서브넷에는 라우트 테이블을 유지하고 연결된 인터넷 게이트웨이가 필요합니다.

Virtual Private Cloud (VPC) 생성

Amazon Web Services에 로그인합니다.
좌측 메뉴에서 Your VPCs를 선택한 후, VPC 생성을 선택합니다. “이름 태그”에 gitlab-vpc를 입력하고, “IPv4 CIDR 블록”에 10.0.0.0/16를 입력합니다. 별도의 하드웨어가 필요하지 않은 경우, “테넌시”는 기본 값을 유지할 수 있습니다. 준비가 되면 예, 생성을 선택합니다.
VPC를 선택한 후, 작업을 선택한 다음, DNS 해법 설정 편집을 선택하여 DNS 해법을 활성화합니다. 완료되면 저장을 선택합니다.

서브넷

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

로드 밸런서 및 RDS 인스턴스와 일치하도록 비공개 및 공용 서브넷을 만들어 봅시다:

왼쪽 메뉴에서 서브넷을 선택합니다.
서브넷 생성을 선택합니다. 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`

모든 서브넷을 만든 후, 두 공용 서브넷에 대해 IPv4 자동 할당을 활성화합니다:
1. 각 공용 서브넷을 차례로 선택한 다음 작업을 선택하고 자동 할당 IP 설정 수정을 선택합니다. 이 옵션을 활성화하고 저장합니다.

인터넷 게이트웨이

이제 여전히 같은 대시보드에서 인터넷 게이트웨이로 이동하여 새로 생성해 봅시다:

왼쪽 메뉴에서 인터넷 게이트웨이를 선택합니다.
인터넷 게이트웨이 생성을 선택하고, gitlab-gateway라는 이름을 지정하고 생성을 선택합니다.
표에서 선택한 다음 작업 드롭다운 목록에서 “VPC에 연결”을 선택합니다.
목록에서 gitlab-vpc를 선택하고 연결을 누릅니다.

NAT 게이트웨이 생성

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

VPC 대시보드로 이동하여 왼쪽 메뉴에서 NAT 게이트웨이를 선택합니다.
NAT 게이트웨이 생성을 선택하고 다음을 완료합니다:
1. 서브넷: 드롭다운 목록에서 gitlab-public-10.0.0.0을 선택합니다.
2. 엘라스틱 IP 할당 ID: 기존의 Elastic IP를 입력하거나 새 IP를 할당하려면 엘라스틱 IP 주소 할당을 선택합니다.
3. 필요에 따라 태그를 추가합니다.
4. NAT 게이트웨이 생성을 선택합니다.

두 번째 NAT 게이트웨이를 생성하되, 이번에는 두 번째 공용 서브넷 gitlab-public-10.0.2.0에 배치합니다.

경로 테이블

공용 경로 테이블

이전 단계에서 생성한 인터넷 게이트웨이를 통해 인터넷에 연결하기 위해 공용 서브넷용 경로 테이블을 만들어야 합니다.

VPC 대시보드에서:

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

이제 인터넷 게이트웨이를 새로운 대상으로 추가하고 어떤 대상에서도 트래픽을 받을 수 있도록 해야 합니다.

경로 테이블을 선택한 다음 아래에서 옵션을 보여주는 gitlab-public 경로를 선택합니다.
경로 탭을 선택하고 경로 편집 > 경로 추가를 선택하여 대상을 0.0.0.0/0로 설정합니다. 대상 열에서 이전에 만든 gitlab-gateway를 선택합니다.
완료되면 경로 저장을 선택합니다.

이제 공용 서브넷을 경로 테이블에 연결해야 합니다:

서브넷 연결 탭을 선택한 다음 서브넷 연결 편집을 선택합니다.
공용 서브넷만 선택한 후 저장을 선택합니다.

프라이빗 라우트 테이블

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

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

로드 밸런서

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

EC2 대시보드에서 왼쪽 탐색 창에서 로드 밸런서를 찾습니다:

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

로드 밸런서가 실행되고 작동하기 시작하면 보안 그룹을 다시 확인하여 ELB를 통한 액세스 및 기타 요구 사항을 정제할 수 있습니다.

로드 밸런서용 DNS 구성

Route 53 대시 보드에서 왼쪽 탐색 창에서 호스팅된 영역을 선택하세요:

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

이를 수행하는 방법은 사용 중인 레지스트러에 따라 달라집니다.

RDS를 사용한 PostgreSQL

데이터베이스 서버에는 Aurora가 지원되지 않는 PostgreSQL을 사용하는 Amazon RDS를 사용합니다. 먼저 보안 그룹과 서브넷 그룹을 만든 후에 실제 RDS 인스턴스를 생성합니다.

RDS 보안 그룹

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

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

RDS 서브넷 그룹

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

데이터베이스 생성

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

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

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

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

ElastiCache에서의 Redis

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

Redis 보안 그룹 생성

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

Redis 서브넷 그룹

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

Redis 클러스터 생성

ElastiCache 대시보드로 돌아갑니다.
왼쪽 메뉴에서 Redis를 선택하고 새로운 Redis 클러스터를 만들기 위해 생성을 선택합니다. 클러스터 모드를 활성화하지 않습니다. 그러나 클러스터 모드를 사용하지 않더라도 여전히 다중 가용 영역에 Redis를 배포할 수 있습니다.
설정 섹션에서:
1. 클러스터에 이름을 지정합니다(gitlab-redis)하고 설명을 추가합니다.
2. 버전은 최신 버전을 선택합니다.
3. 포트는 6379로 유지합니다(위에서 Redis 보안 그룹에서 사용한 것과 동일).
4. 노드 유형을 선택합니다(적어도 cache.t3.medium은 사용하되 필요에 맞게 조정합니다) 및 복제본 수를 지정합니다.
고급 설정 섹션에서:
1. 멀티-AZ 자동 장애 조치 옵션을 선택합니다.
2. 이전에 생성한 서브넷 그룹을 선택합니다.
3. 원하는 가용 영역을 수동으로 선택하고 “Replica 2”에서 다른 영역을 선택합니다.
보안 설정에서 보안 그룹을 편집하고 이전에 생성한 gitlab-redis-sec-group을 선택합니다.
나머지 설정은 기본값으로 유지하거나 원하는대로 편집한 후 생성을 선택합니다.

베스천 호스트 설정

GitLab 인스턴스가 프라이빗 서브넷에 있기 때문에 구성 변경 및 업그레이드와 같은 작업을 수행하기 위해 SSH로 이러한 인스턴스에 연결해야 합니다. 이를 위해 베스천 호스트를 사용하는 방법이 있습니다.

참고: 베스천 호스트를 유지하고 싶지 않은 경우 AWS Systems Manager 세션 매니저를 인스턴스에 액세스할 수 있도록 설정할 수 있습니다. 이는 이 문서의 범위를 벗어납니다.

베스천 호스트 A 생성

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

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

EC2 대시보드에서 왼쪽 메뉴에서 인스턴스를 선택합니다.
인스턴스 목록에서 베스천 호스트 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 에이전트 포워딩의 사용 방법은 AWS에서 실행 중인 프라이빗 Amazon VPC에 안전하게 연결을 참조하세요.

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

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

GitLab 설치

EC2 대시 보드에서:

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

사용자 정의 구성 추가

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

Let’s Encrypt 비활성화

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

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

PostgreSQL에 필요한 확장 기능 설치

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

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

콜론과 포트 번호는 포함하지 않도록 주의하세요:

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

psql 프롬프트에서 확장 기능을 만든 다음 세션을 종료합니다:

psql (10.9)
Type "help" for help.

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

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

/etc/gitlab/gitlab.rb 파일을 편집하고 external_url 'http://<도메인>' 옵션을 찾은 후 사용 중인 https 도메인으로 변경하세요.

GitLab 데이터베이스 설정을 찾아 필요에 따라 주석 처리를 제거하세요. 현재 경우에는 데이터베이스 어댑터, 인코딩, 호스트, 이름, 사용자 이름 및 암호를 지정합니다.

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

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

다음으로 Redis 섹션을 구성해야 합니다. 호스트를 추가하고 포트의 주석 처리를 제거하세요.

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

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

마지막으로 변경 사항이 적용되도록 GitLab을 다시 구성해야 합니다.
```
sudo gitlab-ctl reconfigure
```
모든 것이 올바르게 설정되었는지 확인하려면 다음을 실행할 수 있습니다.
```
sudo gitlab-rake gitlab:check
sudo gitlab-ctl status
```

Gitaly 설정

경고: 이 아키텍처에서는 단일 Gitaly 서버가 단일 장애 지점을 만듭니다. 이 제한 사항을 해결하려면 Gitaly 클러스터를 사용하세요.

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

Gitaly를 설치할 EC2 인스턴스를 생성해 봅시다.

EC2 대시보드에서 인스턴스 시작을 선택하세요.
AMI를 선택하세요. 이 예제에서는 Ubuntu Server 18.04 LTS (HVM), SSD Volume Type를 선택합니다.
인스턴스 유형을 선택하세요. c5.xlarge를 선택합니다.
인스턴스 구성 세부정보 구성을 선택하세요.
1. 네트워크 드롭다운 목록에서 이전에 생성한 VPC인 gitlab-vpc를 선택하세요.
2. 서브넷 드롭다운 목록에서 이전에 생성한 서브넷 목록에서 gitlab-private-10.0.1.0을 선택하세요.
3. 자동 할당 퍼블릭 IP가 서브넷 설정 사용 (비활성화)로 설정되었는지 확인하세요.
4. 저장소 추가를 선택하세요.
루트 볼륨 크기를 20 GiB로 늘리고 볼륨 유형을 프로비저닝된 IOPS SSD (io1)로 변경하세요. (이는 임의의 크기입니다. 귀하의 저장소 저장 요구 사항에 맞게 충분한 크기의 볼륨을 만드세요.)
1. IOPS를 1000 (20 GiB x 50 IOPS)로 설정하세요. GiB 당 최대 50 IOPS까지 할당할 수 있습니다. 더 큰 볼륨을 선택하는 경우 IOPS를 증가하세요. git과 같은 직렬 방식으로 많은 작은 파일이 쓰이는 워크로드는 성능이 우수한 저장소를 필요로 합니다. 따라서 프로비저닝된 IOPS SSD (io1)를 선택합니다.
태그 추가를 선택하여 태그를 추가하세요. 이 경우에는 키: 이름, 값: Gitaly만 설정합니다.
보안 그룹 구성을 선택하고 새 보안 그룹 생성을 만드세요.
1. 보안 그룹에 이름과 설명을 추가하세요. 우리는 둘 다 gitlab-gitaly-sec-group을 사용합니다.
2. 사용자 지정 TCP 규칙을 만들어 포트 범위에 8075를 추가하세요. 소스에서 gitlab-loadbalancer-sec-group을 선택하세요.
3. bastion-sec-group에서 SSH를 위한 인바운드 규칙도 추가하여 SSH 에이전트 포워딩을 사용하여 Bastion 호스트에서 연결할 수 있도록 합니다.
설정에 만족하시면 검토 및 시작을 선택한 후 시작을 선택하세요.
마지막으로 선택한 개인 키 파일에 액세스할 수 있는 것을 확인하거나 새로운 파일을 생성한 후 인스턴스 시작을 선택하세요.

참고: 구성 및 저장소 데이터를 루트 볼륨에 저장하는 대신, 저장소 저장용 추가 EBS 볼륨을 추가할 수도 있습니다. 위의 지침과 동일한 지침을 따르세요. Amazon EBS 요금을 확인하세요. GitLab의 성능에 부정적인 영향을 미칠 수 있으므로 EFS의 사용을 권장하지는 않습니다. 자세한 내용은 관련 문서를 참조하세요.

이제 EC2 인스턴스를 마련했으므로, 독립적인 서버에서 Gitaly를 설치하고 구성하는 문서를 따릅니다. 그 문서에서 클라이언트 설정 단계를 생성한 GitLab 인스턴스에서 실행하세요.

Proxied SSL 지원 추가

로드 밸런서에서 SSL을 종료하는 경우, 프록시 SSL을 지원하는 단계를 따라 /etc/gitlab/gitlab.rb에서 이를 구성하십시오.

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

허용된 SSH 키의 빠른 조회

GitLab에 액세스가 허용된 사용자의 공개 SSH 키는 /var/opt/gitlab/.ssh/authorized_keys에 저장됩니다. 전형적으로 모든 인스턴스가 SSH를 통해 사용자가 Git 작업을 수행할 때 이 파일에 액세스할 수 있도록 공유 저장소를 사용합니다. 그러나 저희 구성에는 공유 저장소가 없기 때문에 GitLab 데이터베이스에서 색인 조회를 통해 SSH 사용자를 허용하도록 구성을 업데이트합니다.

authorized_keys 파일 대신 데이터베이스에서 빠른 SSH 키 조회를 설정하려면 빠른 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에서 다음을 업데이트하십시오:

# 프로토콜 버전 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를 생성하여 우리의 시작 구성 및 자동 확장 그룹에 사용할 계획입니다.

처음으로 로그인

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

GitLab을 설치한 방식 및 다른 방법을 통해 비밀번호를 변경하지 않은 경우, 기본 비밀번호는 다음 중 하나입니다:

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

기본 비밀번호를 변경하려면, root 사용자로 로그인하여 사용자 프로필에서 변경하십시오.

우리의 자동 확장 그룹이 새 인스턴스를 만드는 경우, 사용자 이름이 root이고 새로 생성된 비밀번호로 로그인할 수 있습니다.

사용자 지정 AMI 생성

EC2 대시보드에서:

이전에 만든 GitLab 인스턴스 선택
작업을 선택하고 이미지로 이동하고 이미지 생성을 선택
이미지에 이름과 설명(우리는 둘 다에 GitLab-Source를 사용)을 지정
그 외 모든 것을 기본값으로 두고 이미지 생성 선택

이제 사용자 지정 AMI가 있으며, 이를 다음 단계인 시작 구성을 만들기 위해 사용할 수 있습니다.

auto scaling 그룹 안에서 GitLab 배포

시작 구성 만들기

EC2 대시 보드에서:

왼쪽 메뉴에서 시작 구성(예: Launch Configurations)을 선택하고 시작 구성 만들기를 선택합니다.
왼쪽 메뉴에서 내 AMI(예: My AMIs)를 선택하고 위에서 만든 GitLab 사용자 정의 AMI를 선택합니다.
사용 가능한 인스턴스 유형 중에서 여러분의 요구에 가장 적합한 유형(최소한 c5.xlarge)을 선택하고 세부 정보 구성을 선택합니다.
시작 구성에 이름을 입력합니다(예: gitlab-ha-launch-config로 사용합니다).
요청 Spot Instance를 요청하지 않습니다.
IAM 역할(IAM Role) 드롭다운 목록에서 앞서 생성한 GitLabAdmin 인스턴스 역할을 선택합니다.
나머지는 기본값으로 두고 저장소 추가를 선택합니다.
루트 볼륨은 기본적으로 8GiB이며 여기에는 데이터를 저장하지 않기 때문에 충분합니다. 보안 그룹 구성을 선택합니다.
기존 보안 그룹 선택을 확인하고 앞서 만든 gitlab-loadbalancer-sec-group을 선택합니다.
검토(Review)를 선택하여 변경 내용을 검토하고 시작 구성 시작을 선택합니다.
개인 키에 액세스할 수 있는지 확인하거나 새로 생성합니다. 시작 구성 시작을 선택합니다.

자동 확장 그룹 만들기

시작 구성이 생성된 후, 자동 확장 그룹 생성하기를 선택하여 자동 확장 그룹 만들기를 시작합니다.
그룹 이름을 입력합니다 (예: gitlab-auto-scaling-group로 사용합니다).
그룹 크기에 시작할 인스턴스 수를 입력합니다 (예: 2를 입력합니다).
네트워크(Network) 드롭다운 목록에서 gitlab-vpc를 선택합니다.
앞서 생성한 개인 서브넷 모두를 추가합니다.
고급 세부 정보(Advanced Details) 섹션을 확장하고 하나 이상의 로드 밸런서에서 트래픽 수신 옵션을 확인합니다.
클래식 로드 밸런서(Classic Load Balancers) 드롭다운 목록에서 앞서 만든 로드 밸런서를 선택합니다.
Health Check Type에서 ELB를 선택합니다.
헬스 체크 Grace Period는 기본값인 300초로 둡니다. 스케일링 정책 설정을 선택합니다.
이 그룹에 대한 용량을 조정하기 위해 스케일링 정책 사용을 확인합니다.
이 그룹에 대해 CPU 사용률이 60%보다 크면 인스턴스가 추가되고, 45%보다 작으면 제거되는 방식으로 스케일을 조정합니다.

마지막으로, 변경 내용을 검토, 필요한 알림 및 태그를 구성하고 자동 확장 그룹을 생성합니다.

자동 확장 그룹이 생성되면 EC2 대시 보드에서 새로운 인스턴스가 시작됨을 볼 수 있습니다. 또한 이러한 새로운 인스턴스가 로드 밸런서에 추가됩니다. 인스턴스가 헬스 체크를 통과하면 로드 밸런서로부터 트래픽을 받을 준비가 됩니다.

자동 확장 그룹으로 인스턴스가 생성되었으므로 수동으로 만든 인스턴스를 종료합니다. 우리는 이 인스턴스가 사용자 정의 AMI를 만들기 위해서만 필요했습니다.

Prometheus를 사용한 헬스 체크 및 모니터링

Amazon의 Cloudwatch 이외에도 다양한 서비스에서 사용할 수 있는 외부 서비스인 GitLab은 Prometheus를 기반으로 한 통합 모니터링 솔루션을 제공합니다. 더 많은 정보는 GitLab Prometheus를 참조하세요.

GitLab은 또한 여러 헬스 체크 엔드포인트를 제공하며, 이를 사용하여 보고를 받을 수 있습니다.

GitLab Runner

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

AWS(Amazon Web Services)에서 GitLab Runner를 자동 확장하는 방법에 대해 자세히 알아보세요.

백업 및 복원

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

알아두어야 할 몇 가지 중요한 사항:

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

GitLab 백업

GitLab을 백업하려면:

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

GitLab 12.1 이전 버전의 경우 gitlab-rake gitlab:backup:create을 사용합니다.

백업에서 GitLab 복원하기

GitLab을 복원하려면 먼저 복원 문서 및 복원 전제조건을 확인하세요. 그런 다음 Linux 패키지 설치 섹션의 단계를 따르세요.

GitLab 업데이트

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

인스턴스에 SSH로 로그인합니다.
백업을 만듭니다:
```
sudo gitlab-backup create
```
참고: GitLab 12.1 및 이전 버전의 경우 gitlab-rake gitlab:backup:create를 사용하세요.
저장소를 업데이트하고 GitLab을 설치합니다:
```
sudo apt update
sudo apt install gitlab-ee
```

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

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

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

결론

이 가이드에서는 대부분 확장 및 일부 중복 옵션을 통해 진행했습니다. 결과는 개인에 따라 다를 수 있습니다.

비용/복잡성과 가동 시간 간의 균형이 있는 것을 염두에 두세요. 원하는 만큼 가동 시간이 중요하면, 솔루션이 더 복잡해집니다. 더 복잡한 솔루션일수록 설정 및 유지 관리에 필요한 작업이 더 많아집니다.

다음 리소스를 자세히 읽어보고 추가 자료를 요청하려면 언제든지 이슈를 열어주세요:

GitLab 확장: GitLab은 여러 유형의 클러스터링을 지원합니다.
Geo 복제: Geo는 널리 분산된 개발 팀을 위한 솔루션입니다.
Linux 패키지: GitLab 인스턴스를 관리하는 데 필요한 모든 정보를 담고 있습니다.
라이선스 추가: 라이선스로 GitLab 엔터프라이즈 에디션의 모든 기능을 활성화합니다.
가격 책정: 각 티어의 가격 책정을 확인하세요.

문제 해결

인스턴스의 상태 확인에 실패하는 경우

인스턴스가 로드 밸런서의 상태 확인에서 실패하는 경우, 이전에 구성한 상태 확인 엔드포인트에서 200 상태를 반환하는지 확인하세요. 상태 302와 같은 다른 상태는 상태 확인을 실패시킵니다.

root 사용자에 암호를 설정하여 상태 확인이 통과되기 전에 로그인 엔드포인트에서 자동 리디렉션이 발생하는 것을 방지해야 할 수도 있습니다.

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

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

일부 작업 로그가 객체 저장소에 업로드되지 않음

GitLab 배포가 하나 이상의 노드로 확장되면 일부 작업 로그가 객체 저장소에 올바르게 업로드되지 않을 수 있습니다. CI가 객체 저장소를 사용하려면 점진적 로깅이 필요합니다.

이미 활성화되어 있지 않으면 점진적 로깅을 활성화하세요.

Amazon Web Services(AWS)에 GitLab POC 설치

상업용 GitLab 시작하기

생산 용량 Linux 패키지 설치 시작하기

생산 용량 클라우드 네이티브 하이브리드 GitLab 시작하기

소개

요구 사항

아키텍처

AWS 비용

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

IAM 정책 생성

IAM 역할 생성

네트워크 구성

Virtual Private Cloud (VPC) 생성

서브넷

인터넷 게이트웨이

NAT 게이트웨이 생성

경로 테이블

공용 경로 테이블

프라이빗 라우트 테이블

로드 밸런서

로드 밸런서용 DNS 구성

RDS를 사용한 PostgreSQL

RDS 보안 그룹

RDS 서브넷 그룹

데이터베이스 생성

ElastiCache에서의 Redis

Redis 보안 그룹 생성

Redis 서브넷 그룹

Redis 클러스터 생성

베스천 호스트 설정

베스천 호스트 A 생성

Bastion Host B 만들기

SSH 에이전트 포워딩 사용하기

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

GitLab 설치

사용자 정의 구성 추가

Let’s Encrypt 비활성화

PostgreSQL에 필요한 확장 기능 설치

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

Gitaly 설정

Proxied SSL 지원 추가

허용된 SSH 키의 빠른 조회

호스트 키 구성

Amazon S3 객체 저장소

처음으로 로그인

사용자 지정 AMI 생성

auto scaling 그룹 안에서 GitLab 배포

시작 구성 만들기

자동 확장 그룹 만들기

Prometheus를 사용한 헬스 체크 및 모니터링

GitLab Runner

백업 및 복원

GitLab 백업

백업에서 GitLab 복원하기

GitLab 업데이트

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

결론

문제 해결

인스턴스의 상태 확인에 실패하는 경우

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

일부 작업 로그가 객체 저장소에 업로드되지 않음

도움말

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

도움받기