Overview
任意の言語やソースコードからライブラリやフレームワークを読み取りベストプラクティスに則ってDockerfileすら書かずにイメージを生成してくれる。
Googleがオープンソースとして作成し、GCPではデフォルト使えるようになっている模様
実際に使ってみた感想
https://github.com/GoogleCloudPlatform/buildpacks
公式のチュートリアルに則って使ってみたのですが本当にコマンド一髪で生成されました。
正直凄いと言うより、不思議です。
構成
と言うわけでbuildpackの中身をみていきましょう。
buildpackはbuilderと言う実際にイメージを生成するツールが存在しています。
自分のソースコードに合わせた適切なbuilderを使うことでimageを作ることができるのです。
builder
builderはビルドするための情報や方法が格納されたイメージ,以下の部品によって構成されています。
- buildpack
- lifecycle
- stack
buildpack
ソースコードを検査し、ビルド計画をするための作業単位
最低以下のファイルが必要になる
- buildpack.toml – buildpackのメタデータ?
- bin/detect – buildpackが実行できるかどうかを検証
- bin/build – buildpackを実行するロジック
フェーズとしては以下の二つ
- detect
buildpackの内容と実際のソースコードが合致しているかどうかを逐次的にみていく
例えばnpm buildpackならpackage.jsonを見る
- build
buildpackが実際にimageを作っていく。この時に、環境変数を設定し、バイナリを埋め込み(ruby,python,php),依存関係を解決する(bunble installなど)
lifecycle
複数のbuildpackを連携させて最終的なimageを作り出す
フェーズは以下の４つ
- Detection – buildするためにbuildpackのグループを探索する
- Analysis – build か export フェーズに最適化に使うかもしれないファイルを復活させる ---?
- Build – コンテナの中で実行可能なパッケージとしてソースコードを変換する
- Export – 最終的な OCI(open container initiative) image を作る。 (OCIとはコンテナイメージのフォーマットの模様)
stack
実行環境やビルド時に使用する lifescycleを提供する機能
つまり
ソースコードを解析にそれに該当するbuildpackのグループがコードをコンテナ中で実行可能な形に変換していく。
それを元にして、環境変数やビルド時に情報を埋め込みながら最終的なイメージへ出力していくと言う感じっぽいです。
逆に言うと、解析できるbuilderがないとイメージへの変換が出来ないようです。
そのため。OSSのbuilderも存在しているようです。
https://github.com/cloudfoundry/ruby-buildpack
最後に
雑にまとめましたが、対応している言語であれば普通に使えそうです。
試していませんが、buildpackでimageを焼いてそれを元にdocker-composeを使って異なるコンテナ間の処理をかけばさくっとローカル環境が構築できそうです。