OCI에서 CI/CD 파이프라인을 사용으로 설정하기 위해 GitLab 배치

구조

이 참조 아키텍처에는 독립형 배치와 분산 배치의 두 가지 배치 옵션이 있습니다.

독립형(1,000명 미만의 사용자)
독립형 아키텍처는 GitLab에 가장 간단한 옵션입니다. OCI 테넌시 내의 단일 컴퓨트 인스턴스에 모든 GitLab 구성요소를 배치합니다. 최대 1,000명의 사용자에게 서비스를 제공해야 하고 엄격한 가용성 요구 사항이 없는 경우 백업이 빈번한 독립형 솔루션이 많은 조직에 적합합니다. 단일 테넌시는 둘 이상의 GitLab 서버를 호스트할 수 있습니다. 다음 다이어그램은 이 참조 구조를 보여 줍니다:

deploy_gitlab_sa.png에 대한 설명
분산(1000-2000명의 사용자)
분산 솔루션은 전용 GitLab 서버의 다양한 구성 요소를 각각 특정 작업을 수행하도록 지정된 별도의 인스턴스로 분리하는 다계층 구조입니다. 특히 분산 구조에는 완전히 작동하는 GitLab 배치에 필요한 전용 PostgreSQL 서버, Redis 서버, Gitaly 서버 및 Prometheus 모니터링 인스턴스가 있습니다. GitLab 권장 사항에 따라 이 분산 배치는 약 2,000명의 사용자를 지원합니다. 일부 내장 중복성으로 인해 독립형 배포보다 성능이 뛰어나고 내결함성이 높습니다. 그러나 분산 배포는 가용성이 높지 않습니다.

deploy_gitlab_dist.png 그림에 대한 설명

이러한 아키텍처에는 다음과 같은 구성 요소가 있습니다:

영역
Oracle Cloud Infrastructure 지역은 가용성 도메인이라고 하는 하나 이상의 데이터 센터를 포함하는 지역화된 지역입니다. 지역은 다른 지역과 독립적이며, 방대한 거리는 국가 또는 대륙에서 분리할 수 있습니다.
가용성 도메인
가용성 도메인은 영역 내의 독립적인 독립형 데이터 센터입니다. 각 가용성 도메인의 물리적 리소스는 결함 허용 한도를 제공하는 다른 가용성 도메인의 리소스와 격리됩니다. 가용성 도메인은 전원, 냉각 또는 내부 가용성 도메인 네트워크와 같은 인프라를 공유하지 않습니다. 따라서 한 가용성 도메인의 실패는 영역의 다른 가용성 도메인에 영향을 주지 않을 수 있습니다. 이러한 GitLab 참조 구조의 일부로 배치된 인스턴스는 모두 단일 가용성 도메인으로 이동합니다.
VCN(가상 클라우드 네트워크) 및 서브넷
VCN는 OCI 지역에서 설정하는 소프트웨어 정의 네트워크입니다. VCN은 영역 또는 가용성 도메인에 특정한 서브넷으로 분할할 수 있습니다. 지역별 서브넷과 가용성 도메인별 서브넷은 모두 동일한 VCN에 공존할 수 있습니다. 서브넷은 공용 또는 전용일 수 있습니다. 공용 및 전용 서브넷을 포함하는 기존 VCN에 이 GitLab 구조를 배치하거나 필요한 서브넷으로 VCN를 생성하도록 구성할 수 있습니다.
- 배스천 호스트 서브넷
  배스천 호스트 서브넷은 배스천 호스트 인스턴스를 포함하는 전용 공용 서브넷입니다. 배스천 호스트는 이 아키텍처의 선택적 구성요소이며, GitLab가 인터넷 또는 공용 서브넷에 직접 접속된 경우 필요하지 않습니다.
- 로드 밸런서 서브넷
  로드 밸런서 서브넷은 로드 밸런서를 포함하는 전용 공용 서브넷입니다.
- GitLab 전용 서브넷
  GitLab 전용 서브넷에는 Gitaly 서버, Redis 서버, Postgres 서버, Prometheus- Grafana(모니터링) 서버 및 선택적 GitLab 실행기의 두 GitLab 서버가 포함됩니다.
로드 밸런서
로드 밸런서는 GitLab 인스턴스에 접속하는 데 사용되는 공용 IP를 포함합니다. GitLab 인스턴스에 대한 사용자 정의 도메인 이름을 원하는 경우 로드 밸런서의 IP 주소를 DNS 제공자에 등록합니다. 로드 밸런서는 GitLab 서버 모니터링을 위해 라운드 로빈 건전성 검사 정책을 사용합니다.
Compute
GitLab의 경우 GitLab 서버 컴퓨트 인스턴스가 하나만 생성됩니다. 분산 아키텍처의 경우 총 8개의 컴퓨트 인스턴스가 생성됩니다. 이러한 각 인스턴스는 다음 서비스를 제공합니다:
- GitLab 서버
  기본 GitLab 웹 기반 응용 프로그램은 두 GitLab 서버에 설치됩니다. GitLab 관리는 이러한 인스턴스에서 수행되며 로드 밸런서는 프론트 엔드로 작동합니다.
- PostgreSQL 서버
  GitLab 애플리케이션에 대한 영구 데이터베이스 정보를 저장합니다. 예를 들어, 사용자, 권한, 문제 또는 기타 메타 데이터는 PostgreSQL 데이터베이스에 저장됩니다.
- Redis 서버
  GitLab 응용 프로그램은 Redis를 작업 정보, 메타 데이터 및 수신 작업에 대한 비영구 데이터베이스 백엔드로 사용합니다.
- Gitaly 서버
  Gitaly 서비스는 Git 저장소에 대한 파일 저장 영역을 제공합니다. GitLab에서 저장소의 일부인 모든 파일은 Gitaly 서버에 저장됩니다. 추가 용량 레벨을 입증하기 위해 두 Gitaly 인스턴스가 생성됩니다. 저장소별로 특정 프로젝트에 대한 데이터를 저장하는 서버를 사용자 정의할 수 있습니다.
- PostgreSQL 서버
  GitLab는 PostgreSQL 서버에 영구 데이터베이스 정보를 저장합니다. 영구 데이터의 예로는 사용자, 권한, 문제 및 기타 프로젝트 메타데이터가 있습니다.
- Redis 서버
  GitLab 응용 프로그램은 Redis를 작업 정보, 특정 유형의 메타 데이터 및 수신 작업에 대한 비영구 데이터베이스 백엔드로 사용합니다.
- Prometheus + Grafana(모니터링) 서버
  Prometheus + Grafana 서버는 시스템 및 서비스 모니터링 서버입니다. 제공된 간격으로 구성된 대상에서 측정 단위를 수집하고, 규칙 표현식을 평가하고, 결과를 표시하며, 지정된 조건이 관찰될 때 경보를 트리거할 수 있습니다.
- 러너
  GitLab 실행기는 파이프 라인에서 작업을 실행하기 위해 GitLab CI/CD와 함께 작동하는 전용 시스템입니다. 일반적으로 GitLab 인스턴스가 작동되어 실행 및 테스트된 후 GitLab 환경에 배치됩니다. 배치의 일부로 생성되지 않습니다.
오브젝트 스토리지
분산 배치는 백업을 포함하여 GitLab 프로젝트와 연관된 다양한 유형의 데이터를 저장하도록 설계된 OCI 테넌시 내에 일련의 오브젝트 스토리지 버킷을 생성합니다.

권장 사항

GitLab를 배치할 때 다음 권장 사항을 시작점으로 사용하여 Oracle Cloud Infrastructure에서 CI/CD 파이프라인을 사용으로 설정하십시오. 요구 사항은 여기에 설명된 아키텍처와 다를 수 있습니다.

컴퓨트 구성

이 아키텍처는 Oracle Linux OS 이미지를 사용하며 모든 컴퓨트 구성 제품군(표준 또는 유연성) 을 지원합니다. GitLab은 독립형 및 분산 배치에 대해 다음 구성 매개변수를 권장합니다:

독립형

서비스

구성

GitLab 서버

OCPU 4개, 8GB RAM

GitLab 실행기(N 선택사항)

OCPU 1개, 4GB RAM

분배됨

서비스

구성

배스천 서버(선택사항)

OCPU 1개, 2GB RAM

GitLab 서버(2)

OCPU 4개, 8GB RAM

PostgreSQL

OCPU 1개, 8GB RAM

Redis

OCPU 1개, 4GB RAM

Gitaly(1필수, 2선택 사항)

OCPU 2개, 16GB RAM

모니터링 노드

OCPU 1개, 2GB RAM

GitLab 실행기(N 선택사항)

OCPU 1개, 4GB RAM

GitLab은 이러한 구성을 권장하지만 배치 시 사용자가 정의할 수 있습니다.

VCN
VCN 및 서브넷을 생성할 때 전용 접속을 설정하려는 다른 네트워크(OCI, 온-프레미스 데이터 센터 또는 다른 클라우드 제공자) 와 겹치지 않는 CIDR 블록을 사용합니다. VCN CIDR 블록은 생성 후 편집할 수 있습니다.

서브넷을 설계할 때 트래픽 흐름 및 보안 요구사항을 고려하십시오. 특정 계층 또는 역할 내의 모든 리소스를 동일한 서브넷에 연결합니다. 이 서브넷은 보안 경계 역할을 할 수 있습니다.
보안
Oracle Cloud Guard를 사용하여 OCI에서 리소스의 보안을 사전에 모니터하고 유지 관리할 수 있습니다. Cloud Guard는 정의할 수 있는 감지기 레시피를 사용하여 리소스의 보안 취약점을 검사하고 운영자 및 사용자의 위험 작업을 모니터합니다. 잘못된 구성 또는 비보안 작업이 감지되면 Cloud Guard는 해결 조치를 권장하고 정의할 수 있는 응답자 레시피를 기반으로 해당 작업을 지원합니다.

최대 보안이 필요한 리소스의 경우 Oracle은 보안 영역을 사용할 것을 권장합니다. 보안 영역은 최적의 방법을 기반으로 하는 보안 정책의 Oracle 정의 레시피와 연관된 구획입니다. 예를 들어, 보안 영역의 리소스는 공용 인터넷에서 액세스할 수 없어야 하며 고객 관리 키를 사용하여 암호화해야 합니다. 보안 영역에서 리소스를 생성 및 업데이트하면 OCI는 보안 영역 레시피의 정책에 대해 작업을 검증하고 정책을 위반하는 작업을 거부합니다.
러너
기존 GitLab 인스턴스와 동일한 전용 서브넷에 GitLab 실행기를 배치하거나 전용 VCN 또는 서브넷에 배치할 수 있습니다.

고려 사항

이 참조 구조를 배치할 때는 다음 사항을 고려하십시오.

성능
이 구조의 일부로 실행된 모든 기본 컴퓨트 구성은 GitLab 설명서에 제공된 권장 사항을 따릅니다. 그러나 입자 노드에 더 많은 리소스가 필요한 경우 컴퓨트 구성의 배율을 조정할 수 있습니다. 분산 아키텍처는 독립형 배포보다 성능이 높습니다. 구조에는 다음과 같은 예상 성능 측정 단위 옵션이 있습니다.
Security
로드 밸런서 및 배스천 호스트(있는 경우) 를 제외하고 GitLab 구조의 모든 구성요소는 전용 서브넷에 있습니다. 분산 아키텍처의 컴퓨트 인스턴스에는 모두 방화벽이 사용으로 설정되어 있고 iptables가 켜져 있으며 필요한 포트만 노드 간 통신을 사용으로 설정합니다.
가용성
GitLab 서버는 쌍으로 배치되고 로드 밸런서에 의해 균형이 조정됩니다. 모든 인스턴스는 단일 가용성 도메인에 배치됩니다. 또한 이 참조 아키텍처는 다양한 유형의 데이터를 저장하기 위한 여러 오브젝트 스토리지 버킷을 생성합니다. 오브젝트 스토리지는 지역 서비스이며 특정 컴퓨트 인스턴스 또는 가용성 도메인에 연결되지 않습니다. 인터넷에 접속되어 있고 오브젝트 스토리지 끝점 중 하나에 액세스할 수 있는 한 OCI 컨텍스트 내부 또는 외부의 모든 위치에서 데이터에 액세스할 수 있습니다. 이 배치는 서비스 게이트웨이를 사용하여 오브젝트 스토리지 버킷에 접속합니다. 서비스 게이트웨이를 사용하면 전용 서브넷의 전용 IP 주소에서 오브젝트 스토리지 공용 엔드포인트에 연결할 수 있습니다.
백업 및 복원
분산 배치는 백업을 저장하기 위한 오브젝트 스토리지 버킷을 생성하고 해당 버킷으로 데이터를 업로드하는 데 필요한 모든 구성 설정을 지정합니다. 또한 기본 GitLab 서버 인스턴스에서 cron 작업을 생성하여 매일 GitLab 데이터 백업을 생성하고 버킷에 업로드하고 복사본을 시스템에 저장합니다. gitlab-secrets. json 파일은 중요한 데이터를 포함하며 이 백업에 포함되지 않습니다. 관리자가 이 배포 외부에 있는 /etc/gitlab 디렉토리 또는 /etc/gitlab/gitlab-secrets.json 파일의 복사본을 안전한 장소에 보관하는 것이 좋습니다. 더 자주 백업을 수행하고 오브젝트 스토리지 버킷에 적절한 보존 정책을 설정하려는 경우 고려하십시오.
```
## Run a backup everyday at 1am.
0 1 * * * sudo gitlab-backup create
 
## Run a separate backup for configuration settings (creates a tar archive in /etc/gitlab/config_backup)
0 2 * * * sudo gitlab-ctl backup-etc
```
GitLab 데이터뿐만 아니라 전체 GitLab 서버를 백업할 수 있습니다. OCI 블록 볼륨 서비스를 사용하면 일정에 따라 블록 볼륨 백업을 자동으로 수행하고 선택한 백업 정책에 따라 블록 볼륨 백업을 보존할 수 있습니다. 자세한 내용은 정책 기반 백업 설명서를 참조하십시오.
비용
이 아키텍처의 비용은 컴퓨트 인스턴스, 네트워크 로드 밸런서 및 데이터 스토리지와 같은 OCI 배치된 인프라와 GitLab의 라이센스 구매와 관련이 있습니다. OCI 서비스 비용에 대한 자세한 내용은 Oracles Cloud Proce List 페이지를 참조하십시오.
공용 URL
DNS 제공자를 사용하여 GitLab 인스턴스의 공용 IP 주소를 사용자정의 도메인 이름과 연관시키는 것이 좋습니다. 분산 구조에서 사용자정의 URL은 로드 밸런서의 공용 IP 주소와 연관되어야 합니다. 배치 시 외부 URL 도메인 이름을 설정한 다음 이후 GitLab 배치에서 URL을 IP 주소와 연관시킬 수 있습니다. 사실 값 뒤에 언제든지 사용자정의 URL을 변경할 수 있습니다.

배치

이 참조 구조에 대한 Terraform 코드는 Oracle Cloud Infrastructure Resource Manager에서 샘플 스택으로 사용할 수 있습니다. GitLab에서 코드를 다운로드하여 특정 요구 사항에 맞게 사용자 정의할 수도 있습니다.

Oracle Cloud Infrastructure Resource Manager의 샘플 스택을 사용하여 배치합니다:
1. 을 누릅니다.
  아직 사인인하지 않은 경우 테넌시 및 사용자 인증서를 입력합니다.
2. 스택을 배치할 영역을 선택합니다.
3. 화면의 프롬프트 및 지침에 따라 스택을 만듭니다.
4. 스택을 생성한 후 Terraform 작업 을 누르고 계획 을 선택합니다.
5. 작업이 완료될 때까지 기다렸다가 계획을 검토합니다.
  변경하려면 스택 세부정보 페이지로 돌아가서 스택 편집 을 누르고 필요한 사항을 변경합니다. 그런 다음 계획 작업을 다시 실행합니다.
6. 더 이상 변경할 필요가 없는 경우 스택 세부 정보 페이지로 돌아가서 Terraform 작업 을 누르고 적용 을 선택합니다.
GitLab에서 Terraform 코드를 사용하여 배포합니다:
1. GitLab로 이동합니다.
2. 저장소를 로컬 컴퓨터로 복제하거나 다운로드합니다.
3. README 문서의 지침을 따릅니다.

자세히 살펴보기

GitLab를 배포하여 Oracle Cloud Infrastructure에서 CI/CD 파이프라인을 사용으로 설정하는 방법에 대해 자세히 알아보십시오.

다음 추가 리소스를 검토합니다: