Linuxコンテナイメージの選び方

Linuxコンテナイメージの比較という記事は、イメージ選択のベストプラクティスについて書いたものだ。アーキテクチャ、セキュリティ、パフォーマンスも要因の一つだが、商用ユーザーはサポートオプションも求めている。

Linuxコンテナを使うと、リソースとプロセスの分離メカニズムであるcgroupsとnamespacesを利用して、カーネル空間とユーザー空間のコンポーネントを別々に管理することができる。SolarisとBSDにもLinuxコンテナと同様の抽象化があるが、本記事ではLinuxコンテナにのみ注目する。コンテナを動かすホストには、OSカーネルとコンテナを動かすのに必要なライブラリとツール一式が含まれている。それに対して、コンテナイメージには、コンテナで配布するアプリケーションを動かすのに必要なライブラリ、インタプリタ、アプリケーションコードが含まれている。これらは基盤となるシステムライブラリよって異なっている。インタプリタ自身もローレベルの言語で書かれているため、これはインタプリタ言語にも当てはまる。

各種コンテナイメージのディスクサイズは、Fedoraで230 MB、Alpine Linuxで4 MBと違っている。しかし、ディストリビューションの選択で考慮すべきことは、サイズだけではない。主要なグループには、Debian/Ubuntu、RHEL、Centos、Fedora、Alpineといったものがある。

コンテナのセキュリティ脆弱性は数多く 報告されている。最近の調査によると、Docker Hubに公開されているDebianコンテナイメージの脆弱性がもっとも少なく、Ubuntuイメージはもっとも多かったという。ただし、この調査のサンプルは、公開されているDockerイメージに限られている。Clairやvulsのようなオープンソースツール、あるいはTwistlockのような商用ツールは、様々なレベルの保護と機能を提供している。ほとんどのベンダーは、そのディストリビューションとWebサーバやデータベースのようなよく使われるソフトウェアにある既知の脆弱性に対するテストを自動化している。コンテナの脆弱性を軽減し最小化するためのオープンソースの取り組みには、ホスト-コンテナ通信に影響を及ぼすものと、そうでない方法によるものの両方（スライド7-9）がある。

glibcのようなコアライブラリとパッケージ形式は、セキュリティとパフォーマンスに影響を及ぼす。glibcとgccのような成熟したライブラリは、長年にわたる利用と大きなユーザーコミュニティのおかげで、堅牢になっている。このことは、コンテナイメージがこれらを利用する大きな理由になっている。しかし、Alpineのような一部のディストリビューションは別のものを使っており、問題を引き起こしていた。

これら3つの基準とは別に、エンタープライズ顧客はライフサイクルとサポートオプションも求めている。RHELとUbuntuには商用サポートオプションがあり、様々な形で利用できるフォーラムを通じたコミュニティサポートがついている。UbuntuとRHELは、ライフサイクルスパン（バグ修正の提供、修正と機能のバックポート、サポートの提供という観点で、そのバージョンがサポートされている期間）の点でリードしている。

結論として、コンテナイメージの選択は、Linuxディストリビューションの選択と似ている。"Distroless"イメージは、このトピックに関する興味深い副産物だ。Distrolessイメージは、アプリケーションとそのランタイム依存関係だけで構成されているイメージだ。Linuxディストリビューションに通常あるシェルやパッケージマネージャのようなプログラムは、まったく入っていない。