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를 사용하는 경우 필요에 맞는 지속적 배포 전략을 선택하세요:

배포 전략 설정 방법론
제품로의 지속적 배포 기본 브랜치를 계속해서 제품으로 계속 배포하는 자동 배포를 활성화합니다. 제품으로 지속적 배포
시간별 점진적 배포를 통한 제품으로의 지속적 배포 INCREMENTAL_ROLLOUT_MODE 변수를 timed로 설정합니다. 배포 간 5분의 지연을 두고 제품으로 계속 배포합니다.
자동으로 스테이징 배포, 매뉴얼으로 제품 배포 STAGING_ENABLED를 1로 설정하고 INCREMENTAL_ROLLOUT_MODE를 manual로 설정합니다. 기본 브랜치는 스테이징으로 지속 배포되고 제품으로 지속 전달됩니다.

나중에 Auto DevOps를 활성화하거나 활성화할 때 배포 방법을 선택할 수 있습니다:

  1. 왼쪽 사이드바에서 검색 또는 이동하여 프로젝트를 찾습니다.
  2. 설정 > CI/CD를 선택합니다.
  3. Auto DevOps를 확장합니다.
  4. 배포 전략을 선택하세요.
  5. 변경 사항 저장을 선택하세요.
note
블루-그린 배포 기술을 사용하여 다운타임과 위험을 최소화하세요.

Auto DevOps 기본 도메인

Auto DevOps 기본 도메인은 자동 리뷰 앱 및 자동 배포를 사용하기 위해 필요합니다.

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

  • 프로젝트, 그룹 또는 인스턴스 수준: 클러스터 설정으로 이동하여 거기에 추가합니다.
  • 프로젝트 또는 그룹 수준: 환경 변수로 추가합니다: 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 pod으로 요청을 라우팅합니다.

Kubernetes에 대한 Auto DevOps 요구 사항

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

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

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

    1. 프로젝트용 Kubernetes 1.12+ 클러스터. Kubernetes 1.16+ 클러스터의 경우 Kubernetes 1.16+에 대한 자동 배포를 위해 추가 구성이 필요합니다.
    2. 외부 HTTP 트래픽의 경우 Ingress 컨트롤러가 필요합니다. 정규 배포의 경우 어떤 Ingress 컨트롤러라도 작동하지만 GitLab 14.0부터는 카나리아 배포를 위해 NGINX Ingress가 필요합니다. NGINX Ingress 컨트롤러를 Kubernetes 클러스터에 배포하려면 GitLab 클러스터 관리 프로젝트 템플릿을 사용하거나 ingress-nginx Helm 차트를 사용하여 매뉴얼으로 배포할 수 있습니다.

    사용자 정의 차트를 사용하여 배포하는 경우, Prometheus가 스크랩 할 Ingress 매니페스트를 prometheus.io/scrape: "true", prometheus.io/port: "10254"으로 주석 처리해야 합니다.

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

  • 기본 도메인 (자동 리뷰 앱 및 자동 배포를 위해)

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

  • GitLab Runner (모든 단계를 위해)

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

    러너는 인스턴스 러너로 등록되어 전체 GitLab 인스턴스에 대해 사용 가능하거나 특정 프로젝트에 할당된 프로젝트 러너로 구성되어야 합니다.

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

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

Kubernetes 또는 Prometheus가 구성되지 않은 경우 자동 리뷰 앱 및 자동 배포가 생략됩니다.

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

#

자동 DevOps 요구 사항 (Auto DevOps requirements) 에 대해서는, Kubernetes Ingress-NGINX docs에 따르면:

전통적인 클라우드 환경에서는 네트워크 로드 밸런서가 필요한 경우 하나의 Kubernetes manifest로 외부 클라이언트 및 간접적으로 클러스터 내에서 실행되는 애플리케이션에 대한 단일 접점을 제공합니다. 그러나 bare-metal 환경에서는 이러한 편의성이 부족하여 외부 사용자에게 동일한 형태의 접근을 제공하기 위해 약간 다른 설정이 필요합니다.

상기 문서에 설명된 문제와, MetalLB를 통한 가능한 해결책과 PorterLB를 통한 것 등이 있습니다.