• 개요
• 사용 사례
• 배포 보드 활성화하기
  • 예시 manifest 파일
• 카나리아 배포
• 추가 읽을거리

배포 보드 (사용 중단됨)

• GitLab 9.0에서 도입됨.
• GitLab Premium에서 GitLab Free로 이전됨 (13.8).
• GitLab 13.5 및 이전 버전에서 여러 배포로 구성된 앱이 배포 보드에서 중복으로 표시됩니다. 이는 GitLab 13.6에서 수정되었습니다.
• GitLab 13.11 및 이전 버전에서 폴더에있는 환경에서는 배포 보드가 표시되지 않습니다. 이는 GitLab 13.12에서 수정되었습니다.
• GitLab 14.5에서 사용 중단.
• GitLab 15.0에서 Self-managed에서 비활성화됨.

GitLab 배포 보드는 각 CI 환경의 현재 상태와 상태를 표시하여 쿠버네티스에서 실행 중인 각 환경의 상태를 종합적으로 보여줍니다. 개발자 및 팀원들은 이미 사용 중인 워크플로우에서 롤아웃의 진행 상황 및 상태를 케이크 및 걸음 단위로 확인할 수 있으며 쿠버네티스에 대한 액세스가 필요하지 않습니다.

개요

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

• 완료된 시점뿐만 아니라 시작부터 배포를 따라갈 수 있음
• 여러 서버를 통해 빌드의 롤아웃을 확인할 수 있음
• 더 세부적인 상태 정보 (성공, 실행 중, 실패, 보류 중, 알 수 없음)
• 카나리 배포 확인

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

네모 상자는 해당 환경과 관련된 쿠버네티스 클러스터의 파드를 나타냅니다. 각 네모 상자 위에 마우스를 올리면 롤아웃 중인 상태를 확인할 수 있습니다. 백분율은 최신 릴리스로 업데이트 된 파드의 비율을 의미합니다.

배포 보드는 쿠버네티스와 밀접하게 연결되어 있으므로 일부 요구 사항이 있습니다. 특히 다음과 같은 사항에 익숙해져야 합니다:

• 쿠버네티스 파드
• 쿠버네티스 라벨
• 쿠버네티스 네임스페이스
• 쿠버네티스 카나리 배포

사용 사례

배포 보드는 특정 환경에 대한 쿠버네티스 파드의 시각적인 표현이므로 여러 사용 사례가 있습니다. 그중 몇 가지를 살펴보겠습니다:

• 스테이징에서 실행 중인 것을 프로덕션으로 프로모션하려고 합니다. 환경 디렉터리에 이동하여 스테이징에서 실행 중인 것이 예상대로 실행 중인지 확인한 후 매뉴얼 작업을 선택하여 프로덕션으로 배포합니다.
• 배포를 트리거하고 업그레이드 할 컨테이너가 많기 때문에 시간이 오래 걸릴 것으로 예상됩니다 (배포를 하나씩 X개의 컨테이너만 종료하도록 제한했습니다). 그러나 배포가 완료되었을 때 누군가에게 알려주어야 합니다. 따라서 환경 디렉터리으로 이동하여 각 파드가 롤아웃되는 상황을 실시간으로 확인합니다.
• 프로덕션에서 뭔가 이상한 보고를 받았으므로 프로덕션 환경을 확인하여 실행 중인 것을 확인하고, 배포가 진행 중인지, 멈춘 것인지, 실패했는지 확인합니다.
• 좋아 보이는 MR이 있지만 스테이징에서 실행해보고 싶습니다. 스테이징이 프로덕션에 더 가깝게 설정되어 있기 때문에 스테이징으로 배포하려면 환경 디렉터리으로 이동하여 관심 있는 Review App을 찾고 매뉴얼 조치를 선택하여 스테이징으로 배포합니다.

배포 보드 활성화하기

특정 환경의 배포 보드를 표시하려면 다음을 준수해야 합니다:

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

2. 쿠버네티스 클러스터가 작동 중이어야 합니다.

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

5. 배포, 복제 설정 및 파드에 app.gitlab.com/env: $CI_ENVIRONMENT_SLUG와 app.gitlab.com/app: $CI_PROJECT_PATH_SLUG 쿠버네티스 어노테이션이 적용되어 있어야 합니다. 이는 클러스터/네임스페이스에 한 개 이상의 적절한 환경을 찾을 수 있도록하는데 사용됩니다. 이러한 리소스는 쿠버네티스 서비스 설정에서 정의된 네임스페이스에 포함되어야 합니다. 미리 정의된 스테이지 및 명령어를 사용하고 어노테이션을 자동으로 적용하는 자동 배포 .gitlab-ci.yml 템플릿을 사용할 수 있으며, 각 프로젝트는 고유한 네임스페이스를 가져야 합니다. 아래 이미지는 이를 쿠버네티스에서 표시하는 방법을 보여줍니다.

   쿠버네티스 app 라벨을 기반으로 매칭하는 것은 GitLab 12.1에서 제거되었습니다. 이전 이슈를 마이그레이션하려면 필요한 어노테이션을 적용하고 응용 프로그램을 다시 배포해야 합니다(위에서 언급한대로). Auto DevOps를 사용하는 경우 이러한 작업은 자동으로 수행되며 별도 조치가 필요하지 않습니다.

   클러스터를 관리하기 위해 GCP를 사용하는 경우 GCP 자체에서 배포 세부 정보를 확인할 수 있습니다. Workloads > deployment name > Details로 이동합니다:

   

위의 모든 항목이 설정되어 있고 파이프라인이 적어도 한 번 실행된 후에는 Operate > Environments에서 환경 페이지로 이동하십시오.

배포 보드는 기본적으로 표시됩니다. 각 환경 이름 옆의 삼각형을 명시적으로 선택하여 해당 환경을 숨길 수 있습니다.

예시 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}

이러한 주석은 배포, 레플리카 세트 및 파드에 적용됩니다. 레플리카 수를 변경함으로써 kubectl scale --replicas=3 deploy APPLICATION_NAME -n ${KUBE_NAMESPACE}와 같이 새로운 버전의 애플리케이션의 인스턴스에 대한 파드를 보고 따를 수 있습니다.

카나리아 배포

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

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

추가 읽을거리

• GitLab 자동 배포
• GitLab CI/CD 변수
• 환경과 배포
• Kubernetes 배포 예시