GKE를 사용한 최신 CI/CD: 개발자 워크플로 적용

Last reviewed 2023-09-11 UTC

표준

---

이 튜토리얼에서는 새 애플리케이션을 온보딩하고 애플리케이션 기능을 개발하고 Google Kubernetes Engine(GKE)에서 최신 지속적 통합/지속적 배포(CI/CD) 기술을 사용하여 애플리케이션을 프로덕션에 배포하는 방법을 설명합니다.

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

• GKE를 사용한 최신 CI/CD: 소프트웨어 배포 프레임워크
• GKE를 사용한 최신 CI/CD: CI/CD 시스템 구축(참조 아키텍처)
• GKE를 사용한 최신 CI/CD: 개발자 워크플로 적용(이 문서)

이 튜토리얼에서는 Skaffold, kustomize ,Artifact Registry ,구성 동기화 ,Cloud Build, Cloud Deploy 같은 도구를 사용하여 애플리케이션을 개발, 빌드, 배포합니다.

이 문서는 IT 보안, DevOps, 사이트 안정성 엔지니어링(SRE)팀은 물론 엔터프라이즈 설계자 및 애플리케이션 개발자를 대상으로 합니다. 자동화 배포 도구와 프로세스에 대한 경험이 있으면 이 문서의 개념을 쉽게 이해할 수 있습니다.

아키텍처

이 튜토리얼에서는 새 애플리케이션을 온보딩합니다. 그런 다음 새 기능을 개발하고 개발, 스테이징, 프로덕션 환경에 애플리케이션을 배포합니다. 참조 아키텍처에는 다음 다이어그램에 표시된 워크플로와 함께 새 애플리케이션을 온보딩하고 출시하는 데 필요한 인프라와 도구가 포함되어 있습니다.

워크플로에는 CI 코드 저장소부터 다음 단계가 포함됩니다.

1. 애플리케이션 저장소를 통해 애플리케이션 소스 코드를 공유합니다.

2. 코드를 커밋하고 애플리케이션 저장소에 푸시하면 Cloud Build에서 CI 파이프라인을 자동으로 트리거합니다. CI 프로세스는 컨테이너 이미지를 만들어 Artifact Registry에 푸시합니다.

3. CI 프로세스도 Cloud Deploy에서 애플리케이션에 대해 CD 출시를 만듭니다.

4. CD 출시는 skaffold를 사용하여 개발 목적으로 완전히 렌더링된 kubernetes 매니페스트를 생성하며 이를 개발 GKE 클러스터에 배포합니다.

5. 그런 후 CD 출시가 개발에서 스테이징 대상으로 승격되어 완전히 렌더링된 스테이징 매니페스트를 생성하고 이를 스테이징 GKE 클러스터에 배포합니다.

6. 그런 후 CD 출시는 스테이징에서 프로덕션으로 승격되어 완전히 렌더링된 프로덕션 매니페스트를 생성하고 이를 프로덕션 GKE 클러스터에 배포합니다.

이 워크플로에 사용되는 도구와 인프라에 대한 자세한 내용은 GKE를 사용한 최신 CI/CD: CI/CD 시스템 구축을 참조하세요.

목표

• 새 애플리케이션을 온보딩합니다.

• 개발 환경에 애플리케이션을 배포합니다.

• 새 기능을 개발하고 개발 환경에 배포합니다.

• 새 기능을 스테이징으로 승격한 후 프로덕션에 출시합니다.

• 애플리케이션의 복원력을 테스트합니다.

비용

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

• Google Kubernetes Engine
• Google Kubernetes Engine (GKE) Enterprise edition for Config Sync
• Artifact Registry
• Cloud Build
• Cloud Deploy

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

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

시작하기 전에

• 이 튜토리얼에서는 이 시리즈의 참조 아키텍처를 배포합니다.

개발 환경 준비

1. GKE를 사용한 최신 CI/CD: CI/CD 시스템 구축에서 직접 계속하는 경우 다음 단계로 이동합니다. 그러나 새 세션이 있거나 세션이 만료되었으면 Cloud Shell을 열고 참조 아키텍처 인프라를 설치한 프로젝트를 설정합니다.

   gcloud config set core/project PROJECT_ID
   

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

새 애플리케이션 온보딩

참조 아키텍처에는 애플리케이션 팩토리가 포함됩니다. 이 팩토리는 application-factory-repo라는 git 저장소와 다음 Cloud Build 트리거의 컬렉션입니다.

• create-app
• tf-plan
• tf-apply
• create-team

애플리케이션 팩토리를 사용하여 시작 조건 저장소에서 새 애플리케이션을 온보딩합니다. 애플리케이션 온보딩은 다음 단계로 구성됩니다.

1. 애플리케이션 정의 만들기: Terraform 파일에서 애플리케이션 정의를 만들고 애플리케이션 카탈로그 역할을 수행하는 application-factory-repo에 저장합니다.

2. 애플리케이션 인프라 만들기: 애플리케이션 정의 파일에서 Terraform을 실행하여 애플리케이션 인프라를 만듭니다. 애플리케이션 인프라는 다음으로 구성됩니다.

   1. 새 애플리케이션의 시작 영역에는 acm-gke-infrastructure-repo 저장소의 네임스페이스, 서비스 계정, 기본 정책을 정의하는 작업이 포함됩니다. 시작 영역은 새 애플리케이션을 온보딩하는 동안 개발 GKE 클러스터에만 생성됩니다. 이 작업은 개발자가 개발 환경을 사용하고 여기에서 반복 작업을 시작할 수 있도록 개발자를 차단 해제하기 위해 수행됩니다. 스테이징 및 프로덕션 클러스터의 시작 영역은 GitOps 접근 방식으로 생성됩니다. 이 접근 방식에 대해서는 해당 클러스터에서 출시를 승격할 준비가 되는 이 문서의 후반부에서 설명합니다.

   2. 인프라 시작 조건 저장소의 인프라 저장소는 Cloud Build의 CI 파이프라인, Cloud Deploy의 CD 파이프라인, 아티팩트 저장을 위한 Artifact Registry 저장소를 만들 수 있는 코드를 호스팅합니다.

   3. 인프라 Cloud Build 트리거는 인프라 저장소의 코드를 가져와서 해당 정의에 따라 리소스를 만듭니다.

   4. 애플리케이션의 소스 코드를 호스팅하는 애플리케이션 시작 조건 저장소의 애플리케이션 저장소입니다.

3. 애플리케이션 CI/CD 리소스 만들기: 애플리케이션 인프라를 사용해서 애플리케이션의 CI/CD 리소스를 만듭니다.

참고: 참조 아키텍처를 사용하면 전체 애플리케이션 온보딩 및 배포 단계를 자동화할 수 있습니다. 아키텍처를 쉽게 이해할 수 있도록 이 문서에서는 이러한 단계를 세분화해서 설명합니다.

애플리케이션 정의 만들기

create-app 트리거를 실행하여 application-factory-repo에서 애플리케이션 정의 파일을 생성합니다. 정의 파일에는 애플리케이션을 만드는 데 필요한 선언적인 리소스 정의가 포함됩니다.

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

   Cloud Build 페이지로 이동

2. create-app 트리거를 클릭합니다.

3. SHOW URL PREVIEW를 클릭하여 웹훅을 호출하는 데 필요한 URL을 표시합니다.

4. Cloud Shell에서 이전 단계에서 가져온 URL에 curl 요청을 만들고 매개변수를 페이로드로 전달하여 트리거를 호출합니다.

   curl "WEBHOOK_URL" -d '{"message": {"app": "sample","runtime": "python","trigger_type": "webhook","github_team": ""}}'
   

   이전 코드 샘플에서는 다음을 수행합니다.

   • WEBHOOK_URL을 트리거에서 가져온 URL로 바꿉니다.

   • "app": "sample"은 애플리케이션의 이름을 지정합니다.

   • "runtime": "python"은 Python 템플릿을 사용하여 애플리케이션 저장소를 만들도록 애플리케이션 팩토리에 지시합니다.

   • "trigger_type": "webhook"은 애플리케이션의 CI/CD 파이프라인 유형을 지정합니다.

   • "github_team": ""은 애플리케이션에 대해 생성된 저장소와 연결되는 GitHub의 팀입니다. 아직 GitHub 팀을 만들지 않았으므로 이를 빈 문자열로 전달합니다.

5. create-app 트리거의 파이프라인을 확인합니다.

   Cloud Build 기록 페이지로 이동합니다.

   create-app 트리거에 대해 새 파이프라인이 있습니다. 완료되었으면 애플리케이션 정의가 application-factory-repo에 생성됩니다.

6. 애플리케이션 정의 파일을 검토합니다.

   1. 웹브라우저에서 GitHub로 이동하고 계정에 로그인합니다.

   2. 사진 아이콘을 클릭하고 Your organizations를 클릭합니다. 조직을 선택합니다.

   3. 저장소 application-factory-repo를 클릭하고 apps/python 폴더로 이동하여 create-app 트리거로 만든 sample.tf라는 새 파일을 엽니다. 파일을 검사합니다. 이 파일에는 새 애플리케이션을 만들기 위한 Terraform 코드가 포함되어 있습니다.

애플리케이션 인프라 만들기

이제 애플리케이션 정의를 만들었으므로 tf-apply 트리거를 실행하여 애플리케이션 인프라를 만듭니다.

1. Google Cloud 콘솔에서 다음을 수행합니다.

   Cloud Build 페이지로 이동합니다.

   tf-apply 트리거를 클릭합니다.

2. "SHOW URL PREVIEW"를 클릭하여 웹훅을 호출하는 데 필요한 URL을 표시합니다.

3. 트리거를 호출합니다.

   curl "WEBHOOK_URL" -d '{}'
   

   이전 코드 샘플에서는 다음을 수행합니다.

   • WEBHOOK_URL을 트리거에서 가져온 URL로 바꿉니다.

4. tf-apply 트리거의 파이프라인을 확인합니다.

   Cloud Build 기록 페이지로 이동합니다.

   tf-apply 트리거에 대해 새 파이프라인이 있습니다. 완료될 때까지 기다립니다.

이 트리거는 애플리케이션 인프라를 만듭니다.

애플리케이션 인프라 검토

애플리케이션 인프라의 다양한 구성요소를 검토합니다.

시작 영역

1. Cloud Shell로 이동하여 프로젝트를 설정합니다.

   gcloud config set core/project PROJECT_ID
   

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

2. 개발 GKE 클러스터에 대한 사용자 인증 정보를 가져옵니다.

   gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a
   

3. 애플리케이션의 네임스페이스를 확인합니다. 애플리케이션 샘플에 따라 네임스페이스 이름이 지정됩니다.

   kubectl get namespaces sample
   

   다음과 유사한 결과가 출력됩니다.

   NAME     STATUS   AGE
   sample   Active   15m
   

4. 네임스페이스에서 서비스 계정을 확인합니다.

   kubectl get serviceaccounts -n sample
   

   기본값 외에도 서비스 계정이 있습니다. 다음과 유사한 결과가 출력됩니다.

   NAME         SECRETS   AGE
   default      0         15m
   sample-ksa   0         15m
   

인프라 저장소

웹브라우저에서 GitHub로 이동하고 계정에 로그인합니다. 화면 하단에 있는 사진 아이콘을 클릭합니다. 그런 다음 Your organizations를 클릭합니다. 조직을 선택하고 sample-infra 저장소를 클릭합니다.

이 저장소에는 cicd-trigger, dev, staging, prod의 4개 브랜치가 있습니다. 또한 cicd-trigger, 개발, 스테이징, 프로덕션이라는 4개의 폴더가 포함되어 있습니다. 기본 브랜치는 cicd-trigger이며 여기에 코드를 푸시할 수 있지만 다른 브랜치에 보호 규칙이 있으므로 해당 브랜치로 코드를 직접 푸시할 수 없습니다. 코드를 해당 브랜치로 푸시하려면 pull 요청을 만들어야 합니다. cicd-trigger 폴더에는 애플리케이션의 CI/CD 리소스를 만들기 위한 코드가 있고 dev, staging, prod 폴더에는 애플리케이션의 여러 다른 환경에 대해 인프라를 만들기 위한 코드가 있습니다.

인프라 트리거

• Google Cloud 콘솔에서 다음을 수행합니다.

  Cloud Build 페이지로 이동

  deploy-infra-sample이라는 새 트리거가 있습니다.

• 이 트리거는 sample-infra 저장소에 연결되므로 이 저장소에 코드 푸시가 발생하면 트리거가 호출되고 푸시가 발생한 브랜치를 식별하고 해당 브랜치의 해당 폴더로 이동하여 Terraform을 실행합니다. 예를 들어 코드가 cicd-trigger 브랜치로 푸시되면 트리거가 cicd-trigger 브랜치의 cicd 트리거 폴더에서 Terraform을 실행합니다. 마찬가지로 dev 브랜치에 대한 푸시가 발생하면 트리거는 개발 브랜치의 개발 폴더 등에서 Terraform을 실행합니다.

애플리케이션 저장소

• GitHub로 이동하여 조직의 저장소를 불러옵니다. 이름이 sample인 새 저장소가 있습니다. 이 저장소는 Dockerfile, 애플리케이션의 필수 구성을 설명하는 kustomize 구성, CD용 Cloud Deploy에서 사용할 배포 단계를 정의하는 skaffold.yaml에서 컨테이너를 빌드하기 위한 소스 코드 및 단계를 호스팅합니다.

애플리케이션 CI/CD 리소스 만들기

애플리케이션의 골조를 만들었으므로 이제 deploy-infra-sample 트리거를 실행하여 CI/CD 리소스를 만듭니다. 웹훅 URL을 사용하거나 git 저장소 sample-infra에 커밋하여 트리거를 수동으로 호출할 수 있습니다.

1. Cloud Build 트리거를 호출하려면 저장소의 파일에 새 줄을 추가합니다. 그런 다음 변경사항을 푸시합니다.

   1. Cloud Shell에서 Git을 사용한 적이 없으면 이름과 이메일 주소를 사용하여 Git을 구성합니다. Git은 이 정보를 사용하여 Cloud Shell에서 만드는 커밋의 작성자를 식별합니다.

      git config --global user.email "GITHUB_EMAIL_ADDRESS"
      git config --global user.name "GITHUB_USERNAME"
      

      다음을 바꿉니다.

      • GITHUB_EMAIL_ADDRESS: GitHub 계정과 연결된 이메일 주소
      • GITHUB_USERNAME: GitHub 계정과 연결된 사용자 이름

   2. sample-infra 저장소 클론

      git clone https://github.com/GITHUB_ORG/sample-infra
      
      cd sample-infra
      

      다음을 바꿉니다.

      • GITHUB_ORG를 GitHub 조직으로 바꿉니다.

      기본 브랜치 cicd-trigger가 체크아웃됩니다.

   3. env/cicd-trigger/main.tf 파일에 새 줄을 추가하고 변경사항을 커밋한 후 푸시합니다.

        echo "" >> env/cicd-trigger/main.tf
      

   4. 변경사항을 커밋하고 푸시합니다.

      git add .
      git commit -m "A dummy commit to invoke the infrastrucutre trigger"
      git push
      cd ..
      

      변경사항이 푸시되는 즉시 Cloud Deploy 트리거 deploy-infra-sample이 시작됩니다.

2. 트리거 상태를 모니터링

   Cloud Build 기록 페이지로 이동하여 파이프라인을 확인하고 완료될 때까지 기다립니다.

애플리케이션 CI/CD 리소스 검토

애플리케이션에 대해 만든 다양한 CI/CD 리소스를 검토합니다.

1. Google Cloud 콘솔 사용

   Cloud Build 페이지로 이동하고 deploy-app-sample 트리거를 확인합니다.

   이것은 CI 파이프라인 트리거입니다. 애플리케이션 코드 저장소 sample에 연결됩니다. 애플리케이션 저장소에 푸시가 수행될 때 트리거가 호출되고 트리거 구성에 정의된 대로 빌드 단계를 수행합니다. 호출 시 트리거가 수행하는 단계를 보려면 트리거 이름을 클릭한 후 편집기 열기 버튼을 클릭합니다.

2. Artifact Registry 페이지로 이동하고 이름이 sample인 새 저장소를 확인합니다.

   이 아티팩트 저장소는 애플리케이션의 아티팩트를 저장합니다.

3. Cloud Deploy 파이프라인 페이지로 이동하고 이름이 sample인 파이프라인을 확인합니다. 이것은 GKE 클러스터에 애플리케이션을 배포하는 지속적 배포 파이프라인입니다.

개발 환경에 애플리케이션 배포

deploy-app-sample 트리거는 sample이라는 애플리케이션 저장소에 연결됩니다. 웹훅 URL을 사용하거나 애플리케이션 저장소 푸시를 통해 수동으로 트리거를 호출할 수 있습니다.

1. sample 저장소의 파일에 새 줄을 추가하고 변경사항을 푸시하여 Cloud Build 트리거를 호출합니다.

   1. sample 저장소 클론

      Cloud Shell에서 다음을 실행합니다.

      git clone https://github.com/GITHUB_ORG/sample
      
      cd sample
      

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

   2. skaffold.yaml 파일에 새 줄을 추가합니다.

        echo "" >> skaffold.yaml
      

   3. 변경사항을 커밋하고 푸시합니다.

      git add .
      git commit -m "A dummy commit to invoke CI/CD trigger"
      git push
      

   4. 변경사항이 푸시되는 즉시 Cloud Deploy 트리거 deploy-app-sample이 시작됩니다.

2. 트리거 상태를 모니터링

   Cloud Build 기록 페이지로 이동하여 파이프라인을 확인하고 완료될 때까지 기다립니다.

   트리거는 해당 구성에 정의된 단계를 실행합니다. 첫 번째 단계는 sample 저장소에서 애플리케이션 코드로부터 Docker 이미지를 빌드하는 것입니다. 마지막 단계는 개발 GKE 클러스터에서 애플리케이션을 배포하는 Cloud Deploy 파이프라인을 시작하는 것입니다.

3. 개발 클러스터에서 배포를 확인합니다.

   Cloud Deploy 파이프라인 페이지로 이동

   sample 파이프라인을 클릭하여 개발 GKE 클러스터에 대한 배포가 시작되었습니다. 완료될 때까지 기다립니다.

애플리케이션이 성공적으로 배포되었는지 확인

1. 개발 클러스터에 대한 사용자 인증 정보를 가져옵니다.

   gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a
   

2. GKE 클러스터로 터널링합니다.

   gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a && kubectl port-forward --namespace sample $(kubectl get pod --namespace sample --selector="deploy.cloud.google.com/delivery-pipeline-id=sample" --output jsonpath='{.items[0].metadata.name}') 8080:8080
   

3. Cloud Shell 툴바에서 다음을 클릭합니다.

   웹 미리보기를 클릭한 후 포트 8080에서 미리보기를 클릭합니다.

   출력은 다음과 같습니다.

   Hello World!
   

4. Cloud Shell에서 CTRL+C를 눌러 포트 전달을 종료합니다.

애플리케이션에 새 기능 추가

새 기능을 개발할 때는 변경사항을 테스트하고 반복하기 위해 개발 환경에 신속하게 배포해야 합니다. 이 튜토리얼에서는 애플리케이션 코드 저장소를 변경하고 이를 개발 환경에 배포합니다.

1. Cloud Shell에서 디렉터리를 이미 클론된 sample 저장소로 변경합니다.

2. 애플리케이션을 업데이트하여 다른 메시지를 출력합니다.

     sed -i "s/Hello World/My new feature/g" main.py
   

3. 변경사항을 커밋하고 푸시합니다.

   git add .
   git commit -m "Changed the message"
   git push
   

   코드가 GitHub 저장소로 푸시되면 웹훅 트리거 deploy-app-sample이 시작됩니다.

4. Cloud Build 기록 페이지에서 트리거 상태를 모니터링하고 완료될 때까지 기다립니다.

5. Cloud Deploy 파이프라인 페이지로 이동

   sample 파이프라인을 클릭하여 개발 GKE 클러스터에 대한 배포가 시작되었습니다. 완료될 때까지 기다립니다.

애플리케이션이 성공적으로 배포되었는지 확인

1. 새 Cloud Shell을 열었으면 개발 클러스터에 대한 사용자 인증 정보를 가져옵니다.

   gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a
   

2. GKE 클러스터로 터널링합니다.

   gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a && kubectl port-forward --namespace sample $(kubectl get pod --namespace sample --selector="deploy.cloud.google.com/delivery-pipeline-id=sample" --output jsonpath='{.items[0].metadata.name}') 8080:8080
   

3. Cloud Shell 툴바에서 다음을 클릭합니다.

   웹 미리보기를 클릭한 후 포트 8080에서 미리보기를 클릭합니다.

   

   출력은 다음과 같습니다.

   My new feature!
   

4. Cloud Shell에서 CTRL+C를 눌러 포트 전달을 종료합니다.

스테이징 및 프로덕션 클러스터로 변경사항 승격

스테이징 및 프로덕션 환경으로 애플리케이션을 승격하려면 먼저 이러한 환경에 대해 GKE 클러스터에서 애플리케이션의 시작 영역을 만들어야 합니다. 애플리케이션을 온보딩할 때 개발 브랜치에서 코드를 acm-gke-infrastructure-repo에 추가하여 개발 GKE 클러스터에 개발 시작 영역이 자동으로 생성되었습니다.

스테이징 및 프로덕션 GKE 클러스터에서 시작 영역 만들기

1. 스테이징 GKE 클러스터에서 시작 영역 만들기: acm-gke-infrastructure-repo의 개발 브랜치에서 스테이징 브랜치로 pull 요청을 만들고 병합해야 합니다.

   1. GitHub로 가서 acm-gke-infrastructure-repo 저장소로 이동합니다. Pull requests, New pull request 버튼을 차례로 클릭합니다. 기본 메뉴에서 스테이징을 선택하고 비교 메뉴에서 개발을 선택합니다. Create pull request 버튼을 클릭합니다.

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

   구성 동기화는 acm-gke-infrastructure-repo 저장소의 스테이징 브랜치에 도달하는 변경 사항을 GKE 클러스터와 동기화하며, 이로 인해 스테이징 GKE 클러스터의 애플리케이션에 대한 시작 영역이 생성됩니다.

2. 프로덕션 GKE 클러스터에서 시작 영역 만들기: 스테이징에서 프로덕션 브랜치로 pull 요청을 만들고 병합해야 합니다.

   1. Pull requests, New pull request 버튼을 차례로 클릭합니다. 기본 메뉴에서 prod를 선택하고 비교 메뉴에서 스테이징을 선택합니다. Create pull request 버튼을 클릭합니다.

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

   구성 동기화는 acm-gke-infrastructure-repo 저장소의 프로덕션 브랜치에 도달한 변경사항을 프로덕션 GKE 클러스터와 동기화하며, 이로 인해 프로덕션 GKE 클러스터의 애플리케이션에 대한 시작 영역이 생성됩니다.

개발에서 스테이징으로 변경사항 승격

이제 스테이징 및 프로덕션 GKE 클러스터에서 애플리케이션의 시작 영역을 만들었으므로 애플리케이션을 개발 환경에서 스테이징 환경으로 승격합니다.

1. 최신 출시 버전 이름을 찾아 환경 변수로 저장합니다.

     export RELEASE=$(gcloud deploy targets describe dev --region=us-central1 --format="json" | jq -r '."Active Pipeline"[0]."projects/PROJECT_ID/locations/us-central1/deliveryPipelines/sample"."Latest release"' | awk -F '/' '{print $NF}')
    

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

   환경 변수가 설정되었는지 확인합니다.

     echo $RELEASE
     

2. Cloud Shell에서 다음 명령어를 실행하여 개발에서 스테이징 환경으로의 출시 버전 승격을 트리거합니다.

    gcloud deploy releases promote --release=$RELEASE --delivery-pipeline=sample  --region=us-central1 --to-target=staging --quiet
    

3. 스테이징 배포 확인

   Cloud Deploy 파이프라인 페이지로 이동

   sample 파이프라인을 클릭하여 스테이징 GKE 클러스터에 대한 배포가 시작되었습니다. 완료될 때까지 기다립니다.

4. 스테이징 배포가 성공적으로 수행되었는지 확인합니다.

   1. 스테이징 클러스터에 대한 사용자 인증 정보를 가져옵니다.

      gcloud container clusters get-credentials gke-staging-us-central1 --zone us-central1-a
      

   2. GKE 클러스터로 터널링합니다.

      gcloud container clusters get-credentials gke-staging-us-central1 --zone us-central1-a && kubectl port-forward --namespace sample $(kubectl get pod --namespace sample --selector="deploy.cloud.google.com/delivery-pipeline-id=sample" --output jsonpath='{.items[0].metadata.name}') 8080:8080
      

   3. Cloud Shell 툴바에서 다음을 클릭합니다.

      웹 미리보기를 클릭한 후 포트 8080에서 미리보기를 클릭합니다.

      

      출력은 다음과 같습니다.

      My new feature!
      

   4. Cloud Shell에서 CTRL+C를 눌러 포트 전달을 종료합니다.

스테이징에서 프로덕션으로 변경사항 승격

이제 출시 버전을 스테이징에서 프로덕션으로 승격합니다. 프로덕션 클러스터가 2개 있고 Cloud Deploy에는 각각 prod1 및 prod2라는 대상이 있습니다.

1. Cloud Shell에서 다음 명령어를 실행하여 스테이징에서 prod1 클러스터로 출시 버전 승격을 트리거합니다.

    gcloud deploy releases promote --release=$RELEASE --delivery-pipeline=sample  --region=us-central1 --to-target=prod1 --quiet
    

2. 프로덕션 클러스터를 출시하려면 승인이 필요하므로 승인이 이루어질 때까지 대기합니다. 확인하려면 다음 안내를 따르세요.

   Cloud Deploy 파이프라인 페이지로 이동

   sample 파이프라인을 클릭합니다. prod1에 출시하려면 승인이 필요하며 출시를 승인하려면 clouddeploy.approver 역할이 필요합니다. 프로젝트 소유자이므로 출시를 승인할 수 있는 액세스 권한이 있습니다.

3. prod1에 출시를 승인합니다.

   다음 명령어를 실행하여 승인 대기 중인 출시 이름을 가져오고 이를 환경 변수에 저장합니다.

    export ROLLOUT=$(gcloud deploy targets describe prod1 --region=us-central1 --format="json" | jq -r '."Pending Approvals"[]' | awk -F '/' '{print $NF}')
    

   출시 버전 승인

    gcloud deploy rollouts approve $ROLLOUT --delivery-pipeline=sample --region=us-central1 --release=$RELEASE --quiet
    

4. 승인되면 prod1 출시가 시작됩니다. Cloud Deploy 파이프라인 페이지에서 진행 상황을 모니터링합니다.

5. prod1 배포가 완료되면 prod2 출시를 시작합니다.

    gcloud deploy releases promote --release=$RELEASE --delivery-pipeline=sample  --region=us-central1 --to-target=prod2 --quiet
    

6. prod2 출시에도 승인이 필요합니다. prod2 클러스터에 대한 출시를 승인합니다.

   다음 명령어를 실행하여 승인 대기 중인 출시 이름을 가져오고 이를 환경 변수에 저장합니다.

    export ROLLOUT=$(gcloud deploy targets describe prod2 --region=us-central1 --format="json" | jq -r '."Pending Approvals"[]' | awk -F '/' '{print $NF}')
    

   출시 버전 승인

    gcloud deploy rollouts approve $ROLLOUT --delivery-pipeline=sample --region=us-central1 --release=$RELEASE --quiet
    

   참고: Cloud Deploy를 사용하면 여러 GKE 클러스터에서 동시 배포를 수행하여 여러 프로덕션 클러스터에 동시에 배포할 수 있습니다. 자세한 내용은 Cloud Deploy를 사용한 동시 배포를 참조하세요.

7. 승인되면 prod2 출시가 시작됩니다. Cloud Deploy 파이프라인 페이지에서 진행 상황을 모니터링합니다.

8. prod1 및 prod2에서 Cloud Deploy 파이프라인이 완료된 후 프로덕션 클러스터에서 배포가 성공했는지 확인합니다.

   1. 프로덕션 클러스터에 멀티 클러스터 인그레스가 생성되며, 부하 분산기를 사용하여 프로덕션 애플리케이션에 액세스합니다. 이 멀티 클러스터 인그레스 구성은 sample 저장소의 YAML 파일 k8s/prod/mci.yaml 및 k8s/prod/mcs.yaml을 사용하여 생성됩니다. 부하 분산기의 IP 주소로 요청을 보내면 멀티 클러스터 인그레스가 2개의 서로 다른 GKE 클러스터에서 실행되는 애플리케이션의 두 인스턴스 중 하나로 요청을 전달합니다.

   2. 부하 분산기에 연결된 전달 규칙을 나열하여 IP 주소를 찾습니다.

      gcloud compute forwarding-rules list
      

   3. 다음과 유사한 결과가 출력됩니다.

      NAME: mci-qqxs9x-fw-sample-sample-ingress
      REGION:
      IP_ADDRESS: 34.36.123.118
      IP_PROTOCOL: TCP
      TARGET: mci-qqxs9x-sample-sample-ingress
      

   4. 웹브라우저를 열고 URL에 다음을 입력합니다.

      http://IP_ADDRESS:80
      

      IP_ADDRESS를 부하 분산기의 IP 주소로 바꿉니다.

      출력은 다음과 같습니다.

      My new feature!
      

      이렇게 하면 애플리케이션이 프로덕션 클러스터에 예상대로 배포되었는지 확인할 수 있습니다.

애플리케이션의 복원력 테스트

이 섹션에서는 애플리케이션에 영향을 주지 않고 2개의 프로덕션 GKE 클러스터 노드 중 하나를 다시 시작하여 프로덕션에서 실행 중인 애플리케이션의 복원력을 테스트합니다.

프로덕션의 애플리케이션은 멀티 클러스터 인그레스를 사용하며 부하 분산기 IP를 통해 액세스할 수 있습니다. 이 IP를 통해 애플리케이션에 액세스할 때 멀티 클러스터 인그레스는 2개의 서로 다른 GKE 클러스터에서 실행 중인 애플리케이션의 두 인스턴스 중 하나로 이를 라우팅합니다. GKE 클러스터 중 하나가 정상 상태가 아니고 여기에서 실행 중인 애플리케이션 인스턴스에 연결할 수 없으면 멀티 클러스터 인그레스가 다른 GKE 클러스터에서 실행 중인 정상 상태의 애플리케이션 인스턴스로 트래픽을 계속 전송합니다. 이렇게 하면 클러스터 중단을 최종 사용자에게 표시하지 않고 애플리케이션이 요청을 계속 처리할 수 있습니다.

복원력을 테스트하려면 다음 안내를 따르세요.

1. us-west1에서 실행 중인 프로덕션 GKE 클러스터의 노드 풀을 찾습니다.

    gcloud container clusters describe gke-prod-us-west1 --zone=us-west1-a --format=json | jq ".nodePools[0].instanceGroupUrls[]" | tr '"' ' ' |  awk -F '/' '{for(i=NF-2; i<=NF; i=i+2) printf ("%s ",$i); print  ""}'
   

2. 다음과 유사한 결과가 출력됩니다.

   us-west1-b gke-gke-prod-us-west1-node-pool-01-6ad4e1ed-grp
   us-west1-c gke-gke-prod-us-west1-node-pool-01-98407373-grp
   

   출력에는 2개 열이 포함됩니다. 첫 번째 열은 영역이고 두 번째 열은 us-west1 리전에서 프로덕션 GKE 클러스터의 노드 풀과 연결된 인스턴스 그룹의 이름입니다.

3. 노드 풀에 따라 인스턴스 그룹을 다시 시작합니다.

    gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_1  --zone=ZONE_1 --max-unavailable=100%
   
    gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_2  --zone=ZONE_2 --max-unavailable=100%
   

   INSTANCE_GROUP_1을 첫 번째 인스턴스 그룹의 이름으로 바꿉니다.

   ZONE_1을 두 번째 인스턴스 그룹의 영역으로 바꿉니다.

   INSTANCE_GROUP_2를 두 번째 인스턴스 그룹의 이름으로 바꿉니다.

   ZONE_2를 두 번째 인스턴스 그룹의 영역으로 바꿉니다.

4. 인스턴스 그룹의 상태를 확인합니다.

   인스턴스 그룹 페이지로 이동

   두 인스턴스 그룹이 재부팅되고 다른 그룹에는 녹색 체크표시가 표시됩니다.

   

5. 웹브라우저를 열고 URL에 다음을 입력합니다.

   http://IP_ADDRESS:80
   

   IP_ADDRESS를 부하 분산기의 IP 주소로 바꿉니다.

   2개의 GKE 클러스터 중 하나가 작동 중지되더라도 애플리케이션을 사용할 수 있고 다음과 같이 출력됩니다.

    My new feature!
    

   이는 애플리케이션의 복원력과 고가용성을 보여줍니다.

애플리케이션 관리

애플리케이션 팩토리에서 이 애플리케이션을 만들었으면 애플리케이션에 대해 별개의 git 저장소, 인프라, CI/CD 파이프라인이 생성됩니다. 여기에서는 이러한 리소스를 사용해서 애플리케이션을 배포하고 새 기능을 추가했습니다. 추가적인 애플리케이션 관리를 위해서는 애플리케이션 팩토리를 업데이트할 필요 없이 이러한 git 저장소 및 파이프라인과의 상호작용만 필요합니다. 요구사항에 따라 애플리케이션의 파이프라인 및 git 저장소를 맞춤설정할 수 있습니다. 애플리케이션 소유자는 애플리케이션의 파이프라인 및 git 저장소에 액세스하여 이를 관리할 수 있는 사용자를 정의할 수 있습니다.

삭제

이 튜토리얼에서 사용한 리소스 비용이 Google Cloud 계정에 청구되지 않도록 하려면 다음 안내를 따르세요.

프로젝트 삭제

주의: 프로젝트를 삭제하면 다음과 같은 효과가 발생합니다.
• 프로젝트의 모든 항목이 삭제됩니다. 이 문서의 태스크에 기존 프로젝트를 사용한 경우 프로젝트를 삭제하면 프로젝트에서 수행한 다른 작업도 삭제됩니다.
• 커스텀 프로젝트 ID가 손실됩니다. 이 프로젝트를 만들 때 앞으로 사용할 커스텀 프로젝트 ID를 만들었을 수 있습니다. appspot.com URL과 같이 프로젝트 ID를 사용하는 URL을 보존하려면 전체 프로젝트를 삭제하는 대신 프로젝트 내에서 선택한 리소스만 삭제합니다.
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.

다음 단계

• ID 제휴 설정 권장사항 알아보기
• Kubernetes 및 지속적 소프트웨어 배포 과제 읽기
• 하이브리드 및 멀티 클라우드 모니터링과 로깅 패턴 알아보기
• Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기 Cloud 아키텍처 센터 살펴보기