GitLab 배포 보드는 Kubernetes에서 실행되는 각 CI 환경의 현재 상태와 상태에 대한 통합 보기를 제공하여 배포의 파드 상태를 표시합니다. 개발자와 다른 팀원은 Kubernetes에 액세스할 필요 없이 이미 사용하는 워크플로우에서 파드별로 롤아웃의 진행 상황과 상태를 확인할 수 있습니다.

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

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

• 완료되었을 때가 아니라 처음부터 배포를 추적
• 여러 서버에 걸쳐 빌드 롤아웃 모니터링
• 더 세밀한 상태 세부 사항 (Succeeded, Running, Failed, Pending, Unknown)
• 카나리 배포 확인

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

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

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

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

사용 사례#

배포 보드는 특정 환경의 Kubernetes 파드를 시각적으로 표현하므로 많은 사용 사례가 있습니다. 몇 가지 예를 들면:

• 스테이징에서 실행되는 것을 프로덕션으로 프로모션하려는 경우. 환경 목록으로 이동하여 스테이징에서 실행되는 것이 예상대로인지 확인한 다음 프로덕션에 배포하는 수동 작업을 선택합니다.
• 배포를 트리거했는데 업그레이드해야 할 컨테이너가 많아 시간이 걸린다는 것을 알고 있는 경우(한 번에 X개의 컨테이너만 중단하도록 배포를 제한했습니다). 하지만 배포가 완료되었을 때 누군가에게 알려야 하므로 환경 목록으로 이동하여 프로덕션 환경을 보고 각 파드가 롤링될 때 실시간 진행 상황을 확인합니다.
• 프로덕션에 이상한 것이 있다는 보고를 받아 프로덕션 환경을 보고 실행 중인 것이 무엇인지, 배포가 진행 중인지, 중단되었는지, 실패했는지 확인합니다.
• 좋아 보이는 MR이 있지만 스테이징이 프로덕션과 더 가까운 방식으로 설정되어 있어 스테이징에서 실행하려는 경우. 환경 목록으로 이동하여 관심 있는 리뷰 앱을 찾고 스테이징에 배포하는 수동 작업을 선택합니다.

배포 보드 활성화#

특정 환경에 대한 배포 보드를 표시하려면:

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

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 어노테이션이 배포, 레플리카 세트 및 파드에 적용되어 있는지 확인합니다. 여기서 $CI_ENVIRONMENT_SLUG와 $CI_PROJECT_PATH_SLUG는 CI/CD 변수의 값입니다. GitLab은 이러한 변수를 사용하여 하나 이상의 클러스터/네임스페이스에서 적절한 환경을 조회합니다. 이러한 리소스는 Kubernetes 서비스 설정에 정의된 네임스페이스에 포함되어야 합니다. 미리 정의된 단계와 명령이 있고 어노테이션을 자동으로 적용하는 Auto deploy .gitlab-ci.yml 템플릿을 사용할 수 있습니다. 각 프로젝트는 Kubernetes에서도 고유한 네임스페이스를 가져야 합니다. 아래 이미지는 이것이 Kubernetes 내부에서 어떻게 표시되는지 보여줍니다.

   GCP를 사용하여 클러스터를 관리하는 경우 워크로드 > 배포 이름 > 세부 사항으로 이동하여 GCP 자체에서 배포 세부 사항을 볼 수 있습니다:

   

이러한 이전 지침이 모두 설정되고 파이프라인이 최소 한 번 실행되면 운영 > 환경 아래의 환경 페이지로 이동합니다.

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

예시 매니페스트 파일#

다음 예는 배포 보드를 활성화하기 위해 두 어노테이션 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}

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

카나리 배포#

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

카나리 배포에 대해 자세히 알아보세요.

추가 읽기#

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