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. Bare metal.
  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 요구 사항

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

  • Kubernetes (Auto Review Apps 및 Auto Deploy에 대해)

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

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

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

      사용자 정의 차트를 사용하여 배포할 때, prometheus.io/scrape: "true" 및 prometheus.io/port: "10254"를 사용하여 인그레스 매니페스트에 주석을 달아 Prometheus에 의해 수집할 수 있도록 하세요.

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

  • 베이스 도메인 (Auto Review Apps 및 Auto Deploy에 대해)

    Auto DevOps 앱이 모두 사용하는 Auto DevOps 베이스 도메인을 지정해야합니다. 이 도메인은 와일드카드 DNS로 구성해야 합니다.

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

    Runner는 일반적으로 Docker 또는 Kubernetes 익스큐터 중 하나로 Docker를 실행하도록 구성되어야 하며, 권한 부여된 모드 활성화되어야 합니다. Runner는 Kubernetes 클러스터에 설치되어야 할 필요는 없지만, Kubernetes 익스큐터는 쉽게 사용할 수 있으며 자동으로 자동 확장됩니다. Docker 기반 runner를 Docker Machine을 사용하여 자동 확장할 수도 있습니다.

    Runner는 전체 GitLab 인스턴스에 대한 인스턴스 러너로 등록되거나 특정 프로젝트에 할당된 프로젝트 러너로 설정되어야 합니다.

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

    앱의 HTTPS 엔드포인트를 활성화하려면 Kubernetes용 인증서 관리 컨트롤러인 cert-manager를 설치할 수 있습니다. 클러스터에 cert-manager를 설치하면 Let’s Encrypt 인증서를 발급하고 확인하여 인증서를 유효하게 유지합니다.

Kubernetes 또는 Prometheus가 구성되지 않은 경우 Auto Review Apps 및 Auto Deploy이 스킵됩니다.

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

Auto DevOps bare metal 요구 사항

Kubernetes Ingress-NGINX 문서에 따르면:

기존 클라우드 환경에서는 네트워크 로드 밸런서가 필요할 때 하나의 Kubernetes 매니페스트로 NGINX Ingress 컨트롤러에 대한 외부 클라이언트 및 간접적으로 클러스터 내부에서 실행 중인 어플리케이션에 대한 단일 연락처를 제공합니다. 그러나 금속 서버 환경에서는 이러한 가용성이 없어 외부 소비자에게 동일한 종류의 액세스를 제공하기 위해 약간 다른 설정이 필요합니다.

상기 문서에 설명된 문제와 가능한 해결책이 제시되어 있습니다. 예를 들어,