개요

이 실습에서는 커밋된 코드로부터 컨테이너 이미지를 자동으로 빌드하는 CI/CD 파이프라인을 만들고, Container Registry에 이미지를 저장하고, Git 저장소의 Kubernetes 매니페스트를 업데이트하고, 이 매니페스트를 사용하여 애플리케이션을 Google Kubernetes Engine에 배포합니다.

이 실습에서는 2개의 Git 저장소를 만듭니다.

• App 저장소: 애플리케이션 자체의 소스 코드를 포함합니다.
• Env 저장소: Kubernetes 배포용 매니페스트를 포함합니다.

변경사항을 app 저장소에 푸시하면 Cloud Build 파이프라인이 테스트를 실행하고, 컨테이너 이미지를 빌드하고, Artifact Registry에 푸시합니다. Cloud Build는 이미지를 푸시한 후 배포 매니페스트를 업데이트하여 env 저장소에 푸시합니다. 이때 다른 Cloud Build 파이프라인이 트리거되며, 이 파이프라인은 GKE 클러스터에 매니페스트를 적용하고 성공하면 env 저장소의 다른 브랜치에 매니페스트를 저장합니다.

app과 env 저장소를 분리하는 이유는 수명 주기와 용도가 서로 다르기 때문입니다. app 저장소는 주 사용자가 실제 사람이며 특정 애플리케이션 전용입니다. env 저장소는 주 사용자가 Cloud Build 등의 자동화된 시스템이며 여러 애플리케이션에서 공유될 수 있습니다. env 저장소는 각각 특정 환경에 매핑되는 여러 브랜치(이 실습에서는 production만 사용)를 가질 수 있으며 특정 컨테이너 이미지를 참조하지만, app 저장소는 그렇지 않습니다.

이 실습을 마치면 다음 작업을 손쉽게 처리할 수 있는 시스템이 구축됩니다.

• Cloud Build 기록을 조회하여 배포 실패와 성공 구분
• env 저장소의 production 브랜치를 조회하여 현재 사용 중인 매니페스트에 액세스
• Cloud Build의 해당 빌드를 다시 실행하여 이전 버전으로 롤백

참고: 이 실습에서는 Cloud Build를 사용하여 파이프라인을 실행하지만 Spinnaker 및 Jenkins와 같이 대안으로 사용할 수 있는 유명한 다른 빌드 자동화 도구도 있습니다. 현재 이러한 다른 도구 중 일부는 고급 CI/CD 구현에 필요할 수 있는 블루-그린 배포, 카나리아 분석 및 유사한 기능에 대한 우수한 지원을 제공합니다.

목표

이 실습에서는 다음 작업을 수행하는 방법을 알아봅니다.

• Kubernetes Engine 클러스터 만들기
• Cloud Source Repositories 만들기
• Cloud Source Repositories에서 Cloud Build 트리거
• Cloud Build를 통해 테스트 자동화 및 배포 가능한 컨테이너 이미지 게시
• Cloud Build를 통해 Kubernetes Engine 클러스터에 배포된 리소스 관리

설정 및 요건

Qwiklabs에 액세스하기

각 실습에서는 정해진 기간 동안 새 Google Cloud 프로젝트와 리소스 집합이 무료로 제공됩니다.

1. 시크릿 창을 사용하여 Qwiklabs에 로그인합니다.

2. 실습 사용 가능 시간(예: 1:15:00)을 참고하여 해당 시간 내에 완료합니다.
   일시중지 기능은 없습니다. 필요한 경우 다시 시작할 수 있지만 처음부터 시작해야 합니다.

3. 준비가 되면 실습 시작을 클릭합니다.

4. 실습 사용자 인증 정보(사용자 이름 및 비밀번호)를 기록해 두세요. Google Cloud Console에 로그인합니다.

5. Google Console 열기를 클릭합니다.

6. 다른 계정 사용을 클릭한 다음, 안내 메시지에 이 실습에 대한 사용자 인증 정보를 복사하여 붙여넣습니다.
   다른 사용자 인증 정보를 사용하는 경우 오류가 발생하거나 요금이 부과됩니다.

7. 약관에 동의하고 리소스 복구 페이지를 건너뜁니다.

초기 로그인 단계를 완료하면 프로젝트 대시보드가 표시됩니다.

Google Cloud Shell 활성화하기

Google Cloud Shell은 다양한 개발 도구가 탑재된 가상 머신으로, 5GB의 영구 홈 디렉터리를 제공하며 Google Cloud에서 실행됩니다.

Google Cloud Shell을 사용하면 명령줄을 통해 Google Cloud 리소스에 액세스할 수 있습니다.

1. Cloud 콘솔의 오른쪽 상단 툴바에서 'Cloud Shell 열기' 버튼을 클릭합니다.

   

2. 계속을 클릭합니다.

환경을 프로비저닝하고 연결하는 데 몇 분 정도 소요됩니다. 연결되면 사용자가 미리 인증되어 프로젝트가 PROJECT_ID로 설정됩니다. 예:

gcloud는 Google Cloud의 명령줄 도구입니다. Cloud Shell에 사전 설치되어 있으며 명령줄 자동 완성을 지원합니다.

• 다음 명령어를 사용하여 사용 중인 계정 이름을 나열할 수 있습니다.

gcloud auth list

출력:

Credentialed accounts: - @.com (active)

출력 예시:

Credentialed accounts: - google1623327_student@qwiklabs.net

• 다음 명령어를 사용하여 프로젝트 ID를 나열할 수 있습니다.

gcloud config list project

출력:

[core] project =

출력 예시:

[core] project = qwiklabs-gcp-44776a13dea667a6 참고: gcloud 전체 문서는 gcloud CLI 개요 가이드를 참조하세요.

작업 1. 실습 초기화

이 작업에서는 필수 API를 활성화하고, Cloud Shell에서 Git 구성을 초기화하고, 나중에 실습에서 사용되는 샘플 코드를 다운로드하여 Google Cloud 프로젝트의 사용을 준비합니다.

1. Cloud Shell에서 다음 명령어를 실행하여 GKE, Cloud Build, Cloud Source Repositories, 컨테이너 분석용 API를 사용 설정합니다.

gcloud services enable container.googleapis.com \ cloudbuild.googleapis.com \ sourcerepo.googleapis.com \ containeranalysis.googleapis.com

2. 리전에 my-repository라는 Artifact Registry Docker 저장소를 만들어 컨테이너 이미지를 저장합니다.

gcloud artifacts repositories create my-repository \ --repository-format=docker \ --location={{{project_0.default_region | REGION}}}

3. Cloud Shell에서 이 실습의 샘플 애플리케이션을 배포하는 데 사용할 GKE 클러스터를 만듭니다.

gcloud container clusters create hello-cloudbuild \ --num-nodes 1 --region {{{project_0.default_region | REGION}}}

4. Cloud Shell에서 Git을 사용한 적이 없는 경우 내 이름과 이메일 주소를 사용하여 구성합니다.

git config --global user.email "you@example.com" git config --global user.name "Your Name"

Git은 이러한 정보를 사용하여 Cloud Shell에서 만드는 커밋의 작성자를 식별합니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 실습 초기화

작업 2. Cloud Source Repositories에 Git 저장소 만들기

이 작업에서는 이 실습에서 사용되는 두 개의 Git 저장소(hello-cloudbuild-app 및 hello-cloudbuild-env)를 만들고 일부 샘플 코드로 hello-cloudbuild-app를 초기화합니다.

1. Cloud Shell에서 두 개의 Git 저장소를 만듭니다.

gcloud source repos create hello-cloudbuild-app gcloud source repos create hello-cloudbuild-env

2. hello-cloudbuild-app 저장소를 클론합니다.

PROJECT_ID=$(gcloud config get-value project) gcloud source repos clone hello-cloudbuild-app --project=$PROJECT_ID

3. Cloud Storage에서 샘플 코드를 복사하고 보관 파일에서 콘텐츠를 홈 디렉터리로 추출하려면 다음 명령어를 실행합니다.

cd ~ gcloud storage cp gs://cloud-training/gke-gitops/hello-cloudbuild-app.zip ~ && unzip ~/hello-cloudbuild-app.zip -d ~ && rm ~/hello-cloudbuild-app.zip

3. Cloud Source Repositories를 원격 저장소로 구성합니다.

cd ~/hello-cloudbuild-app REGION={{{project_0.default_region | REGION}}} sed -i s/us-central1/$REGION/g cloudbuild.yaml sed -i s/us-central1/$REGION/g cloudbuild-trigger-cd.yaml sed -i s/us-central1/$REGION/g cloudbuild-delivery.yaml sed -i s/us-central1/$REGION/g kubernetes.yaml.tpl git init git add . git commit -m "first commit" git remote add google \ "https://source.developers.google.com/p/${PROJECT_ID}/r/hello-cloudbuild-app"

방금 클론한 코드에는 간단한 'Hello World' 애플리케이션이 포함되어 있습니다.

from flask import Flask app = Flask('hello-cloudbuild') @app.route('/') def hello(): return "Hello World!\n" if __name__ == '__main__': app.run(host = '0.0.0.0', port = 8080)

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. Cloud Source Repositories에 Git 저장소 만들기

작업 3. Cloud Build로 컨테이너 이미지 만들기

클론한 코드에는 다음 Dockerfile이 이미 포함되어 있습니다.

FROM python:3.7-slim RUN pip install flask WORKDIR /app COPY app.py /app/app.py ENTRYPOINT ["python"] CMD ["/app/app.py"]

이 Dockerfile을 사용하면 Cloud Build로 컨테이너 이미지를 만들어 Container Registry에 저장할 수 있습니다.

1. Cloud Shell에서 다음 명령어를 사용하여 최신 커밋을 기반으로 Cloud Build 빌드를 만듭니다.

cd ~/hello-cloudbuild-app COMMIT_ID="$(git rev-parse --short=7 HEAD)" gcloud builds submit --tag="{{{project_0.default_region | REGION}}}-docker.pkg.dev/${PROJECT_ID}/my-repository/hello-cloudbuild:${COMMIT_ID}" .

이 명령어를 실행하면 Cloud Build는 컨테이너 이미지가 만들어질 때 생성되는 로그를 터미널에 스트리밍합니다.

2. 빌드가 완료되면 Google Cloud 콘솔의 Artifact Registry > 저장소로 이동하여 새 컨테이너 이미지를 Artifact Registry에서 실제로 사용할 수 있는지 확인합니다.

3. my-repository를 클릭합니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. Cloud Build로 컨테이너 이미지 만들기

작업 4. 지속적 통합(CI) 파이프라인 만들기

이 작업에서는 소규모 단위 테스트를 자동으로 실행하고 컨테이너 이미지를 빌드하여 Container Registry에 푸시하도록 Cloud Build를 구성합니다. Cloud Source Repositories에 새 커밋을 푸시하면 이 파이프라인이 자동으로 트리거됩니다. 코드에 이미 포함되어 있는 cloudbuild.yaml 파일은 파이프라인의 구성입니다.

1. Google Cloud 콘솔에서 Cloud Build > 트리거로 이동합니다.
2. 트리거 만들기를 클릭합니다.
3. 이름 필드에 hello-cloudbuild를 입력합니다.
4. 이벤트에서 브랜치로 푸시를 선택합니다.
5. 소스에서 저장소로 hello-cloudbuild-app을 선택하고 브랜치로 ^master$를 입력합니다.
6. 빌드 구성에서 Cloud Build 구성 파일을 선택합니다.
7. Cloud Build 구성 파일 위치 필드에서 / 다음에 cloudbuild.yaml을 입력합니다.
8. 서비스 계정에서 내 프로젝트 ID로 시작하는 서비스 계정(@.iam.gserviceaccount.com과 유사)을 선택합니다.
9. 만들기를 클릭합니다.

트리거가 만들어지면 Cloud Shell로 돌아갑니다. 이제 애플리케이션 코드를 Cloud Source Repositories에 푸시하여 Cloud Build의 CI 파이프라인을 트리거해야 합니다.

10. 이 트리거를 시작하려면 다음 명령어를 실행합니다.

cd ~/hello-cloudbuild-app git push google master

11. Google Cloud 콘솔에서 Cloud Build > 대시보드로 이동합니다.

빌드가 실행 중이거나 최근에 끝난 것으로 표시됩니다.

빌드를 클릭하면 실행 상태를 추적하고 로그를 조사할 수 있습니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 지속적 통합(CI) 파이프라인 만들기

작업 5. 테스트 환경 및 CD 파이프라인 만들기

Cloud Build는 지속적 배포 파이프라인에도 사용됩니다. __hello-cloudbuild-env__ 저장소의 candidate 프랜치에 커밋이 푸시될 때마다 파이프라인이 실행됩니다. 이 파이프라인은 Kubernetes 클러스터에 매니페스트의 새 버전을 적용하고, 성공하면 매니페스트를 production 브랜치에 복사합니다. 이 프로세스의 속성은 다음과 같습니다.

• candidate 브랜치는 배포 시도 기록입니다.
• production 브랜치는 배포 성공 기록입니다.
• Cloud Build에서 배포 성공과 실패를 확인할 수 있습니다.
• Cloud Build의 해당 빌드를 다시 실행하여 이전 배포로 롤백할 수 있습니다. 롤백하면 배포 기록을 정확히 반영하기 위해 production 브랜치도 업데이트됩니다.

이제 지속적 통합 파이프라인을 수정하여 hello-cloudbuild-env 저장소의 candidate 브랜치를 업데이트하고 지속적 배포 파이프라인을 트리거해 봅니다.

GKE에 Cloud Build 액세스 권한 부여

애플리케이션을 Kubernetes 클러스터에 배포하려면 Cloud Build에 Kubernetes Engine 개발자 ID 및 액세스 관리 역할이 필요합니다.

• Cloud Shell에서 다음 명령어를 실행합니다.

PROJECT_NUMBER="$(gcloud projects describe ${PROJECT_ID} --format='get(projectNumber)')" gcloud projects add-iam-policy-binding ${PROJECT_NUMBER} \ --member=serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \ --role=roles/container.developer

hello-cloudbuild-env 저장소 초기화

hello-cloudbuild-env 저장소를 두 개의 브랜치(production과 candidate) 및 배포 프로세스를 기술하는 Cloud Build 구성 파일로 초기화해야 합니다.

먼저 hello-cloudbuild-env 저장소를 클론하고 production 브랜치를 만듭니다. 여전히 빈 상태입니다.

1. Cloud Shell에서 다음 명령어를 실행합니다.

cd ~ gcloud source repos clone hello-cloudbuild-env cd ~/hello-cloudbuild-env git checkout -b production

2. 그런 다음, hello-cloudbuild-app 저장소에 있는 cloudbuild-delivery.yaml 파일을 복사하고 변경사항을 커밋해야 합니다.

cd ~/hello-cloudbuild-env cp ~/hello-cloudbuild-app/cloudbuild-delivery.yaml ~/hello-cloudbuild-env/cloudbuild.yaml git add . git commit -m "Create cloudbuild.yaml for deployment" 참고: cloudbuild-delivery.yaml 파일은 Cloud Build에서 실행할 배포 프로세스를 설명합니다.

프로세스는 두 단계로 구성됩니다.

• Cloud Build가 GKE 클러스터에 매니페스트를 적용합니다.
• 성공하면 Cloud Build가 매니페스트를 production 브랜치에 복사합니다.

3. candidate 브랜치를 만들고 두 브랜치를 사용할 수 있도록 Cloud Source Repositories에 푸시합니다.

git checkout -b candidate git push origin production git push origin candidate

4. hello-cloudbuild-env 저장소의 Cloud Build 서비스 계정에 소스 저장소 작성자 IAM 역할을 부여합니다.

PROJECT_NUMBER="$(gcloud projects describe ${PROJECT_ID} \ --format='get(projectNumber)')" cat >/tmp/hello-cloudbuild-env-policy.yaml <<EOF bindings: - members: - serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com role: roles/source.writer EOF gcloud source repos set-iam-policy \ hello-cloudbuild-env /tmp/hello-cloudbuild-env-policy.yaml

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. Cloud Build에 Kubernetes Engine 개발자 및 소스 저장소 작성자 IAM 역할 부여

지속적 배포 파이프라인의 트리거 만들기

1. Google Cloud 콘솔에서 Cloud Build > 트리거로 이동합니다.
2. 트리거 만들기를 클릭합니다.
3. 이름 필드에 hello-cloudbuild-deploy를 입력합니다.
4. 이벤트에서 브랜치로 푸시를 선택합니다.
5. 소스 아래에서, 저장소로 hello-cloudbuild-env를 선택하고 브랜치로 ^candidate$를 선택합니다.
6. 빌드 구성에서 Cloud Build 구성 파일을 선택합니다.
7. Cloud Build 구성 파일 위치 필드에서 / 다음에 cloudbuild.yaml을 입력합니다.
8. 서비스 계정에서 내 프로젝트 ID로 시작하는 서비스 계정(@.iam.gserviceaccount.com과 유사)을 선택합니다.
9. 만들기를 클릭합니다.

지속적 배포 파이프라인을 트리거하도록 지속적 통합 파이프라인 수정

이 섹션에서는 지속적 통합 파이프라인에 몇 단계를 추가하여 Kubernetes 매니페스트의 새 버전을 생성한 후 __hello-cloudbuild-env__ 저장소에 푸시하여 지속적 배포 파이프라인을 트리거합니다.

1. 앱 저장소에서 cloudbuild.yaml 파일의 확장된 버전을 복사합니다.

cd ~/hello-cloudbuild-app cp cloudbuild-trigger-cd.yaml cloudbuild.yaml

cloudbuild-trigger-cd.yaml은 cloudbuild.yaml 파일의 확장된 버전입니다. 이 파일은 새 Kubernetes 매니페스트를 생성하고 지속적 배포 파이프라인을 트리거하는 단계를 추가합니다.

참고: 이 파이프라인은 간단한 sed를 사용하여 매니페스트 템플릿을 렌더링합니다. 실무에서는 kustomize 또는 skaffold와 같은 전용 도구를 사용하는 것이 좋습니다. 이러한 도구로 매니페스트 템플릿의 렌더링을 자세히 제어할 수 있습니다.

2. 수정사항을 커밋한 후 Cloud Source Repositories에 푸시합니다.

cd ~/hello-cloudbuild-app git add cloudbuild.yaml git commit -m "Trigger CD pipeline" git push google master

이렇게 하면 Cloud Build의 지속적 통합 파이프라인이 트리거됩니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 지속적 배포 파이프라인의 트리거 만들기

작업 6. Cloud Build 파이프라인 검토

1. Google Cloud 콘솔에서 Cloud Build > 대시보드로 이동합니다.
2. hello-cloudbuild-app 트리거를 클릭하여 실행을 추적하고 로그를 검사합니다.

이 파이프라인의 마지막 단계에서는 새 매니페스트를 hello-cloudbuild-env 저장소에 푸시하여 지속적 배포 파이프라인을 트리거합니다.

3. 기본 대시보드로 돌아갑니다.
4. hello-cloudbuild-env 저장소에서 빌드가 실행 중이거나 최근에 끝난 것으로 표시됩니다. 빌드를 클릭하면 실행 상태를 추적하고 로그를 조사할 수 있습니다.

작업 7. 전체 파이프라인 테스트

이제 전체 CI/CD 파이프라인이 구성되었습니다. 이 섹션에서는 파이프라인을 처음부터 끝까지 테스트합니다.

1. Google Cloud 콘솔에서 Kubernetes Engine > 게이트웨이, 서비스, 인그레스로 이동합니다.

2. 상단 메뉴에서 서비스를 선택합니다.

목록에 hello-cloudbuild라는 서비스 하나가 있어야 합니다. 이 서비스는 방금 실행된 지속적 배포 빌드에서 만든 것입니다.

3. hello-cloudbuild 서비스의 엔드포인트를 클릭합니다.

'Hello World!'가 표시되어야 합니다 엔드포인트가 없거나 부하 분산기 오류가 표시되는 경우 부하 분산기 초기화가 완료될 때까지 몇 분 정도 기다려야 할 수 있습니다. 필요한 경우 '새로고침'을 클릭하여 페이지를 업데이트합니다.

4. Cloud Shell에서 애플리케이션 및 단위 테스트의 'Hello World'를 'Hello Cloud Build'로 바꿉니다.

cd ~/hello-cloudbuild-app sed -i 's/Hello World/Hello Cloud Build/g' app.py sed -i 's/Hello World/Hello Cloud Build/g' test_app.py

5. 변경사항을 커밋하고 Cloud Source Repositories에 푸시합니다.

git add app.py test_app.py git commit -m "Hello Cloud Build" git push google master

6. 이렇게 하면 전체 CI/CD 파이프라인이 트리거됩니다.

몇 분 후에 브라우저에서 애플리케이션을 새로고침합니다. 이제 'Hello Cloud Build!'가 표시됩니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 전체 파이프라인 테스트

작업 8. 롤백 테스트

이 작업에서는 'Hello World!'를 표시하던 애플리케이션 버전으로 롤백합니다.

1. Google Cloud 콘솔에서 Cloud Build > 대시보드로 이동합니다.

2. hello-cloudbuild-env 저장소의 빌드 기록 아래에서 모두 보기 링크를 클릭합니다.

3. 사용 가능한 빌드 중에서 두 번째로 최신인 빌드를 클릭합니다.

4. 빌드 다시 시도를 클릭합니다.

5. 빌드가 끝나면 브라우저에서 애플리케이션을 새로고침합니다.

이제 다시 'Hello World!' 페이지가 표시됩니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 롤백 테스트

실습 종료하기

실습을 완료하면 실습 종료를 클릭합니다. Google Cloud Skills Boost에서 사용된 리소스를 자동으로 삭제하고 계정을 지웁니다.

실습 경험을 평가할 수 있습니다. 해당하는 별표 수를 선택하고 의견을 입력한 후 제출을 클릭합니다.

별점의 의미는 다음과 같습니다.

• 별표 1개 = 매우 불만족
• 별표 2개 = 불만족
• 별표 3개 = 중간
• 별표 4개 = 만족
• 별표 5개 = 매우 만족

의견을 제공하고 싶지 않다면 대화상자를 닫으면 됩니다.

의견이나 제안 또는 수정할 사항이 있다면 지원 탭을 사용하세요.

Copyright 2025 Google LLC All rights reserved. Google 및 Google 로고는 Google LLC의 상표입니다. 기타 모든 회사명 및 제품명은 해당 업체의 상표일 수 있습니다.