GitLab 배포 보드는 Kubernetes에서 실행되는 각 CI 환경의 현재 상태를 한 화면에 모아 보여 주며, 배포의 Pod 상태를 표시합니다. 개발자를 비롯한 팀원은 Kubernetes에 직접 접근하지 않고도 이미 사용하는 워크플로 안에서 롤아웃 진행 상황과 상태를 Pod 단위로 확인할 수 있습니다.

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

배포 보드를 사용하면 다음과 같이 배포를 더 자세히 파악할 수 있습니다.

• 배포가 끝난 시점뿐 아니라 시작부터 추적합니다
• 여러 서버에 걸친 빌드 롤아웃을 지켜봅니다
• 더 세분화된 상태를 확인합니다(Succeeded, Running, Failed, Pending, Unknown)
• 카나리 배포를 참고합니다

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

사각형은 해당 환경과 연결된 Kubernetes 클러스터의 Pod를 나타냅니다. 각 사각형 위에 마우스를 올리면 배포 롤아웃이 진행되는 상태를 볼 수 있습니다. 백분율은 최신 릴리스로 업데이트된 Pod의 비율입니다.

배포 보드는 Kubernetes와 밀접하게 연결되어 있으므로 다음 개념에 익숙해야 합니다.

• Kubernetes Pod
• Kubernetes 레이블
• Kubernetes 네임스페이스
• Kubernetes 카나리 배포

사용 사례#

배포 보드는 특정 환경의 Kubernetes Pod를 시각적으로 표현한 것이므로 사용 사례가 많습니다. 몇 가지를 들면 다음과 같습니다.

• 스테이징에서 실행 중인 것을 프로덕션으로 승격하려 합니다. 환경 목록으로 이동해 스테이징에서 실행 중인 것이 의도한 내용인지 확인한 다음, 프로덕션에 배포하는 수동 job을 선택합니다.
• 배포를 트리거했는데 업그레이드할 컨테이너가 많아 시간이 오래 걸린다는 것을 알고 있습니다(한 번에 X 개 컨테이너만 내리도록 배포 속도도 제한해 두었습니다). 배포가 끝나면 누군가에게 알려야 하므로, 환경 목록으로 이동해 프로덕션 환경을 보고 각 Pod가 교체되는 진행 상황을 실시간으로 확인합니다.
• 프로덕션에 이상이 있다는 보고를 받아 프로덕션 환경을 열어 무엇이 실행 중인지, 배포가 진행 중인지, 멈췄는지, 실패했는지 확인합니다.
• 괜찮아 보이는 MR 이 있지만, 스테이징이 프로덕션에 더 가깝게 구성되어 있어 스테이징에서 실행해 보려고 합니다. 환경 목록으로 이동해 관심 있는 리뷰 앱을 찾고, 스테이징에 배포하는 수동 작업을 선택합니다.

배포 보드 활성화#

특정 환경의 배포 보드를 표시하려면 다음 조건을 갖춰야 합니다.

1. 배포 stage가 있는 환경을 정의해 둡니다.

2. Kubernetes 클러스터가 실행 중이어야 합니다.

   [!note] OpenShift를 사용한다면 DeploymentConfiguration 이 아니라 Deployment 리소스를 사용하는지 확인합니다. 그렇지 않으면 배포 보드가 올바르게 렌더링되지 않습니다. 자세한 내용은 OpenShift 문서와 GitLab 이슈 #4584를 참고합니다.

3. docker 또는 kubernetes 실행기로 GitLab Runner를 구성합니다.

4. 해당 클러스터에 대해 프로젝트의 Kubernetes 통합을 구성합니다. 특히 Kubernetes 네임스페이스는 배포 스크립트에 필요하므로 중요합니다 (KUBE_NAMESPACE 배포 변수로 노출됩니다).

5. app.gitlab.com/env: $CI_ENVIRONMENT_SLUG와 app.gitlab.com/app: $CI_PROJECT_PATH_SLUG Kubernetes 어노테이션이 Deployment, ReplicaSet, Pod에 적용되어 있는지 확인합니다. 여기서 $CI_ENVIRONMENT_SLUG와 $CI_PROJECT_PATH_SLUG는 CI/CD 변수의 값입니다. GitLab은 이 변수로 환경이 여러 개일 수 있는 클러스터·네임스페이스에서 올바른 환경을 찾습니다. 이 리소스들은 Kubernetes 서비스 설정에 정의한 네임스페이스에 있어야 합니다. 사용할 stage와 명령이 미리 정의되어 있고 어노테이션을 자동으로 적용하는 Auto deploy .gitlab-ci.yml 템플릿을 사용할 수 있습니다. 각 프로젝트는 Kubernetes에서도 고유한 네임스페이스를 가져야 합니다. 아래 이미지는 이 내용이 Kubernetes 안에서 어떻게 표시되는지 보여 줍니다.

   GCP로 클러스터를 관리한다면 Workloads > deployment name > Details로 이동하여 GCP에서 직접 배포 세부 정보를 확인할 수 있습니다.

   

앞의 설정을 모두 마치고 파이프라인을 한 번 이상 실행했다면, Operate > Environments 아래의 환경 페이지로 이동합니다.

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

예시 매니페스트 파일#

다음은 배포 보드를 활성화하기 위해 app.gitlab.com/env와 app.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}

어노테이션은 Deployment, ReplicaSet, Pod에 적용됩니다. kubectl scale --replicas=3 deploy APPLICATION_NAME -n ${KUBE_NAMESPACE}와 같이 레플리카 수를 변경하면 보드에서 인스턴스의 Pod를 추적할 수 있습니다.

카나리 배포#

플리트의 일부만 애플리케이션의 새 버전으로 업데이트하는, 널리 쓰이는 CI 전략입니다.

카나리 배포에 대해 자세히 알아봅니다.

더 읽어 보기#

• GitLab Auto deploy
• GitLab CI/CD 변수
• 환경 및 배포
• Kubernetes 배포 예시