Buildpacks

Dockerfile を書かずに、アプリのソースコードを本番向け OCI イメージへ変換する。

カテゴリ: App Definition & GitOps
CNCF 成熟度: Incubating
言語: Go
ライセンス: Apache-2.0
リポジトリ: buildpacks/pack
ドキュメント基準コミット: 2df3b8c (v0.40.7)

これは何か

Cloud Native Buildpacks (CNB) は、ソースコードを実行可能な OCI コンテナイメージへ変換する仕様とツール群である。CLI をアプリのディレクトリに向けると、言語を検出し、依存を取得し、イメージを生成する。Dockerfile は不要だ。

エコシステムは 3 層に分かれる。本リポジトリの pack CLI は開発者向けのプラットフォーム実装である。自分でイメージをビルドはしない。builder イメージと lifecycle バイナリ群をコンテナとして起動し、detect / analyze / restore / build / export の各フェーズを駆動する。実際のビルドロジックは言語ごとの buildpack にあり、参照ビルドエンジンは別リポジトリ buildpacks/lifecycle にある。

CNB は、Heroku・Cloud Foundry・Google App Engine などで分裂していた buildpack エコシステムを再統一するために存在する。この標準は OCI イメージフォーマットの上にベンダ中立な platform-to-buildpack 契約を定義し、同じ buildpack をどこでも動かせるようにし、レイヤ rebase でベースイメージを差し替えられるようにする。

いつ使うか

Dockerfile をサービスごとに保守せず、ソースから再現性あるコンテナイメージを得たいとき。
複数言語のサービスを多数運用し、単一の builder でまかないたいとき。
run イメージを rebase することで、全アプリを再ビルドせずに OS レイヤをまとめてパッチしたいとき。
全レイヤを細かく制御したいときは不向きで、BuildKit で手書きの Dockerfile を使う方が直接的だ。
Jib (JVM) や ko (Go) のような特化ツールで十分な単一言語の現場には不向き。

このディープダイブの構成

歴史: 起源・マイルストーン・存在理由。
アーキテクチャ: コンポーネントとビルドの流れ。
採用とエコシステム: 誰が動かし、周辺に何があるか。
内部実装: ソースから読んだ重要なコードパス。
はじめに: インストールと最初の動作セットアップ。

Buildpacks ​

これは何か ​

いつ使うか ​

このディープダイブの構成 ​

出典 ​

Buildpacks

これは何か

いつ使うか

このディープダイブの構成

出典