22時に寝て0時に起きてやや吐き気で苦しんで4時に起きて7時に起きた。夜遅くに食べてないのに調子悪かった。

docker image のマルチプラットフォーム対応⌗

やぎさんが docker buildx でマルチプラットフォームのイメージを作成する の記事を書いてて buildx プラグインがあることを知った。ちょうどいまお仕事でコンテナベースのプロダクトを開発している。まずはオンプレミス向けが対象なので amd64 でビルドしていた。今後はクラウド向けにも提供していくので arm64 ビルドもいずれ追加しないといけないと考えていた。ちょうどリリースを終えて調査時間の余裕があるのでこの機会に buildx について調べてみることにした。

Docker Engine 23.0 release notes をみると次のように書いてある。

  • Set Buildx and BuildKit as the default builder on Linux. moby/moby#43992
    • Alias docker build to docker buildx build. docker/cli#3314
    • The legacy builder can still be used by explicitly setting DOCKER_BUILDKIT=0.
    • There are differences in how BuildKit and the legacy builder handle multi-stage builds. For more information, see Multi-stage builds.

23 からデフォルトのビルダーとして buildx が使われるようになっているらしい。Building multi-platform images を一通り読んで試してみた。

buildx ではカスタムビルダーを定義して複数プラットフォーム向けの docker image を一緒にビルドできる。このとき個々のビルド環境を builder instance と呼び、ビルド環境を抽象した概念として扱われている。マルチプラットフォーム対応の文脈で言えば amd64 や arm64 のビルド環境をそれぞれに作る。例えば amd64 のマシン上で arm64 のビルド環境を作るときは qemu を使ってエミュレーションしたビルド環境を用意したりもできる。builder instance はカスタムビルダーで制御する。

$ docker buildx create --name mybuilder --platform linux/amd64,linux/arm64
$ docker buildx ls
NAME/NODE    DRIVER/ENDPOINT             STATUS   BUILDKIT PLATFORMS
mybuilder    docker-container
  mybuilder0 unix:///var/run/docker.sock inactive          linux/amd64*, linux/arm64*

ここで作ったカスタムビルダーの driver は、デフォルトビルダーの docker ではなく、docker-container になる。おそらく builder instance の実体であるビルド環境がコンテナ上に構築されるのだと思う。これらの builder instance を使ってビルドされる。カスタムビルダーをデフォルトで使うには次のように実行する。

$ docker buildx use mybuilder

このカスタムビルダーを使って docker image をビルドする。カスタムビルダー側にプラットフォームの設定をもっているので --platform は指定しなくてもよいけど、明示した方がわかりやすいだろう。

$ docker buildx build --platform linux/amd64,linux/arm64 -t myimage:latest .

ビルドの処理は進んでいたが、正常終了しなかったので途中でやめた。なにか設定の漏れがあるかもしれないが、だいたいの雰囲気はつかめた。

ここでいま gitlab ci/cd 環境では kaniko というツールを使って docker image をビルドしている。そもそも kaniko と buildx の違いもわからなくなって README を読み返すと次のようなことが書いてあった。

kaniko は Docker デーモンに依存せず、Dockerfile 内の各コマンドを完全にユーザースペースで実行します。これにより、標準的な Kubernetes クラスタのように、Docker デーモンを簡単かつ安全に実行できない環境でもコンテナイメージを構築することができます。

ローカルで検証しているとしばしば忘れてしまうが、docker cli を使うには docker daemon を起動しておかないといけない。ci/cd におけるビルド環境がそもそも dokcer で動いていたりすると docker daemon を使えるかどうか (dind: docker in docker) はセキュリティ上の大きな違いになってくる。ci/cd 環境によっては docker daemon が使えないという状況はありえる。そういった環境でも docker image をビルドできるのが kaniko のメリットと言える。

kaniko はマルチプラットフォーム対応なビルドができるのかどうか？issue でもそういった質問がいくつかみつかる。

結論から言うと、kaniko そのものはマルチプラットフォーム対応のビルド機能をもっていない。アーキテクチャごとのビルド環境があればそれぞれビルドするだけになる。しかし、マルチプラットフォーム対応の docker image というのは manifest list というのを作ってコンテナレジストリに push すればよいという仕組みらしい。この manifest を作るためのツールとして manifest-tool というのがある。このツールと組み合わせれば、kaniko でもマルチプラットフォーム対応の docker image をコンテナレジストリに登録できる。実際に試したわけではないので想像で書くが次のような手順だと推測する。

  1. kaniko でそれぞれのプラットフォームの docker image をビルドする
    1. amd64 向けにビルドする => latest-amd64
    2. arm64 向けにビルドする => latest-arm64
  2. ビルドされた複数プラットフォームの docker image に対して manifest-tool でコンテナレジストリに push する
    1. latest- prefix のタグをもつ docker image の manifest list を作る
    2. manifest list を使ってコンテナレジストリへ push する

ci/cd 環境でこういった手順のパイプライン処理やジョブを定義して実行すれば kaniko でもマルチプラットフォーム対応な docker image を push できると思う。