Terraform config-as-code를 저장하도록 CI/CD 구성

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

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

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

• 버전 제어
• 지속적 통합
• 지속적 배포
• 지속적 테스트

아키텍처

이 튜토리얼에서는 Terraform 실행 관리에 GitOps 사례를 적용합니다. 이 다이어그램에서는 Secure Source Manager 브랜치 dev 및 prod를 사용하여 실제 환경을 나타냅니다. 이러한 환경은Google Cloud 프로젝트 내의 Virtual Private Cloud (VPC) 네트워크 dev 및 prod에 의해 정의됩니다.

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

개발자나 운영자는 개발 또는 기능 브랜치에 인프라 제안을 한 후 pull 요청을 통해 이를 제출하는 것이 좋습니다. 이렇게 하면 공동작업자와 잠재적인 변경사항을 논의 및 검토하고 변경사항이 기본 브랜치에 병합되기 전에 후속 커밋을 추가할 수 있습니다.

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

목표

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

비용

이 문서에서는 비용이 청구될 수 있는 Google Cloud구성요소( )를 사용합니다.

• Cloud Build
• Cloud Storage
• Compute Engine

프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요.

Google Cloud 신규 사용자는 무료 체험판을 사용할 수 있습니다.

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

시작하기 전에

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

2. Cloud Shell에서 방금 선택한 프로젝트의 ID를 가져옵니다.

   gcloud config get-value project

   이 명령어가 프로젝트 ID를 반환하지 않으면 프로젝트를 사용하도록 Cloud Shell을 구성합니다. PROJECT_ID를 프로젝트 ID로 바꿉니다.

   gcloud config set project PROJECT_ID

3. 필요한 API를 사용 설정합니다.

   gcloud services enable cloudbuild.googleapis.com compute.googleapis.com securesourcemanager.googleapis.com

   이 단계를 완료하는 데 몇 분 정도 걸릴 수 있습니다.
4. Cloud Shell에서 Git을 사용한 적이 없으면 내 이름과 이메일 주소를 사용하여 Git을 구성합니다.

   git config --global user.email "YOUR_EMAIL_ADDRESS"
   git config --global user.name "YOUR_NAME"
   

   Git은 이 정보를 사용하여 Cloud Shell에서 만드는 커밋의 작성자를 식별합니다.

Secure Source Manager 저장소 설정

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

• dev 분기에는 개발 환경에 적용되는 최신 변경사항이 포함됩니다.
• prod 브랜치에는 프로덕션 환경에 적용되는 최신 변경사항이 포함됩니다.
• feature_x와 유사한 기능 브랜치는 dev 또는 prod 브랜치로 푸시하기 전에 변경사항을 만드는 데 사용됩니다.

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

1. 빈 Secure Source Manager 저장소 만들기 - 저장소를 초기화하지 마세요.

2. 다음 명령어를 실행하여 보안 소스 관리자 인증 도우미를 전역 git config에 추가합니다.

   git config --global credential.'https://*.*.sourcemanager.dev'.helper gcloud.sh
   

   인증 도우미는 Secure Source Manager와 함께 Git 명령어를 사용할 때 gcloud CLI를 사용하여Google Cloud 사용자 인증 정보를 가져옵니다.

3. 초기 사용자 인증 정보 설정 후 다시 인증하려면 다음 gcloud CLI 명령어를 실행합니다.

   gcloud auth login
   

4. solutions-terraform-cloudbuild-gitops 저장소를 로컬 셸 또는 작업 환경에 클론합니다.

   git clone https://github.com/GoogleCloudPlatform/solutions-terraform-cloudbuild-gitops.git
   

5. Secure Source Manager 저장소를 업스트림으로 추가합니다.

   git remote add google HTTPS_REPO_URL
   

   여기서 HTTPS_REP_URL은 Secure Source Manager 저장소의 HTTPS URL입니다. URL은 Secure Source Manager 웹 인터페이스의 저장소 페이지 상단에서 확인할 수 있습니다.

6. dev 브랜치를 만들고 전환합니다.

   git checkout dev
   

7. 다음 명령어를 사용하여 클론된 저장소를 저장소에 푸시합니다.

   git push -u google --all
   

8. prod 브랜치에 대해 이전 두 단계를 반복합니다.

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

• 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 요청을 병합하기 전에 요금제를 검토하여 예를 들어 승인되지 않은 항목에 액세스 권한이 부여되지 않도록 할 수 있습니다.

빌드 구성 파일 수정

샘플 빌드 구성 파일이 Secure Source Manager와 호환되도록 하려면 다음을 수정해야 합니다.

• 저장소를 클론하는 단계를 추가합니다.
• 브랜치 이름을 가져와 변수에 할당하는 단계를 추가합니다.

dev 브랜치에서 빌드 구성 파일을 수정합니다.

1. dev 브랜치로 변경합니다.

   git checkout dev
   

2. cloudbuild.yaml 파일을 열고 콘텐츠를 다음으로 바꿉니다.

   # 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.
   
   
   steps:
   - id: 'clone repository'
     name: 'gcr.io/cloud-builders/git'
     args:
     - clone
     - '${_REPO_URL}'
     - .
   - id: 'branch name'
     name: gcr.io/cloud-builders/git
     entrypoint: 'sh'
     args:
     - '-c'
     - |
         branch=$(basename "$_REF")
         git checkout ${branch}
         echo "***********************"
         git branch --show-current
         echo "***********************"
   
   - id: 'tf init'
     name: 'hashicorp/terraform:1.0.0'
     entrypoint: 'sh'
     args:
     - '-c'
     - |
      branch=$(basename "$_REF")
         if [ -d "environments/${branch}/" ]; then
           cd environments/${branch}
           terraform init
         else
           for dir in environments/*/
           do
             cd ${dir}
             env=${dir%*/}
             env=${env#*/}
             echo ""
             echo "*************** TERRAFORM INIT ******************"
             echo "******* At environment: ${env} ********"
             echo "*************************************************"
             terraform init || exit 1
             cd ../../
           done
         fi
   
   - id: 'tf plan'
     name: 'hashicorp/terraform:1.0.0'
     entrypoint: 'sh'
     args:
     - '-c'
     - |
         branch=$(basename "$_REF")
         if [ -d "environments/${branch}/" ]; then
           cd environments/${branch}
           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
   
   - id: 'tf apply'
     name: 'hashicorp/terraform:1.0.0'
     entrypoint: 'sh'
     args:
     - '-c'
     - |
         branch=$(basename "$_REF")
         if [ -d "environments/${branch}/" ]; then
           cd environments/${branch}
           terraform apply -auto-approve
         else
           echo "***************************** SKIPPING APPLYING *******************************"
           echo "Branch '${branch}' does not represent an official environment."
           echo "*******************************************************************************"
         fi

3. 파일이 수정되었는지 확인합니다.

   git status
   

4. 변경사항을 커밋하고 푸시합니다.

   git add --all
   git commit -m "Modify build config file."
   git push google dev
   

5. pull 요청을 열어 변경사항을 prod 브랜치로 빠르게 승격합니다.

   1. Secure Source Manager 웹 인터페이스에서 저장소로 이동합니다.
   2. Pull 요청 탭을 클릭합니다.
   3. 새 pull 요청을 클릭합니다.
   4. 병합 대상: 필드에서 prod 브랜치를 선택합니다.
   5. 다음에서 가져오기: 필드에서 dev 브랜치를 선택합니다.
   6. 변경사항을 검토한 후 새 pull 요청을 클릭합니다.
   7. pull 요청 만들기를 클릭합니다.
   8. Merge pull request(pull 요청 병합)를 클릭합니다.

   9. pull 요청 병합을 다시 클릭합니다.

      변경사항이 prod 브랜치에 병합됩니다.

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

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

이러한 문제를 방지하기 위해 이 섹션에서는 Cloud Storage 버킷을 가리키는 원격 상태를 구성합니다. 원격 상태는 backends의 기능으로, 이 튜토리얼에서는 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 프로젝트를 가리키도록 일부 파일을 변경합니다.

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

   PROJECT_ID=$(gcloud config get-value project)
   gcloud storage buckets create gs://${PROJECT_ID}-tfstate
   

2. 객체 버전 관리를 사용 설정하여 배포 기록을 유지합니다.

   gcloud storage buckets update gs://${PROJECT_ID}-tfstate --versioning
   

   객체 버전 관리를 사용 설정하면 스토리지 비용이 늘어납니다. 하지만 객체 수명 주기 관리를 구성하여 이전 상태 버전을 삭제하면 이 비용을 줄일 수 있습니다.

3. 변경사항을 적용할 새 cloud-storage-bucket 브랜치를 만듭니다.

   cd ~/solutions-terraform-cloudbuild-gitops
   git checkout -b cloud-storage-bucket
   

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

   sed -i s/PROJECT_ID/$PROJECT_ID/g environments/*/terraform.tfvars
   sed -i s/PROJECT_ID/$PROJECT_ID/g environments/*/backend.tf
   

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

   sed -i "" s/PROJECT_ID/$PROJECT_ID/g environments/*/terraform.tfvars
   sed -i "" s/PROJECT_ID/$PROJECT_ID/g environments/*/backend.tf
   

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

   git status
   

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

   On branch cloud-storage-bucket
   Changes not staged for commit:
   (use "git add ..." to update what will be committed)
   (use "git restore ..." 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")
   

6. 변경사항을 커밋하고 푸시합니다.

   git add --all
   git commit -m "Update project IDs and buckets"
   git push google -u cloud-storage-bucket
   

   새 cloud-storage-bucket 브랜치가 저장소에 푸시됩니다.

7. 각 브랜치의 병합 요청을 열고 제출하여 cloud-storage-bucket 변경사항을 dev 및 prod 브랜치로 병합합니다.

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

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

참고: 빌드 실행에 사용되는 Cloud Build 기본 서비스 계정은 변경 중입니다. 빌드를 실행할 고유한 서비스 계정을 지정하는 것이 가장 좋습니다. 자세한 내용은 Cloud Build 서비스 계정 변경을 참고하세요.

1. Cloud Build 서비스 계정 이메일을 찾으려면 Cloud Build 페이지에서 설정으로 이동하세요.

   Cloud Build 설정으로 이동

2. 서비스 계정 이메일 값을 복사합니다.

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

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

   다음을 바꿉니다.

   • PROJECT_ID를 프로젝트 ID로 바꿉니다.
   • CLOUDBUILD_SA을 Cloud Build 서비스 계정 이메일로 바꿉니다.

Cloud Build에 연결

모든 브랜치에 푸시할 때 Cloud Build를 트리거하려면 Secure Source Manager 웹훅을 설정하세요. 빌드 구성 파일은 브랜치 이름을 확인하여 dev 또는 prod 환경을 변경해야 하는지 확인합니다.

1. 프로젝트에서 Cloud Build를 사용 설정하고 설정합니다.

2. Google Cloud 콘솔에서 트리거 페이지를 엽니다.

   트리거 페이지 열기

3. 페이지 상단의 프로젝트 선택기 드롭다운 메뉴에서 프로젝트를 선택합니다.

4. 열기를 클릭합니다.

5. 트리거 만들기를 클릭합니다.

6. 다음 트리거 설정을 입력합니다.

   • 이름: trigger-on-push

   • 리전: 트리거의 리전을 선택합니다. 트리거와 연결된 빌드 구성 파일이 비공개 풀을 지정하는 경우, 트리거에 선택한 리전이 비공개 풀의 리전과 일치해야 합니다.

     참고: 비공개 풀을 사용하는 경우 비공개 풀이 공개 인터넷에 액세스할 수 있도록 외부 IP를 할당해야 합니다. 자세한 내용은 새 비공개 풀 만들기를 참고하세요.

     global을 리전으로 선택하면 Cloud Build가 빌드 구성 파일에 지정된 리전을 사용하여 빌드를 실행합니다. 빌드 구성 파일에 비공개 풀을 지정하는 경우 비공개 풀의 리전이거나 비공개 풀을 지정하지 않은 경우 전역 기본 풀일 수 있습니다.

   • 설명(선택사항): 트리거에 대한 설명을 입력합니다.

   • 이벤트: 트리거를 호출할 저장소 이벤트로 웹훅 이벤트를 선택합니다.

     Secret Manager가 설치되어 있지 않으면 Secret Manager를 사용 설정하라는 메시지가 표시됩니다.

   • 웹훅 URL: 다음 중 하나를 선택합니다.

     • Cloud Build를 사용하여 새 보안 비밀을 생성하려면 새 보안 비밀 사용을 선택합니다. 보안 비밀 만들기를 클릭하여 보안 비밀을 만듭니다.
     • 기존 보안 비밀을 사용하려면 기존 보안 비밀을 사용하거나 직접 보안 비밀 만들기를 선택합니다. 드롭다운 선택 상자에 보안 비밀과 버전을 입력합니다.

     기존 보안 비밀을 사용하는 경우 Cloud Build 서비스 에이전트인 [e-mail]에 Secret Manager 보안 비밀 접근자 역할을 수동으로 부여해야 할 수 있습니다.

     자세한 내용은 Cloud Build 서비스 에이전트에 역할 부여를 참고하세요.

7. URL 미리보기 표시를 클릭하고 URL을 기록합니다. Secure Source Manager에서 웹훅을 설정하려면 이 URL이 필요합니다.

   • 구성: 유형에서 Cloud Build 구성 파일 (YAML 또는 JSON)을 선택하고 위치에서 인라인을 선택합니다.

8. 편집기 열기 버튼을 클릭하여 빌드 구성 파일을 수정합니다.

9. cloudbuild.yaml 파일의 내용을 편집기에 복사합니다.

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

   - id: 'tf plan'
     name: 'hashicorp/terraform:1.0.0'
     entrypoint: 'sh'
     args:
     - '-c'
     - |
         branch=$(basename "$_REF")
         if [ -d "environments/${branch}/" ]; then
           cd environments/${branch}
           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 명령어는 환경 분기에 대해 실행되지만 다른 경우에는 완전히 무시됩니다.

10. + 변수 추가를 클릭하고 다음 두 개의 치환 변수를 추가합니다.

    • 변수: _REPO_URL, 값:$(body.repository.clone_url)
    • 변수: _REF, 값:$(body.ref)

11. 만들기를 클릭합니다.

Secure Source Manager에서 웹훅 설정하기

dev 또는 prod 브랜치에 푸시할 때 빌드를 트리거하는 웹훅을 만듭니다.

1. Secure Source Manager 웹 인터페이스에서 웹훅을 만들 저장소로 이동합니다.
2. 설정을 클릭합니다.
3. 웹훅을 클릭한 다음 웹훅 추가를 클릭합니다.

4. Hook ID 필드에 웹훅의 ID를 입력합니다.

   참고: 후크 ID는 리소스 이름 지정 규칙을 따라야 합니다. 소문자, 숫자 또는 대시만 포함해야 하고, 문자로 시작해야 하며, 웹훅을 만든 후에는 변경할 수 없습니다.

5. 타겟 URL 필드에 Cloud Build에서 웹훅 트리거를 설정할 때 복사한 웹훅 URL을 입력합니다.

   웹훅 URL을 찾는 방법은 다음과 같습니다.

   1. Google Cloud 콘솔에서 트리거 페이지를 엽니다.

      트리거 페이지 열기

   2. 트리거를 클릭합니다.

   3. Webhook URL 섹션에서 Show URL preview를 클릭하고 URL을 복사합니다.

6. 웹훅 URL에는 Cloud Build 트리거를 만들 때 입력한 키와 보안 비밀 값이 포함됩니다. 이러한 값이 유출되지 않도록 대상 URL 끝에서 삭제하고 민감한 쿼리 문자열 필드에 복사합니다.

   웹훅 URL에서 키와 비밀번호를 찾으려면 key=로 시작하는 텍스트를 찾으세요.

   예를 들어 다음 URL이 있다고 가정해 보겠습니다. https://cloudbuild.googleapis.com/v1/projects/my-project/triggers/test-trigger:webhook?key=eitIfKhYnv0LrkdsyHqIros8fbsheKRIslfsdngf&secret=Hello%20Secret%20Manager

   타겟 URL 필드에서 물음표 ?key=...로 시작하는 부분을 복사하여 삭제합니다. 그런 다음 초기 물음표를 삭제하고 나머지 부분 key=...을 민감한 쿼리 문자열 필드로 이동합니다.

7. 웹훅 추가를 클릭합니다.

8. 웹훅이 웹훅 페이지에 표시됩니다.

   참고: 웹훅을 추가하거나 수정할 때 Sensitive Query String의 길이가 입력된 길이와 일치하지 않을 수 있습니다. 이는 보안을 위해 자리표시자 문자열이 사용되기 때문입니다.

새 기능 브랜치에서 환경 구성 변경

1. dev 브랜치에 있는지 확인합니다.

   cd ~/solutions-terraform-cloudbuild-gitops
   git checkout dev
   

2. 최신 변경사항을 가져옵니다.

   git pull
   

3. bug-fix 브랜치를 만들어 환경 구성을 변경합니다.

   git checkout -b bug-fix
   

4. 수정할 modules/firewall/main.tf을 엽니다.

5. 30행의 target_tags 필드에서 "http-server2" 오타를 수정합니다.

   값은 "http-server"여야 합니다.

6. 변경사항을 커밋하고 푸시합니다.

   git add --all
   git commit -m "Fix typo."
   git push google -u bug-fix
   

7. Google Cloud 콘솔에서 Cloud Build 기록 페이지를 엽니다.

   방문 기록 페이지 열기

8. 빌드를 클릭하여 terraform plan의 출력을 비롯한 자세한 내용을 확인합니다.

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

- id: 'tf plan'
  name: 'hashicorp/terraform:1.0.0'
  entrypoint: 'sh'
  args:
  - '-c'
  - |
      branch=$(basename "$_REF")
      if [ -d "environments/${branch}/" ]; then
        cd environments/${branch}
        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' - | branch=$(basename "$_REF") if [ -d "environments/${branch}/" ]; then cd environments/${branch} terraform apply -auto-approve else echo "***************************** SKIPPING APPLYING *******************************" echo "Branch '${branch}' does not represent an official environment." echo "*******************************************************************************" fi

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

이제 dev 환경에 원하는 상태를 적용할 차례입니다.

1. Secure Source Manager 웹 인터페이스에서 저장소로 이동합니다.
2. 새 pull 요청을 클릭합니다.
3. 병합 대상: 필드에서 dev 브랜치를 선택합니다.
4. 다음에서 가져오기: 필드에서 bug-fix 브랜치를 선택합니다.
5. 새 pull 요청을 클릭합니다.
6. pull 요청 만들기를 클릭합니다.
7. pull 요청 병합을 클릭한 후 pull 요청 병합을 다시 클릭합니다.

8. 새 Cloud Build가 트리거되었는지 확인합니다.

   Cloud Build 페이지로 이동

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

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

   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
   

10. EXTERNAL_IP_VALUE를 복사하고 웹브라우저에서 주소를 엽니다.

    http://EXTERNAL_IP_VALUE
    

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

11. Cloud Storage로 이동합니다.

    Cloud Storage 페이지로 이동

12. 프로젝트를 선택합니다.

13. Terraform 상태 스토리지 버킷을 클릭합니다. 버킷 이름은 다음과 같습니다.

    PROJECT_ID-tfstate
    

14. env를 클릭한 다음 dev를 클릭하여 Terraform 상태 파일을 확인합니다.

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

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

1. Secure Source Manager 웹 인터페이스에서 저장소로 이동합니다.
2. Pull 요청 탭을 클릭합니다.
3. 새 pull 요청을 클릭합니다.
4. 병합 대상:에 저장소 prod 브랜치를 선택합니다.
5. 다음에서 가져오기:에서 저장소 dev 브랜치를 선택합니다.
6. 새 pull 요청을 클릭합니다.
7. 제목에 '네트워킹 변경사항 홍보'와 같은 제목을 입력한 후 pull 요청 만들기를 클릭합니다.

8. 제안된 변경사항을 검토하고 pull 요청 병합을 클릭합니다.

   날짜와 저장소 URL이 댓글 필드에 추가됩니다.

9. pull 요청 병합을 다시 클릭하여 확인합니다.

10. Google Cloud 콘솔에서 빌드 기록 페이지를 열어 프로덕션 환경에 적용되는 변경사항을 확인합니다.

    Cloud Build 페이지로 이동

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

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

    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
    

12. EXTERNAL_IP_VALUE를 복사하고 웹브라우저에서 주소를 엽니다.

    http://EXTERNAL_IP_VALUE
    

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

13. Cloud Storage로 이동합니다.

    Cloud Storage 페이지로 이동

14. 프로젝트를 선택합니다.

15. Terraform 상태 스토리지 버킷을 클릭합니다. 버킷 이름은 다음과 같습니다.

    PROJECT_ID-tfstate
    

16. env를 클릭한 다음 prod를 클릭하여 Terraform 상태 파일을 확인합니다.

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

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

삭제

이 튜토리얼을 완료한 후에는 향후에 요금이 청구되지 않도록Google Cloud 에서 만든 리소스를 삭제합니다.

프로젝트 삭제

주의: 프로젝트 삭제가 미치는 영향은 다음과 같습니다.

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

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

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

다음 단계

• 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 빠른 점검을 사용하여 업계와 비교되는 자신의 현재 상태를 파악하기