배포 보드 (폐기 예정)
- Self-managed에서 사용 불가능합니다. GitLab 15.0에서 비활성화됨.
certificate_based_clusters
라는 기능 플래그를 활성화할 수 있습니다.GitLab 배포 보드는 현재 CI 환경에 실행 중인 각각의 pod의 상태를 통합된 형태로 보여줌으로써 Kubernetes에서 실행 중인 배포의 상태를 시각적으로 표시합니다. 개발자 및 다른 팀원들은 쿠버네티스에 액세스할 필요 없이 이미 사용 중인 워크플로우에서 롤아웃의 진행 및 상태, pod별로 확인할 수 있습니다.
개요
배포 보드를 사용하면 다음과 같은 이점을 가질 수 있습니다:
- 실행이 완료될 때까지가 아니라 시작하여 롤아웃을 따라갈 수 있음
- 여러 서버 간에 빌드의 롤아웃을 지켜볼 수 있음
- 보다 세부적인 상태 정보 (완료됨, 실행 중, 실패, 대기 중, 알 수 없음)
- Canary 배포 확인
다음은 프로덕션 환경의 배포 보드의 예시입니다.
네모 상자들은 해당 환경과 관련된 Kubernetes 클러스터 내의 pod를 나타냅니다. 각 상자 위로 마우스를 올리면 롤아웃 중인 배포의 상태를 볼 수 있습니다. 백분율은 최신 릴리스로 업데이트된 pod의 백분율을 의미합니다.
배포 보드가 Kubernetes와 강력하게 결합되어 있으므로 일부 필요한 지식이 필요합니다. 특히 다음과 같은 사항에 익숙해져야 합니다:
사용 사례
배포 보드는 특정 환경의 Kubernetes pod의 시각적 표현이므로 여러 가지 사용 사례가 있습니다. 일부 사용 사례를 들자면:
- 스테이징에서 실행 중인 내용을 프로덕션으로 홍보하려면 환경 목록으로 이동하여 스테이징에서 실행 중인 것이 예상한 것인지 확인한 후 수동 작업을 선택하여 프로덕션으로 배포합니다.
- 배포를 시작하고 여러 컨테이너를 업그레이드해야 하는 경우, 조금 시간이 걸릴 것으로 알고 있습니다 (업그레이드를 X개의 컨테이너만 한 번에 중지했습니다). 그러나 배포가 완료되었을 때 누군가에게 알려야 하므로 환경 목록으로 이동하여 프로덕션 환경을 보고 각 pod가 롤아웃되는 상황을 실시간으로 확인할 수 있습니다.
- 프로덕션에서 이상한 것이 있다는 보고를 받았으므로 프로덕션 환경으로 이동하여 현재 실행 중인 내용을 확인하고 배포가 진행 중인지, 멈춰 있는지, 실패했는지 확인합니다.
- 좋아 보이는 MR이 있지만 스테이징에서 실행해야 한다고 생각됩니다. Review App를 찾아 스테이징으로 배포하는 수동 조치를 선택합니다.
배포 보드 활성화
특정 환경에 대한 배포 보드를 표시하려면 다음을 해야 합니다:
-
배포 단계가 정의된 환경을 가져야 합니다.
-
Kubernetes 클러스터가 구동 중이어야 합니다.
OpenShift를 사용하는 경우DeploymentConfiguration
대신Deployment
리소스를 사용해야 합니다. 그렇지 않으면 배포 보드가 올바르게 렌더링되지 않습니다. 자세한 정보는 OpenShift 문서 및 GitLab issue #4584를 참조하십시오. - 프로젝트의 GitLab Runner를
docker
또는kubernetes
executor로 구성해야 합니다. - 프로젝트에 대한 Kubernetes 통합을 클러스터에 구성해야 합니다. 특히 Kubernetes 네임스페이스는 배포 스크립트에 필요합니다 (
KUBE_NAMESPACE
배포 변수로 노출됨). -
Kubernetes 주석인
app.gitlab.com/env: $CI_ENVIRONMENT_SLUG
와app.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로 이동하여 배포 세부 정보를 볼 수 있습니다:
위 항목들이 모두 설정되고 파이프라인이 최소 한 번 실행된 후에는 운영 > 환경 페이지로 이동하면 배포 보드가 기본적으로 표시됩니다. 해당 환경 이름 옆의 삼각형을 명시적으로 선택하여 숨길 수 있습니다.
예제 매니페스트 파일
다음 예제는 배포 보드를 활성화하기 위해 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}
와 같이 해당 보드에서 인스턴스의 팟을 따를 수 있습니다.
참고:
YAML 파일은 정적입니다. 만약 kubectl apply
를 사용하여 적용한다면, YAML에서 변수를 바꾸기 전에 프로젝트 및 환경 슬러그를 수동으로 제공하거나 스크립트를 만들어야 합니다.
카나리아 배포
애플리케이션의 새 버전으로 플릿의 작은 부분이 업데이트되는 인기 있는 CI 전략입니다.