Docker 以上の 8 つのオープンソース コンテナ管理ソリューション

Docker は 2013 年に誕生し、コンテナの概念を普及させました。そのため、ほとんどの人は今でもコンテナの概念を「Docker コンテナ」と同一視しています。

Docker は最初に試したことで、新規参入者が従うべき標準を設定しました。たとえば、Docker にはシステム イメージの大規模なライブラリがあります。すべての代替手段は、Docker の基盤となるスタック全体の 1 つ以上の部分を変更する際に、同じイメージ形式を使用する必要があります。

[[410087]]

この間、新しいコンテナ標準が登場し、コンテナ エコシステムはさまざまな方向に進化しました。現在、Docker 以外にもコンテナを使用する方法はたくさんあります。

この記事では、以下の内容を取り上げます。

• コンテナの技術的基盤としての Chroot、cgroup、名前空間
• Dockerのベースとなるソフトウェアスタックを定義する
• Docker と Kubernetes が遵守する必要がある標準について説明します。
• 元の Docker コンテナを、より優れた、より安全な機能を備えたコンポーネントに置き換える代替ソリューションを紹介します。

コンテナソフトウェアスタック

Chroot 呼び出し、cgroup、名前空間などの Linux 機能により、コンテナーは他のすべてのプロセスから分離して実行され、ランタイム セキュリティが確保されます。

クルート

Docker のようなすべてのテクノロジーは、Unix 系オペレーティング システム (OS) のルート ディレクトリから生まれます。ルート ディレクトリの上には、ルート ファイル システムとその他のディレクトリがあります。

ルート ディレクトリでの不要な削除はオペレーティング システム全体に影響を及ぼす可能性があるため、長期的には危険です。そのために、システムコール chroot() が存在します。レガシー ソフトウェアを実行するためのルート ディレクトリや、データベースを格納するためのルート ディレクトリなど、追加のルート ディレクトリを作成します。

これらすべての環境では、chroot は実際のルート ディレクトリのように見えますが、実際には、/ で始まるものにパス名を追加するだけです。実際のルート ディレクトリは依然として存在し、すべてのプロセスは指定されたルート ディレクトリ外の任意の場所を参照できます。

Linux cgroups

コントロール グループ (cgroups) は、2008 年のバージョン 2.6.24 以降の Linux カーネルの機能です。cgroups は、複数のプロセスのシステム リソース (メモリ、CPU、ネットワーク、I/O) の使用を同時に制限、分離、測定します。

ユーザーがサーバーから大量のメールを送信できないようにしたいとします。メモリ制限が 1GB、CPU 使用率が 50% の cgroup を作成し、アプリケーションのプロセス ID をグループに追加しました。これらの制限に達すると、システムは電子メールの送信プロセスを制限します。ホスティング ポリシーによっては、プロセスが終了する場合もあります。

名前空間

Linux 名前空間は、もう 1 つの便利な抽象化レイヤーです。名前空間を使用すると、それぞれが独自のネストされた「サブツリー」を持つプロセスの階層を多数持つことができます。名前空間はグローバル リソースを使用し、それを自身のリソースであるかのようにメンバーに提示できます。

具体的には、Linux システムはプロセス識別子 (PID) 1 から開始し、他のすべてのプロセスはそのツリーに含まれます。 PID 名前空間を使用すると、独自の PID 1 プロセスを持つ新しいツリーを拡張できます。現在、値が 1 の PID が 2 つあり、各名前空間は独自の名前空間を生成でき、同じプロセスに複数の PID を接続できます。

子名前空間内のプロセスは親の存在を認識しませんが、親名前空間は子名前空間全体にアクセスできます。

名前空間には、cgroup、IPC、ネットワーク、マウント、PID、ユーザー、UTS の 7 種類があります。

ネットワーク名前空間

一部のリソースは不足しています。慣例により、一部のポートには事前定義された役割があり、他の用途には使用しないでください。たとえば、ポート 80 は HTTP 呼び出しのみを処理し、ポート 443 は HTTPS 呼び出しのみを処理します。共有ホスティング環境では、2 つ以上のサイトがポート 80 からの HTTP 要求をリッスンできます。ポートを取得した最初のサイトでは、他のアプリケーションがそのポート上のデータにアクセスすることを許可しません。最初のアプリケーションはインターネット上で表示されますが、他のすべてのアプリケーションは表示されません。

解決策は、ネットワーク名前空間を使用することです。これにより、内部プロセスは異なるネットワーク インターフェイスを認識するようになります。

あるネットワーク名前空間では同じポートが開いている一方で、別のネットワーク名前空間ではそのポートが閉じられている場合があります。これを行うには、同時に複数の名前空間に属する追加の「仮想」ネットワーク インターフェイスを使用する必要があります。また、物理デバイスに到着したリクエストを対応する名前空間とその中のプロセスに接続するために、中間にルーター プロセスも存在する必要があります。

複雑？そのため、Docker や同様のツールは非常に人気があります。それでは、Docker とその代替手段を紹介しましょう。

Docker: 誰でも使えるコンテナ

コンテナがクラウド コンピューティングの世界を席巻する前は、仮想マシンが大流行していました。 Windows マシンを持っていて、iOS 用のモバイル アプリを開発したい場合は、新しい Mac を購入するか、Windows ハードウェアに Mac の仮想マシンをインストールすることができます。仮想マシンは扱いにくい場合もあり、不要なリソースを消費することが多く、起動に時間がかかることもよくあります (最大 1 分)。

コンテナは、オペレーティング システム、データベース、イメージ、アイコン、ソフトウェア ライブラリ、コード、その他の必要なコンポーネントなど、プログラムを実行するために必要なすべてのものが揃った標準ソフトウェア ユニットです。コンテナは、他のすべてのコンテナやオペレーティング システム自体からも分離して実行されます。コンテナは仮想マシンに比べて軽量なので、すぐに起動でき、簡単に置き換えることができます。

分離と保護を保って動作するには、コンテナは Chroot、cgroup、および名前空間に基づいている必要があります。

コンテナのイメージは、実際のマシン上でアプリケーションを形成するテンプレートです。 1 つのイメージに基づいて、可能な限り多くのコンテナを作成できます。 Dockerfile と呼ばれるテキスト ファイルには、イメージを組み立てるために必要なすべての情報が含まれています。

Docker によってもたらされた真の革命は、Docker イメージ リポジトリの作成と Docker エンジンの開発でした。これらの画像はどこでも同じように実行されます。広く採用された最初のコンテナ イメージとして、これは、後続のすべての参入者が注意しなければならない暗黙の世界標準を形成しました。

CRIとOCI

OCI は Open Container Initiative の略で、イメージとコンテナの仕様を公開しています。これは 2015 年に Docker によって開始され、Microsoft、Facebook、Intel、VMWare、Oracle などの多くの業界大手によって採用されてきました。

OCI は、コンテナを直接使用したり、コンテナを作成および実行したりできる runc と呼ばれる仕様の実装も提供します。

コンテナ ランタイム インターフェース (CRI) は、Kubernetes がコンテナ ランタイムと対話する方法を定義する Kubernetes API です。また、標準化されているため、どの CRI 実装を採用するかを選択できます。

CRI と OCI を使用したコンテナ向けソフトウェア スタック

Linux は、コンテナを実行するソフトウェア スタックの最も基本的な部分です。

Containerd と CRI-O はどちらも CRI および OCI 仕様に準拠していることに注意してください。 Kubernetes の場合、これは、ユーザーが違いに気付かずに Containerd または CRI-O のいずれかを使用できることを意味します。また、これから説明する他の代替手段も使用できます。これはまさに、OCI や CRI などのソフトウェア標準の作成と採用の目的です。

Docker ソフトウェア スタック

Docker のソフトウェア スタックには以下が含まれます。

• docker-cli、開発者向け Docker コマンドライン インターフェース
• containerd は元々 Docker によって作成され、後に独立したプロジェクトとして開始されました。 CRI仕様を実装している
• OCI仕様を実装するrunc
• コンテナ (chroot、cgroups、名前空間などを使用)

Kubernetes のソフトウェア スタックはほぼ同じです。 Kubernetes は Containerd ではなく、Red Hat/IBM などが作成した CRI の実装である CRI-O を使用します。

コンテナ

containerd は Linux および Windows 上でデーモンとして実行されます。イメージをロードし、コンテナとして実行し、基盤となるストレージを監視し、コンテナのランタイムとライフサイクル全体を管理します。

Containerd は 2014 年に Docker の一部として誕生し、2017 年に Cloud Native Computing Foundation (CNCF) のプロジェクトとなり、2019 年初頭に卒業しました。Containerd の使用に関するヒントを知りたい場合は、次の記事を参照してください。

containerd イメージリポジトリを構成するための完全なガイド

ランク

runc は OCI 仕様のリファレンス実装です。コンテナとその中のプロセスを作成して実行します。 cgroup や名前空間などの低レベルの Linux 機能を使用します。

runc の代替には、Kata-Runtime、GVisor、CRI-O などがあります。

Kata-Runtime は、ハードウェア仮想化を使用して、OCI 仕様を個別の軽量 VM として実装します。ランタイムは OCI、CRI-O、Containerd と互換性があるため、Docker および Kubernetes とシームレスに連携します。

Google の gVisor は、独自のカーネルを含むコンテナを作成します。これは、Docker および Kubernetes と統合する runsc というプロジェクトを通じて OCI を実装します。独自のカーネルを持つコンテナはカーネルを持たないコンテナよりも安全ですが、万能薬ではなく、このアプローチにはリソースの使用コストがかかります。

CRI-O は、Kubernetes 専用に設計されたコンテナ スタックであり、CRI 標準の最初の実装です。任意のコンテナ レジストリからイメージを取得し、Docker を使用する代わりに軽量な代替手段として使用できます。

現在、コンテナ ランタイムとして runc と Kata Containers をサポートしていますが、他の OC 互換ランタイムもプラグインできます (少なくとも理論上は)。

これは CNCF インキュベーティング プロジェクトです。

ポッドマン

Podman はデーモンを使用しない Docker の代替品です。そのコマンドは、意図的に Docker との互換性を最大限に高めており、CLI インターフェースでエイリアスを作成し、「podman」の代わりに「Docker」という単語を使用できるようになりました。

Podman は Docker を置き換えることを目的としているので、同じコマンドセットを使い続けるのは理にかなっています。 Podman は Docker の 2 つの問題を改善しようとします。

まず、Docker は常に内部デーモンを使用して実行されます。デーモンはバックグラウンドで実行される単一のプロセスです。それが失敗すると、システム全体が失敗します。

2 番目に、Docker はルート権限を持つバックグラウンド プロセスとして実行されるため、新しいユーザーにアクセス権を付与すると、実際にはサーバー全体へのアクセス権を付与することになります。

Podman は、オペレーティング システムから直接コンテナーを実行するリモート Linux クライアントです。ルートレスモードで実行することもできます。 DockerHub からイメージをダウンロードし、Docker とまったく同じ方法で、まったく同じコマンドを使用して実行します。

Podman は、root 以外のユーザーとしてコマンドとイメージを実行するため、Docker よりも安全です。一方、Portainer や Watchtower など、Docker 用に開発されていて Podman では利用できないツールも多数あります。 Docker を廃止するということは、以前に確立したワークフローを放棄することを意味します。

Podman のディレクトリ構造は、buildah、skopeo、CRI-I に似ています。その Pod も KubernetesPod と非常によく似ています。

Linux コンテナ: LXC と LXD

LXC (LinuX Containers) は 2008 年にリリースされ、Linux 上の最初のアップストリーム カーネル コンテナーです。 Docker の最初のバージョンでは LXC を使用していましたが、その後の開発で runc が実装されたため LXC は削除されました。

LXC の目標は、単一の Linux カーネルを使用して、制御ホスト上で複数の分離された Linux 仮想環境を実行することです。これを行うには、仮想マシンを起動する必要なく cgroups 機能を使用します。また、名前空間を使用して、アプリケーションを基盤となるシステムから完全に分離します。

LXC は、仮想マシンとほぼ同じようにシステム コンテナーを作成するように設計されていますが、ハードウェアが仮想化されているため、ハードウェアのオーバーヘッドはほとんどありません。

LXC はハードウェアおよびソフトウェア パッケージをエミュレートせず、必要なアプリケーションのみを組み込むため、ほぼベアメタル速度で実行されます。対照的に、仮想マシンにはオペレーティング システム全体が含まれており、ハード ディスク、仮想プロセッサ、ネットワーク インターフェイスなどのハードウェアをエミュレートします。

つまり、LXC は小さくて高速ですが、仮想マシンは大きくて低速です。一方、仮想環境は、すぐに導入できる既成のマシンにパッケージ化することができず、GUI 管理コンソールで管理することが困難です。 LXC には高度な技術的専門知識が必要であり、最適化されたマシンは他の環境と互換性がない可能性があります。

LXC 対 Docker

LXC は Linux 上の強化された chroot のようなもので、生成される「小さな」サーバーは起動が速く、必要な RAM が少なくなります。ただし、Docker にはさらに多くの機能があります。

• マシン間でのポータブルな展開: あるバージョンの Docker を使用して作成されたオブジェクトは、Docker をサポートする他の Linux ホストに転送してインストールできます。
• バージョン管理: Docker は Git のような方法でバージョンを追跡できます。コンテナの新しいバージョンを作成したり、ロールバックしたりできます。
• コンポーネントの再利用: Docker を使用すると、既に作成されたパッケージを新しいパッケージにスタックできます。 LAMP 環境が必要な場合は、そのコンポーネントを一度インストールし、事前に作成された LAMP イメージとして再利用できます。
• Docker イメージ アーカイブ: 専用サイトから数十万の Docker イメージをダウンロードでき、このようなイメージ リポジトリに新しいイメージをアップロードするのは簡単です。

LXC はシステム管理者を対象としていますが、Docker は開発者を対象としています。これが Docker がより人気がある理由です。

翻訳

LXD には、ローカル UNIX ソケットおよびネットワーク (有効な場合) 経由で REST API を公開する特権デーモンがあります。コマンドライン ツールを使用してアクセスすることもできますが、常に REST API 呼び出しを使用して通信します。クライアントがローカル マシン上にあるかリモート サーバー上にあるかに関係なく、機能は同じです。

LXD は、単一のローカル マシンから数千のリモート マシンまで拡張できます。 Docker と同様に、イメージベースであり、すべての一般的な Linux ディストリビューションのイメージが利用可能です。 Ubuntu の開発元である Canonical 社は LXD の開発に資金を提供しているため、LXD は常に最新バージョンの Ubuntu やその他の同様の Linux オペレーティング システムで実行されます。 LXD は、OpenNebula および OpenStack 標準とシームレスに統合できます。

技術的には、LXD は LXC をベースに構築されています (どちらも同じ liblxc ライブラリと Go 言語を使用してコンテナーを作成します) が、LXD はユーザー エクスペリエンスの向上を目指しています。

Docker は永遠に存在し続けるのでしょうか?

Docker には 1,100 万人の開発者、700 万のアプリケーション、毎月 130 億のイメージダウンロードがあります。 Docker が依然としてリーダーであると言うのは控えめな表現でしょう。ただし、この記事で説明したように、通常は互換性の問題なしに、Docker ソフトウェア スタックの 1 つ以上の部分を置き換えることができる製品がすでに多数存在します。また、Docker が提供するサービスと比較すると、他のソフトウェアの主な目的はセキュリティです。