このドキュメントでは、データ処理ワークフローに CI / CD パイプラインを使用するのアーキテクチャをデプロイする方法について説明します。
このデプロイは、繰り返し実行されるデータ処理ジョブを構築するデータ サイエンティストやアナリストを対象としており、研究開発(R&D)を構造化してデータ処理ワークロードを体系的かつ自動的に維持するのに役立ちます。
データ サイエンティストやアナリストは CI / CD の方法論を応用して、品質、保守性、適応性に優れたデータ処理とワークフローを実現できます。適用できる手法は次のとおりです。
- ソースコードのバージョン管理
- アプリの自動的なビルド、テスト、デプロイ
- 本番環境からの環境分離
- 環境設定のための複製可能な手順
アーキテクチャ
次の���は、テスト パイプラインと本番環境パイプラインの両方の CI / CD パイプライン ステップの詳細を示しています。
上の図では、デベロッパーがコードの変更を Cloud Source Repositories に commit するとテスト パイプラインが開始し、データ処理ワークフロー インテグレーション テストに合格するとテスト パイプラインが終了します。この時点で、パイプラインはメッセージを Pub/Sub に公開します。これには、メッセージのデータ フィールド内の最新の自己実行型 Java アーカイブ(JAR)ファイル(Airflow 変数から取得)への参照が含まれています。
上の図では、メッセージが Pub/Sub トピックに公開されると本番環境パイプラインが開始し、本番ワークフローの DAG ファイルが Cloud Composer にデプロイされると本番環境パイプラインが終了します。
このデプロイガイドでは、次の Google Cloud プロダクトを使用します。
- Cloud Build: データ処理ワークフローとデータ処理自体をビルド、デプロイ、テストする CI / CD パイプラインを作成します。Cloud Build は、Google Cloud 上でビルドを実行するマネージド サービスです。ビルドは、各ステップが Docker コンテナで実行される一連のビルドステップです。
- Cloud Composer: データ処理の開始、テスト、結果の検証など、ワークフローのステップを定義して実行します。Cloud Composer は、マネージド Apache Airflow サービスです。このサービスは、このデプロイメントのデータ処理ワークフローのような複雑なワークフローを作成、スケジュール設定、モニタリング、管理できる環境を提供します。
- Dataflow: サンプルデータ処理として Apache Beam WordCount の例を実行します。
目標
- Cloud Composer 環境を構成する。
- データ用の Cloud Storage バケットを作成する。
- ビルド、テスト、本番環境用のパイプラインを作成する。
- ビルドトリガーを構成する。
費用の最適化
このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。
始める前に
Google Cloud コンソールの [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを�����ま��は作成します。
Google Cloud プロジェクトの課金が有効になっていることを確認します。詳しくは、プロジェクトで課金が有効になっているかどうかを確認する方法をご覧ください。
サンプルコード
このデプロイのサンプルコードは、次の 2 つのフォルダにあります。
env-setup
フォルダには、Google Cloud 環境の初期設定用のシェル スクリプトが含まれています。source-code
フォルダには、時間の経過に伴って継続的に開発され、ソース管理が必要なコードが含まれています。このコードによってビルドとテストの自動的なプロセスがトリガーされます。このフォルダには次のサブフォルダが含まれます。data-processing-code
フォルダには、Apache Beam プロセスのソースコードが含まれています。workflow-dag
フォルダには、データ処理ワークフローの Composer DAG 定義が含まれています。この DAG 定義には、Dataflow プロセスを設計、実装、テストするステップが記述されています。build-pipeline
フォルダには 2 つの Cloud Build 構成が含まれています。1 つはテスト パイプライン用の構成であり、もう 1 つは本番環境パイプライン用の構成です。このフォルダには、これらのパイプラインのサポート スクリプトも含まれています。
このデプロイでは、データ処理用と DAG ワークフロー用のソースコード ファイルは、同じソースコード リポジトリ内の別のフォルダに格納されています。本番環境では、通常これらのソースコード ファイルは個別のソースコード リポジトリに格納され、別のチームによって管理されます。
統合テストと単体テスト
このデプロイには、データ処理ワークフローをエンドツーエンドで検証する統合テストのほかに、2 つの単体テストがあり���す。それは、データ処理コードとデータ処理ワークフロー コードの自動テストです。データ処理コードのテストは Java で記述されていて、Maven ビルドプロセス中に自動的に実行されます。データ処理ワークフロー コードのテストは Python で記述されていて、独立したビルドステップとして実行されます。
環境の設定
このデプロイでは、すべてのコマンドを Cloud Shell で実行します。Cloud Shell は、Google Cloud コンソールの下部にウィンドウとして表示されます。
Google Cloud コンソールで Cloud Shell を開きます。
サンプルコード リポジトリのクローンを作成します。
git clone https://github.com/GoogleCloudPlatform/ci-cd-for-data-processing-workflow.git
スクリプトを実行して環境変数を設定します。
cd ~/ci-cd-for-data-processing-workflow/env-setup source set_env.sh
このスクリプトでは次の環境変数を設定します。
- Google Cloud プロジェクト ID
- リージョンとゾーン
- ビルド パイプラインとデータ処理ワークフローで使用される Cloud Storage バケットの名前
環境変数はセッション間で保持されないため、このデプロイで Cloud Shell セッションがシャットダウンまたは切断された場合は、環境変数を再設定する必要があります。
Cloud Composer 環境を作成する
このデプロイでは、Cloud Composer 環境を作成します。
Cloud Shell で、Cloud Composer v2 API サービス エージェント拡張機能(
roles/composer.ServiceAgentV2Ext
)のロールを Cloud Composer サービス エージェント アカウントに追加します。gcloud projects add-iam-policy-binding $GCP_PROJECT_ID \ --member serviceAccount:service-$PROJECT_NUMBER@cloudcomposer-accounts.iam.gserviceaccount.com \ --role roles/composer.ServiceAgentV2Ext
Cloud Shell で Cloud Composer 環境を作成します。
gcloud composer environments create $COMPOSER_ENV_NAME \ --location $COMPOSER_REGION \ --image-version composer-2.0.14-airflow-2.2.5
スクリプトを実行して、Cloud Composer 環境の変数を設定します。これらの変数はデータ処理 DAG で必要になります。
cd ~/ci-cd-for-data-processing-workflow/env-setup chmod +x set_composer_variables.sh ./set_composer_variables.sh
このスクリプトでは次の環境変数を設定します。
- Google Cloud プロジェクト ID
- リージョンとゾーン
- ビルド パイプラインとデータ処理ワークフローで使用される Cloud Storage バケットの名前
Cloud Composer 環境プロパティを抽出する
Cloud Composer は、Cloud Storage バケットを使用して DAG を保存します。DAG 定義ファイルをバケットに移動すると、Cloud Composer の読み取りがトリガーされ、自動的にファイルが読み取られます。Cloud Composer 環境を作成したときに、Cloud Composer 用の Cloud Storage バケットを作成しました。次の手順で��、バケットの URL を抽出してから、DAG 定義を Cloud Storage バケットに自動的にデプロイするように CI / CD パイプラインを構成します。
Cloud Shell で、バケットの URL を環境変数としてエクスポートします。
export COMPOSER_DAG_BUCKET=$(gcloud composer environments describe $COMPOSER_ENV_NAME \ --location $COMPOSER_REGION \ --format="get(config.dagGcsPrefix)")
Cloud Storage バケットにアクセスできるようにするために、Cloud Composer が使用するサービス アカウントの名前をエクスポートします。
export COMPOSER_SERVICE_ACCOUNT=$(gcloud composer environments describe $COMPOSER_ENV_NAME \ --location $COMPOSER_REGION \ --format="get(config.nodeConfig.serviceAccount)")
Cloud Storage バケットを作成する
このセクションでは、次のデータを保存する一連の Cloud Storage バケットを作成します。
- ビルドプロセスの中間ステップのアーティファクト。
- データ処理ワークフローの入力ファイルと出力ファイル。
- Dataflow ジョブのバイナリ ファイルを保存するためのステージングの場所。
Cloud Storage バケットを作成するには、以下の手順を実施します。
Cloud Shell で Cloud Storage バケットを作成し、Cloud Composer サービス アカウントにデータ処理ワークフローを実行する権限を付与します。
cd ~/ci-cd-for-data-processing-workflow/env-setup chmod +x create_buckets.sh ./create_buckets.sh
Pub/Sub トピックを作成する
このセクションでは、本番環境ビルド パイプラインを自動的にトリガーするためにデータ処理ワークフロー統合テストから送信されたメッセージを受信する Pub/Sub トピックを作成します。
Google Cloud コンソールで、[Pub/Sub トピック] ページに移動します。
[トピックを作成] をクリックします。
トピックを構成する手順は、次のとおりです。
- [トピック ID] に「
integration-test-complete-topic
」と入力します。 - [デフォルトのサブスクリプションを追加する] オプションがオンになっていることを確認します。
- 残りのオプションはオフにしておきます。
- [暗号化] で、Google が管理する暗号鍵を選択します。
- [トピックを作成] をクリックします。
- [トピック ID] に「
Cloud Source Repositories にソースコードを push する
このデプロイでは、バージョン管理に組み込む必要があるソース コードベースが 1 つあります。次の手順は、コードベースが開発され、時間の経過とともに変更されていく様子を表しています。変更がリポジトリに push されるたびに、ビルド、デプロイ、テストのパイプラインがトリガーされます。
Cloud Shell で、
source-code
フォルダを Cloud Source Repositories に push します。gcloud source repos create $SOURCE_CODE_REPO cp -r ~/ci-cd-for-data-processing-workflow/source-code ~/$SOURCE_CODE_REPO cd ~/$SOURCE_CODE_REPO git init git remote add google \ https://source.developers.google.com/p/$GCP_PROJECT_ID/r/$SOURCE_CODE_REPO git add . git commit -m 'initial commit' git push google master
これらは、新しいディレクトリで Git を初期化し、コンテンツをリモート リポジトリに push する際の標準的なコマンドです。
Cloud Build パイプラインを作成する
このセクションでは、データ処理ワークフローをビルド、デプロイ、テストするビルド パイプラインを作成��ます。
Cloud Build サービス アカウントにアクセス権を付与する
Cloud Build は、Cloud Composer DAG をデプロイし、ワークフローをトリガーします。これは、Cloud Build サービス アカウントに追加のアクセス権を付与することによって可能になります。Cloud Composer で使用できるさまざまなロールの詳細については、アクセス制���の�������メントをご覧ください。
Cloud Build ジョブが Cloud Composer で Airflow 変数を設定できるように、Cloud Shell で Cloud Build サービス アカウントに
composer.admin
ロールを追加します。gcloud projects add-iam-policy-binding $GCP_PROJECT_ID \ --member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com \ --role=roles/composer.admin
Cloud Build ジョブが Cloud Composer でデ��タ ワークフローをトリガーできるように、Cloud Build サービス アカウントに
composer.worker
ロールを追加します。gcloud projects add-iam-policy-binding $GCP_PROJECT_ID \ --member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com \ --role=roles/composer.worker
ビルドとテストのパイプラインを作成する
ビルドとテストのパイプライン ステップは YAML 構成ファイルで構成します。このデプロイでは、git
、maven
、gcloud
のビルド済みビルダー イメージを使用して、各ビルドステップのタスクを実行します。ビルド時に環境設定を定義するには、構成変数の置換を使用します。ソースコード リポジトリの場所は、変数の置換と Cloud Storage バケットの場所によって定義されます。JAR ファイル、テストファイル、DAG 定義をデプロイするときに、この情報が必要になります。
Cloud Shell で、ビルド パイプラインの構成ファイルを送信して Cloud Build 内にパイプラインを作成します。
cd ~/ci-cd-for-data-processing-workflow/source-code/build-pipeline gcloud builds submit --config=build_deploy_test.yaml --substitutions=\ REPO_NAME=$SOURCE_CODE_REPO,\ _DATAFLOW_JAR_BUCKET=$DATAFLOW_JAR_BUCKET_TEST,\ _COMPOSER_INPUT_BUCKET=$INPUT_BUCKET_TEST,\ _COMPOSER_REF_BUCKET=$REF_BUCKET_TEST,\ _COMPOSER_DAG_BUCKET=$COMPOSER_DAG_BUCKET,\ _COMPOSER_ENV_NAME=$COMPOSER_ENV_NAME,\ _COMPOSER_REGION=$COMPOSER_REGION,\ _COMPOSER_DAG_NAME_TEST=$COMPOSER_DAG_NAME_TEST
このコマンドは、次の手順でビルドを実行するように Cloud Build に指示するものです。
WordCount の自己実行型 JAR ファイルをビルドしてデプロイします。
- ソースコードをチェックアウトします。
- WordCount Beam ソースコードを自己実行型 JAR ファイルにコンパイルします。
- この JAR ファイルを Cloud Storage に保存します。Cloud Composer はここからファイルを取得して WordCount 処理ジョブを実行できます。
データ処理ワークフローを Cloud Composer にデプロイして設定します。
- ワークフロー DAG で使用されるカスタム オペレータ コードの単体テストを実行します。
- テストの入力ファイルとテストの参照ファイルを Cloud Storage にデプロイします。テストの入力ファイルは、WordCount 処理ジョブへの入力になります。テストの参照ファイルは、WordCount 処理ジョブの出力を検証する際の参照として使用されます。
- 新しくビルドされた JAR ファイルを指すように Cloud Composer 変数を設定します。
- ワークフロー DAG 定義を Cloud Composer 環境にデプロイします。
テスト処理ワークフローをトリガーするには、テスト環境でデータ処理ワークフローを実行します。
ビルドとテストのパイプラインを検証する
ビルドファイルを送信したら、ビルドステップを検証します。
Google Cloud コンソールで [ビルド履歴] ページに移動し、過去および現在実行中のすべてのビルドの��ストを表示します。
実行中のビルドをクリックします。
[ビルドの詳細] ページで、そのビルドステップが上記のステップと一致していることを確認します。
[ビルドの詳細] ページで、ビルドが完了すると、ビルドの [ステータス] フィールドに「
Build successful
」と表示されます。Cloud Shell で、WordCount のサンプル JAR ファイルが正しいバケットにコピーされたことを確認します。
gcloud storage ls gs://$DATAFLOW_JAR_BUCKET_TEST/dataflow_deployment*.jar
出力は次のようになります。
gs://…-composer-dataflow-source-test/dataflow_deployment_e88be61e-50a6-4aa0-beac-38d75871757e.jar
Cloud Composer のウェブ インターフェースの URL を取得します。次の手順で使用するために、この URL をメモしておきます。
gcloud composer environments describe $COMPOSER_ENV_NAME \ --location $COMPOSER_REGION \ --format="get(config.airflowUri)"
前の手順の URL を使用して Cloud Composer UI に移動し、DAG が正しく実行されたことを確認します。[実行] 列に情報が表示されない場合は、数分待ってからページを再読み込みしてください。
データ処理ワークフロー DAG
test_word_count
がデプロイされて実行モードになっていることを確認するには、[実行] の下の薄い緑色の円にポインタを置き、「実行中」と表示されることを確認します。実行中のデータ処理ワークフローをグラフとして表示するには、薄い緑色の円をクリックし、[DAG 実行] ページで [Dag ID:
test_word_count
] をクリックします。現在の DAG の実行ステータスを更新するには、[グラフ表示] ページを再読み込みします。ワークフローが完了するまでに、通常 3~5 分かかります。DAG の実行が正常に終了したことを確認するには、ポインタを各タスクの上に置き、ツールチップに「状態: 成功」と表示されることを確認します。
do_comparison
という名前の最後から 2 番目のタスクは、参照ファイルに対してプロセスの出力を検証する統合テストです。
統合テストが完了すると、
publish_test_complete
という名前の最後のタスクでintegration-test-complete-topic
Pub/Sub トピックにメッセージが公開され、本番環境ビルド パイプラインがトリガーされます。公開されたメッセージに最新の JAR ファイルへの正しい参照が含まれていることを確認するには、デフォルトの
integration-test-complete-topic-sub
Pub/Sub サブスクリプションからメッセージを pull します。Google Cloud コンソールで、[サブスクリプション] ページに移動します。
[integration-test-complete-topic-sub] をクリックし、[メッセージ] タブを選択して [Pull] をクリックします。
出力例を以下に示します。
本番環境パイプラインを作成する
テスト処理ワークフローが正常に実行されたら、現在のバージョンのワークフローを本番環境に昇格させることができます。ワークフローを本番環境にデプロイするには、いくつかの方法があります。
- 手動。
- テスト環境��たはステージング環境ですべてのテストが正常に完了した場合に自動的にトリガーする。
- スケジュール設定されたジョブによって自動的にトリガーする。
このデプロイでは、すべてのテストでテスト環境が正常に完了すると本番環境ビルドが自動的にトリガーされます。自動アプローチの詳細については、リリース エンジニアリングをご覧ください。
自動アプローチを実装する前に、本番環境に手動でデプロイして、本番環境用デプロイメント ビルドを確認します。本番環境用デプロイメント ビルドは次の手順で実行します。
- テスト用バケットから本番環境用バケットに WordCount の JAR ファイルをコピーします。
- 本番環境用ワークフローの Cloud Composer 変数を設定して、新しく昇格する JAR ファイルを指すようにします。
- 本番環境用ワークフローの DAG 定義を Cloud Composer 環境にデプロイしてワークフローを実行します。
変数置換によって、本番環境にデプロイされる最新の JAR ファイルの名前が定義されます。本番環境の処理ワークフローで使用される Cloud Storage バケットに置換されます。本番環境用の Airflow ワークフローをデプロイする Cloud Build パイプラインを作成するには、以下の手順を実行します。
Cloud Shell で、JAR ファイル名の Cloud Composer 変数を出力して、最新の JAR ファイルのファイル名を読み取ります。
export DATAFLOW_JAR_FILE_LATEST=$(gcloud composer environments run $COMPOSER_ENV_NAME \ --location $COMPOSER_REGION variables get -- \ dataflow_jar_file_test 2>&1 | grep -i '.jar')
ビルド パイプライン構成ファイル
deploy_prod.yaml,
を使用して、Cloud Build でパイプラインを作成します。cd ~/ci-cd-for-data-processing-workflow/source-code/build-pipeline gcloud builds submit --config=deploy_prod.yaml --substitutions=\ REPO_NAME=$SOURCE_CODE_REPO,\ _DATAFLOW_JAR_BUCKET_TEST=$DATAFLOW_JAR_BUCKET_TEST,\ _DATAFLOW_JAR_FILE_LATEST=$DATAFLOW_JAR_FILE_LATEST,\ _DATAFLOW_JAR_BUCKET_PROD=$DATAFLOW_JAR_BUCKET_PROD,\ _COMPOSER_INPUT_BUCKET=$INPUT_BUCKET_PROD,\ _COMPOSER_ENV_NAME=$COMPOSER_ENV_NAME,\ _COMPOSER_REGION=$COMPOSER_REGION,\ _COMPOSER_DAG_BUCKET=$COMPOSER_DAG_BUCKET,\ _COMPOSER_DAG_NAME_PROD=$COMPOSER_DAG_NAME_PROD
本番環境パイプラインによって作成されたデータ処理ワークフローを検証する
Cloud Composer UI の URL を取得します。
gcloud composer environments describe $COMPOSER_ENV_NAME \ --location $COMPOSER_REGION \ --format="get(config.airflowUri)"
本番環境用データ処理ワークフロー DAG がデプロイされていることを確認するには、前の手順で取得した URL に移動し、
prod_word_count
DAG が DAG リストに含まれていることを確認します。- [DAG] ページの [
prod_word_count
] 行で、[DAG をトリガー] をクリックします。
- [DAG] ページの [
DAG の実行ステータスを更新するには、Airflow ロゴをクリックするか、ページを再読み込みします。[実行] 列の薄い緑色の円は、DAG が実行中であることを示します。
実行が完了したら、[DAG 実行] 列の下の濃い緑色の円にポインタを置き、「成功」と表示されることを確認します。
Cloud Shell で、Cloud Storage バケットの結果ファイルを一覧表示します。
gcloud storage ls gs://$RESULT_BUCKET_PROD
出力は次のようになります。
gs://…-composer-result-prod/output-00000-of-00003 gs://…-composer-result-prod/output-00001-of-00003 gs://…-composer-result-prod/output-00002-of-00003
Google Cloud Build トリガーを作成する
このセクションでは、ソースコードの変更をテスト ビルドプロセスにリンクし、テスト パイプラインと本番環境ビルド パイプラインの間にリンクする Cloud Build トリガーを作成します。
テストビルド パイプライン トリガーの構成
ソース リポジトリのマスター ブランチに変更が push されたときに新しいビルドをトリガーする Cloud Build トリガーを設定します。
Google Cloud コンソールで、[ビルドトリガー] ページに移動します。
[トリガーを作成] をクリックします。
トリガー設定を構成するには、以下の手順を実施します。
- [名前] フィールドに「
trigger-build-in-test-environment
」と入力します。 - [リージョン] プルダウンで、[グローバル(非リージョン)] を選択します。
- [イベント] で [ブランチに push する] をクリックします。
- [ソース] で [
data-pipeline-source
] を選択します。 - [ブランチ名] フィールドに「
master
」と入力します。 - [構成] の [Cloud Build 構成ファイル(yaml または json)] をクリックします。
- [ロケーション] で [リポジトリ] をクリックします。
- [Cloud Build 構成ファイルの場所] フィールドに「
build-pipeline/build_deploy_test.yaml
」と入力します。
- [名前] フィールドに「
Cloud Shell で次のコマンドを実行して、ビルドに必要なすべての置換変数を取得します。後の手順で必要になるため、この値をすべてメモしておきます。
echo "_COMPOSER_DAG_BUCKET : ${COMPOSER_DAG_BUCKET} _COMPOSER_DAG_NAME_TEST : ${COMPOSER_DAG_NAME_TEST} _COMPOSER_ENV_NAME : ${COMPOSER_ENV_NAME} _COMPOSER_INPUT_BUCKET : ${INPUT_BUCKET_TEST} _COMPOSER_REF_BUCKET : ${REF_BUCKET_TEST} _COMPOSER_REGION : ${COMPOSER_REGION} _DATAFLOW_JAR_BUCKET : ${DATAFLOW_JAR_BUCKET_TEST}"
[トリガー設定] ページの [高度な置換変数] で、変数を前の手順で取得した環境の値に置き換えます。次の値を一度に 1 つずつ追加して、名前と値のペアごとに [+ 項目を追加] をクリックします。
_COMPOSER_DAG_BUCKET
_COMPOSER_DAG_NAME_TEST
_COMPOSER_ENV_NAME
_COMPOSER_INPUT_BUCKET
_COMPOSER_REF_BUCKET
_COMPOSER_REGION
_DATAFLOW_JAR_BUCKET
[作成] をクリックします。
本番環境ビルド パイプライン トリガーの構成
テスト環境でテストに合格し、tests-complete
Pub/Sub トピックにメッセージが公開されたときに本番環境のビルドをトリガーする Cloud Build トリガーを設定します。このトリガーには、本番環境パイプラインを実行する前にビルドを手動で承認する必要がある承認の手順が含まれています。
Google Cloud コンソールで、[ビルドトリガー] ページに移動します。
[トリガーを作成] をクリックします。
トリガー設定を構成するには、以下の手順を実施します。
- [名前] フィールドに「
trigger-build-in-prod-environment
」と入力します。 - [リージョン] プルダウンで、[グローバル(非リージョン)] を選択します。
- [イベント] で [Pub/Sub メッセージ] をクリックします。
- [サブスクリプション] で [integration-test-complete-topic] を選択します。
- [ソース] で [
data-pipeline-source
] を選択します。 - [リビジョン] で [ブランチ] を選択します。
- [ブランチ名] フィールドに「
master
」と入力します。 - [構成] の [Cloud Build 構成ファイル(yaml または json)] をクリックします。
- [ロケーション] で [リポジトリ] をクリックします。
- [Cloud Build 構成ファイルの場所] フィールドに「
build-pipeline/deploy_prod.yaml
」と入力します。
- [名前] フィールドに「
Cloud Shell で次のコマンドを実行して、ビルドに必要なすべての置換変数を取得します。後の手順で必要になるため、この値をすべてメモしておきます。
echo "_COMPOSER_DAG_BUCKET : ${COMPOSER_DAG_BUCKET} _COMPOSER_DAG_NAME_PROD : ${COMPOSER_DAG_NAME_PROD} _COMPOSER_ENV_NAME : ${COMPOSER_ENV_NAME} _COMPOSER_INPUT_BUCKET : ${INPUT_BUCKET_PROD} _COMPOSER_REGION : ${COMPOSER_REGION} _DATAFLOW_JAR_BUCKET_PROD : ${DATAFLOW_JAR_BUCKET_PROD} _DATAFLOW_JAR_BUCKET_TEST : ${DATAFLOW_JAR_BUCKET_TEST}"
[トリガー設定] ページの [高度な置換変数] で、変数を前の手順で取得した環境の値に置き換えます。次の値を一度に 1 つずつ追加して、名前と値のペアごとに [+ 項目を追加] をクリックします。
_COMPOSER_DAG_BUCKET
_COMPOSER_DAG_NAME_PROD
_COMPOSER_ENV_NAME
_COMPOSER_INPUT_BUCKET
_COMPOSER_REGION
_DATAFLOW_JAR_BUCKET_PROD
_DATAFLOW_JAR_BUCKET_TEST
_DATAFLOW_JAR_FILE_LATEST = $(body.message.data)
[承認] で [ビルドを実行する前に承認を必要とする] をオンにします。
[作成] をクリックします。
トリガーをテストする
トリガーをテストするには、テスト入力ファイルに新しい単語を追加し、それに合わせてテスト参照ファイルも調整します。Cloud Source Repositories への commit push によってビルド パイプラインがトリガーされ、更新されたテストファイルを使用してデータ処理ワークフローが正しく実行されることを確認します。
Cloud Shell で、テストファイルの末尾にテスト用の単語を追加します。
echo "testword" >> ~/$SOURCE_CODE_REPO/workflow-dag/support-files/input.txt
テスト入力ファイルで行った変更に合わせて、テスト結果の参照ファイル
ref.txt
を更新します。echo "testword: 1" >> ~/$SOURCE_CODE_REPO/workflow-dag/support-files/ref.txt
変更を commit して Cloud Source Repositories に push します。
cd ~/$SOURCE_CODE_REPO git add . git commit -m 'change in test files' git push google master
Google Cloud コンソールで [履歴] ページに移動します。
マスター ブランチへの以前の push によって新しいテストビルドがトリガーされたことを確認するには、現在実行中のビルドで [Ref] 列に [master] と表示されていることを確認します。
Cloud Shell で、Cloud Composer のウェブ インターフェースの URL を取得します。
gcloud composer environments describe $COMPOSER_ENV_NAME \ --location $COMPOSER_REGION --format="get(config.airflowUri)"
ビルドが完了したら、前のコマンドの URL に移動して、
test_word_count
DAG が実行されていることを確認します。DAG の実行が完了するまで待ちます。完了すると、[DAG 実行] 列の薄い緑色の円が消えます。プロセスが完了するまでに通常 3~5 分かかります。
Cloud Shell でテスト結果ファイルをダウンロードします。
mkdir ~/result-download cd ~/result-download gcloud storage cp gs://$RESULT_BUCKET_TEST/output* .
新しく追加した単語が結果ファイルのいずれかに含まれていることを確認します。
grep testword output*
出力は次のようになります。
output-00000-of-00003:testword: 1
Google Cloud コンソールで [履歴] ページに移動します。
統合テストの完了によって新しい本番環境ビルドがトリガーされ、ビルドが承認待ちであることを確認します。
本番環境のビルド パイプラインを実行するには、ビルドの横にあるチェックボックスをオンにして、[承認] をクリックし、確認ボックスの [承認] をクリックします。
ビルドが完了したら、前のコマンドの URL に移動し、
prod_word_count
DAG を手動でトリガーして本番環境パイプラインを実行します。
クリーンアップ
以降のセクションでは、このデプロイで使用した Google Cloud プロジェクトと Apache Hive および Dataproc リソースについて、今後料金が発生しないようにする方法について説明します。
Google Cloud プロジェクトを削除する
このデプロイで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、Google Cloud プロジェクトを削除します。
- In the Google Cloud console, go to the Manage resources page.
- 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.
個々のリソースを削除する
このデプロイに使用したプロジェクトを保持するには、次の手順で作成したリソースを削除します。
Cloud Build トリガーを削除するには、次の手順を実施します。
Google Cloud コンソールで [トリガー] ページに移動します。
作成したトリガーの横にある [さらに表示] more_vert をクリックし、[削除] をクリックします。
Cloud Shell で Cloud Composer 環境を削除します。
gcloud -q composer environments delete $COMPOSER_ENV_NAME \ --location $COMPOSER_REGION
Cloud Storage バケットとそのファイルを削除します。
gcloud storage rm gs://$DATAFLOW_JAR_BUCKET_TEST \ gs://$INPUT_BUCKET_TEST \ gs://$REF_BUCKET_TEST \ gs://$RESULT_BUCKET_TEST \ gs://$DATAFLOW_STAGING_BUCKET_TEST \ gs://$DATAFLOW_JAR_BUCKET_PROD \ gs://$INPUT_BUCKET_PROD \ gs://$RESULT_BUCKET_PROD \ gs://$DATAFLOW_STAGING_BUCKET_PROD \ --recursive
Pub/Sub トピックとデフォルトのサブスクリプションを削除するには、Cloud Shell で次のコマンドを実行します。
gcloud pubsub topics delete integration-test-complete-topic gcloud pubsub subscriptions delete integration-test-complete-topic-sub
リポジトリを削除します。
gcloud -q source repos delete $SOURCE_CODE_REPO
作成したファイルとフォルダを削除します。
rm -rf ~/ci-cd-for-data-processing-workflow rm -rf ~/$SOURCE_CODE_REPO rm -rf ~/result-download
次のステップ
- Cloud Build を使用した GitOps スタイルの継続的デリバリーの詳細を見る。
- データ処理ワークフローに CI/CD パイプラインを使用する方法を学ぶ。
- 一般的な Dataflow のユースケース パターンの詳細を確認する。
- リリース エンジニアリングの詳細を見る。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。