프로덕션급 GitLab 시작하기
- 프로덕션급 Linux 패키지 설치 시작하기
- 프로덕션급 Cloud Native Hybrid GitLab 시작하기
소개
요구 사항
아키텍처
AWS 비용
IAM EC2 인스턴스 역할 및 프로필 생성
- IAM 정책 생성
- IAM 역할 생성
네트워크 구성
- 가상 사설 클라우드(VPC) 생성
- 서브넷
- 인터넷 게이트웨이
- NAT 게이트웨이 생성
- 라우팅 테이블
  - 공용 라우팅 테이블
  - 개인 라우팅 테이블
로드 밸런서
- 로드 밸런서를 위한 DNS 구성
RDS(PostgreSQL) 구성
- RDS 보안 그룹
- RDS 서브넷 그룹
- 데이터베이스 생성
Redis with ElastiCache
- Redis 보안 그룹 생성
- Redis 서브넷 그룹
- Redis 클러스터 생성
배스천 호스트 설정
- 배스천 호스트 A 생성
  - 배스천 호스트 A에 탄력적 IP 할당
  - 인스턴스로 SSH 연결 확인
- 바스천 호스트 B 생성
- SSH 에이전트 포워딩 사용
GitLab 설치 및 사용자화 AMI 생성
- GitLab 설치
- 사용자화 구성 추가
- IP 허용 목록
- 프록시 프로토콜
- 처음으로 로그인
- 사용자 정의 AMI 생성
자동 스케일링 그룹 내에서 GitLab 배포
- 시작 템플릿 생성
- 자동 스케일링 그룹 생성
Prometheus를 사용한 건강 점검 및 모니터링
GitLab 러너
백업 및 복원
- GitLab 백업
- 백업에서 GitLab 복원
GitLab 업데이트
AWS에서 공식 GitLab 생성 AMI ID 찾기
결론
문제 해결
- 인스턴스에서 건강 점검이 실패하는 경우
- “요청한 변경 내용이 거부되었습니다 (422)”
- 일부 작업 로그가 객체 저장소에 업로드되지 않음

Amazon Web Services(AWS)에 GitLab POC 설치하기

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

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

1,000명 이하의 조직을 위한 권장 AWS 설치 방법은 EC2 단일 박스 Linux package installation을 시작하여 데이터를 백업하기 위한 스냅샷 전략을 구현하는 것입니다. 자세한 내용은 20 RPS or 1,000 user reference architecture를 참조하세요.

프로덕션급 GitLab 시작하기

이 문서는 개념 증명 인스턴스를 위한 설치 가이드로서 참조 아키텍처가 아니며 고가용성 구성으로 이어지지 않습니다. GitLab Environment Toolkit (GET)을 사용하는 것을 강력히 권장합니다.

이 가이드를 정확히 따르면, 개념 증명 인스턴스가 생성되며 이는 기본적으로 비 고가용성(Non-HA) 40 RPS or 2,000 User Reference Architecture의 scaled down 버전에 대응합니다. 2,000명 참조 아키텍처는 주로 비 고가용성이 아닙니다. 이는 비용과 복잡성을 낮추면서 일부 스케일링을 제공하기 위해 주로 의도되었습니다. 60 RPS or 3,000 User Reference Architecture은 GitLab HA가 되는 최소 사이즈입니다. HA를 달성하기 위한 추가 서비스 역할이 있으며 특히 HA를 위해 Gitaly Cluster를 사용하여 Git 저장소 저장에 HA를 달성하고 트리플 리던던시를 지정합니다.

GitLab은 두 가지 주요 참조 아키텍처를 유지 및 테스트합니다. Linux 패키지 아키텍처는 인스턴스 컴퓨팅에 구현되며 Cloud Native Hybrid 아키텍처는 Kubernetes 클러스터의 사용을 최대화합니다. Cloud Native Hybrid 참조 아키텍처 사양은 Linux 패키지 아키텍처를 먼저 설명하는 참조 아키텍처 크기 페이지의 부록 섹션입니다. 예를 들어, 60 RPS or 3,000 User Cloud Native Reference Architecture는 60 RPS or 3,000 User Reference Architecture 페이지의 하위 섹션인 Cloud Native Hybrid reference architecture with Helm Charts (alternative)입니다.

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

인프라스트럭처를 코드로 구축하는 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에 사용합니다.

AWS에서 Cloud Native Hybrid 환경을 배포하려면 GitLab Environment Toolkit을 사용할 수 있지만 필수는 아니며 모든 유효한 순열을 지원하지 않을 수 있습니다. 그럼에도 불구하고 스크립트는 있는 그대로 제공되며 사용자는 그에 맞게 수정할 수 있습니다.

소개

우리의 설정에서는 주로 Linux 패키지를 사용하지만 네이티브 AWS 서비스도 활용합니다. Linux 패키지에 번들된 PostgreSQL과 Redis를 사용하는 대신 Amazon RDS와 ElastiCache를 사용합니다.

이 안내서에서는 VPC 및 서브넷을 구성하여 나중에 데이터베이스 서버로 RDS 및 Redis 클러스터로 ElastiCache와 같은 서비스를 통합하여 마지막으로 사용자 정의 스케일링 정책으로 자동 확장 그룹에서 관리하는 멀티 노드 설정을 진행합니다.

요구 사항

AWS 및 Amazon EC2에 대한 기본적인 이해를 가지고 있어야 하며 다음이 필요합니다.

AWS 계정
SSH 키를 생성하거나 업로드하여 인스턴스에 SSH로 연결합니다.(연결 및 사용자 인증 > SSH 키 쌍 생성)
GitLab 인스턴스의 도메인 이름
도메인을 보호하기 위한 SSL/TLS 인증서. 이미 소유하고 있지 않은 경우, AWS Certificate Manager(ACM)를 통해 무료 공개 SSL/TLS 인증서를 제공받을 수 있습니다. 이 인증서는 나중에 생성을 위해 가능한 빨리 요청하시는 것이 좋습니다.

ACM을 통해 제공받은 인증서를 확인하는 데 몇 시간이 걸릴 수 있습니다. 나중에 지연을 피하려면 가능한 한 빨리 인증서를 요청하십시오.

아키텍처

다음은 권장 아키텍처의 다이어그램입니다.

AWS 비용

GitLab은 다음과 같은 AWS 서비스를 사용하며, 가격정보에 대한 링크가 제공됩니다.

EC2: GitLab은 공유 하드웨어에 배포되며, 온디맨드 가격이 적용됩니다. 별도의 또는 예약된 인스턴스에서 GitLab을 실행하려면, 해당 비용에 대한 정보는 EC2 가격 페이지에서 확인할 수 있습니다.
S3: GitLab은 백업, artifact 및 LFS 객체를 저장하기 위해 S3(가격 페이지)를 사용합니다.
NLB: GitLab 인스턴스로의 요청을 라우팅하기 위해 사용되는 네트워크 로드 밸러서(가격 페이지)입니다.
RDS: PostgreSQL을 사용하는 Amazon Relational Database Service (가격 페이지)입니다.
ElastiCache: Redis 구성을 제공하기 위해 사용되는 인메모리 캐시 환경(가격 페이지)입니다.

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

우리는 Amazon S3 객체 저장소를 사용하기 때문에, EC2 인스턴스는 S3 버킷에 대한 읽기, 쓰기 및 목록 권한을 갖추어야 합니다. AWS 키를 GitLab 구성에 포함하지 않고도, IAM Role을 사용하여 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-*"
        }
    ]
}

정책 검토를 위해 다음을 선택합니다. 정책에 이름을 지정합니다(여기서는 gl-s3-policy 사용)하고 정책 생성(Create policy)을 선택합니다.

IAM 역할 생성

여전히 IAM 대시보드에 있으면, 왼쪽 메뉴에서 역할(Roles)을 선택하고 역할 생성(Create role)을 선택합니다.
신뢰하는 실체 유형(Trusted entity type)으로 AWS service, 사용 사례(Use case)로 각각 드롭다운 목록 및 라디오 버튼에서 EC2를 선택하고 다음을 선택합니다.
정책 필터에서 위에서 만든 gl-s3-policy를 검색하고 선택한 후 다음을 선택합니다.
역할에 이름을 지정합니다(여기서는 GitLabS3Access 사용)하고 필요한 경우 일부 태그를 추가합니다. 역할 생성(Create role)을 선택합니다.

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

네트워크 구성

GitLab 클라우드 인프라를 위한 VPC를 만든 후, 적어도 두 개의 가용 영역(AZ)에 공용 및 사설 인스턴스를 갖기 위해 서브넷을 생성합니다. 공용 서브넷에는 라우팅 테이블이 필요하며 연결된 인터넷 게이트웨이가 필요합니다.

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

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

Amazon Web Services에 로그인합니다.
왼쪽 메뉴에서 Your VPCs를 선택한 후 VPC 생성(Create VPC)을 선택합니다. “Name tag”에 gitlab-vpc를 입력하고 “IPv4 CIDR 블록”에 10.0.0.0/16을 입력합니다. 전용 하드웨어가 필요하지 않은 경우에는 기본 설정으로 둘 수 있습니다. 준비되면 VPC 생성(Create VPC)을 선택합니다.
VPC를 선택하고 작업(Actions)을 선택한 후 VPC 설정 편집(Edit VPC Settings)을 선택하고 DNS 해결 기능 사용(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`

모든 서브넷이 생성되면 두 공용 서브넷에 대해 IPv4 자동 할당을 활성화합니다:
1. 각 공용 서브넷을 차례로 선택하고 작업(Actions)을 선택한 후 서브넷 설정 편집(Edit subnet settings)을 선택합니다. 퍼블릭 IPv4 주소 자동 할당 활성화(Enable auto-assign public IPv4 address) 옵션을 선택하고 저장합니다.

인터넷 게이트웨이

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

왼쪽 메뉴에서 인터넷 게이트웨이(Internet Gateways)를 선택합니다.
인터넷 게이트웨이 생성(Create internet gateway)를 선택하고 gitlab-gateway라는 이름을 지정하고 생성(Create)을 선택합니다.
테이블에서 선택한 후 작업(Actions) 드롭다운 목록에서 “VPC에 연결(Attach to VPC)”을 선택합니다.
목록에서 gitlab-vpc를 선택하고 연결(Attach)을 선택합니다.

NAT 게이트웨이 생성

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

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

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

라우팅 테이블

공용 라우팅 테이블

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

VPC 대시보드에서:

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

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

왼쪽 메뉴에서 라우팅 테이블을 선택하고 gitlab-public 라우트를 선택하여 하단에 나타나는 옵션을 표시합니다.
경로 탭을 선택한 다음 경로 편집 > 경로 추가를 선택하고 대상을 인터넷 게이트웨이로 설정한 후 이전에 생성한 gitlab-gateway를 선택하십시오. 완료되면 변경 사항 저장을 선택합니다.

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

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

개인 라우팅 테이블

각 개인 서브넷의 인스턴스가 해당 가용 영역의 해당 공용 서브넷에있는 NAT 게이트웨이를 통해 인터넷에 액세스할 수 있도록 하기 위해 두 개의 개인 라우팅 테이블을 생성해야 합니다.

위와 같은 단계를 따라 두 개인 라우팅 테이블을 생성합니다. gitlab-private-a 및 gitlab-private-b로 이름을 지정합니다.
다음으로 각 개인 라우팅 테이블에 새 경로를 추가해야 합니다. 여기서 대상은 앞서 생성한 NAT 게이트웨이 중 하나여야 합니다.
1. gitlab-public-10.0.0.0에서 생성한 NAT 게이트웨이를 gitlab-private-a 라우팅 테이블의 새 경로 대상으로 추가합니다.
2. 마찬가지로, gitlab-public-10.0.2.0의 NAT 게이트웨이를 gitlab-private-b의 새 경로 대상으로 추가합니다.
마지막으로 각 개인 서브넷을 해당 개인 라우팅 테이블에 연결해야 합니다.
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를 처리하기 위한 다양한 방법이 있지만, 본 시제품을 위해 로드 밸런서에서 SSL을 종료시킵니다.

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

로드 밸런서 생성을 선택합니다.
네트워크 로드 밸런서를 선택하고 생성을 선택합니다.
로드 밸런서 이름을 gitlab-loadbalancer로 설정합니다. 다음 추가 옵션을 설정합니다:
- 스키마: 인터넷 통신 가능
- IP 주소 유형: IPv4
- VPC: 드롭다운 목록에서 gitlab-vpc를 선택합니다.
- 매핑: 로드 밸런서가 양쪽 가용 영역으로 트래픽을 라우팅할 수 있도록 목록에서 공용 서브넷을 선택합니다.
로드 밸런서에 트래픽을 제어하기 위해 보안 그룹을 추가합니다. 보안 그룹 섹션에서 새 보안 그룹 생성을 선택하고 이름을 지정한 후(HTTP 및 HTTPS 트래픽 허용)에서 어디에서든(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
1. 포트 443의 TLS 리스너의 보안 정책 설정에서:
  1. 정책 이름: 드롭다운 목록에서 사전 정의된 보안 정책을 선택합니다. AWS 문서에서 네트워크 로드 밸런서용 사전 정의 SSL 보안 정책 목록을 확인할 수 있습니다. 지원되는 SSL 암호 및 프로토콜을 확인하려면 GitLab 코드베이스를 참조하십시오.
  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 Allowlist에 VPC IP 주소 범위 (CIDR)를 추가해야 합니다. Health check endpoints을 사용할 수 있는 IP주소 범위(CIDR)를 추가해야합니다
6. gitlab-loadbalancer-ssh-target의 상태 확인에는 TCP를 선택합니다.
  - gitlab-loadbalancer-http-target을 포트 80 및 443 리스너에 모두 할당합니다.
  - gitlab-loadbalancer-ssh-target을 포트 22 리스너에 할당합니다.
7. 대상 그룹을 생성한 후 일부 속성은 이미 생성된 후에만 구성할 수 있습니다. 요구 사항에 따라 구성해야 하는 몇 가지 기능이 있습니다.
  - 클라이언트 IP 보존은 기본적으로 대상 그룹용으로 활성화됩니다. 이를 통해 로드 밸런서에 연결된 클라이언트의 IP가 GitLab 애플리케이션에서 보존됩니다. 이를 요구 사항에 따라 설정할 수 있습니다.
  - 프록시 프로토콜은 기본적으로 대상 그룹용으로 비활성화되어 있습니다. 이를 통해 로드 밸런서가 프록시 프로토콜 헤더에 추가 정보를 보낼 수 있습니다. 이를 사용하려면 내부 로드 밸런서, NGINX 등과 같은 다른 환경 구성이 필요합니다. 본 시제품에서는 GitLab 노드에서만 활성화하면 됩니다.
로드 밸런서 생성을 선택합니다.

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

로드 밸런서가 작동하기 시작하면, NLB를 통한 액세스 및 기타 요구 사항을 정확하게 다시 검토할 수 있습니다.

로드 밸런서를 위한 DNS 구성

Route 53 대시보드에서 왼쪽 탐색 창에서 호스팅된 영역(Hosted zones)을 선택합니다.

기존의 호스팅된 영역을 선택하거나, 도메인을 위해 아직 영역을 보유하고 있지 않다면 호스팅 영역 생성(Create Hosted Zone)을 선택하고 도메인 이름을 입력한 후 만들기(Select Create)를 선택합니다.
레코드 생성(Create record)을 선택하고 다음 값들을 제공합니다:
1. 이름(Name): 도메인 이름(기본 값) 또는 하위 도메인을 입력합니다.
2. 유형(Type): A - IPv4 주소를 선택합니다.
3. 별칭(Alias): 기본값은 비활성화입니다. 이 옵션을 활성화합니다.
4. 통행량 경로 설정(Route traffic to): 네트워크 로드 밸런서에 별칭(Alias to Network Load Balancer)를 선택합니다.
5. 지역(Region): 네트워크 로드 밸런서가 있는 지역을 선택합니다.
6. 네트워크 로드 밸런서 선택: 이전에 생성한 네트워크 로드 밸런서를 선택합니다.
7. 라우팅 정책(Routing Policy): Simple을 사용하지만 사용 사례에 따라 다른 정책을 선택할 수 있습니다.
8. 대상 상태 평가(Evaluate Target Health): 이 값을 No로 설정하지만, 대상 상태에 따라 트래픽을 라우팅할 수 있도록 로드 밸런서를 선택할 수 있습니다.
9. 만들기(Create)를 선택합니다.
도메인을 Route 53을 통해 등록했다면 작업이 완료됩니다. 다른 도메인 등록기를 사용했다면 도메인 등록기의 DNS 레코드를 업데이트해야 합니다. 다음 단계를 수행해야 합니다:
1. 호스팅된 영역(Hosted zones)을 선택한 후 위에서 추가한 도메인을 선택합니다.
2. NS 레코드 목록이 표시됩니다. 도메인 등록기의 관리자 패널에서 이러한 각각을 도메인의 DNS 레코드로 추가해야 합니다. 이러한 단계는 도메인 등록기마다 다를 수 있습니다. 도움이 필요하다면 구글에 “등록기명” DNS 레코드 추가를 검색하여 해당 도메인 등록기에 특화된 도움 문서를 찾을 수 있습니다.

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

RDS(PostgreSQL) 구성

데이터베이스 서버로는 Amazon RDS를 사용하여 PostgreSQL을 사용하며, 여기에는 가용성을 위해 Multi 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): “사용자 정의”로 설정합니다.
3. 출처(Source): 이전에 생성한 gitlab-loadbalancer-sec-group을 선택합니다.
완료되면 보안 그룹 생성(Create security group)을 선택합니다.

RDS 서브넷 그룹

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

데이터베이스 생성

경고: 오랜 기간에 걸쳐 고부하 상황이 지속될 때 CPU 크레딧이 고갈되어 성능 문제가 발생할 수 있으므로 데이터베이스에 burstable 인스턴스(t class 인스턴스)를 사용하는 것을 피하세요.

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

RDS 대시보드로 이동하고 왼쪽 메뉴에서 데이터베이스(Databases)를 선택한 후 데이터베이스 생성(Create database)를 선택합니다.
데이터베이스 생성 방법으로 표준 생성(Standard Create)을 선택합니다.
데이터베이스 엔진으로 PostgreSQL을 선택하고 database requirements에서 GitLab 버전에 정의된 최소 PostgreSQL 버전을 선택합니다.
이는 프로덕션 서버이므로 템플릿 섹션에서 Production을 선택합니다.
가용성 및 내구성(Availability & durability)에서 가용성 존(Availability Zone)에서 다른 예비 RDS 인스턴스가 프로비저닝되도록 Multi-AZ DB 인스턴스(Multi-AZ DB instance)를 선택합니다.
설정(Settings)에서:
- DB 인스턴스 식별자로 gitlab-db-ha를 사용합니다.
- 마스터 사용자 이름으로 gitlab을 사용합니다.
- 마스터 암호로 매우 안전한 암호를 사용합니다.
나중에 필요하기 때문에 이러한 사항을 메모해 둡니다.
DB 인스턴스 크기로 표준 클래스(Standard classes)를 선택하고 드롭다운 목록에서 요구 사항에 맞는 인스턴스 크기를 선택합니다. 여기서는 db.m5.large 인스턴스를 사용합니다.
저장소(Storage)에서 다음을 구성합니다:
1. 저장 유형 드롭다운 목록에서 Provisioned IOPS (SSD)를 선택합니다. Provisioned IOPS(SSD) 스토리지가 가장 적합합니다(비용을 줄이기 위해 일반 용도(SSD)를 선택할 수도 있습니다). 자세한 내용은 Amazon RDS용 스토리지를 참조하세요.
2. 저장소를 할당하고 프로비저닝된 IOPS를 설정합니다. 여기서는 각각 100 및 1000의 최소값을 사용합니다.
3. 저장소 자동 스케일링을 활성화하고 최대 저장소 한계를 설정합니다(선택 사항).
연결성(Connectivity)에서 다음을 구성합니다:
1. 가상 사설 클라우드(Virtual Private Cloud, VPC) 드롭다운 목록에서 이전에 생성한 VPC(gitlab-vpc)를 선택합니다.
2. DB 서브넷 그룹(DB subnet group)에서 이전에 생성한 서브넷 그룹(gitlab-rds-group)을 선택합니다.
3. 공개 액세스를 No로 설정합니다.
4. VPC 보안 그룹(VPC security group)에서 기존 선택(Choose existing)을 선택하고 드롭다운 목록에서 위에서 생성한 gitlab-rds-sec-group을 선택합니다.
5. 추가 구성(Additional configuration)에서 기본값인 데이터베이스 포트인 5432를 유지합니다.
데이터베이스 인증(Database authentication)으로 가서 암호 인증(Password authentication)을 선택합니다.
추가 구성(Additional configuration) 섹션을 확장하고 다음을 완료합니다:
1. 초기 데이터베이스 이름을 설정합니다. 여기서는 gitlabhq_production을 사용합니다.
2. 선호하는 백업 설정을 구성합니다.
3. 여기서 만든 것 이외의 변경 사항은 유지하기 위해 자동으로 검정입니다.
4. 다른 모든 설정은 변경하지 않거나 필요에 따라 조정합니다.
5. 준비되었다면 데이터베이스 생성(Create database)을 선택합니다.

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

Redis with 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 클라우드를 선택하고 Multi-AZ 옵션을 활성화합니다.
클러스터 설정 섹션에서:
1. 엔진 버전은 GitLab 버전에 정의된 Redis 버전을 선택합니다(Redis 요구 사항 참조).
2. 포트는 상단에서 Redis 보안 그룹에서 사용한 것과 동일한 6379로 남깁니다.
3. 노드 유형을 선택합니다(적어도 cache.t3.medium 이상이며 필요에 맞게 조정) 및 복제본 수를 선택합니다.
연결 설정 섹션에서:
1. 네트워크 유형: IPv4
2. 서브넷 그룹: 기존 서브넷 그룹 선택을 선택하고 이전에 생성한 gitlab-redis-group을 선택합니다.
가용 영역 배치 섹션에서:
1. 원하는 사용 가능한 영역을 수동으로 선택하고 “복제본 2”에서 다른 영역을 선택합니다.
다음을 선택합니다.
보안 설정에서 보안 그룹을 편집하고 이전에 만든 gitlab-redis-sec-group을 선택합니다. 다음을 선택합니다.
나머지 설정은 기본값으로 남기거나 원하는 대로 편집합니다.
완료되면 생성을 선택합니다.

배스천 호스트 설정

GitLab 인스턴스가 비공개 서브넷에 있으므로 구성 변경 및 업그레이드와 같은 작업을 수행하기 위해 이러한 인스턴스에 SSH로 연결해야 합니다. 이를 위한 하나의 방법은 배스천 호스트를 사용하는 것입니다. 때로는 점프 박스로도 지칭됩니다.

참고: 배스천 호스트를 유지하고 싶지 않다면 AWS Systems Manager 세션 매니저를 인스턴스 액세스에 사용할 수 있습니다. 이는 이 문서의 범위를 벗어납니다.

배스천 호스트 A 생성

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

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

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

인스턴스로 SSH 연결 확인

EC2 대시보드에서 왼쪽 메뉴에서 인스턴스를 선택합니다.
인스턴스 목록에서 Bastion Host A를 선택합니다.
연결을 선택하고 연결 지침에 따릅니다.
성공적으로 연결되면, 이제 중복성을 위해 두 번째 바스천 호스트 설정으로 넘어갑니다.

바스천 호스트 B 생성

다음 변경 사항과 함께 앞에서와 동일한 단계로 EC2 인스턴스를 생성합니다:
1. 서브넷에서 앞서 생성한 두 번째 퍼블릭 서브넷(gitlab-public-10.0.2.0)을 선택합니다.
2. 태그 추가 섹션에서 키: 이름 및 값: Bastion Host B를 설정하여 두 인스턴스를 쉽게 식별할 수 있도록 합니다.
3. 보안 그룹에서 앞에서 생성한 bastion-sec-group을(를) 선택합니다.

SSH 에이전트 포워딩 사용

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

바스천 호스트에 개인 키 파일을 저장하는 것은 좋지 않은 생각입니다. 이를 해결하기 위해 클라이언트에서 SSH 에이전트 포워딩을 사용합니다.

예를 들어 명령줄 ssh 클라이언트는 다음과 같이 -A 옵션과 사용하여 에이전트 포워딩을 사용합니다.

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

기타 클라이언트에서 SSH 에이전트 포워딩 사용 방법에 대한 단계별 가이드는 AWS에서 실행되는 비공개 Amazon VPC에 안전하게 연결를 참조하세요.

GitLab 설치 및 사용자화 AMI 생성

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

GitLab 설치

EC2 대시보드에서 다음 섹션을 사용하여 올바른 AMI를 찾고 프로젝트에서 시작을 선택합니다.

이름 및 태그 섹션에서 이름을 GitLab로 설정합니다.
인스턴스 유형 드롭다운 목록에서 작업 부하에 기초하여 인스턴스 유형을 선택합니다. 사용 요구사항을 확인하여 필요한 유형을 선택하세요(최소 100명의 사용자를 수용할 수 있는 c5.2xlarge 이상).
키페어 섹션에서 새 키페어 생성을 선택합니다.
1. 키페어 이름을 지정(여기에서 gitlab을 사용)하고 나중에 사용할 gitlab.pem 파일을 저장합니다.
네트워크 설정 섹션:
1. VPC: 앞서 생성한 gitlab-vpc를 선택합니다.
2. 서브넷: 앞서 생성한 서브넷 목록에서 gitlab-private-10.0.1.0을 선택합니다.
3. 자동 할당된 공인 IP: 비활성화를 선택합니다.
4. 방화벽: 기존 보안 그룹 선택을 선택하고 앞서 생성한 gitlab-loadbalancer-sec-group을(를) 선택합니다.
저장소의 경우 기본적으로 루트 볼륨은 8 GiB이며 거기에 데이터를 저장하지 않기 때문에 충분합니다.
모든 설정을 검토하고, 만족하면 인스턴스 시작을 선택합니다.

사용자화 구성 추가

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에 필요한 확장 기능 설치

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

호스트 또는 엔드포인트를 찾으려면 Amazon RDS > 데이터베이스로 이동하여 앞에서 만든 데이터베이스를 선택합니다. 연결 및 보안 탭에서 엔드포인트를 확인하세요.

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

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://<도메인>' 옵션을 찾아 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>"

마지막으로 변경 사항이 적용되도록 GitLab을 다시 구성합니다:
```
sudo gitlab-ctl reconfigure
```
모든 것이 올바르게 설정되었는지 확인하고 서비스 상태를 확인하는 것이 좋습니다:
```
sudo gitlab-rake gitlab:check
sudo gitlab-ctl status
```

Gitaly 설정

경고: 이 아키텍처에서는 단일 Gitaly 서버를 보유하면 단일 장애 지점이 생성됩니다. 이 제한을 제거하려면 Gitaly 클러스터를 사용하세요.

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

Gitaly를 설치하는 EC2 인스턴스를 생성해 봅시다:

EC2 대시보드에서 인스턴스 시작을 선택합니다.
이름 및 태그 섹션에서 이름을 Gitaly로 설정합니다.
AMI를 선택합니다. 이 예에서는 최신 Ubuntu Server LTS (HVM), SSD 볼륨 유형을 선택합니다. 지원되는 최신 OS 버전을 확인하려면 GitLab 문서를 확인하세요.
인스턴스 유형을 선택합니다. m5.xlarge를 선택합니다.
키 페어 섹션에서 새 키 페어 생성을 선택합니다.
1. 키 페어에 이름을 지정하고(gitaly를 사용함) 나중에 사용할 gitaly.pem 파일을 저장합니다.
네트워크 설정 섹션에서:
1. VPC에서 드롭다운 목록에서 gitlab-vpc를 선택합니다.
2. 서브넷에서 이전에 생성한 사설 서브넷(gitlab-private-10.0.1.0)을 선택합니다.
3. Auto-assign Public IP 아래 비활성화가 선택되어 있는지 확인합니다.
4. 방화벽에서 보안 그룹 생성을 선택하고 보안 그룹 이름을 입력한 후 설명을 추가합니다.
  1. 사용자 지정 TCP 규칙을 만들어 포트 범위에 8075 포트를 추가합니다. 소스로 gitlab-loadbalancer-sec-group을 선택합니다.
  2. 또한 bastion-sec-group에서 SSH를 위한 인바운드 규칙을 추가하여 SSH 에이전트 포워딩을 통해 연결할 수 있도록 합니다.
Root 볼륨 크기를 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 요금을 확인하고 EFS의 사용은 GitLab의 성능에 부정적인 영향을 줄 수 있기 때문에 권장하지 않습니다. 자세한 내용은 관련 문서에서 확인할 수 있습니다.

이제 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 작업을 수행할 수 있도록 공유 스토리지를 사용합니다. 그러나 이번 설정에서는 공유 스토리지가 없으므로 SSH 사용자를 GitLab 데이터베이스에서 인덱스 조회를 통해 인증하도록 구성을 업데이트합니다.

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/의 내용(기본 및 공용 키)을 불러오기하여 클러스터 내 레이드 밸런서 뒤에 있는 서버에 액세스할 때 잘못된 중간자 공격 경고를 방지합니다.

우리는 커스텀 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과 함께 객체 저장소를 사용하는 데 필요한 다른 정보가 포함되어 있습니다.

::NOTE:: 우리가 이전에 생성한 AWS IAM 프로필을 사용하기 때문에, 객체 저장소를 구성할 때 AWS 액세스 키와 시크릿 액세스 키/값 쌍을 생략해야 합니다. 대신, 상기에 연결된 객체 저장소 문서에 나와 있는대로 구성에서 'use_iam_profile' => true를 사용하세요.

변경 내용을 저장한 후에 sudo gitlab-ctl reconfigure를 실행하는 것을 잊지 마십시오.

GitLab 인스턴스의 구성 변경이 이로써 완료되었습니다. 다음으로, 이 인스턴스를 기반으로 사용할 사용자 정의 AMI를 만들어, 시작 구성 및 자동 스케일링 그룹에 사용합니다.

IP 허용 목록

이전에 만든 gitlab-vpc의 VPC IP 주소 범위 (CIDR)를 IP 허용 목록에 추가해야 합니다. 또한, Health check endpoints에 대한 설정도 동일합니다.

/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/32"]

GitLab을 다시 구성합니다:
```
sudo gitlab-ctl reconfigure
```

처음으로 로그인

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

GitLab을 설치하는 방법 및 다른 수단으로 비밀번호를 변경하지 않은 경우, 기본 비밀번호는 다음 중 하나입니다:

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

기본 비밀번호를 변경하려면, 기본 비밀번호로 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 대시보드에서:

왼쪽 메뉴에서 자동 스케일링 그룹을 선택하고 자동 스케일링 그룹 생성을 선택합니다.
그룹 이름을 입력합니다 (우리는 gitlab-auto-scaling-group을 사용합니다).
시작 템플릿에서 이전에 만든 시작 템플릿을 선택하고 다음을 선택합니다.
네트워크 설정 섹션에서:
1. VPC 아래에서 드롭다운 목록에서 gitlab-vpc를 선택합니다.
2. 가용 영역 및 서브넷 아래에서, 이전에 생성한 개인 서브넷(gitlab-private-10.0.1.0 및 gitlab-private-10.0.3.0)을 선택합니다.
3. 다음을 선택합니다.
로드 밸런싱 설정 섹션에서:
1. 기존 로드 밸런서에 연결을 선택합니다.
2. 기존 로드 밸런서 대상 그룹 드롭다운 목록에서 이전에 생성한 대상 그룹을 선택합니다.
3. Health Check Type에 대한 Turn on Elastic Load Balancing health checks 옵션을 선택합니다. Health Check Grace Period를 기본값 300초로 둡니다.
4. 다음을 선택합니다.
그룹 크기에서 Desired capacity를 2로 설정합니다.
스케일링 설정 섹션에서:
1. 스케일링 정책 없음을 선택합니다. 정책은 나중에 구성됩니다.
2. 최소 필요 용량: 2로 설정합니다.
3. 최대 필요 용량: 4로 설정합니다.
4. 다음을 선택합니다.
마지막으로, 설정한대로 알림 및 태그를 구성하고 변경 내용을 검토한 후 자동 스케일링 그룹을 생성합니다.
자동 스케일링 그룹이 만들어지면, Cloudwatch에서 스케일 업 및 다운 정책을 만들고 할당해야 합니다.
1. 이전에 만든 By Auto Scaling Group에서 인스턴스 EC2의 CPUUtilization 메트릭을 사용하여 CPUUtilization에 대한 알람을 만듭니다.
2. 다음 조건을 사용하여 scale up policy를 만듭니다:
  1. CPUUtilization이 60% 이상일 때 1 용량 단위를 추가합니다.
  2. Scaling policy name을 Scale Up Policy로 설정합니다.
1. 다음 조건을 사용하여 scale down policy를 만듭니다:
  1. CPUUtilization이 45% 이하일 때 1 용량 단위를 제거합니다.
  2. Scaling policy name을 Scale Down Policy로 설정합니다.
1. 새로운 동적 스케일링 정책을 이전에 생성한 자동 스케일링 그룹에 할당합니다.

자동 스케일링 그룹을 생성하면, EC2 대시보드에서 새로운 인스턴스가 돌아가는 것을 확인할 수 있습니다. 또한, 새로운 인스턴스가 로드 밸런서에 추가되는 것도 확인할 수 있습니다. 인스턴스가 헬스 체크를 통과하면 로드 밸런서로부터 트래픽을 수신할 준비가 되어 있습니다.

자동 스케일링 그룹에 의해 인스턴스가 만들어지면, 수동으로 만든 인스턴스를 종료해야 합니다. 우리는 이 인스턴스를 사용자 정의 AMI를 만들 때만 필요했습니다.

Prometheus를 사용한 건강 점검 및 모니터링

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

또한 GitLab은 여러 건강 점검 엔드포인트를 제공하며, 이를 핑(ping)하여 보고서를 받을 수 있습니다.

GitLab 러너

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

AWS에서 자동 스케일링 GitLab 러너를 구성하는 방법에 대해 더 알아보세요.

백업 및 복원

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

중요한 사항 몇 가지:

백업/복원 도구는 비밀 정보와 같은 일부 구성 파일을 저장하지 않으며, 이러한 경우에는 직접 구성해야 합니다.
기본적으로 백업 파일은 로컬에 저장되지만, Amazon 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은 여러 유형의 클러스터링을 지원합니다.
지오 복제: 지오는 널리 분산된 개발 팀을 위한 솔루션입니다.
Linux 패키지: GitLab 인스턴스를 관리하는 데 필요한 모든 정보.
라이선스 추가: 라이선스로 GitLab Enterprise Edition의 모든 기능 활성화.
가격 책정: 각 계층의 가격.

문제 해결

인스턴스에서 건강 점검이 실패하는 경우

인스턴스에서 로드 밸런서의 건강 점검에 실패하는 경우, 이전에 구성한 건강 점검 엔드포인트에서 상태 200을 반환하는지 확인하십시오. 상태 302와 같은 리디렉션을 포함한 다른 상태는 건강 점검을 실패시킵니다.

건강 점검이 통과되기 전에 로그인 엔드포인트에서 자동 리디렉트를 방지하려면 root 사용자에게 비밀번호를 설정해야 할 수 있습니다.

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

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

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

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

이미 증분 로깅이 활성화되어 있지 않은 경우 증분 로깅을 활성화합니다.

Amazon Web Services(AWS)에 GitLab POC 설치하기

프로덕션급 GitLab 시작하기

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

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

소개

요구 사항

아키텍처

AWS 비용

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

IAM 정책 생성

IAM 역할 생성

네트워크 구성

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

서브넷

인터넷 게이트웨이

NAT 게이트웨이 생성

라우팅 테이블

공용 라우팅 테이블

개인 라우팅 테이블

로드 밸런서

로드 밸런서를 위한 DNS 구성

RDS(PostgreSQL) 구성

RDS 보안 그룹

RDS 서브넷 그룹

데이터베이스 생성

Redis with ElastiCache

Redis 보안 그룹 생성

Redis 서브넷 그룹

Redis 클러스터 생성

배스천 호스트 설정

배스천 호스트 A 생성

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

인스턴스로 SSH 연결 확인

바스천 호스트 B 생성

SSH 에이전트 포워딩 사용

GitLab 설치 및 사용자화 AMI 생성

GitLab 설치

사용자화 구성 추가

Let’s Encrypt 비활성화

PostgreSQL에 필요한 확장 기능 설치

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

Gitaly 설정

프록시된 SSL 지원 추가

인증된 SSH 키의 빠른 조회 설정

호스트 키 구성

Amazon S3 객체 저장소

IP 허용 목록

프록시 프로토콜

처음으로 로그인

사용자 정의 AMI 생성

자동 스케일링 그룹 내에서 GitLab 배포

시작 템플릿 생성

자동 스케일링 그룹 생성

Prometheus를 사용한 건강 점검 및 모니터링

GitLab 러너

백업 및 복원

GitLab 백업

백업에서 GitLab 복원

GitLab 업데이트

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

결론

문제 해결

인스턴스에서 건강 점검이 실패하는 경우

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

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

도움말

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

도움받기