배포 보드(사용 중지됨)
- GitLab 9.0에서 소개되었습니다.
- GitLab 13.8에서 GitLab Premium에서 GitLab Free로 이동되었습니다.
- GitLab 13.5 및 이전 버전에서 여러 배포로 구성된 앱은 배포 보드에서 중복으로 표시됩니다. 이는 GitLab 13.6에서 수정되었습니다.
- GitLab 13.11 및 이전 버전에서 폴더 내 환경에 배포 보드가 표시되지 않습니다. 이는 GitLab 13.12에서 수정되었습니다.
- GitLab 14.5에서 사용 중지되었습니다.
- GitLab 15.0에서 Self-managed에서 사용이 중지되었습니다.
certificate_based_clusters라는 기능 플래그를 활성화할 수 있습니다.GitLab 배포 보드는 Kubernetes에서 실행 중인 각 CI 환경의 현재 상태를 통합된 형태로 보여주며, 배포에 관련된 각 Pod의 상태를 표시합니다. 개발자 및 다른 팀원들은 이미 사용 중인 워크플로우에서 롤아웃의 진행 상황과 상태를 Kubernetes에 접근할 필요 없이 확인할 수 있습니다.
개요
배포 보드를 통해 다음과 같은 이점을 얻을 수 있습니다:
- 시작부터 배포를 추적할 수 있음(완료된 후뿐만 아니라)
- 여러 서버에 걸쳐 빌드의 롤아웃을 확인할 수 있음
- 더 정교한 상태 세부 정보(성공, 실행 중, 실패, 보류 중, 알 수 없음)
- Canary 배포 확인
다음은 프로덕션 환경의 배포 보드의 예시입니다.
네모 상자들은 해당 환경에 연결된 Kubernetes 클러스터의 Pod를 나타냅니다. 각 상자 위로 마우스를 올리면 롤아웃 상태를 확인할 수 있습니다. 백분율은 가장 최신 릴리스로 업데이트된 Pod의 백분율입니다.
배포 보드는 Kubernetes와 밀접한 관련이 있기 때문에 몇 가지 필수적인 지식이 필요합니다. 특히 다음과 같은 것에 익숙해져야 합니다:
사용 사례
배포 보드는 특정 환경의 Kubernetes Pod를 시각적으로 나타내기 때문에 다양한 사용 사례가 있습니다. 예를 들면 다음과 같습니다:
- 스테이징에서 실행 중인 내용을 프로덕션으로 홍보하려면 환경 목록에서 스테이징에서 실행 중인 내용을 확인한 후 수동 작업을 선택하여 프로덕션으로 배포합니다.
- 배포를 트리거하고 업그레이드할 컨테이너가 많기 때문에 시간이 걸릴 것으로 예상됩니다(동시에 X개의 컨테이너만 중단하도록 제한했습니다). 그러나 배포가 완료된 시점을 누군가에게 알려야 합니다. 따라서 환경 목록으로 이동하여 각 Pod가 롤아웃되는 실시간 진행 상황을 확인합니다.
- 프로덕션에서 이상한 점이 있다는 보고를 받았으므로, 프로덕션 환경을 확인하여 실행 중인 내용과 배포가 진행 중인지, 멈췄는지 또는 실패했는지 확인합니다.
- 좋아 보이는 MR이 있지만, 스테이징이 프로덕션에 가까운 방식으로 설정되어 있기 때문에 스테이징에서 실행해보고 싶습니다. 따라서 환경 목록으로 이동하여 관심 있는 Review App을 찾고 해당 Review App을 스테이징으로 배포하는 수동 작업을 선택합니다.
배포 보드 활성화
특정 환경에 대한 배포 보드를 표시하려면 다음을 해야합니다:
- 배포 단계가 포함된 환경을 정의해야합니다.
-
Kubernetes 클러스터가 작동 중이어야 합니다.
참고: OpenShift를 사용하는 경우
DeploymentConfiguration대신Deployment리소스를 사용해야 합니다. 그렇지 않으면 배포 보드가 올바르게 렌더링되지 않습니다. 자세한 정보는 OpenShift 문서 및 GitLab 이슈 #4584를 참조하십시오. -
GitLab Runner를 구성하고
docker또는kubernetes실행기를 사용해야합니다. - 프로젝트의 Kubernetes 통합을 클러스터에 구성해야합니다.
Kubernetes 네임스페이스는 배포 스크립트에 필요하므로
해당 네임스페이스의 값을(
KUBE_NAMESPACE배포 변수로 노출) 참조해야합니다. -
배포, 복제본 집합 및 팟에 대한 Kubernetes 주석으로
app.gitlab.com/env: $CI_ENVIRONMENT_SLUG및app.gitlab.com/app: $CI_PROJECT_PATH_SLUG가 적용되어 있어야합니다. 여기서$CI_ENVIRONMENT_SLUG및$CI_PROJECT_PATH_SLUG은 CI/CD 변수의 값입니다. 이는 하나 이상의 클러스터/네임스페이스에서 적절한 환경을 조회할 수 있도록하기 위한 것입니다. 이러한 리소스들은 Kubernetes 서비스 설정에 정의된 네임스페이스에 포함되어야합니다. 미리 정의된 단계 및 명령어를 사용하고 주석을 자동으로 적용하는 자동 배포.gitlab-ci.yml템플릿을 사용할 수 있습니다. 각 프로젝트는 Kubernetes에서 고유한 네임스페이스를 가져야합니다. 아래 이미지는 Kubernetes 내부에서 이러한 것이 표시되는 방법을 보여줍니다.참고: Kubernetes
app라벨을 기반으로 매칭하는 것이 GitLab 12.1에서 제거되었습니다. 마이그레이션하려면 필요한 주석을 적용하고(위 참조) 응용 프로그램을 다시 배포해야합니다. Auto DevOps를 사용하는 경우, 이 과정은 자동으로 수행되므로 별도의 조치가 필요하지 않습니다.GCP를 사용하여 클러스터를 관리하는 경우 Workloads > 배포 이름 > 세부정보로 이동하여 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}와 같이 레플리카 수를 변경하여 보드에서 인스턴스의 팟을 따를 수 있습니다.
참고:
YAML 파일은 정적입니다. kubectl apply를 사용하여 적용하는 경우 YAML 내에서 프로젝트 및 환경 슬러그를 수동으로 제공하거나 적용 전에 YAML 내의 변수를 대체하는 스크립트를 생성해야합니다.
카나리아 배포
소프트웨어의 새 버전으로의 갱신이 소규모의 플릿에만 적용되는 인기있는 CI 전략입니다.
도움말