프로덕션 수준의 GitLab 시작하기
- 프로덕션 수준의 Linux 패키지 설치 시작
- 프로덕션 수준의 Cloud Native Hybrid GitLab 시작하기
소개
요구 사항
아키텍처
AWS 비용
IAM EC2 인스턴스 역할 및 프로필 생성
- IAM 정책 생성
- IAM 역할 생성
네트워크 구성
- 가상 사설 클라우드(VPC) 생성
- 서브넷
- 인터넷 게이트웨이
- NAT 게이트웨이 생성
- 라우팅 테이블
  - 공용 라우팅 테이블
  - 사설 라우팅 테이블
로드 밸런서
- 로드 밸런서의 DNS 구성
PostgreSQL with RDS
- RDS 보안 그룹
- RDS 서브넷 그룹
- 데이터베이스 생성
ElastiCache의 Redis
- Redis 보안 그룹 생성
- Redis 서브넷 그룹
- Redis 클러스터 생성
버스테이션 호스트 설정
- 버스테이션 호스트 A 생성
  - 버스테이션 호스트 A에 Elastic IP 할당
  - 인스턴스에 SSH로 연결할 수 있는지 확인
- 버스테이션 호스트 B 생성
- SSH 에이전트 포워딩 사용
GitLab 설치 및 사용자 AMI 생성
- GitLab 설치
- 사용자 정의 구성 추가
- IP 허용 디렉터리
- 프록시 프로토콜
- 처음 로그인
- 사용자 정의 AMI 생성
자동 확장 그룹 내에서 GitLab 배포
- 시작 템플릿 생성
- 자동 확장 그룹 생성
프로메테우스를 사용한 상태 체크 및 모니터링
GitLab 러너
백업 및 복원
- GitLab 백업
- 백업에서 GitLab 복원
GitLab 업데이트
공식 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 패키지 설치를 시작하고 있습니다. 자세한 정보는 20 RPS 또는 1,000 사용자 참조 아키텍처를 참조하세요.

프로덕션 수준의 GitLab 시작하기

이 문서는 컨셉 프로포즈 인스턴스에 대한 설치 가이드이며 참조 아키텍처가 아니며 고가용성 구성으로 이어지지 않습니다. GitLab Environment Toolkit (GET)을 사용하는 것이 강력하게 권장됩니다.

이 가이드를 정확하게 따를 경우 컨셉 프로포즈 인스턴스가 생성되며, 이는 비 고가용성 40 RPS 또는 2,000 사용자 참조 아키텍처의 스케일 다운 버전에 대략적으로 동등합니다. 2K 참조 아키텍처는 주로 비용과 복잡성을 낮추면서 일부 스케일링을 제공하기 위해 고가용성이 아닙니다. 60 RPS 또는 3,000 사용자 참조 아키텍처는 GitLab HA가 되는 가장 작은 크기입니다. Addiyional 서비스 역할을 통해 HA를 달성하기 위해 주로 Gitaly Cluster를 사용하여 Git 리포지터리 저장 공간의 HA를 달성하고 세 번의 중복성을 지정합니다.

GitLab은 주로 두 가지 유형의 참조 아키텍처를 유지 및 테스트합니다. Linux 패키지 아키텍처는 인스턴스 컴퓨트에 구현되며 Cloud Native Hybrid 아키텍처는 Kubernetes 클러스터의 사용을 최대화합니다. Cloud Native Hybrid 참조 아키텍처 사양은 Linux 패키지 아키텍처를 설명하는 참조 아키텍처 크기 페이지의 부록 섹션입니다. 예를 들어, 60 RPS 또는 3,000 사용자 Cloud Native 참조 아키텍처는 60 RPS 또는 3,000 사용자 참조 아키텍처 페이지의 Helm Charts를 사용한 Cloud Native Hybrid 참조 아키텍처(대체) 부분에 있습니다.

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

Infrastructure as Code 도구인 GitLab Environment Tool (GET)은 AWS의 Linux 패키지를 사용하여 구축하는 가장 좋은 장소입니다. 특히 HA 설정을 타겟팅하는 경우입니다. 모든 것을 자동화하는 것은 아니지만 복잡한 설치(예: Gitaly Cluster)를 완료합니다. 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를 사용합니다.

이 가이드에서는 우리가 시작하기 위해 Virtual Private Cloud 및 서브넷을 구성하여 나중에 데이터베이스 서버로 RDS와 Redis 클러스터로 ElastiCache 서비스를 통합하여 마침내 사용자 정의 스케일링 정책을 가진 자동 스케일링 그룹에서 관리하는 멀티 노드 설정을 진행합니다.

요구 사항

AWS와 Amazon EC2을 기본적으로 알고 있을 뿐만 아니라 다음이 필요합니다.

AWS 계정
인스턴스에 SSH로 연결하기 위해 SSH 키를 생성하거나 업로드해야 합니다.
GitLab 인스턴스용 도메인 이름
도메인을 안전하게 하는 SSL/TLS 인증서. 이미 보유하고 있지 않은 경우 AWS Certificate Manager(ACM)를 사용하여 무료 공개 SSL/TLS 인증서를 프로비저닝할 수 있습니다. 로드 밸런서를 사용하기 위해 AWS Certificate Manager를 사용하여 무료 공개 SSL/TLS 인증서를 프로비저닝할 수 있습니다. 만약 아직 보유하고 있지 않은 경우 최대한 빨리 인증서를 신청하십시오.

ACM을 통해 제공된 인증서를 유효성 검사하는 데 몇 시간이 걸릴 수 있습니다. 나중에 지연을 피하려면 최대한 빨리 인증서를 요청하십시오.

아키텍처

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

AWS 비용

GitLab은 다음과 같은 AWS 서비스를 사용합니다. 가격 정보로 이어진 링크:

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

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

Amazon S3 객체 리포지터리를 사용하고 있기 때문에 EC2 인스턴스는 S3 버킷에 대한 읽기, 쓰기 및 디렉터리 권한이 필요합니다. AWS 키를 설정하여 GitLab 구성에 임베드하는 것을 피하기 위해 IAM 역할을 사용합니다. 우리는 IAM 역할에 부여하기 위해 IAM 정책을 생성해야 합니다:

IAM 정책 생성

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

Create policy를 선택하고 JSON 탭을 선택한 다음 정책을 추가합니다. 보안 best pratices 및 최소 권한 부여를 지키고 우리의 역할이 필요한 조치만 수행할 수 있도록합니다.

다이어그램에 표시된 대로 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를 선택하고 Next를 선택합니다.
정책 필터에서 위에서 생성한 gl-s3-policy를 검색하여 선택한 후 Next를 선택합니다.
역할에 이름을 지정합니다(GitLabS3Access를 사용합니다). 필요한 경우 일부 태그를 추가합니다. 그리고 Create role을 선택합니다.

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

네트워크 구성

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

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

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

Amazon Web Services에 로그인합니다.
왼쪽 메뉴에서 Your VPCs를 선택한 후 Create VPC를 선택합니다. “Name tag”에 gitlab-vpc를 입력하고, “IPv4 CIDR 블록”에 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 할당 ID: 기존 Elastic IP를 입력하거나 새 IP를 할당하려면 Allocate Elastic IP address를 선택합니다.
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를 선택하여 대상을 Internet Gateway로 설정하고 이전에 생성한 gitlab-gateway를 선택합니다. 완료되면 Save changes를 선택합니다.

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

Subnet Associations 탭을 선택하고 Edit subnet associations를 선택합니다.
공용 서브넷만 선택하고 Save associations를 선택합니다.

사설 라우팅 테이블

각 사설 서브넷의 인스턴스가 동일한 가용 영역 내의 공용 서브넷에 배치된 NAT 게이트웨이를 통해 인터넷에 연결할 수 있도록 두 개의 사설 라우팅 테이블을 생성해야 합니다.

위와 동일한 단계를 따라 두 개의 사설 라우팅 테이블을 생성합니다. gitlab-private-a 및 gitlab-private-b로 이름을 지정합니다.
그런 다음 각 사설 라우팅 테이블에 대해 목적지가 0.0.0.0/0이고 대상이 앞서 생성한 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를 처리하는 다양한 방법이 있지만, 이 POC(Concept of Principles)에서는 로드 밸런서에서 SSL을 종료하고 백엔드 SSL을 처리하지 않습니다.

EC2 대시보드에서 왼쪽 탐색 모음에서 로드 밸런서를 찾습니다.

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

프로토콜 포트 대상 그룹

TCP 80 gitlab-loadbalancer-ssh-target
TCP 22 gitlab-loadbalancer-http-target
TCP 443 gitlab-loadbalancer-http-target
1. 포트 443의 TLS 리스너에 대해 보안 정책 설정:
  1. 정책 이름: 드롭다운 디렉터리에서 미리 정의된 보안 정책을 선택합니다. 네트워크 로드 밸런서용 사전 정의 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 Health 체크의 경우 준비 상태 체크 엔드포인트를 사용해야 합니다. IP 허용 디렉터리에 VPC IP 주소 범위를 추가하여 Health Check 엔드포인트에 대한 접근을 허용해야 합니다.
6. gitlab-loadbalancer-ssh-target Health 체크의 경우 TCP를 선택합니다.
  - gitlab-loadbalancer-http-target을 포트 80과 443 리스너에 할당합니다.
  - gitlab-loadbalancer-ssh-target을 포트 22 리스너에 할당합니다.
7. 대상 그룹이 이미 생성된 후에만 일부 속성을 구성할 수 있습니다. 여기에는 요구 사항에 따라 구성할 수 있는 몇 가지 기능이 있습니다.
  - 클라이언트 IP 보존은 대상 그룹에서 기본적으로 활성화되어 있습니다. 이를 통해 로드 밸런서에 연결된 클라이언트의 IP가 GitLab 애플리케이션에서 보존됩니다. 이를 요구 사항에 따라 활성화/비활성화할 수 있습니다.
  - 프록시 프로토콜은 대상 그룹에서 기본적으로 비활성화되어 있습니다. 이를 통해 로드 밸런서가 프록시 프로토콜 헤더에 추가 정보를 전송할 수 있습니다. 이를 활성화하려면 기타 환경 컴포넌트(내부 로드 밸런서, NGINX 등)도 구성해야 합니다. 이 POC에서는 나중에 GitLab 노드에서만 이를 활성화하면 됩니다.
로드 밸런서 생성을 선택합니다.

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

로드 밸런서가 가동된 후에는 NLB(Network Load Balancer)를 통한 액세스 및 다른 요구 사항을 세분화하기 위해 보안 그룹을 재조정할 수 있습니다.

로드 밸런서의 DNS 구성

Route 53 대시보드에서 왼쪽 탐색 모음에서 호스팅 영역을 선택합니다.

기존 호스팅 영역을 선택하거나, 도메인에 대한 호스팅 영역이 없는 경우 호스팅 영역 생성을 선택하고, 도메인 이름을 입력한 후 생성을 선택합니다.
레코드 생성을 선택하고 다음 값을 제공합니다:
1. 이름: 도메인 이름(기본 값) 또는 하위 도메인을 입력합니다.
2. 유형: A - IPv4 주소를 선택합니다.
3. 에일리어스: 기본으로 비활성화 상태입니다. 이 옵션을 활성화합니다.
4. 트래픽 라우팅: 네트워크 로드 밸런서에 대한 에일리어스를 선택합니다.
5. 지역: 네트워크 로드 밸런서가 위치한 지역을 선택합니다.
6. 네트워크 로드 밸런서 선택: 이전에 만든 네트워크 로드 밸런서를 선택합니다.
7. 라우팅 정책: 우리는 간단한을 사용하지만 사용 사례에 따라 다른 정책을 선택할 수 있습니다.
8. 대상 상태 평가: 우리는 이를 아니오로 설정했지만 대상 상태에 따라 로드 밸런서가 트래픽을 라우팅하도록 설정할 수 있습니다.
9. 생성을 선택합니다.
도메인을 Route 53을 통해 등록했다면, 끝났습니다. 다른 도메인 등록기를 사용했다면, 도메인 레지스트라에 DNS 레코드를 업데이트해야 합니다. 다음 작업을 수행해야 합니다:
1. 호스팅 영역을 선택하고 위에 추가한 도메인을 선택합니다.
2. NS 레코드 디렉터리이 표시됩니다. 도메인 레지스트라의 관리자 패널에서 각각을 도메인의 DNS 레코드로 추가합니다. 이러한 단계는 도메인 레지스트라 간에 다를 수 있습니다. 도움이 필요하다면 구글에서 “사용하는 레지스트라의 이름” DNS 레코드 추가를 검색하면 해당 도메인 레지스트라에 특화된 도움말 문서를 찾을 수 있습니다.

이러한 작업은 사용하는 레지스트라에 따라 달라지며 이 안내서의 범위를 벗어납니다.

PostgreSQL with RDS

우리의 데이터베이스 서버에서는 Amazon RDS for PostgreSQL을 사용하며, 이는 다중 가용 영역(Multi AZ)을 제공합니다(Aurora is not supported). 먼저 보안 그룹(security group)과 서브넷 그룹(subnet group)을 생성한 후 실제 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)과 설명을 입력하고 이전에 생성한 gitlab-vpc를 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 클래스 인스턴스)를 사용하지 않도록 주의하십시오.

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

RDS 대시보드로 이동하여 왼쪽 메뉴에서 데이터베이스(Databases)를 선택하고 데이터베이스 생성(Create database)를 선택합니다.
데이터베이스 생성 방법으로 표준 생성(Standard Create)을 선택합니다.
데이터베이스 엔진으로 PostgreSQL을 선택하고 database requirements에서 GitLab 버전에 정의된 최소 PostgreSQL 버전을 선택합니다.
이것이 프로덕션 서버이므로 템플릿(Templates) 섹션에서 Production을 선택합니다.
가용성 및 내구성(Availability & durability)에서 다른 가용성 영역에 대기 중인 RDS 인스턴스를 보유하려면 다중 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. 데이터베이스 인증(Database authentication)에서 암호 인증(Password authentication)을 선택합니다.
추가 구성(Additional configuration)을 확장하고 다음을 완료합니다:
초기 데이터베이스 이름을 입력합니다. 여기서는 gitlabhq_production을 사용합니다.
선호하는 백업 설정을 구성합니다.
여기서 변경하는 유일한 것은 Maintenance에서 자동 마이너 버전 업데이트를 비활성화하는 것입니다.
다른 설정은 그대로 두거나 필요에 따라 조정합니다.
완료하면 데이터베이스 생성(Create database)를 선택합니다.

데이터베이스를 생성했으므로 이제 ElastiCache에서 Redis를 설정하는 작업으로 넘어갑니다.

ElastiCache의 Redis

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

Redis 보안 그룹 생성

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

Redis 서브넷 그룹

AWS 콘솔에서 ElastiCache 대시보드로 이동합니다.
왼쪽 메뉴에서 서브넷 그룹(Subnet Groups)으로 이동하고 새 서브넷 그룹을 만듭니다(여기서는 gitlab-redis-group이라고 지정합니다). 이전에 만든 VPC(gitlab-vpc)을 선택하고 선택한 서브넷 테이블에는 private subnets만 포함되도록합니다.
준비가 되면 생성(Create)을 선택합니다.

Redis 클러스터 생성

ElastiCache 대시보드로 돌아가세요.
왼쪽 메뉴에서 Redis 캐시(Redis caches)를 선택하고 Redis 캐시 생성(Create Redis cache)를 선택하여 새로운 Redis 클러스터를 만듭니다.
배포 옵션(Deployment option)에서 자체 캐시 설계(Design your own cache)를 선택합니다.
생성 방법(Creation method)에서 클러스터 캐시(Cluster cache)를 선택합니다.
클러스터 모드(Cluster mode)에서 지원되지 않습니다가 선택되지 않았지만 클러스터 모드가 비활성화되어 있어도 여전히 여러 가용 영역에 Redis를 배포할 수 있습니다.
클러스터 정보(Cluster info)에서 클러스터에 이름(gitlab-redis)과 설명을 지정합니다.
위치(Location)에서 AWS 클라우드(AWS Cloud)를 선택하고 Multi-AZ 옵션을 활성화합니다.
클러스터 설정 섹션에서:
1. 엔진 버전으로 Redis requirements에서 GitLab 버전에 정의된 Redis 버전을 선택합니다.
2. 포트를 6379로 둔 채로, 노드 유형(적어도 cache.t3.medium를 사용하되 필요에 따라 조정) 및 복제본 수를 선택합니다.
연결 설정 섹션에서:
1. 네트워크 유형(Network type): IPv4
2. 서브넷 그룹(Subnet groups): 기존 서브넷 그룹 선택(Choose existing subnet group)을 선택하고 이전에 생성한 gitlab-redis-group을 선택합니다.
가용 영역 배치 섹션에서:
1. 선호하는 가용 영역을 매뉴얼으로 선택하고 “Replica 2”에서 다른 두 가용 영역과 다른 가용 영역을 선택합니다.
다음(Next)을 선택합니다.
보안 설정에서 보안 그룹을 편집하고 이전에 생성한 gitlab-redis-sec-group을 선택합니다. 다음(Next)을 선택합니다.
나머지 설정을 기본 값으로 둬도 되고 필요에 따라 수정합니다.
완료되면 생성(Create)을 선택합니다.

버스테이션 호스트 설정

우리의 GitLab 인스턴스는 사설 서브넷에 있기 때문에 구성 변경 및 업그레이드를 포함하는 작업을 위해 SSH로 이러한 인스턴스에 연결할 방법이 필요합니다. 이를 위한 한 가지 방법은 버스테이션 호스트(가끔 점프 박스로도 불림)를 사용하는 것입니다.

버스테이션 호스트를 유지하고 싶지 않다면 AWS Systems Manager Session Manager를 인스턴스에 액세스하기 위해 설정할 수 있습니다. 이는 이 문서의 범위를 벗어납니다.

버스테이션 호스트 A 생성

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

버스테이션 호스트 A에 Elastic IP 할당

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

인스턴스에 SSH로 연결할 수 있는지 확인

EC2 대시보드에서 왼쪽 메뉴에서 인스턴스를 선택합니다.
인스턴스 디렉터리에서 Bastion Host A를 선택합니다.
연결을 선택하고 연결 지침에 따릅니다.
성공적으로 연결되면, 이제 여유성을 위해 두 번째 버스테이션 호스트를 설정해 봅시다.

버스테이션 호스트 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 에이전트 포워딩 사용 방법에 대한 절차에 대한 단계별 가이드는 사설 Amazon VPC에서 Linux 인스턴스에 안전하게 연결를 참조하세요.

GitLab 설치 및 사용자 AMI 생성

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

GitLab 설치

EC2 대시보드에서:

아래 제목이 있는 섹션인 “AWS에서 공식 GitLab-created AMI ID 찾기“를 사용하여 올바른 AMI를 찾고 실행을 선택합니다.
이름 및 태그 섹션에서 이름을 GitLab으로 설정합니다.
인스턴스 유형 드롭다운 디렉터리에서 워크로드에 따라 인스턴스 유형을 선택합니다. 하드웨어 요구 사항을 확인하여 필요에 맞는 인스턴스 유형을 선택하세요(적어도 100명의 사용자를 수용할 수 있는 c5.2xlarge 이상이어야 함).
키페어 섹션에서 새 키페어 생성을 선택합니다.
1. 키페어에 이름을 지정하고(여기서는 gitlab을 사용) gitlab.pem 파일을 나중에 사용하기 위해 저장합니다.
네트워크 설정 섹션에서:
1. VPC: 이전에 생성한 gitlab-vpc를 선택합니다.
2. 서브넷: 이전에 생성한 서브넷 디렉터리에서 gitlab-private-10.0.1.0을 선택합니다.
3. Auto-assign Public IP: Disable를 선택합니다.
4. Firewall: 기존 보안 그룹 선택을 선택하고 이전에 생성한 gitlab-loadbalancer-sec-group를 선택합니다.
리포지터리는 루트 볼륨이 기본적으로 8 GiB이며 데이터를 저장하지 않기 때문에 충분합니다.
모든 설정을 검토하고 만족하다면 인스턴스 시작을 선택합니다.

사용자 정의 구성 추가

Bastion Host A를 통해 GitLab 인스턴스에 연결하고 SSH 에이전트 포워딩을 사용하세요. 연결한 후 다음 사용자 정의 구성을 추가하세요.

Let’s Encrypt 비활성화

로드 밸런서에 SSL 인증서를 추가하기 때문에 GitLab의 Let’s Encrypt 지원이 필요하지 않습니다. Let’s Encrypt는 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 Cluster를 사용하세요.

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

Gitaly를 설치할 EC2 인스턴스를 생성합니다:

EC2 대시보드에서 인스턴스 시작을 선택합니다.
이름 및 태그 섹션에서 이름을 Gitaly로 설정합니다.
AMI를 선택합니다. 이 예제에서는 최신 Ubuntu Server LTS (HVM), SSD 볼륨 타입을 선택합니다. 지원되는 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. Custom TCP 규칙을 만들고 포트 8075를 포트 범위에 추가합니다. 소스에서 gitlab-loadbalancer-sec-group을 선택합니다.
  2. Bastion 호스트에서 SSH 에이전트 포워딩을 사용할 수 있도록 SSH를 통한 입력 규칙을 추가하세요.
루트 볼륨 크기를 20 GiB로 늘리고 볼륨 유형을 Provisioned IOPS SSD (io1)로 변경하세요. (볼륨 크기는 임의의 값입니다. 리포지터리 스토리지 요구 사항에 대한 충분한 크기의 볼륨을 만드세요.)
1. IOPS를 1000으로 설정하세요 (20 GiB × 50 IOPS). GiB 당 최대 50 IOPS까지 할당할 수 있습니다. 더 큰 볼륨을 선택하는 경우 IOPS를 그에 맞게 늘려야 합니다. git과 같이 많은 작은 파일이 직렬로 작성되는 워크로드는 성능이 뛰어난 리포지터리가 필요하므로 Provisioned IOPS SSD (io1)를 선택했습니다.
모든 설정을 검토한 후 행복하다면 인스턴스 시작을 선택하세요.

루트 볼륨에 구성과 리포지터리 데이터를 모두 저장하는 대신 리포지터리 스토리지를 위해 추가적인 EBS 볼륨을 추가할 수도 있습니다. Amazon EBS 요금을 확인하세요. 성능에 부정적인 영향을 미칠 수 있으므로 EFS의 사용을 권장하지 않습니다. 자세한 내용은 관련 문서를 참조하세요.

이제 EC2 인스턴스를 사용할 준비가 되었습니다. 독립 서버에서 Gitaly를 설치하고 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 사용자를 데이터베이스의 색인 조회를 통해 승인하도록 구성을 업데이트합니다.

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 개체, 업로드, Merge Request 차이, 컨테이너 레지스트리 이미지 등을 저장하기 위해 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 허용 디렉터리에 추가해야 합니다. 이는 Health Check 엔드포인트에 대한 것입니다.

/etc/gitlab/gitlab.rb을 편집하세요.

gitlab_rails['monitoring_whitelist'] = ['127.0.0.0/8', '10.0.0.0/16']

GitLab을 재구성하세요.
```
sudo gitlab-ctl reconfigure
```

프록시 프로토콜

만약 이전에 만든 로드 밸런서에서 프록시 프로토콜을 활성화했다면, gitlab.rb 파일에서 이것도 활성화해야 합니다.

/etc/gitlab/gitlab.rb을 편집하세요.

nginx['proxy_protocol'] = true
nginx['real_ip_trusted_addresses'] = [ "127.0.0.0/8", "IP_OF_THE_PROXY/32"]

GitLab을 재구성하세요.
```
sudo gitlab-ctl reconfigure
```

처음 로그인

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

GitLab을 설치하는 방식 및 다른 수단으로 비밀번호를 변경하지 않았다면, 기본 비밀번호는 다음 중 하나입니다.

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

기본 비밀번호를 변경하려면, 기본 비밀번호로 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)을 선택하고 내 AMI(My AMIs) 탭을 선택합니다.
내 소유 기술자(Owned by me)를 선택하고, 우리가 이전에 만든 GitLab-Source 사용자 정의 AMI를 선택하세요.
필요에 맞는 인스턴스 유형을 선택하세요(최소 c5.2xlarge).
키 페어(Key pair) 섹션에서 새 키 페어 만들기(Create new key pair)를 선택하세요.
1. 키 페어에 이름을 지정하고(우리는 gitlab-launch-template을 사용합니다.), gitlab-launch-template.pem 파일을 나중에 사용하기 위해 저장하세요.
기본적으로 루트 볼륨은 8 GiB이며, 여기에 데이터를 저장하지 않기 때문에 충분합니다. 보안 그룹 구성(Configure Security Group)을 선택하세요.
**기존 보안 그룹 선택(Select and existing security group)을 확인하고, 이전에 생성한 gitlab-loadbalancer-sec-group을 선택하세요.
네트워크 설정(Network settings) 섹션:
1. 방화벽(Firewall): 기존 보안 그룹 선택(Select existing security group)을 선택하고, 이전에 만든 gitlab-loadbalancer-sec-group을 선택하세요.
고급 상세 정보(Advanced details) 섹션:
1. IAM 인스턴스 프로필(IAM instance profile): 우리가 이전에 만든 GitLabS3Access 역할을 선택하세요.
모든 설정을 검토하고, 만족하면 시작 템플릿 생성(Create launch template)을 선택하세요.

자동 확장 그룹 생성

EC2 대시보드에서:

왼쪽 메뉴에서 자동 확장 그룹(Auto scaling groups)을 선택하고 자동 확장 그룹 생성(Create Auto Scaling group)을 선택하세요.
그룹 이름(Group name)을 입력하세요(우리는 gitlab-auto-scaling-group을 사용합니다.).
시작 템플릿(Launch template) 아래에서 이전에 생성한 시작 템플릿을 선택하세요. 다음을 선택하세요.
네트워크 설정 섹션에서:
1. VPC에서 드롭다운 디렉터리에서 gitlab-vpc를 선택하세요.
2. 가용성 영역 및 서브넷(Availability Zones and subnets)에서 이전에 작성한 사설 서브넷들(gitlab-private-10.0.1.0 및 gitlab-private-10.0.3.0)을 선택하세요.
3. 다음을 선택하세요.
부하 분산 설정 섹션에서:
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. 다음을 선택하세요.
그룹 크기(Group size)에서 Desired capacity를 2로 설정하세요.
확장 설정 섹션에서:
1. 스케일링 정책 없음(No scaling policies)을 선택하세요. 해당 정책은 나중에 구성합니다.
2. 최소 기대 수용량(Min desired capacity)을 2로 설정하세요.
3. 최대 기대 수용량(Max desired capacity)을 4로 설정하세요.
4. 다음을 선택하세요.
마지막으로, 원하는대로 알림 및 태그를 구성하고, 변경 내용을 검토한 후 자동 확장 그룹을 생성하세요.
자동 확장 그룹 생성 후, Cloudwatch에서 스케일 업 및 다운 정책을 만들고 할당해야 합니다.
1. 이전에 만든 EC2 인스턴스에서 Auto Scaling Group에 대한 CPUUtilization 메트릭을 사용하여 알람을 만듭니다.
2. 다음 조건으로 스케일 업 정책을 생성하세요:
  1. CPUUtilization이 60% 이상일 때 1 용량 단위를 추가합니다.
  2. Scaling policy name을 Scale Up Policy로 설정하세요.
1. 다음 조건으로 스케일 다운 정책을 생성하세요:
  1. CPUUtilization이 45% 이하일 때 1 용량 단위를 제거합니다.
  2. Scaling policy name을 Scale Down Policy로 설정하세요.
1. 새로운 동적 스케일링 정책을 이전에 만든 자동 확장 그룹에 할당하세요.

자동 확장 그룹이 생성되면, EC2 대시보드에서 새로운 인스턴스가 생성되고 로드 밸런서에 추가되는 것을 확인할 수 있습니다. 인스턴스가 상태 체크를 통과하면 로드 밸런서에서 트래픽을 받을 준비가 됩니다.

우리의 인스턴스는 자동 확장 그룹에서 생성되었기 때문에 목표로한 인스턴스를 확인하기 위해 매뉴얼으로 만든 인스턴스를 종료하세요. 우리는 종종 이 인스턴스를 사용하여 사용자 정의 AMI를 만들기 위해 필요했을 뿐입니다.

프로메테우스를 사용한 상태 체크 및 모니터링

Amazon의 클라우드와치 외에도 다양한 서비스에서 활성화할 수 있는 프로메테우스를 기반으로 한 통합 모니터링 솔루션을 제공하는 GitLab이 있습니다. 설치 방법에 대해 더 알아보려면 GitLab 프로메테우스를 참조하세요.

GitLab은 또한 여러 상태 체크 엔드포인트를 제공하여 핑(ping)하여 보고서를 받을 수 있습니다.

GitLab 러너

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

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

백업 및 복원

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

몇 분 후 새 버전이 실행되게 됩니다.

공식 GitLab 생성 AMI ID 찾기

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

결론

본 안내서에서는 대부분 스케일링 및 일부 중복 옵션에 대해 설명했습니다. 개별적인 결과는 다를 수 있습니다.

모든 솔루션은 비용/복잡성 및 가동 시간 사이의 상충 관계를 가집니다. 원하는 가동 시간이 길수록 솔루션이 더 복잡해지며, 솔루션이 더 복잡할수록 설정 및 유지에 필요한 작업이 많아집니다.

아래 자료를 읽어보시고 추가 자료를 요청하려면 언제든지 이슈를 열어주세요:

GitLab 확장: GitLab은 여러 가지 타입의 클러스터링을 지원합니다.
Geo 복제: Geo는 광범위하게 분산된 개발 팀들을 위한 솔루션입니다.
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 구성

PostgreSQL with RDS

RDS 보안 그룹

RDS 서브넷 그룹

데이터베이스 생성

ElastiCache의 Redis

Redis 보안 그룹 생성

Redis 서브넷 그룹

Redis 클러스터 생성

버스테이션 호스트 설정

버스테이션 호스트 A 생성

버스테이션 호스트 A에 Elastic IP 할당

인스턴스에 SSH로 연결할 수 있는지 확인

버스테이션 호스트 B 생성

SSH 에이전트 포워딩 사용

GitLab 설치 및 사용자 AMI 생성

GitLab 설치

사용자 정의 구성 추가

Let’s Encrypt 비활성화

PostgreSQL에 필요한 확장 기능 설치

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

Gitaly 설정

프록시된 SSL 지원 추가

승인된 SSH 키의 빠른 조회

호스트 키 구성

Amazon S3 객체 리포지터리

IP 허용 디렉터리

프록시 프로토콜

처음 로그인

사용자 정의 AMI 생성

자동 확장 그룹 내에서 GitLab 배포

시작 템플릿 생성

자동 확장 그룹 생성

프로메테우스를 사용한 상태 체크 및 모니터링

GitLab 러너

백업 및 복원

GitLab 백업

백업에서 GitLab 복원

GitLab 업데이트

공식 GitLab 생성 AMI ID 찾기

결론

문제 해결

인스턴스의 상태 체크 실패

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

일부 작업 로그가 객체 리포지터리에 업로드되지 않음

도움말

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

도움받기