Auto DevOps 요구 사항

세부정보: Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

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 Deploy를 활성화합니다. 프로덕션으로의 지속적 배포.
타임드 점진적 롤아웃을 통한 프로덕션으로의 지속적 배포 INCREMENTAL_ROLLOUT_MODE 변수를 timed로 설정합니다. 롤아웃 간 5분의 지연을 가지고 프로덕션으로 지속적으로 배포합니다.
스테이징으로의 자동 배포, 프로덕션으로의 수동 배포 STAGING_ENABLED를 1로, INCREMENTAL_ROLLOUT_MODE를 manual로 설정합니다. 기본 브랜치를 스테이징으로 지속적으로 배포하고 프로덕션으로 지속적으로 전달합니다.

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 제공업체에서 확인하세요.

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

설정을 완료하면 모든 요청이 로드 밸런서로 전달되어 앱을 실행하는 Kubernetes 파드에 라우팅됩니다.

Kubernetes를 위한 Auto DevOps 요구 사항

Auto DevOps와 Kubernetes를 모두 완전히 활용하려면 다음이 필요합니다:

  • Kubernetes (자동 리뷰 앱 및 자동 배포를 위함)

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

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

    2. 외부 HTTP 트래픽을 위해 인그레스 컨트롤러가 필요합니다. 일반 배포의 경우 어떤 인그레스 컨트롤러라도 작동하지만, GitLab 14.0부터 canary 배포가 필요한 경우 NGINX Ingress가 필요합니다. NGINX Ingress 컨트롤러를 Kubernetes 클러스터에 배포하려면 GitLab 클러스터 관리 프로젝트 템플릿을 통해 또는 수동으로 ingress-nginx Helm 차트를 사용하여 배포할 수 있습니다.

      사용자 정의 차트를 사용하여 배포하는 경우 Ingress 매니페스트를 prometheus.io/scrape: "true" 및 prometheus.io/port: "10254"를 사용하여 Prometheus에 스크랩되도록 주석을 달아야 합니다.

      참고: 클러스터가 베어 메탈에 설치된 경우, 베어 메탈용 Auto DevOps 요구 사항을 참조하세요.

  • 베이스 도메인 (자동 리뷰 앱 및 자동 배포를 위함)

    모든 Auto DevOps 애플리케이션에서 사용되는 Auto DevOps 베이스 도메인을 지정해야 합니다. 이 도메인은 와일드카드 DNS로 구성되어야 합니다.

  • GitLab Runner (모든 단계에 대해)

    러너는 일반적으로 Docker 또는 Kubernetes 실행기 중 하나를 사용하여 Docker를 실행할 수 있도록 구성해야 합니다. 권한이 활성화된 러너가어야 합니다. 러너는 클러스터에 설치될 필요는 없지만 Kubernetes 실행기는 쉽게 사용할 수 있으며 자동으로 오토스케일링됩니다. Docker 기반 러너도 Docker Machine을 사용하여 자동으로 스케일을 조정할 수 있습니다.

    러너는 GitLab 인스턴스 전체의 인스턴스 러너로 등록하거나 특정 프로젝트에 할당된 프로젝트 러너로 등록해야 합니다.

  • cert-manager (TLS/HTTPS를 위한 선택 사항)

    응용 프로그램의 HTTPS 엔드포인트를 활성화하려면 인증서를 발급하는 데 도움이 되는 네이티브 Kubernetes 인증서 관리 컨트롤러인 cert-manager를 설치할 수 있습니다. 클러스터에 cert-manager를 설치하면 Let’s Encrypt 인증서를 발급하고 해당 인증서가 유효하고 최신 상태를 유지하도록 보장합니다.

Kubernetes 또는 Prometheus를 구성하지 않은 경우 자동 리뷰 앱 및 자동 배포는 건너뜁니다.

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

베어 메탈을 위한 Auto DevOps 요구 사항

Kubernetes Ingress-NGINX 문서에 따르면:

기존 클라우드 환경에서는 네트워크 로드 밸런서를 필요에 따라 사용할 수 있으며, 단일 Kubernetes 매니페스트로 외부에서 NGINX Ingress 컨트롤러에 대한 단일 접점을 제공하여 간접적으로 클러스터 내에서 실행 중인 응용 프로그램에 대한 외부 사용자에게 동일한 유형의 액세스를 제공하는 것이 충분합니다. 그러나 베어 메탈 환경에서는 이러한 편의가 부족하기 때문에 외부 소비자에게 동일한 유형의 액세스를 제공하기 위해 약간 다른 설정이 필요합니다.

상기 링크에 설명된 문서는 MetalLB나 PorterLB를 통해 가능한 해결책 등을 제시합니다.