1. 소개
웹사이트와 애플리케이션을 실행하기란 쉽지 않습니다.
예상치 못한 문제가 발생하고, 서버가 다운되며, 수요 증가로 인해 더 많은 리소스가 사용되고, 다운타임 없이 변경하는 것은 복잡하고 스트레스가 많습니다.
이 모든 작업을 수행하고 자동화까지 할 수 있는 도구를 상상해 보세요. GKE를 사용하면 이 모든 작업을 쉽게 수행할 수 있습니다. 이 Codelab에서는 가상의 회사인 Fancy Store의 전자상거래 웹사이트를 운영하는 개발자 역할을 맡게 됩니다. 확장 및 중단 문제로 인해 GKE에 애플리케이션을 배포해야 합니다.
실습은 일반적인 클라우드 개발자의 경험을 반영하여 다음과 같은 순서로 진행됩니다.
- GKE 클러스터 만들기
- Docker 컨테이너를 만듭니다.
- GKE에 컨테이너를 배포합니다.
- 서비스를 통해 컨테이너를 노출합니다.
- 컨테이너를 여러 복제본으로 확장합니다.
- 웹사이트를 수정합니다.
- 다운타임 없이 새 버전을 출시합니다.
아키텍처 다이어그램
학습할 내용
- GKE 클러스터를 만드는 방법
- Docker 이미지를 만드는 방법
- Kubernetes에 Docker 이미지를 배포하는 방법
- Kubernetes에서 애플리케이션을 확장하는 방법
- Kubernetes에서 순차적 업데이트를 수행하는 방법
기본 요건
- 프로젝트를 만들 수 있는 관리 액세스 권한이 있는 Google 계정 또는 프로젝트 소유자 역할이 있는 프로젝트
- Docker 및 Kubernetes에 대한 기본적인 이해 (기본적인 이해가 부족한 경우 지금 Docker 및 Kubernetes를 검토하세요.)
2. 환경 설정
자습형 환경 설정
아직 Google 계정이 없다면 계정을 만들어야 합니다. Google Cloud 콘솔에 로그인하고 새 프로젝트를 만듭니다.
프로젝트 ID는 모든 Google Cloud 프로젝트에서 고유한 이름이어야 합니다 (위의 이름은 이미 사용되었으므로 사용할 수 없습니다). 이후에는 PROJECT_ID로 참조됩니다.
그런 다음 Google Cloud 리소스를 사용하려면 Cloud 콘솔에서 결제를 사용 설정해야 합니다. Google Cloud 신규 사용자는 $300 상당의 무료 체험판을 사용할 수 있습니다. 신규 사용자가 아니더라도 Codelab 비용은 몇 달러를 넘지 않으니 걱정하지 마세요. 하지만 더 많은 리소스를 사용하거나 실행 중일 경우 codelab에 더 많은 비용이 들 수 있습니다 (마지막의 '삭제' 섹션 참고). 자세한 내용은 가격 책정을 참조하세요.
Cloud Shell
노트북으로 Google Cloud 및 GKE를 원격으로 운영할 수 있지만, 이 Codelab에서는 클라우드에서 실행되는 명령줄 환경인 Cloud Shell을 사용합니다.
이 Debian 기반 가상 머신에는 필요한 모든 개발 도구가 로드되어 있습니다. 영구적인 5GB 홈 디렉터리를 제공하고 Google Cloud에서 실행되므로 네트워크 성능과 인증이 크게 개선됩니다. 즉, 이 Codelab에 필요한 것은 브라우저뿐입니다(Chromebook에서도 작동 가능).
- Cloud Console에서 Cloud Shell을 활성화하려면 단순히 Cloud Shell 활성화
를 클릭합니다. 환경을 프로비저닝하고 연결하는 데 몇 정도만 소요됩니다.
Cloud Shell에 연결되면 사용자 인증이 이미 완료되었고 프로젝트가 내 PROJECT_ID에 설정되어 있음을 확인할 수 있습니다.
gcloud auth list
명령어 결과
Credentialed accounts: - <myaccount>@<mydomain>.com (active)
gcloud config list project
명령어 결과
[core] project = <PROJECT_ID>
어떤 이유로든 프로젝트가 설정되지 않았으면 다음 명령어를 실행하면 됩니다.
gcloud config set project <PROJECT_ID>
PROJECT_ID를 찾고 계신가요? 설정 단계에서 사용한 ID를 확인하거나 Cloud Console 대시보드에서 확인하세요.
또한 Cloud Shell은 기본적으로 이후 명령어를 실행할 때 유용할 수 있는 몇 가지 환경 변수를 설정합니다.
echo $GOOGLE_CLOUD_PROJECT
명령어 결과
<PROJECT_ID>
- 마지막으로 기본 영역 및 프로젝트 구성을 설정합니다.
gcloud config set compute/zone us-central1-f
다양한 영역을 선택할 수 있습니다. 자세한 내용은 리전 및 영역을 참고하세요.
3. GKE 클러스터 만들기
이제 개발자 환경이 작동하므로 웹사이트를 배포할 GKE 클러스터가 필요합니다. 클러스터를 만들기 전에 적절한 API가 사용 설정되어 있는지 확인해야 합니다. 다음 명령어를 실행하여 컨테이너 API를 사용 설정합니다.
gcloud services enable container.googleapis.com
이제 클러스터를 만들 수 있습니다. 아래 단계에 따라 3개의 노드가 있는 fancy-cluster라는 클러스터를 만듭니다.
gcloud container clusters create fancy-cluster --num-nodes 3
클러스터가 생성되려면 몇 분 정도 걸릴 수 있습니다. 그런 다음 다음 명령어를 실행하여 클러스터의 3개 작업자 가상 머신 (VM) 인스턴스를 확인합니다.
gcloud compute instances list
출력:
NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS gke-fancy-cluster-default-pool-ad92506d-1ng3 us-east4-a n1-standard-1 10.150.0.7 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4fvq us-east4-a n1-standard-1 10.150.0.5 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4zs3 us-east4-a n1-standard-1 10.150.0.6 XX.XX.XX.XX RUNNING
또한 Cloud 콘솔에서 클러스터와 관련 정보를 볼 수 있습니다. 왼쪽 상단의 메뉴 버튼을 클릭하고 Kubernetes Engine까지 아래로 스크롤한 다음 클러스터를 클릭합니다. fancy-cluster라는 이름의 클러스터가 표시됩니다.
축하합니다. 첫 번째 클러스터를 만들었습니다.
4. 소스 저장소 클론
기존 웹사이트이므로 저장소에서 소스를 클론하기만 하면 됩니다. 그러면 Docker 이미지를 만들고 GKE에 배포하는 데 집중할 수 있습니다.
다음 명령어를 실행하여 소스 저장소를 Cloud Shell 인스턴스에 클론하고 적절한 디렉터리로 변경합니다. 또한 배포하기 전에 애플리케이션을 테스트할 수 있도록 Node.js 종속 항목을 설치합니다.
cd ~ git clone https://github.com/googlecodelabs/monolith-to-microservices.git cd ~/monolith-to-microservices ./setup.sh
이렇게 하면 저장소가 클론되고, 디렉터리가 변경되고, 애플리케이션을 로컬로 실행하는 데 필요한 종속 항목이 설치됩니다. 스크립트를 실행하는 데 몇 분 정도 걸릴 수 있습니다.
신중하게 조사하고 애플리케이션을 테스트하세요. 다음 명령어를 실행하여 웹 서버를 시작합니다.
cd ~/monolith-to-microservices/monolith npm start
출력:
Monolith listening on port 8080!
Cloud Shell 메뉴에서 웹 미리보기 아이콘을 클릭하고 포트 8080에서 미리보기를 선택하여 애플리케이션을 미리 볼 수 있습니다.
그러면 Fancy Store가 작동하는 모습을 볼 수 있는 새 창이 열립니다.
웹사이트를 확인한 후 창을 닫아도 됩니다. 터미널 창에서 Control+C (Windows 또는 Mac)를 눌러 웹 서버 프로세스를 중지합니다.
5. Cloud Build로 Docker 컨테이너 만들기
이제 소스 파일이 준비되었으므로 애플리케이션을 도커화할 차례입니다.
일반적으로는 Docker 컨테이너를 빌드하고 레지스트리에 푸시하여 GKE가 가져올 이미지를 저장하는 2단계 접근방식을 취해야 합니다. 하지만 Cloud Build를 사용하면 단일 명령어로 Docker 컨테이너를 만들고 이미지를 Container Registry에 넣을 수 있어 훨씬 편리합니다. (Docker 파일을 직접 만들고 푸시하는 프로세스를 보려면 Container Registry 빠른 시작을 참고하세요.)
Cloud Build는 디렉터리의 파일을 압축하여 Cloud Storage 버킷으로 이동합니다. 그러면 빌드 프로세스가 버킷의 파일을 가져와 Dockerfile을 사용하여 Docker 빌드 프로세스를 실행합니다. Docker 이미지에 대해 호스트를 gcr.io로 지정하여 --tag 플래그를 지정했으므로 결과 Docker 이미지가 Container Registry로 푸시됩니다.
먼저 다음 명령어를 실행하여 Cloud Build API를 사용 설정해야 합니다.
gcloud services enable cloudbuild.googleapis.com
API가 사용 설정되면 Cloud Shell에서 다음 명령어를 실행하여 빌드 프로세스를 시작합니다.
cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:1.0.0 .
이 프로세스는 몇 분 정도 걸리지만 완료되면 터미널에 다음과 같은 출력이 표시됩니다.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ID CREATE_TIME DURATION SOURCE IMAGES STATUS 1ae295d9-63cb-482c-959b-bc52e9644d53 2019-08-29T01:56:35+00:00 33S gs://<PROJECT_ID>_cloudbuild/source/1567043793.94-abfd382011724422bf49af1558b894aa.tgz gcr.io/<PROJECT_ID>/monolith:1.0.0 SUCCESS
빌드 기록을 보거나 프로세스를 실시간으로 확인하려면 Cloud 콘솔로 이동하세요. 왼쪽 상단의 메뉴 버튼을 클릭하고 Ci/CD로 스크롤한 다음 Cloud Build를 클릭하고 마지막으로 History를 클릭합니다. 이전 빌드 목록이 표시되지만, 생성한 빌드만 있어야 합니다.
빌드 ID를 클릭하면 로그 출력을 포함한 해당 빌드의 모든 세부정보를 확인할 수 있습니다.
빌드 세부정보 페이지에서 빌드 정보 섹션의 이미지 이름을 클릭하여 생성된 컨테이너 이미지를 볼 수 있습니다.
6. GKE에 컨테이너 배포
이제 웹사이트를 컨테이너화하고 컨테이너를 Container Registry에 푸시했으므로 Kubernetes에 배포할 수 있습니다.
GKE 클러스터에서 애플리케이션을 배포하고 관리하려면 Kubernetes 클러스터 관리 시스템과 통신해야 합니다. 일반적으로 kubectl 명령줄 도구를 사용하여 이 작업을 수행합니다.
Kubernetes는 애플리케이션을 포드로 나타냅니다. 포드는 컨테이너 (또는 긴밀하게 결합된 컨테이너의 그룹)를 나타내는 단위입니다. 포드는 Kubernetes에서 배포 가능한 최소 단위입니다. 여기에서는 각 포드에 모놀리식 컨테이너만 포함됩니다.
애플리케이션을 배포하려면 배포를 만들어야 합니다. 배포는 복제본이라고 하는 애플리케이션의 여러 사본을 관리하고, 이러한 사본이 클러스터의 개별 노드에서 실행되도록 예약합니다. 이 경우 배포는 애플리케이션의 포드 하나만 실행합니다. 배포는 ReplicaSet를 생성하여 이를 보장합니다. ReplicaSet는 지정된 수의 복제본이 항상 실행되도록 하는 역할을 합니다.
kubectl create deployment 명령어를 실행하면 Kubernetes가 클러스터에 1개의 복제본으로 monolith라는 배포를 만듭니다.
다음 명령어를 실행하여 애플리케이션을 배포합니다.
kubectl create deployment monolith --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:1.0.0
배포 확인
배포가 성공적으로 생성되었는지 확인하려면 다음 명령어를 실행합니다. 포드 상태가 'Running'이 되기까지 시간이 걸릴 수 있습니다.
kubectl get all
출력:
NAME READY STATUS RESTARTS AGE pod/monolith-7d8bc7bf68-htm7z 1/1 Running 0 6m21s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubernetes ClusterIP 10.27.240.1 <none> 443/TCP 24h NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE deployment.apps/monolith 1 1 1 1 20m NAME DESIRED CURRENT READY AGE replicaset.apps/monolith-7d8bc7bf68 1 1 1 20m
이 출력은 다음의 몇 가지를 보여줍니다. 현재 생성된 배포, 적절한 포드 수가 1인 ReplicaSet, 실행 중인 포드를 확인할 수 있습니다. 모든 항목이 성공적으로 생성된 것 같습니다.
리소스를 개별적으로 보려면 다음 명령어를 실행하면 됩니다.
# Show pods kubectl get pods # Show deployments kubectl get deployments # Show replica sets kubectl get rs #You can also combine them kubectl get pods,deployments
Kubernetes의 이점을 최대한 활용하려면 서버 충돌을 시뮬레이션하고 포드를 삭제하여 어떤 일이 일어나는지 확인해 보세요.
이전 명령어에서 포드 이름을 복사한 후 다음 명령어를 실행하여 삭제합니다.
kubectl delete pod/<POD_NAME>
충분히 빠르다면 이전 명령어를 실행하여 모든 항목을 다시 확인할 수 있습니다. 종료 중인 포드 하나와 생성 중이거나 실행 중인 포드 하나가 표시됩니다.
kubectl get all
출력:
NAME READY STATUS RESTARTS AGE pod/monolith-7d8bc7bf68-2bxts 1/1 Running 0 4s pod/monolith-7d8bc7bf68-htm7z 1/1 Terminating 0 9m35s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubernetes ClusterIP 10.27.240.1 <none> 443/TCP 24h NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE deployment.apps/monolith 1 1 1 1 24m NAME DESIRED CURRENT READY AGE replicaset.apps/monolith-7d8bc7bf68 1 1 1 24m
있다면 이유가 무엇인가? ReplicaSet은 포드가 종료되고 있음을 확인하고 원하는 복제본 수를 유지하기 위해 새 포드를 트리거했습니다. 나중에 여러 인스턴스가 실행되도록 확장하는 방법을 알아볼 텐데요. 이렇게 하면 인스턴스 하나가 다운되더라도 사용자에게는 다운타임이 표시되지 않습니다.
7. GKE 배포 노출
GKE에 애플리케이션을 배포했지만 클러스터 외부에서 애플리케이션에 액세스할 방법이 없습니다. 기본적으로 GKE에서 실행하는 컨테이너에는 외부 IP 주소가 없으므로 인터넷에서 이 컨테이너에 액세스할 수 없습니다. 서비스 리소스를 통해 애플리케이션을 인터넷 트래픽에 명시적으로 노출해야 합니다. 서비스는 앱의 포드에 네트워킹 및 IP 지원을 제공합니다. GKE는 앱의 외부 IP와 부하 분산기 (청구 대상)를 만듭니다.
다음 명령어를 실행하여 웹사이트를 인터넷에 노출합니다.
kubectl expose deployment monolith --type=LoadBalancer --port 80 --target-port 8080
출력:
service/monolith exposed
서비스 액세스
GKE는 외부 IP 주소를 배포가 아닌 서비스 리소스에 할당합니다. GKE가 애플리케이션에 프로비저닝한 외부 IP를 찾으려면 kubectl get service 명령어로 서비스를 검사하면 됩니다.
kubectl get service
출력:
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE monolith 10.3.251.122 203.0.113.0 80:30877/TCP 3d
앱의 외부 IP 주소를 확인한 후 복사합니다. 브라우저가 해당 URL (예: http://203.0.113.0)을 가리키도록 하여 앱에 액세스할 수 있는지 확인합니다.
이전에 테스트한 것과 동일한 웹사이트가 표시됩니다. 축하합니다. 이제 웹사이트가 Kubernetes에서 완전히 실행됩니다.
8. GKE 배포 확장
이제 GKE에서 앱의 인스턴스를 실행하고 인터넷에 노출했으므로 웹사이트가 매우 인기가 많아졌습니다. 트래픽을 처리할 수 있도록 앱을 여러 인스턴스로 확장할 수 있는 방법이 필요합니다. 애플리케이션을 최대 3개의 복제본으로 확장하는 방법을 알아봅니다.
다음 명령어를 실행하여 배포를 최대 3개의 복제본으로 확장합니다.
kubectl scale deployment monolith --replicas=3
출력:
deployment.apps/monolith scaled
확장된 배포 확인
배포가 성공적으로 확장되었는지 확인하려면 다음 명령어를 실행합니다.
kubectl get all
출력:
NAME READY STATUS RESTARTS AGE pod/monolith-7d8bc7bf68-2bxts 1/1 Running 0 36m pod/monolith-7d8bc7bf68-7ds7q 1/1 Running 0 45s pod/monolith-7d8bc7bf68-c5kxk 1/1 Running 0 45s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubernetes ClusterIP 10.27.240.1 <none> 443/TCP 25h service/monolith LoadBalancer 10.27.253.64 XX.XX.XX.XX 80:32050/TCP 6m7s NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE deployment.apps/monolith 3 3 3 3 61m NAME DESIRED CURRENT READY AGE replicaset.apps/monolith-7d8bc7bf68 3 3 3 61m
포드의 인스턴스 3개가 실행 중인 것을 확인할 수 있습니다. 또한 배포와 ReplicaSet의 원하는 개수가 이제 3개입니다.
9. 웹사이트에 변경사항 적용
마케팅팀에서 웹사이트의 홈페이지를 변경해 달라고 요청했습니다. 마케팅팀은 홈페이지에서 어떤 회사이며 무엇을 판매하는지에 대해 더 많은 정보를 제공해야 한다고 생각합니다. 이 섹션에서는 마케팅팀이 만족할 수 있도록 홈페이지에 텍스트를 추가합니다. 개발자 한 명이 이미 index.js.new라는 파일 이름에 변경사항을 작성했습니다. 파일을 index.js에 복사하면 변경사항이 반영됩니다. 아래 안내를 따라 적절하게 변경하세요.
다음 명령어를 실행하고, 업데이트된 파일을 올바른 파일 이름에 복사하고, 콘텐츠를 출력하여 변경사항을 확인합니다.
cd ~/monolith-to-microservices/react-app/src/pages/Home mv index.js.new index.js cat ~/monolith-to-microservices/react-app/src/pages/Home/index.js
결과 코드는 다음과 같습니다.
/*
Copyright 2019 Google LLC
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
https://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
*/
import React from "react";
import { makeStyles } from "@material-ui/core/styles";
import Paper from "@material-ui/core/Paper";
import Typography from "@material-ui/core/Typography";
const useStyles = makeStyles(theme => ({
root: {
flexGrow: 1
},
paper: {
width: "800px",
margin: "0 auto",
padding: theme.spacing(3, 2)
}
}));
export default function Home() {
const classes = useStyles();
return (
<div className={classes.root}>
<Paper className={classes.paper}>
<Typography variant="h5">
Fancy Fashion & Style Online
</Typography>
<br />
<Typography variant="body1">
Tired of mainstream fashion ideas, popular trends and societal norms?
This line of lifestyle products will help you catch up with the Fancy trend and express your personal style.
Start shopping Fancy items now!
</Typography>
</Paper>
</div>
);
}
React 구성요소를 업데이트했지만 정적 파일을 생성하려면 React 앱을 빌드해야 합니다. 다음 명령어를 실행하여 React 앱을 빌드한 다음 모놀리식 공개 디렉터리에 복사합니다.
cd ~/monolith-to-microservices/react-app npm run build:monolith
코드가 업데이트되었으므로 Docker 컨테이너를 다시 빌드하고 Container Registry에 게시해야 합니다. 이전과 동일한 명령어를 사용할 수 있지만 이번에는 버전 라벨을 업데이트합니다.
다음 명령어를 실행하여 업데이트된 이미지 버전 2.0.0으로 새 Cloud Build를 트리거합니다.
cd ~/monolith-to-microservices/monolith
#Feel free to test your application
npm start
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0 .
터미널 창에서 Control+C (Windows 또는 Mac)를 눌러 웹 서버 프로세스를 중지합니다.
다음 섹션에서는 이 이미지를 사용하여 다운타임 없이 애플리케이션을 업데이트합니다.
10. 다운타임 없이 웹사이트 업데이트
변경사항이 완료되었고 마케팅팀은 업데이트에 만족합니다. 이제 사용자에게 방해를 주지 않고 웹사이트를 업데이트할 수 있습니다. 아래 안내에 따라 웹사이트를 업데이트하세요.
GKE의 순차적 업데이트를 사용하면 실행 중인 모든 복제본에서 시스템이 이전 컨테이너 이미지의 인스턴스를 새것으로 교체할 때도 애플리케이션은 계속 실행되며 사용 가능합니다.
명령줄에서 다음 명령어를 사용하여 배포의 이미지를 새 버전으로 업데이트하겠다고 Kubernetes에 알릴 수 있습니다.
kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0
출력:
deployment.apps/monolith image updated
배포 확인
다음 명령어를 실행하여 배포 업데이트를 검증할 수 있습니다.
kubectl get pods
출력:
NAME READY STATUS RESTARTS AGE monolith-584fbc994b-4hj68 1/1 Terminating 0 60m monolith-584fbc994b-fpwdw 1/1 Running 0 60m monolith-584fbc994b-xsk8s 1/1 Terminating 0 60m monolith-75f4cf58d5-24cq8 1/1 Running 0 3s monolith-75f4cf58d5-rfj8r 1/1 Running 0 5s monolith-75f4cf58d5-xm44v 0/1 ContainerCreating 0 1s
3개의 새 포드가 생성되고 이전 포드가 종료되는 것을 확인할 수 있습니다. 연령을 보면 어떤 것이 새롭고 어떤 것이 오래되었는지 알 수 있습니다. 결국 3개의 포드만 다시 표시되며, 이 포드는 업데이트된 3개의 포드입니다.
변경사항을 확인하려면 부하 분산기의 외부 IP로 다시 이동하여 앱이 업데이트되었는지 확인합니다.
IP 주소를 잊은 경우 다음 명령어를 실행하여 서비스를 나열하고 IP 주소를 확인합니다.
kubectl get svc
웹사이트에 홈페이지 구성요소에 추가한 텍스트가 표시됩니다.
11. 삭제
Git 저장소 삭제
cd ~ rm -rf monolith-to-microservices
Container Registry 이미지 삭제
참고: 다른 버전을 만든 경우 동일한 구문을 사용하여 해당 이미지를 삭제할 수도 있습니다. 이 Codelab에서는 태그가 두 개만 있다고 가정합니다.
# Delete the container image for version 1.0.0 of our monolith
gcloud container images delete gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:1.0.0 --quiet
# Delete the container image for version 2.0.0 of our monolith
gcloud container images delete gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0 --quiet
Cloud Storage에서 Cloud Build 아티팩트 삭제
참고: 이 Codelab 이외의 아티팩트에 Cloud Build를 사용한 경우 Cloud Storage 버킷 gs://<PROJECT_ID>_cloudbuild/source에서 소스를 수동으로 삭제해야 합니다.
# The following command will take all source archives from all builds and delete them from cloud storage
# Run this command to print all sources:
# gcloud builds list | awk 'NR > 1 {print $4}'
gcloud builds list | awk 'NR > 1 {print $4}' | while read line; do gsutil rm $line; done
GKE 서비스 삭제
kubectl delete service monolith kubectl delete deployment monolith
GKE 클러스터 삭제
gcloud container clusters delete fancy-cluster
참고: 이 명령어는 다소 시간이 걸릴 수 있습니다.
12. 축하합니다.
GKE에서 웹사이트를 배포, 확장, 업데이트했습니다. 이제 Docker와 Kubernetes를 사용해 보았습니다.