docs community blog github
Edit

Buildpacks

チュートリアルでコンテナイメージを作成するために実行した pack build コマンドは、次のような出力をしていたはずです。

...
===> DETECTING
paketo-buildpacks/node-engine 0.1.1
paketo-buildpacks/npm-install 0.2.0
paketo-buildpacks/npm-start   0.0.2
...
===> BUILDING
Paketo Node Engine Buildpack 0.1.1
...
Paketo NPM Install Buildpack 0.2.0
...
Paketo NPM Start Buildpack 0.0.2
...

このドキュメントでは出力している内容の意味を説明し、Buildpack が実行可能なコンテナイメージをビルドするために必要な依存対象をどのように検出しているのか説明します。

Buildpack とは何か

Buildpack はアプリケーションのソースコードを調査し、依存対象を特定、収集します。 そして、依存対象をレイヤーとして積み重ねた、OCI に準拠したコンテナイメージを作成します。

Paketo Buildpack は利用者の要求するプログラミング言語のランタイムを提供します

それぞれの Buildpack は単一の依存対象を提供する、独立したモジュールです。 複数の Buildpack を組み合わせることで、アプリケーションの要求する全ての依存対象を提供します。

Buildpack はアプリケーションのソースコードを 検出(detect)構築(build) の2段階のフェーズで処理します。

検出フェーズ

detect フェーズでは、アプリケーションのコンテナイメージに含めなければならない依存対象を特定する印を発見するため、ソースコードを調査します。

チュートリアルで実行した pack build コマンドの出力より、paketo-buildpacks/npm-install が使われていることが分かるでしょう。 これは、NPM Install Buildpack がソースコードから package.json ファイルを発見するようになっているからです。 これを、検出基準(detection criteria)と呼びます。 サンプルリポジトリのアプリケーションには package.json が含まれているため、NPM Install Buildpack の検出は成功したのです。

それぞれの Buildpack は担当する依存対象に応じた独自の検出基準を実装しています。 検出に成功した Buildpack は、その Buildpack が必要とする依存対象(requires)と、後に続く build フェーズへ提供する依存対象(provides)からなる契約(contract)を返します。

構築フェーズ

build フェーズでは、detect フェーズに与えられた契約を満たすことで、最終的なコンテナイメージの構築に参加します。 コンテナイメージに、依存対象の実行可能ファイル(例えば Node.js のエンジン)を含むレイヤーを追加する場合もありますし、単純にコマンドを実行するだけレイヤーを追加する場合もあります(例えば npm install)。

チュートリアルで実行した pack build コマンドの出力には、“BUILDING” ヘッダーの後に、NPM Install Buildpack が構築フェーズで実行した処理の出力が含まれています。 具体的には、アプリケーションの依存ライブラリをインストールするため npm install コマンドを実行しています。 その後、NPM Start Buildpack が ndoe server.js をコンテナイメージの起動コマンドに設定しているのが分かります。

次の図は、最終的なコンテナイメージを構成するレイヤーに、Buildpack がどのように寄与しているのか示しています。

Final app image

Buildpack について詳しく知りたければ buildpacks.io を参照してください。

コンポーネント Buildpacks

Paketo は明確な責務を定義したさまざまなコンポーネントとしての Buildpack を提供しています。 コンポーネント Buildpack は、上流の Buildpack が生成したレイヤー(貢献)を必要とする場合もあるし、下流の Buildpack が必要とするレイヤー(貢献)を生成する場合もあります。

例えば、Gradle Buildpack は、ビルド用のコンテナに Gradle をインストールして、Gradle で JVM アプリケーションのパッケージをコンパイルする役割を担当する コンポーネント Buildpack です。 上流の Buildpack が提供する JDK を必要とし、下流の Buildpack にコンパイル済みの JVM アプリケーションを提供します。

合成 Buildpack

複数のコンポーネント Buildpack を合成して、より高水準の Buildpack を構成できます。 合成 Buildpack に含まれるのは、コンポーネント Buildpack の順序付きリストです。 順序が未定義の Buildpack もありますし、特定の依存対象を検出した場合だけ活性化する Buildpack もあります。

Paketo Buildpack はどのように連携しているのか

プログラミング言語別の Paketo Buildpack は 合成 Buildpack です。 ほとんどの一般的なプログラミング言語のランタイムやアプリケーションの構成について、ダウンロードした状態そのままで利用できるようになっています。 それぞれの Buildpack は、複数のコンポーネント Buildpack を順序付きのグループとして構成しています。 それぞれのグループの満足条件は、グループに所属する全ての Buildpack の要求を満たすことです(詳しくは検出フェーズで説明しています)。`

Paketo Buildpack と Cloud Native Buildpack プロジェクトはどのような関係なのか

Paketo Buildpack は Cloud Native Buildpack の仕様 として定義された Buildpack API を実装しています。 Paketo Buildpack の build フェーズと detect フェーズは、CNB のライフサイクル で実行できるように設計されています。

Paketo Buildpack と Cloud Foundry Buildpack は何が違うのか

Paketo Buildpacks CF Buildpacks
どんな環境でも デプロイできる OCI イメージを作成します CF にデプロイするための droplet を作成します
小規模で、合成可能なコンポーネント として開発されています 単一のモノリシックなコードベースです
独自の Buildpack を作成して 簡単に機能追加できます 機能追加するには Buildpack をフォークしなければなりません
Edit

Last modified: September 14, 2021