구성 동기화를 통한 안전한 출시

이 문서에서는 클러스터 운영자와 플랫폼 관리자가 구성 동기화를 사용하여 여러 환경에서 안전하게 변경사항을 적용하는 방법을 설명합니다. 이 방식은 모든 환경에 동시에 영향을 주는 오류를 방지하는 데 도움이 됩니다.

구성 동기화에서는 Git 저장소에 저장된 파일을 사용하여 단일 클러스터, 멀티 테넌트 클러스터, 멀티 클러스터 Kubernetes 구성을 관리할 수 있습니다.

구성은 다음을 포함한 몇 가지 사항을 나타낼 수 있습니다.

NetworkPolicies 리소스, DaemonSets 리소스 또는 RoleBindings 리소스와 같은 표준 GKE 객체
구성 커넥터를 통하는 Compute Engine 인스턴스 또는 Cloud SQL 데이터베이스 같은 Google Cloud 리소스
정책 컨트롤러를 통하는 구성 자체에 대한 제약조건

구성 동기화는 특히 Google Kubernetes Engine(GKE) Enterprise 버전을 기반으로 빌드하는 플랫폼을 실행하는 데 필요한 구성, 정책, 워크로드(예: 보안 에이전트, 모니터링 에이전트, 인증서 관리자)를 배포하는 데 적합합니다.

구성 동기화를 사용하여 사용자용 애플리케이션을 배포할 수 있지만 이 출시 수명 주기를 앞에서 언급한 관리 워크로드의 출시 수명 주기에 연결하지 않는 것이 좋습니다. 대신 애플리케이션 팀이 출시 일정을 관리할 수 있도록 지속적 배포 도구와 같은 애플리케이션 배포 전용 도구를 사용하세요.

구성 동기화는 여러 요소를 관리할 수 있는 강력한 제품이므로 중대한 영향을 미치는 오류를 방지하기 위해 가드레일이 필요합니다. 이 문서에서는 가드레일을 만드는 몇 가지 방법을 설명합니다. 첫 번째 섹션에서는 단계적 출시에 대해 다루고 두 번째 섹션에서는 테스트 및 유효성 검사를 중점적으로 다룹니다. 세 번째 섹션에서는 배포를 모니터링하는 방법을 설명합니다.

구성 동기화로 단계적 출시 구현

GKE Enterprise 사용자가 일반적으로 사용하는 멀티 클러스터 환경에서는 모든 클러스터에 동시에 구성 변경을 적용하지 않는 것이 좋습니다. 단계적 출시인 클러스터별 클러스터는 모든 오류의 잠재적 영향을 줄이기 때문에 훨씬 안전합니다.

구성 동기화로 단계적 출시를 구현하는 방법에는 여러 가지가 있습니다.

Git 커밋 또는 태그를 사용하여 클러스터에 원하는 변경사항을 수동으로 적용
Git 분기를 사용하여 변경사항이 병합될 때 자동으로 변경사항 적용. 서로 다른 클러스터 그룹에 서로 다른 분기를 사용할 수 있습니다.
ClusterSelector 및 NamespaceSelector 객체를 사용하여 클러스터 또는 네임스페이스의 하위 그룹에 변경사항을 선택적으로 적용

단계적 출시의 모든 방법은 장단점이 있습니다. 다음 표는 어떤 방법을 동시에 사용할 수 있는지를 보여줍니다.

호환성	Git 커밋 또는 태그	Git 분기	클러스터 선택기	네임스페이스 선택기
Git 커밋 또는 태그		호환되지 않음	호환 가능	호환 가능
Git 분기	호환되지 않음		호환 가능	호환 가능
클러스터 선택기	호환 가능	호환 가능		호환 가능
네임스페이스 선택기	호환 가능	호환 가능	호환 가능

다음 결정 트리는 단계적 출시 방법 중 하나를 사용할 시기를 결정하는 데 도움이 됩니다.

출시 방법의 결정 트리

Git 커밋 또는 태그 사용

다른 단계적 출시 방법과 달리 Git 커밋 또는 태그 사용은 최대한의 제어를 제공하는 가장 안전한 방법입니다. 콘솔에서 Google Cloud 콘솔의 구성 동기화 페이지를 사용하여 여러 클러스터를 동시에 업데이트할 수 있습니다. 이 방법은 클러스터에 변경사항을 하나씩 적용하고 적용 시기를 정확히 제어하려는 경우에 사용합니다.

이 방법에서는 각 클러스터를 저장소의 특정 버전(커밋 또는 태그)에 '고정'합니다. 이것은 Git 커밋을 컨테이너 이미지 태그로 사용하는 것과 비슷합니다. RootSync 또는 RepoSync 커스텀 리소스의 spec.git.revision 필드에 커밋, 태그 또는 해시를 지정하여 이 메서드를 구현합니다.

Kustomize와 같은 도구를 사용하여 RootSync 또는 RepoSync 커스텀 리소스를 관리하는 경우 출시에 필요한 수동 작업량을 줄일 수 있습니다. 이러한 도구를 사용하면 한 위치에서 revision 매개변수를 변경한 다음 선택한 순서와 속도에 따라 새 RootSync 또는 RepoSync 커스텀 리소스를 클러스터에 선택적으로 적용하면 됩니다.

또한 Google Cloud 콘솔을 사용하여 동일한 Fleet에 속하는 여러 클러스터의 revision 매개변수를 동시에 업데이트할 수 있습니다. 하지만 구성을 업데이트하는 자동화 시스템이 있는 경우 Google Cloud 콘솔을 사용하여 구성을 변경하지 않는 것이 좋습니다.

예를 들어 다음 RootSync 정의는 1.2.3 태그를 사용하도록 구성 동기화를 구성합니다.

apiVersion: configsync.gke.io/v1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-sync-system
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: git@example.com:gke/config-sync.git
    revision: 1.2.3
    auth: ssh

이 구성을 클러스터에 적용하면 구성 동기화는 example.com:gke/config-sync.git 저장소의 1.2.3 태그를 사용합니다.

클러스터를 업데이트하려면 spec.git.revision 필드를 클러스터의 새 값으로 변경합니다. 이렇게 하면 업데이트할 클러스터와 업데이트할 시기를 정의할 수 있습니다. 변경사항을 롤백해야 하는 경우 spec.git.revision 필드를 이전 값으로 다시 변경합니다.

다음 다이어그램은 이 방법의 출시 프로세스를 보여줍니다. 먼저 구성 동기화 저장소에 대한 변경사항을 커밋한 다음 모든 클러스터에서 RootSync 정의를 업데이트합니다.

Git 커밋 및 태그의 출시 프로세스.

다음과 같이 하는 것을 권장합니다.

태그 대신 Git 커밋 ID를 사용합니다. Git의 작동 방식으로 인해 절대 변경되지 않을 것이라는 보장이 있습니다. 예를 들어 git push --force는 구성 동기화가 사용하는 커밋을 변경할 수 없습니다. 이 접근법은 감사 목적과 로그에서 사용 중인 커밋을 추적하는 데 유용합니다. 또한 태그와 달리 ID를 커밋하기 위한 추가 단계가 없습니다.
Git 커밋 ID 대신 Git 태그를 사용하려는 경우 보호를 지원하는 Git 솔루션을 사용하는 경우 태그를 보호할 수 있습니다.
동시에 여러 클러스터를 업데이트하려는 경우 Google Cloud 콘솔에서 업데이트할 수 있습니다. 한 번에 여러 클러스터를 업데이트하려면 동일한 Fleet의 일부여야 하며 동일한 프로젝트에 있어야 합니다.

Git 분기 사용

Git 저장소에 병합되는 즉시 클러스터에 변경사항을 적용하려면 커밋 또는 태그 대신 Git 브랜치를 사용하도록 구성 동기화를 구성합니다. 이 방법을 사용하면 Git 저장소에서 여러 개의 장기적 브랜치를 만들고 여러 클러스터에서 구성 동기화를 구성하여 서로 다른 브랜치에서 구성을 읽을 수 있습니다.

예를 들어 단순한 패턴에는 다음과 같은 두 개의 분기가 있습니다.

비프로덕션 클러스터의 staging 분기
프로덕션 클러스터의 main 분기

비프로덕션 클러스터의 경우 spec.git.branch 필드를 staging으로 설정하여 RootSync 또는 RepoSync 객체를 만듭니다. 프로덕션 클러스터의 경우 spec.git.branch 매개변수를 main로 설정하여 RootSync 또는 RepoSync 객체를 만듭니다.

예를 들어 다음 RootSync 정의는 main 브랜치를 사용하도록 구성 동기화를 구성합니다.

apiVersion: configsync.gke.io/v1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-sync-system
spec:
  git:
    repo: git@example.com:gke/config-sync.git
    branch: main
    auth: ssh

다음 다이어그램은 이 방법의 출시 프로세스를 보여줍니다.

Git 분기의 출시 프로세스

3개 이상의 분기를 사용하거나 환경 이외의 다른 대상에 매핑된 분기를 사용하여 이 패턴을 특정 요구사항에 맞게 조정할 수 있습니다. 변경사항을 롤백해야 하는 경우 git revert 명령어를 사용하여 동일한 분기에서 새 커밋을 만들어 이전 커밋에서 변경된 사항을 되돌립니다.

다음과 같이 하는 것을 권장합니다.

여러 클러스터를 처리할 때는 프로덕션 클러스터와 비프로덕션 클러스터를 구분하는 데 도움이 되도록 두 개 이상의 Git 분기를 사용합니다.
대부분의 Git 솔루션에서는 보호된 분기 기능을 사용하여 해당 분기의 삭제 또는 검토되지 않은 변경사항을 방지할 수 있습니다. 자세한 내용은 GitHub, GitLab, Bitbucket 문서를 참조하세요.

ClusterSelector 및 NamespaceSelector 객체 사용

Git 분기는 결국 모두 동일한 정책을 적용하려는 여러 클러스터에 걸쳐 변경사항을 단계적으로 출시하는 좋은 방법입니다. 그러나 클러스터 또는 네임스페이스의 하위 집합에만 변경사항을 출시하려면 ClusterSelector 및 NamespaceSelector 객체를 사용합니다. 이러한 객체의 목표는 비슷하며, 즉 특정 라벨이 있는 클러스터 또는 네임스페이스에만 객체를 적용할 수 있습니다.

예를 들면 다음과 같습니다.

ClusterSelector 객체를 사용하면 다양한 규정 준수 체제에 대해 해당 객체가 위치한 국가에 따라 클러스터에 다른 정책을 적용할 수 있습니다.
NamespaceSelector 객체를 사용하면 내부 팀과 외부 계약자가 사용하는 네임스페이스에 다른 정책을 적용할 수 있습니다.

ClusterSelector 및 NamespaceSelector 객체를 사용하면 다음과 같은 고급 테스트 및 출시 방법을 구현할 수도 있습니다.

정책의 카나리아 릴리스: 소규모의 클러스터 및 네임스페이스의 하위 집합에 새 정책을 배포하여 장시간의 정책 효과를 연구합니다.
A/B 테스트: 동일한 정책의 여러 버전을 다른 클러스터에 배포하여 정책 버전의 영향을 조사한 다음 어디에나 배포할 최적의 버전을 선택합니다.

예를 들어 여러 프로덕션 클러스터가 있는 조직을 가정해 보겠습니다. 플랫폼팀에서 이미 Cluster 및 ClusterSelector 객체를 사용하여 프로덕션 클러스터의 두 범주인 canary-prod 및 prod를 만들었습니다(ClusterSelector 사용 참조).

플랫폼팀은 각 네임스페이스가 속한 팀을 파악하기 위해 네임스페이스에 팀 라벨의 존재를 시행하도록 정책 컨트롤러를 사용하여 정책을 출시하려고 합니다. 이미 테스트 실행 모드에서 이 정책의 버전을 출시했으며 이제 소수의 클러스터에 이 정책을 적용하고자 합니다. 그들은 ClusterSelector 객체를 사용하여 서로 다른 클러스터에 적용되는 두 개의 서로 다른 K8sRequiredLabels 리소스를 만듭니다.

K8sRequiredLabels 리소스는 prod 유형의 클러스터에 적용되며, enforcementAction 매개변수를 dryrun으로 설정합니다.

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: ns-must-have-team
  annotations:
    configmanagement.gke.io/cluster-selector: prod
Spec:
  enforcementAction: dryrun
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Namespace"]
  parameters:
    labels:
      - key: "team"

K8sRequiredLabels 리소스는 enforcementAction 매개변수 없이 canary-prod 유형의 클러스터에 적용됩니다. 즉, 정책이 실제로 적용됩니다.

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: ns-must-have-team
  annotations:
    configmanagement.gke.io/cluster-selector: canary-prod
spec:
  match:
    kinds:
      - apiGroups: [""]
    kinds: ["Namespace"]
  parameters:
    labels:
      - key: "team"

configmanagement.gke.io/cluster-selector 주석을 사용하면 팀은 canary-prod 유형의 클러스터에서만 정책을 적용하여 의도치 않은 부작용이 전체 프로덕션 Fleet로 확산되지 않도록 할 수 있습니다. 정책 컨트롤러의 테스트 실행 기능에 대한 자세한 내용은 제약조건 만들기를 참조하세요.

다음과 같이 하는 것을 권장합니다.

클러스터 또는 네임스페이스의 하위 집합에 구성 변경사항을 무기한으로 적용해야 하는 경우에는 ClusterSelector 및 NamespaceSelector 객체를 사용합니다.
선택기를 사용하여 변경사항을 출시하는 경우 매우 신중해야 합니다. Git 커밋을 사용하는 경우 클러스터별로 출시하므로 한 번에 하나의 클러스터에만 오류가 발생합니다. 하지만 Git 분기를 사용하면 오류가 해당 분기를 사용하는 모든 클러스터에 영향을 줄 수 있습니다. 선택기를 사용하면 오류가 한 번에 모든 클러스터에 영향을 미칠 수 있습니다.

검토, 테스트, 유효성 검사 구현

구성 동기화의 한 가지 이점은 Kubernetes 리소스, 클라우드 리소스, 정책 등 모든 요소를 선언적으로 관리한다는 것입니다. 즉 소스 제어 관리 시스템의 파일은 리소스(구성 동기화의 경우 Git 파일)를 나타냅니다. 이 특성을 통해 애플리케이션의 소스 코드에 이미 사용 중인 개발 워크플로(검토 및 자동 테스트)를 구현할 수 있습니다.

검토 구현

구성 동기화는 Git를 기반으로 하므로 선호하는 Git 솔루션을 사용하여 구성 동기화 저장소를 호스팅할 수 있습니다. Git 솔루션에는 구성 동기화 저장소의 변경사항을 검토하는 데 사용할 수 있는 코드 검토 기능이 있을 수 있습니다.

저장소 변경사항을 검토하는 권장사항은 다음과 같이 일반 코드 검토와 동일합니다.

트렁크 기반 개발을 연습합니다.
소규모 배치로 작업합니다.
동시에 또는 적어도 즉시 코드 검토를 수행하도록 합니다.
변경을 검토하고 승인하는 사람이 변경을 제안하는 사람과 동일하지 않아야 합니다.

구성 동기화 코드베이스의 민감도를 감안하여 가능한 경우 Git 솔루션에 다음 구성을 만드는 것이 좋습니다.

클러스터에서 직접 사용되는 분기를 보호합니다. GitHub, GitLab, Bitbucket 문서를 참조하세요. GitLab을 사용하면 태그를 보호할 수도 있습니다.
분기를 보호한 후 변경사항을 병합하는 데 필요한 승인을 세분화할 수 있습니다.
- GitHub에서 필수 검토를 사용 설정합니다.
- GitLab의 경우 코드 소유자를 사용하여 파일 또는 디렉터리별로 승인 권한을 위임합니다. 병합 요청 승인을 사용하면 여러 팀의 다른 사용자가 요청이 병합되기 전에 승인하도록 할 수 있습니다.
- Bitbucket에서 기본 평가자와 기본 병합 검사를 결합합니다. 선택 사항으로 Atlassian Marketplace에서 제공되는 Bitbucket 서버용 코드 소유자 플러그인을 사용하여 저장소의 하위 섹션에 대한 변경사항을 승인할 수 있는 사용자를 제어할 수 있습니다.

이러한 다양한 기능을 사용하여 코드베이스의 각 변경 요청에 대한 승인을 적용할 수 있습니다. 예를 들어 최소한 플랫폼팀 구성원(클러스터 전체를 운영하는 사람)과 보안팀의 구성원(보안 정책 정의 및 구현을 책임지는 사람)에게 각 변경사항에 대해 승인을 받을 수 있습니다.

다음과 같이 하는 것을 권장합니다.

저장소에 동료 검토를 적용하고 클러스터에서 사용되는 Git 브랜치를 보호합니다.

자동 테스트 구현

코드베이스 작업 시 일반적인 권장사항은 지속적 통합을 구현하는 것입니다. 즉, 변경 요청이 생성되거나 업데이트될 때 실행되도록 자동화된 테스트를 구성합니다. 자동화된 테스트는 사람이 변경 요청을 검토하기 전에 많은 오류를 포착할 수 있습니다. 이는 개발자를 위해 피드백 루프를 강화합니다. 구성 동기화 저장소에 대해 동일한 도구를 사용하여 동일한 아이디어를 구현할 수 있습니다.

예를 들어 새 변경사항에 대해 nomos vet 명령어를 자동으로 실행하는 것이 좋습니다. 이 명령어는 구성 동기화 저장소의 구문이 유효한지 확인합니다. 구성 유효성 검사 튜토리얼에 따라 Cloud Build를 사용하여 이 테스트를 구현할 수 있습니다. Cloud Build를 다음 옵션과 통합할 수 있습니다.

Bitbucket(빌드 트리거 사용)
GitHub(Google Cloud Build GitHub 애플리케이션 사용). 빌드 트리거는 GitHub에서도 사용할 수 있지만 GitHub 애플리케이션을 우선적으로 활용하는 통합 방법입니다.

구성 유효성 검사 튜토리얼에서 볼 수 있듯이 컨테이너 이미지를 사용하여 테스트를 수행합니다. 따라서 Cloud Build 뿐만 아니라 컨테이너를 실행하는 모든 지속적 통합 솔루션에서 테스트를 구현할 수 있습니다.

피드백 루프를 더 강화하기 위해 해당 사용자에게 nomos vet 명령어를 Git 커밋 전 후크로 실행하도록 요청할 수 있습니다. 한 가지 주의해야 할 점은 일부 사용자가 구성 동기화에서 관리하는 Kubernetes 클러스터에 액세스하지 못할 수 있으며 워크스테이션에서 전체 유효성 검사를 실행하지 못할 수 있다는 점입니다. nomos vet --clusters "" 명령어를 실행하여 의미 체계 및 구문 검사로 유효성 검사를 제한합니다.

다음과 같이 하는 것을 권장합니다.

지속적 통합 파이프라인에서 테스트를 구현하세요.
제안된 모든 변경사항에 대해 최소한 nomos vet 명령어는 실행하도록 합니다.

출시 모니터링

이 문서에서 다루는 모든 가드레일을 구현하더라도 오류가 발생할 수 있습니다. 다음은 일반적인 두 가지 오류 유형입니다.

구성 동기화 자체에는 문제를 일으키지 않지만 워크로드가 제대로 작동하지 못하는 오류(예: 워크로드의 구성요소가 통신하는 것을 방해하는 지나치게 제한적인 NetworkPolicy)
잘못된 Kubernetes 매니페스트 또는 허용 컨트롤러에서 거부된 객체 등 구성 동기화가 클러스터에 변경사항을 적용할 수 없는 오류 앞서 설명한 방법은 이러한 오류를 대부분 발견할 것입니다.

앞의 첫 번째 글머리 기호에 설명된 오류를 감지하려면 각 워크로드의 상태를 파악해야 하므로 구성 동기화 수준에서는 거의 불가능합니다. 따라서 애플리케이션이 오작동하면 이를 알리는 기존 모니터링 시스템에서 이러한 오류를 감지하는 것이 가장 좋습니다.

가드레일을 모두 구현한 경우에 드물지만 두 번째 글머리 기호에 설명된 오류를 감지하려면 특정 설정이 필요합니다. 기본적으로 구성 동기화는 로그에 오류를 작성합니다(기본적으로 Cloud Logging에서 확인할 수 있음). 구성 동기화 Google Cloud 콘솔 페이지에도 오류가 표시됩니다. 로그나 콘솔은 보통 오류를 감지하기에 충분하지 않습니다. 항상 모니터링하지 않기 때문입니다. 오류 감지를 자동화하는 가장 간단한 방법은 클러스터에 오류가 있는지 알려주는 nomos status 명령어를 실행하는 것입니다.

또한 오류 자동 알림을 사용하여 고급 솔루션을 설정할 수도 있습니다. 구성 동기화는 Prometheus 형식의 측정항목을 노출합니다. 자세한 내용은 구성 동기화 모니터링을 참조하세요.

모니터링 시스템에 구성 동기화 측정항목이 있으면 gkeconfig_monitor_errors 측정항목이 0보다 클 때 알리는 알림을 만듭니다. 자세한 내용은 Cloud Monitoring의 알림 정책 관리 또는 Prometheus의 알림 규칙을 참조하세요.

구성 동기화를 사용한 안전한 출시에 대한 메커니즘 요약

다음 표에는 이 문서의 앞부분에서 설명한 다양한 메커니즘이 요약되어 있습니다. 이러한 메커니즘 중 어느 것도 배타적이지 않습니다. 일부 또는 전부를 다른 목적으로 사용할 수 있습니다.

메커니즘	장점	단점	사용 사례
Git 커밋 ID 및 태그	특정 Git 커밋 ID 또는 태그를 사용하여 적용될 클러스터 변경사항을 정밀하게 제어합니다.	클러스터 간의 장기적인 차이에 Git 커밋 ID나 태그를 사용하지 마세요. 클러스터 선택기를 사용하는 것이 좋습니다.	모든 클러스터는 `12345` Git 커밋을 적용하도록 구성됩니다. 테스트할 새 커밋 `abcdef`를 사용하여 변경합니다. 이 새 커밋을 사용하여 변경사항의 유효성을 검사하도록 단일 클러스터 구성을 변경합니다.
Git 분기	동일한 변경사항을 여러 환경에 적용하려면 여러 Git 분기를 사용합니다.	클러스터 간의 장기적 차이에 여러 개의 Git 분기를 사용하지 마세요. 분기가 크게 갈리며 다시 병합하기가 어렵습니다.	먼저 스테이징 분기에서 변경사항을 병합합니다. 그러면 스테이징 클러스터가 수령합니다. 그런 다음 마스터 분기의 변경사항을 병합하면 프로덕션 클러스터가 수령합니다.
클러스터 선택기 및 네임스페이스 선택기	클러스터와 네임스페이스의 장기적 차이에 선택기를 사용합니다.	여러 환경에 걸친 단계적 출시에는 선택기를 사용하지 마세요. 스테이징에서 먼저 수정사항을 테스트한 다음 프로덕션에 배포하려면 별도의 Git 분기를 사용합니다.	애플리케이션팀에 개발 클러스터에 대한 전체 액세스 권한이 필요하지만 프로덕션 클러스터에 대한 읽기 전용 액세스 권한이 있을 경우에는 `ClusterSelector` 객체를 사용하여 관련 클러스터에 올바른 RBAC 정책을 적용합니다.
동료 검토	동료 검토를 사용하여 관련 팀에서 변경사항을 승인하는지 확인합니다.	사람이 직접 검토하는 경우 모든 오류를 발견할 수 없으며, 특히 구문 오류 등을 발견하기 어렵습니다.	조직에서 보안팀이 여러 시스템에 영향을 미치는 구성 변경사항을 검토해야 하는 경우 보안팀 구성원에게 변경사항을 검토해달라고 요청합니다.
지속적 통합 파이프라인의 자동 테스트	자동 테스트를 사용하여 제안된 변경사항의 오류를 포착합니다.	자동 테스트는 검토자를 완전히 대체할 수 없습니다. 둘 다 사용합니다.	제안된 모든 변경사항에서 `nomos vet` 명령어를 실행하여 저장소가 유효한 구성 동기화 구성인지 확인합니다.
동기화 오류 모니터링	구성 동기화가 실제로 클러스터에 변경사항을 적용하는지 확인합니다.	동기화 오류는 구성 동기화가 잘못된 저장소를 적용하려고 하거나 Kubernetes API 서버가 일부 객체를 거부하는 경우에만 발생합니다.	사용자가 모든 테스트와 검토를 우회하고 잘못된 변경사항을 구성 동기화 저장소에 커밋합니다. 이 변경사항은 클러스터에 적용할 수 없습니다. 동기화 오류를 모니터링하는 경우 오류가 발생하면 알림을 받게 됩니다.

출시 전략 예시

이 섹션에서는 이 문서의 나머지에서 소개하는 개념을 사용하여 조직의 모든 클러스터에 대한 엔드 투 엔드 출시 전략을 만드는 데 도움을 줍니다. 이 전략에서는 Fleet 예시 1 - 접근법 1에서처럼 개발, 스테이징, 프로덕션을 위한 별도의 Fleet가 있다고 가정합니다.

이 시나리오에서는 특정 Git 커밋을 사용하여 Git 저장소와 동기화하도록 각 클러스터를 구성합니다. 특정 Fleet에 변경사항을 배포하는 프로세스는 4단계입니다.

Fleet에서 단일('카나리아') 클러스터를 업데이트하여 새 커밋을 먼저 사용합니다.
테스트를 실행하고 출시를 모니터링하여 모든 것이 예상대로 작동하는지 확인합니다.
Fleet에서 나머지 클러스터를 업데이트합니다.
모든 것이 예상대로 작동하는지 다시 확인합니다.

모든 클러스터에 변경사항을 배포하려면 각 Fleet에 대해 이 프로세스를 반복합니다. 분기에서 Git 커밋을 사용하여 이 메서드를 기술적으로 적용할 수 있습니다. 하지만 검토 프로세스 초기에 문제를 식별하려면 다음 프로세스를 채택하는 것이 좋습니다.

다른 사용자가 구성 동기화 Git 저장소에서 변경 요청을 열면 개발 클러스터에 변경사항을 배포하세요.
변경 요청이 수락되어 기본 분기에서 병합되는 경우 앞서 설명한 대로 모든 Fleet에 전체 배포를 실행합니다.

일부 변경사항은 특정 Fleet만 대상으로 할 수 있지만 모든 변경사항을 최종적으로 모든 Fleet에 배포하는 것이 좋습니다. 이 전략은 어떤 Fleet를 어떤 커밋과 동기화할지 추적할 필요가 없습니다. 이전 Fleet에서는 적절한 테스트가 불가능하므로 프로덕션 Fleet만 대상으로 하는 변경사항에 특히 주의하세요. 예를 들어 카나리아 클러스터 배포와 나머지 클러스터 배포 사이에 문제가 발생할 때까지 더 오래 기다린다는 의미입니다.

요약하면 전체 엔드 투 엔드 배포 절차는 다음과 같습니다.

다른 사람이 변경 요청을 엽니다.
자동화된 테스트 및 유효성 검사가 실행되고 수동 검토가 완료됩니다.
작업을 수동으로 트리거하여 개발 Fleet의 카나리아 클러스터에 변경사항을 배포합니다. 이 클러스터에서 자동화된 엔드 투 엔드 테스트가 실행됩니다.
모든 것이 정상이면 기본 분기에서 변경 요청을 병합합니다.
병합은 자동화된 작업을 트리거하여 개발 Fleet의 카나리아 클러스터에 새로운 기본 분기 팁 커밋을 배포합니다. 이 클러스터에서 자동화된 엔드 투 엔드 테스트가 실행됩니다(대략 동시에 생성되고 병합된 두 변경 요청 간의 잠재적인 비호환성을 감지하기 위해).
다음 작업은 차례로 실행됩니다(사용자가 직접 트리거하거나 사용자가 회귀 보고서를 허용하도록 사전 정의된 시간 후에 트리거함).
1. 개발 Fleet의 모든 클러스터에 배포합니다.
2. 개발 Fleet 클러스터에서 테스트 및 유효성 검사를 실행합니다.
3. 스테이징 Fleet의 카나리아 클러스터에 배포합니다.
4. 스테이징 Fleet의 카나리아 클러스터에서 테스트 및 유효성 검사를 실행합니다.
5. 스테이징 Fleet의 모든 클러스터에 배포합니다.
6. 스테이징 Fleet의 클러스터에서 테스트 및 유효성 검사를 실행합니다.
7. 프로덕션 Fleet의 카나리아 클러스터에 배포합니다.
8. 프로덕션 Fleet의 카나리아 클러스터에서 테스트 및 유효성 검사를 실행합니다.
9. 프로덕션 Fleet의 모든 클러스터에 배포합니다.
10. 프로덕션 Fleet의 클러스터에서 테스트 및 유효성 검사를 실행합니다.

전체 출시 절차.

다음 단계

구성 동기화 모니터링 읽어보기
Fleet에 대해 알아보기
지속적 통합 파이프라인에서 회사 정책에 대해 앱 유효성 검사 방법 알아보기