Docker サンドボックスを使用した Bazel リモート実行のトラブルシューティング

Nightly · 9.1 · 9.0 · 8.7 · 8.6 · 8.5 · 8.4 · 8.3 · 8.2 · 8.1

ローカルビルドでは成功する Bazel ビルドが、リモートビルドでは失敗することがあります。これは、ローカルビルドには影響しない制限や要件がリモートビルドにはあるためです。このような失敗の最も一般的な 原因については、リモート実行用に Bazel ルールを調整するをご覧ください。

このページでは、Docker サンドボックス機能を使用してリモート実行で発生する最も一般的な問題を特定して解決する方法について説明します。この機能では、リモート実行と同じ制限がビルドに適用されます。これにより、リモート実行サービスを使用せずにビルドのトラブルシューティングを行うことができます。

Docker サンドボックス機能は、次のようにリモート実行の制限を模倣します。

  • ビルド アクションはツールチェーン コンテナで実行されます。同じツールチェーン コンテナを使用して、コンテナ化されたリモート実行をサポートするサービスを使用して、ローカルとリモートでビルドを実行できます。

  • コンテナの境界を越えて不要なデータが移動することはありません。明示的に宣言された入力と出力のみがコンテナに出入りします。また、関連するビルド アクションが正常に完了した後にのみ出入りします。

  • 各アクションは新しいコンテナで実行されます。生成されたビルド アクションごとに、新しい一意のコンテナが作成されます。

これらの問題は、次のいずれかの方法でトラブルシューティングできます。

  • ネイティブでのトラブルシューティング。 この方法では、Bazel とそのビルド アクションがローカルマシンでネイティブに実行されます。Docker サンドボックス機能では、リモート実行と同じ制限がビルドに適用されます。ただし、この方法では、ローカルツール、状態、データがビルドにリークしていることを検出できません。これはリモート実行で問題を引き起こします。

  • Docker コンテナでのトラブルシューティング。 この方法では、Bazel とそのビルド アクションが Docker コンテナ内で実行されます。これにより、リモート実行と同じ制限を適用するだけでなく、ローカルマシンからビルドにリークするツール、状態、データを検出できます。この方法では、ビルドの一部が失敗した場合でも、ビルドに関する分析情報が得られます。この方法は試験運用版であり、正式にはサポートされていません。

前提条件

トラブルシューティングを開始する前に、次の操作を行います。

  • Docker をインストールし、実行に必要な権限を構成します。
  • Bazel 0.14.1 以降をインストールします。以前のバージョンでは、Docker サンドボックス機能はサポートされていません。
  • こちらの手順に沿って、最新のリリース バージョンに固定された bazel-toolchains リポジトリをビルドの WORKSPACE ファイル に追加します。
  • 機能を有効にするには、.bazelrc ファイルにフラグを追加します。ファイルが存在しない場合は、Bazel プロジェクトのルート ディレクトリに作成します。以下のフラグは参照サンプルです。bazel-toolchains リポジトリの最新の .bazelrc ファイルを参照し、そこで定義されているフラグの値を構成 docker-sandbox にコピーしてください。
# Docker Sandbox Mode
build:docker-sandbox --host_javabase=<...>
build:docker-sandbox --javabase=<...>
build:docker-sandbox --crosstool_top=<...>
build:docker-sandbox --experimental_docker_image=<...>
build:docker-sandbox --spawn_strategy=docker --strategy=Javac=docker --genrule_strategy=docker
build:docker-sandbox --experimental_docker_verbose
build:docker-sandbox --experimental_enable_docker_sandbox

ルールで追加のツールが必要な場合は、次の操作を行います。

  1. Dockerfile を使用してツールをインストールし、イメージをローカルで ビルド して、カスタム Docker コンテナを作成します。

  2. 上記の --experimental_docker_image フラグの値を、カスタム コンテナ イメージの名前に置き換えます。

ネイティブでのトラブルシューティング

この方法では、Bazel とそのすべてのビルド アクションがローカルマシンで直接実行されます。これは、リモートで実行したときにビルドが成功するかどうかを確認する信頼性の高い方法です。

ただし、この方法では、ローカルにインストールされたツール、バイナリ、データがビルドにリークする可能性があります。特に、configure スタイルの WORKSPACE ルールを使用している場合は注意が必要です。このようなリークはリモート実行で問題を引き起こします。リークを検出するには、Docker コンテナでトラブルシューティングを行います ネイティブでのトラブルシューティングに加えて。

ステップ 1: ビルドを実行する

  1. ビルドを実行する Bazel コマンドに --config=docker-sandbox フラグを追加します。次に例を示します。

    bazel --bazelrc=.bazelrc build --config=docker-sandbox target

  2. ビルドを実行し、完了するまで待ちます。Docker サンドボックス機能により、ビルドの実行速度が通常より最大 4 倍遅くなります。

次のエラーが発生することがあります。

ERROR: 'docker' is an invalid value for docker spawn strategy.

この場合は、--experimental_docker_verbose フラグを指定してビルドを再度実行します。 このフラグを使用すると、詳細なエラー メッセージが表示されます。このエラーは通常、Docker のインストールに問題があるか、現在のユーザー アカウントで実行する権限がないことが原因で発生します。詳細については、Docker のドキュメント をご覧ください。問題が解決しない場合は、Docker コンテナでのトラブルシューティングに進んでください。

ステップ 2: 検出された問題を解決する

最もよく発生する問題とその回避策は次のとおりです。

Docker コンテナでのトラブルシューティング

この方法では、Bazel はホスト Docker コンテナ内で実行され、Bazel のビルド アクションは Docker サンドボックス機能によって生成された個々のツールチェーン コンテナ内で実行されます。サンドボックスは、ビルド アクションごとに新しいツールチェーン コンテナを生成し、各ツールチェーン コンテナで実行されるアクションは 1 つだけです。

この方法では、ホスト環境にインストールされているツールをより詳細に制御できます。ビルドの実行とビルド アクションの実行を分離し、インストールされているツールを最小限に抑えることで、ビルドがローカル実行環境に依存しているかどうかを確認できます。

ステップ 1: コンテナをビルドする

  1. Docker コンテナを作成し、最小限のビルドツールセットで Bazel をインストールする Dockerfile を作成します。

    FROM debian:stretch

RUN apt-get update && apt-get install -y apt-transport-https curl software-properties-common git gcc gnupg2 g++ openjdk-8-jdk-headless python-dev zip wget vim

RUN curl -fsSL https://download.docker.com/linux/debian/gpg | apt-key add -

RUN add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable"

RUN apt-get update && apt-get install -y docker-ce

RUN wget https://releases.bazel.build/<latest Bazel version>/release/bazel-<latest Bazel version>-installer-linux-x86_64.sh -O ./bazel-installer.sh && chmod 755 ./bazel-installer.sh

RUN ./bazel-installer.sh

  2. コンテナを bazel_container としてビルドします。

    docker build -t bazel_container - < Dockerfile

ステップ 2: コンテナを起動する

次のコマンドを使用して Docker コンテナを起動します。このコマンドでは、ビルドするホスト上のソースコードのパスに置き換えます。

docker run -it \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /tmp:/tmp \
  -v your source code directory:/src \
  -w /src \
  bazel_container \
  /bin/bash

このコマンドは、コンテナを root として実行し、Docker ソケットをマッピングして /tmp ディレクトリをマウントします。これにより、Bazel は他の Docker コンテナを生成し、/tmp の下のディレクトリを使用してこれらのコンテナとファイルを共有できます。ソースコードはコンテナ内の /src にあります。

このコマンドは、ツールチェーン コンテナとして使用される rbe-ubuntu16-04 コンテナと互換性のないバイナリを含む debian:stretch ベースコンテナから意図的に開始されます。ローカル環境のバイナリがツールチェーン コンテナにリークすると、ビルドエラーが発生します。

ステップ 3: コンテナをテストする

Docker コンテナ内から次のコマンドを実行してテストします。

docker ps
bazel version

ステップ 4: ビルドを実行する

次のようにビルドを実行します。出力ユーザーは root です。これにより、Bazel が実行されるホスト コンテナ内、Bazel のビルド アクションが実行される Docker サンドボックス機能によって生成されたツールチェーン コンテナ内、ホスト コンテナとアクション コンテナが実行されるローカルマシンから、同じ絶対パスでアクセスできるディレクトリに対応します。

bazel --output_user_root=/tmp/bazel_docker_root --bazelrc=.bazelrc \ build --config=docker-sandbox target

ステップ 5: 検出された問題を解決する

ビルドの失敗は次のように解決できます。

  • ビルドが「ディスク容量不足」エラーで失敗する場合は、ホスト コンテナをフラグ --memory=XX で起動することで、この 上限を引き上げることができます。ここで、XX は割り当てられたディスク容量（GB）です。これは試験運用版であり、予期しない動作が発生する可能性があります。

  • 分析フェーズまたは読み込みフェーズでビルドが失敗する場合は、WORKSPACE ファイルで宣言されたビルドルールの 1 つ以上がリモート実行と互換性がありません。考えられる原因と回避策については、リモート実行用に Bazel ルールを調整する をご覧ください。

  • その他の理由でビルドが失敗する場合は、ステップ 2: 検出された問題を解決するのトラブルシューティングの手順をご覧ください。