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. 변경 사항 저장을 선택합니다.
note
다운타임과 리스크를 최소화하려면 블루-그린 배포 기술을 사용하세요.

Auto DevOps 기본 도메인

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

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

  • 프로젝트, 그룹 또는 인스턴스 수준: 클러스터 설정으로 이동하여 추가합니다.
  • 프로젝트 또는 그룹 수준: 환경 변수로 추가합니다: KUBE_INGRESS_BASE_DOMAIN.
  • 인스턴스 수준: Admin Area로 이동한 다음 설정 > 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 트래픽을 위해 Ingress 컨트롤러가 필요합니다. 일반적인 배포에 대해서는 임의의 Ingress 컨트롤러가 작동하지만 GitLab 14.0부터는 카나리아 배포를 위해 NGINX Ingress가 필요합니다. NGINX Ingress 컨트롤러는 GitLab 클러스터 관리 프로젝트 템플릿을 통해 Kubernetes 클러스터에 배포하거나 ingress-nginx Helm 차트를 사용하여 매뉴얼으로 배포할 수 있습니다.

      사용자 정의 차트로 배포할 때, prometheus.io/scrape: "true" 및 prometheus.io/port: "10254"를 사용하여 Ingress 매니페스트를 Prometheus에서 스크랩하도록 주석 처리해야 합니다.

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

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

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

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

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

    Runner는 전체 GitLab 인스턴스에 등록된 인스턴스 Runner이거나 특정 프로젝트에 할당된 프로젝트 Runner로 설정해야 합니다.

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

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

Kubernetes 또는 Prometheus를 구성하지 않았다면 Auto Review Apps 및 Auto Deploy가 건너뜁니다.

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

Bare metal용 Auto DevOps 요구 사항

Kubernetes Ingress-NGINX 문서에 따르면:

전통적인 클라우드 환경에서는 네트워크 로드 밸런서가 필요한 경우 NGINX Ingress 컨트롤러에 대한 단일 Kubernetes 매니페스트가 외부 클라이언트 및 간접적으로 클러스터 내부에서 실행 중인 어떠한 애플리케이션에 대해 외부 소비자에게 동일한 종류의 액세스를 제공하기에 충분합니다. 그러나 Bare-metal 환경에서는 이러한 편의성이 부족하며, 외부 소비자에게 동일한 종류의 액세스를 제공하기 위해 약간 다른 설정이 필요합니다.

상기 링크된 문서에서는 해당 문제를 설명하고 가능한 해결책을 제시하고 있습니다. 예를 들어,

하세요.