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
클러스터가 생성되려면 몇 분 정도 걸릴 수 있습니다. 이후 다음 명령어를 실행하고 클러스터의 작업자 가상 머신 (VM) 인스턴스 3개를 확인합니다.
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 빌드 프로세스를 실행합니다. 호스트와 함께 --tag 플래그를 Docker 이미지의 gcr.io로 지정했기 때문에 결과로 생성되는 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를 클릭하고 마지막으로 기록을 클릭합니다. 여기에서 이전 빌드 목록을 볼 수 있지만 직접 만든 빌드만 표시됩니다.
빌드 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개가 실행 중인 것을 확인할 수 있습니다. 또한 Deployment와 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를 사용해 봤습니다.