Auto DevOps를 활성화하기 전에 배포를 위한 준비를 해야 합니다. 준비하지 않은 경우에도 앱을 빌드하고 테스트하는 데 사용할 수 있으며, 이후에 배포를 구성할 수 있습니다.

배포를 준비하려면:

1. 배포 전략을 정의합니다.

2. 기본 도메인을 준비합니다.

3. 배포할 위치를 정의합니다:

   1. Kubernetes.
   2. Amazon Elastic Container Service (ECS).
   3. Amazon Elastic Kubernetes Service (EKS).
   4. Amazon EC2.
   5. Google Kubernetes Engine.
   6. 베어 메탈.

4. Auto DevOps를 활성화합니다.

Auto DevOps 배포 전략#

Auto DevOps를 사용하여 애플리케이션을 배포할 때, 필요에 맞는 지속적 배포 전략을 선택하세요:

Auto DevOps를 활성화할 때 또는 이후에 배포 방법을 선택할 수 있습니다:

1. 상단 바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 설정 > CI/CD를 선택합니다.
3. Auto DevOps를 확장합니다.
4. 배포 전략을 선택합니다.
5. 변경 사항 저장을 선택합니다.

Auto DevOps 기본 도메인#

Auto DevOps 기본 도메인은 Auto Review Apps와 Auto Deploy를 사용하는 데 필요합니다.

기본 도메인을 정의하려면 다음 중 하나를 수행하세요:

• 프로젝트, 그룹 또는 인스턴스 수준에서: 클러스터 설정으로 이동하여 추가합니다.
• 프로젝트 또는 그룹 수준에서: 환경 변수로 추가합니다: KUBE_INGRESS_BASE_DOMAIN.
• 인스턴스 수준에서: 관리자 영역으로 이동한 다음 설정 > CI/CD > 지속적 통합 및 전달에서 추가합니다.

기본 도메인 변수 KUBE_INGRESS_BASE_DOMAIN은 다른 환경 변수와 동일한 우선순위를 따릅니다.

프로젝트 및 그룹에서 기본 도메인을 지정하지 않은 경우, Auto DevOps는 인스턴스 전체의 Auto DevOps 도메인을 사용합니다.

Auto DevOps는 기본 도메인과 일치하는 와일드카드 DNS A 레코드가 필요합니다. example.com의 기본 도메인에 대해 다음과 같은 DNS 항목이 필요합니다:

*.example.com   3600     A     10.0.2.2

이 경우 배포된 애플리케이션은 example.com에서 제공되며, 10.0.2.2는 일반적으로 NGINX인 로드 밸런서의 IP 주소입니다(요구 사항 참조). DNS 레코드 설정은 이 문서의 범위를 벗어나며, 자세한 내용은 DNS 공급자에게 문의하세요.

또는 nip.io와 같이 구성 없이 자동 와일드카드 DNS를 제공하는 무료 공개 서비스를 사용할 수 있습니다. nip.io의 경우, Auto DevOps 기본 도메인을 10.0.2.2.nip.io로 설정하세요.

설정을 완료하면 모든 요청이 로드 밸런서에 도달하고, 로드 밸런서는 애플리케이션을 실행하는 Kubernetes 파드로 요청을 라우팅합니다.

Kubernetes에 대한 Auto DevOps 요구 사항#

Kubernetes와 함께 Auto DevOps를 최대한 활용하려면 다음이 필요합니다:

• Kubernetes (Auto Review Apps 및 Auto Deploy용)

  배포를 활성화하려면 다음이 필요합니다:

  1. 프로젝트를 위한 Kubernetes 1.12+ 클러스터. Kubernetes 1.16+ 클러스터의 경우 Kubernetes 1.16+용 Auto Deploy에 대한 추가 구성이 필요합니다.

  2. 외부 HTTP 트래픽의 경우 Ingress 컨트롤러가 필요합니다. 일반적인 배포의 경우 모든 Ingress 컨트롤러가 작동하지만, GitLab 14.0부터 카나리아 배포에는 NGINX Ingress가 필요합니다. NGINX Ingress 컨트롤러는 GitLab 클러스터 관리 프로젝트 템플릿을 통하거나 ingress-nginx Helm 차트를 수동으로 사용하여 Kubernetes 클러스터에 배포할 수 있습니다.

     커스텀 차트를 사용하여 배포할 때, Prometheus가 prometheus.io/scrape: "true" 및 prometheus.io/port: "10254"를 사용하여 스크레이프하도록 Ingress 매니페스트에 주석을 달아야 합니다.

     [!note] 클러스터가 베어 메탈에 설치된 경우 베어 메탈에 대한 Auto DevOps 요구 사항을 참조하세요.

• 기본 도메인 (Auto Review Apps 및 Auto Deploy용)

  모든 Auto DevOps 애플리케이션이 사용하는 Auto DevOps 기본 도메인을 지정해야 합니다. 이 도메인은 와일드카드 DNS로 구성해야 합니다.

• GitLab Runner (모든 스테이지용)

  Runner는 Docker 또는 Kubernetes 실행기와 함께 특권 모드 활성화로 일반적으로 Docker를 실행하도록 구성해야 합니다. Runner는 Kubernetes 클러스터에 설치할 필요가 없지만, Kubernetes 실행기는 사용하기 쉽고 자동으로 자동 확장됩니다. Docker Machine을 사용하여 Docker 기반 Runner도 자동 확장하도록 구성할 수 있습니다.

  Runner는 전체 GitLab 인스턴스에 대한 인스턴스 Runner 또는 특정 프로젝트에 할당된 프로젝트 Runner로 등록해야 합니다.

• cert-manager (선택 사항, TLS/HTTPS용)

  애플리케이션에 HTTPS 엔드포인트를 활성화하려면 인증서 발급을 돕는 기본 Kubernetes 인증서 관리 컨트롤러인 cert-manager를 설치할 수 있습니다. 클러스터에 cert-manager를 설치하면 Let's Encrypt 인증서가 발급되고 인증서가 유효하고 최신 상태로 유지됩니다.

Kubernetes나 Prometheus가 구성되어 있지 않으면 Auto Review Apps 및 Auto Deploy가 건너뜁니다.

모든 요구 사항을 충족한 후 Auto DevOps를 활성화할 수 있습니다.

베어 메탈에 대한 Auto DevOps 요구 사항#

Kubernetes Ingress-NGINX 문서에 따르면:

네트워크 로드 밸런서를 즉시 사용할 수 있는 기존 클라우드 환경에서는 단일 Kubernetes 매니페스트로 NGINX Ingress 컨트롤러에 대한 외부 클라이언트의 단일 접점을 제공하고 간접적으로 클러스터 내에서 실행 중인 모든 애플리케이션에 제공하기에 충분합니다. 베어 메탈 환경에는 이러한 기능이 없으므로 외부 소비자에게 동일한 종류의 액세스를 제공하기 위해 약간 다른 설정이 필요합니다.

이전에 링크된 문서는 문제를 설명하고 가능한 해결책을 제공합니다. 예를 들면:

• MetalLB를 통한 방법.
• PorterLB를 통한 방법.