このページでは、リモート キャッシュ、キャッシュをホストするサーバーの設定、 使用してビルドを実行しています。
デベロッパー チームや継続的インテグレーションがリモート キャッシュを使用する ビルド出力を共有します。ビルドが再現可能な場合、 あるマシンの出力を別のマシンで安全に再利用でき ビルドが大幅に高速化されます
概要
Bazel は、ビルドをアクションと呼ばれる個別のステップに分割します。各アクション 入力、出力名、コマンドライン、環境変数があります。必須 入力と想定される出力がアクションごとに明示的に宣言されている。
ビルド出力用のリモート キャッシュとしてサーバーを設定できます。 アクション出力です。これらの出力は、出力ファイル名のリストと その内容のハッシュ値を生成します。リモート キャッシュを使用すると、ビルドの出力を 新しい出力をローカルでビルドするのではなく、別のユーザーのビルドから出力します。
リモート キャッシュを使用するには:
- サーバーをキャッシュのバックエンドとして設定する
- リモート キャッシュを使用するように Bazel ビルドを構成する
- Bazel バージョン 0.10.0 以降を使用する
リモート キャッシュには、次の 2 種類のデータが保存されます。
- アクション キャッシュ。アクション ハッシュからアクション結果メタデータへのマップです。
- 出力ファイルのコンテンツ アドレス指定可能なストア（CAS）。
リモート キャッシュには、すべてのリクエストの stdout と stderr も格納されることに注意してください。 できます。そのため、Bazel の stdout/stderr を検査することは、 キャッシュ ヒットの見積もりをご覧ください。
ビルドでリモート キャッシュを使用する方法
リモート キャッシュとしてサーバーを設定すると、そのキャッシュを複数の 方法:
- リモート キャッシュの読み取りと書き込み
- 特定のターゲットを除くリモート キャッシュの読み取りと書き込み
- リモート キャッシュからのみ読み取る
- リモート キャッシュをまったく使用しない
リモート キャッシュの読み取りと書き込みが可能な Bazel ビルドを実行すると、 ビルドの手順は次のとおりです。
- Bazel は、ビルドする必要があるターゲットのグラフを作成して、 必要なアクションのリストを返します。これらのアクションではそれぞれ、入力が宣言されている 出力ファイル名を指定します。
- Bazel はローカルマシンで既存のビルド出力をチェックし、出力されたものを再利用します。 表示されます。
- Bazel は、キャッシュで既存のビルド出力を確認します。出力が見つかった場合 Bazel は出力を取得します。これはキャッシュ ヒットです。
- 出力が見つからなかった必要なアクションについて、Bazel は以下を実行します。 必要なビルド出力を作成します。
- 新しいビルドの出力がリモート キャッシュにアップロードされます。
サーバーをキャッシュのバックエンドとして設定する
キャッシュのバックエンドとして機能するサーバーを設定する必要があります。HTTP/1.1 Bazel のデータを不透明なバイトとして扱うことができるため、多くの既存のサーバー リモート キャッシュ バックエンドとして使用できます。Bazel HTTP キャッシュ プロトコルは、 キャッシュ保存について説明します。
バックエンドの選択、設定、メンテナンスはお客様の責任で行っていただく必要があります キャッシュされた出力を保存するサーバーです。サーバーを選ぶ際には、以下の点を考慮してください。
- ネットワーク速度。たとえば、チームが同じオフィスにいる場合は、 独自のローカル サーバーを実行する場合です。
- セキュリティはその中の 1 つでしょう。リモート キャッシュにはバイナリが含まれるため、セキュリティを確保する必要があります。
- 管理のしやすさ。たとえば、Google Cloud Storage はフルマネージド サービスです。
リモート キャッシュに使用できるバックエンドは多数あります。次のようなオプションがあります。
nginx
nginx はオープンソースのウェブサーバーです。[WebDAV モジュール] を使用すると、
Bazel のリモート キャッシュとして使用されます。Debian と Ubuntu では、
nginx-extras パッケージ。macOS の場合、nginx は Homebble から利用できます。
brew tap denji/nginxbrew install nginx-full --with-webdav
以下は、nginx の構成例です。新しい P-MAX キャンペーンを
/path/to/cache/dir を、nginx に権限が付与されている有効なディレクトリに変更します。
書き込みと読み取りができます。client_max_body_size オプションを
出力ファイルが大きいほど大きい値になります。このサーバーには、そのサーバー間で
必要があります。
nginx.conf の server セクションの設定例:
location /cache/ {
# The path to the directory where nginx should store the cache contents.
root /path/to/cache/dir;
# Allow PUT
dav_methods PUT;
# Allow nginx to create the /ac and /cas subdirectories.
create_full_put_path on;
# The maximum size of a single file.
client_max_body_size 1G;
allow all;
}
bazel-remote
bazel-remote はオープンソースのリモートビルド キャッシュで、 必要があります。の本番環境で正常に使用されており、 2018 年初頭から数々の企業を支援していますBazel プロジェクトは bazel-remote のテクニカル サポートは提供されません。
このキャッシュはディスクにコンテンツを格納し、ガベージ コレクションも行います ストレージの上限を適用し、未使用のアーティファクトをクリーンアップします。キャッシュは Docker イメージとして利用可能であり、そのコードは GitHub。 REST と gRPC リモート キャッシュ API の両方がサポートされています。
GitHub を参照 をご覧ください。
Google Cloud Storage
[Google Cloud Storage] はフルマネージドのオブジェクト ストアであり、 Bazel のリモート キャッシュ プロトコルと互換性のある HTTP API。必要な 課金が有効になっている Google Cloud アカウントを持っている必要があります。
Cloud Storage をキャッシュとして使用するには:
Storage バケットを作成します。 ネットワーク帯域幅として最も近いバケットのロケーションを リモートキャッシュにとって重要です。
Bazel が Cloud Storage に対して認証するためのサービス アカウントを作成します。詳しくは、 サービス アカウントを作成する。
シークレット JSON キーを生成し、認証のために Bazel に渡します。保存 鍵を安全に保護します。この鍵があれば、誰でも任意のデータを読み書きできます。 GCS バケットとやり取りします
次のフラグを Bazel コマンドに追加して、Cloud Storage に接続します。
- フラグを使用して、次の URL を Bazel に渡します。
--remote_cache=https://storage.googleapis.com/bucket-name。ここで、bucket-nameはストレージ バケットの名前です。 --google_credentials=/path/to/your/secret-key.jsonフラグを使用して認証キーを渡す。または--google_default_credentials: アプリケーション認証を使用します。
- フラグを使用して、次の URL を Bazel に渡します。
古いファイルを自動的に削除するように Cloud Storage を構成できます。詳しくは、 オブジェクトのライフサイクルを管理する。
その他のサーバー
PUT と GET をサポートする任意の HTTP/1.1 サーバーをキャッシュの値として設定できます。 バックエンドです。ユーザーから、Hazelcast などのキャッシュ バックエンドが成功したという報告が寄せられています。 Apache httpd、AWS S3。
認証
バージョン 0.11.0 以降、HTTP 基本認証のサポートが Bazel に追加されました。
リモート キャッシュの URL を介して、Bazel にユーザー名とパスワードを渡すことができます。「
構文は https://username:password@hostname.com:port/path です。注:
HTTP 基本認証では、HTTP 接続を介して、平文のユーザー名とパスワードが送信されます。
常に HTTPS とともに使用することが重要です。
HTTP キャッシュ プロトコル
Bazel は HTTP/1.1 によるリモート キャッシュをサポートしています。プロトコルは概念的にシンプルです。
バイナリデータ（BLOB）は、PUT リクエストを介してアップロードされ、GET リクエストを介してダウンロードされます。
アクション結果のメタデータはパス /ac/ に保存され、出力ファイルが保存されます。
パス /cas/ の下。
たとえば、http://localhost:8080/cache で実行されているリモート キャッシュについて考えてみましょう。
SHA256 でアクションのアクション結果メタデータをダウンロードする Bazel リクエスト
ハッシュ 01ba4719... は次のようになります。
GET /cache/ac/01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b HTTP/1.1
Host: localhost:8080
Accept: */*
Connection: Keep-Alive
SHA256 ハッシュ 15e2b0d3... を含む出力ファイルをアップロードするための Bazel リクエスト
CAS は次のようになります。
PUT /cache/cas/15e2b0d3c33891ebb0f1ef609ec419420c20e320ce94c65fbc8c3312448eb225 HTTP/1.1
Host: localhost:8080
Accept: */*
Content-Length: 9
Connection: Keep-Alive
0x310x320x330x340x350x360x370x380x39
リモート キャッシュを使用して Bazel を実行する
サーバーがリモート キャッシュとして設定されると、リモート キャッシュを使用するには、 Bazel コマンドにフラグを追加する必要があります。構成のリストと 見てみましょう。
また、ご使用の環境に固有の認証の設定が必要な場合もあります。 表示されます。
これらのフラグを .bazelrc ファイルに追加して、
Bazel を実行するたびに指定する必要があります。プロジェクトと
チームの力学では、次のようなフラグを .bazelrc ファイルに追加できます。
- ローカルマシン
- プロジェクトのワークスペース（チームと共有する）
- CI システムの場合
リモート キャッシュの読み取りと書き込み
リモート キャッシュに書き込むことができる人物に注意してください。おすすめ CI システムのみがリモート キャッシュに書き込めるようにします。
リモート キャッシュの読み取りと書き込みを行うには、次のフラグを使用します。
build --remote_cache=http://your.host:portHTTP 以外にも、プロトコル HTTPS、grpc、grpcs がサポートされています。
上記のフラグに加えて、次のフラグを使用して、 リモート キャッシュ:
build --remote_upload_local_results=false特定のターゲットをリモート キャッシュの使用から除外する
特定のターゲットをリモート キャッシュの使用から除外するには、そのターゲットに
no-remote-cache。例:
java_library(
name = "target",
tags = ["no-remote-cache"],
)
リモート キャッシュからコンテンツを削除する
リモート キャッシュからのコンテンツの削除は、サーバー管理の一部です。 リモート キャッシュからコンテンツを削除する方法は、使用するサーバーによって異なります。 キャッシュとして設定します出力を削除する場合は、キャッシュ全体を削除するか、 古い出力を削除することもできます
キャッシュに保存された出力は、名前とハッシュのセットとして保存されます。削除のタイミング 出力が特定のコンテンツに属するかを 構築できます。
以下の場合は、キャッシュからコンテンツを削除することをおすすめします。
- キャッシュが汚染された後にクリーンなキャッシュを作成する
- 古い出力を削除して、ストレージ使用量を減らす
Unix ソケット
リモート HTTP キャッシュは、UNIX ドメイン ソケットを介した接続をサポートしています。動作
curl の --unix-socket フラグに似ています。次のコマンドで unix を構成します。
ドメイン ソケット:
build --remote_cache=http://your.host:port
build --remote_cache_proxy=unix:/path/to/socketこの機能は Windows ではサポートされていません。
ディスク キャッシュ
Bazel では、ファイル システム上のディレクトリをリモート キャッシュとして使用できます。これは、 ブランチの切り替え時や作業時にビルド アーティファクトを共有するのに便利 複数のチェックアウトなど、同じプロジェクトの複数のワークスペースで管理できます。以降 Bazel ではディレクトリのガベージ コレクションは行われません。この場合は、 定期的にクリーンアップします。次のようにディスク キャッシュを有効にします。
build --disk_cache=path/to/build/cache~ エイリアスを使用して、ユーザー固有のパスを --disk_cache フラグに渡すことができます。
（Bazel が現在のユーザーのホーム ディレクトリに置き換えます）。これは、
プロジェクトのすべてのデベロッパーに対して
.bazelrc 個のファイルにチェックインしました。
既知の問題
ビルド中の入力ファイルの変更
ビルド中に入力ファイルが変更されると、Bazel によるアップロードが無効になることがある
リモートキャッシュに出力します変更検出を有効にするには、
--experimental_guard_against_concurrent_changes フラグ。そこで、
は既知の問題ではなく、今後のリリースではデフォルトで有効になる予定です。
更新については、[問題 #3360] をご覧ください。一般に、サーバー コンポーネントの作成中は、
構築できます。
環境変数がアクションにリークする
アクションの定義には環境変数が含まれています。これはチームにとって問題となる
マシン間でリモートキャッシュヒットを共有しますたとえば、Compute Engine インスタンスで
異なる $PATH 変数はキャッシュ ヒットを共有しません。環境変数のみ
--action_env で明示的にホワイトリストに登録されたものがアクションに含まれる
定義します。/etc/bazel.bazelrc のインストールに Bazel の Debian/Ubuntu パッケージが使用されている
$PATH を含む環境変数のホワイトリストを使用します。新しい P-MAX キャンペーンを
キャッシュ ヒットが想定より少ない場合は、環境に古い
/etc/bazel.bazelrc ファイル。
Bazel でワークスペース外のツールを追跡しない
Bazel は現在、ワークスペース外のツールを追跡しません。これは
問題です。たとえば、アクションが /usr/bin/ のコンパイラを使用している場合などです。その後、
異なるコンパイラがインストールされている 2 人のユーザーが、誤ってキャッシュ ヒットを共有する
アクション ハッシュは同じですが、出力は異なります。詳しくは、
問題 #4558 をご覧ください。
Docker コンテナ内でビルドを実行すると増分メモリ内状態が失われる Bazel は、単一の Docker コンテナで実行している場合でもサーバー/クライアント アーキテクチャを使用します。 サーバーサイドでは、Bazel がメモリ内状態を維持するので、ビルドが高速化されます。 CI などの Docker コンテナ内でビルドを実行すると、メモリ内状態が失われる リモート キャッシュを使用する前に、Bazel で再ビルドする必要があります。