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 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는 귀하의 로드 밸런서의 IP 주소, 일반적으로 NGINX입니다 (요구 사항 참조).
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 차트를 사용하여 배포할 수 있습니다.

      사용자 정의 차트를 사용하여 배포할 때, Ingress 매니페스트를 Prometheus가 스크랩할 수 있도록 [prometheus.io/scrape: "true"와 prometheus.io/port: "10254"로 주석을 달아야 합니다.

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

  • 기본 도메인 (Auto Review Apps 및 Auto Deploy를 위해)

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

  • GitLab Runner (모든 단계에 필요)

    러너는 Docker를 실행하도록 구성되어야 하며, 일반적으로 Docker 또는 Kubernetes 실행기를 사용해야 하며, 특권 모드가 활성화되어야 합니다. 러너는 Kubernetes 클러스터에 설치될 필요는 없지만, Kubernetes 실행기는 사용하기 쉽고 자동으로 오토스케일합니다. Docker 기반 러너도 Docker Machine을 사용하여 오토스케일하도록 구성할 수 있습니다.

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

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

    어플리케이션의 HTTPS 엔드포인트를 활성화하려면, cert-manager를 설치할 수 있으며, 이는 인증서 발급을 돕는 네이티브 Kubernetes 인증서 관리 컨트롤러입니다. 클러스터에 cert-manager를 설치하면 Let’s Encrypt 인증서를 발급하며, 인증서가 유효하고 최신 상태인지 확인합니다.

Kubernetes 또는 Prometheus가 구성되지 않은 경우, Auto Review Apps 및 Auto Deploy가 건너뛰어집니다.

모든 요구 사항이 충족되면, Auto DevOps를 활성화할 수 있습니다.

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

Kubernetes Ingress-NGINX 문서에 따르면:

전통적인 클라우드 환경에서는 네트워크 로드 밸런서를 온디맨드로 사용할 수 있지만, 단일 Kubernetes 매니페스트만으로 외부 클라이언트에 대해 NGINX Ingress 컨트롤러에 대한 단일 접점을 제공할 수 있으며, 간접적으로 클러스터 내에서 실행되는 모든 애플리케이션에 대한 접접점을 제공합니다. 베어 메탈 환경에서는 이러한 일반적인 것이 부족하여 외부 소비자에게 동일한 접근을 제공하기 위해 약간 다른 설정이 필요합니다.

위의 문서에서는 문제를 설명하고 가능한 해결책을 제시합니다. 예를 들어: