概要

このラボでは、Google Cloud のマネージド プロダクトを使用して継続的インテグレーション / 継続的デプロイ（CI / CD）の手法を実装し、データ処理用の CI / CD パイプラインを設定します。データ サイエンティストやエンジニアは、CI / CD の方法論を応用して、品質、保守性、適応性に優れたデータ処理とワークフローを実現できます。適用できる手法は次のとおりです。

• ソースコードのバージョン管理
• アプリの自動的なビルド、テスト、デプロイ
• 本番環境からの環境分離
• 環境設定のための複製可能な手順

デプロイ アーキテクチャ

このラボでは、次の Google Cloud プロダクトを使用します。

• Cloud Build: データ処理ワークフローとデータ処理自体をビルド、デプロイ、テストする CI / CD パイプラインを作成します。Cloud Build は、Google Cloud 上でビルドを実行するマネージド サービスです。ビルドは、各ステップが Docker コンテナで実行される一連のビルドステップです。
• Cloud Composer: データ処理の開始、テスト、結果の検証など、ワークフローのステップを定義して実行します。Cloud Composer は、マネージド Apache Airflow サービスです。このサービスは、本ラボのデータ処理ワークフローのような複雑なワークフローを作成、スケジュール設定、モニタリング、管理できる環境を提供します。
• Dataflow: サンプルデータ処理として Apache Beam WordCount の例を実行します。

設定と要件

各ラボでは、新しい Google Cloud プロジェクトとリソースセットを一定時間無料で利用できます。

1. [ラボを開始] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるポップアップでお支払い方法を選択してください。 左側の [ラボの詳細] パネルには、以下が表示されます。

   • [Google Cloud コンソールを開く] ボタン
   • 残り時間
   • このラボで使用する必要がある一時的な認証情報
   • このラボを行うために必要なその他の情報（ある場合）

2. [Google Cloud コンソールを開く] をクリックします（Chrome ブラウザを使用している場合は、右クリックして [シークレット ウィンドウで開く] を選択します）。

   ラボでリソースが起動し、別のタブで [ログイン] ページが表示されます。

   ヒント: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。

   注: [アカウントの選択] ダイアログが表示されたら、[別のアカウントを使用] をクリックします。

3. 必要に応じて、下のユーザー名をコピーして、[ログイン] ダイアログに貼り付けます。

   {{{user_0.username | "Username"}}}

   [ラボの詳細] パネルでもユーザー名を確認できます。

4. [次へ] をクリックします。

5. 以下のパスワードをコピーして、[ようこそ] ダイアログに貼り付けます。

   {{{user_0.password | "Password"}}}

   [ラボの詳細] パネルでもパスワードを確認できます。

6. [次へ] をクリックします。

   重要: ラボで提供された認証情報を使用する必要があります。Google Cloud アカウントの認証情報は使用しないでください。 注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。

7. その後次のように進みます。

   • 利用規約に同意してください。
   • 一時的なアカウントなので、復元オプションや 2 要素認証プロセスは設定しないでください。
   • 無料トライアルには登録しないでください。

その後、このタブで Google Cloud コンソールが開きます。

注: Google Cloud のプロダクトやサービスのリストを含むメニューを表示するには、左上のナビゲーション メニューをクリックするか、[検索] フィールドにサービス名またはプロダクト名を入力します。

Google Cloud Shell の有効化

Google Cloud Shell は、開発ツールと一緒に読み込まれる仮想マシンです。5 GB の永続ホーム ディレクトリが用意されており、Google Cloud で稼働します。

Google Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。

1. Google Cloud コンソールで、右上のツールバーにある [Cloud Shell をアクティブにする] ボタンをクリックします。

   

2. [続行] をクリックします。

環境がプロビジョニングされ、接続されるまでしばらく待ちます。接続した時点で認証が完了しており、プロジェクトに各自のプロジェクト ID が設定されます。次に例を示します。

gcloud は Google Cloud のコマンドライン ツールです。このツールは、Cloud Shell にプリインストールされており、タブ補完がサポートされています。

• 次のコマンドを使用すると、有効なアカウント名を一覧表示できます。

gcloud auth list

出力:

Credentialed accounts: - @.com (active)

出力例:

Credentialed accounts: - google1623327_student@qwiklabs.net

• 次のコマンドを使用すると、プロジェクト ID を一覧表示できます。

gcloud config list project

出力:

[core] project =

出力例:

[core] project = qwiklabs-gcp-44776a13dea667a6 注: gcloud ドキュメントの全文については、 gcloud CLI の概要ガイド をご覧ください。

CI / CD パイプライン

大まかに言えば、CI / CD パイプラインは次のステップで構成されます。

1. Cloud Build が Maven ビルダーを使用して WordCount サンプルを自己実行型の Java アーカイブ（JAR）ファイルにパッケージ化します。Maven ビルダーは、Maven がインストールされているコンテナです。Maven ビルダーを使用するようにビルドステップが構成されている場合、Maven がタスクを実行します。
2. Cloud Build が JAR ファイルを Cloud Storage にアップロードします。
3. Cloud Build がデータ処理ワークフロー コードの単体テストを実行し、そのワークフロー コードを Cloud Composer にデプロイします。
4. Cloud Composer が JAR ファイルを受け取り、Dataflow 上でデータ処理ジョブを実行します。

次の図に、CI / CD パイプライン ステップの詳細を示します。

このラボでは、テスト環境と本番環境へのデプロイが 2 つの異なる Cloud Build パイプライン（テスト パイプラインと本番環境パイプライン）に分かれています。

上の図では、テスト パイプラインは以下のステップで構成されています。

1. 開発者がコードの変更を Cloud Source Repositories に commit します。
2. コードの変更によって Cloud Build でテストビルドがトリガーされます。
3. Cloud Build が自己実行型 JAR ファイルをビルドし、それを Cloud Storage のテスト用 JAR バケットにデプロイします。
4. Cloud Build がテストファイルを Cloud Storage のテストファイル バケットにデプロイします。
5. Cloud Build が、新しくデプロイされた JAR ファイルを参照するように Cloud Composer の変数を設定します。
6. Cloud Build が、データ処理ワークフローの有向非巡回グラフ（DAG）をテストし、Cloud Storage の Cloud Composer バケットにデプロイします。
7. このワークフローの DAG ファイルが Cloud Composer にデプロイされます。
8. Cloud Build が、新しくデプロイされたデータ処理ワークフローの実行をトリガーします。

環境を完全に分離するには、異なるプロジェクト内に作成された複数の Cloud Composer 環境が必要です。このようにして作成された環境はデフォルトで分離され、本番環境を保護するのに役立ちます。ただし、このアプローチは本ラボの対象範囲外です。複数の Google Cloud プロジェクトのリソースにアクセスする方法の詳細については、サービス アカウント権限の設定をご覧ください。

データ処理ワークフロー

Cloud Composer がデータ処理ワークフローを実行する手順は、Python で書かれた有向非巡回グラフ（DAG）で定義されます。DAG では、データ処理ワークフローのすべてのステップが、それぞれの依存関係とともに定義されます。

CI / CD パイプラインは毎回のビルドの中で、DAG 定義を Cloud Source Repositories から Cloud Composer に自動的にデプロイします。このプロセスにより、Cloud Composer のワークフロー定義は人の手を介さなくても常に最新の状態に保たれます。

テスト環境用の DAG 定義では、データ処理ワークフローに加えてエンドツーエンドのテストステップが定義されています。テストステップは、データ処理ワークフローが正しく実行されることを確認するのに役立ちます。

次の図に、データ処理ワークフローを示します。

データ処理ワークフローは次のステップで構成されます。

1. Dataflow で WordCount データ処理を実行します。

2. WordCount プロセスの出力ファイルをダウンロードします。WordCount プロセスは次の 3 つのファイルを出力します。

   • download_result_1
   • download_result_2
   • download_result_3

3. download_ref_string という名前の参照ファイルをダウンロードします。

4. この参照ファイルと照らし合わせて結果を検証します。この統合テストでは、3 つの結果すべてを集計して、集計結果を参照ファイルと比較します。

Cloud Composer などのタスク オーケストレーション フレームワークを使用してデータ処理ワークフローを管理すると、ワークフローのコードの複雑さを軽減できます。

テスト

このラボには、データ処理ワークフローをエンドツーエンドで検証する統合テストのほかに、2 つの単体テストがあります。それは、データ処理コードとデータ処理ワークフロー コードの自動テストです。データ処理コードのテストは Java で記述されていて、Maven ビルドプロセス中に自動的に実行されます。データ処理ワークフロー コードのテストは Python で記述されていて、独立したビルドステップとして実行されます。

サンプルコード

サンプルコードは次の 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 ワークフロー用のソースコード ファイルは、同じソースコード リポジトリ内の別のフォルダに格納されています。本番環境では、通常これらのソースコード ファイルは個別のソースコード リポジトリに格納され、別のチームによって管理されます。

タスク 1. 環境設定

このラボでは、すべてのコマンドを Cloud Shell で実行します。Cloud Shell は、Google Cloud コンソールの下部にウィンドウとして表示されます。

1. Cloud コンソールで Cloud Shell を開きます。

2. サンプルコード リポジトリのクローンを作成します。

   git clone https://github.com/GoogleCloudPlatform/ci-cd-for-data-processing-workflow.git

3. このラボのサンプル ファイルが含まれているディレクトリに移動します。

   cd ~/ci-cd-for-data-processing-workflow/env-setup

4. sed コマンドを使用して、set_env.sh ファイル内のリージョンを更新します。

   sed -i "s/us-central1-a/{{{project_0.default_zone|Zone}}}/g" set_env.sh sed -i "s/us-central1/{{{project_0.default_region|Region}}}/g" set_env.sh

5. スクリプトを実行して環境変数を設定します。

   source set_env.sh

   このスクリプトでは次の環境変数を設定します。

   • Google Cloud プロジェクト ID
   • リージョンとゾーン
   • ビルド パイプラインとデータ処理ワークフローで使用される Cloud Storage バケットの名前

   環境変数はセッション間で保持されないため、ラボを進めている間に Cloud Shell セッションがシャットダウンまたは切断された場合は、環境変数を再設定する必要があります。

6. yaml ファイルにロギング オプションを追加します。

   echo -e "\noptions:\n logging: CLOUD_LOGGING_ONLY" >> ~/ci-cd-for-data-processing-workflow/source-code/build-pipeline/build_deploy_test.yaml

7. パイプライン スクリプトを更新します。

   sed -i 's/project=project/project_id=project/' ~/ci-cd-for-data-processing-workflow/source-code/workflow-dag/data-pipeline-test.py

タスク 2. Cloud Composer 環境を作成する

Cloud Composer API が有効になっていることを確認する

必要な API にアクセスできることを確認するには、Cloud Composer API への接続を再起動します。

1. Google Cloud コンソール上部の検索バーに「Cloud Composer API」と入力し、検索結果の「Cloud Composer API」をクリックします。

2. [管理] をクリックします。

3. [API を無効にする] をクリックします。

確認を求められたら、[無効にする] をクリックします。

4. [有効にする] をクリックします。

API が再度有効になると、ページに無効にするオプションが表示されます。

Cloud Composer 環境を作成する

1. Cloud Shell で次のコマンドを実行して Cloud Composer 環境を作成します。

   gcloud composer environments create $COMPOSER_ENV_NAME \ --location $COMPOSER_REGION \ --image-version composer-3-airflow-2

注: コマンドを実行してから Cloud Composer の作成が完了するまで、通常は 15 分ほどかかります。Composer の準備が完了するまで待ってから続行してください。

コマンドが完了したら、Google Cloud で確認します。

2. スクリプトを実行して、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 パイプラインを構成します。

1. Cloud Shell で、バケットの URL を環境変数としてエクスポートします。

   export COMPOSER_DAG_BUCKET=$(gcloud composer environments describe $COMPOSER_ENV_NAME \ --location $COMPOSER_REGION \ --format="get(config.dagGcsPrefix)")

2. Cloud Storage バケットにアクセスできるようにするために、Cloud Composer が使用するサービス アカウントの名前をエクスポートします。

   export COMPOSER_SERVICE_ACCOUNT=$(gcloud composer environments describe $COMPOSER_ENV_NAME \ --location $COMPOSER_REGION \ --format="get(config.nodeConfig.serviceAccount)")

タスク 3. 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

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 Cloud Storage バケットを作成する

タスク 4. 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 config --global credential.'https://source.developers.google.com'.helper gcloud.sh git config --global user.email $(gcloud config list --format 'value(core.account)') git config --global user.name $(gcloud config list --format 'value(core.account)') 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 Source Repositories にソースコードを push する

タスク 5. Cloud Build パイプラインを作成する

このセクションでは、データ処理ワークフローをビルド、デプロイ、テストするビルド パイプラインを作成します。

ビルドとテストのパイプラインを作成する

ビルドとテストのパイプライン ステップは YAML 構成ファイルで構成します。このラボでは、事前ビルド済みの git、maven、gsutil、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 に指示するものです。

  1. WordCount の自己実行型 JAR ファイルをビルドしてデプロイします。

     • ソースコードをチェックアウトします。
     • WordCount Beam ソースコードを自己実行型 JAR ファイルにコンパイルします。
     • この JAR ファイルを Cloud Storage に保存します。Cloud Composer はここからファイルを取得して WordCount 処理ジョブを実行できます。

  2. データ処理ワークフローを Cloud Composer にデプロイして設定します。

     • ワークフロー DAG で使用されるカスタム オペレータ コードの単体テストを実行します。
     • テストの入力ファイルとテストの参照ファイルを Cloud Storage にデプロイします。テストの入力ファイルは、WordCount 処理ジョブへの入力になります。テストの参照ファイルは、WordCount 処理ジョブの出力を検証する際の参照として使用されます。
     • 新しくビルドされた JAR ファイルを指すように Cloud Composer 変数を設定します。
     • ワークフロー DAG 定義を Cloud Composer 環境にデプロイします。

  3. テスト環境でデータ処理ワークフローを実行し、テスト処理ワークフローをトリガーします。

ビルドとテストのパイプラインを検証する

ビルドファイルを送信したら、ビルドステップを検証します。

1. Cloud コンソールで [ビルド履歴] ページに移動し、過去および現在実行中のすべてのビルドのリストを表示します。

2. 現在実行中のビルドをクリックします。

3. [ビルドの詳細] ページで、そのビルドステップが上記のステップと一致していることを確認します。

   

   ビルドが完了すると、[ビルドの詳細] ページの [ステータス] フィールドに「Build successful」と表示されます。

   注: ビルドに失敗した場合は、もう一度ビルドを実行してください。

4. Cloud Shell で、WordCount のサンプル JAR ファイルが正しいバケットにコピーされたことを確認します。

   gsutil ls gs://$DATAFLOW_JAR_BUCKET_TEST/dataflow_deployment*.jar

   出力は次のようになります。

   gs://…-composer-dataflow-source-test/dataflow_deployment_e88be61e-50a6-4aa0-beac-38d75871757e.jar

5. Cloud Composer のウェブ インターフェースの URL を取得します。次の手順で使用するために、この URL をメモしておきます。

   gcloud composer environments describe $COMPOSER_ENV_NAME \ --location $COMPOSER_REGION \ --format="get(config.airflowUri)"

6. 前の手順の URL を使用して Cloud Composer UI に移動し、DAG が正しく実行されたことを確認します。Composer のページで [Airflow ウェブサーバー] リンクをクリックして移動することもできます。[DAG Runs] 列に情報が表示されない場合は、数分待ってからページを再読み込みしてください。

7. データ処理ワークフロー DAG test_word_count がデプロイされて実行モードになっていることを確認するには、[DAG Runs] の下の薄い緑色の円にポインタを置き、「実行中」と表示されることを確認します。

   

8. 実行中のデータ処理ワークフローをグラフとして表示するには、薄い緑色の円をクリックし、[Dag Runs] ページで [Dag Id: test_word_count] をクリックします。

9. 現在の DAG の実行ステータスを更新するには、[グラフ表示] ページを再読み込みします。ワークフローが完了するまでに、通常 3〜5 分かかります。DAG の実行が正常に終了したことを確認するには、ポインタを各タスクの上に置き、ツールチップに「State: success」と表示されることを確認します。最後のタスク do_comparison は、プロセスの出力を参照ファイルと照らし合わせて検証する統合テストです。

注: test_word_count DAG の do_comparison タスクまたは publish_test_complete タスクのいずれかのステータスが Failed になっている場合、これらのタスクの問題は無視してください。

DAG の実行に失敗した場合は、以下の手順を使用して別の DAG 実行をトリガーしてください。

1. [DAG] ページの test_word_count 行で、[DAG をトリガー] をクリックします。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 Cloud Build パイプラインを作成する

本番環境パイプラインを作成する

テスト処理ワークフローが正常に実行されたら、現在のバージョンのワークフローを本番環境に昇格させることができます。ワークフローを本番環境にデプロイするには、いくつかの方法があります。

• 手動。
• テスト環境またはステージング環境ですべてのテストが正常に完了した場合に自動的にトリガーする。
• スケジュール設定されたジョブによって自動的にトリガーする。

自動アプローチはこのラボの対象範囲外です。詳細については、リリース エンジニアリングをご覧ください。

このラボでは、Cloud Build の本番環境用デプロイメント ビルドを実行して本番環境に手動でデプロイします。本番環境用デプロイメント ビルドは次の手順で実行します。

1. テスト用バケットから本番環境用バケットに WordCount の JAR ファイルをコピーします。
2. 本番環境用ワークフローの Cloud Composer 変数を設定して、新しく昇格する JAR ファイルを指すようにします。
3. 本番環境用ワークフローの DAG 定義を Cloud Composer 環境にデプロイしてワークフローを実行します。

変数置換によって、本番環境にデプロイされる最新の JAR ファイルの名前が定義されます。本番環境の処理ワークフローで使用される Cloud Storage バケットに置換されます。本番環境用の Airflow ワークフローをデプロイする Cloud Build パイプラインを作成するには、以下の手順を実行します。

4. 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 | grep -i '.jar')

5. ビルド パイプラインの構成ファイル 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

本番環境パイプラインによって作成されたデータ処理ワークフローを検証する

1. Cloud Composer UI の URL を取得します。

   gcloud composer environments describe $COMPOSER_ENV_NAME \ --location $COMPOSER_REGION \ --format="get(config.airflowUri)"

2. 本番環境用データ処理ワークフロー DAG がデプロイされていることを確認するには、前の手順で取得した URL に移動し、prod_word_count DAG が DAG リストに含まれていることを確認します。

3. [DAGs] ページの prod_word_count 行で、[DAG をトリガー] をクリックします。

   

4. DAG の実行ステータスを更新するには、ページを再読み込みします。本番環境用データ処理ワークフロー DAG がデプロイされ実行モードになっていることを確認するには、[DAG Runs] の下の薄い緑色の円にポインタを置き、「実行中」と表示されることを確認します。

   

5. 実行が完了したら、[DAG Runs] 列の下の濃い緑色の円にポインタを置き、「成功」と表示されることを確認します。

6. Cloud Shell で、Cloud Storage バケットの結果ファイルを一覧表示します。

   gsutil 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

注: 通常、本番環境でのデータ ワークフロー ジョブの実行は、ファイルがバケットに保存されるなどのイベントによってトリガーされるか、定期的に実行するようにスケジュール設定されます。デプロイの前に、本番環境用データ ワークフローが実行中でないことをデプロイジョブで確認することが重要です。

本番環境では、Airflow CLI コマンドの dags を使用して DAG 実行のステータスを取得できます。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 本番環境パイプラインを作成する

タスク 6. ビルドトリガーを構成する

ソース リポジトリのマスター ブランチに変更が push されたときに新しいビルドをトリガーする Cloud Build トリガーを設定します。

1. Cloud Shell で次のコマンドを実行して、ビルドに必要なすべての置換変数を取得します。後の手順で必要になるため、この値をすべてメモしておきます。

   echo "_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}"

2. Cloud コンソールで、[ビルドトリガー] ページに移動します（[ビルドトリガー] ページ）。

3. [トリガーを作成] をクリックします。

4. トリガー設定を構成するには、以下の手順を実施します。

   • [名前] フィールドに「Trigger build in test environment」と入力します。
   • [イベント] で [ブランチに push する] をクリックします。
   • data-pipeline-source (Cloud Source Repositories) には [リポジトリ] を選択します。
   • [ブランチ] フィールドでは ^master$ を選択します。
   • [構成] の [Cloud Build 構成ファイル（yaml または json）] をクリックします。
   • [Cloud Build 構成ファイルの場所] フィールドに「build-pipeline/build_deploy_test.yaml」と入力します。

5. [詳細設定] フィールドで、変数を前のステップで環境から取得した値に置き換えます。次の値を一度に 1 つずつ追加して、名前と値のペアごとに [+ 変数を追加] をクリックします。

   • _DATAFLOW_JAR_BUCKET

   • _COMPOSER_INPUT_BUCKET

   • _COMPOSER_REF_BUCKET

   • _COMPOSER_DAG_BUCKET

   • _COMPOSER_ENV_NAME

   • _COMPOSER_REGION

   • _COMPOSER_DAG_NAME_TEST

     

6. [サービス アカウント] で、[xxxxxxx-compute@developer.gserviceaccount.com] を選択します。

7. [作成] をクリックします。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 ビルドトリガーを構成する

トリガーをテストする

トリガーをテストするには、テスト入力ファイルに新しい単語を追加し、それに合わせてテスト参照ファイルも調整します。Cloud Source Repositories への commit push によってビルド パイプラインがトリガーされ、更新されたテストファイルを使用してデータ処理ワークフローが正しく実行されることを確認します。

1. Cloud Shell で、テストファイルの末尾にテスト用の単語を追加します。

   echo "testword" >> ~/$SOURCE_CODE_REPO/workflow-dag/support-files/input.txt

2. テスト入力ファイルで行った変更に合わせて、テスト結果の参照ファイル ref.txt を更新します。

   echo "testword: 1" >> ~/$SOURCE_CODE_REPO/workflow-dag/support-files/ref.txt

3. 変更を commit して Cloud Source Repositories に push します。

   cd ~/$SOURCE_CODE_REPO git add . git commit -m 'change in test files' git push google master

4. Cloud コンソールで、[履歴] ページに移動します（[履歴] ページ）。

5. マスター ブランチへの以前の push によって新しいビルドがトリガーされたことを確認するには、現在実行中のビルドで [トリガー] 列に [マスター ブランチへの push] と表示されていることを確認します。

6. Cloud Shell で、Cloud Composer のウェブ インターフェースの URL を取得します。

   gcloud composer environments describe $COMPOSER_ENV_NAME \ --location $COMPOSER_REGION --format="get(config.airflowUri)"

7. ビルドが完了したら、前のコマンドで取得した URL に移動し、test_word_count DAG が実行されていることを確認します。

   DAG の実行が完了するまで待ちます。完了すると、[DAG runs] 列の薄い緑色の円が消えます。プロセスが完了するまでに通常 3～5 分かかります。

   注: test_word_count DAG の do_comparison タスクの問題は無視してください。

8. Cloud Shell でテスト結果ファイルをダウンロードします。

   mkdir ~/result-download cd ~/result-download gsutil cp gs://$RESULT_BUCKET_TEST/output* .

9. 新しく追加した単語が結果ファイルのいずれかに含まれていることを確認します。

   grep testword output*

   出力は次のようになります。

   output-00000-of-00003:testword: 1

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 トリガーをテストする

お疲れさまでした

• Cloud Build を使用した GitOps スタイルの継続的デリバリーの詳細を見る。
• Cloud Composer を使用したインフラストラクチャの自動化の詳細を見る。
• 一般的な Dataflow のユースケース パターンの詳細を確認する。
• リリース エンジニアリングの詳細を見る。

ラボを終了する

ラボが完了したら、[ラボを終了] をクリックします。ラボで使用したリソースが Google Cloud Skills Boost から削除され、アカウントの情報も消去されます。

ラボの評価を求めるダイアログが表示されたら、星の数を選択してコメントを入力し、[送信] をクリックします。

星の数は、それぞれ次の評価を表します。

• 星 1 つ = 非常に不満
• 星 2 つ = 不満
• 星 3 つ = どちらともいえない
• 星 4 つ = 満足
• 星 5 つ = 非常に満足

フィードバックを送信しない場合は、ダイアログ ボックスを閉じてください。

フィードバックやご提案の送信、修正が必要な箇所をご報告いただく際は、[サポート] タブをご利用ください。

Copyright 2020 Google LLC All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。