安定版リリースのドキュメントについては、[バージョニングされたドキュメント] プルダウンを使用してください。デフォルトのビューには HEAD の最新バージョンが表示されます。

このページは Cloud Translation API によって翻訳されました。

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

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

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

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

ビルドアクションはツールチェーンコンテナで実行されます。同じツールチェーンコンテナを使用して、コンテナ化されたリモート実行をサポートするサービスを介してローカルに、またはリモートでビルドを実行できます。
余分なデータがコンテナの境界を越えることはありません。明示的に宣言された入力と出力のみが、関連するビルドアクションが正常に完了した後にのみ、コンテナに出入りします。
各アクションは新しいコンテナで実行されます。生成されたビルドアクションごとに、新しい一意のコンテナが作成されます。

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

ネイティブでのトラブルシューティングこの方法では、Bazel とそのビルドアクションがローカルマシンでネイティブに実行されます。Docker サンドボックス機能は、リモート実行と同じ制限をビルドに適用します。ただし、この方法では、リモート実行で問題を引き起こすローカルツール、状態、ビルドへのデータの漏洩は検出されません。
Docker コンテナのトラブルシューティング。この方法では、Bazel とそのビルドアクションが Docker コンテナ内で実行されます。これにより、リモート実行と同じ制限に加え、ローカルマシンからビルドへのツール、状態、データ漏洩を検出できます。このメソッドは、ビルドの一部が失敗した場合でも、ビルドの分析情報を提供します。このメソッドは試験運用版であり、正式にはサポートされていません。

前提条件

トラブルシューティングを開始する前に、以下を行います（まだ行っていない場合）。

Docker をインストールして、実行に必要な権限を構成します。
Bazel 0.14.1 以降をインストールします。以前のバージョンでは、Docker サンドボックス機能はサポートされていません。
こちらの説明に沿って、最新リリースバージョンに固定された bazel-ツールチェーンリポをビルドの WORKSPACE ファイルに追加します。
この機能を有効にするには、.bazelrc ファイルにフラグを追加します。Bazel プロジェクトのルートディレクトリにこのファイルが存在しない場合は、作成します。以下のフラグはリファレンスサンプルです。bazel-ツールチェーンリポジトリにある最新の .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 とそのすべてのビルドアクションを直接実行します。リモートで実行したときに、ビルドが成功するかどうかを信頼できる方法で確認します。

ただし、この方法では、特に構成スタイルの 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 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 は割り当てられたディスク容量（ギガバイト単位）です。これは試験運用版のため、予期しない動作が発生する可能性があります。
分析フェーズまたは読み込みフェーズでビルドが失敗した場合、WORKSPACE ファイルで宣言された 1 つ以上のビルドルールがリモート実行に対応していません。考えられる原因と回避策については、リモート実行用の Bazel ルールの適用をご覧ください。
その他の理由でビルドが失敗した場合は、ステップ 2: 検出された問題を解決するのトラブルシューティング手順をご覧ください。