Terraform を使用してデータ品質ルールをコードとして管理する

このチュートリアルでは、Terraform、Cloud Build、GitHub を使用して Dataplex データ品質ルールをコードとして管理する方法について説明します。

データの品質を定義して測定するために、データ品質ルールのさまざまなオプションを使用できます。大規模なインフラストラクチャ管理戦略の一環としてデータ品質ルールをデプロイするプロセスを自動化すると、データに割り当てるルールを一貫性をもって、予測可能な形で適用できます。

dev 環境や prod 環境など、複数の環境用の異なるバージョンのデータセットがある場合、Terraform では、信頼性の高い方法で、環境固有のバージョンのデータセットにデータ品質ルールを割り当てることができます。

バージョン管理も、重要な DevOps のベストプラクティスです。データ品質ルールをコードとして管理すると、GitHub の履歴で参照できるデータ品質ルールのバージョンが提供されます。Terraform は Cloud Storage に状態を保存でき、Cloud Storage には以前のバージョンの状態ファイルを保存できます。

Terraform と Cloud Build の詳細については、Google Cloud での Terraform の概要と Cloud Build をご覧ください。

アーキテクチャ

このチュートリアルが Cloud Build を使用して Terraform の実行を管理する方法を理解するために、次のアーキテクチャ図を検討してください。GitHub ブランチ（dev と prod）を使用して、実際の環境を表していることに留意してください。

開発環境と本番環境を備えたインフラストラクチャ。

Terraform コードを dev または prod ブランチに push すると、プロセスが開始されます。このシナリオでは、Cloud Build がトリガーし、Terraform マニフェストを適用して、それぞれの環境で必要な状態を実現します。一方、Terraform コードを他のブランチ（機能ブランチなど）に push すると、Cloud Build が実行され、terraform plan が実行されますが、どの環境にも適用されません。

理想的には、開発者またはオペレーターのいずれかが、保護されていないブランチに対してインフラストラクチャの提案を行い、pull リクエストを通じてそれらを提出する必要があります。このチュートリアルで後述する Cloud Build GitHub アプリは、ビルドジョブを自動的にトリガーし、terraform plan レポートをこれらの pull リクエストにリンクします。このようにして、潜在的な変更を共同編集者と話し合ってレビューし、変更がベースブランチにマージされる前にフォローアップ commit を追加できます。

懸念事項が発生しない場合は、最初に変更を 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.

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 bigquery.googleapis.com cloudbuild.googleapis.com compute.googleapis.com dataplex.googleapis.com

このステップが完了するまでに数分かかる場合があります。

Git を Cloud Shell で使用したことがない場合は、名前とメールアドレスを使用して Git を構成します。
```
git config --global user.email "YOUR_EMAIL_ADDRESS"
git config --global user.name "YOUR_NAME"
```
Git はこの情報を使用して、Cloud Shell で作成する commit の作成者を識別します。

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 に移動します。
[Fork] をクリックします。

これで、ソースファイルを格納する 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 ファイルが含まれています。1 つのファイルは、1 つのテーブルに対する一連のデータ品質ルールを表します。このファイルは、dev 環境と prod 環境で使用されます。
- schemas/ フォルダには、このインフラストラクチャにデプロイされた BigQuery テーブルのテーブルスキーマが含まれています。
- bigquery.tf ファイルには、このデプロイで作成される BigQuery テーブルの構成が含まれています。
- dataplex.tf ファイルには、データ品質のための Dataplex データスキャンが含まれています。このファイルは、rules_file_parsing.tf と組み合わせて使用され、yaml ファイルから環境にデータ品質ルールを読み取ります。
cloudbuild.yaml ファイルは、一連の手順に基づいてタスクを実行する方法など、Cloud Build に関する手順を含むビルド構成ファイルです。このファイルは、Cloud Build がコードを取得するブランチに応じて、条件付き実行を指定します。たとえば、
- dev と prod ブランチの場合は、次の手順が実行されます。
  1. terraform init
  2. terraform plan
  3. terraform apply
- その他のブランチの場合は、次の手順が実行されます。
  1. terraform init（すべての environments サブフォルダ）
  2. terraform plan（すべての environments サブフォルダ）

提案された変更がすべての環境に適していることを確認するために、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 の後に 2 つの引用符（""）の追加が必要な場合があります。

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")

変更を commit して push します。
```
git add --all
git commit -m "Update project IDs and buckets"
git push origin dev
```
GitHub の構成に応じて、前述の変更を push するために認証する必要があります。

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 に push するたびに Cloud Build が Terraform マニフェストを自動的に適用できます。

次の手順では、terraform-google-dataplex-auto-data-quality リポジトリにのみアプリをインストールする手順を示していますが、より多くのリポジトリまたはすべてのリポジトリにアプリをインストールすることもできます。

GitHub Marketplace で Cloud Build アプリのページに移動します。
- GitHub でアプリを初めて構成する場合は、ページの下部にある [Setup with Google Cloud Build] をクリックします。次に、[Grant this app access to your GitHub account] をクリックします。
- GitHub でアプリを構成するのが初めてではない場合は、[Configure access] をクリックします。個人アカウントの [Applications] ページが開きます。
Cloud Build の行で [Configure] をクリックします。
[Only select repositories] を選択し、[terraform-google-dataplex-auto-data-quality] を選択してリポジトリに接続します。
[Save] または [Install] をクリックします。ボタンのラベルはワークフローによって異なります。インストールを続行するために Google Cloud にリダイレクトされます。
Google Cloud アカウントでログインします。プロンプトが表示されたら、Cloud Build と GitHub の統合を承認します。
Cloud Build ページでプロジェクトを選択します。ウィザードが表示されます。
[リポジトリを選択] セクションで、GitHub アカウントと terraform-google-dataplex-auto-data-quality リポジトリを選択します。
利用規約に同意する場合は、チェックボックスをオンにして、[接続] をクリックします。
[トリガーを作成] セクションで、[トリガーを作成] をクリックします。
1. トリガー名を追加します（push-to-branch など）。このトリガー名は、後で必要になるためメモしておきます。
2. [イベント] セクションで、[ブランチに push する] を選択します。
3. [ソース] セクションの [ブランチ] フィールドで .* を選択します。
4. [作成] をクリックします。

Cloud Build GitHub アプリが構成され、GitHub リポジトリが Google Cloud プロジェクトにリンクされました。今後、GitHub リポジトリの変更により Cloud Build の実行がトリガーされ、GitHub Checks を使用して結果が GitHub に報告されます。

新機能ブランチで環境構成を変更する

これでほとんどの環境が構成されました。次にローカル環境でコードを変更してみましょう。

GitHub で、フォークされたリポジトリのメインページに移動します。
```
https://github.com/YOUR_GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality
```
dev ブランチにいることを確認します。
編集するファイルを開くには、modules/deploy/dataplex.tf ファイルに移動します。
19 行目のラベル the_environment を environment に変更します。
「ラベルの変更」などの commit メッセージをページの下部に追加し、[この commit の新しいブランチを作成して pull リクエストを開始する] を選択します。
[Propose changes] をクリックします。
次のページで、[pull リクエストを作成する] をクリックして、dev ブランチに変更した新しい pull リクエストを開きます。

pull リクエストが開くと、Cloud Build ジョブが自動的に開始されます。
[Show all checks] をクリックし、チェックが緑色になるまで待ちます。pull リクエストはまだ統合しないでください。 統合はチュートリアルの後半のステップで行います。
[Details] をクリックして、[View more details on 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
```
リポジトリ名の下にある [設定] をクリックします。
左側のメニューで [Branches] をクリックします。
[Branch protection rules] で、[Add rule] をクリックします。
[Branch name pattern] に「dev」と入力します。
[Protect matching branches] セクションで、[Require status checks to pass before merging] を選択します。
以前に作成した Cloud Build トリガー名を検索します。
[作成] をクリックします。
手順 3～7 を繰り返し、[Branch name pattern] を prod に設定します。

この構成は、dev ブランチと prod ブランチの両方を保護するうえで重要です。つまり、commit を最初に別のブランチに push する必要があり、その後でのみ保護されたブランチにマージできます。このチュートリアルの保護では、マージを許可するために Cloud Build の実行が成功する必要があります。

開発環境の変更を促進する

マージされるのを待っている pull リクエストがあります。そこで、必要な状態を dev 環境に適用します。

GitHub で、フォークされたリポジトリのメインページに移動します。
```
https://github.com/YOUR_GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality
```
リポジトリ名の下で、[Pull requests] をクリックします。
作成した pull リクエストをクリックします。
[Merge pull request]、[Confirm merge] の順にクリックします。
新しい Cloud Build がトリガーされたことを確認します。

[Cloud Build] ページに移動する
ビルドを開き、ログを確認します。Terraform が作成および管理しているすべてのリソースが表示されます。

本番環境の変更をプロモートする

開発環境をすべてテストしたため、データ品質ルール用のコードを本番環境にプロモートさせることができます。

GitHub で、フォークされたリポジトリのメインページに移動します。
```
https://github.com/YOUR_GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality
```
リポジトリ名の下で、[Pull requests] をクリックします。
[New pull request] をクリックします。
ベースリポジトリの場合は、フォークされたリポジトリを選択します。
[base] に、独自のベースリポジトリから prod を選択します。[compare] に dev を選択します。
[Create pull request] をクリックします。
[title] には「Changing label name」などのタイトルを入力し、[Create pull request] をクリックします。
terraform plan の詳細を含む Cloud Build から提案された変更を確認し、[Merge pull request] をクリックします。
[Confirm merge] をクリックします。
Google Cloud コンソールで [ビルド履歴] ページを開き、本番環境に適用されている変更を確認します。

[Cloud Build] ページに移動する

Terraform と Cloud Build を使用して管理されるデータ品質ルールが正常に構成されました。

クリーンアップ

チュートリアルが終了したら、Google Cloud で作成したリソースをクリーンアップして今後料金が発生しないようにします。

プロジェクトの削除

注意: プロジェクトを削除すると、次のような影響があります。

プロジェクト内のすべてのものが削除されます。このドキュメントのタスクで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
カスタムプロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタムプロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

複数のアーキテクチャ、チュートリアル、クイックスタートを実施する予定がある場合は、プロジェクトを再利用すると、プロジェクトの割り当て上限を超えないようにすることができます。

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 で、フォークされたリポジトリのメインページに移動します。
リポジトリ名の下にある [設定] をクリックします。
左側のメニューで [Branches] をクリックします。
[Branch protection rules] セクションで、dev と prod の両方の行の [Delete] ボタンをクリックします。

必要に応じて、Cloud Build アプリは、GitHub から完全にアンインストールできます。

GitHub で、GitHub アプリケーションページに移動します。
[Installed GitHub Apps] タブで、[Cloud Build] 行の [Configure] をクリックします。次に、[Danger zone] セクションで、[Uninstall Google Cloud Builder] 行の [Uninstall] ボタンをクリックします。

ページの上部に「You're all set.A job has been queued to uninstall Google Cloud Build.」と表示されます。
[Authorized GitHub Apps] タブで、[Google Cloud Build] 行の [Revoke] ボタンをクリックし、[I understand, revoke access] をクリックします。

GitHub リポジトリを保持しない場合は、次のようにします。

GitHub で、フォークされたリポジトリのメインページに移動します。
リポジトリ名の下にある [設定] をクリックします。
[Danger Zone] に移動します。
[Delete this repository] をクリックし、確認手順に沿って操作します。

次のステップ

自動データ品質について学習する。
DevOps と DevOps のベストプラクティスについて学習する。
Cloud Foundation Toolkit で、その他の Terraform テンプレートを確認する。