BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース GCPが"kaniko"をリリース、特権を持たないコンテナやKubernetes内でのコンテナイメージ構築が可能に

GCPが"kaniko"をリリース、特権を持たないコンテナやKubernetes内でのコンテナイメージ構築が可能に

ブックマーク

原文(投稿日:2018/04/17)へのリンク

読者の皆様へ: 皆様のご要望にお応えするべく、ノイズを削減する機能セットを開発しました。皆様が関心をお持ちのトピックを、EメールとWeb通知で受け取ることができます。新機能をぜひお試しください。

Googleは、特権のないコンテナやKubernetesクラスタ内でコンテナイメージを構築するオープンソースツール “kaniko”をリリースした。kanikoは指定されたDockerfileからイメージを構築するが、Dockerデーモンには依存せず、各コマンドをすべてユーザスペース内で実行し、結果として変更されたファイルシステムをスナップショットする。

標準のDockerfileからイメージを構築する場合、一般的にはDockerデーモンへのアクセスを要する。そのためには、実行中のマシンでのrootアクセス権が必要だ。kanikoのリリースを発表したGoogle Cloud Platformのブログ記事によると、例えばKubernetesクラスタのように、簡単かつセキュアにDockerデーモンを公開できない環境においては、これがコンテナイメージの構築を難しくする場合がある。

これらの問題を克服するため、kanikoでは、rootアクセス権限がなくてもDockerfileからコンテナイメージを構築することが可能になっている。kanikoは標準的なKubernetesクラスタ内(最終イメージをプッシュするために必要な認証情報を格納したKubernetes Secretが必要)、Google Container Builder、あるいはDockerとgcloud SDKを用いてローカルに実行することができる。

kanikoはDockerfile、ビルドコンテキスト、最終イメージをプッシュするレジストリ名の3つを引数とするコンテナイメージとして実行される。このイメージはスクラッチイメージから構築され、静的なGo言語バイナリとイメージをプッシュおよびプルするために必要な構成ファイルのみが含まれる。kanikoエグゼキュータは指定されたベースイメージのファイルシステムをフェッチして、コンテナファイルシステムのルートに抽出する。ここで言う“ベースイメージ”とは、指定されたDockerfile内のFROMで定義されたイメージである。

次にkanikoは、指定された順序でDockerfileコマンドを実行し、各コマンド実行後にファイルシステムのスナップショットを取得する。スナップショットは、ファイルシステムを走査して、メモリに保存されている以前の状態と比較する方法で、ユーザスペース内で生成される。ファイルシステムの変更は新たなレイヤとしてベースイメージに追加され、関連する変更がイメージのメタデータに施される。Dockerfile内の全コマンドの実行が終了すると、エグゼキュータは、新たに構築したイメージを対象レジストリにプッシュする。上記のステップはすべて、エグゼキュータイメージ内のユーザスペースで実行される。これにより、マシンへの特権アクセスを回避、すなわち“DockerデーモンあるいはCLIは関与しない”。

 

kaniko container image build flow
kanikoコンテナのイメージ構築フロー(GCPブログより引用)

 

Dockerfileコマンドの大部分はkanikoで実行可能だが、現時点でSHELL、HEALTHCHECK、STOPSIGNAL、ARGは例外となっている。マルチステージDockerfileも現時点ではサポート対象外だ。いずれの制限についても現在、作業が進行中だとkanikoチームは述べている。

kanikoと同類のツールとしては、imgorca-buildbuildahFTLBazel rule_dockerなどがある。imgはコンテナ内から非rootユーザとして実行可能だが、ネストしたコンテナを生成するため、imgコンテナは“RawProcアクセス”を持つ必要がある(kanikoはネストしたコンテナを生成しないので、RawProcアクセスを必要としない)。orca-buildはDockerfileからのイメージ構築をrunCに依存しているため、コンテナ内では実行できない。またbuildahは、Dockerデーモンが実行するのと同じ権限を必要とする。

FTLとBazelは、イメージのサブセットのためのDockerイメージを可能な限り速く作成することを目的としている。kanikoのREADMEには、“これらのツールは特殊な‘高速パス’として、kanikoが提供する一般的なDockerfileのサポートと併用されるものと考えられます”、と説明されている。

kanikoのイメージ構築プロセスがコンテナ開発のビルドとデプロイのライフサイクル全体にどのように一致しているのか、興味のある読者は、以前のInfoQのニュース項目である “Googleが“Skaffold” – Kubernetesでの継続的デプロイメントを促進するツールをリリース”に、この分野のツールや提案プロセスが紹介されている。

kanikoのGitHubプロジェクトにあるREADME.mdファイルには、このツールはまだ実運用レベルではないため、コントリビューションや機能要求、バグ報告を歓迎する旨が述べられている。今回のリリースに関する詳細情報は、Google Cloud Platformブログの記事 “Introducing kaniko: Build container images in Kubernetes and Google Container Builder without privileges”にある。

この記事を評価

採用ステージ
スタイル

この記事に星をつける

おすすめ度
スタイル

BT