배포 보드 (폐기 예정)

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated
  • Self-managed에서 사용 불가능합니다. GitLab 15.0에서 비활성화됨.
Self-managed GitLab에서는 기본적으로 이 기능을 사용할 수 없습니다. 관리자는 certificate_based_clusters라는 기능 플래그를 활성화할 수 있습니다.

GitLab 배포 보드는 현재 CI 환경에 실행 중인 각각의 pod의 상태를 통합된 형태로 보여줌으로써 Kubernetes에서 실행 중인 배포의 상태를 시각적으로 표시합니다. 개발자 및 다른 팀원들은 쿠버네티스에 액세스할 필요 없이 이미 사용 중인 워크플로우에서 롤아웃의 진행 및 상태, pod별로 확인할 수 있습니다.

note
Kubernetes 클러스터가 있다면 Auto DevOps를 사용하여 프로덕션 환경으로 자동으로 애플리케이션을 배포할 수 있습니다.

개요

배포 보드를 사용하면 다음과 같은 이점을 가질 수 있습니다:

  • 실행이 완료될 때까지가 아니라 시작하여 롤아웃을 따라갈 수 있음
  • 여러 서버 간에 빌드의 롤아웃을 지켜볼 수 있음
  • 보다 세부적인 상태 정보 (완료됨, 실행 중, 실패, 대기 중, 알 수 없음)
  • Canary 배포 확인

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

deploy boards landing page

네모 상자들은 해당 환경과 관련된 Kubernetes 클러스터 내의 pod를 나타냅니다. 각 상자 위로 마우스를 올리면 롤아웃 중인 배포의 상태를 볼 수 있습니다. 백분율은 최신 릴리스로 업데이트된 pod의 백분율을 의미합니다.

배포 보드가 Kubernetes와 강력하게 결합되어 있으므로 일부 필요한 지식이 필요합니다. 특히 다음과 같은 사항에 익숙해져야 합니다:

사용 사례

배포 보드는 특정 환경의 Kubernetes pod의 시각적 표현이므로 여러 가지 사용 사례가 있습니다. 일부 사용 사례를 들자면:

  • 스테이징에서 실행 중인 내용을 프로덕션으로 홍보하려면 환경 목록으로 이동하여 스테이징에서 실행 중인 것이 예상한 것인지 확인한 후 수동 작업을 선택하여 프로덕션으로 배포합니다.
  • 배포를 시작하고 여러 컨테이너를 업그레이드해야 하는 경우, 조금 시간이 걸릴 것으로 알고 있습니다 (업그레이드를 X개의 컨테이너만 한 번에 중지했습니다). 그러나 배포가 완료되었을 때 누군가에게 알려야 하므로 환경 목록으로 이동하여 프로덕션 환경을 보고 각 pod가 롤아웃되는 상황을 실시간으로 확인할 수 있습니다.
  • 프로덕션에서 이상한 것이 있다는 보고를 받았으므로 프로덕션 환경으로 이동하여 현재 실행 중인 내용을 확인하고 배포가 진행 중인지, 멈춰 있는지, 실패했는지 확인합니다.
  • 좋아 보이는 MR이 있지만 스테이징에서 실행해야 한다고 생각됩니다. Review App를 찾아 스테이징으로 배포하는 수동 조치를 선택합니다.

배포 보드 활성화

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

  1. 배포 단계가 정의된 환경을 가져야 합니다.

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

    note
    OpenShift를 사용하는 경우 DeploymentConfiguration 대신 Deployment 리소스를 사용해야 합니다. 그렇지 않으면 배포 보드가 올바르게 렌더링되지 않습니다. 자세한 정보는 OpenShift 문서GitLab issue #4584를 참조하십시오.
  3. 프로젝트의 GitLab Runnerdocker 또는 kubernetes executor로 구성해야 합니다.
  4. 프로젝트에 대한 Kubernetes 통합을 클러스터에 구성해야 합니다. 특히 Kubernetes 네임스페이스는 배포 스크립트에 필요합니다 (KUBE_NAMESPACE 배포 변수로 노출됨).
  5. Kubernetes 주석인 app.gitlab.com/env: $CI_ENVIRONMENT_SLUGapp.gitlab.com/app: $CI_PROJECT_PATH_SLUG이 배포, 레플리카 세트 및 pod에 적용되어야 합니다. 여기서 $CI_ENVIRONMENT_SLUG$CI_PROJECT_PATH_SLUG는 CI/CD 변수의 값입니다. 이는 더 많은 환경을 가진 클러스터/네임스페이스에서 올바른 환경을 조회할 수 있도록 합니다. 이러한 리소스들은 Kubernetes 서비스 설정에서 정의된 네임스페이스에 포함되어야 합니다. 미리 정의된 단계 및 명령어를 사용하는 Auto deploy .gitlab-ci.yml 템플릿을 사용하여 주석을 자동으로 적용할 수 있습니다. 각 프로젝트는 Kubernetes에서 고유한 네임스페이스를 가져야 합니다. 아래 이미지는 Kubernetes 내에서 표시되는 내용을 보여줍니다.

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

    deploy boards Kubernetes Label

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

예제 매니페스트 파일

다음 예제는 배포 보드를 활성화하기 위해 app.gitlab.com/envapp.gitlab.com/app 두 가지의 어노테이션을 사용하는 Kubernetes 매니페스트 배포 파일의 일부입니다:

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}

이러한 어노테이션은 배포, 레플리카 세트 및 팟에 적용됩니다. 레플리카 개수를 변경함으로써 kubectl scale --replicas=3 deploy APPLICATION_NAME -n ${KUBE_NAMESPACE}와 같이 해당 보드에서 인스턴스의 팟을 따를 수 있습니다.

참고: YAML 파일은 정적입니다. 만약 kubectl apply를 사용하여 적용한다면, YAML에서 변수를 바꾸기 전에 프로젝트 및 환경 슬러그를 수동으로 제공하거나 스크립트를 만들어야 합니다.

카나리아 배포

애플리케이션의 새 버전으로 플릿의 작은 부분이 업데이트되는 인기 있는 CI 전략입니다.

카나리아 배포에 대해 더 읽어보세요.

더 읽을거리