Google Cloud의 Cloud Deploy로 자동화된 CI/CD Pipeline 구성하기

 

 

본 포스팅은 2021년 11월 3일 필자가 GDG devfest 2021에서 발표한 내용을 기반으로 작성했습니다.

 

 

이번 Google Cloud Next 21에서 여러 Google Cloud Platform 서비스를 발표했습니다. 

 

발표한 서비스는 Dataplex, Analytics Hub 등.. 주로 데이터 플랫폼에 힘을 실어주는 서비스가 주로 등장했습니다.

 

그 중에 데이터 플랫폼이 아닌 다른 분야에서 나온 서비스가 하나 있습니다.

 

개인적으로 타 CSP에 비해 약하고 생각했던 CI/CD 분야의 서비스인 Cloud Deploy가 그것입니다.

 

데이터 플랫폼은 예로부터 GCP가 강한 분야였기 때문에 이에 힘을 실어주는 서비스의 등장은 GCP의 장점을 부각시키는 것이었지만,

 

CI/CD 분야 서비스인 Cloud Deploy의 등장은 GCP가 상대적으로 약한 분야를 보완할 수 있는 런칭이라서 더욱 특별하게 느껴졌습니다.

 

그래서 이번 포스팅은 새로 등장한 Cloude Deploy를 어떻게 사용할 수 있는지, 간단한 CI/CD Pipeline을 구성해서 알아보겠습니다.

 

 

 

1. Google Cloud Deploy란?

 

 

 

Google Cloud Deploy는 OSS CI/CD 툴인 Skaffold를 기반으로 만들어졌습니다.

 

Skaffold는 이제 CI/CD 툴의 대세가 되었다고 할 수 있을 정도로 많은 유저들이 사용하고 있는 OSS입니다.

 

YAML파일의 매니페스트 하나를 생성하는 것으로 완전한 CI/CD 파이프라인을 구성할 수 있을 정도로 간편하고 강력한 툴이기도 합니다.

 

이 Skaffold는 Google이 제작한 툴이기 때문에 Cloud Deploy에도 Skaffold의 기능들을 잘 녹여냈을 것이라고 예상할 수 있습니다. 

 

Google Cloud Next 21 "Secure and reliable continuous delivery to GKE" 세션을 기반으로 그린 슬라이드 

 

Cloud Deploy는 이 Skaffold를 관리형 서비스로 제공하는 Continuous Delivery 서비스입니다.

 

기존에 Skaffold가 할 수 있었던 CD 기능에 관리형 서비스에서 제공하는 모니터링, 감사, 관리 및 스케일링 기능들을 더한 것이라고 보면 되겠습니다.

 

Google Cloud Next 21 "Secure and reliable continuous delivery to GKE" 세션을 기반으로 그린 슬라이드 2

 

Cloud Deploy가 Google Cloud의 관리형 서비스라고 해서 벤더 사에 종속된 서비스는 아닙니다.

 

Google Cloud Platform은 오픈 클라우드를 지향하고 있기 때문에 대부분의 서비스를 OSS 기반으로 제공해 특정 벤더 사의 서비스에 종속되지 않고 사용할 수 있게끔 제공하고 있습니다. 

 

이는 Cloud Deploy의 경우에도 적용되는 점입니다.

 

Skaffold라는 OSS를 기반으로 만들어졌기 때문에 꼭 Google Cloud의 CI/CD툴과 연동할 필요 없이 시중에서 사용할 수 있는 다른 툴과 자유롭게 혼합해서 사용할 수 있습니다.

 

다만 Cloud Deploy를 사용해 배포할 수 있는 환경은 Google Cloud의 GKE(Google Kubernetes Engine)에 한정된다는 한계가 존재합니다.

 

Anthos를 사용한 환경에도 배포할 수 있는지, 그렇다면 On-prem이나 다른 CSP의 쿠버네티스 환경에도 배포할 수 있는지는 업데이트가 나와봐야 알 수 있을 것 같습니다.

 

Google Cloud Platform Cloud Deploy Document에서 발췌

 

물론 Google Cloud 서비스의 일부이기 때문에 GCP 서비스와 연동하면 더 견고하고 고급 기능을 사용하는 파이프라인을 구성할 수 있습니다.

 

예를 들어 GCP의 메세징 서비스인 Pub/sub과 Cloud Deploy를 연동하면 새 릴리즈가 추가될때나 배포를 실시할 때 관리자에게 메일이나 SMS로 알람을 보내는 기능을 추가할 수도 있습니다.

 

 

2. Cloud Deploy를 활용한 CI/CD Pipeline 구성

 

 

이제 실제로 Cloud Deploy를 사용한 Pipeline의 예제를 보겠습니다.

 

앞서 Cloud Deploy는 OSS인 Skaffold를 기반으로 제공되기 때문에 다른 CI/CD 툴과 연동성이 좋다는 장점을 언급했습니다.

 

이 장점을 살려서 대중화된 소스 레포지토리인 Gitlab과 GItlab의 CI/CD 기능인 Gitlab CI/CD를 Cloud Deploy와 함께 사용해서 파이프라인을 구성해보겠습니다. 

 

 

먼저 제가 깃랩 레포지토리에 담은 소스 코드를 보겠습니다.

 

코드는 Golang으로 짜여진 간단한 웹서버를 Kubernetes 위에서 띄울 수 있는 구성입니다.

 

여기서 .gitlab-ci.yml, skaffold.yaml, 그리고 보이진 않지만 cloud-deploy 폴더 내의 clouddeploy.yaml 파일이 CI/CD 파이프라인 구성에 필요한 파일들입니다. 

 

 

.gitlab-ci.yml

 

stages:          # List of stages for jobs, and their order of execution
  - deploy
 
 
deploy-job:      # This job runs in the deploy stage.
  stage: deploy  # It only runs when *both* jobs in the test stage complete successfully.
  script:
    - skaffold config set default-repo gcr.io/lswoo-int-210304
    - skaffold build --interactive=false --file-output=artifacts.json 
    - echo "Application successfully built"
    - gcloud beta deploy releases create test-release-rel-$(date +%y%m%d-%s)   --project=lswoo-int-210304  --region=us-central1 --delivery-pipeline=cloud-deploy-test --build-artifacts=artifacts.json
    - echo "Application successfully released."
 

 

.gitlab-ci.yml은 gitlab의 CI/CD 기능을 사용하기 위한 매니페스트입니다.

 

깃랩은 이렇게 ".gitlab-ci.yml" 이름을 가진 파일을 감지해 레포지토리에 푸시가 들어오면 스크립트를 자동으로 실행합니다.

 

stages는 파이프라인의 단계를 정의합니다. 저는 "deploy"라는 이름의 단계 하나만 사용하겠습니다.

 

deploy-job은 "deploy" 단계에서 실행할 스크립트를 정의합니다. 

 

skaffold config set 명령어로 default 컨테이너 레포지토리를 "gcr.io/lswoo-int-210304"라는 GCP 컨테이너 레지스트리로 지정합니다.

 

skaffold build 명령어로 Go 웹서버 코드를 이미지로 빌드한 뒤 이에 대한 명세를 artifacts.json 파일로 떨어뜨립니다.

 

gcloud beta deploy 명령어로 artifacts.json 파일에 기반해 Cloud Deploy로 새 릴리즈를 등록합니다.

  

중요한 것은 gcloud beta deploy 명령어를 실행하는 것만으로 Cloud Deploy와 연동이 가능하다는 것입니다.

 

이렇게 스크립트를 돌릴 수만 있는 환경이라면 어떤 툴과도 Cloud Deploy를 함께 사용할 수 있습니다.

 

 

skaffold.yaml

 

apiVersion: skaffold/v2beta15
kind: Config
build:
  googleCloudBuild: #Googlecloudbuild를 이용해 build
    projectId: lswoo-int-210304 #projectId를 넣어야 build 가능 
  artifacts: 
  - image: skaffold-buildpacks # build 실행 뒤 나오는 artifact
    buildpacks: # Buildpack을 사용해서 Build(without Dockerfile)
      builder: "gcr.io/buildpacks/builder:v1" #Buildpack이 사용할 Builder로 Google cloud builder 지정
 

 

skaffold.yaml 파일은 앞서 실행한 skaffold build 명령어를 실행하기 위해 필요한 매니페스트 파일입니다.

 

빌드 방식으로 googleCloudBuild를 지정해 GCP의 Cloud build를 이용해서 리모트 빌드를 실행하도록 구성했습니다.

 

buildpack을 사용해서 빌드하기 때문에 Dockerfile 없이 이미지를 빌드할 수 있도록 했습니다.

 

여기까지가 CI/CD 파이프라인 중 CI, 즉 Continuous Integration에 해당하는 잡을 담당하게 됩니다.

 

 

cloud-deploy/clouddeploy.yaml

 

apiVersion: deploy.cloud.google.com/v1beta1
kind: DeliveryPipeline
metadata:
  name: cloud-deploy-test
description: cloud deploy delivery pipeline
serialPipeline:
 stages:
 - targetId: dev
 - targetId: qa
 - targetId: stage
 - targetId: prod
 
---
 
apiVersion: deploy.cloud.google.com/v1beta1
kind: Target
metadata:
  name: dev
description: dev cluster
requireApproval: true
gke:
  cluster: projects/lswoo-int-210304/locations/us-central1-c/clusters/cluster-dev
 
---
 
apiVersion: deploy.cloud.google.com/v1beta1
kind: Target
metadata:
  name: prod
description: prod cluster
requireApproval: true
gke:
  cluster: projects/lswoo-int-210304/locations/us-central1-c/clusters/cluster-prod
 
---
 
apiVersion: deploy.cloud.google.com/v1beta1
kind: Target
metadata:
  name: qa
description: qa cluster
requireApproval: true
gke:
  cluster: projects/lswoo-int-210304/locations/us-central1-c/clusters/cluster-qa
 
---
 
apiVersion: deploy.cloud.google.com/v1beta1
kind: Target
metadata:
  name: stage
description: stage cluster
requireApproval: true
gke:
  cluster: projects/lswoo-int-210304/locations/us-central1-c/clusters/cluster-stage
 

 

이번 포스팅의 주제인 Cloud Deploy를 사용하기 위해 필요한 매니페스트 파일입니다.

 

매니페스트는 크게 2개의 리소스로 나눌 수 있습니다.

 

clouddeploy.yaml은 CD파이프라인의 단계를 구성하는 DeliveryPipeline과 릴리즈를 배포할 GKE 환경인 Target으로 구성할 수 있습니다.

 

DeliveryPipeline은 보통 배포 환경이 dev -> qa -> stage -> prod 순으로 이루어져 있기 때문에 파이프라인도 동일하게 구성했습니다.

 

Target에선 각 단계가 어떤 GKE 클러스터를 의미하는지 지정할 수 있도록 구성합니다.

 

이 매니페스트를 기반으로 gcloud beta deploy apply 명령어를 실행해서 첫 rollout을 배포하면 Cloud Deploy를 사용할 수 있는 준비가 끝납니다. CI/CD 파이프라인을 시작하기 전에 꼭 실행해야 합니다.

 

 

명령어를 실행하면 위와 같이 Web console 화면에서 지정한 단계대로 스테이지가 구성되는 것을 볼 수 있습니다.

 

이 3개의 파일만 준비되면 CI/CD 파이프라인의 구성이 모두 끝납니다. 이제 사용을 해보겠습니다.

 

깃랩에 담은 소스 코드는 아래와 같은 간단한 웹서버입니다.

 

 

 

이제 간단한 변경본을 레포지토리에 푸시해서 CI/CD 파이프라인을 트리거해보겠습니다.

 

CI/CD 파이프라인은 먼저 깃랩 CI/CD가 푸시를 감지해서 자동으로 Gitlab CI/CD를 가동하는 것으로 시작합니다.

 

 

Gitlab CI/CD에서 모든 스크립트를 실행한 다음에는 Cloud Deploy 웹 콘솔에서 다음과 같이 "1 pending"이라는 문구가 노란불로 들어온 것을 볼 수 있습니다.

 

이는 파이프라인에 새 릴리즈가 등록되었으니 검토 후 환경에 적용하라는 뜻입니다.

 

아래 "Review" 버튼을 클릭하면 등록된 릴리즈를 자세히 볼 수 있습니다. 

 

 

리뷰 페이지에서 릴리즈 정보와 함께 배포를 승인한다는 APPROVE 버튼을 볼 수 있습니다.

 

APPROVE 버튼을 클릭하면 Dev환경에 릴리즈가 배포됩니다.

 

GCP의 IAM 기능을 사용하면 릴리즈 승인 권한을 필요한 인원에게만 부여할 수 있습니다.

 

 

MANIFES DIFF 탭에선 기존과 새 릴리즈의 쿠버네티스 구성요소 변경점을 확인할 수 있습니다.

 

이번 릴리즈는 어플리케이션 단의 코드 변경만 있었기 때문에 Pull하는 이미지만 달라지는 것을 확인할 수 있습니다.

 

 

APPROVE 버튼을 누르면 파이프라인 화면에서 dev 환경에 배포가 진행되고 있음을 확인할 수 있습니다.

 

 

배포가 완료된 후 dev 환경의 서비스에 접속해보면 아래와 같이 변경된 릴리즈가 잘 배포되었음을 확인할 수 있습니다.

 

 

이렇게 배포된 환경이 이상없음을 확인하면 Promote 작업을 이용해 다음 qa, stage, 그리고 마지막 prod 환경 순으로 릴리즈 승계가 가능합니다.

 

 

3. 결론

 

이번 포스팅에서 소개한 CI/CD PIpeline의 구성도는 다음과 같습니다.

 

 

 

이 파이프라인을 사용해서 개발자는 코드에 변경점을 푸시하고, 클러스터 운영자는 배포를 승인하는 작업만으로 모든 CI/CD 과정을 자동화할 수 있었습니다. 

 

이제 Cloud Deploy의 등장으로 Google Cloud Platform는 Artifact Registry, Cloud Build와 함께 온전한 CI/CD 서비스를 제공할 수 있게 되었습니다.

 

대중적으로 사용되던 Skaffold를 기반으로 만들어졌기 때문에 사용법을 따로 배울 필요 없이 곧바로 파이프라인을 구성할 수 있다는 장점도 있었습니다. 

 

이 포스팅을 보시는 분들이 Cloud Deploy를 사용한 CI/CD 파이프라인 구성에 도움이 되었기를 바랍니다.