GSP330

개요

챌린지 실습에서는 특정 시나리오와 일련의 작업이 주어집니다. 단계별 안내를 따르는 대신, 과정의 실습에서 배운 기술을 사용하여 스스로 작업을 완료하는 방법을 알아내 보세요. 이 페이지에 표시되어 있는 자동 채점 시스템에서 작업을 올바르게 완료했는지 피드백을 제공합니다.

챌린지 실습을 진행할 때는 새로운 Google Cloud 개념에 대한 정보가 제공되지 않습니다. 학습한 기술을 응용하여 기본값을 변경하거나 오류 메시지를 읽고 조사하여 실수를 바로잡아야 합니다.

100점을 받으려면 시간 내에 모든 작업을 성공적으로 완료해야 합니다.

이 실습은 Implement DevOps Workflows in Google Cloud 과정에 등록한 수강생에게 권장됩니다. 챌린지에 도전할 준비가 되셨나요?

실습 시작 버튼을 클릭하기 전에

다음 안내를 확인하세요. 실습에는 시간 제한이 있으며 일시중지할 수 없습니다. 실습 시작을 클릭하면 타이머가 시작됩니다. 이 타이머에는 Google Cloud 리소스를 사용할 수 있는 시간이 얼마나 남았는지 표시됩니다.

실무형 실습을 통해 시뮬레이션이나 데모 환경이 아닌 실제 클라우드 환경에서 직접 실습 활동을 진행할 수 있습니다. 실습 시간 동안 Google Cloud에 로그인하고 액세스하는 데 사용할 수 있는 새로운 임시 사용자 인증 정보가 제공됩니다.

이 실습을 완료하려면 다음을 준비해야 합니다.

• 표준 인터넷 브라우저 액세스 권한(Chrome 브라우저 권장)

참고: 이 실습을 실행하려면 시크릿 모드 또는 시크릿 브라우저 창을 사용하세요. 개인 계정과 학생 계정 간의 충돌로 개인 계정에 추가 요금이 발생하는 일을 방지해 줍니다.

• 실습을 완료하기에 충분한 시간---실습을 시작하고 나면 일시중지할 수 없습니다.

참고: 계정에 추가 요금이 발생하지 않도록 하려면 개인용 Google Cloud 계정이나 프로젝트가 이미 있어도 이 실습에서는 사용하지 마세요.

챌린지 시나리오

여러분은 몇 개월 전에 Cymbal Superstore의 DevOps 엔지니어로 채용되면서 이 회사에서 전자상거래 웹사이트를 운영하는 방식에 대한 관한 모든 내용을 알게 되었습니다. 특히 DevOps팀은 대규모 CI/CD 파이프라인을 담당하고 있으며 이를 빌드하는 데 여러분의 지원을 받고자 합니다. 이를 통해 회사에서는 개발자가 작업을 자동화하고, 다른 팀과 보다 효과적으로 협업하며, 소프트웨어를 보다 자주 안정적으로 출시할 수 있도록 지원할 수 있습니다. Cymbal Superstore에서는 파이프라인에 모든 네이티브 Google Cloud 서비스를 사용하고자 하므로 Cloud Source Repositories, Artifact Registry, Docker, Cloud Build에 대한 여러분의 경험이 큰 도움이 될 것입니다.

이 프로젝트를 시작하기 전에 DevOps팀은 여러분이 보유하고 있는 새로운 기술 역량을 보여주기를 원합니다. 그 일환으로 DevOps팀은 샌드박스 환경에서 지정된 기간 동안 여러분이 수행하기를 원하는 작업 목록을 만들었습니다.

챌린지

수행해야 할 작업은 다음과 같습니다.

• 제공된 일련의 구성을 기반으로 GKE 클러스터 만들기
• Go 애플리케이션 코드를 호스팅하기 위한 Google 소스 저장소 만들기
• 프로덕션 및 개발 애플리케이션을 배포하는 Cloud Build 트리거 만들기
• 앱에 업데이트를 푸시하고 새 빌드 만들기
• 프로덕션 애플리케이션을 이전 버전으로 롤백

전반적으로 Cloud Source Repositories, Artifact Registry, Cloud Build를 사용하여 간단한 CI/CD 파이프라인을 만듭니다.

작업 1. 실습 리소스 만들기

이 섹션에서는 데모 환경을 위해 Google Cloud 프로젝트를 초기화합니다. 필요한 API를 사용 설정하고, Cloud Shell에서 Git을 구성하며, Artifact Registry Docker 저장소를 만들고, 프로덕션 및 개발 애플리케이션을 실행할 GKE 클러스터를 만듭니다.

1. 다음 명령어를 실행하여 GKE, Cloud Build, Cloud Source Repositories용 API를 사용 설정합니다.

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

2. Cloud Build 서비스 계정에 대해 Kubernetes 개발자 역할을 추가합니다.

export PROJECT_ID=$(gcloud config get-value project) gcloud projects add-iam-policy-binding $PROJECT_ID \ --member=serviceAccount:$(gcloud projects describe $PROJECT_ID \ --format="value(projectNumber)")@cloudbuild.gserviceaccount.com --role="roles/container.developer"

3. Cloud Shell에서 다음을 실행하여 Git을 구성합니다. 이때 <email>을 생성된 실습 이메일 주소로, <name>을 이름으로 바꿉니다.

git config --global user.email <email> git config --global user.name <name>

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

5. 다음 구성을 사용하여 hello-cluster라는 GKE Standard 클러스터를 만듭니다.

설정	값
영역
출시 채널	일반
클러스터 버전	1.29 이상
클러스터 자동 확장 처리	사용 설정됨
노드 수	3
최소 노드 수	2
최대 노드 수	6

6. 클러스터에 prod 및 dev 네임스페이스를 만듭니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 실습 리소스 만들기

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

이 작업에서는 Cloud Source Repositories에 sample-app이라는 저장소를 만들고 이 저장소를 샘플 코드로 초기화합니다. 이 저장소에는 Go 애플리케이션 코드가 있으며 빌드를 트리거하는 기본 소스가 됩니다.

1. Cloud Source Repositories에 sample-app이라는 비어 있는 저장소를 만듭니다.

2. Cloud Shell에서 sample-app Cloud 소스 저장소를 클론합니다.

3. 다음 명령어를 사용하여 샘플 코드를 sample-app 디렉터리에 복사합니다.

cd ~ gsutil cp -r gs://spls/gsp330/sample-app/* sample-app

4. cloudbuild-dev.yaml 파일과 cloudbuild.yaml 파일의 <your-region> 및 <your-zone> 자리표시자를 자동으로 프로젝트에 할당된 리전 및 영역으로 바꾸는 다음 명령어를 실행합니다.

export REGION="{{{project_0.default_region | REGION}}}" export ZONE="{{{project_0.default_zone | ZONE}}}" for file in sample-app/cloudbuild-dev.yaml sample-app/cloudbuild.yaml; do sed -i "s/<your-region>/${REGION}/g" "$file" sed -i "s/<your-zone>/${ZONE}/g" "$file" done

5. sample-app 디렉터리에 추가된 샘플 코드로 최초 커밋을 수행하고 master 브랜치에 변경사항을 푸시합니다.

6. dev라는 브랜치를 만듭니다. sample-app 디렉터리에 추가된 샘플 코드로 커밋을 수행하고 dev 브랜치에 변경사항을 푸시합니다.

7. 샘플 코드와 브랜치를 소스 저장소에 저장했는지 확인합니다.

방금 클론한 코드는 빨간색과 파란색 두 개의 진입점이 있는 간단한 Go 애플리케이션을 포함합니다. 각각은 사용하는 진입점에 따라 색상이 있는 정사각형을 웹페이지에 표시합니다.

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

작업 3. Cloud Build 트리거 만들기

이 섹션에서는 두 개의 Cloud Build 트리거를 만듭니다.

• 첫 번째 트리거는 master 브랜치에서 변경사항을 수신 대기하고 애플리케이션의 Docker 이미지를 빌드하여 Google Artifact Registry에 푸시하고 최신 버전의 이미지를 GKE 클러스터의 prod 네임스페이스에 배포합니다.

• 두 번째 트리거는 dev 브랜치에서 변경사항을 수신 대기하고 애플리케이션의 Docker 이미지를 빌드하여 Google Artifact Registry에 푸시하고 최신 버전의 이미지를 GKE 클러스터의 dev 네임스페이스에 배포합니다.

1. 다음 구성을 사용하여 sample-app-prod-deploy라는 Cloud Build 트리거를 만듭니다.

   • 이벤트: 브랜치에 푸시
   • 소스 저장소: sample-app
   • 브랜치: ^master$
   • Cloud Build 구성 파일: cloudbuild.yaml

2. 다음 구성을 사용하여 sample-app-dev-deploy라는 Cloud Build 트리거를 만듭니다.

   • 이벤트: 브랜치에 푸시
   • 소스 저장소: sample-app
   • 브랜치: ^dev$
   • Cloud Build 구성 파일: cloudbuild-dev.yaml

트리거를 설정한 후 브랜치를 변경하면 cloudbuild.yaml 파일에 지정된 대로 애플리케이션을 빌드하고 배포하는 해당 Cloud Build 파이프라인이 트리거됩니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. Cloud Build 트리거 만들기

작업 4. 애플리케이션의 첫 번째 버전 배포

이 섹션에서는 프로덕션 애플리케이션과 개발 애플리케이션의 첫 번째 버전을 빌드합니다.

첫 번째 개발 배포 빌드

1. Cloud Shell에서 sample-app 디렉터리에 있는 cloudbuild-dev.yaml 파일을 검사하여 빌드 프로세스의 단계를 확인합니다. cloudbuild-dev.yaml 파일에서 9줄과 13줄의 <version>을 v1.0으로 바꿉니다.

2. dev/deployment.yaml 파일로 이동하여 17줄의 <todo>를 올바른 컨테이너 이미지 이름으로 업데이트합니다. 또한 컨테이너 이미지 이름에서 PROJECT_ID 변수를 실제 프로젝트 ID로 바꿉니다.

참고: dev/deployment.yaml 파일과 cloudbuild-dev.yaml 파일의 컨테이너 이미지 이름이 동일한지 확인하세요.

3. dev 브랜치의 변경사항으로 커밋을 수행하고 변경사항을 푸시하여 sample-app-dev-deploy 빌드 작업을 트리거합니다.

4. Cloud Build 기록 페이지에서 빌드가 성공적으로 실행되었는지 확인하고 development-deployment 애플리케이션이 클러스터의 dev 네임스페이스에 배포되었는지 확인합니다.

5. development-deployment 배포를 포트 8080에서 dev-deployment-service라는 LoadBalancer 서비스에 노출하고 컨테이너의 대상 포트를 Dockerfile에 지정된 포트로 설정합니다.

6. 서비스의 부하 분산기 IP로 이동하고 URL 끝에 /blue 진입점을 추가하여 애플리케이션이 실행 중인지 확인합니다. http://34.135.97.199:8080/blue와 유사한 형태여야 합니다.

첫 번째 프로덕션 배포 빌드

1. master 브랜치로 전환합니다. sample-app 디렉터리에 있는 cloudbuild-dev.yaml 파일을 검사하여 빌드 프로세스의 단계를 확인합니다. cloudbuild.yaml 파일에서 11줄과 16줄의 <version>을 v1.0으로 바꿉니다.

2. prod/deployment.yaml 파일로 이동하여 17줄의 <todo>를 올바른 컨테이너 이미지 이름으로 업데이트합니다. 또한 컨테이너 이미지 이름에서 PROJECT_ID 변수를 실제 프로젝트 ID로 바꿉니다.

참고: prod/deployment.yaml 파일과 cloudbuild.yaml 파일의 컨테이너 이미지 이름이 동일한지 확인하세요.

3. master 브랜치의 변경사항으로 커밋을 수행하고 변경사항을 푸시하여 sample-app-prod-deploy 빌드 작업을 트리거합니다.

4. Cloud Build 기록 페이지에서 빌드가 성공적으로 실행되었는지 확인하고 production-deployment 애플리케이션이 클러스터의 prod 네임스페이스에 배포되었는지 확인합니다.

5. prod 네임스페이스의 production-deployment 배포를 포트 8080에서 prod-deployment-service라는 LoadBalancer 서비스에 노출하고 컨테이너의 대상 포트를 Dockerfile에 지정된 포트로 설정합니다.

6. 서비스의 부하 분산기 IP로 이동하고 URL 끝에 /blue 진입점을 추가하여 애플리케이션이 실행 중인지 확인합니다. http://34.135.245.19:8080/blue와 유사한 형태여야 합니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 애플리케이션의 첫 번째 버전 배포

작업 5. 애플리케이션의 두 번째 버전 배포

이 섹션에서는 프로덕션 애플리케이션과 개발 애플리케이션의 두 번째 버전을 빌드합니다.

두 번째 개발 배포 빌드

1. dev 브랜치로 다시 전환합니다.

참고: 계속 진행하기 전에 dev 환경에 대한 배포를 만들 dev 브랜치가 표시되는지 확인하세요.

2. main.go 파일에서 main() 함수를 다음으로 업데이트합니다.

func main() { http.HandleFunc("/blue", blueHandler) http.HandleFunc("/red", redHandler) http.ListenAndServe(":8080", nil) }

3. main.go 파일의 내부에 다음 함수를 추가합니다.

func redHandler(w http.ResponseWriter, r *http.Request) { img := image.NewRGBA(image.Rect(0, 0, 100, 100)) draw.Draw(img, img.Bounds(), &image.Uniform{color.RGBA{255, 0, 0, 255}}, image.ZP, draw.Src) w.Header().Set("Content-Type", "image/png") png.Encode(w, img) }

4. cloudbuild-dev.yaml 파일을 검사하여 빌드 프로세스의 단계를 확인합니다. Docker 이미지의 버전을 v2.0으로 업데이트합니다.

5. dev/deployment.yaml 파일로 이동하여 컨테이너 이미지 이름을 새 버전(v2.0)으로 업데이트합니다.

6. dev 브랜치의 변경사항으로 커밋을 수행하고 변경사항을 푸시하여 sample-app-dev-deploy 빌드 작업을 트리거합니다.

7. Cloud Build 기록 페이지에서 빌드가 성공적으로 실행되었는지 확인하고 development-deployment 애플리케이션이 클러스터의 dev 네임스페이스에 배포되었고 v2.0 이미지를 사용 중인지 확인합니다.

8. 서비스의 부하 분산기 IP로 이동하고 URL 끝에 /red 진입점을 추가하여 애플리케이션이 실행 중인지 확인합니다. http://34.135.97.199:8080/red와 유사한 형태여야 합니다.

참고: 업데이트가 부하 분산기에 적용되는 데 몇 분 정도 걸릴 수 있습니다.

두 번째 프로덕션 배포 빌드

1. master 브랜치로 전환합니다.

참고: 계속 진행하기 전에 master 환경에 대한 배포를 만들 master 브랜치가 표시되는지 확인하세요.

2. main.go 파일에서 main() 함수를 다음으로 업데이트합니다.

func main() { http.HandleFunc("/blue", blueHandler) http.HandleFunc("/red", redHandler) http.ListenAndServe(":8080", nil) }

3. main.go 파일의 내부에 다음 함수를 추가합니다.

func redHandler(w http.ResponseWriter, r *http.Request) { img := image.NewRGBA(image.Rect(0, 0, 100, 100)) draw.Draw(img, img.Bounds(), &image.Uniform{color.RGBA{255, 0, 0, 255}}, image.ZP, draw.Src) w.Header().Set("Content-Type", "image/png") png.Encode(w, img) }

4. cloudbuild.yaml 파일을 검사하여 빌드 프로세스의 단계를 확인합니다. Docker 이미지의 버전을 v2.0으로 업데이트합니다.

5. prod/deployment.yaml 파일로 이동하여 컨테이너 이미지 이름을 새 버전(v2.0)으로 업데이트합니다.

6. master 브랜치의 변경사항으로 커밋을 수행하고 변경사항을 푸시하여 sample-app-prod-deploy 빌드 작업을 트리거합니다.

7. Cloud Build 기록 페이지에서 빌드가 성공적으로 실행되었는지 확인하고 production-deployment 애플리케이션이 클러스터의 prod 네임스페이스에 배포되었고 v2.0 이미지를 사용 중인지 확인합니다.

8. 서비스의 부하 분산기 IP로 이동하고 URL 끝에 /red 진입점을 추가하여 애플리케이션이 실행 중인지 확인합니다. http://34.135.245.19:8080/red와 유사한 형태여야 합니다.

참고: 업데이트가 부하 분산기에 적용되는 데 몇 분 정도 걸릴 수 있습니다.

좋습니다. 완벽하게 작동하는 프로덕션 및 개발 CI/CD 파이프라인을 성공적으로 만들었습니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 애플리케이션의 두 번째 버전 배포

작업 6. 프로덕션 배포 롤백

이 섹션에서는 프로덕션 배포를 이전 버전으로 롤백합니다.

1. production-deployment를 롤백하여 v1.0 버전의 애플리케이션을 사용합니다.

힌트: Cloud Build 기록을 사용하면 배포를 이전 버전으로 간편하게 롤백/다시 빌드할 수 있습니다.

2. 서비스의 부하 분산기 IP로 이동하고 프로덕션 배포의 URL 끝에 /red 진입점을 추가합니다. 페이지의 응답은 404가 되어야 합니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 프로덕션 배포 롤백

수고하셨습니다

수고하셨습니다. 이 실습에서는 Google Cloud에서 DevOps 워크플로를 구현하는 기술 역량을 확인해 봤습니다. 먼저 애플리케이션을 실행할 GKE 클러스터와 코드베이스를 호스팅할 git 저장소를 만들었습니다. 그런 다음 Cloud Build 트리거를 만들고, 코드와 템플릿을 수정하고, 첫 번째 개발 및 프로덕션 애플리케이션 빌드를 만든 저장소에 업데이트를 푸시했습니다. 마지막으로 애플리케이션에 업데이트를 푸시하여 새 빌드를 만들고 프로덕션 애플리케이션을 이전 버전으로 롤백했습니다. 이제 사용자 환경에서 DevOps 작업을 시작할 준비가 되었습니다.

다음 기술 배지 획득

이 사용자 주도형 실습은 Implement DevOps Workflows in Google Cloud 과정의 일부입니다. 이 기술 배지 과정을 완료하면 위의 배지를 획득하여 수료를 인증할 수 있습니다. 이력서 및 소셜 플랫폼에 배지를 공유하고 #GoogleCloudBadge 해시태그를 사용해 스스로 달성한 업적을 널리 알리세요.

이 기술 배지는 Google Cloud의 클라우드 DevOps 엔지니어 학습 과정의 일부입니다. Monitor and Log with Google Cloud Observability 과정에 등록하여 학습 여정을 계속하세요.

Google Cloud 교육 및 자격증

Google Cloud 기술을 최대한 활용하는 데 도움이 됩니다. Google 강의에는 빠른 습득과 지속적인 학습을 지원하는 기술적인 지식과 권장사항이 포함되어 있습니다. 기초에서 고급까지 수준별 학습을 제공하며 바쁜 일정에 알맞은 주문형, 실시간, 가상 옵션이 포함되어 있습니다. 인증은 Google Cloud 기술에 대한 역량과 전문성을 검증하고 입증하는 데 도움이 됩니다.

설명서 최종 업데이트: 2024년 6월 26일

실습 최종 테스트: 2024년 6월 26일

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