サンドボックス化

問題を報告 ソースを表示 Nightly · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

この記事では、Bazel でのサンドボックス化、sandboxfs のインストール、デバッグについて説明します 確認しましょう。

サンドボックス化は、プロセスを互いに分離したり、システム内のリソースから分離したりする権限制限戦略です。Bazel の場合、これはファイルへのアクセスを 許可します。

Bazel のファイル システム サンドボックスは、既知の入力のみを含む作業ディレクトリでプロセスを実行します。これにより、コンパイラやその他のツールは、アクセスすべきでないソースファイルの絶対パスを把握していない限り、そのソースファイルを見ることができません。

サンドボックス化では、ホスト環境が隠されることはありません。プロセスは、ファイル システム上のすべてのファイルに自由にアクセスできます。ただし、ユーザー サポートと 作業ディレクトリの外部にあるファイルを変更できません。 これにより、ビルドの再現性に影響する可能性のある隠れた依存関係がビルドグラフに存在しなくなります。

具体的には、Bazel はアクションごとに execroot/ ディレクトリを構築します。 このディレクトリは、実行時にアクションの作業ディレクトリとして機能します。execroot/ アクションへのすべての入力ファイルが含まれ、アクションのコンテナ 生成します。Bazel は、オペレーティング システムが提供する手法（Linux ではコンテナ、macOS では sandbox-exec）を使用して、execroot/ 内のアクションを制限します。

サンドボックス化する理由

  • アクション サンドボックスを使用しないと、ツールが宣言されていないものを使用しているかどうかを Bazel で判断できません。 入力ファイル（依存関係リストに明示的にリストされていないファイル）を アクション）。宣言されていない入力ファイルのいずれかが変更されても、Bazel は ユーザーが、ビルドが最新であり、アクションを再構築しないと考えています。これにより、 増分ビルドが正しく行われません。

  • キャッシュ エントリを誤って再利用すると、リモート キャッシュ中に問題が発生します。共有キャッシュ内の不正なキャッシュエントリは、プロジェクトのすべてのデベロッパーに影響します。リモート キャッシュ全体をワイプすることは現実的なソリューションではありません。

  • サンドボックス化はリモート実行の動作を模倣します。サンドボックス化でビルドが正常に動作する場合は、リモート実行でも動作する可能性があります。リモート実行で必要なすべてのファイル（ローカル ツールを含む）をアップロードすることで、新しいコンパイラを試すたびに、または既存のツールを変更するたびに、クラスタ内のすべてのマシンにツールをインストールする必要がなくなるため、コンパイル クラスタのメンテナンス費用を大幅に削減できます。

どのようなサンドボックス戦略を採用するか

使用するサンドボックスの種類（ある場合）は、戦略フラグで選択できます。sandboxed の使用 Bazel は、以下に示すサンドボックス実装のいずれかを選択します。 密閉性の低い一般的なサンドボックスよりも、OS 固有のサンドボックスを優先します。 --worker_sandboxing フラグを渡すと、永続ワーカーが汎用サンドボックスで実行されます。

local（standalone）戦略では、いかなる種類のサンドボックス化も行われません。アクションのコマンドラインを単に実行するだけで、作業ディレクトリを 「execroot」です。

processwrapper-sandbox は、「高度な」機能を必要としないサンドボックス化戦略です。任意の POSIX システムですぐに動作します。これは、 オリジナルのディレクトリを指すシンボリック リンクで構成されるサンドボックス ディレクトリを構築します。 作業ディレクトリを設定してアクションのコマンドラインを execroot ではなくこのディレクトリに移動し、既知の出力アーティファクトを サンドボックスから execroot に移動し、サンドボックスを削除します。これにより 宣言されていない入力ファイルを誤って使用してしまわないよう、 execroot を不明な出力ファイルで埋める

linux-sandbox はさらに一歩進んで、processwrapper-sandbox の上に構築されます。内部で Docker が行っていることと同様に、Docker は 隔離する Linux 名前空間（ユーザー、マウント、PID、ネットワーク、IPC の名前空間） アクションを実行します。つまり、ファイル システム全体が読み取り専用になりますが、 サンドボックス ディレクトリに作成されます。そのため、ディレクトリ内のファイルが誤って変更されることはありません。 作成されます。これにより、バグのあるテストで $HOME ディレクトリが誤って rm -rf されるような状況を防ぐことができます。必要に応じて、この操作を ファイアウォールルールがありますlinux-sandbox は PID 名前空間を使用して、アクションが他のプロセスを認識しないようにし、最後にすべてのプロセス（アクションによって生成されたデーモンも含む）を確実に強制終了します。

darwin-sandbox も同様ですが、macOS 用です。Apple の sandbox-exec ツールを使用して、Linux サンドボックスとほぼ同じことを実現します。

linux-sandbox と darwin-sandbox はどちらも、オペレーティング システムが提供するメカニズムの制限により、「ネストされた」シナリオでは機能しません。Docker はコンテナ マジックにも Linux 名前空間を使用するため、docker run --privileged を使用しない限り、Docker コンテナ内で linux-sandbox を簡単に実行することはできません。macOS では、すでにサンドボックス化されているプロセス内で sandbox-exec を実行することはできません。そのため、このような場合、Bazel は自動的に processwrapper-sandbox を使用するようにフォールバックします。

誤ってビルドしないようにするには、ビルド エラーを あまり厳格でない実行戦略 — 実行リストを明示的に変更する Bazel が使用しようとするストラテジー（例: bazel build --spawn_strategy=worker,linux-sandbox）。

通常、動的実行には、ローカル実行のサンドボックス化が必要です。オプトアウトするには、 --experimental_local_lockfree_output フラグを渡します。動的実行では、永続ワーカーがサイレントでサンドボックス化されます。

サンドボックスの欠点

  • サンドボックス化すると、セットアップと破棄のコストが追加で発生します。費用の額 ビルドの形状や構成など、さまざまな要因によって パフォーマンス指標です。Linux では、サンドボックス化されたビルドが 数パーセント遅くなります。--reuse_sandbox_directories を設定すると、セットアップとテイクダウンの費用を軽減できます。

  • サンドボックス化により、ツールが保持しているキャッシュは実質的に無効になります。これは、永続ワーカーを使用すると軽減できますが、その場合、サンドボックスの保証が弱くなります。

  • マルチプレックス ワーカーでは、ワーカーをサンドボックス化するための明示的なワーカー サポートが必要です。マルチプレックス サンドボックスをサポートしていないワーカーは、動的実行でシングルプレックス ワーカーとして実行されるため、追加のメモリが必要になる場合があります。

Sandboxfs

sandboxfs は FUSE ファイル システムであり、デバイスの任意のビューを公開する ファイル システムでアクセスできます。Bazel は sandboxfs を使用して、アクションごとに execroot/ を即座に生成するため、数千のシステム呼び出しを行うコストを回避できます。execroot/ 内の I/O は、FUSE オーバーヘッドが原因で遅くなる可能性があります。

sandboxfs をインストールする

次の手順で sandboxfs をインストールし、Bazel でビルドを実行します。 説明します。

ダウンロード

sandboxfs をダウンロードしてインストールし、sandboxfs バイナリが PATH に配置されるようにします。

Run sandboxfs

  1. （macOS のみ）OSXFUSE をインストールします。

  2. （macOS のみ）次を実行します。

    sudo sysctl -w vfs.generic.osxfuse.tunables.allow_other=1

    この作業は、インストール後と再起動のたびに行う必要があります。 macOS のコア システム サービスは sandboxfs を通じて動作します。

  3. --experimental_use_sandboxfs を使用して Bazel ビルドを実行します。

    bazel build target --experimental_use_sandboxfs

トラブルシューティング

検索結果として darwin-sandbox や linux-sandbox ではなく local が表示される場合 アノテーションが付けられている場合、サンドボックス化が 無効です。有効にするには --genrule_strategy=sandboxed --spawn_strategy=sandboxed を渡します。

デバッグ

サンドボックスに関する問題をデバッグするには、以下の方法に沿って対応してください。

無効な名前空間

たとえば Google Kubernetes Engine ユーザー名前空間は、クラスタノードまたは Debian ではデフォルトで 懸念を軽減できます/proc/sys/kernel/unprivileged_userns_clone ファイルが 0 が含まれる場合、ユーザーの名前空間を有効にするには、次のコマンドを実行します。

   sudo sysctl kernel.unprivileged_userns_clone=1

ルールの実行エラー

システム設定が原因で、サンドボックスがルールを実行できない場合があります。namespace-sandbox.c:633: execvp(argv[0], argv): No such file or directory のようなメッセージが表示された場合は、genrules の場合は --strategy=Genrule=local、他のルールの場合は --spawn_strategy=local を使用してサンドボックスを無効にしてみてください。

ビルド失敗の詳細なデバッグ

ビルドが失敗した場合は、--verbose_failures と --sandbox_debug を使用して以下を行います。 Bazel は、ビルドが失敗したときに実行された正確なコマンドを、 サンドボックスを設定します

エラー メッセージの例

ERROR: path/to/your/project/BUILD:1:1: compilation of rule
'//path/to/your/project:all' failed:

Sandboxed execution failed, which may be legitimate (such as a compiler error),
or due to missing dependencies. To enter the sandbox environment for easier
debugging, run the following command in parentheses. On command failure, a bash
shell running inside the sandbox will then automatically be spawned

namespace-sandbox failed: error executing command
  (cd /some/path && \
  exec env - \
    LANG=en_US \
    PATH=/some/path/bin:/bin:/usr/bin \
    PYTHONPATH=/usr/local/some/path \
  /some/path/namespace-sandbox @/sandbox/root/path/this-sandbox-name.params --
  /some/path/to/your/some-compiler --some-params some-target)

生成されたサンドボックス ディレクトリを調べて、Bazel でどのファイルが使用されているかを確認できるようになりました コマンドを再実行して動作を確認します。

--sandbox_debug を使用する場合、Bazel はサンドボックス ディレクトリを削除しません。積極的にデバッグを行っている場合を除き、 --sandbox_debug。時間の経過とともにディスクがいっぱいになるため。