コンテナとコンテナランタイムについて

コンテナ技術は仮想化技術であり、よく「ソフトウェア定義の XXX」と呼ばれます。コンテナが登場する前は、仮想マシン技術、つまりソフトウェア定義のハードウェアが広く使用されていました。代表的な製品はVMWareです。私が EMC で働き始めた頃、会社は VMWare の買収がいかに賢明だったかを頻繁に語っていました。当時は仮想マシン技術が非常に普及していました。例えば、ソフトウェアがハードウェアをシミュレートし、ユーザーは未使用のハードウェアやオペレーティングシステムを自分のホスト上で簡単に実行したり、システム全体のスナップショットをファイルとして簡単に移行したりできるので、非常に便利です。

[[337147]]

ただし、仮想マシンはハードウェア全体をシミュレートする必要があり、オーバーヘッドが非常に高くなります。メモリ、CPU、ディスク容量はすべて排他的です。システムアーキテクチャレベルでは、仮想マシン技術は依然として非常に有用ですが、日常的な開発作業では、仮想マシン技術は重すぎます。

ソフトウェアの開発と展開の観点から、次のような仮想化テクノロジが必要です。

• CPU、メモリ、ディスク、ネットワーク、その他のリソースを分離する機能
• リソース使用量と優先順位を制御する機能
• 独立したオペレーティングシステムを実行可能
• 比較的軽いシステムオーバーヘッド
• より便利な管理機能

Unix/Linux の世界では、まず思い浮かぶのは Chroot です。

1. ルート

chroot は Unix システムにおける操作であり、ルート ディレクトリを変更します。 Linux システムでは、デフォルトのディレクトリ構造は `/` で始まります。つまり、ルートで始まります。 chroot を使用した後、システムのディレクトリ構造は指定された場所を `/` の場所として使用します。 Chroot によって作成されたルート ディレクトリは、「chroot jail」(chroot jail、または chroot prison) と呼ばれます。

chroot を実行できるのは root ユーザーのみです。完全にファイルシステム指向ではなく、ネットワークやプロセス制御も含まれる可能性のあるほとんどの Unix システムでは、システム コール インターフェイスを通じて chroot を解除するプログラムが提供されています。

chroot 後、システムによって読み取られるディレクトリとファイルは、古いシステム ルートの下ではなく、新しいルート (つまり、指定された新しい場所) の下に置かれるようになります。したがって、次の 3 つの利点がもたらされます。

• システムのセキュリティを強化し、ユーザーの権限を制限します。 chroot 後、古いシステムのルート ディレクトリ構造とファイルは新しいルートの下ではアクセスできなくなるため、システムのセキュリティが強化されます。これは通常、ログインする前に chroot を使用して実行され、ユーザーが特定のファイルにアクセスできなくなります。
• ユーザー開発を容易にするために、元のシステムから分離されたシステム ディレクトリ構造を確立します。 chroot を使用した後、システムは新しいルートの下のディレクトリとファイルを読み取ります。これは、元のシステム ルートの下のファイルとは無関係なディレクトリ構造です。この新しい環境は、ソフトウェアの静的コンパイルや、システムに関連しない独立した開発をテストするために使用できます。
• システムのルートディレクトリを切り替え、Linux システムと緊急システムを起動するなど。 chroot の役割はシステムのルート位置を切り替えることであり、この役割はシステムの初期ブートディスク処理プロセスで最も顕著であり、システムのルート位置を初期 RAM ディスク (initrd) から切り替えて実際の init を実行します。さらに、システムに何らかの問題が発生した場合には、chroot を使用して一時的なシステムに切り替えることもできます。

しかし、Chroot は前述の要件を満たしていません。 chroot の分離機能は非常に制限されています。 chroot メカニズム自体は、I/O、帯域幅、ディスク領域、CPU 時間などのリソースの使用を制限するようには設計されていません。

前述の要件を達成するには、より強力な仮想化テクノロジが必要であり、それに応じてコンテナが開発されました。

2. コンテナとVM

Linux コンテナと仮想マシンの違いは誰もがよく知っていると思います。ここで簡単に説明しましょう:

それぞれが独自の完全なオペレーティング システムを持つ仮想マシンを使用する従来の仮想化では、仮想マシンに組み込まれたアプリケーションを実行するときにメモリ使用量が必要以上に高くなる可能性があり、仮想マシンがホスト マシンに必要なリソースを使い果たし始める可能性があります。コンテナはオペレーティング システム環境 (カーネル) を共有するため、完全な仮想マシンよりも少ないリソースを使用し、ホスト マシンのメモリへの負荷を軽減します。

従来の仮想マシンは、仮想マシンでホストされるアプリケーションに加えて、完全なオペレーティング システムと関連ツールが含まれているため、大量のディスク領域を占有する可能性があります。

コンテナは比較的軽量です。コンテナ化されたアプリケーションを実行するために必要なライブラリとツールのみが含まれているため、仮想マシンよりもコンパクトで、起動も速くなります。

オペレーティング システムを更新またはパッチ適用する場合、従来のコンピューターは 1 台ずつ更新する必要があり、各ゲスト オペレーティング システムに個別にパッチを適用する必要があります。コンテナの場合、コンテナ ホスト (コンテナをホストしているマシン) のオペレーティング システムのみを更新する必要があります。これによりメンテナンスが大幅に簡素化されます。

これらの利点により、コンテナはソフトウェア開発の分野で急速に発展しました。コンテナはオーバーヘッドが少なく、分離性に優れているため、さまざまなソフトウェア アプリケーションのインストールにコンテナを使用することに慣れています。競合を心配することなく、同じソフトウェアの複数のバージョンを簡単に使用できます。

Linux コンテナ テクノロジーはこれをどのように実現するのでしょうか?コンテナ テクノロジーを構築する 2 つのコア機能である、名前空間とコントロール グループについて見てみましょう。

3. 名前空間

名前空間は、カーネル リソースを分割する Linux カーネルの機能です。プロセスがアクセスできるリソースを制御して、あるプロセス セットが 1 つのリソース セットを認識し、別のプロセス セットが別のリソース セットを認識するようにします。リソースは複数のスペースに存在する場合があります。 Linux システムは、すべてのプロセスで使用される各タイプの単一の名前空間から起動します。プロセスは他の名前空間を作成したり、異なる名前空間に参加したりできます。

Linux での一般的な名前空間は次のとおりです。

• マウントmnt
• プロセスID pid
• ネットワーク
• プロセス間通信 (ipc)
• ユーザーID ユーザー
• UTS

簡単に言えば、名前空間を使用すると、必要なリソースの分離を実現し、使用できるリソースを制御できます。

4. 対照群 Cグループ

CGroup は Control Groups の略で、プロセス グループが使用する物理リソース (CPU メモリ I/O など) を制限、記録、分離するために Linux カーネルによって提供されるメカニズムです。 CGroups は 2007 年に Linux 2.6.24 カーネルに導入されたものであり、新しいものではありません。プロセス管理を cpuset から分離します。著者は Google の Paul Menage 氏です。 CGroups は、LXC が仮想化を実現するために使用するリソース管理方法でもあります。

CGroup は、任意のプロセスをグループで管理する Linux カーネル機能です。 CGroup 自体は、プロセスをグループ化するための機能とインターフェースを提供するインフラストラクチャです。この機能を通じて、I/O やメモリ割り当て制御などの特定のリソース管理機能が実装されます。これらの特定のリソース管理機能は、CGroup サブシステムまたはコントローラーと呼ばれます。 CGroup サブシステムには、メモリを制御するメモリ コントローラーと、プロセスのスケジュールを制御する CPU コントローラーが含まれています。実行中のカーネルで使用可能な Cgroup サブシステムは、/proc/cgroup によって識別されます。

CGroup の主な機能は次のとおりです。

• リソース制限は、グループが構成されたメモリ制限を超えないように設定できます。これにはファイルシステムキャッシュも含まれます。[8][9]
• 優先順位を付けることにより、一部のグループが CPU 使用率またはディスク I/O スループットのより大きなシェアを獲得できるようになります。
• アカウンティング。グループのリソース使用量を測定します。例:請求目的のため
• プロセスグループの制御、フリーズ、チェックポイントの記録、再起動

CGroup の一般的なサブシステムには以下が含まれます。

• blkio はブロックデバイス（ハードディスクなど）の IO へのアクセスを制限します。
• cpuは、CPUタイムスライスの割り当てなど、プロセスのCPUスケジューリング戦略を設定します。
• メモリはcgroup内のプロセスの使用を制御し、メモリ使用レポートを生成するために使用されます。
• net_clsはクラス識別子（classid）を使用してネットワークパケットをマークし、Linuxトラフィックコントローラtc（トラフィックコントローラ）が特定のcgroupからのパケットを識別し、フロー制御または監視を行うことを可能にします。
• net_prioはcgroup内のプロセスによって生成されるネットワークトラフィックの優先度を設定します。
• hugetlbは使用されるメモリページの数を制限します
• pidsはタスクの数を制限します
• ns は、異なる cgroup 下のプロセスに異なる名前空間を使用さ​​せることができます。

各サブシステムは定義された cgroup に関連付けられ、この cgroup 内のプロセスはそれに応じて制限および制御されます。

簡単に言えば、CGroup を使用すると、使用できるリソースの量を制御することができます。

Namespace と CGroup の 2 つの機能により、コンテナーはリソースの分離とアクセス量を制御できます。しかし、便利な管理機能とインターフェースは依然として必要です。 Dockerはコンテナの基本機能をベースに優れた管理機能とインターフェースを提供しており、コンテナ分野における事実上の標準となっています。一般的にコンテナについて話す場合、デフォルトでは Docker テクノロジーが使用されます。

5.ドッカー

Docker は、アプリケーションを開発、配信、実行するためのオープン ソース ソフトウェアおよびオープン プラットフォームです。 Docker を使用すると、ユーザーはインフラストラクチャ内のアプリケーションをより小さな粒子に分割できるため、ソフトウェアの配信速度が向上します。 Docker コンテナは仮想マシンに似ていますが、原則として、コンテナはオペレーティング システム層を仮想化し、仮想マシンはハードウェアを仮想化します。したがって、コンテナはより移植性が高く、サーバーをより効率的に使用します。

Docker の主な機能は次のとおりです。

• 階層型コンテナ

Docker は、ファイルシステムの読み取り専用レイヤーを使用してコンテナを構築するために AUFS/devicemapper/btrfs を使用します。コンテナは読み取り専用レイヤーで構成されており、コミットされるとコンテナ イメージになります。イメージは、アプリケーションの構築に使用されるレイヤーを含むコンテナーです。 Docker コンテナが実行中の場合、最上位レイヤーのみが読み取りおよび書き込み可能で、その下のすべてのレイヤーは読み取り専用となり、最上位レイヤーは新しいレイヤーにコミットされるまで一時データとなります。読み取り専用ファイルシステムでオーバーレイを使用すると、本質的に複雑さが増し、パフォーマンスが低下します。

• 単一のアプリケーションコンテナ

Docker はコンテナを 1 つのプロセスのみに制限します。デフォルトの docker baseimage OS テンプレートは、init、cron、syslog、ssh などの複数のアプリケーション、プロセス、サービスをサポートするように設計されていません。ご想像のとおり、これによりある程度の複雑さが生じ、日常の使用シナリオに大きな影響を与えます。現在のアーキテクチャでは、アプリケーションとサービスは通常のマルチプロセス OS 環境で実行するように設計されているため、Docker で実行する方法を見つけるか、Docker をサポートするツールを使用する必要があります。 LAMP コンテナ アプリケーションの場合、PHP コンテナ、Apache コンテナ、MySQL コンテナという、相互にサービスを使用する 3 つのコンテナを構築する必要があります。 3 つのコンテナすべてを 1 つにまとめることはできますか?はい、ただし、php-fpm、apache、mysqld を同じコンテナーで実行することはできません。また、別のプロセス マネージャー (runit や supervisor など) をインストールすることもできません。

• 国家分離

Docker はコンテナ ストレージをアプリケーションから分離します。データ ボリューム コンテナー内のホストのコンテナー外部に永続データをマウントできます。使用ケースが非永続データを含むコンテナだけである場合を除き、これにより Docker コンテナの移植性が低下する可能性があります。これは、コンテナ オーケストレーションがステートレス アプリケーションをより簡単にサポートできる根本的な理由でもあります。

• 画像登録

Docker は、ユーザーがイメージをプッシュおよびプルできるパブリックおよびプライベートのイメージ レジストリを提供します。イメージは、アプリケーションを構成する読み取り専用レイヤーです。これにより、ユーザーはアプリケーションを簡単に共有および配布できるようになります。

上の図は Docker のアーキテクチャ図であり、Docker がどのようにコンテナ管理機能を提供しているかがわかります。

• Dockerデーモンはコンテナのライフサイクルを管理する役割を担っています。
• レジストリはコンテナイメージリポジトリ機能を提供します
• Dockerデーモンは、イメージリポジトリからコンテナイメージをプッシュ/プルする役割を担っています。
• クライアント プログラムは、デーモン プロセスと通信し、関連するコンテナー管理コマンドを送信する役割を担います。

Docker バージョン 1.11 より前では、Docker Engine デーモンはコンテナ イメージをダウンロードし、コンテナ プロセスを開始し、リモート API を公開し、ログ収集デーモンとして機能し、すべて集中プロセスとして root として実行されていました。このような集中型アーキテクチャは導入を容易にしますが、プロセスと権限の分離に関する Unix のベスト プラクティスには従いません。さらに、Docker を upstart や systemd などの Linux init システムと適切に統合することが難しくなります。

下の図に示すように、バージョン 1.11 以降では、Docker デーモンはコンテナの実行自体を処理しなくなりました。代わりに、containerd によって処理されるようになりました。より正確には、Docker デーモンはイメージを Open Container Image (OCI) バンドルとして準備し、コンテナへの API 呼び出しを行って OCI バンドルを起動します。次に、runC を使用してコンテナ化されたコンテナを起動します。

では、ContainerD と RunC はそれぞれ何でしょうか?探索を続けましょう。

6.コンテナD

Containerd は、シンプルさ、堅牢性、移植性を重視した業界標準のコンテナ ランタイムです。 containerd は Linux および Windows 用のデーモンとして利用できます。イメージの転送と保存からコンテナの実行と監視、低レベルの保存、ネットワーク接続など、ホスト システム上のコンテナのライフサイクル全体を管理します。 containerd は、開発者やエンドユーザーが直接使用するのではなく、大規模なシステムに組み込むことを目的としています。

containerD は Go 言語で構築されています。興味があれば、コードを見てみましょう:

https://github.com/containerd/containerd

7.ランC

RunC はコンテナを実行するために使用される軽量ツールです。一つのことだけをうまくやるために使用されます。これは、Docker エンジンを経由せずにコンテナを直接実行できる小さなコマンドライン ツールと考えることができます。実際、runC は OCI 標準に従ってコンテナを作成および実行する標準化された製品です。 OCI (Open Container Initiative) 組織は、コンテナ形式とランタイムに関するオープンな業界標準の開発を目指しています。

RunC は、通常のユーザーとしてコンテナを実行することをサポートします。

RunC はコンテナのホットマイグレーションをサポートします。ホットマイグレーションとは、コンテナのチェックポイントを作成し、一連のファイルを取得することです。この一連のファイルを使用して、ローカル ホストまたは他のホスト上のコンテナーを復元できます。これが、チェックポイント コマンドと復元コマンドが存在する理由です。ホットマイグレーションは比較的複雑な操作です。現在、runC はホット移行ツールとして CRIU を使用しています。 RunC は主に CRIU (ユーザー空間でのチェックポイントと復元) を呼び出して、ホット マイグレーション操作を完了します。 CIRU はプロセスをフリーズする役割を担い、それを一連のファイルとしてハードドライブに保存します。そして、これらのファイルを使用して、フリーズしたプロセスを復元する役割を担います。

上の図は、さまざまなコンテナ テクノロジが RunC をどのように使用するかを示しています。 Docker/Podman/CRI-O はすべて RunC を使用していることがわかります。それでは、Docker 以外にどのようなコンテナ ランタイムが利用できるか見てみましょう。

8. クリオー

CRI-O は Kubernetes 用の軽量コンテナ ランタイムであり、これが CRI-O が提供するものです。この名前は、CRI (Container Runtime Interface) と Open Container Initiative (OCI オープン コンテナ イニシアチブ) を組み合わせたものです。これは、CRI-O が OCI 準拠のランタイムとコンテナ イメージに厳密に焦点を合わせているためです。 CRI-O の範囲は、Kubernetes と組み合わせて OCI コンテナを管理および実行することです。このプロジェクトにはトラブルシューティング用のユーザー向けツールがいくつかありますが、開発者向けツールとして意図されているものではありません。

上の図はCRI-Oのアーキテクチャを示しています。

つまり、CRI-O は Kubernetes 内のコンテナ ランタイム インターフェースの標準です。 K8s (Google) の登場は、Docker の制約を取り除き、オープン プラットフォームへと移行するための動きであると、私は理解しています。 Docker はテクノロジー製品としては成功しているものの、ビジネスではそれほど成功していないことがわかります。 k8s が Docker の分離を完了した場合、Docker の見通しはあまり良くないようです。

9. ポッドマン

デーモン プロセスは Docker アーキテクチャの主な批判であり、多くの管理およびセキュリティ上の問題を引き起こします。

Podman は、Linux システム上で OCI コンテナを開発、管理、実行するためのデーモンレス コンテナ エンジンです。コンテナは、root または通常のユーザーとして実行できます。

Podman は従来の fork/exec モデルを使用してコンテナを管理するため、コンテナ プロセスは Podman プロセスの子孫になります。 Docker はクライアント/サーバー モデルを使用します。実行される docker コマンドは Docker クライアント ツールであり、クライアント/サーバー操作を通じて Docker デーモンと通信します。次に、Docker デーモンはコンテナを作成し、Docker クライアント ツールとの stdin/stdout 通信を処理します。 Podman は非 root ユーザー モードで実行できますが、docker デーモンは root ユーザーとして起動する必要があります。ポッドマンのモデルはより安全なモデルであると考えられています。同時に、デーモン プロセスのみが存在するため、システムの見た目がよりクリーンになります。

もちろん、Podman の問題は、まだ非常に新しいこと、管理ツールと機能が非常に弱いこと、イメージをビルドするために buildah が必要な場合があること、そしてコミュニティとエコシステムがまだ非常に小さいことです。 Docker の代わりに Podman を使用する場合は、注意して進めてください。

10.LXC/LXD

LXC は、Linux カーネルのコンテナ機能へのユーザー空間インターフェースです。強力な API とシンプルなツールにより、Linux ユーザーはシステム コンテナーまたはアプリケーション コンテナーを簡単に作成および管理できます。

LXC は、通常は完全なオペレーティング システム イメージで構成される「フル システム コンテナ」を実行するように設計されたシステム コンテナ ランタイムです。最も一般的な使用例では、LXC プロセスは Debian、Fedora、Arch などの完全な Linux ディストリビューションを起動し、ユーザーは仮想マシン イメージを操作します。 LXC はアプリケーション コンテナーの実行 (ダウンロードは不可) にも使用できますが、この使用法では基盤となるオペレーティング システムの詳細に関する詳細な知識が必要となり、あまり一般的ではありません。 LXC は、さまざまなパブリックミラーから「フルシステムコンテナ」イメージをダウンロードし、暗号的に検証できます。 LXC には、upstart や systemd などの instart システムと統合するための中央デーモンがありません。

LXD は LXC に似ていますが、モニターとコンテナ プロセスを生成する liblxc 上の REST API です。これにより、LXD デーモンが中心の障害点とならず、LXD デーモンに障害が発生した場合でもコンテナーが引き続き実行されることが保証されます。その他の詳細は LXC とほぼ同じです。簡単に言えば、LXD = LXC + RestAPI

LXC は軽量の Linux コンテナを提供するコンテナ テクノロジですが、Docker はコンテナに基づく単一のアプリケーション仮想化エンジンです。似ているように聞こえるかもしれませんが、まったく違います。 LXC コンテナとは異なり、Docker コンテナは軽量 VM のように動作しないため、そのように扱うことはできません。 Docker コンテナは、設計上、単一のアプリケーションに制限されています。 LXC コンテナにログインし、OS のように扱い、アプリケーションとサービスをインストールすると、期待どおりに実行されます。 Docker コンテナではそれを実行できません。 Docker ベースの OS テンプレートは単一のアプリケーション環境に削減されており、サービス、デーモン、syslog、cron、複数のアプリケーションの実行などの適切な初期化やサポートはありません。

11.rkt

rkt は、最新のクラウドネイティブ環境向けに開発されたアプリケーション コンテナ エンジンです。ポッドネイティブ アプローチ、プラグ可能な実行環境、明確に定義されたサーフェス領域を備えているため、他のシステムとの統合に最適です。

rkt のコア実行ユニットは Pod です。これは、共有コンテキストで実行される 1 つ以上のアプリケーションのコレクションです (rkt の Pod は、Kubernetes オーケストレーション システムの概念と同義です)。 rkt を使用すると、ユーザーは Pod レベルと、より細かいアプリケーション レベルで、さまざまな構成 (分離パラメーターなど) を適用できます。 rkt のアーキテクチャは、各ポッドを自己完結型の分離された環境で従来の Unix プロセス モデル (つまり、中央デーモンがない) で直接実行できることを意味します。 rkt は、最新のオープンな標準コンテナ形式である App Container (appc) 仕様を実装していますが、Docker で作成されたコンテナ イメージなど、他のコンテナ イメージも実行できます。

rkt プロジェクトは、2014 年 12 月に CoreOS によって導入されて以来、成熟し、広く使用されるようになりました。これはほとんどの主要な Linux ディストリビューションで利用可能であり、rkt の各リリースでは、ユーザーがインストールできるスタンドアロンの rpm/deb パッケージがビルドされます。これらのパッケージは、rkt + Kubernetes 統合のテストをサポートするために、Kubernetes リポジトリの一部としても利用できます。 rkt は、Google Container Image と CoreOS Container Linux が Kubernetes を実行する方法においても中心的な役割を果たします。 RKT は、高速で構成可能、かつ安全な配信機能で知られています。多くのユーザーが docker のセキュリティ問題に気付いていたため、CoreOS は 2014 年に docker の競合として RKT をリリースする必要があり、セキュリティ、相互運用性などの機能により人気を博しました。

Podman と同様に、rkt には集中型デーモンはありませんが、代わりにクライアント コマンドから直接コンテナーを起動するため、システム初期化機能 (systemd、upstart など) と互換性があります。

12.カタコンテナ

Kata Containers は、OpenStack Foundation によって管理されるコンテナ プロジェクトですが、OpenStack プロジェクトからは独立しています。コンテナイメージを使用して、超軽量の仮想マシンの形式でコンテナを作成できるランタイム ツールです。 Kata Containers によって作成されたさまざまなコンテナーは、異なる仮想マシン (カーネル) 上で実行されるため、従来のコンテナーよりも優れた分離性とセキュリティが実現します。同時に、高速起動や迅速な展開など、コンテナの利点も継承します。

先ほど、仮想マシン テクノロジにはオーバーヘッドによる一定の使用制限があることを説明しました。 Kata Container は、コンテナ社会を迅速かつ効率的かつ経済的に構築できる、仮想マシン技術の逆襲ともいえます。

上記のアーキテクチャに示されているように、Kata Containers は RunC に似ており、OCI ランタイム仕様に準拠した実装でもあります。違いは、各 Docker コンテナまたは各 K8S Pod に独立した Linux カーネル (ホスト カーネルを共有しない) が追加され、コンテナの分離とセキュリティが向上することです。

13. その他

前に述べたものに加えて、他のコンテナ テクノロジもいくつかあります。簡単に見てみましょう。

• systemd-nspawn は、Linux コンテナ内でプロセスを実行するように設計されたコンテナ ランタイムです。 systemd-nspawn の名前は「spawn from namespace」に由来しており、プロセスの分離のみを処理し、メモリ、CPU などのリソースの分離は実行しません。systemd-nspawn はアプリケーション コンテナーまたはシステム コンテナーを実行できますが、単独でイメージを実行、ダウンロード、または検証することはできません。 systemd-nspawn には集中型デーモンがなく、upstart や systemd などのシステム起動と統合できます。
• OpenVZ OpenVZ は、Linux カーネルに基づくオペレーティング システム レベルの仮想化テクノロジです。 OpenVZ を使用すると、物理サーバー上で複数のオペレーティング システムを実行できます。このテクノロジーは、仮想プライベート サーバー (VPS) でよく使用されます。 OpenVZ は、通常は完全なシステム イメージである「完全なシステム コンテナ」を実行するように設計されたシステム コンテナ ランタイムです。最も一般的な使用例では、OpenVZ プロセスは Debian、Fedora、Arch などの完全な Linux ディストリビューションを起動し、ユーザーは仮想マシン イメージと同様にそれを操作します。 OpenVZ は、さまざまなパブリックミラーから「フルシステムコンテナ」イメージをダウンロードし、暗号的に検証できます。 OpenVZ には、upstart や systemd などの init システムと統合するための中央デーモンがありません。
• FreeBSD jail は、オペレーティング システム層の仮想化テクノロジであり、FreeBSD オペレーティング システム内で動作します。このテクノロジーを使用すると、FreeBSD システム管理者は jail と呼ばれるいくつかの小さなソフトウェア システムを作成できます。この技術は Poul-Henning Kamp によって採用され、FreeBSD システムに追加されました。
• Solaris コンテナと Solaris ゾーンは、Sun が開発したオペレーティング システム レベルの仮想化テクノロジの実装です。 2004 年 2 月に Solaris 10 ビルド 51 ベータ版で初めて公開され、徹底的なテストを経て、2005 年に Solaris 10 で完全リリースされました。
• Linux-VServer は、Linux カーネルにオペレーティング システム レベルの仮想化機能を追加して作成された仮想プライベート サーバー実装です。オープンソースソフトウェアとして開発、リリースされています。

14. まとめ

マイクロサービスとクラウドネイティブ テクノロジーの人気により、コンテナ エコシステムはますます多くのプレーヤーを魅了しています。かつての王者Dockerは、他の多くの新興企業から挑戦を受けてきました。今後、さらに多くの組織が下図に加わることが予想されます。

この記事がコンテナ技術の基礎知識の理解に役立ち、多くのコンテナ技術用語やさまざまなコンテナランタイムに直面したときに困惑することがなくなることを願っています。