このチュートリアルでは、Terraform を使用した Java アプリケーションのビルドの基本について説明します。
Bazel。ワークスペースを設定し、ターゲットや BUILD
ファイルなどの主要な Bazel コンセプトを示すシンプルな Java プロジェクトをビルドします。
完了までの予想時間: 30 分。
学習内容
このチュートリアルでは、次のことを学習します。
- ターゲットを構築する
- プロジェクトの依存関係を可視化する
- プロジェクトを複数のターゲットとパッケージに分割する
- パッケージ全体でターゲットの公開設定を制御する
- ラベルでターゲットを参照する
- ターゲットをデプロイする
始める前に
Bazel をインストールする
チュートリアルの準備として、まだインストールしていない場合はまず Bazel をインストールします。
JDK をインストールする
Java JDK をインストールします(推奨バージョンは 11 ですが、バージョン 8 ~ 15 がサポートされています)。
JDK を指すように JAVA_HOME 環境変数を設定します。
Linux/macOS の場合:
export JAVA_HOME="$(dirname $(dirname $(realpath $(which javac))))"
Windows の場合:
- コントロール パネルを開きます。
- [システムとセキュリティ] に移動します>システム>[システムの詳細設定]>「上級」タブ >「環境変数...」.
- [ユーザー変数] リスト(上部にあるリスト)で、[新規...] をクリックします。
- [変数名] で、フィールドに「
JAVA_HOME
」と入力します。 - [Browse Directory...] をクリックします。
- JDK ディレクトリ(
C:\Program Files\Java\jdk1.8.0_152
など)に移動します。 - [OK] をクリックします。すべてのダイアログウィンドウで 表示できます
サンプル プロジェクトを取得する
Bazel の GitHub リポジトリからサンプル プロジェクトを取得します。
git clone https://github.com/bazelbuild/examples
このチュートリアルのサンプル プロジェクトは examples/java-tutorial
にあります。
構成されており、次のように構成されています。
java-tutorial
├── BUILD
├── src
│ └── main
│ └── java
│ └── com
│ └── example
│ ├── cmdline
│ │ ├── BUILD
│ │ └── Runner.java
│ ├── Greeting.java
│ └── ProjectRunner.java
└── WORKSPACE
Bazel を使用したビルド
ワークスペースを設定する
プロジェクトを作成する前に、ワークスペースを設定する必要があります。ワークスペースとは プロジェクトのソースファイルと Bazel のビルド出力を保持するディレクトリです。これは、 Bazel が特殊なファイルとして認識するファイルも含まれています。
WORKSPACE
ファイル。ディレクトリとその内容を Bazel ワークスペースであり、プロジェクトのディレクトリ構造のルートに存在します。1 つ以上の
BUILD
ファイル。プロジェクトのさまざまな部分をビルドする方法を Bazel に指示します。(ワークスペース内のBUILD
ファイルを含むディレクトリはパッケージです。パッケージについては、このチュートリアルの後半で説明します)。
ディレクトリを Bazel ワークスペースとして指定するには、そのディレクトリに WORKSPACE
という名前の空のファイルを作成します。
Bazel がプロジェクトをビルドする場合、すべての入力と依存関係が同じワークスペースにある必要があります。別々のワークスペースに存在するファイルはそれぞれ別のワークスペースに存在する これについては、このチュートリアルでは扱いません。
BUILD ファイルについて
BUILD
ファイルには、Bazel 用のさまざまなタイプの指示が含まれています。最も重要なタイプはビルドルールです。これは、Bazel にビルド方法を指示します。
必要な出力(実行可能なバイナリやライブラリなど)を出力できます。BUILD
ファイル内のビルドルールの各インスタンスはターゲットと呼ばれ、特定のソースファイルと依存関係のセットを参照します。ターゲットは他のターゲットを指すようにすることもできます。
java-tutorial/BUILD
ファイルを確認します。
java_binary(
name = "ProjectRunner",
srcs = glob(["src/main/java/com/example/*.java"]),
)
この例では、ProjectRunner
ターゲットが Bazel の組み込みツールをインスタンス化します。
java_binary
ルール。このルールは、Bazel に次の動作を指示します。
.jar
ファイルとラッパー シェル スクリプト(どちらもターゲットにちなんで名付けられています)をビルドします。
ターゲットの属性は、依存関係とオプションを明示的に記述します。
name
属性は必須ですが、多くの属性は省略可能です。たとえば、
ProjectRunner
ルール ターゲット。name
はターゲットの名前、srcs
は指定します。
Bazel がターゲットのビルドに使用するソースファイル。main_class
で、
main メソッドを含むクラス。(先ほどの例で、
glob を使用して一連のソースファイルを Bazel に渡します。
(1 つずつリストするのではなく)
プロジェクトをビルドする
サンプル プロジェクトをビルドするには、java-tutorial
ディレクトリに移動します。
次のコマンドを実行します。
bazel build //:ProjectRunner
ターゲット ラベルの //
部分は、ワークスペースのルート(この場合はルート自体)を基準とした BUILD
ファイルの場所であり、ProjectRunner
は BUILD
ファイル内のターゲット名です。(
ターゲット ラベルの詳細については、このチュートリアルの最後に記載してください)。
Bazel は、次のような出力を生成します。
INFO: Found 1 target...
Target //:ProjectRunner up-to-date:
bazel-bin/ProjectRunner.jar
bazel-bin/ProjectRunner
INFO: Elapsed time: 1.021s, Critical Path: 0.83s
これで、最初の Bazel ターゲットがビルドされました。Bazel の場所のビルド
ワークスペースのルートの bazel-bin
ディレクトリに出力されます。探す
Bazel の出力構造を理解してください。
新しくビルドされたバイナリをテストします。
bazel-bin/ProjectRunner
依存関係グラフを確認する
Bazel では、ビルド依存関係を BUILD ファイルで明示的に宣言する必要があります。 Bazel はこれらのステートメントを使用して、プロジェクトの依存関係グラフを作成します。 正確な増分ビルドが可能になります。
サンプル プロジェクトの依存関係を可視化するために、サンプル プロジェクトの依存関係を 依存関係グラフの Cloud Storage バケットを ワークスペースのルート:
bazel query --notool_deps --noimplicit_deps "deps(//:ProjectRunner)" --output graph
上記のコマンドは、ターゲット //:ProjectRunner
のすべての依存関係(ホストと暗黙的な依存関係を除く)を検索し、出力をグラフとしてフォーマットするように Bazel に指示します。
次に、テキストを GraphViz に貼り付けます。
ご覧のとおり、このプロジェクトには、追加の依存関係なしで 2 つのソースファイルをビルドする単一のターゲットがあります。
ワークスペースを設定し、プロジェクトをビルドして依存関係を確認したら、複雑さを追加できます。
Bazel ビルドの改良
小規模なプロジェクトでは 1 つのターゲットで十分ですが、大規模なプロジェクトは複数のターゲットとパッケージに分割して、高速な増分ビルド(変更された部分のみを再ビルド)を可能にし、プロジェクトの複数の部分を一度にビルドしてビルドを高速化することをおすすめします。
複数のビルド ターゲットを指定する
サンプル プロジェクトのビルドは 2 つのターゲットに分割できます。java-tutorial/BUILD
ファイルの内容を次のように置き換えます。
java_binary(
name = "ProjectRunner",
srcs = ["src/main/java/com/example/ProjectRunner.java"],
main_class = "com.example.ProjectRunner",
deps = [":greeter"],
)
java_library(
name = "greeter",
srcs = ["src/main/java/com/example/Greeting.java"],
)
この構成では、Bazel はまず greeter
ライブラリをビルドし、次に ProjectRunner
バイナリをビルドします。java_binary
の deps
属性は、Bazel に次のことを通知します。
ProjectRunner
バイナリをビルドするには、greeter
ライブラリが必要です。
プロジェクトの新しいバージョンをビルドするには、次のコマンドを実行します。
bazel build //:ProjectRunner
Bazel は次のような出力を生成します。
INFO: Found 1 target...
Target //:ProjectRunner up-to-date:
bazel-bin/ProjectRunner.jar
bazel-bin/ProjectRunner
INFO: Elapsed time: 2.454s, Critical Path: 1.58s
新しくビルドされたバイナリをテストします。
bazel-bin/ProjectRunner
ここで ProjectRunner.java
を変更してプロジェクトを再ビルドすると、Bazel のみが
そのファイルを再コンパイルします。
依存関係グラフを見ると、ProjectRunner
が
入力は以前と同じですが、ビルドの構造は異なります。
これで、2 つのターゲットを持つプロジェクトがビルドされました。ProjectRunner
ターゲットのビルド
2 つのソースファイルがあり、他の 1 つのターゲット(:greeter
)に依存。
追加のソースファイルです。
複数のパッケージを使用する
プロジェクトを複数のパッケージに分割しましょう。src/main/java/com/example/cmdline
ディレクトリを見ると、BUILD
ファイルとソースファイルも含まれていることがわかります。そのため、Bazel から見ると、ワークスペースには //src/main/java/com/example/cmdline
と //
の 2 つのパッケージが含まれています(ワークスペースのルートに BUILD
ファイルがあるため)。
src/main/java/com/example/cmdline/BUILD
ファイルを確認します。
java_binary(
name = "runner",
srcs = ["Runner.java"],
main_class = "com.example.cmdline.Runner",
deps = ["//:greeter"],
)
runner
ターゲットは、//
パッケージの greeter
ターゲット(ターゲットラベル //:greeter
)に依存しています。Bazel は deps
属性を通じてこれを認識します。依存関係グラフを見てみましょう。
ただし、ビルドを成功させるには、runner
ターゲットを明示的に指定する必要があります。
目標に対する//src/main/java/com/example/cmdline/BUILD
の公開設定
visibility
属性を使用する //BUILD
。これは、デフォルトではターゲットが同じ BUILD
ファイル内の他のターゲットにのみ表示されるためです。(Bazel は、ターゲットの公開設定を使用して、実装の詳細を含むライブラリが公開 API に漏洩するなどの問題を防ぎます)。
これを行うには、visibility
属性を greeter
ターゲットに追加します。
java-tutorial/BUILD
を次のように変更します。
java_library(
name = "greeter",
srcs = ["src/main/java/com/example/Greeting.java"],
visibility = ["//src/main/java/com/example/cmdline:__pkg__"],
)
これで、root で次のコマンドを実行し、新しいパッケージをビルドできます。 できます。
bazel build //src/main/java/com/example/cmdline:runner
Bazel は、次のような出力を生成します。
INFO: Found 1 target...
Target //src/main/java/com/example/cmdline:runner up-to-date:
bazel-bin/src/main/java/com/example/cmdline/runner.jar
bazel-bin/src/main/java/com/example/cmdline/runner
INFO: Elapsed time: 1.576s, Critical Path: 0.81s
新しくビルドしたバイナリをテストします。
./bazel-bin/src/main/java/com/example/cmdline/runner
これで、それぞれ 1 つのターゲットを含む 2 つのパッケージとしてビルドするようにプロジェクトを変更し、それらの間の依存関係を把握できました。
ラベルを使用してターゲットを参照する
BUILD
ファイルとコマンドラインで、Bazel はターゲット ラベルを使用して参照します。
ターゲット(例: //:ProjectRunner
)
//src/main/java/com/example/cmdline:runner
。構文は次のとおりです。
//path/to/package:target-name
ターゲットがルール ターゲットの場合、path/to/package
は BUILD
ファイルを含むディレクトリのパスであり、target-name
は BUILD
ファイルでターゲットに付けた名前(name
属性)です。ターゲットがファイルの場合
target の場合、path/to/package
はパッケージのルートへのパスです。
target-name
は、フルパスを含むターゲット ファイルの名前です。
リポジトリ ルートでターゲットを参照する場合、パッケージパスは空になります。
//:target-name
を使用してください。同じ BUILD
ファイル内のターゲットを参照する場合は、//
ワークスペース ルート識別子をスキップして :target-name
のみを使用することもできます。
たとえば、java-tutorial/BUILD
ファイル内のターゲットの場合、ワークスペースのルート自体がパッケージ(//
)であり、2 つのターゲットラベルが単純に //:ProjectRunner
と //:greeter
であるため、パッケージパスを指定する必要はありませんでした。
ただし、//src/main/java/com/example/cmdline/BUILD
ファイル内のターゲットの場合は、//src/main/java/com/example/cmdline
のフルパッケージパスを指定し、ターゲットラベルは //src/main/java/com/example/cmdline:runner
でした。
デプロイ用に Java ターゲットをパッケージ化する
次に、すべてのランタイム依存関係を使用してバイナリをビルドし、デプロイ用に Java ターゲットをパッケージ化しましょう。これにより、Cloud Shell の外部でバイナリを 開発環境です。
すでに説明したように、java_binary ビルドルールが
.jar
とラッパー シェル スクリプトを生成します。詳しくは、
このコマンドを使用した runner.jar
:
jar tf bazel-bin/src/main/java/com/example/cmdline/runner.jar
内容は次のとおりです。
META-INF/
META-INF/MANIFEST.MF
com/
com/example/
com/example/cmdline/
com/example/cmdline/Runner.class
ご覧のとおり、runner.jar
には Runner.class
が含まれていますが、その依存関係である Greeting.class
は含まれていません。Bazel が生成する runner
スクリプトが greeter.jar
を追加する
クラスパスに渡されるため、このままにするとローカルで実行されますが、
別のマシンではスタンドアロンで実行できません幸いなことに、java_binary
ルールは
を使用すると、デプロイ可能な自己完結型のバイナリを構築できます。これをビルドするには、
_deploy.jar
をターゲット名に追加します。
bazel build //src/main/java/com/example/cmdline:runner_deploy.jar
Bazel は、次のような出力を生成します。
INFO: Found 1 target...
Target //src/main/java/com/example/cmdline:runner_deploy.jar up-to-date:
bazel-bin/src/main/java/com/example/cmdline/runner_deploy.jar
INFO: Elapsed time: 1.700s, Critical Path: 0.23s
これで runner_deploy.jar
がビルドされました。必要なランタイム依存関係が含まれているため、開発環境から独立して実行できます。前と同じコマンドを使用して、このスタンドアロン JAR の内容を確認します。
jar tf bazel-bin/src/main/java/com/example/cmdline/runner_deploy.jar
コンテンツには、実行に必要なクラスがすべて含まれています。
META-INF/
META-INF/MANIFEST.MF
build-data.properties
com/
com/example/
com/example/cmdline/
com/example/cmdline/Runner.class
com/example/Greeting.class
関連情報
詳しくは以下をご覧ください。
rules_jvm_external: Maven の推移的な依存関係を管理するためのルールを使用します。
操作の詳細について確認する外部依存関係 作成することにしました
Bazel の詳細に関するその他のルール。
ビルドを開始する方法に関する C++ ビルドのチュートリアル Bazel を使用した C++ プロジェクト。
Android アプリのチュートリアルと iOS アプリのチュートリアル: Bazel を使用して Android と iOS 用のモバイルアプリのビルドを開始する。
ご利用をお待ちしております。