Terraform, Cloud Build, GitOps를 사용하여 인프라를 코드로 관리

이 튜토리얼에서는 널리 사용되는 GitOps 방법론을 사용하여 Terraform 및 Cloud Build로 코드형 인프라를 관리하는 방법을 설명합니다. GitOps는 Weaveworks에 의해 처음 창안된 용어로, Git 저장소를 사용하여 원하는 환경 상태를 저장하는 것이 핵심 개념입니다. Terraform은 코드를 사용하여 클라우드 인프라를 예측 가능하게 만들고, 변경하고, 개선할 수 있는 HashiCorp 도구입니다. 이 튜토리얼에서는 Google Cloud의 지속적 통합 서비스인 Cloud Build를 사용하여 환경에 Terraform 매니페스트를 자동으로 적용합니다.

이 튜토리얼은 인프라를 예측 가능하게 변경할 수 있는 효과적인 전략을 찾고 있는 개발자와 운영자를 대상으로 합니다. 이 도움말에서는 개발자가 Google Cloud, Linux, GitHub에 익숙하다고 가정합니다.

State of DevOps 보고서에는 소프트웨어 제공 성능을 향상시키는 기능이 나와 있습니다. 이 튜토리얼에서는 다음 기능을 설명합니다.

아키텍처

이 튜토리얼에서 Terraform 실행 관리에 GitOps 사례를 어떻게 적용하는지 알아보려면 다음 아키텍처 다이어그램을 살펴보세요. 이 다이어그램에서는 GitHub 분기(dev 및 prod)를 사용하여 실제 환경을 나타냅니다. 이러한 환경은 Virtual Private Cloud(VPC) 네트워크(dev 및 prod)에 의해 Google Cloud 프로젝트로 정의됩니다.

개발 및 프로덕션 환경이 있는 인프라

Terraform 코드를 dev 분기 또는 prod 분기로 푸시하면 프로세스가 시작됩니다. 이 시나리오에서 Cloud Build는 각 환경에서 Terraform 매니페스트를 트리거한 후 적용하여 원하는 상태를 달성합니다. 반면 Terraform 코드를 다른 분기(예: 기능 분기)로 푸시하면 Cloud Build가 실행되어 terraform plan을 실행하지만 환경에는 아무것도 적용되지 않습니다.

개발자나 운영자는보호되지 않는 분기에 인프라 제안을 한 후 pull 요청을 통해 이를 제출하는 것이 좋습니다. 이 튜토리얼의 뒷부분에서 설명하는 Cloud Build GitHub 앱은 빌드 작업을 자동으로 트리거하고 terraform plan 보고서를 이러한 pull 요청에 연결합니다. 이렇게 하면 공동작업자와 잠재적인 변경사항을 논의 및 검토하고 변경사항이 기본 분기에 병합되기 전에 후속 커밋을 추가할 수 있습니다.

문제가 발생하지 않으면 먼저 변경사항을 dev 분기에 병합해야 합니다. 이 병합으로 인해 dev 환경에 대한 인프라 배포가 트리거되므로 이 환경을 테스트할 수 있습니다. 배포한 내용을 테스트하고 확인한 후에는 dev 분기를 prod 분기로 병합하여 프로덕션 환경에 대한 인프라 설치를 트리거해야 합니다.

목표

GitHub 저장소를 설정합니다.
Cloud Storage 버킷에 상태를 저장하도록 Terraform을 구성합니다.
Cloud Build 서비스 계정에 권한을 부여합니다.
Cloud Build를 GitHub 저장소에 연결합니다.
기능 분기에서 환경 구성을 변경합니다.
변경사항을 개발 환경으로 승격합니다.
변경사항을 프로덕션 환경으로 승격합니다.

비용

이 문서에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.

프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요. Google Cloud를 처음 사용하는 사용자는 무료 체험판을 사용할 수 있습니다.

이 문서에 설명된 태스크를 완료했으면 만든 리소스를 삭제하여 청구가 계속되는 것을 방지할 수 있습니다. 자세한 내용은 삭제를 참조하세요.

기본 요건

Google Cloud 계정에 로그인합니다. Google Cloud를 처음 사용하는 경우 계정을 만들고 Google 제품의 실제 성능을 평가해 보세요. 신규 고객에게는 워크로드를 실행, 테스트, 배포하는 데 사용할 수 있는 $300의 무료 크레딧이 제공됩니다.

Google Cloud Console의 프로젝트 선택기 페이지에서 Google Cloud 프로젝트를 선택하거나 만듭니다.

프로젝트 선택기로 이동

Google Cloud 프로젝트에 결제가 사용 설정되어 있는지 확인합니다.

Google Cloud Console의 프로젝트 선택기 페이지에서 Google Cloud 프로젝트를 선택하거나 만듭니다.

프로젝트 선택기로 이동

Google Cloud 프로젝트에 결제가 사용 설정되어 있는지 확인합니다.

Google Cloud 콘솔에서 Cloud Shell을 활성화합니다.

Cloud Shell 활성화

Google Cloud 콘솔 하단에서 Cloud Shell 세션이 시작되고 명령줄 프롬프트가 표시됩니다. Cloud Shell은 Google Cloud CLI가 사전 설치된 셸 환경으로, 현재 프로젝트의 값이 이미 설정되어 있습니다. 세션이 초기화되는 데 몇 초 정도 걸릴 수 있습니다.
Cloud Shell에서 방금 선택한 프로젝트의 ID를 가져옵니다.
```
gcloud config get-value project
```
이 명령어가 프로젝트 ID를 반환하지 않으면 프로젝트를 사용하도록 Cloud Shell을 구성합니다. PROJECT_ID를 프로젝트 ID로 바꿉니다.
```
gcloud config set project PROJECT_ID
```
필요한 API를 사용 설정합니다.
```
gcloud services enable cloudbuild.googleapis.com compute.googleapis.com
```
이 단계를 완료하는 데 몇 분 정도 걸릴 수 있습니다.
Cloud Shell에서 Git을 사용한 적이 없으면 내 이름과 이메일 주소를 사용하여 Git을 구성합니다.
```
git config --global user.email "YOUR_EMAIL_ADDRESS"
git config --global user.name "YOUR_NAME"
```
Git은 이 정보를 사용하여 Cloud Shell에서 만드는 커밋의 작성자를 식별합니다.

GitHub 저장소 설정

이 튜토리얼에서는 단일 Git 저장소를 사용하여 클라우드 인프라를 정의합니다. 서로 다른 환경에 해당하는 각각의 분기를 사용하여 이 인프라를 조정합니다.

dev 분기에는 개발 환경에 적용되는 최신 변경사항이 포함됩니다.
prod 분기에는 프로덕션 환경에 적용되는 최신 변경사항이 포함됩니다.

이 인프라를 사용하면 언제든지 저장소를 참조하여 각 환경에 필요한 구성을 파악하고 먼저 이를 dev 환경에 병합해 새로운 변경사항을 제안할 수 있습니다. 그런 다음 dev 분기를 후속 prod 분기에 병합해 변경사항을 승격합니다.

시작하려면 solutions-terraform-cloudbuild-gitops 저장소를 포크합니다.

GitHub에서 https://github.com/GoogleCloudPlatform/solutions-terraform-cloudbuild-gitops.git으로 이동합니다.
페이지 오른쪽 상단에서 포크를 클릭합니다.

이제 소스 파일이 있는 solutions-terraform-cloudbuild-gitops 저장소의 복사본이 준비되었습니다.

Cloud Shell에서 YOUR_GITHUB_USERNAME을 GitHub 사용자 이름을 바꿔 이 포크된 저장소를 클론합니다.

cd ~
git clone https://github.com/YOUR_GITHUB_USERNAME/solutions-terraform-cloudbuild-gitops.git
cd ~/solutions-terraform-cloudbuild-gitops

이 저장소의 코드는 다음과 같이 구성됩니다.

environments/ 폴더에는 dev 및 prod 같은 환경을 나타내는 하위 폴더가 포함됩니다. 따라서 다양한 성숙도, 개발, 프로덕션 단계에서 워크로드 간에 논리적인 구분이 가능합니다. 이러한 환경을 최대한 유사하게 유지하는 것이 좋지만 각 하위 폴더에는 필요에 따라 고유한 설정을 지정할 수 있는 자체 Terraform 구성이 있습니다.
modules/ 폴더에는 인라인 Terraform 모듈이 있습니다. 이러한 모듈은 관련 리소스의 논리적 그룹을 나타내며 서로 다른 환경에서 코드를 공유하는 데 사용됩니다.
cloudbuild.yaml 파일은 일련의 단계를 바탕으로 태스크를 수행하는 방법 등 Cloud Build에 내릴 명령이 포함된 빌드 구성 파일입니다. 이 파일은 Cloud Build가 코드를 가져오는 분기에 따라 조건부 실행을 지정합니다. 예를 들면 다음과 같습니다.
- dev 및 prod 분기의 경우 다음 단계가 실행됩니다.
  1. terraform init
  2. terraform plan
  3. terraform apply
- 다른 분기의 경우 다음 단계가 실행됩니다.
  1. 모든 environments 하위 폴더에 terraform init
  2. 모든 environments 하위 폴더에 terraform plan

제안된 변경사항이 모든 환경에 적합한지 확인하려면 terraform init 및 terraform plan을 모든 environments 하위 폴더에 대해 실행합니다. pull 요청을 병합하기 전에 요금제를 검토하여 예를 들어 승인되지 않은 항목에 액세스 권한이 부여되지 않도록 할 수 있습니다.

Cloud Storage 버킷에 상태를 저장하도록 Terraform 구성

기본적으로 Terraform은 상태를 terraform.tfstate라는 파일에 로컬로 저장합니다. 이러한 기본 구성으로 인해 여러 사용자가 동시에 Terraform을 실행하고 각 머신이 현재 인프라를 자체적으로 이해할 경우에는 팀의 Terraform 사용이 어려워질 수 있습니다.

이러한 문제를 방지하기 위해 이 섹션에서는 Cloud Storage 버킷을 가리키는 원격 상태를 구성합니다. 원격 상태는 백엔드의 기능으로, 이 튜토리얼에서는 backend.tf 파일에 구성됩니다. 예를 들면 다음과 같습니다.

# Copyright 2019 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.

terraform {
  backend "gcs" {
    bucket = "PROJECT_ID-tfstate"
    prefix = "env/dev"
  }
}

다음 단계에서는 Cloud Storage 버킷을 만들고 새 버킷과 Google Cloud 프로젝트를 가리키도록 일부 파일을 변경합니다.

Cloud Shell에서 Cloud Storage 버킷을 만듭니다.

PROJECT_ID=$(gcloud config get-value project)
gsutil mb gs://${PROJECT_ID}-tfstate

객체 버전 관리를 사용 설정하여 배포 기록을 유지합니다.
```
gsutil versioning set on gs://${PROJECT_ID}-tfstate
```
객체 버전 관리를 사용 설정하면 스토리지 비용이 늘어납니다. 하지만 객체 수명 주기 관리를 구성하여 이전 상태 버전을 삭제하면 이 비용을 줄일 수 있습니다.

terraform.tfvars 파일과 backend.tf 파일 모두에서 PROJECT_ID 자리표시자를 프로젝트 ID로 바꿉니다.

cd ~/solutions-terraform-cloudbuild-gitops
sed -i s/PROJECT_ID/$PROJECT_ID/g environments/*/terraform.tfvars
sed -i s/PROJECT_ID/$PROJECT_ID/g environments/*/backend.tf

OS X/Mac OS에서는 다음과 같이 sed -i 뒤에 따옴표("")를 두 개 추가해야 할 수 있습니다.

cd ~/solutions-terraform-cloudbuild-gitops
sed -i "" s/PROJECT_ID/$PROJECT_ID/g environments/*/terraform.tfvars
sed -i "" s/PROJECT_ID/$PROJECT_ID/g environments/*/backend.tf

모든 파일이 업데이트되었는지 확인합니다.

git status

출력 형식은 다음과 같습니다.

On branch dev
Your branch is up-to-date with 'origin/dev'.
Changes not staged for commit:
 (use "git add <file>..." to update what will be committed)
 (use "git checkout -- <file>..." to discard changes in working directory)
       modified:   environments/dev/backend.tf
       modified:   environments/dev/terraform.tfvars
       modified:   environments/prod/backend.tf
       modified:   environments/prod/terraform.tfvars
no changes added to commit (use "git add" and/or "git commit -a")

변경사항을 커밋하고 푸시합니다.
```
git add --all
git commit -m "Update project IDs and buckets"
git push origin dev
```
GitHub 구성에 따라 인증하여 이전 변경사항을 푸시해야 합니다.

Cloud Build 서비스 계정에 권한 부여

Cloud Build 서비스 계정에서 Google Cloud 리소스를 관리하기 위해 Terraform 스크립트를 실행하려면 프로젝트에 적절한 액세스 권한을 부여해야 합니다. 편의를 위해 이 튜토리얼에서는 프로젝트 편집자 액세스 권한을 부여합니다. 하지만 프로젝트 편집자 역할이 폭넓은 권한을 가진 경우 프로덕션 환경에서는 회사의 IT 보안 권장사항을 따라야 합니다. 일반적으로 최소한의 액세스 권한을 제공하는 것이 좋습니다.

Cloud Shell에서 프로젝트의 Cloud Build 서비스 계정의 이메일을 가져옵니다.

CLOUDBUILD_SA="$(gcloud projects describe $PROJECT_ID \
    --format 'value(projectNumber)')@cloudbuild.gserviceaccount.com"

Cloud Build 서비스 계정에 필요한 액세스 권한을 부여합니다.

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member serviceAccount:$CLOUDBUILD_SA --role roles/editor

Cloud Build를 GitHub 저장소에 직접 연결

이 섹션에서는 Cloud Build GitHub 앱을 설치하는 방법을 설명합니다. 이 앱을 설치하면 GitHub 저장소와 Google Cloud 프로젝트를 연결할 수 있어 새 분기를 만들거나 코드를 GitHub에 푸시할 때마다 Cloud Build가 Terraform 매니페스트를 자동으로 적용할 수 있습니다.

다음 단계에서는 solutions-terraform-cloudbuild-gitops 저장소에 앱을 설치하는 방법만 안내합니다. 하지만 개발자는 전체 또는 일부 저장소에 앱을 설치할 수 있습니다.

Cloud Build 앱의 GitHub Marketplace 페이지로 이동합니다.

Cloud Build 앱 페이지 열기
- GitHub에서 앱을 처음 구성할 때는 페이지 하단에서 Google Cloud Build로 설정을 클릭한 후 이 앱에 GitHub 계정 액세스 권한 부여를 클릭합니다.
- GitHub에서 앱을 처음으로 구성하는 것이 아니라면 액세스 구성을 클릭합니다. 개인 계정의 애플리케이션 페이지가 열립니다.
Cloud Build 행에서 구성을 클릭합니다.
저장소만 선택을 선택한 후 solutions-terraform-cloudbuild-gitops를 선택하여 저장소에 연결합니다.
저장 또는 설치를 클릭합니다. 버튼 라벨은 워크플로에 따라 다릅니다. 설치를 계속할 수 있도록 Google Cloud로 리디렉션됩니다.
Google Cloud 계정에 로그인합니다. 요청이 있을 경우 GitHub와 Cloud Build 통합을 승인합니다.
Cloud Build 페이지에서 프로젝트를 선택합니다. 마법사가 표시됩니다.
저장소 선택 섹션에서 GitHub 계정과 solutions-terraform-cloudbuild-gitops 저장소를 선택합니다.
이용약관에 동의하면 체크박스를 선택하고 연결을 클릭합니다.
트리거 만들기 섹션에서 트리거 만들기를 클릭합니다.
1. 트리거 이름을 추가합니다(예: push-to-branch). 나중에 필요하므로 이 트리거 이름을 기록해 두세요.
2. 이벤트 섹션에서 분기로 푸시를 선택합니다.
3. 소스 섹션의 분기 필드에서 .*를 선택합니다.
4. 만들기를 클릭합니다.

이제 Cloud Build GitHub 앱이 구성되었으며 GitHub 저장소가 Google Cloud 프로젝트에 연결되었습니다. 이제부터 GitHub 저장소를 변경하면 Cloud Build 실행이 트리거되고 GitHub 검사를 사용하여 GitHub에 결과가 다시 보고됩니다.

새 기능 분기에서 환경 구성 변경

지금까지 대부분의 환경을 구성했습니다. 이제 개발 환경에서 몇 가지 코드를 변경해야 합니다.

GitHub에서 포크된 저장소의 기본 페이지로 이동합니다.

https://github.com/YOUR_GITHUB_USERNAME/solutions-terraform-cloudbuild-gitops

dev 분기에 있는지 확인합니다.
수정할 파일을 열려면 modules/firewall/main.tf 파일로 이동하고 연필 아이콘을 클릭합니다.
30행의 target_tags 필드에서 "http-server2" 오타를 수정합니다.

값은 "http-server"여야 합니다.
페이지 하단에 'Fixing http firewall target'과 같은 커밋 메시지를 추가하고 이 커밋에 사용할 새 분기를 만들고 pull 요청을 시작하기를 선택합니다.
변경사항 제안을 클릭합니다.
다음 페이지에서 pull 요청 만들기를 클릭하여 변경사항과 함께 새 pull 요청을 엽니다.

pull 요청이 열리면 Cloud Build 작업이 자동으로 시작됩니다.
모든 검사 표시를 클릭하고 체크 표시가 녹색이 될 때까지 기다립니다.
Google Cloud Build에 대한 자세한 내용보기 링크에서 terraform plan의 출력을 비롯해 자세한 내용을 보려면 세부정보를 클릭합니다.

pull 요청을 아직 병합하지 마세요.

이 Cloud Build 작업은 cloudbuild.yaml 파일에서 정의된 파이프라인을 실행했습니다. 앞의 설명처럼 이 파이프라인은 가져올 분기에 따라 서로 다르게 동작합니다. 빌드는 $BRANCH_NAME 변수가 모든 환경 폴더와 일치하는지 검사합니다. 일치하면 Cloud Build는 해당 환경에 대해 terraform plan을 실행합니다. 일치하지 않으면 Cloud Build에서 모든 환경에 terraform plan을 실행하여 제안된 변경사항이 모든 환경에 적합한지 확인합니다. 이러한 요금제 중 하나라도 실행에 실패하면 빌드가 실패합니다.

- id: 'tf plan'
  name: 'hashicorp/terraform:1.0.0'
  entrypoint: 'sh'
  args:
  - '-c'
  - |
      if [ -d "environments/$BRANCH_NAME/" ]; then
        cd environments/$BRANCH_NAME
        terraform plan
      else
        for dir in environments/*/
        do
          cd ${dir}
          env=${dir%*/}
          env=${env#*/}
          echo ""
          echo "*************** TERRAFOM PLAN ******************"
          echo "******* At environment: ${env} ********"
          echo "*************************************************"
          terraform plan || exit 1
          cd ../../
        done
      fi

마찬가지로 terraform apply 명령어는 환경 분기에 대해 실행되지만 다른 경우에는 완전히 무시됩니다. 이 섹션에서는 새 분기에 대한 코드 변경사항을 제출했으므로 인프라 배포가 Google Cloud 프로젝트에 적용되지 않았습니다.

- id: 'tf apply'
  name: 'hashicorp/terraform:1.0.0'
  entrypoint: 'sh'
  args:
  - '-c'
  - |
      if [ -d "environments/$BRANCH_NAME/" ]; then
        cd environments/$BRANCH_NAME
        terraform apply -auto-approve
      else
        echo "***************************** SKIPPING APPLYING *******************************"
        echo "Branch '$BRANCH_NAME' does not represent an official environment."
        echo "*******************************************************************************"
      fi

분기 병합 전에 Cloud Build 실행 성공 적용

각각의 Cloud Build 실행이 성공할 때만 병합을 적용하려면 다음 단계를 진행합니다.

GitHub에서 포크된 저장소의 기본 페이지로 이동합니다.

https://github.com/YOUR_GITHUB_USERNAME/solutions-terraform-cloudbuild-gitops

저장소 이름 아래에서 설정을 클릭합니다.
왼쪽 메뉴에서 분기를 클릭합니다.
분기 보호 규칙에서 규칙 추가를 클릭합니다.
분기 이름 패턴에 dev를 입력합니다.
일치하는 분기 보호 섹션에서 병합 전에 상태 검사를 통과해야 함을 선택합니다.
이전에 만든 Cloud Build 트리거 이름을 검색합니다.
만들기를 클릭합니다.
3~7단계를 반복하여 분기 이름 패턴을 prod로 설정합니다.

이 구성은 dev 분기와 prod 분기를 모두 보호하는 데 중요합니다. 즉, 커밋이 먼저 다른 분기로 푸시되어야 하며 그런 다음에만 보호되는 분기에 병합할 수 있습니다. 이 튜토리얼의 보호에서는 Cloud Build 실행이 성공해야만 병합이 허용됩니다.

개발 환경으로 변경사항 승격

병합 대기 중인 pull 요청이 있습니다. 이제 dev 환경에 원하는 상태를 적용할 차례입니다.

GitHub에서 포크된 저장소의 기본 페이지로 이동합니다.

https://github.com/YOUR_GITHUB_USERNAME/solutions-terraform-cloudbuild-gitops

저장소 이름 아래에서 pull 요청을 클릭합니다.
방금 만든 pull 요청을 클릭합니다.
pull 요청 병합을 클릭한 후 병합 확인을 클릭합니다.
새 Cloud Build가 트리거되었는지 확인합니다.

Cloud Build 페이지로 이동

빌드를 열고 로그를 확인합니다.

빌드가 완료되면 다음과 같은 내용이 표시됩니다.

Step #3 - "tf apply": external_ip = EXTERNAL_IP_VALUE
Step #3 - "tf apply": firewall_rule = dev-allow-http
Step #3 - "tf apply": instance_name = dev-apache2-instance
Step #3 - "tf apply": network = dev
Step #3 - "tf apply": subnet = dev-subnet-01

EXTERNAL_IP_VALUE를 복사하고 웹브라우저에서 주소를 엽니다.
```
http://EXTERNAL_IP_VALUE
```
이 프로비저닝에서는 VM을 부팅하고 방화벽 규칙을 전파하는 데 몇 초 정도 걸릴 수 있습니다. 최종적으로 웹브라우저에 Environment: dev가 표시됩니다.

Cloud Storage 버킷의 Terraform 상태 파일로 이동합니다.

https://storage.cloud.google.com/PROJECT_ID-tfstate/env/dev/default.tfstate

프로덕션 환경으로 변경사항 승격

이제 개발 환경을 완벽하게 테스트했으므로 인프라 코드를 프로덕션으로 승격할 수 있습니다.

GitHub에서 포크된 저장소의 기본 페이지로 이동합니다.

https://github.com/YOUR_GITHUB_USERNAME/solutions-terraform-cloudbuild-gitops

저장소 이름 아래에서 pull 요청을 클릭합니다.
새 pull 요청을 클릭합니다.
기본 저장소에 방금 포크한 저장소를 선택합니다.
기본의 경우 자체 기본 저장소에서 prod를 선택합니다. 비교에는 dev를 선택합니다.
pull 요청 만들기를 클릭합니다.
제목에 Promoting networking changes와 같은 제목을 입력한 후 pull 요청 만들기를 클릭합니다.
Cloud Build의 terraform plan 세부정보를 비롯해 제안된 변경사항을 검토하고 pull 요청 병합을 클릭합니다.
병합 확인을 클릭합니다.
Google Cloud 콘솔에서 빌드 기록 페이지를 열어 프로덕션 환경에 적용되는 변경사항을 확인합니다.

Cloud Build 페이지로 이동

빌드가 완료될 때까지 기다린 다음 로그를 확인합니다.

로그 끝에 다음과 같은 내용이 표시됩니다.

Step #3 - "tf apply": external_ip = EXTERNAL_IP_VALUE
Step #3 - "tf apply": firewall_rule = prod-allow-http
Step #3 - "tf apply": instance_name = prod-apache2-instance
Step #3 - "tf apply": network = prod
Step #3 - "tf apply": subnet = prod-subnet-01

EXTERNAL_IP_VALUE를 복사하고 웹브라우저에서 주소를 엽니다.
```
http://EXTERNAL_IP_VALUE
```
이 프로비저닝에서는 VM을 부팅하고 방화벽 규칙을 전파하는 데 몇 초 정도 걸릴 수 있습니다. 최종적으로 웹브라우저에 Environment: prod가 표시됩니다.

Cloud Storage 버킷의 Terraform 상태 파일로 이동합니다.

https://storage.cloud.google.com/PROJECT_ID-tfstate/env/prod/default.tfstate

Cloud Build에서 서버리스 코드형 인프라 파이프라인을 성공적으로 구성했습니다. 앞으로 다음을 해볼 수 있습니다.

별도의 사용 사례에 배포를 추가합니다.
필요에 맞게 추가 환경을 만듭니다.
환경별로 VPC를 사용하는 대신 환경별로 프로젝트를 사용합니다.

삭제

이 튜토리얼을 마쳤으면 나중에 요금이 청구되지 않도록 Google Cloud에서 만든 리소스를 삭제합니다.

프로젝트 삭제

주의: 프로젝트를 삭제하면 다음과 같은 효과가 발생합니다.

프로젝트의 모든 항목이 삭제됩니다. 이 문서의 태스크에 기존 프로젝트를 사용한 경우 프로젝트를 삭제하면 프로젝트에서 수행한 다른 작업도 삭제됩니다.
커스텀 프로젝트 ID가 손실됩니다. 이 프로젝트를 만들 때 앞으로 사용할 커스텀 프로젝트 ID를 만들었을 수 있습니다. appspot.com URL과 같이 프로젝트 ID를 사용하는 URL을 보존하려면 전체 프로젝트를 삭제하는 대신 프로젝트 내에서 선택한 리소스만 삭제합니다.

여러 아키텍처, 튜토리얼, 빠른 시작을 살펴보려는 경우 프로젝트를 재사용하면 프로젝트 할당량 한도 초과를 방지할 수 있습니다.

Google Cloud 콘솔에서 리소스 관리 페이지로 이동합니다.
리소스 관리로 이동
프로젝트 목록에서 삭제할 프로젝트를 선택하고 삭제를 클릭합니다.
대화상자에서 프로젝트 ID를 입력한 후 종료를 클릭하여 프로젝트를 삭제합니다.

GitHub 저장소 삭제

GitHub 저장소에서 새 pull 요청을 차단하지 않으려면 분기 보호 규칙을 삭제하면 됩니다.

GitHub에서 포크된 저장소의 기본 페이지로 이동합니다.
저장소 이름 아래에서 설정을 클릭합니다.
왼쪽 메뉴에서 분기를 클릭합니다.
분기 보호 규칙 섹션에서 dev 및 prod 행의 삭제 버튼을 클릭합니다.

원하는 경우 GitHub에서 Cloud Build 앱을 완전히 제거할 수 있습니다.

GitHub 애플리케이션 설정으로 이동합니다.

GitHub 애플리케이션 페이지로 이동
설치된 GitHub 앱 탭의 Cloud Build 행에서 구성을 클릭합니다. 그런 다음 위험 영역 섹션에서 Google Cloud 빌더 제거 행의 제거 버튼을 클릭합니다.

페이지 상단에 다음과 같은 메시지가 표시됩니다. '이제 다 되었습니다. Google Cloud Build를 제거하기 위한 작업이 대기 열에 추가되었습니다.'
승인된 GitHub 앱 탭에서 Google Cloud Build 행의 취소 버튼을 클릭한 다음 팝업에서 액세스 취소를 확인합니다.를 클릭합니다.

GitHub 저장소를 유지하지 않으려면 다음 안내를 따르세요.

GitHub에서 포크된 저장소의 기본 페이지로 이동합니다.
저장소 이름 아래에서 설정을 클릭합니다.
위험 영역까지 아래로 스크롤합니다.
이 저장소 삭제를 클릭하고 확인 단계를 따릅니다.

다음 단계

Cloud Foundation Toolkit 템플릿을 사용하여 Google Cloud에서 반복 가능한 기업용 기본 환경을 빠르게 구축하기
이 튜토리얼에 설명된 GitOps 워크플로에 대해 알아보려면 Next' 19의 Repeatable Google Cloud Environments at Scale With Cloud Build Infra-As-Code Pipelines 시청하기
Cloud Build를 사용한 GitOps 스타일의 지속적 배포 튜토리얼 확인하기
빌드 단계 순서 구성, 아티팩트 빌드, 테스트, 배포, 커스텀 빌드 단계 만들기 등 Cloud Build의 고급 기능 살펴보기
Cloud Build로 Terraform 배포의 확장 및 규정 준수 보장에 대한 블로그를 확인하세요.
DevOps에 대한 리소스를 읽어보세요.
이 튜토리얼과 관련된 DevOps 기능 자세히 알아보기
DevOps 빠른 점검을 사용하여 업계와 비교되는 자신의 현재 상태를 파악하세요.