Cloud Build로 자동화된 서버리스 배포 파이프라인 빌드

클라우드에 배포할 준비가 된 애플리케이션이 있습니다. 옵션을 조사한 후 Cloud Build와 함께 Cloud Run을 사용하여 컨테이너화된 애플리케이션 코드를 빌드하고 Artifact Registry 저장소에 푸시합니다. 세 단계로 Dockerfile 및 Cloud Build 구성을 사용하여 컨테이너를 빌드하고 Artifact Registry에 푸시하고 Cloud Run에 배포합니다.

steps:
# Build the container image
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'us-central1-docker.pkg.dev/my-project/my-app-repo/shiny-new-app', '.']

# Push the container image to Artifact Registry
- name: 'gcr.io/cloud-builders/docker'
  args: ['push', 'us-central1-docker.pkg.dev/my-project/my-app-repo/shiny-new-app']

# Deploy container image to Cloud Run
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
  entrypoint: gcloud
  args: ['run', 'deploy', 'my-serverless-app', '--image', 'us-central1-docker.pkg.dev/my-project/my-app-repo/shiny-new-app', '--region', 'us-central1']

images:
- us-central1-docker.pkg.dev/my-project/my-app-repo/shiny-new-app

위의 예는 빌드, 푸시 및 배포 단계를 하나의 Cloud Build 작업으로 결합합니다. 이 블로그에서는 이것이 일련의 수동 배포 단계로 어떻게 보일 수 있는지, 그리고 이를 보다 복잡한 솔루션의 출발점으로 사용할 수 있는 자동 서버리스 배포 파이프라인으로 개발할 수 있는 방법을 보여줍니다. Cloud Build , Artifact Registry , Pub/Sub 및 Cloud Run 을 사용할 것입니다.

컨테이너화된 애플리케이션을 Cloud Run에 배포하는 수동 단계를 살펴보는 것으로 시작하겠습니다.

1. 먼저 리포지토리의 기본 브랜치에 대한 애플리케이션 코드를 변경합니다.
2. 애플리케이션 변경이 병합되면 Cloud Build를 사용하여 새 컨테이너를 빌드합니다.
3. 성공적인 빌드 후 Cloud Build는 새로 빌드된 컨테이너를 Artifact Registry로 푸시합니다.
4. 새 빌드를 가리키는 새 구성으로 Cloud Run을 업데이트합니다.
5. Cloud Run은 서비스의 새 버전을 배포합니다. 이제 코드 변경 사항이 배포되었습니다.

물론 애플리케이션 코드가 변경될 때마다 이러한 단계를 거쳐야 합니다. 이는 실용적이지 않으며 코드를 지속적으로 업데이트하는 팀에게 물류상의 악몽이 될 수 있습니다. 여러 환경에 대한 스테이징 변경 또는 체계적인 테스트 또는 증분 롤아웃 통합의 추가 복잡성은 말할 것도 없습니다. 빌드와 배포의 두 부분으로 살펴봄으로써 멋진 ​​작은 파이프라인을 자동화하는 방법을 살펴보겠습니다.

파이프라인의 빌드 단계를 자동화하려면 저장소의 애플리케이션 코드에 변경 사항이 커밋될 때 Cloud Build가 빌드하고 푸시해야 합니다. 이렇게 하려면 다음이 필요합니다.

GitHub 저장소를 프로젝트에 연결하면 Cloud Build가 저장소 이벤트를 사용하여 Cloud Build 트리거를 시작할 수 있습니다. 특정 브랜치로 푸시, 새 태그 푸시 및 풀 요청 생성을 포함하여 일반적인 리포지토리 이벤트가 지원됩니다.

빌드 구성 파일을 사용하여 Cloud Build 작업을 구성할 수 있습니다. 이 YAML 파일은 Cloud Build에 작업 수준 지침을 제공합니다. 이 파일은 애플리케이션의 Dockerfile과 함께 또는 리포지토리의 별도 디렉터리에 있을 수 있습니다. 자동 빌드의 경우 구성 파일은 컨테이너 이미지를 빌드하고 Artifact Registry에 푸시하도록 Cloud Build에 지시합니다.

Cloud Build 트리거는 기본 브랜치에 변경사항이 푸시될 때마다 호출될 수 있습니다. 해당 구성에는 GitHub 저장소가 Google Cloud 프로젝트에 연결되어 있어야 하고, 사용하려는 브랜치의 이름과 저장소에 있는 Cloud Build 구성 파일의 경로가 필요합니다. 포함하거나 무시할 파일 및 디렉터리를 지정하여 Cloud Build 트리거의 호출 범위를 더 좁힐 수 있으므로 특정 파일이 변경된 경우에만 새 빌드를 만들 수 있습니다.

steps:
  # Docker Build 
  - name: 'gcr.io/cloud-builders/docker'
    args: 
      - 'build'
      - '-t'
      - '${_REGION}-docker.pkg.dev/${PROJECT_ID}/content-api/content-api:${_IMAGE_TAG}'

# Default to us-central1
substitutions:
  _REGION: us-central1
  _IMAGE_TAG: $SHORT_SHA

# Store in Artifact Registry
images:
  - '${_REGION}-docker.pkg.dev/${PROJECT_ID}/content-api/content-api:${_IMAGE_TAG}'

밑줄(_) 접두사가 있는 변수를 사용하면 Cloud Build 트리거를 구성할 때 대체 항목을 제공할 수 있습니다. 위의 예에서 _REGION을 재정의하여 컨테이너 레지스트리를 새 위치로 이동하더라도 이 구성을 변경하지 않고 사용할 수 있습니다. $PROJECT_ID와 같이 밑줄이 없는 대체 항목은 기본 제공되며 Cloud Build에서 값을 제공합니다. 문서에서 기본 제공 대체 목록을 볼 수 있습니다 . 이것은 유사한 기능을 가진 여러 트리거에 대해 단일 Cloud Build 구성을 사용하는 데 유용합니다.

수동 파이프라인을 사용하면 새 빌드가 푸시되는 시점을 알 수 있으므로 Cloud Run 서비스를 직접 충실하게 업데이트할 수 있습니다. 이것이 자동으로 작동하려면 새 빌드를 사용할 수 있음을 Cloud Run에 알릴 수 있는 방법이 있어야 합니다. Pub/Sub 및 다른 Cloud Build 트리거의 약간의 도움으로 이 작업을 수행할 수 있습니다. 좀 더 자세히 살펴보겠습니다.

Google Cloud 프로젝트에 ‘gcr’이라는 Pub/Sub 주제가 포함된 경우 Artifact Registry는 저장소의 변경사항에 대한 메시지를 게시합니다 . 이미지 빌드가 푸시, 태그 지정 또는 삭제될 때마다 메시지가 게시됩니다. 이러한 메시지는 애플리케이션에 대한 해당 Pub/Sub 구독 또는 우리의 경우 Cloud Build 트리거에 의해 전달됩니다.

두 번째 Cloud Build 트리거는 Cloud Run 서비스의 새 버전을 배포하도록 구성됩니다. 저장소 이벤트 외에도 Cloud Build 트리거는 Pub/Sub 이벤트를 지원합니다 . gcr Pub/Sub 주제를 트리거 이벤트로 선택하여 해당 구독을 생성할 수 있습니다. 그러면 Artifact Registry가 Pub/Sub에 메시지를 게시할 때 Cloud Run 서비스가 자동으로 업데이트됩니다.

단일 Cloud Build 트리거 빌드, 푸시 및 애플리케이션 배포가 가능하지만 빌드와 푸시에서 배포를 분리하면 각 단계가 별도의 Cloud Build 작업에서 실행되고 파이프라인의 각 부분을 더 쉽게 개발할 수 있습니다.

steps:
  # Print the full Pub/Sub message for debugging.
  - name: gcr.io/cloud-builders/gcloud
    entrypoint: /bin/bash
    args:
      - '-c'
      - |
        echo ${_BODY}
  # Cloud Run Deploy
  - name: gcr.io/cloud-builders/gcloud
    args:
      - run
      - deploy
      - ${_SERVICE}
      - --image=${_IMAGE_NAME}
      - --region=${_REGION}
      - --revision-suffix=${_REVISION}
      - --project=${_TARGET_PROJECT}
      - --allow-unauthenticated

다시 한 번 구성 파일은 트리거의 대체 변수 설정을 통해 값이 제공되는 변수를 사용합니다. _BODY, _IMAGE_NAME, _REVISION과 같은 특정 변수의 값은 gcr Pub/Sub 주제에서 수신된 메시지를 사용하여 평가되지만 다른 변수는 하드코딩됩니다.

이 파이프라인의 가치는 단순성에 있는 것이 아니라 별도의 Google Cloud 프로젝트에서 변경사항 준비, 애플리케이션의 각 변경사항에 대한 자동 테스트 통합, Cloud Run 서비스. 이는 추가 Cloud Build 트리거와 Pub/Sub 주제의 조합으로 모두 달성할 수 있습니다. 또는 최근 Cloud Run 지원이 추가되어 Cloud Deploy를 롤백, 승인, 감사 및 전달 측정항목이 포함된 Cloud Run 대상에 배포하는 전달 파이프라인으로 사용할 수 있습니다.