Computer Engine(vm) vs Kubenetes(container)
왜 굳이 쿠버네티스를 사용하는가?
- vm에 비해 속도가 빠르다.
VM Server에 경우 가상화를 위한 게스트 os(os는 무거운편에 속함)가 필요하기 때문에
컨테이너의 경우 운영 체제(OS)를 가상화의 형식으로 활용 보통 리눅스
-
코드 통합이나 환경문제를 해결하는데 도움을 줍니다. 예로 기존 팀에 새로운 개발자가 들어왔을때 source code에 경우는 git hub같은 저장소를 활용하여 가져올 순 있겠지만 개발 환경을 통일하지 않으면 버전에 따른 문제가 발생할 확률이 높기 때문에 주의해야 하지만 컨테이너에 경우 서비스가 돌아가는데 필요한 Library 들을 전부 포함해, Container Image 라는 형식으로 사용할 수 있다.
it 업계에서 유명한 짤 : 내 컴퓨터에는 문제 없는데?
-
개별 서비스 확장에 유리하다. VM서버에 경우에도 확장이 가능하지만 어떤 특정 모듈만 확장하는게 힘들다. 모듈A에 부하가 생길경우 부하 해결을 위해 VM서버가 하나 더 생성하게 된다. 쿠버네티스의 경우 서비스별 컨테이너를 pod 형태로 관리 할 수 있기 때문에 서비스를 모듈별로 관리 하여 개발할 때 특정 모듈만 늘리고 줄이고가 가능하다.
CI/CD pipeline 왜 사용하는가?
기존의 소프트웨어 출시는 버그 발견 위험이나 막상 로컬 환경에서 문제 없이 돌아가다배포 버전 출시를 앞두고 사람이 실수를 하거나 환경차이, 버전문제로 인한 버그가 발생해 원점으로 돌아 가는 상황이 발생이 가능하다.
그러한 위험성을 배제 하기 위해서 (코드 -> 빌드 -> 테스트) 과정을 자동화하여 자주 배포 하고 테스트를 통해 실제로 문제가 있으면 알려주는 방식을 통해 코드 변경을 수월하게 끔 하는게 CI(Continuous Integration)
소프트웨어 출시 이후에도 시장에 지속적인 개선 제공을 위한 모델이 지속적인 배포와 릴리스 간격단축을 통해 버전관리를 담당하는 부분이 지속적 통합(Continuous Deployment) 또는 지속적 전달(Continuous delivery)이라고 하며 합쳐 CI/CD 파이프 모델이라고 할 수 있습니다.
CI/CD 파이프 라인에 장점
- 시장 출시 기간 단축 - 매번 테스트를 거친 후 배포 하기 때문에 사용자의 요구에 매주 혹은 매일 신속한 피드백 수렴이 가능하기 때문에 시장에 경쟁력을 갖출 수 있다.
- 위험 감소 - 그냥 출시 시간만 짧게 하는게 아닌 테스트를 거친 출시이기에
- 빌드 시간 단축 - 쿠버네티스를 사용 하기 위해서는 개별적으로 이미지를 빌드하고 푸시하는 귀찮은 과정을 생략 할 수 있음
참고 아키텍처
이 시스템 아키텍처 장점
- 코드 -> 빌드 -> 테스트 -> 배포까지의 자동화가능
- dev -> staging -> product 환경을 구분하여 안정성이 높음
- 독자적인 도구로 소프트웨어 배포를 관리가능 (구글 서비스만 이용)
- 한번 파이프라인을 갖추고 나면 적은 인원으로 시스템으로 관리가 가능하기 때문에 서비스에 집중가능
- 버전에러 발생시 롤백이 간편함
핵심 파이프라인
- 개발 작업 공간 Cloud Code
- 개발자들이 코드를 수정하고 배포 테스트가 자유로운 dev환경
- 빌드 및 테스트를 담당하는 Cloud build - CI
- 빌드 -> 테스트까지 자동화를 담당
- 배포 관리를 위한 Google Cloud Deploy - CD
- staging, product 환경 배포 담당
비용 관리
비용이 청구될 수 있는 리소스.
Cloud Build - 매일 빌드 시간 120분이 무료로 제공
Google Cloud Deploy - pipeline 하나는 무료
Artifact Registry - 100GB =14,300
Google Kubernetes Engine - e2-midum bookdisk100GB *2 = 280,000
Cloud Source Repositories - 100GB = 7200
Cloud Storage - 1TB =28,000
1month 329,500, 1year 3,954,000
GCP 요금 계산기
https://cloud.google.com/products/calculator?hl=ko
테스트 환경 준비
- 필요한 권한을 설정합니다.
- 스테이징 및 프로덕션 환경을 위한 GKE 클러스터를 만듭니다.
- 소스 리포지토리를 복제합니다.
- Cloud Source Repositories에 소스 코드용 저장소를 만듭니다.
- container app을 위해 Artifact Registry에 리포지토리를 생성합니다.
프로젝트 연결
gcloud config set project chchoi-project권한 설정 (API, service account)
필요한 API 설정 (Artifact Registry, Cloud Build, Google Cloud Deploy,
Cloud Source Repositories, Google Kubernetes Engine, Resource Manager, Service Networking API)
gcloud services enable artifactregistry.googleapis.com
gcloud services enable cloudbuild.googleapis.com
gcloud services enable clouddeploy.googleapis.com
gcloud services enable sourcerepo.googleapis.com
gcloud services enable container.googleapis.com
gcloud services enable cloudresourcemanager.googleapis.com
gcloud services enable servicenetworking.googleapis.com
service account 필요한 권한 부여 (CI/CD 파이프라인에 필요한 권한)
gcloud projects add-iam-policy-binding chchoi-project \
--member=serviceAccount:$(gcloud projects describe chchoi-project \
--format="value(projectNumber)")-compute@developer.gserviceaccount.com \
--role="roles/clouddeploy.jobRunner"- Google Cloud Deploy 작업을 대상에 배포할 수 있는 권한 없이 실행할 수 있습니다.
gcloud projects add-iam-policy-binding chchoi-project\
--member=serviceAccount:$(gcloud projects describe chchoi-project\
--format="value(projectNumber)")@cloudbuild.gserviceaccount.com \
--role="roles/clouddeploy.operator"- Google Cloud Deploy 대상 리소스 만들기, 검색, 업데이트, 삭제가 가능합니다.
gcloud projects add-iam-policy-binding chchoi-project \
--member=serviceAccount:$(gcloud projects describe chchoi-project \
--format="value(projectNumber)")-compute@developer.gserviceaccount.com \
--role="roles/container.admin"- 엣지 컨테이너의 모든 리소스에 대한 전체 액세스 권한
엣지 컨테이너?
대기 시간을 줄이고 대역폭을 절약하며 전반적인 디지털 경험을 향상시키기 위해 최종 사용자와 최대한 가까운 곳에 위치한 분산 컴퓨팅 리소스
gcloud projects add-iam-policy-binding chchoi-project \
--member=serviceAccount:$(gcloud projects describe chchoi-project\
--format="value(projectNumber)")@cloudbuild.gserviceaccount.com \
--role="roles/iam.serviceAccountUser"- 서비스 계정이 액세스하는 작업을 사용자도 간접적으로 액세스 할 수 있게끔 하는 권한
GKE 클러스터 생성 (Staging, production)
gcloud container clusters create-auto staging \
--region us-central1 \
--project=$(gcloud config get-value project) \
--asyncgcloud container clusters create-auto prod \
--region us-central1 \
--project=$(gcloud config get-value project) \
--async
staging -> product 환경을 구분하는 이유?
staging과 product는 모든 조건을 동일하게 만들어 staging에 문제 없이 배포 가능하면 product 환경에서 동일하게 실행 가능하게끔 구성하게 됨. 버전이 바뀔 때마다 먼저 staging 환경에서 테스트해보고 안정성이 높은 버전을 출시하기 위함. 또 버전 기록이 남기 때문에 혹시나 문제가 생겨도 롤백이 간편함.
Source code clone
git clone https://github.com/google/golden-path-for-app-delivery.gitCSR(Cloud Source Repositories)에 source code push**
CSR 생성
gcloud source repos create cicd-sampleCSR이란?
Google Cloud Platform에서 Github또는 Bitbucketd을 호스팅하여 관리 할 수 있는 Google에 클라우드 코드 플랫폼
레포지토리 연결
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-samplecode push
git push --all google
artifacts repo 생성
gcloud artifacts repositories create cicd-sample-repo \
--repository-format=Docker \
--location us-central1
artifact repo에 보관되는 것?
어떤 버전을 배포 할건지 docker image를 보관
Cloud Build Trigger 생성
gcloud beta builds triggers create cloud-source-repositories \
--name="cicd-sample-main" \
--repo="cicd-sample" \
--branch-pattern="main" \
--build-config="cloudbuild.yaml"Bulid Trigger란?
정해진 레포지토리에서 소스코드를 감시하고 조건에 맞춰 (ex.branch에 소스코드가 변경되면, 수동 업데이트) cloud bulid.yaml을 기준으로 순서대로 실행
substitutions:
_REGION: us-central1
steps:
- name: 'gcr.io/k8s-skaffold/skaffold'
entrypoint: 'sh'
args:
- -xe
- -c
- |
# Build and push images
skaffold build --file-output=/workspace/artifacts.json \
--default-repo=${_REGION}-docker.pkg.dev/$PROJECT_ID/cicd-sample-repo \
--push=true
# Test images
skaffold test --build-artifacts=/workspace/artifacts.json
- name: 'google/cloud-sdk:latest'
entrypoint: 'sh'
args:
- -xe
- -c
- |
gcloud config set deploy/region ${_REGION}
sed -i s/PROJECT_ID/$PROJECT_ID/g deploy/*
gcloud deploy apply --file deploy/pipeline.yaml
gcloud deploy apply --file deploy/staging.yaml
gcloud deploy apply --file deploy/prod.yaml
gcloud deploy releases create rel-${SHORT_SHA} \
--delivery-pipeline cicd-sample \
--description "$(git log -1 --pretty='%s')" \
--build-artifacts /workspace/artifacts.json \
--annotations "commit_ui=https://source.cloud.google.com/$PROJECT_ID/cicd-sample/+/$COMMIT_SHA"
artifacts:
objects:
location: 'gs://$PROJECT_ID-gceme-artifacts/'
paths:
- '/workspace/artifacts.json'
options:
machineType: E2_HIGHCPU_8
timeout: 3600sCloud Build란?
특정 트리거에 맞춰 정해진 코드를 순서대로 실행시켜주는 서비스
Artifact?
IT에서 Artifact는 빌드 결과로 나오는 개발 산출물을 Artifact라고 함
배포 패키지, WAR 파일, 로그 및 보고서 등 빌드 프로세스에서 생성된 파일
Skaffold?
Kubenetes용 CD툴
- 어플리케이션 수정으로 반영된 내용이 K8S에 올려서 바로 테스트하고 싶을때 사용
- Helm chart 와 비슷하게 실제 테스팅 또는 프로덕션 환경에 배포 할 수 있음
dev 환경에서 Code 빌드-> 테스트 해보기
로컬 환경에서 테스트를 위한 minikube 설치
minikube start- Shell 편집기에서 source code 클러스터 연동하기
Cloud Code - kubernetes를 누르면 생성해둔 클러스터를 선택하여 쉘 편집기에서 편하게 코드를 수정 할 수 있는 환경 생성가능
코드 변경
- 환경 구축이 끝나면 index.html, redis 같은 백엔드 프론트엔드의 코드 수정을 통해 자유롭게 빌드 테스트 배포가 가능해짐
코드 수정 후 디버깅을 돌리면 실제로 코드가 변경된 환경으로 들어가서 확인이 가능.
배포 파이프라인을 통한 staging 배포
git repo 설정
git config --global user.email "cks8483@naver.com"
git config --global user.name "cks8483"git commit
git add .
git commit -m "use lowercase for: sample app info"Cloud Source Repositories에 git push
git push google
staging -> product 정식 배포
Code build에서 우선 staging 클러스터에 먼저 배포를 진행하여 테스트 이후 이상이 없으면 승격 요청을하고 관리 조직원이 승낙하면 product로 배포.
staging이 문제 없으면 승격 버튼을 눌러서 production에 정식 배포
리소스 삭제
- Google Cloud Deploy 파이프라인을 삭제합니다.
gcloud deploy delivery-pipelines delete cicd-sample --region=us-central1 --force- Cloud Build 트리거를 삭제합니다.
gcloud beta builds triggers delete cicd-sample-main- 스테이징 및 프로덕션 클러스터를 삭제합니다.
gcloud container clusters delete staging --region=us-central1
gcloud container clusters delete prod --region=us-central1- Cloud Source Repositories에서 저장소를 삭제합니다.
gcloud source repos delete cicd-sample- Cloud Storage 버킷을 삭제합니다.
gsutil rm -r gs://$(gcloud config get-value project)-gceme-artifacts/
gsutil rm -r gs://$(gcloud config get-value project)_clouddeploy/- Artifact Registry에서 저장소를 삭제합니다.
gcloud artifacts repositories delete cicd-sample-repo \
--location us-central1