Dataflow でのカスタム コンテナの使用

このページでは、カスタム コンテナ イメージを提供して、Dataflow パイプラインの Python ユーザーコードのランタイム環境をカスタマイズする方法について説明します。カスタム コンテナは、Dataflow Runner v2 を使用したポータブル パイプラインでのみサポートされます。

Dataflow がワーカー VM を起動すると、Docker コンテナ イメージが使用されます。デフォルトの Apache Beam イメージのいずれかを使用する代わりに、カスタム コンテナ イメージを指定できます。カスタム コンテナ イメージを指定すると、Dataflow は指定されたイメージを pull するワーカーを起動します。カスタム コンテナを使用する理由は次のとおりです。

  • ワーカーの起動時間を短縮するために、パイプラインの依存関係をプリインストールする。
  • パブリック リポジトリでは使用できないパイプラインの依存関係をプリインストールする。
  • サードパーティ ソフトウェアをバックグラウンドで起動する。
  • 実行環境をカスタマイズする。

カスタム コンテナの詳細については、Apache Beam カスタム コンテナ ガイドをご覧ください。

始める前に

Apache Beam SDK バージョン 2.25.0 以降がインストールされていることを確認します。この Apache Beam SDK バージョンが Python のバージョンをサポートしていることを確認します。詳細については、Apache Beam SDK のインストールのガイドをご覧ください。

コンテナ イメージをローカルでテストするための Docker がインストールされていることを確認してください。詳細については、Docker の取得をご覧ください。

コンテナ イメージの作成とビルド

この例では、Python 3.8 と Apache Beam SDK バージョン 2.25.0 を使用します。カスタム コンテナ イメージを作成するには、Apache Beam イメージを親イメージとして指定し、独自のカスタマイズを追加します。

  1. Dockerfile を新規に作成し、apache/beam_python3.8_sdk:2.25.0 を親として指定してカスタマイズを追加します。Dockerfile の作成方法については、Dockerfiles 作成のベスト プラクティスをご覧ください。
    FROM apache/beam_python3.8_sdk:2.25.0
    # Make your customizations here, for example:
    ENV FOO=/bar
    COPY path/to/myfile ./
  2. 子イメージをビルドし、このイメージをコンテナ レジストリに push します。

    Cloud Build

    export PROJECT=PROJECT
    export REPO=REPO
    export TAG=TAG
    export REGISTRY_HOST=HOST
    export IMAGE_URI=$REGISTRY_HOST/$PROJECT/$REPO:$TAG
    
    gcloud builds submit --tag $IMAGE_URI

    Docker

    export PROJECT=PROJECT
    export REPO=REPO
    export TAG=TAG
    export REGISTRY_HOST=HOST
    export IMAGE_URI=$REGISTRY_HOST/$PROJECT/$REPO:$TAG
    
    docker build -f Dockerfile -t $IMAGE_URI ./
    docker push $IMAGE_URI
    次のように置き換えます。
    • PROJECT: プロジェクト名またはユーザー名。
    • REPO: イメージ リポジトリの名前。
    • TAG: イメージタグ。
    • HOST: イメージ レジストリのホスト名(例: gcr.io)。

カスタム コンテナを使用したジョブの実行

パイプラインを実行するときは、予期しないエラーを避けるために、カスタム コンテナ イメージで指定したものと同じ Python バージョンと Apache Beam SDK バージョンを使用します。

ローカルでのテスト

PortableRunner を使用して Apache Beam wordcount の例を実行し、コンテナ イメージをローカルでテストします。

python -m apache_beam.examples.wordcount \
  --input=INPUT_FILE \
  --output=OUTPUT_FILE \
  --runner=PortableRunner \
  --job_endpoint=embed \
  --environment_type=DOCKER \
  --environment_config=$IMAGE_URI

次のように置き換えます。

  • INPUT_FILE: テキスト ファイルとして読み取り可能な入力ファイル。このファイルは、コンテナ イメージまたはリモート ファイルにプリロードされた SDK ハーネス コンテナ イメージからアクセスできる必要があります。
  • OUTPUT_FILE: 出力を書き込むファイルパス。このパスは、リモートパスまたはコンテナのローカルパスになります。
  • $IMAGE_URI: カスタム コンテナ イメージの URI。変数がスコープ内にある場合は、前の手順で作成したシェル変数 $IMAGE_URI を使用できます。

パイプラインが正常に完了したら、コンソールのログを調べて、パイプラインが正常に完了したことを確認します。また、$IMAGE_URI で指定されたリモート イメージが使用されていたことを確認します。

このローカルテストでは、実際のコンテナ イメージ自体を検証します。パイプラインは、このステップの前にコンテナ イメージなしで検証する必要があります。たとえば、DirectRunner を使用します。コンテナの分離特性により、ローカル ファイル システムや、環境変数などのローカル構成にアクセスすることはできません。

つまり、ローカルの入力ファイルや認証情報ファイル、アプリケーションのデフォルト認証情報の設定に使用されるローカル環境変数に、そのコンテナ自体からはアクセスすることはできません。ローカル出力はコンテナ ファイル システムに書き込まれ、コンテナがシャットダウンしてパイプラインが完了するとアクセスできなくなります。

これらの出力を永続化する必要がある場合は、出力パスとしてリモート ファイルシステムを指定し、このリモート ファイルシステムに対するアクセス権がコンテナ自体に設定します。デバッグ目的では、一時的なロギングの追加で十分かもしれません。

詳細については、カスタム コンテナ イメージを使用したパイプラインの実行に関する Apache Beam のガイドをご覧ください。

Dataflow ジョブの起動

Dataflow で Apache Beam パイプラインを起動するときにコンテナ イメージのパスを指定します。バッチ Python パイプラインを起動する場合は、--experiment=use_runner_v2 フラグを設定する必要があります。ストリーミング Python パイプラインを起動する場合、テストを指定する必要はありません。たとえば、カスタム コンテナ イメージを使用してバッチ ワードカウントの例を起動するには、次のようにします。

python -m apache_beam.examples.wordcount \
  --input=INPUT_FILE \
  --output=OUTPUT_FILE \
  --project=PROJECT_ID \
  --region=REGION \
  --temp_location=TEMP_LOCATION \
  --runner=DataflowRunner \
  --experiment=use_runner_v2 \
  --worker_harness_container_image=$IMAGE_URI

次のように置き換えます。

  • INPUT_FILE: サンプルの実行時に Dataflow によって読み取られる Cloud Storage 入力ファイルのパス。
  • OUTPUT_FILE: サンプル パイプラインによって書き込まれる Cloud Storage 出力ファイルのパス。ここには文字数が書き込まれます。
  • PROJECT_ID: Google Cloud プロジェクトの ID。
  • REGION: Dataflow ジョブをデプロイするリージョン エンドポイント。
  • TEMP_LOCATION: パイプラインの実行中に作成される一時ジョブファイルをステージングするための Dataflow 用の Cloud Storage パス。
  • $IMAGE_URI: カスタム コンテナ イメージの URI。変数がスコープ内にある場合は、前の手順で作成したシェル変数 $IMAGE_URI を使用できます。

トラブルシューティング

このセクションでは、Dataflow でカスタム コンテナを操作する際によく起きる問題のトラブルシューティングについて説明します。

サポートに問い合わせる前に、ローカルテストの手順と次のトラブルシューティング セクションの手順に沿って、コンテナ イメージに関連する問題を除外してください。

コンテナログの検索

コンテナ関連のエラー メッセージを含む Dataflow ワーカーログは、ログ エクスプローラで確認できます。

  1. 次のログ名を選択します。

    • dataflow.googleapis.com/docker
    • dataflow.googleapis.com/kubelet
    • dataflow.googleapis.com/worker
  2. Dataflow Step リソースを選択して、job_id を指定します。

ワーカーが起動しない

ワーカーが起動しない場合、またはジョブがタイムアウトになった場合は、Dataflow がカスタム コンテナ イメージを pull できることを確認します。

次のクエリを使用して、ログ エクスプローラでログメッセージ Error Syncing pod... を検索し、Dataflow ログをクエリします。

resource.type="dataflow_step" AND jsonPayload.message:("$IMAGE_URI") AND severity="ERROR"

ワーカーが起動時にイメージを pull できるように、ワーカーが Dataflow ワーカーからアクセス可能である必要があります。Container Registry を使用してコンテナ イメージをホストする場合、デフォルトの Google Cloud サービス アカウントは、同じプロジェクト内のイメージにアクセスできます。Dataflow がコンテナ イメージを pull できない場合、ワーカーは起動できません。

詳細については、アクセス制御の構成をご覧ください。