Terraform으로 데이터 품질 규칙을 코드로 관리

이 튜토리얼에서는 Terraform, Cloud Build, GitHub을 이용해서 Dataplex 데이터 품질 규칙을 코드로 관리하는 방법을 설명합니다.

데이터 품질 규칙을 위한 여러 다양한 옵션을 사용해서 데이터 품질을 정의하고 측정할 수 있습니다. 대규모 인프라 관리 전략의 일부로서 데이터 품질 규칙을 배포하는 프로세스를 자동화할 때는 지정한 규칙에 따라 데이터가 일관적이고 예측 가능한 방식으로 사용되는지 확인해야 합니다.

dev 및 prod 환경과 같이 여러 환경에 대해 여러 버전의 데이터 세트가 있을 때 Terraform은 환경별 데이터 세트 버전에 데이터 품질 규칙을 할당할 수 있는 신뢰할 수 있는 방법을 제공합니다.

버전 제어도 중요한 DevOps 권장사항입니다. 데이터 품질 규칙을 코드로 관리하면 GitHub 기록에 제공되는 데이터 품질 규칙 버전이 제공됩니다. Terraform은 또한 해당 상태를 Cloud Storage에 저장할 수 있으며, 여기에는 이전 버전의 상태 파일이 포함될 수 있습니다.

Terraform 및 Cloud Build에 대한 자세한 내용은 Google Cloud의 Terraform 개요 및 Cloud Build를 참조하세요.

아키텍처

이 튜토리얼에서 Terraform 실행을 위해 Cloud Build를 사용하는 방법을 알아보려면 다음 아키텍처 다이어그램을 참조하세요. 이 다이어그램에서는 GitHub 브랜치(dev 및 prod)를 사용하여 실제 환경을 나타냅니다.

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

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 저장소에 연결합니다.
Dataplex 데이터 품질 규칙을 설정합니다.
기능 브랜치 및 테스트에서 환경 구성을 변경합니다.
변경사항을 개발 환경으로 승격합니다.
변경사항을 프로덕션 환경으로 승격합니다.

비용

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

프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요. 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.

Go to project selector

Make sure 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.

Go to project selector

Make sure that billing is enabled for your Google Cloud project.

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.
Cloud Shell에서 방금 선택한 프로젝트의 ID를 가져옵니다.
```
gcloud config get-value project
```
이 명령어에서 프로젝트 ID를 반환하지 않으면 Cloud Shell에서 프로젝트를 사용하도록 구성합니다. PROJECT_ID를 프로젝트 ID로 바꿉니다.
```
gcloud config set project PROJECT_ID
```

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

gcloud services enable bigquery.googleapis.com cloudbuild.googleapis.com compute.googleapis.com dataplex.googleapis.com

이 단계를 완료하는 데 몇 분 정도 걸릴 수 있습니다.

Cloud Shell에서 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 브랜치에 병합해 변경사항을 승격합니다.

시작하려면 terraform-google-dataplex-auto-data-quality 저장소를 포크합니다.

GitHub에서 https://github.com/GoogleCloudPlatform/terraform-google-dataplex-auto-data-quality.git로 이동합니다.
포크를 클릭합니다.

이제 소스 파일이 있는 terraform-google-dataplex-auto-data-quality 저장소의 복사본이 준비되었습니다.

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

cd ~
git clone https://github.com/YOUR_GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality.git
cd ~/terraform-google-dataplex-auto-data-quality

dev 브랜치와 prod 브랜치를 만듭니다.
```
git checkout -b prod
git checkout -b dev
```

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

environments/ 폴더에는 dev 및 prod 같은 환경을 나타내는 하위 폴더가 포함됩니다. 따라서 다양한 성숙도, 개발, 프로덕션 단계에서 워크로드 간에 논리적인 구분이 가능합니다.
modules/ 폴더에는 인라인 Terraform 모듈이 있습니다. 이러한 모듈은 관련 리소스의 논리적 그룹을 나타내며 서로 다른 환경에서 코드를 공유하는 데 사용됩니다. 여기에서 modules/deploy/ 모듈은 배포 템플릿을 나타내며 여러 배포 환경에 재사용됩니다.
modules/deploy/ 내부에 대한 설명은 다음과 같습니다.
- rule/ 폴더에는 데이터 품질 규칙이 포함된 yaml 파일이 포함됩니다. 하나의 파일은 하나의 테이블에 대한 데이터 품질 규칙 집합을 나타냅니다. 이 파일은 dev 및 prod 환경에 사용됩니다.
- schemas/ 폴더에는 이 인프라에 배포된 BigQuery 테이블의 테이블 스키마가 포함됩니다.
- bigquery.tf 파일에는 이 배포에서 생성된 BigQuery 테이블의 구성이 포함됩니다.
- dataplex.tf 파일에는 데이터 품질에 대한 Dataplex 데이터 스캔이 포함됩니다. 이 파일은 yaml 파일에서 환경으로 데이터 품질 파일을 읽어오기 위해 rules_file_parsing.tf와 함께 사용됩니다.
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이 실행됩니다. pull 요청을 병합하기 전에 요금제를 검토하여 예를 들어 승인되지 않은 항목에 액세스 권한이 부여되지 않도록 할 수 있습니다.

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

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

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

# Copyright 2024 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-dev"
  }
}

각 dev 및 prod 환경에 개별 backend.tf 파일이 존재합니다. 각 환경에 서로 다른 Cloud Storage 버킷을 사용하는 것이 권장사항으로 간주됩니다.

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

Cloud Shell에서 다음 2개의 Cloud Storage 버킷을 만듭니다.

DEV_BUCKET=gs://PROJECT_ID-tfstate-dev
gcloud storage buckets create ${DEV_BUCKET}

PROD_BUCKET=gs://PROJECT_ID-tfstate-prod
gcloud storage buckets create ${PROD_BUCKET}

객체 버전 관리를 사용 설정하여 배포 기록을 유지합니다.
```
gcloud storage buckets update ${DEV_BUCKET} --versioning
gcloud storage buckets update ${PROD_BUCKET} --versioning
```
객체 버전 관리를 사용 설정하면 스토리지 비용이 늘어납니다. 하지만 객체 수명 주기 관리를 구성하여 이전 상태 버전을 삭제하면 이 비용을 줄일 수 있습니다.

PROJECT_ID 자리 표시자를 각 환경의 main.tf 및 backend.tf 파일에 있는 프로젝트 ID로 바꿉니다.

cd ~/terraform-google-dataplex-auto-data-quality
sed -i s/PROJECT_ID/PROJECT_ID/g environments/*/main.tf
sed -i s/PROJECT_ID/PROJECT_ID/g environments/*/backend.tf

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

cd ~/solutions-terraform-cloudbuild-gitops
sed -i "" s/PROJECT_ID/PROJECT_ID/g environments/*/main.tf
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/main.tf
       modified:   environments/prod/backend.tf
       modified:   environments/prod/main.tf
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 매니페스트를 자동으로 적용할 수 있습니다.

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

GitHub Marketplace에서 Cloud Build 앱 페이지로 이동합니다.
- GitHub에서 앱을 처음 구성할 때는 페이지 하단에서 Google Cloud Build로 설정을 클릭한 후 이 앱에 GitHub 계정 액세스 권한 부여를 클릭합니다.
- GitHub에서 앱을 처음으로 구성하는 것이 아니라면 액세스 구성을 클릭합니다. 개인 계정의 애플리케이션 페이지가 열립니다.
Cloud Build 행에서 구성을 클릭합니다.
저장소만 선택을 선택한 후 terraform-google-dataplex-auto-data-quality를 선택하여 저장소에 연결합니다.
저장 또는 설치를 클릭합니다. 버튼 라벨은 워크플로에 따라 다릅니다. 설치를 계속할 수 있도록 Google Cloud로 리디렉션됩니다.
Google Cloud 계정에 로그인합니다. 요청이 있을 경우 GitHub와 Cloud Build 통합을 승인합니다.
Cloud Build 페이지에서 프로젝트를 선택합니다. 마법사가 표시됩니다.
저장소 선택 섹션에서 GitHub 계정과 terraform-google-dataplex-auto-data-quality 저장소를 선택합니다.
이용약관에 동의하면 체크박스를 선택하고 연결을 클릭합니다.
트리거 만들기 섹션에서 트리거 만들기를 클릭합니다.
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/terraform-google-dataplex-auto-data-quality

dev 브랜치에 있는지 확인합니다.
수정할 파일을 열려면 modules/deploy/dataplex.tf 파일로 이동합니다.
19행에서 the_environment 라벨을 environment로 바꿉니다.
페이지 하단에 "modifying label"과 같은 커밋 메시지를 추가하고 이 커밋에 새 브랜치를 만들고 pull 요청 시작을 선택합니다.
변경사항 제안을 클릭합니다.
다음 페이지에서 pull 요청 만들기를 클릭하여 dev 브랜치 변경사항과 함께 새 pull 요청을 엽니다.

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

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

- id: 'tf plan'
  name: 'hashicorp/terraform:1.8.4'
  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 "*************** TERRAFORM PLAN ******************"
          echo "******* At environment: ${env} ********"
          echo "*************************************************"
          terraform plan || exit 1
          cd ../../
        done
      fi

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

- id: 'tf apply'
  name: 'hashicorp/terraform:1.8.4'
  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/terraform-google-dataplex-auto-data-quality

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

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

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

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

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

https://github.com/YOUR_GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality

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

Cloud Build 페이지로 이동
빌드를 열고 로그를 확인합니다. Terraform에서 만들고 관리하는 모든 리소스를 보여줍니다.

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

이제 개발 환경이 완전히 테스트되었으므로 데이터 품질 규칙을 위한 코드를 프로덕션으로 승격할 수 있습니다.

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

https://github.com/YOUR_GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality

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

Cloud Build 페이지로 이동

Terraform 및 Cloud Build를 사용해서 관리되는 데이터 품질 규칙을 성공적으로 구성했습니다.

삭제

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

프로젝트 삭제

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

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

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

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

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에서 포크된 저장소의 기본 페이지로 이동합니다.
저장소 이름 아래에서 설정을 클릭합니다.
위험 영역으로 이동합니다.
이 저장소 삭제를 클릭하고 확인 단계를 따릅니다.

다음 단계

자동 데이터 품질 알아보기
DevOps 및 DevOps 권장사항 자세히 알아보기
Cloud Foundation Toolkit에서 추가 Terraform 템플릿 살펴보기