ローカルで成功した 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 --define=EXECUTOR=remote
build:docker-sandbox --experimental_docker_verbose
build:docker-sandbox --experimental_enable_docker_sandbox
ルールで追加のツールが必要な場合は、次の操作を行います。
Dockerfile を使用してツールをインストールし、イメージをローカルでビルドして、カスタム Docker コンテナを作成します。
上記の
--experimental_docker_imageフラグの値を、カスタム コンテナ イメージの名前に置き換えます。
ネイティブのトラブルシューティング
このメソッドは、Bazel とそのすべてのビルド アクションをローカルマシンで直接実行します。リモートで実行した場合にビルドが成功するかどうかを確認する信頼性の高い方法です。
ただし、この方法では、特に configure スタイルの WORKSPACE ルールを使用している場合、ローカルにインストールされたツール、バイナリ、データがビルドに漏洩する可能性があります。このようなリークはリモート実行で問題を引き起こします。このようなリークを検出するには、ネイティブのトラブルシューティングに加えて、Docker コンテナでトラブルシューティングを行います。
ステップ 1: ビルドを実行する
ビルドを実行する Bazel コマンドに
--config=docker-sandboxフラグを追加します。次に例を示します。bazel --bazelrc=.bazelrc build --config=docker-sandbox targetビルドを実行し、完了するまで待ちます。Docker サンドボックス機能により、ビルドの実行速度は通常より最大 4 倍遅くなります。
次のエラーが発生することがあります。
ERROR: 'docker' is an invalid value for docker spawn strategy.
その場合は、--experimental_docker_verbose フラグを指定してビルドを再度実行します。このフラグを使用すると、詳細なエラー メッセージが有効になります。このエラーは通常、Docker のインストールに欠陥があるか、現在のユーザー アカウントで実行する権限がないことが原因で発生します。詳細については、Docker のドキュメントをご覧ください。問題が解決しない場合は、Docker コンテナでのトラブルシューティングに進みます。
ステップ 2: 検出された問題を解決する
以下に、最もよく発生する問題とその回避策を示します。
Bazel runfiles ツリーで参照されているファイル、ツール、バイナリ、またはリソースが見つかりません。影響を受けるターゲットのすべての依存関係が明示的に宣言されていることを確認します。詳細については、暗黙的な依存関係の管理をご覧ください。
絶対パスまたは
PATH変数で参照されるファイル、ツール、バイナリ、またはリソースがない。必要なツールがすべてツールチェーン コンテナ内にインストールされていることを確認し、ツールチェーン ルールを使用して、不足しているリソースを指す依存関係を正しく宣言します。詳細については、ツールチェーン ルールを介してビルドツールを呼び出すをご覧ください。バイナリの実行が失敗します。ビルドルールの 1 つが、実行環境（Docker コンテナ）と互換性のないバイナリを参照している。詳細については、プラットフォーム依存バイナリの管理をご覧ください。問題を解決できない場合は、bazel-discuss@google.com までお問い合わせください。
@local-jdkのファイルがないか、エラーが発生している。ローカルマシンの Java バイナリがビルドにリークしていますが、ビルドと互換性がありません。ルールとターゲットでは、@local_jdkの代わりにjava_toolchainを使用します。さらにサポートが必要な場合は、bazel-discuss@google.com までお問い合わせください。その他のエラー。サポートについては、bazel-discuss@google.com までお問い合わせください。
Docker コンテナでのトラブルシューティング
この方法では、Bazel はホスト Docker コンテナ内で実行され、Bazel のビルド アクションは Docker サンドボックス機能によって生成された個々のツールチェーン コンテナ内で実行されます。サンドボックスは、ビルド アクションごとに新しいツールチェーン コンテナを生成し、各ツールチェーン コンテナで 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コンテナを
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 psbazel 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は割り当てられたディスク容量（ギガバイト単位）です。これは試験運用版であり、予期しない動作が発生する可能性があります。分析フェーズまたは読み込みフェーズでビルドが失敗した場合、WORKSPACE ファイルで宣言された 1 つ以上のビルドルールがリモート実行と互換性がないことを示します。考えられる原因と回避策については、リモート実行用に Bazel ルールを適応させるをご覧ください。
その他の理由でビルドが失敗した場合は、ステップ 2: 検出された問題を解決するのトラブルシューティングの手順をご覧ください。