GKE를 사용한 최신 CI/CD: CI/CD 시스템 구축

이 참조 아키텍처는 Google Kubernetes Engine, Cloud Build, Skaffold, kustomize, 구성 동기화, 정책 컨트롤러, Artifact Registry, Cloud Deploy와 같은 도구를 사용하여 최신 지속적 통합/지속적 배포(CI/CD) 시스템을 구축할 수 있는 메서드와 초기 인프라를 제공합니다.

이 문서는 다음 시리즈의 일부입니다.

이 문서는 엔터프라이즈 설계자와 애플리케이션 개발자를 비롯해 IT 보안, DevOps, 사이트 안정성 엔지니어링 팀을 대상으로 합니다. 자동 배포 도구 및 프로세스 관련 경험은 이 문서의 개념을 이해하는 데 유용합니다.

CI/CD 워크플로

최신 CI/CD 시스템을 빌드하려면 먼저 시스템의 기본 기능을 수행하는 도구 및 서비스를 선택해야 합니다. 이 참조 아키텍처는 다음 다이어그램에 표시된 CI/CD 시스템의 핵심 기능을 구현하는 데 중점을 둡니다.

다양한 팀이 CI/CD 시스템에 대한 책임을 관리하거나 공유합니다.

이 참조 구현은 각 구성요소에 다음과 같은 도구를 사용합니다.

  • 소스 코드 관리: GitHub
    • 애플리케이션 및 구성 코드를 저장합니다.
    • 변경사항을 검토할 수 있습니다.
  • 애플리케이션 구성 관리: kustomize
    • 원하는 애플리케이션 구성을 정의합니다.
    • 구성 기본 요소 또는 청사진을 재사용하고 확장할 수 있습니다.
  • 지속적 통합: Cloud Build
    • 소스 코드를 테스트하고 검증합니다.
    • 배포 환경에서 사용하는 아티팩트를 빌드합니다.
  • 지속적 배포: Cloud Deploy
    • 다양한 환경의 코드 배포 프로세스를 정의합니다.
    • 실패한 변경사항에 대한 롤백을 제공합니다.
  • 인프라 구성: 구성 동기화
    • 클러스터 및 정책 구성에 일관성 있게 적용됩니다.
  • 정책 시행: 정책 컨트롤러
    • 조직의 정책에 따라 특정 환경에서 실행할 수 있는 항목을 정의하는 데 사용할 수 있는 메커니즘을 제공합니다.
  • 컨테이너 조정: Google Kubernetes Engine
    • CI 중에 빌드된 아티팩트를 실행합니다.
    • 워크로드의 확장, 상태 확인, 출시 방법을 제공합니다.
  • 컨테이너 아티팩트: Artifact Registry
    • CI 중에 빌드된 아티팩트(컨테이너 이미지)를 저장합니다.

아키텍처

이 섹션에서는 이 참조 아키텍처(인프라, 파이프라인, 코드 저장소, 시작 영역)를 사용하여 구현하는 CI/CD 구성요소를 설명합니다.

CI/CD 시스템의 이러한 측면에 대한 일반적인 설명은 GKE를 사용한 최신 CI/CD: 소프트웨어 배포 프레임워크를 참조하세요.

참조 아키텍처 변형

참조 아키텍처에는 2개의 배포 모델이 포함됩니다.

  • 멀티 프로젝트 변형은 격리 경계가 향상된 프로덕션 배포와 비슷합니다.
  • 단일 프로젝트 변형은 데모를 수행하는 데 유용합니다.

다중 프로젝트 참조 아키텍처

참조 아키텍처의 multi-project 버전은 프로덕션과 비슷한 시나리오를 시뮬레이션합니다. 이러한 시나리오에서는 서로 다른 캐릭터가 적절한 격리 경계를 사용해서 인프라, CI/CD 파이프라인, 애플리케이션을 만듭니다. 이러한 캐릭터 또는 팀은 필요한 리소스에만 액세스할 수 있습니다.

자세한 내용 GKE를 사용한 최신 CI/CD: 소프트웨어 배포 프레임워크를 참조하세요.

이 버전의 참조 아키텍처를 설치하고 적용하는 방법에 대한 자세한 내용은 소프트웨어 배포 청사진을 참조하세요.

단일 프로젝트 참조 아키텍처

참조 아키텍처의 single-project 버전은 단일 Google Cloud 프로젝트에서 전체 소프트웨어 배포 플랫폼을 설정하는 방법을 보여줍니다. 이 버전은 승격된 IAM 역할이 없는 사용자가 프로젝트에 대해 소유자 역할만 갖고 참조 아키텍처를 설치하고 시도할 수 있게 도와줍니다. 이 문서에서는 참조 아키텍처의 단일 프로젝트 버전을 보여줍니다.

플랫폼 인프라

이 참조 아키텍처의 인프라는 개발, 스테이징, 프로덕션 애플리케이션 환경을 지원하는 Kubernetes 클러스터로 구성됩니다. 다음 다이어그램은 클러스터의 논리 레이아웃을 보여줍니다.

클러스터 레이아웃은 다양한 플랫폼 워크로드를 지원합니다.

코드 저장소

이 참조 아키텍처를 사용하여 운영자, 개발자, 플랫폼, 보안 엔지니어를 위한 저장소를 설정합니다.

다음 다이어그램은 다양한 코드 저장소의 참조 아키텍처 구현 및 작업, 개발, 보안팀이 저장소와 상호작용하는 방법을 보여줍니다.

저장소에는 권장사항은 물론 애플리케이션 및 플랫폼 구성이 포함됩니다.

이 워크플로에서 운영자는 운영자 저장소의 CI/CD 및 애플리케이션 구성에 대한 권장사항을 관리할 수 있습니다. 개발자가 개발 저장소에서 애플리케이션을 온보딩하는 경우 개발자는 권장사항, 애플리케이션의 비즈니스 로직, 애플리케이션이 올바르게 작동하는 데 필요한 특수 구성을 자동으로 가져옵니다. 한편 운영팀과 보안팀은 구성 및 정책 저장소에서 플랫폼의 일관성과 보안을 관리할 수 있습니다.

애플리케이션 랜딩 영역

이 참조 아키텍처에서 애플리케이션의 랜딩 영역은 애플리케이션이 프로비저닝될 때 생성됩니다. 이 시리즈의 다음 문서인 GKE를 사용한 최신 CI/CD: 개발자 워크플로 적용에서는 자체 시작 영역을 만드는 새 애플리케이션을 프로비저닝합니다. 다음 다이어그램은 이 참조 아키텍처에서 사용되는 시작 영역의 중요 구성요소를 보여줍니다.

GKE 클러스터에는 여러 다른 애플리케이션을 위한 3개의 네임스페이스가 포함됩니다.

각 네임스페이스에는 GKE용 워크로드 아이덴티티 제휴가 Cloud Storage 또는 Spanner와 같이 Kubernetes 컨테이너 외부의 서비스에 액세스하기 위해 사용되는 서비스 계정이 포함됩니다. 네임스페이스에는 또한 다른 네임스페이스 또는 애플리케이션과 경계를 격리하거나 공유하는 네트워크 정책과 같은 기타 리소스가 포함됩니다.

네임스페이스는 CD 실행 서비스 계정에 의해 생성됩니다. CD 실행 서비스 계정이 필요한 네임스페이스에만 액세스할 수 있도록 하려면 팀이 최소 권한의 원칙을 따르는 것이 좋습니다.

구성 동기화에서 서비스 계정 액세스를 정의하고 Kubernetes 역할 기반 액세스 제어(RBAC) 역할 및 역할 바인딩을 사용하여 구현할 수 있습니다. 이 모델을 사용하면 팀이 관리하는 네임스페이스에 직접 리소스를 배포할 수 있지만 다른 네임스페이스의 리소스를 덮어쓰거나 삭제하지는 못합니다.

목표

  • 단일 프로젝트 참조 아키텍처를 배포합니다.
  • 코드 저장소를 살펴봅니다.
  • 파이프라인 및 인프라를 살펴봅니다.

비용

이 문서에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.

프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요. Google Cloud를 처음 사용하는 사용자는 무료 체험판을 사용할 수 있습니다.

이 문서에 설명된 태스크를 완료했으면 만든 리소스를 삭제하여 청구가 계속되는 것을 방지할 수 있습니다. 자세한 내용은 삭제를 참조하세요.

시작하기 전에

  1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  2. Google Cloud 프로젝트에 결제가 사용 설정되어 있는지 확인합니다.

  3. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

참조 아키텍처 배포

  1. Cloud Shell에서 프로젝트를 설정합니다.

    gcloud config set core/project PROJECT_ID

    PROJECT_ID를 Google Cloud 프로젝트 ID로 바꿉니다.

  2. Cloud Shell에서 Git 저장소를 클론합니다.

    git clone https://github.com/GoogleCloudPlatform/software-delivery-blueprint.git
cd software-delivery-blueprint/launch-scripts
git checkout single-project-blueprint

  3. GitHub에서 다음 범위로 개인 액세스 토큰을 만듭니다.

    • repo
    • delete_repo
    • admin:org
    • admin:repo_hook

  4. software-delivery-bluprint/launch-scripts 폴더 아래에 vars.sh라는 빈 파일이 있습니다. 파일에 다음 콘텐츠를 추가합니다. 

    cat << EOF >vars.sh
export INFRA_SETUP_REPO="gke-infrastructure-repo"
export APP_SETUP_REPO="application-factory-repo"
export GITHUB_USER=GITHUB_USER
export TOKEN=TOKEN
export GITHUB_ORG=GITHUB_ORG
export REGION="us-central1"
export SEC_REGION="us-west1"
export TRIGGER_TYPE="webhook"
EOF

    GITHUB_USER를 GitHub 사용자 이름으로 바꿉니다.

    TOKEN을 GitHub 개인 액세스 토큰으로 바꿉니다.

    GITHUB_ORG를 GitHub 조직의 이름으로 바꿉니다.

  5. bootstrap.sh 스크립트를 실행합니다. Cloud Shell에서 승인을 요청하는 메시지가 표시되면 승인을 클릭합니다.

    ./bootstrap.sh

    스크립트가 소프트웨어 배포 플랫폼을 부트스트랩합니다.

코드 저장소 살펴보기

이 섹션에서는 코드 저장소를 살펴봅니다.

GitHub에 로그인

  1. 웹브라우저에서 github.com으로 이동하고 계정에 로그인합니다.
  2. 인터페이스 상단에 있는 사진 아이콘을 클릭합니다.
  3. 내 조직을 클릭합니다.
  4. vars.sh 파일에 입력으로 제공한 조직을 선택합니다.
  5. 저장소 탭을 클릭합니다.

시작 조건, 운영자, 구성, 인프라 저장소 살펴보기

시작 조건, 운영자, 구성, 인프라 저장소는 운영자와 플랫폼 관리자가 플랫폼 빌드 및 운영을 위한 일반적인 권장사항을 정의하는 곳입니다. 이러한 저장소는 참조 아키텍처가 부트스트래핑될 때 GitHub 조직 아래에 생성됩니다.

목록의 각 저장소에는 간략한 설명이 포함됩니다.

시작 조건 저장소

시작 조건 저장소는 플랫폼 전반의 CI/CD, 인프라 및 개발 권장사항 채택을 도와줍니다. 자세한 내용은 GKE를 사용한 최신 CI/CD: 소프트웨어 배포 프레임워크를 참조하세요.

애플리케이션 시작 조건 저장소

애플리케이션 시작 조건 저장소에서 운영자는 애플리케이션에 대한 CI, 측정항목 수집, 로깅, 컨테이너 단계, 보안과 같은 권장사항을 코드화하여 문서화할 수 있습니다. 참조 아키텍처에는 Go 및 자바 애플리케이션용 시작 조건 저장소의 예시가 포함되어 있습니다.

app-template-python, app-template-java, app-template-golang 애플리케이션 시작 조건 저장소에는 새 애플리케이션을 만드는 데 사용할 수 있는 상용구 코드가 포함됩니다. 새 애플리케이션 만들기 외에도 애플리케이션 요구사항을 기반으로 새 템플릿을 만들 수 있습니다. 참조 아키텍처에서 제공하는 애플리케이션 시작 조건 저장소에는 다음이 포함됩니다.

  • k8s 폴더 아래에 kustomize 베이스 및 패치

  • 애플리케이션 소스 코드

  • 애플리케이션 빌드 및 실행 방법을 설명하는 Dockerfile

  • CI 단계 권장사항을 설명하는 cloudbuild.yaml 파일

  • 배포 단계를 설명하는 skaffold.yaml 파일

이 시리즈의 다음 문서인 GKE를 사용한 최신 CI/CD: 개발자 워크플로 적용에서 app-template-python 저장소를 사용하여 새 애플리케이션을 만듭니다.

인프라 시작 조건 저장소

인프라 시작 조건 저장소에서 운영자와 인프라 관리자는 인프라에 대한 CI/CD 파이프라인, IaC, 측정항목 수집, 로깅, 보안과 같은 권장사항을 코드화하여 문서화할 수 있습니다. 참조 아키텍처에는 Terraform을 사용하는 인프라 시작 조건 저장소의 예시가 포함되어 있습니다. infra-template 인프라 시작 조건 저장소에는 Cloud Storage 버킷 또는 Spanner 데이터베이스 등 애플리케이션에 필요한 인프라 리소스를 만드는 데 사용할 수 있는 Terraform용 상용구 코드가 포함됩니다.

공유 템플릿 저장소

공유 템플릿 저장소에서 인프라 관리자와 운영자는 태스크 수행을 위한 표준 템플릿을 제공합니다. 참조 아키텍처에 제공된 terraform-modules라는 저장소가 있습니다. 저장소에는 다양한 인프라 리소스를 만드는 템플릿화된 Terraform 코드가 포함되어 있습니다.

연산자 저장소

참조 아키텍처에서 운영자 저장소는 애플리케이션 시작 조건 저장소와 동일합니다. 운영자는 애플리케이션 시작 조건 저장소에서 CI 및 CD 모두에 필요한 파일을 관리합니다. 참조 아키텍처에는 app-template-python, app-template-java, app-template-golang 저장소가 포함됩니다.

  • 이는 시작 조건 템플릿이며 플랫폼의 Kubernetes에서 실행되는 애플리케이션의 기본 Kubernetes 매니페스트가 포함됩니다. 운영자는 필요에 따라 시작 조건 템플릿에서 매니페스트를 업데이트할 수 있습니다. 애플리케이션이 생성될 때 업데이트가 선택됩니다.
  • 이러한 저장소의 cloudbuild.yaml 및 skaffold.yaml 파일에는 플랫폼에서 각각 CI 및 CD를 실행하기 위한 권장사항이 저장되어 있습니다. 애플리케이션 구성과 비슷하게, 연산자는 권장사항을 업데이트하고 권장사항에 추가할 수 있습니다. 개별 플랫폼 파이프라인은 최신 단계를 사용하여 생성됩니다.

이 참조 구현에서 운영자는 kustomize를 사용하여 시작 조건 저장소의 k8s 폴더에서 기본 구성을 관리합니다. 그런 다음 개발자는 애플리케이션별 변경사항(예: 리소스 이름 및 구성 파일)으로 매니페스트를 자유롭게 확장할 수 있습니다. kustomize 도구는 구성을 데이터처럼 지원합니다. 이 방법론에서 kustomize 입력 및 출력은 Kubernetes 리소스입니다. 매니페스트를 하나 수정하여 나온 출력을 다른 수정사항에 사용할 수 있습니다.

다음 다이어그램은 Spring Boot 애플리케이션의 기본 구성을 보여줍니다.

애플리케이션 구성은 별도의 팀이 관리하는 여러 저장소에서 생성됩니다.

kustomize의 구성을 데이터처럼 모델은 다음과 같은 큰 이점이 있습니다. 운영자가 기본 구성을 업데이트하면 다음 실행 시 개발자의 변경 없이도 개발자의 배포 파이프라인에서 업데이트가 자동으로 사용됩니다.

kustomize를 사용하여 Kubernetes 매니페스트를 관리하는 방법에 대한 자세한 내용은 kustomize 문서를 참조하세요.

구성 및 정책 저장소

참조 아키텍처에는 구성 동기화 및 정책 컨트롤러를 사용하는 구성 및 정책 저장소 구현이 포함되어 있습니다. acm-gke-infrastructure-repo 저장소에는 애플리케이션 환경 클러스터 전반에 배포하는 구성 및 정책이 포함됩니다. 이러한 저장소의 플랫폼 관리자가 정의 및 저장하는 구성은 플랫폼이 운영 및 개발팀에게 일관된 외관과 느낌을 주도록 하는 데 중요합니다.

다음 섹션에서는 참조 아키텍처가 구성 및 정책 저장소를 구현하는 방법에 대해 자세히 설명합니다.

구성

이 참조 구현에서는 구성 동기화를 사용하여 플랫폼의 클러스터 구성을 중앙에서 관리하고 정책을 적용합니다. 중앙 집중식 관리를 사용하면 시스템 전체에 구성 변경사항을 전파할 수 있습니다.

구성 동기화를 사용하면 조직에서 클러스터를 등록하여 GitOps라는 Git 저장소 프로세스에서 구성을 동기화할 수 있습니다. 새 클러스터를 추가할 때 클러스터는 자동으로 최신 구성으로 동기화되고 다른 사용자가 대역 외 변경을 수행할 경우 구성을 사용하여 클러스터 상태를 지속적으로 조정합니다.

구성 동기화에 대한 자세한 내용은 해당 문서를 참조하세요.

정책

이 참조 구현에서는 Open Policy Agent를 기반으로 하는 정책 컨트롤러를 사용해서 플랫폼의 Kubernetes 클러스터에 대한 각 요청을 가로채고 검증합니다. Rego 정책 언어를 사용하여 정책을 만들 수 있으며, 이를 통해 클러스터에 제출된 리소스 유형뿐만 아니라 해당 구성도 완전히 제어할 수 있습니다.

다음 다이어그램의 아키텍처는 정책 컨트롤러를 사용하여 리소스를 만드는 요청 흐름을 보여줍니다.

정책 규칙을 먼저 정의한 다음 kubectl 및 API 클라이언트와 같은 다양한 도구를 사용하여 적용합니다.

구성 동기화 저장소에서 규칙을 만들고 정의하면 이러한 변경사항이 클러스터에 적용됩니다. 그런 다음 CLI 또는 API 클라이언트의 새 리소스 요청은 정책 컨트롤러의 제약조건을 기준으로 확인됩니다.

정책 관리에 대한 자세한 내용은 정책 컨트롤러 개요를 참조하세요.

인프라 저장소

참조에는 Terraform을 사용한 인프라 저장소 구현이 포함되어 있습니다. gke-infrastructure-repo 저장소에는 개발, 스테이징, 프로덕션 환경을 위해 GKE 클러스터를 만들고 acm-gke-infrastructure-repo 저장소를 사용하여 구성 동기화를 구성하기 위한 코드형 인프라가 포함되어 있습니다. gke-infrastructure-repo에는 개발, 스테이징, 프로덕션 환경에 하나씩 세 개의 브랜치가 포함됩니다. 또한 각 브랜치에 개발, 스테이징, 프로덕션 폴더가 포함되어 있습니다.

파이프라인 및 인프라 살펴보기

참조 아키텍처는 Google Cloud 프로젝트에서 파이프라인을 만듭니다. 이 파이프라인은 공유 인프라를 만듭니다.

파이프라인

이 섹션에서는 코드로서의 인프라 파이프라인을 살펴보고 이를 실행해서 GKE 클러스터를 포함하는 공유 인프라를 만듭니다. 이 파이프라인은 인프라 저장소 gke-infrastructure-repo에 연결된 Google Cloud 프로젝트에서 create-infra라는 Cloud Build 트리거입니다. Cloud Build 코드형 인프라 파이프라인을 사용하며 규모에 따른 반복 가능한 GCP 환경 동영상에서 설명한 대로 GitOps 방법론을 따라 인프라를 만듭니다.

gke-infrastructure-repo에는 개발, 스테이징, 프로덕션 브랜치가 있습니다. 저장소에는 이러한 브랜치에 해당하는 개발, 스테이징, 프로덕션 폴더도 있습니다. 저장소에는 브랜치 보호 규칙이 있으며 코드는 개발 브랜치에만 푸시될 수 있습니다. 스테이징 및 프로덕션 브랜치에 코드를 푸시하려면 pull 요청을 만들어야 합니다.

일반적으로 저장소에 대한 액세스 권한이 있는 사용자가 변경사항을 검토한 후 pull 요청을 병합하여 의도한 변경사항만 상위 브랜치로 승격되도록 합니다. 개별 사용자가 청사진을 사용해 볼 수 있도록 저장소 관리자가 검토를 우회하고 pull 요청을 병합할 수 있도록 브랜치 보호 규칙이 참조 아키텍처에서 완화되었습니다.

gke-infrastructure-repo에 푸시가 수행되면 create-infra 트리거가 호출됩니다. 이 트리거는 푸시가 발생한 브랜치를 식별하여 해당 브랜치의 저장소에 있는 해당 폴더로 이동합니다. 해당 폴더를 찾은 후 폴더에 포함된 파일을 사용해서 Terraform을 실행합니다. 예를 들어 코드가 개발 브랜치에 푸시되면 트리거가 개발 브랜치의 개발 폴더에서 Terraform을 실행하여 개발 GKE 클러스터를 만듭니다. 마찬가지로 staging 브랜치에 푸시가 발생하면 트리거가 스테이징 브랜치의 스테이징 폴더에서 Terraform을 실행하여 스테이징 GKE 클러스터를 만듭니다.

파이프라인을 실행하여 GKE 클러스터를 만듭니다.

  1. Google Cloud Console에서 Cloud Build 페이지로 이동합니다.

    Cloud Build 페이지로 이동

    • 5개의 Cloud Build 웹훅 트리거가 있습니다. 이름이 create-infra인 트리거를 찾습니다. 이 트리거는 GKE 클러스터가 포함된 공유 인프라를 만듭니다.

  2. 트리거 이름을 클릭합니다. 트리거 정의가 열립니다.

  3. 편집기 열기를 클릭하여 트리거가 실행하는 단계를 확인합니다.

    다른 트리거는 GKE를 사용한 최신 CI/CD: 개발자 워크플로 적용에서 애플리케이션을 온보딩할 때 사용됩니다.

    Cloud Build 트리거

  4. Google Cloud Console에서 Cloud Build 페이지로 이동합니다.

    Cloud Build 기록 페이지로 이동

    기록 페이지에 있는 파이프라인을 검토합니다. bootstrap.sh를 사용하여 소프트웨어 배포 플랫폼을 배포했을 때 스크립트가 이 파이프라인을 시작하고 개발 GKE 클러스터를 생성한 gke-infrastructure-repo 저장소의 dev 브랜치로 코드를 푸시했습니다.

  5. 스테이징 GKE 클러스터를 만들려면 개발 브랜치에서 스테이징 브랜치에 대한 pull 요청을 제출합니다.

    1. GitHub로 가서 gke-infrastructure-repo 저장소로 이동합니다.

    2. pull 요청을 클릭한 후 새 pull 요청을 클릭합니다.

    3. 기본 메뉴에서 staging을 선택하고 비교 메뉴에서 dev를 선택합니다.

    4. pull 요청 만들기를 클릭합니다.

  6. 저장소 관리자의 경우 pull 요청을 병합합니다. 그렇지 않으면 관리자에게 pull 요청을 병합하도록 요청합니다.

  7. Google Cloud 콘솔에서 Cloud Build 기록 페이지로 이동합니다.

    Cloud Build 기록 페이지로 이동

    두 번째 Cloud Build 파이프라인이 프로젝트에서 시작됩니다. 이 파이프라인은 스테이징 GKE 클러스터를 만듭니다.

  8. 프로덕션 GKE 클러스터를 만들려면 스테이징에서 프로덕션 브랜치에 pull request를 제출합니다.

    1. GitHub로 가서 gke-infrastructure-repo 저장소로 이동합니다.

    2. pull 요청을 클릭한 후 새 pull 요청을 클릭합니다.

    3. 기본 메뉴에서 prod를 선택하고 비교 메뉴에서 스테이징을 선택합니다.

    4. pull 요청 만들기를 클릭합니다.

  9. 저장소 관리자의 경우 pull 요청을 병합합니다. 그렇지 않으면 관리자에게 pull 요청을 병합하도록 요청합니다.

  10. Google Cloud 콘솔에서 Cloud Build 기록 페이지로 이동합니다.

    Cloud Build 기록 페이지로 이동

    세 번째 Cloud Build 파이프라인이 프로젝트에서 시작됩니다. 이 파이프라인은 프로덕션 GKE 클러스터를 만듭니다.

인프라

이 섹션에서는 파이프라인에서 생성된 인프라를 살펴봅니다.

  • Google Cloud 콘솔에서 Kubernetes 클러스터 페이지로 이동합니다.

    Kubernetes 클러스터 페이지로 이동

    이 페이지에는 개발(gke-dev-us-central1), 스테이징(gke-staging-us-central1), 프로덕션(gke-prod-us-central1, gke-prod-us-west1)에 사용되는 클러스터가 나와 있습니다.

    클러스터 세부정보에는 위치, 클러스터 크기, 총 코어 수가 포함됩니다.

개발 클러스터

개발 클러스터(gke-dev-us-central1)는 개발자가 애플리케이션에서 반복하는 데 사용할 수 있는 네임스페이스에 대한 액세스 권한을 제공합니다. 개발 중인 코드를 적극적으로 모니터링하고 변경사항이 있는 경우 개발 환경에 다시 적용하여 반복적인 워크플로를 제공하는 Skaffold와 같은 도구를 사용하는 것이 좋습니다. 이 반복 루프는 핫 리로드와 비슷합니다. 프로그래밍 언어에 따라 지정하는 대신 Docker 이미지로 빌드할 수 있는 모든 애플리케이션에서 루프가 작동합니다. Kubernetes 클러스터 내에서 루프를 실행할 수 있습니다.

또는 개발자가 개발 환경을 위한 CI/CD 루프를 따를 수 있습니다. 이 루프를 사용하면 상위 환경으로 승격할 수 있도록 코드 변경사항이 준비됩니다.

이 시리즈의 다음 문서인 GKE를 사용한 최신 CI/CD: 개발자 워크플로 적용에서는 Skaffold 및 CI/CD를 모두 사용해서 개발 루프를 만듭니다.

스테이징 클러스터

이 클러스터는 애플리케이션의 스테이징 환경을 실행합니다. 이 참조 아키텍처에서는 스테이징을 위해 하나의 GKE 클러스터를 만듭니다. 일반적으로 스테이징 환경은 프로덕션 환경의 정확한 복제본입니다.

프로덕션 클러스터

참조 아키텍처에는 프로덕션 환경을 위한 2개의 GKE 클러스터가 있습니다. 지리적 중복 또는 고가용성(HA) 시스템의 경우 각 환경에 여러 클러스터를 추가하는 것이 좋습니다. 애플리케이션이 배포된 모든 클러스터에는 리전 클러스터를 사용하는 것이 가장 좋습니다. 이 접근 방식은 영역 수준의 장애와 클러스터 또는 노드 풀 업그레이드로 인한 모든 중단으로부터 애플리케이션을 격리합니다.

네임스페이스, 할당량, RBAC와 같은 클러스터 리소스 구성을 동기화하기 위해서는 구성 동기화를 사용하는 것이 좋습니다. 이러한 리소스 관리 방법에 대한 자세한 내용은 구성 및 정책 저장소를 참조하세요.

참조 아키텍처 적용

지금까지 참조 아키텍처에 대해 살펴보았습니다. 이제 이 구현을 기반으로 하는 개발자 워크플로를 살펴볼 수 있습니다. 이 시리즈의 다음 문서인 GKE를 사용한 최신 CI/CD: 개발자 워크플로 적용에서는 새 애플리케이션을 만들고 기능을 추가한 후 애플리케이션을 스테이징 및 프로덕션 환경에 배포합니다.

삭제

이 시리즈의 다음 문서인 GKE를 사용한 최신 CI/CD: 개발자 워크플로 적용을 사용해 보려면 이 참조 아키텍처와 연결된 프로젝트 또는 리소스를 삭제하지 마세요. 그렇지 않고 참조 아키텍처에 사용한 리소스 관련 비용이 Google Cloud 계정에 청구되지 않도록 하려면 프로젝트를 삭제하거나 리소스를 수동으로 삭제하면 됩니다.

프로젝트 삭제

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

수동으로 리소스 삭제

  • Cloud Shell에서 인프라를 삭제합니다.

      gcloud container clusters delete gke-dev-us-central1
  gcloud container clusters delete gke-staging-us-central1
  gcloud container clusters delete gke-prod-us-central1
  gcloud container clusters delete gke-prod-us-west1
  gcloud beta builds triggers delete create-infra
  gcloud beta builds triggers delete add-team-files
  gcloud beta builds triggers delete create-app
  gcloud beta builds triggers delete tf-plan
  gcloud beta builds triggers delete tf-apply

다음 단계