배포 보드 (사용 중단)
- 자체 관리에서 비활성화됨 GitLab 15.0에서.
자체 관리 GitLab에서는 기본적으로 이 기능이 제공되지 않습니다. 사용 가능하게 하려면, 관리자가
certificate_based_clusters
라는 기능 플래그를 활성화할 수 있습니다.GitLab 배포 보드는 각 CI 환경의 현재 상태와 건강 상태를 통합적으로 표시합니다.
Kubernetes에서 실행 중인 배포의 파드 상태를 보여줍니다. 개발자와 다른 팀원들은 Kubernetes에 접근할 필요 없이 기존에 사용 중인 워크플로우에서 롤아웃의 진행 상황과 상태를 파드별로 볼 수 있습니다.
개요
배포 보드를 사용하면 다음과 같은 이점으로 배포에 대한 더 많은 통찰력을 얻을 수 있습니다:
- 배포가 완료될 때만이 아니라 시작부터 따라가는 것
- 여러 서버에 걸쳐 빌드의 롤아웃을 지켜보는 것
- 더 세분화된 상태 세부정보 (성공, 실행 중, 실패, 대기 중, 알 수 없음)
- 카나리 배포 보기
다음은 프로덕션 환경의 배포 보드 예제입니다.
각 정사각형은 주어진 환경과 연관된 Kubernetes 클러스터의 파드를 나타냅니다. 각 정사각형 위에 마우스를 올리면 배포 롤아웃의 상태를 볼 수 있습니다. 퍼센트는 최신 릴리스로 업데이트된 파드의 비율입니다.
배포 보드는 Kubernetes와 밀접하게 연결되어 있으므로 몇 가지 필수 지식이 필요합니다. 특히, 다음에 익숙해야 합니다:
사용 사례
배포 보드는 특정 환경에 대한 Kubernetes 파드의 시각적 표현이기 때문에 많은 사용 사례가 있습니다. 몇 가지를 이름을 붙이면:
- 스테이징에서 실행 중인 것을 프로덕션으로 홍보하고 싶습니다. 환경 목록으로 이동하여 스테이징에서 실행 중인 것이 예상한 것인지 확인한 후, 프로덕션에 배포할 수동 작업을 선택합니다.
- 배포를 트리거하고 업그레이드할 컨테이너가 많은 경우 시간이 오래 걸림을 알고 있습니다 (X개의 컨테이너를 한 번에 중단하도록 배포를 조절했습니다). 하지만 언제 배포되었는지 알려야 하므로 환경 목록으로 이동하여 프로덕션 환경에서 각 파드가 롤아웃될 때 실시간으로 진행 상황을 확인합니다.
- 프로덕션에서 뭔가 이상하다는 보고서를 받았으므로 프로덕션 환경을 확인하여 실행 중인 것이 무엇인지, 배포가 진행 중인지, 중단되었는지 또는 실패했는지 확인합니다.
- 잘 보이는 MR이 있지만 스테이징에서 실행하고 싶습니다. 왜냐하면 스테이징이 프로덕션에 더 가까운 방식으로 설정되어 있기 때문입니다. 환경 목록으로 이동하여 관심 있는 검토 앱을 찾고, 이를 스테이징에 배포하기 위한 수동 작업을 선택합니다.
배포 보드 활성화
특정 환경의 배포 보드를 표시하려면 다음을 수행해야 합니다:
-
배포 단계가 포함된 환경을 정의해야 합니다.
-
Kubernetes 클러스터가 실행 중이어야 합니다.
OpenShift를 사용 중인 경우DeploymentConfiguration
대신Deployment
리소스를 사용해야 하며, 그렇지 않으면 배포 보드가 올바르게 렌더링되지 않습니다. 자세한 내용은 OpenShift 문서와 GitLab 문제 #4584를 참조하세요. -
docker
또는kubernetes
실행기로 GitLab Runner를 구성합니다. -
클러스터에 대한 Kubernetes 통합을 프로젝트에 구성합니다. Kubernetes 네임스페이스는 배포 스크립트에 필요하므로 특히 중요합니다(배포 변수로
KUBE_NAMESPACE
에 의해 노출됨). -
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 변수의 값입니다. 이는 클러스터/네임스페이스에서 올바른 환경을 조회할 수 있도록 하며, 하나 이상의 환경이 있을 수 있습니다. 이러한 리소스는 Kubernetes 서비스 설정에서 정의된 네임스페이스에 포함되어야 합니다. 미리 정의된 단계와 명령이 있는 자동 배포.gitlab-ci.yml
템플릿을 사용할 수 있으며, 자동으로 주석을 적용합니다. 각 프로젝트는 Kubernetes에서 고유한 네임스페이스를 가져야 합니다. 아래 이미지는 Kubernetes 내에서 이와 같은 모습으로 표시되는 방법을 보여줍니다.GCP를 사용하여 클러스터를 관리하는 경우 Workloads > 배포 이름 > 세부정보로 이동하여 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}
주석은 배포, 복제 세트 및 포드에 적용됩니다. 복제 수를 변경하면 kubectl scale --replicas=3 deploy APPLICATION_NAME -n ${KUBE_NAMESPACE}
와 같이 보드에서 인스턴스의 포드를 추적할 수 있습니다.
kubectl apply
를 사용하여 적용하는 경우 프로젝트 및 환경 슬러그를 수동으로 제공해야 하거나 적용하기 전에 YAML에서 변수를 바꾸는 스크립트를 만들어야 합니다.카나리 배포
애플리케이션의 새로운 버전으로 플릿의 작은 부분이 업데이트되는 인기 있는 CI 전략입니다.