배포 보드 (사용 중단)

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated
자체 호스팅된 GitLab의 경우 기본적으로 이 기능을 사용할 수 없습니다. 이 기능을 사용하려면 관리자가 certificate_based_clusters라는 피처 플래그를 활성화해야 합니다.

GitLab 배포 보드는 현재 CI 환경에서 실행 중인 각 pod의 건강 상태와 상태를 통합된 보기로 제공하여 Kubernetes에서 실행 중인 환경별 롤아웃의 진행 상황과 상태를 변경 없이 개발자 및 다른 팀원들이 현재 사용 중인 워크플로우에서 볼 수 있습니다.

note
Kubernetes 클러스터가 있는 경우 Auto DevOps를 사용하여 프로덕션 환경으로 자동 배포할 수 있습니다.

개요

배포 보드를 사용하면 다음과 같은 이점으로 배포에 대한 더 많은 통찰력을 얻을 수 있습니다:

  • 시작부터 배포를 따를 수 있음
  • 여러 서버에 걸쳐 빌드의 롤아웃을 관찰
  • 더 미세한 상태 세부 정보 (성공, 실행 중, 실패, 대기 중, 알 수 없음)
  • 캐너리 배포 보기

다음은 프로덕션 환경의 배포 보드의 예입니다.

배포 보드 랜딩 페이지

네모 상자는 지정된 환경과 관련된 Kubernetes 클러스터의 pod를 나타냅니다. 각 네모 상자 위에 마우스를 올리면 롤아웃 중인 디플로이 상태를 볼 수 있습니다. 백분율은 가장 최신 릴리스로 업데이트된 pod의 비율입니다.

배포 보드가 Kubernetes와 밀접하게 연결되어 있기 때문에 기본적인 지식이 필요합니다. 특히 다음과 같은 것에 익숙해져야 합니다:

사용 사례

배포 보드는 특정 환경의 Kubernetes pod의 시각적인 표현이기 때문에 다양한 사용 사례가 있습니다. 몇 가지 예를 들자면:

  • Staging에서 실행 중인 내용을 프로덕션 환경으로 프로모션하려는 경우, 환경 디렉터리에 가서 Staging에서 실행 중인 것이 예상대로인지 확인한 후, 프로덕션으로 배포하려면 매뉴얼 작업을 선택합니다.
  • 배포를 트리거하고 업그레이드할 컨테이너가 많으므로 시간이 걸릴 것으로 알고 있습니다(한 번에 X개의 컨테이너만 중단하도록 제한했습니다). 그러나 배포가 완료되면 누군가에게 알려야 하므로 환경 디렉터리에 가서 프로덕션 환경을 살펴보고 각 pod가 롤아웃되는 실시간 진행 상황을 확인합니다.
  • 프로덕션 환경에 뭔가 이상한 것이 있다는 보고를 받았으므로 프로덕션 환경을 확인하여 무엇이 실행 중이고, 배포가 진행 중이거나 멈춘 상태인지 확인합니다.
  • 좋아 보이는 MR이 있지만, Staging이 프로덕션에 더 가까운 방식으로 설정되어 있기 때문에 Staging에서 실행해 보고 싶습니다. 환경 디렉터리에 가서 관심 있는 Review App을 찾아 매뉴얼 조치를 선택하여 Staging으로 배포합니다.

배포 보드 활성화

특정 환경에 대한 배포 보드를 표시하려면 다음을 해야 합니다:

  1. 배포 단계가 있는 환경을 정의해야 합니다.

  2. Kubernetes 클러스터가 동작 중이어야 합니다.

    note
    OpenShift를 사용하는 경우 Deployment 리소스 대신 DeploymentConfiguration를 사용하십시오. 그렇지 않으면 배포 보드가 올바르게 렌더링되지 않습니다. 자세한 내용은 OpenShift 문서와 GitLab 이슈 #4584를 참조하십시오.
  3. 프로젝트에 GitLab Runner를 설정하고 docker 또는 kubernetes 실행자를 사용해야 합니다.
  4. 프로젝트에서 Kubernetes 통합을 구성하여 클러스터에 대한 Kubernetes 네임스페이스가 필요합니다. Kubernetes 배포 스크립트에서 이를 사용해야 하기 때문입니다 (KUBE_NAMESPACE 배포 변수로 노출됨).

  5. Kubernetes 주석으로 app.gitlab.com/env: $CI_ENVIRONMENT_SLUG 와 app.gitlab.com/app: $CI_PROJECT_PATH_SLUG가 배포, 레플리카셋, pod에 적용되어 있어야 합니다. 이렇게 하면 클러스터/네임스페이스에서 올바른 환경을 조회할 수 있습니다. 이러한 리소스는 Kubernetes 서비스 설정에서 정의된 네임스페이스에 포함되어야 합니다. 각 프로젝트는 Kubernetes에서 고유한 네임스페이스를 가져야 합니다. 아래 이미지는 이것이 Kubernetes에서 어떻게 표시되는지 보여줍니다.

    GCP를 사용하여 클러스터를 관리하는 경우 Workloads > deployment name > Details로 이동하여 GCP 자체에서 배포 세부 정보를 볼 수 있습니다.

    배포 보드 Kubernetes 라벨

모든 항목이 설정되고 파이프라인이 한 번 실행된 후에는 운영 > 환경 아래에 환경 페이지로 이동하면 배포 보드가 기본적으로 표시됩니다. 해당하는 환경 이름 옆의 삼각형을 명시적으로 선택하여 숨길 수 있습니다.

예제 Manifest 파일

다음 예는 배포 보드를 사용하기 위해 app.gitlab.com/env 와 app.gitlab.com/app 두 가지 주석을 사용한 Kubernetes manifest 배포 파일의 일부입니다: 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: "APPLICATION_NAME"
  annotations:
    app.gitlab.com/app: ${CI_PROJECT_PATH_SLUG}
    app.gitlab.com/env: ${CI_ENVIRONMENT_SLUG}
spec:
  replicas: 1
  selector:
    matchLabels:
      app: "APPLICATION_NAME"
  template:
    metadata:
      labels:
        app: "APPLICATION_NAME"
      annotations:
        app.gitlab.com/app: ${CI_PROJECT_PATH_SLUG}
        app.gitlab.com/env: ${CI_ENVIRONMENT_SLUG}

이러한 주석은 배포, 레플리카셋, pod에 적용됩니다. kubectl scale --replicas=3 deploy APPLICATION_NAME -n ${KUBE_NAMESPACE}와 같이 레플리카수를 변경하면 보드에서 인스턴스의 pod를 따를 수 있습니다.

note
YAML 파일은 정적입니다. kubectl apply를 사용하여 적용하는 경우 직접 프로젝트 및 환경 슬러그를 제공하거나 적용하기 전에 변수를 치환하기 위한 스크립트를 생성해야 합니다.

카나리아 배포(Canary Deployments)

인기 있는 CI 전략으로, 플리트의 일부가 응용 프로그램의 새 버전으로 업데이트됩니다.

카나리아 배포에 대해 더 알아보기.

추가 자료