Cloud Build를 사용하여 Git 저장소에서 워크플로 배포

Cloud Build 트리거를 사용하여 Git 저장소에서 자동으로 빌드를 시작하고 워크플로를 배포할 수 있습니다. 소스 저장소의 변경사항에 따라 워크플로를 배포하도록 트리거를 구성하거나 변경사항이 특정 기준과 일치할 때만 워크플로를 배포할 수 있습니다.

이 접근 방식은 배포 수명 주기를 관리하는 데 유용합니다. 예를 들어 스테이징 환경의 워크플로에 변경사항을 배포하고 해당 환경에서 테스트를 실행한 후 이러한 변경사항을 프로덕션 환경에 점진적으로 출시할 수 있습니다.

시작하기 전에

이 안내에서는 트리거를 만들 수 있도록 Google Cloud 프로젝트에 Cloud Build 편집자 역할(roles/cloudbuild.builds.editor)이 있다고 가정합니다. 또한 GitHub 또는 Bitbucket과 같은 소스 저장소에 워크플로가 필요합니다.

콘솔

Cloud Build 및 Workflows API를 사용 설정합니다.

API 사용 설정
Cloud Build 서비스 계정에 Workflows 관리자 역할(roles/workflows.admin)을 부여합니다.
1. Google Cloud 콘솔에서 IAM 페이지로 이동합니다.
  
  IAM으로 이동
2. 프로젝트를 선택합니다.
3. Cloud Build 서비스 계정(PROJECT_NUMBER@cloudbuild.gserviceaccount.com) 행에서 주 구성원 수정을 클릭합니다.
4. 다른 역할 추가를 클릭합니다.
5. 역할 목록에서 Workflows 관리자 역할을 선택합니다.
6. 저장을 클릭합니다.
Compute Engine 기본 서비스 계정에 대한 서비스 계정 사용자 역할(roles/iam.serviceAccountUser)을 Cloud Build 서비스 계정에 부여합니다. Compute Engine API를 사용 설정한 경우 Compute Engine 기본 서비스 계정은 PROJECT_NUMBER-compute@developer.gserviceaccount.com입니다.

주의: 서비스 계정 사용자 역할을 할당하면 사용자에게 기본 서비스 계정과 연결된 역할이 간접적으로 부여됩니다. 예를 들어 기본 서비스 계정에 편집자 역할이 있으면 사용자는 편집자 '역할을 수행'할 수 있습니다. 이러한 역할 할당의 영향을 최소화하려면 최소 권한의 원칙에 따라 기본 서비스 계정을 구성하는 것이 좋습니다. 자세한 내용은 기본 서비스 계정에 대한 자동 역할 부여 중지를 참조하세요.
1. Google Cloud 콘솔에서 서비스 계정 페이지로 이동합니다.
  
  서비스 계정으로 이동
2. 프로젝트를 선택합니다.
3. Compute Engine 기본 서비스 계정의 이메일 주소(PROJECT_NUMBER-compute@developer.gserviceaccount.com)를 클릭합니다.
4. 권한 탭을 클릭합니다.
5. 액세스 권한 부여 버튼을 클릭합니다.
6. 새 주 구성원을 추가하려면 서비스 계정의 이메일 주소(SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com)를 입력합니다.
7. 역할 선택 목록에서 서비스 계정 > 서비스 계정 사용자 역할을 선택합니다.
8. 저장을 클릭합니다.

gcloud

Cloud Build 및 Workflows API를 사용 설정합니다.

gcloud services enable cloudbuild.googleapis.com \
  workflows.googleapis.com

Cloud Build 서비스 계정에 Workflows 관리자 역할(roles/workflows.admin)을 부여합니다.

PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format='value(projectNumber)')
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
  --role=roles/workflows.admin

PROJECT_ID를 Google Cloud 프로젝트의 ID로 바꿉니다.

Compute Engine 기본 서비스 계정에 대한 서비스 계정 사용자 역할(roles/iam.serviceAccountUser)을 Cloud Build 서비스 계정에 부여합니다. Compute Engine API를 사용 설정한 경우 Compute Engine 기본 서비스 계정은 PROJECT_NUMBER-compute@developer.gserviceaccount.com입니다.

주의: 서비스 계정 사용자 역할을 할당하면 사용자에게 기본 서비스 계정과 연결된 역할이 간접적으로 부여됩니다. 예를 들어 기본 서비스 계정에 편집자 역할이 있으면 사용자는 편집자 '역할을 수행'할 수 있습니다. 이러한 역할 할당의 영향을 최소화하려면 최소 권한의 원칙에 따라 기본 서비스 계정을 구성하는 것이 좋습니다. 자세한 내용은 기본 서비스 계정에 대한 자동 역할 부여 중지를 참조하세요.
```
gcloud iam service-accounts add-iam-policy-binding \
  $PROJECT_NUMBER-compute@developer.gserviceaccount.com \
  --member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
  --role=roles/iam.serviceAccountUser
```

소스 저장소에 연결

Cloud Build가 저장소에서 발생한 이벤트에 대한 응답으로 빌드를 자동화할 수 있도록 Cloud Build를 소스 저장소에 연결해야 합니다.

GitHub 또는 Bitbucket에 연결하려면 다음 단계별 안내를 완료하세요.

Google Cloud 콘솔에서 Cloud Build 트리거 페이지로 이동합니다.

트리거로 이동
필요한 경우 프로젝트를 선택하고 열기를 클릭합니다.
리전 목록에서 트리거를 만들 리전을 선택합니다.

참고: global을 리전으로 선택하면 기본 풀이 빌드를 실행하는 데 사용됩니다. 그렇지 않으면 트리거 리전의 비공개 풀이 사용됩니다. 빌드 구성 파일에 또는 빌드 인수를 통해 비공개 풀을 지정해야 합니다.
저장소 연결을 클릭합니다.
소스 코드를 저장한 소스 저장소를 선택합니다.

예를 들면 GitHub(Cloud Build GitHub 앱)입니다.
계속을 클릭합니다.
사용자 이름과 비밀번호를 사용하여 소스 저장소에 인증합니다.

GitHub에 로그인하는 경우 GitHub 계정에 액세스하여 계속 진행하려면 Google Cloud Build GitHub 앱을 승인하라는 메시지가 표시됩니다.
사용 가능한 저장소 목록에서 원하는 저장소를 선택한 후 확인을 클릭합니다.

GitHub 및 Bitbucket과 같은 외부 저장소의 경우 작업 중인 Google Cloud 프로젝트에 대한 소유자 수준 권한이 있어야 합니다.
면책 조항을 읽고 옆에 있는 체크박스를 선택하여 약관에 동의합니다.
연결을 클릭합니다.
저장소의 소스 코드를 자동으로 빌드하는 빌드 트리거를 계속 만들려면 트리거 만들기를 클릭합니다. 그렇지 않은 경우 완료를 클릭합니다.

Cloud Build 구성 파일 만들기

빌드 구성 파일은 빌드 트리거를 사용하여 빌드를 시작할 때 필요한 필드를 정의합니다. 프로젝트 루트 디렉터리에 구성 파일을 만들고 YAML 또는 JSON을 사용하여 작성합니다.

예를 들어 다음 구성 파일은 테스트 워크플로를 배포 및 실행한 후 스크립트를 사용하여 출력을 확인합니다. 테스트를 통과하면 워크플로가 배포됩니다.

steps:
# Deploy the test workflow with the commit sha
- id: 'deploy-test-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  args: ['workflows', 'deploy', '$_WORKFLOW_NAME-$BRANCH_NAME-$SHORT_SHA', '--source', 'gitops/workflow.yaml']

# Run the test workflow and capture the output
- id: 'run-test-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args: ['-c', 'gcloud workflows run $_WORKFLOW_NAME-$BRANCH_NAME-$SHORT_SHA > /workspace/testoutput.log']

# Delete the test workflow
- id: 'delete-test-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  args: ['workflows', 'delete', '$_WORKFLOW_NAME-$BRANCH_NAME-$SHORT_SHA', '--quiet']

# Check the test output
- id: 'check-test-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args: ['gitops/test-$BRANCH_NAME.sh']

# Deploy the workflow
- id: 'deploy-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  args: ['workflows', 'deploy', '$_WORKFLOW_NAME-$BRANCH_NAME', '--source', 'gitops/workflow.yaml']

$BRANCH_NAME 및 $SHORT_SHA 대체 변수는 빌드가 Git 저장소에서 트리거될 때 Cloud Build에 의해 채워집니다. 각각 브랜치 이름과 빌드와 연결된 커밋 ID의 처음 7자를 나타냅니다.

$_WORKFLOW_NAME 대체 변수를 사용하면 다른 변수 값으로 구성 파일을 다시 사용할 수 있습니다. 빌드 트리거를 만들 때 해당 값을 지정할 수 있습니다.

자세한 내용은 빌드 구성 파일 만들기를 참조하세요.

빌드 트리거 만들기

Cloud Build 트리거를 만들면 워크플로 배포를 자동화할 수 있습니다.

이전 섹션의 구성 파일에 대한 빌드 트리거를 만들려면 다음 안내를 따르세요.

Google Cloud 콘솔에서 Cloud Build 트리거 페이지로 이동합니다.

트리거로 이동
트리거 만들기를 클릭합니다.
이름 필드에 트리거 이름을 입력합니다.
이벤트에서 트리거를 호출할 이벤트를 선택합니다.

예를 들면 브랜치로 푸시입니다.
소스에서 저장소를 선택하고 트리거를 시작할 브랜치 또는 태그 이름을 선택합니다. 정규 표현식을 사용하여 브랜치 또는 태그와 일치하는 항목을 지정할 수 있습니다.

예를 들면 GoogleCloudPlatform/workflows-demos(저장소) 및 ^main$|^staging$(main 및 staging 브랜치와 일치)입니다.
포함된 파일 및 무시된 파일 필터 표시 섹션을 펼쳐 변경할 때 빌드가 호출되도록 워크플로를 포함된 파일로 지정합니다.

예: gitops/workflow.yaml
구성에서 Cloud Build 구성 파일(YAML 또는 JSON)을 유형으로 선택하고 저장소를 위치로 선택합니다.
Cloud Build 구성 파일 위치 필드에서 파일 위치를 지정합니다.

예: gitops/cloudbuild.yaml
필요한 경우 대체 변수를 추가하려면 변수 추가를 클릭하고 키와 값의 조합을 지정합니다.

예를 들면 _WORKFLOW_NAME(변수) 및 workflows-gitops(값)입니다.
빌드 트리거를 저장하려면 만들기를 클릭합니다.

변경사항이 Git 저장소의 지정된 브랜치에 있는 워크플로로 푸시되면 Cloud Build가 자동으로 트리거되어 워크플로가 배포됩니다.

자세한 내용은 빌드 트리거 만들기 및 관리를 참조하세요.

빌드 트리거 테스트

이전 섹션의 빌드 트리거와 구성 파일을 테스트할 수 있습니다.

Git 저장소의 staging 브랜치에서 workflow.yaml을 수정하고 Hello World를 Bye World로 변경합니다.

main:
  steps:
    - init:
        assign:
          - message: "Hello World"
    - returnResult:
        return: ${message}

변경사항을 커밋하고 staging 브랜치로 푸시합니다.
```
git add workflow.yaml
git commit -m "Update workflow.yaml in staging"
git push
```
Cloud Build 트리거가 실행되어 빌드를 시작합니다.
빌드가 성공했는지 확인하려면 Google Cloud 콘솔에서 빌드 기록 페이지로 이동합니다.

빌드 기록으로 이동

빌드가 완료되면 Cloud Build에서 빌드와 개별 빌드 단계의 전반적인 상태를 제공합니다. 자세한 내용은 빌드 결과 보기를 참조하세요.
스테이징 워크플로가 배포되었는지 확인하려면 Google Cloud 콘솔에서 Workflows 페이지로 이동합니다.

Workflows로 이동

workflows-gitops-staging이라는 워크플로가 표시되어야 합니다.

스테이징 워크플로를 프로덕션에 배포하려면 staging 브랜치를 main 브랜치에 병합합니다.

git checkout main
git merge staging
git push

워크플로 출력에서 test-main.sh가 Hello World일 것으로 예상되므로 빌드가 실패할 것입니다.

RESULT_EXPECTED="result: '\"Hello World\"'"
RESULT_ACTUAL=$(grep "result: " $FILE)
if [[ $RESULT_EXPECTED == $RESULT_ACTUAL ]]; then
  echo "Result test passed"
else
  echo "Result test failed. Expected: $RESULT_EXPECTED Actual: $RESULT_ACTUAL"; exit 1;
fi

프로덕션 워크플로를 성공적으로 배포하려면 staging 브랜치에서 workflow.yaml을 다시 수정하고 문자열을 다시 Hello World로 변경합니다.
변경사항을 커밋하여 staging 브랜치에 푸시한 후 staging 브랜치를 main 브랜치에 병합합니다.
프로덕션 워크플로가 배포되었는지 확인하려면 Google Cloud 콘솔에서 Workflows 페이지로 이동합니다.

Workflows로 이동

workflows-gitops-main이라는 워크플로가 표시되어야 합니다.

다음 단계

Cloud Build 자세히 알아보기
빌드 오류 문제 해결 방법 알아보기
Workflows 문제 해결 방법 알아보기