Buildah vs Kaniko: デーモンレスなイメージ build
Docker デーモンなしで Kubernetes/CI コンテナ内でイメージを build したいなら、クラスタ pipeline に最適化された Kaniko を選び、Dockerfile の有無にかかわらずホスト上で柔軟かつスクリプト可能で rootless なイメージ build がしたいなら Buildah を選びましょう。
Buildah と Kaniko はどちらも Docker デーモンなしで OCI/Docker イメージを build します。これは、特権デーモンの実行が望ましくない CI や Kubernetes で重要です。Kaniko (Google 製) はクラスタ内でコンテナとして実行し、Dockerfile を実行してイメージを push するよう作られています。Buildah (Podman/containers プロジェクト製) はホストレベルのツールで、Dockerfile から、あるいはスクリプト可能なステップごとのコマンドでイメージを build し、rootless モードをサポートします。
| Buildah | Kaniko | |
|---|---|---|
| 主な環境 | ホストと CI (rootless 対応可) | クラスタ内 / CI コンテナ |
| デーモン | なし | なし |
| build 入力 | Dockerfile またはスクリプト化されたコマンド | Dockerfile |
| Rootless | あり (十分にサポート) | コンテナとして実行、デーモンなし |
| キャッシュ | レイヤーキャッシュ、mount キャッシュ | リモートのレイヤーキャッシュ (registry) |
| エコシステム | Podman / containers ツール | Kubernetes ネイティブな pipeline |
それぞれが本当に優れている点
Kaniko は Kubernetes ベースの CI で優れます。pod/コンテナとして実行し、デーモンや特権ホストを必要とせず、結果を push するため、クラスタ上の GitLab CI や Tekton に適合します。Buildah は柔軟性と rootless なホスト build で優れます。Dockerfile から build することも、スクリプト内でコマンドごとにイメージを組み立てることもでき、カスタムまたは最小限のイメージに強力で、Podman と自然に組み合わせられます。
CI では
どちらも Docker-in-Docker デーモンのセキュリティとセットアップのコストを回避します。Kaniko はレイヤーを registry にキャッシュするため、以降の build が runner 間でそれらを再利用できます。Buildah はレイヤーおよび mount キャッシュと rootless 実行をサポートし、共有 runner で魅力的です。どちらを選ぶにせよ、CI の build を再現可能にするためにベースイメージの digest を固定しましょう。
正直な注意点
Kaniko は Dockerfile をユーザー空間で実行し、歴史的に一部の Dockerfile 機能やキャッシュ無効化でエッジケースがあったため、build をテストしましょう。Buildah は Linux 中心で Podman エコシステムで最も洗練されています。非 Linux の CI では通常、いずれにせよ Linux コンテナ内で実行します。
結論
Kubernetes やコンテナベースの CI 内でイメージを build し、ドロップイン可能な Dockerfile ビルダーが欲しいなら Kaniko を選びましょう。特に Podman と併用しながら、柔軟でスクリプト可能な rootless のホスト build がしたいなら Buildah を選びましょう。