GKE (Google Cloud Study Jam) : Google Kubernetes Engine으로 설계하기: 프로덕션 -4

LEE EUI JOO·2023년 8월 4일
0

GCP

목록 보기
7/7

1. CI / CD Pipelines

CI CD를 올바르게 구현하려면 파이프라인을 구성해야 하는데 파이프라인은 애플리케이션 코드 베이스의 버전을 가져와 프로덕션으로 릴리스하는 데 필요한 모든 단계를 수행하는 프로세스이다.

파이프라인은 수동으로 트리거하거나 변경 사항이 코드 베이스에 푸시될 때 자동으로 트리거될 수 있으며 일반적으로 별도의 단계로 구성된다.

가장 흔하게는 Build, Deploy, Test, Approve 의 4가지이다.

첫 번째에서 코드 베이스는 특정 버전 및 아티팩트로 체크아웃되며 예를 들어 Docker 컨테이너 이미지가 빌드되고 빌드 단계 후 다음 단계가 이 단계에 배포되고 아티팩트가 프로덕션 환경을 복제하는 테스트 환경에 배포된다.

애플리케이션이 배포된 후 테스트 단계로 이동하여 애플리케이션은 애플리케이션 품질을 보장하기 위해 여러 가지 방법으로 테스트되며 테스트의 가장 일반적인 유형은 유니스, 기능, 통합, 취약성 및 성능이다.

마지막으로 애플리케이션이 모든 테스트를 통과하면 승인 단계로 이동할 수 있고 이 단계에서 개발자는 파이프라인이 프로덕션 환경으로 진행되어야 하는지 여부를 수동으로 결정한다.

2. CI / CD Spectrum

CI / CD에 대해 이야기할 때 하나의 '버전'만 있는 것은 아니며 수동에서 거의 완전 자동화에 이르기까지 다양한 구현이 있다.

스펙트럼의 각 지점에는 장점과 단점이 있는데 위의 예시를 보면서 몇 가지 옵션을 살펴보자.

가장 낮은 수준에서는 완전한 수동, 즉 CI/CD가 없으며 이 상황에서 각 개발자는 자신이 작성한 모든 코드의 통합 및 배포에 대한 책임이 있으며 다른 개발자의 코드와 충돌하지 않도록 하는데 이것은 우리가 목표로 하는 스펙트럼의 종착지는 아니다.

다음 레벨은 고정된 자동화 세트가 내장된 패키지 도구인데 이는 CI/CD 도구에 전적으로 의존하며 이러한 도구는 일반적으로 유지 관리하거나 검토하기 어려운 매우 구체적인 사용자 지정을 허용하므로 합리적으로 복잡한 시스템에는 적합하지 않는 방식이다.

개발 중심 CI / CD는 시스템 코드 저장소를 중심으로 하는데 이러한 CI/CD 스타일의 좋은 예는 GitOps를 사용하는 것이다.

GitOps는 소스 리포지토리를 애플리케이션의 기둥으로 사용하는 방법론이며 코드와 구성 파일을 모두 리포지토리에 저장하는 방식이다.

Kubernetes 환경에서는 매니페스트 및 yaml 파일을 저장하여 애플리케이션의 배포를 정의하는 방식으로 진행한다.

Cloud Build는 Google Cloud에서 이러한 파이프라인을 만들 수 있는 Google 도구이며 잠시 후에 실습에서 다뤄볼 것이다.

마지막으로 높은 수준의 관리 및 모니터링을 보장하는 데 중점을 둔 운영 중심 CI/CD가 있다.

이 컨트롤은 비용이 많이 들고 개발자에게 친숙하지 않지만 매우 높은 수준의 구성 가능성을 제공하는데 이러한 운영 중심 CI/CD를 구현하는 일반적인 도구는 Spinnaker이다.

Spinnaker는 수천 개의 인스턴스가 포함된 대규모 배포를 처리하도록 설계되었으며 이 시나리오에서 도구 관리 비용은 배포 규모에 따라 책정된다.

3. CI / CD 도구의 예

Google Cloud에는 이를 지원하는 다양한 도구가 있는데 Google Cloud Marketplace에도 인프라, 애플리케이션, 이 경우 CI/CD 파이프라인 생성을 지원하는 다양한 도구가 있다.

가장 일반적으로 사용되는 몇 가지 CI/CD 도구를 살펴볼텐데 애플리케이션에 이미 CI/CD를 사용하고 있다면 익숙할 것이다.

  • Jenkins

    • 가장 초기의 오픈 소스 연속 통합 서버 중 하나이며 오늘날 가장 일반적으로 사용됨 * Spinnaker
    • 소프트웨어 변경 사항을 신속하고 확실하게 릴리스할 수 있도록 지원하는 오픈 소스 다중 클라우드, 지속적 제공 플랫폼

  • CircleCI

    • 지속적 통합 및 제공 플랫폼을 사용하면 모든 규모의 팀이 고품질 소프트웨어를 대규모로 신속하게 빌드하고 출시할 수 있음

  • GitLab CI

    • git 리포지토리 호스팅 및 개발 도구용 플랫폼인 GitLab에 내장된 지속적인 통합 도구

  • Drone

    • 컨테이너 우선 아키텍처로 구축된 최신 CI/CD 플랫폼이며 Docker로 빌드를 실행하는 것은 Drone 디자인의 핵심이다.

지금까지 언급한 도구에 익숙할 수 있는데, AWS에서 CodeBuild, CodeDeploy가 있는것 처럼 GCP에서도 이러한 개발자 도구를 지원한다.

  • Cloud Build

    • Google Cloud 환경 내에서 워크플로를 빌드, 테스트 및 배포할 수 있는 Google 고유의 지속적 통합 도구

    • Cloud Build는 로컬 빌드 및 온프레미스 환경에서도 실행가능

    • Cloud Build는 Google Cloud의 인프라, 온프레미스 환경 또는 이 둘의 혼합에서 빌드를 실행할 수 있는 서비스

    • Cloud Build는 다양한 저장소 또는 Cloud Storage 공간에서 소스 코드를 가져올 수 있음

    • 사양에 맞게 빌드를 실행하고 컨테이너 이미지 또는 Java 아카이브와 같은 아티팩트를 생성할 수도 있다.

    • 사전 정의된 트리거를 기반으로 소스 코드 또는 릴리스 태그의 변경사항에 반응하도록 Cloud Build를 구성할 수 있으며 Cloud Build 내에서 공통 볼륨, 슬래시 작업 공간이 관리되며 애플리케이션 소스 코드가 이 파일에 추가된다.

    • 각 빌드 단계는 독립적으로 컨테이너로 생성되며 슬래시 워크스페이스 볼륨이 공통이기 때문에 각 컨테이너가 작동할 수 있기 때문에 이 환경에서는 중복 데이터 저장소에 대한 필요성이 줄어든다.

    • Cloud Build에서 docker, git, kubectl, helm과 같은 도구는 slash 작업 영역 볼륨의 단계에서 컨테이너로 작동할 수 있고, Container Registry, Artifact Registry, Cloud Storage, GKE와 같은 다른 Google Cloud 제품과의 상호작용을 허용한다.

4. Cloud Build를 사용하는 Google Kubernetes Engine용 CI/CD 실습

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

이 실습에서는 2개의 Git 리포지토리를 생성한다.

  • App repo: 애플리케이션 자체의 소스 코드를 포함
  • Env repo: Kubernetes 배포에 대한 매니페스트를 포함

App repo 에 변경사항을 푸시하면 Cloud Build 파이프라인이 테스트를 실행하고 컨테이너 이미지를 빌드한 다음 Artifact Registry에 푸시한다.

이미지를 푸시한 후 Cloud Build는 배포 매니페스트를 업데이트하고 이를 Env repo에 푸시한다.

이렇게 하면 매니페스트를 GKE 클러스터에 적용하는 또 다른 Cloud Build 파이프라인이 트리거되고 성공하면 env repo 의 다른 분기에 매니페스트를 저장한다.

수명 주기와 용도가 다르기 때문에 app 및 env 저장소를 별도로 유지하는데, 앱 리포지토리 의 주요 사용자 는 실제 사람이며 이 리포지토리는 특정 애플리케이션 전용이다.

env 리포지토리 의 주요 사용자 는 자동화된 시스템(예: Cloud Build)이며 이 리포지토리는 여러 애플리케이션에서 공유될 수 있다.

env 리포지토리에는 각각 특정 환경(이 랩에서는 프로덕션만 사용함)에 매핑되고 특정 컨테이너 이미지를 참조하는 여러 분기가 있을 수 있지만 앱 리포지토리는 그렇지 않다.

우리의 목표

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

4-1. 랩 초기화

이 작업에서는 필요한 API를 사용 설정하고 Cloud Shell에서 git 구성을 초기화하고 나중에 실습에서 사용되는 샘플 코드를 다운로드하여 사용할 Google Cloud 프로젝트를 준비한다.

  • Cloud Shell에서 아래 명령어를 실행하여 GKE, Cloud Build, Cloud Source Repositories, Container Analysis용 API를 사용 설정
gcloud services enable container.googleapis.com \
    cloudbuild.googleapis.com \
    sourcerepo.googleapis.com \
    containeranalysis.googleapis.com
  • 컨테이너 이미지를 저장할 지역 us-central1 에 my-repository 이름이 지정된 Artifact Registry Docker 저장소를 생성
gcloud artifacts repositories create my-repository \
  --repository-format=docker \
  --location=us-central1
  • GKE 클러스터 생성
gcloud container clusters create hello-cloudbuild \
    --num-nodes 1 --region us-central1
  • Cloud Shell에서 Git을 사용한 적이 없는 경우 이름과 이메일 주소로 구성
git config --global user.email "you@example.com"  
git config --global user.name "Your Name"

4-2. Cloud Source 저장소에 Git 저장소 생성

이 작업에서는 이 실습에서 사용되는 두 개의 Git 리포지토리(hello-cloudbuild-app 및 hello-cloudbuild-env)를 생성하고 몇 가지 샘플 코드로 hello-cloudbuild-app를 초기화한다.

  • Cloud Shell에서 두 개의 Git 저장소 생성
gcloud source repos create hello-cloudbuild-app
gcloud source repos create hello-cloudbuild-env
  • GitHub에서 샘플 코드를 복제
cd ~
git clone https://github.com/GoogleCloudPlatform/gke-gitops-tutorial-cloudbuild \
    hello-cloudbuild-app
  • Cloud Source Repositories를 원격으로 구성
cd ~/hello-cloudbuild-app
PROJECT_ID=$(gcloud config get-value project)
git remote add google \
    "https://source.developers.google.com/p/${PROJECT_ID}/r/hello-cloudbuild-app"
### 복제한 코드에는 간단한 "Hello World" 애플리케이션이 포함되어 있음(Flask)

4-3. Cloud Build로 컨테이너 이미지 생성

  • 클론한 레포에는 이미 Dockerfile이 존재하며 Dockerfile을 사용하면 Cloud Build로 컨테이너 이미지를 만들고 Container Registry에 저장할 수 있다.
FROM python:3.7-slim
RUN pip install flask
WORKDIR /app
COPY app.py /app/app.py
ENTRYPOINT ["python"]
CMD ["/app/app.py"]
  • Cloud Shell에서 다음 명령어를 사용하여 최신 커밋을 기반으로 Cloud Build 빌드를 생성한다.
cd ~/hello-cloudbuild-app
COMMIT_ID="$(git rev-parse --short=7 HEAD)"
gcloud builds submit --tag="us-central1-docker.pkg.dev/${PROJECT_ID}/my-repository/hello-cloudbuild:${COMMIT_ID}" .
  • 빌드가 완료되면 Google Cloud Console Artifact Registry ➡️ 레포지토리에서 Artifact Registry에서 새 컨테이너 이미지를 실제로 사용할 수 있는지 확인 ➡️ 내 저장소를 클릭

4-4. 지속적 통합(CI) 파이프라인 생성

이 작업에서는 작은 단위 테스트를 자동으로 실행하고 컨테이너 이미지를 빌드한 다음 이를 Container Registry에 푸시하도록 Cloud Build를 구성한다.

Cloud Source Repositories에 새 커밋을 푸시하면 이 파이프라인이 자동으로 트리거되며 코드에 이미 포함된 cloudbuild.yaml 파일은 파이프라인 구성파일이다.

  1. Google Cloud Console에서 Cloud Build ➡️ 트리거

  2. 트리거 만들기 를 클릭

  3. 이름 필드에 hello-cloudbuild 를 입력

  4. 이벤트 아래에서 분기로 푸시를 선택

  5. 소스 아래에서 리포지토리 로 hello-cloudbuild-app를 선택 하고 Branch 에 대해 ^master$를 입력

  6. 빌드 구성 에서 Cloud Build 구성 파일을 선택

  7. Cloud Build 구성 파일 위치 필드 에서 / 뒤에 cloudbuild.yaml을 입력

  8. 만들기 클릭

  9. 이제 애플리케이션 코드를 Cloud Source Repositories로 푸시하여 Cloud Build에서 CI 파이프라인을 트리거

$ cd ~/hello-cloudbuild-app 
git push google master
Enumerating objects: 28, done.
Counting objects: 100% (28/28), done.
Delta compression using up to 2 threads
Compressing objects: 100% (20/20), done.
Writing objects: 100% (28/28), 16.90 KiB | 16.90 MiB/s, done.
Total 28 (delta 6), reused 28 (delta 6), pack-reused 0
remote: Resolving deltas: 100% (6/6)
remote: Waiting for private key checker: 16/16 objects left
To https://source.developers.google.com/p/qwiklabs-gcp-01-1084cb57bbe7/r/hello-cloudbuild-app
 * [new branch]      master -> master
  1. Google Cloud Console에서 Cloud Build ➡️ 대시보드로 이동
  • 실행 중이거나 최근에 완료된 빌드가 표시되어야 하며 빌드를 클릭하여 실행을 추적하고 로그를 검사할 수 있다.

4-5. 테스트 환경 및 CD 파이프라인 생성

Cloud Build는 지속적 배포 CD 파이프라인에도 사용되는데 Commit이 __hello-cloudbuild-env__repository의 후보 분기로 푸시될 때마다 파이프라인이 실행되기 때문이다.

파이프라인은 새 버전의 매니페스트를 Kubernetes 클러스터에 적용하고 성공하면 매니페스트를 프로덕션 브랜치로 복사하는데 이 프로세스에는 다음과 같은 속성이 있다.

  • 후보 분기는 배포 시도의 히스토리(기록)이다.

  • 프로덕션 분기는 성공적인 배포의 기록이다.

  • Cloud Build에서 성공한 배포와 실패한 배포를 볼 수 있다.

  • Cloud Build에서 해당 빌드를 다시 실행하여 이전 배포로 롤백할 수 있으며 롤백은 프로덕션 분기를 업데이트하여 배포 기록을 정직하게 반영한다.

  • CD 파이프라인을 수정하여 hello-cloudbuild-env 리포지토리 의 후보 분기를 업데이트하여 CD 파이프라인을 트리거한다.

GKE에 Cloud Build 액세스 권한 부여

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

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 저장소 초기화
배포 프로세스를 설명하는 Cloud Build 구성 파일과 두 개의 분기(프로덕션 및 후보)로 hello-cloudbuild-env 저장소를 초기화한다.

  • hello-cloudbuild-env 리포지토리를 복제 하고 프로덕션 브랜치를 생성 (아직 비어있음)
cd ~
gcloud source repos clone hello-cloudbuild-env
cd ~/hello-cloudbuild-env
git checkout -b production
  • hello-cloudbuild-app 리포지토리 에서 사용할 수 있는 cloudbuild-delivery.yaml 파일을 복사 하고 변경 사항을 커밋
cd ~/hello-cloudbuild-env
cp ~/hello-cloudbuild-app/cloudbuild-delivery.yaml ~/hello-cloudbuild-env/cloudbuild.yaml

cat cloudbuild.yaml 
# Copyright 2018 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.

# [START cloudbuild-delivery]
steps:
# This step deploys the new version of our container image
# in the hello-cloudbuild Kubernetes Engine cluster.
- name: 'gcr.io/cloud-builders/kubectl'
  id: Deploy
  args:
  - 'apply'
  - '-f'
  - 'kubernetes.yaml'
  env:
  - 'CLOUDSDK_COMPUTE_REGION=us-central1'
  - 'CLOUDSDK_CONTAINER_CLUSTER=hello-cloudbuild'

# This step copies the applied manifest to the production branch
# The COMMIT_SHA variable is automatically
# replaced by Cloud Build.
- name: 'gcr.io/cloud-builders/git'
  id: Copy to production branch
  entrypoint: /bin/sh
  args:
  - '-c'
  - |
    set -x && \
    # Configure Git to create commits with Cloud Build's service account
    git config user.email $(gcloud auth list --filter=status:ACTIVE --format='value(account)') && \
    # Switch to the production branch and copy the kubernetes.yaml file from the candidate branch
    git fetch origin production && git checkout production && \
    git checkout $COMMIT_SHA kubernetes.yaml && \
    # Commit the kubernetes.yaml file with a descriptive commit message
    git commit -m "Manifest from commit $COMMIT_SHA
    $(git log --format=%B -n 1 $COMMIT_SHA)" && \
    # Push the changes back to Cloud Source Repository
    git push origin production
# [END cloudbuild-delivery]


git add .
git commit -m "Create cloudbuild.yaml for deployment"  
참고: cloudbuild-delivery.yaml 파일은 Cloud Build에서 실행할 배포 프로세스가 담겨있다.

-> Cloud Build는 GKE 클러스터에 매니페스트를 적용
-> 성공하면 Cloud Build가 프로덕션 브랜치에 매니페스트를 복사
  • 후보 분기를 만들고 Cloud Source Repositories에서 사용할 수 있도록 두 분기를 모두 푸시
git checkout -b candidate
git push origin production
git push origin candidate
  • 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

CD 파이프라인에 대한 트리거 생성

  1. Cloud Build ➡️ 트리거 ➡️ 트리거 만들기 클릭

  2. 이름 필드에 hello-cloudbuild-deploy 를 입력

  3. 이벤트 아래에서 분기로 푸시를 선택

  4. Source 아래에서 저장소로 hello-cloudbuild-env를 선택 하고 Branch 로 ^candidate$를 선택

  5. 빌드 구성 에서 Cloud Build 구성 파일을 선택

  6. Cloud Build 구성 파일 위치 필드 에서 / 뒤에 cloudbuild.yaml을 입력 ➡️ 만들기 클릭

CD 파이프라인을 트리거하도록 CI 파이프라인 수정

새 버전의 Kubernetes 매니페스트를 생성하고 이를 __hello-cloudbuild-env__repository로 푸시하여 CD 파이프라인을 트리거하는 CI 파이프라인에 몇 가지 단계를 추가할 것이다.

  • 앱 리포지토리 에 대한 cloudbuild.yaml 파일 의 확장 버전을 복사
cd ~/hello-cloudbuild-app
cp cloudbuild-trigger-cd.yaml cloudbuild.yaml

cat cloudbuild.yaml 
# Copyright 2018 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.

# [START cloudbuild]
steps:
# This step runs the unit tests on the app
- name: 'python:3.7-slim'
  id: Test
  entrypoint: /bin/sh
  args:
  - -c
  - 'pip install flask && python test_app.py -v'

# This step builds the container image.
- name: 'gcr.io/cloud-builders/docker'
  id: Build
  args:
  - 'build'
  - '-t'
  - 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repository/hello-cloudbuild:$SHORT_SHA'
  - '.'

# This step pushes the image to Artifact Registry
# The PROJECT_ID and SHORT_SHA variables are automatically
# replaced by Cloud Build.
- name: 'gcr.io/cloud-builders/docker'
  id: Push
  args:
  - 'push'
  - 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repository/hello-cloudbuild:$SHORT_SHA'
# [END cloudbuild]

# [START cloudbuild-trigger-cd]
# This step clones the hello-cloudbuild-env repository
- name: 'gcr.io/cloud-builders/gcloud'
  id: Clone env repository
  entrypoint: /bin/sh
  args:
  - '-c'
  - |
    gcloud source repos clone hello-cloudbuild-env && \
    cd hello-cloudbuild-env && \
    git checkout candidate && \
    git config user.email $(gcloud auth list --filter=status:ACTIVE --format='value(account)')

# This step generates the new manifest
- name: 'gcr.io/cloud-builders/gcloud'
  id: Generate manifest
  entrypoint: /bin/sh
  args:
  - '-c'
  - |
     sed "s/GOOGLE_CLOUD_PROJECT/${PROJECT_ID}/g" kubernetes.yaml.tpl | \
     sed "s/COMMIT_SHA/${SHORT_SHA}/g" > hello-cloudbuild-env/kubernetes.yaml

# This step pushes the manifest back to hello-cloudbuild-env
- name: 'gcr.io/cloud-builders/gcloud'
  id: Push manifest
  entrypoint: /bin/sh
  args:
  - '-c'
  - |
    set -x && \
    cd hello-cloudbuild-env && \
    git add kubernetes.yaml && \
    git commit -m "Deploying image us-central1-docker.pkg.dev/$PROJECT_ID/my-repository/hello-cloudbuild:${SHORT_SHA}
    Built from commit ${COMMIT_SHA} of repository hello-cloudbuild-app
    Author: $(git log --format='%an <%ae>' -n 1 HEAD)" && \
    git push origin candidate

# [END cloudbuild-trigger-cd]

cloudbuild-trigger-cd.yaml은 cloudbuild.yaml 파일의 확장 버전이며 아래 단계를 추가하여 새 Kubernetes 매니페스트를 생성하고 CD 파이프라인을 트리거한다.

참고: 이 파이프라인은 간단한 sed를 사용하여 매니페스트 템플릿을 렌더링한다.
실제로 kustomize 또는 skaffold와 같은 전용 도구를 사용하면 
매니페스트 템플릿의 렌더링을 더 잘 제어할 수 있는 이점이 있다.
  • 수정 사항을 커밋하고 Cloud Source Repositories에 푸시
    • 이렇게 하면 Cloud Build에서 CI 파이프라인이 트리거된다.
cd ~/hello-cloudbuild-app
git add cloudbuild.yaml
git commit -m "Trigger CD pipeline"
git push google master

4-6. Cloud Build 파이프라인 검토

대시보드로 들어가서 실행을 추적하고 로그를 검사하려면 hello-cloudbuild-app 트리거를 클릭하면 된다.

이 파이프라인의 마지막 단계는 CD 파이프라인을 트리거하는 hello-cloudbuild-env 저장소에 새 매니페스트를 푸시한다.

4-7. 전체 파이프라인 테스트

이제 전체 CI/CD 파이프라인이 구성되었고 이제 처음부터 끝까지 테스트를 해보자.

$ kubectl get svc
NAME               TYPE           CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE
hello-cloudbuild   LoadBalancer   10.112.2.24   35.239.58.8   80:31763/TCP   4m51s
kubernetes         ClusterIP      10.112.0.1    <none>        443/TCP        21m

$ curl 35.239.58.8
Hello World!
  • 애플리케이션과 단위 테스트 모두에서 "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

$ cat test_app.py 
# Copyright 2018 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 unittest
from app import hello

class TestHelloApp(unittest.TestCase):

  def test_hello(self):
    self.assertEqual(hello(), "Hello World!\n")

if __name__ == '__main__':
  unittest.main()
  • Cloud Source Repositories에 변경 사항을 커밋하고 푸시
git add app.py test_app.py
git commit -m "Hello Cloud Build"
git push google master
  • 이렇게 하면 전체 CI/CD 파이프라인이 트리거되고 curl 쳐보면 새로운 문구가 등장할 것이다.

4-8. 롤백 테스트

"Hello World!"라고 표시된 애플리케이션 버전으로 롤백해보자.

  1. Google Cloud Console에서 Cloud Build ➡️ 대시보드 ➡️ hello-cloudbuild-env 리포지토리 의 빌드 기록 아래에서 모두 보기 링크를 클릭

  2. 사용 가능한 두 번째 최신 빌드를 클릭 (최신 이전 버전)

  1. 재구축(Rebuild) 하고 로드밸런서 엔드포인트로 접속하여 롤백상태 확인

4-9. 파이프라인 예시

이제 Cloud Build를 사용하여 애플리케이션과의 CI 워크플로를 설정하는 방법을 살펴보았으므로 더 복잡한 예를 살펴볼텐데, 먼저 파이프라인을 살펴보고 각 단계에서 어떤 일이 발생하는지 살펴보겠다.

  1. 파이프라인의 첫 번째 요점은 개발자가 애플리케이션의 소스 코드를 변경하고 업데이트를 리포지토리에 푸시한다는 것이다.

  2. 다음으로는 코드의 변경 사항을 감지하는 CI 도구가 트리거된다.

  3. 트리거는 업데이트된 코드를 기반으로 새 Docker 컨테이너 이미지를 빌드한다.

  4. 컨테이너 이미지가 빌드된 후 CI 도구는 단위 테스트를 수행하는데 이 과정이 성공적으로 완료되면 도커 이미지가 Container Registry로 푸시된다.

  5. 이 단계에서 CD 도구는 새 이미지를 감지하여 개발 환경으로 푸시한다.

  6. 배포 후 새 프로덕션 환경으로 이동하고 트래픽이 이 환경으로 천천히 이동하기 전에 수동 확인을 기다리며 시간 제한에 도달하면 이전 프로덕션 환경이 폐기되는 방식이다.

애플리케이션이 프로덕션에 배포된 후 Kubernetes 클러스터에 배포되도록 마지막 예제를 확장할 수 있는데 이 예에서는 Spinnaker를 사용하여 GKE에 내장된 클라우드에서 빌드한 새 컨테이너 이미지를 사용하여 새 컨테이너를 배포하고 새 이미지가 배포된 후 Spinnaker는 이전 이미지를 삭제한다.

여기서 핵심은 기본 인프라가 그대로 유지된다는 것이다.

개발자가 커밋을 푸시하면 Cloud Build가 Spinnaker 파이프라인을 트리거하여 새 ReplicaSet를 생성 및 배포하고 기존 항목을 제거하는데 이 아키텍처를 들여다보면 Kubernetes 클러스터 노드가 남아 있고 부분만 생성 및 소멸되는 과정을 볼 수 있다.

4-10. CI / CD 예제

On-Prem

이제 CI/CD가 무엇이고 CI/CD 파이프라인에서 사용되는 공통 도구가 무엇인지 이해했으므로 다양한 환경에서 CI/CD의 몇 가지 예를 살펴보자

이러한 각 예에서 CI/CD를 사용하는 Kubernetes 환경을 살펴볼텐데 살펴볼 첫 번째 예는 전체 파이프라인을 온프레미스에 두는 것이다.

개발자는 소스 코드를 푸시하고 Git 리포지토리에 제출하며 이 Git 푸시는 인프라 클러스터의 컨트롤 플레인 노드에 연결하여 작업자 노드에 작업을 위임한다.

작업자 노드는 업데이트된 소스 코드를 빌드하고 테스트하고 테스트가 성공적으로 완료된 후 작업자 노드는 작업을 프로덕션 클러스터의 컨트롤 플레인 노드에 위임하며 프로덕션 클러스터 컨트롤 플레인 노드는 업데이트된 애플리케이션을 작업자 노드에 배포하는 작업을 위임하여 전체 플로우가 끝이 난다.

이 아키텍처는 Kubernetes를 기반으로 하기 때문에 자동으로 확장되며 단일 장애 지점이 없지만 지리적으로 제한되고 일부 추가 리소스가 필요하다는 단점이 있을 수 있다.

Cloud

이제 완전히 Google Cloud에 기반한 예를 살펴보자

개발자는 소스 코드를 업데이트하고 저장소에 커밋하면 이 작업은 Cloud Build를 트리거하여 업데이트된 컨테이너를 만들고 컨테이너 레지스트리에 푸시한다.

이제 업데이트된 애플리케이션이 컨테이너 레지스트리에서 가져와 테스트 환경에 배포된다.

로드 밸런서는 컨트롤 플레인 노드를 연결하여 파트 1에서 실행 중인 Git 서비스에 액세스하고 리포지토리는 트리거를 통해 CI/CD 파이프라인에 알린다.

CI/CD 작업자는 업데이트된 애플리케이션을 테스트 클러스터에 전달하고 이제 업데이트된 애플리케이션에서 테스트가 수행된다.

업데이트된 애플리케이션은 다른 로드 밸런서 세션을 통해 프로덕션 클러스터에 배포되면서 플로우가 끝이난다.

이 클라우드 CI/CD 아키텍처는 배포가 빠르고 단일 실패 지점이 없으며 서버리스 아키텍처 즉, 클러스터를 관리할 필요조차 없다.

서버에 대한 이슈는 Cloud Run이 이를 처리한다.

profile
LEE EUI JOO
무럭무럭 자라볼까
이전 포스트

GKE (Google Cloud Study Jam) : Google Kubernetes Engine으로 설계하기: 프로덕션 -3

0개의 댓글