이 배포 가이드에서는 Google Cloud 도구의 통합 집합을 사용해서 개발, 지속적 통합(CI), 지속적 배포(CD) 시스템을 설정하고 사용하는 방법을 설명합니다. 이 시스템을 사용하여 애플리케이션을 개발하고 Google Kubernetes Engine(GKE)에 배포할 수 있습니다.
이 가이드에서는 컨테이너화된 앱 개발 및 제공을 위한 배포 파이프라인에 설명된 아키텍처를 만드는 방법을 설명합니다.
이 배포 가이드는 소프트웨어 개발자 및 운영자를 모두 대상으로 하며, 다음 역할이 수행됩니다.
- 먼저 운영자로서 CI/CD 파이프라인을 설정합니다. 이 파이프라인의 기본 구성요소는 Cloud Build, Artifact Registry, Cloud Deploy입니다.
- 그런 다음 개발자 역할로 Cloud Code를 사용해 애플리케이션을 변경합니다. 개발자로 활동할 때 이 파이프라인이 제공하는 통합 환경이 표시됩니다.
- 마지막으로 운영자 역할을 하며 애플리케이션을 프로덕션에 배포하는 단계를 진행합니다.
이 배포 가이드에서는 사용자가 Google Cloud에서 gcloud 명령어를 실행하고 GKE에 애플리케이션 컨테이너를 배포하는 데 익숙하다고 가정합니다.
아키텍처
다음 다이어그램은 이 배포 가이드에서 사용되는 리소스를 보여줍니다.
이 아키텍처에서 사용되는 구성요소에 대한 자세한 내용은 컨테이너화된 앱 개발 및 제공을 위한 배포 파이프라인을 참조하세요.
목표
운영자 역할로 다음을 수행합니다.
- CI 파이프라인과 CD 파이프라인을 설정합니다. 이 설정에는 다음이 포함됩니다.
- 필요한 권한을 설정합니다.
- 스테이징 및 프로덕션 환경에서 사용할 GKE 클러스터를 만듭니다.
- Cloud Source Repositories에 소스 코드를 위한 저장소를 만듭니다.
- 애플리케이션 컨테이너에 대해 Artifact Registry에 저장소를 만듭니다.
- 기본 GitHub 저장소에 Cloud Build 트리거를 만듭니다.
- Cloud Deploy 배포 파이프라인 및 대상을 만듭니다. 대상은 스테이징 및 프로덕션 환경입니다.
- 스테이징 배포를 위해 CI/CD 프로세스를 시작한 후 프로덕션으로 승격합니다.
개발자 역할로 애플리케이션을 변경합니다. 이를 위해 다음을 수행합니다.
- 사전 구성된 개발 환경으로 작업할 수 있도록 저장소를 클론합니다.
- 개발자 작업공간 내에서 애플리케이션을 변경합니다.
- 변경사항을 빌드하고 테스트합니다. 테스트에는 거버넌스 검증 테스트가 포함됩니다.
- 개발 클러스터에서 변경사항을 보고 검증합니다. 이 클러스터는 minikube에서 실행됩니다.
- 변경사항을 기본 저장소에 커밋합니다.
비용
이 문서에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.
- Cloud Build
- Cloud Deploy
- Artifact Registry
- Google Kubernetes Engine
- Cloud Source Repositories
- Cloud Storage
프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요.
이 문서에 설명된 태스크를 완료했으면 만든 리소스를 삭제하여 청구가 계속되는 것을 방지할 수 있습니다. 자세한 내용은 삭제를 참조하세요.
시작하기 전에
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
Enable the Artifact Registry, Cloud Build, Cloud Deploy, Cloud Source Repositories, Google Kubernetes Engine, Resource Manager, and Service Networking APIs.
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
개발 환경 준비
이 섹션에서는 애플리케이션 운영자 역할로 다음 작업을 수행합니다.
- 필요한 권한을 설정합니다.
- 스테이징 및 프로덕션 환경에서 사용할 GKE 클러스터를 만듭니다.
- 소스 저장소를 클론합니다.
- Cloud Source Repositories에 소스 코드를 위한 저장소를 만듭니다.
- Artifact Registry에 컨테이너 애플리케이션을 위한 저장소를 만듭니다.
권한 설정
이 섹션에서는 CI/CD 파이프라인 설정에 필요한 권한을 부여합니다.
Cloud Shell 편집기의 새 인스턴스에서 작업하는 경우 이 배포 가이드에서 사용할 프로젝트를 지정합니다.
gcloud config set project PROJECT_IDPROJECT_ID를 이 배포 가이드용으로 선택했거나 만든 프로젝트의 ID로 바꿉니다.
대화상자가 표시되면 승인을 클릭합니다.
기본 Compute Engine 서비스 계정에 Cloud Deploy에서 작업을 실행하고 Artifact Registry에서 컨테이너를 가져올 수 있는 충분한 권한이 있는지 확인합니다. Cloud Build 및 Cloud Deploy는 이 기본 서비스 계정을 사용합니다.
이 서비스 계정에 이미 필요한 권한이 있을 수 있습니다. 이 단계를 통해 기본 서비스 계정의 자동 역할 부여를 사용 중지하는 프로젝트에 필요한 권한이 부여됩니다.
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:$(gcloud projects describe PROJECT_ID \ --format="value(projectNumber)")-compute@developer.gserviceaccount.com \ --role="roles/clouddeploy.jobRunner" gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:$(gcloud projects describe PROJECT_ID \ --format="value(projectNumber)")-compute@developer.gserviceaccount.com \ --role="roles/artifactregistry.reader"Cloud Build 서비스 계정에 Cloud Deploy를 사용하여 배포를 호출하고 배포 파이프라인 및 대상 정의를 업데이트할 수 있는 권한을 부여합니다.
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:$(gcloud projects describe PROJECT_ID \ --format="value(projectNumber)")@cloudbuild.gserviceaccount.com \ --role="roles/clouddeploy.operator"이 IAM 역할에 대한 자세한 내용은 clouddeploy.operator 역할을 참조하세요.
Cloud Build 및 Cloud Deploy 서비스 계정에 GKE에 배포할 수 있는 권한을 부여합니다.
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:$(gcloud projects describe PROJECT_ID \ --format="value(projectNumber)")-compute@developer.gserviceaccount.com \ --role="roles/container.admin"이 IAM 역할에 대한 자세한 내용은 container.admin 역할을 참조하세요.
Cloud Build 서비스 계정에 Cloud Deploy 작업을 호출하는 데 필요한 권한을 부여합니다.
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:$(gcloud projects describe PROJECT_ID \ --format="value(projectNumber)")@cloudbuild.gserviceaccount.com \ --role="roles/iam.serviceAccountUser"Cloud Build가 Cloud Deploy를 호출하면 Compute Engine 서비스 계정을 사용하여 출시 버전을 만들기 때문에 이 권한이 필요합니다.
이 IAM 역할에 대한 자세한 내용은 iam.serviceAccountUser 역할을 참조하세요.
CI/CD 파이프라인에 필요한 권한을 부여했습니다.
GKE 클러스터 만들기
이 섹션에서는 둘 다 GKE 클러스터인 스테이징 및 프로덕션 환경을 만듭니다. (Minikube를 사용하기 때문에 여기서는 개발 클러스터를 설정할 필요가 없습니다.)
스테이징 및 프로덕션 GKE 클러스터를 만듭니다.
gcloud container clusters create-auto staging \ --region us-central1 \ --project=$(gcloud config get-value project) \ --async gcloud container clusters create-auto prod \ --region us-central1 \ --project=$(gcloud config get-value project) \ --async스테이징 클러스터에서 코드 변경사항을 테스트합니다. 스테이징의 배포가 애플리케이션에 부정적인 영향을 주지 않는 것이 확인된 후 프로덕션에 배포합니다.
다음 명령어를 실행하고 스테이징 및 프로덕션 클러스터 모두 출력에
STATUS: RUNNING이 포함되어 있는지 확인합니다.gcloud container clusters list스테이징 및 프로덕션 클러스터의
kubeconfig파일에 대한 사용자 인증 정보를 가져옵니다.gcloud container clusters get-credentials staging --region us-central1 gcloud container clusters get-credentials prod --region us-central1이 사용자 인증 정보를 사용하여 GKE 클러스터와 상호작용합니다(예: 애플리케이션이 제대로 실행 중인지 확인).
스테이징 및 프로덕션 환경에 사용할 GKE 클러스터가 생성되었습니다.
IDE 열기 및 저장소 클론
저장소를 클론하고 개발 환경에서 애플리케이션을 보려면 다음을 수행합니다.
GitHub 저장소를 Cloud Shell에 클론합니다.
확인을 클릭합니다.
Cloud Shell 편집기가 열리고 샘플 저장소가 클론됩니다.
이제 Cloud Shell 편집기에서 애플리케이션 코드를 볼 수 있습니다.
이 배포 가이드에 사용할 프로젝트를 지정합니다.
gcloud config set project PROJECT_ID대화상자가 표시되면 승인을 클릭합니다.
이제 개발 환경에서 애플리케이션의 소스 코드가 준비되었습니다.
이 소스 저장소에는 CI/CD 파이프라인에 필요한 Cloud Build 및 Cloud Deploy 파일이 포함되어 있습니다.
소스 코드 및 컨테이너를 위한 저장소 만들기
이 섹션에서는 Cloud Source Repositories에서 소스 코드를 위한 저장소를 설정하고 Artifact Registry에는 CI/CD 파이프라인에서 빌드된 컨테이너를 저장하는 저장소를 설정합니다.
Cloud Source Repositories에서 소스 코드를 저장할 저장소를 만들고 이를 CI/CD 프로세스와 연결합니다.
gcloud source repos create cicd-sampleCloud Deploy 구성이 올바른 프로젝트를 타겟팅하는지 확인합니다.
sed -i s/project-id-placeholder/$(gcloud config get-value project)/g deploy/* git config --global credential.https://source.developers.google.com.helper gcloud.sh git remote add google https://source.developers.google.com/p/$(gcloud config get-value project)/r/cicd-sample소스 코드를 저장소에 푸시합니다.
git push --all googleArtifact Registry에서 이미지 저장소를 만듭니다.
gcloud artifacts repositories create cicd-sample-repo \ --repository-format=Docker \ --location us-central1
이제 Cloud Source Repositories에서 소스 코드에 대해 저장소가 준비되었고 Artifact Registry의 애플리케이션 컨테이너에 대해서도 저장소가 준비되었습니다. Cloud Source Repositories 저장소를 사용하면 소스 코드를 클론하고 이를 CI/CD 파이프라인에 연결할 수 있습니다.
CI/CD 파이프라인 구성
이 섹션에서는 애플리케이션 운영자로서 CI/CD 파이프라인을 구성합니다. 이 파이프라인에서는 CI에 대해 Cloud Build가 사용되고 CD에 대해서는 Cloud Deploy가 사용됩니다. 파이프라인 단계는 Cloud Build 트리거에 정의되어 있습니다.
Cloud Build용 Cloud Storage 버킷을 만들어
artifacts.json파일을 저장합니다. 이 파일은 각 빌드에서 Skaffold로 생성된 아티팩트를 추적합니다.gcloud storage buckets create gs://$(gcloud config get-value project)-gceme-artifacts/각 빌드의
artifacts.json파일을 한곳에 저장하는 것이 좋습니다. 이렇게 하면 추적이 가능해져 문제 해결이 쉬워집니다.Cloud Build 트리거를 정의하는
cloudbuild.yaml파일을 검토합니다. 이 파일은 클론한 소스 저장소에 이미 구성되어 있습니다.이 파일은 소스 코드 저장소의 기본 분기에 새 푸시가 수행될 때마다 호출되는 트리거를 정의합니다.
CI/CD 파이프라인의 다음 단계는
cloudbuild.yaml파일에 정의되어 있습니다.Cloud Build에서 Skaffold를 사용하여 애플리케이션 컨테이너를 빌드합니다.
Cloud Build가 빌드의
artifacts.json파일을 Cloud Storage 버킷에 배치합니다.Cloud Build가 애플리케이션 컨테이너를 Artifact Registry에 배치합니다.
Cloud Build가 애플리케이션 컨테이너에서 테스트를 실행합니다.
gcloud deploy apply명령어가 다음 파일을 Cloud Deploy 서비스에 등록합니다.- 배포 파이프라인:
deploy/pipeline.yaml - 대상 파일:
deploy/staging.yaml및deploy/prod.yaml
파일이 등록되면 Cloud Deploy가 파이프라인 및 대상이 아직 없는 경우 이를 만듭니다. 또는 구성이 변경된 경우에도 이를 다시 만듭니다. 대상은 스테이징 및 프로덕션 환경입니다.
- 배포 파이프라인:
Cloud Deploy에서 배포 파이프라인을 위한 새 출시 버전을 만듭니다.
이 출시 버전에서는 CI 프로세스로 빌드 및 테스트된 애플리케이션 컨테이너가 참조됩니다.
Cloud Deploy가 출시 버전을 스테이징 환경에 배포합니다.
배포 파이프라인과 대상은 Cloud Deploy에서 관리되며 소스 코드와 분리됩니다. 이처럼 분리되기 때문에 애플리케이션의 소스 코드가 변경될 때 배포 파이프라인과 대상 파일을 업데이트할 필요가 없습니다.
Cloud Build 트리거를 만듭니다.
gcloud beta builds triggers create cloud-source-repositories \ --name="cicd-sample-main" \ --repo="cicd-sample" \ --branch-pattern="main" \ --build-config="cloudbuild.yaml"이 트리거는 Cloud Build에 소스 저장소를 감시하고
cloudbuild.yaml파일을 사용해서 저장소 변경사항에 대응하도록 지정합니다. 이 트리거는 기본 분기에 새 푸시가 수행될 때마다 호출됩니다.Google Cloud 콘솔에서 Cloud Build 페이지로 이동합니다.
애플리케이션에 대한 빌드가 없는 것을 확인합니다.
CI 및 CD 파이프라인을 설정했고 저장소의 기본 분기에 트리거를 만들었습니다.
개발자 작업공간 내에서 애플리케이션을 변경합니다.
이 섹션에서는 애플리케이션 개발자 역할을 수행합니다.
애플리케이션을 개발할 때 Cloud Code를 개발 작업공간으로 사용하여 애플리케이션을 반복적으로 변경하고 변경사항을 확인합니다.
- 애플리케이션을 변경합니다.
- 새 코드를 빌드하고 테스트합니다.
- minikube 클러스터에 애플리케이션을 배포하고 사용자 대면 변경사항을 확인합니다.
- 기본 저장소에 변경사항을 제출합니다.
이 변경사항이 기본 저장소에 커밋되면 Cloud Build 트리거가 CI/CD 파이프라인을 시작합니다.
애플리케이션 빌드, 테스트, 실행
이 섹션에서는 애플리케이션을 빌드, 테스트, 배포, 액세스합니다.
이전 섹션에서 사용한 동일한 Cloud Shell 편집기 인스턴스를 사용합니다. 편집기를 닫았으면 브라우저에서 ide.cloud.google.com으로 이동하여 Cloud Shell 편집기를 엽니다.
터미널에서 Minikube를 시작합니다.
minikube startMinikube가 Cloud Shell에서 로컬 Kubernetes 클러스터를 설정합니다. 이 설정을 실행하는 데 몇 분 정도 걸립니다. 설정이 완료되면 Minikube 프로세스가 Cloud Shell 인스턴스의 백그라운드에서 실행됩니다.
창의 Cloud Shell 편집기 하단에서 Cloud Code를 선택합니다.
터미널과 편집기 사이에 표시된 얇은 패널에서 Kubernetes에서 실행을 선택합니다.
Use current context (minikube) to run the app?이라는 메시지가 표시되면 예를 클릭합니다.이 명령어는 소스 코드를 빌드하고 테스트를 실행합니다. 몇 분 정도 걸릴 수 있습니다. 테스트에는 단위 테스트와 배포 환경의 규칙 집합을 확인하는 사전 구성된 검증 단계가 포함되어 있습니다. 이렇게 하면 개발 환경에서 작업하는 중에도 배포 문제가 있을 때 경고가 표시됩니다.
출력 탭에는 애플리케이션을 빌드하고 배포하는 Skaffold 진행 상태가 표시됩니다.
해당 섹션 내내 이 탭을 열어두세요.
빌드 및 테스트가 완료되면 출력 탭에
Update succeeded가 표시되고 2개의 URL이 표시됩니다.앱을 빌드하고 테스트할 때 Cloud Code가 출력 탭에 로그와 URL을 다시 스트리밍합니다. 개발 환경에서 변경하고 테스트를 실행할 때 개발 환경의 앱 버전을 보고 올바르게 작동하는지 확인할 수 있습니다.
출력에는
Watching for changes...도 표시됩니다. 감시 모드가 사용 설정되었다는 의미입니다. Cloud Code가 감시 모드인 경우 서비스에서 저장소에 저장된 변경사항을 감지하고 최신 변경사항으로 앱을 자동으로 재빌드하여 다시 배포합니다.Cloud Code 터미널에서 출력의 첫 번째 URL(
http://localhost:8080) 위에 마우스 포인터를 올려놓습니다.도움말이 나타나면 웹 미리보기 열기를 선택합니다.
백그라운드에서 Cloud Code가 Minikube에서 실행되는
cicd-sample서비스로의 트래픽 포트 전달을 자동으로 진행합니다.브라우저에서 페이지를 새로고침합니다.
카운터 옆에 있는 숫자가 늘어나 앱이 새로고침에 응답하고 있음을 나타냅니다.
브라우저에서 로컬 환경을 변경할 때 애플리케이션을 볼 수 있도록 이 페이지를 열어둡니다.
개발 환경에서 애플리케이션을 빌드하고 테스트했습니다. Minikube에서 실행되는 개발 클러스터에 애플리케이션을 배포하고 사용자 대상의 애플리케이션 동작을 확인했습니다.
변경
이 섹션에서는 애플리케이션을 변경하고 앱이 개발 클러스터에서 실행될 때 변경사항을 확인합니다.
Cloud Shell 편집기에서
index.html파일을 엽니다.Sample App Info문자열을 검색하여 제목에 소문자가 사용되도록sample app info로 변경합니다.파일이 자동으로 저장되고 애플리케이션 컨테이너의 재빌드가 트리거됩니다.
Cloud Code가 변경사항을 감지하고 이를 자동으로 다시 배포합니다. 출력 탭에
Update initiated가 표시됩니다. 이 배포를 실행하는 데 몇 분 정도 걸립니다.이러한 자동 재배포 기능은 Kubernetes 클러스터에서 실행되는 모든 애플리케이션에서 사용할 수 있습니다.
빌드가 완료되면 앱이 열려 있는 브라우저로 이동하여 페이지를 새로고침합니다.
새로고침할 때 텍스트가 소문자를 사용하는지 확인합니다.
이 설정을 사용하면 모든 아키텍처의 모든 구성요소에 대해 자동 새로고침이 수행됩니다. Cloud Code 및 minikube를 사용하는 경우 Kubernetes에서 실행되는 모든 항목에 이 핫 코드 새로고침 기능이 포함됩니다.
Cloud Code에서 Kubernetes 클러스터에 배포된 애플리케이션을 디버그할 수 있습니다. 이 단계는 이 배포 가이드에서 다루지 않습니다. 자세한 내용은 Kubernetes 애플리케이션 디버깅을 참고하세요.
코드 커밋
이제 애플리케이션을 변경했으므로 코드를 커밋할 수 있습니다.
Git ID를 구성합니다.
git config --global user.email "YOU@EXAMPLE.COM" git config --global user.name "NAME"다음을 바꿉니다.
- YOU@EXAMPLE.COM: GitHub 계정에 연결된 이메일 주소입니다.
- NAME: GitHub 계정에 연결된 이름입니다.
터미널에서 코드를 커밋합니다.
git add . git commit -m "use lowercase for: sample app info"여기에서는
git push명령어를 실행할 필요가 없습니다. 이 명령어는 나중에 사용됩니다.
개발 환경에서 애플리케이션을 변경했고, 변경사항을 빌드하고 테스트했으며 이러한 변경사항의 사용자 대상 동작을 확인했습니다. 개발 환경의 테스트에는 프로덕션 환경에서 문제를 일으키는 오류를 해결할 수 있는 거버넌스 확인이 포함됩니다.
이 배포 가이드에서는 코드를 기본 저장소에 커밋할 때 코드 검토를 수행하지 않습니다. 하지만 소프트웨어 개발 시에는 코드 검토 또는 변경 승인 프로세스를 진행하는 것이 좋습니다.
변경 승인 권장사항에 대한 자세한 내용은 스트리밍 변경 승인을 참조하세요.
프로덕션에 변경사항 배포
이 섹션에서는 애플리케이션 운영자 역할로 다음 작업을 수행합니다.
- CI/CD 파이프라인을 트리거하여 출시 버전을 스테이징 환경에 배포합니다.
- 출시 버전을 프로덕션으로 승격하고 승인합니다.
CI/CD 파이프라인 시작 및 스테이징에 배포
이 섹션에서는 Cloud Build 트리거를 호출하여 CI/CD 파이프라인을 시작합니다. 이 트리거는 변경사항이 기본 저장소에 커밋될 때마다 호출됩니다. 수동 트리거로 CI 시스템을 시작할 수도 있습니다.
Cloud Shell 편집기에서 다음 명령어를 실행하여 빌드를 트리거합니다.
git push google이 빌드에는
cicd-sample에 수행한 변경사항이 포함됩니다.Cloud Build 대시보드로 돌아가서 빌드가 생성되었는지 확인합니다.
오른쪽의 빌드 로그에서 Running: cicd-sample - cicd-sample-main을 클릭하고 각 단계의 시작과 끝을 나타내는 파란색 텍스트를 찾습니다.
0단계에서는
cloudbuild.yaml파일의skaffold build및skaffold test명령어의 출력을 보여줍니다. 0단계의 빌드 및 테스트 작업(파이프라인의 CI 부분)을 진행했으므로 1단계의 배포 작업(파이프라인의 CD 부분)이 실행됩니다.이 단계가 완료되고 다음 메시지가 표시됩니다.
Created Cloud Deploy rollout ROLLOUT_NAME in target stagingCloud Deploy 배포 파이프라인 페이지를 열고
cicd-sample delivery파이프라인을 클릭합니다.애플리케이션이 스테이징에 배포되지만 프로덕션에 배포되지 않습니다.
애플리케이션이 스테이징에서 문제 없이 작동하는지 확인합니다.
kubectl proxy --port 8001 --context gke_$(gcloud config get-value project)_us-central1_staging이 명령어는 애플리케이션에 액세스하도록 kubectl 프록시를 설정합니다.
Cloud Shell에서 애플리케이션에 액세스합니다.
Cloud Shell 편집기에서 새 터미널 탭을 엽니다.
localhost에 요청을 보내 카운터를 늘립니다.curl -s http://localhost:8001/api/v1/namespaces/default/services/cicd-sample:8080/proxy/ | grep -A 1 Counter이 명령어를 여러 번 실행하면 매번 카운터 값이 늘어나는 것을 볼 수 있습니다.
앱을 보면 스테이징에 배포한 애플리케이션 버전에서 변경된 텍스트가 표시됨을 확인할 수 있습니다.
이 두 번째 탭을 닫습니다.
첫 번째 탭에서
Control+C를 눌러 프록시를 중지합니다.
Cloud Build 트리거를 호출하여 애플리케이션을 빌드하고, 스테이징 환경에 배포하고, 애플리케이션이 스테이징에서 작동하는지 확인하기 위한 테스트를 실행하는 등 CI 프로세스를 시작했습니다.
스테이징 환경에서 코드 빌드 및 테스트가 통과되면 CI 프로세스가 성공한 것입니다. CI 프로세스가 성공하면 Cloud Deploy에서 CD 시스템이 시작됩니다.
출시 버전을 프로덕션으로 승격
이 섹션에서는 출시 버전을 스테이징에서 프로덕션으로 승격합니다. 프로덕션 대상은 승인이 필요하도록 사전 구성되어 있으므로 수동으로 승인해야 합니다.
자체 CI/CD 파이프라인의 경우 프로덕션으로 전체 배포를 수행하기 전 배포를 점진적으로 실행하는 배포 전략을 사용해야 할 수도 있습니다. 배포를 점진적으로 실행하면 문제를 더 쉽게 감지할 수 있고 필요한 경우 이전 출시 버전을 복원할 수 있습니다.
출시 버전을 프로덕션으로 승격하려면 다음을 수행합니다.
Cloud Deploy 배포 파이프라인 개요를 열고 cicd-sample 파이프라인을 선택합니다.
배포를 스테이징에서 프로덕션으로 승격합니다. 방법은 다음과 같습니다.
페이지 상단의 파이프라인 다이어그램에서 스테이징 상자에 있는 파란색 승격 버튼을 클릭합니다.
열린 창 하단에서 승격 버튼을 클릭합니다.
아직 프로덕션에서 배포가 실행되고 있지 않습니다. 필수적인 수동 승인이 남아 있습니다.
배포를 수동으로 승인합니다.
파이프라인 시각화에서 스테이징 상자와 프로덕션 상자 사이에 있는 검토 버튼을 클릭합니다.
열린 창에서 검토 버튼을 클릭합니다.
다음 창에서 승인을 클릭합니다.
Cloud Deploy 배포 파이프라인 개요로 돌아가서 cicd-sample 파이프라인을 선택합니다.
파이프라인 시각화에서 프로덕션 상자가 녹색(성공적인 출시를 의미)으로 표시되면 애플리케이션에 액세스하는 데 사용하는 kubectl 프록시를 설정하여 애플리케이션이 프로덕션에서 작동하는지 확인합니다.
kubectl proxy --port 8002 --context gke_$(gcloud config get-value project)_us-central1_prodCloud Shell에서 애플리케이션에 액세스합니다.
Cloud Shell 편집기에서 새 터미널 탭을 엽니다.
카운터를 늘립니다.
curl -s http://localhost:8002/api/v1/namespaces/default/services/cicd-sample:8080/proxy/ | grep -A 1 Counter이 명령어를 여러 번 실행하면 매번 카운터 값이 늘어나는 것을 볼 수 있습니다.
이 두 번째 터미널 탭을 닫습니다.
첫 번째 탭에서
Control+C를 눌러 프록시를 중지합니다.
프로덕션 배포를 승격하고 승인했습니다. 이제 최신 변경사항이 포함된 애플리케이션이 프로덕션에서 실행됩니다.
삭제
이 배포 가이드에서 사용된 리소스 비용이 Google Cloud 계정에 청구되지 않도록 하려면 리소스가 포함된 프로젝트를 삭제하거나 프로젝트를 유지하고 개별 리소스를 삭제하세요.
옵션 1: 프로젝트 삭제
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
옵션 2: 개별 리소스 삭제
Cloud Deploy 파이프라인을 삭제합니다.
gcloud deploy delivery-pipelines delete cicd-sample --region=us-central1 --forceCloud Build 트리거를 삭제합니다.
gcloud beta builds triggers delete cicd-sample-main스테이징 및 프로덕션 클러스터를 삭제합니다.
gcloud container clusters delete staging gcloud container clusters delete prodCloud Source Repositories에서 저장소를 삭제합니다.
gcloud source repos delete cicd-sampleCloud Storage 버킷을 삭제합니다.
gcloud storage rm -r gs://$(gcloud config get-value project)-gceme-artifacts/ gcloud storage rm -r gs://$(gcloud config get-value project)_clouddeploy/Artifact Registry에서 저장소를 삭제합니다.
gcloud artifacts repositories delete cicd-sample-repo \ --location us-central1
다음 단계
- 비공개 GKE 인스턴스에 배포하는 방법을 알아보려면 Virtual Private Cloud 네트워크에서 비공개 클러스터에 배포를 참조하세요.
- 배포 자동화를 구현, 개선, 측정하는 방법에 관한 자세한 내용은 배포 자동화를 참고하세요.
- 그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 알아보려면 클라우드 아키텍처 센터를 확인하세요.