Dockerの原則をマスターすれば、自慢する必要はなくなります

Docker は現代の開発プロセスのあらゆる場所で使用されています。 Docker は環境の分離やアプリケーションのパッケージ化などの機能を提供するため、サービスの展開が特に簡単になります。この記事では、Docker の背後にあるテクノロジーを簡単に分析します。これを読めば、次の疑問が浮かび上がってきます。

1. コンテナと仮想マシンの違い
2. Dockerリソース分離の原則
3. Dockerのリソース制限の仕組み
4. Dockerの階層構造の原理

コンテナとVM

仮想マシン (VM) は、コンピュータ システムのエミュレーターです。完全なハードウェア システム機能を備えた完全なコンピュータ システムをシミュレートし、ソフトウェアを通じて完全に分離された環境で実行し、物理コンピュータの機能を提供できます。

仮想マシンは、ハイパーバイザー テクノロジを使用して、現在の実際のオペレーティング システム上に仮想マシンの動作環境とシステムを確立し、このテクノロジを通じてリソースを制御します。パフォーマンスの優れた物理マシンは通常、複数の仮想マシンをホストでき、各仮想マシンには独自のオペレーティング システムがあります (図 1.1 を参照)。

図からわかるように、仮想マシンは物理マシンのハードウェア レベルでオペレーティング システムの分離を提供します。これにより、異なる仮想マシン間の分離が非常に徹底されますが、消費されるリソースも増えます。場合によっては、このような徹底した分離は必要なく、多くのリソースを消費しない方がよいこともあります。この場合、コンテナ技術を使用できます。

コンテナは、オペレーティング システム レベルでプロセスの分離を提供できます。 Docker を例に挙げてみましょう。 Docker コンテナを実行すると、コンテナ自体はオペレーティング システム内の単なるプロセスになります。オペレーティングシステムが提供するさまざまな機能を使用して、プロセス間のネットワーク、スペース、権限などの分離を実現し、図 1.2 に示すように、複数の Docker コンテナ プロセスが互いの存在を認識しないようにします。

仮想マシン技術とコンテナ技術の最大の違いは、複数の仮想マシンが複数のオペレーティング システム カーネルを使用するのに対し、複数のコンテナはホスト オペレーティング システム カーネルを共有することです。

Docker リソースの分離: Linux 名前空間

Linux 名前空間は Linux カーネルによって提供される機能であり、PID (プロセス ID)、ユーザー ID、ネットワーク、ファイル システムなどの一連のシステム リソースを分離できます。

Linux に詳しい方であれば、Linux の chroot コマンドを思い浮かべるかもしれません。このコマンドは、現在のディレクトリをルート ディレクトリに変更する (つまり、ルート ディレクトリ / のマウント ポイントを切り替える) もので、これはファイル システムが分離されていることに相当します。 Namespace にも同様の機能がありますが、より強力です。

現在、Linux では、次の表に示すように、主に 6 種類の異なる名前空間が提供されています。

具体的な例を使って、Namespace の役割を説明しましょう。非常に優れたパフォーマンスを持つコンピューターを持っているとします。コンピュータのリソースをユーザーに販売します。各ユーザーは ssh インスタンスを購入します。異なる顧客間の干渉を避けるために、ユーザーが自分の SSH インスタンスの下にあるリソースにのみアクセスできるように、異なるユーザーの権限を制限することができます。

ただし、一部の操作にはルート権限が必要であり、ユーザーにルート権限を付与することはできません。この場合、名前空間を使用して、ユーザー名前空間を通じて UID を分離できます。具体的には、UID x を持つユーザーは名前空間内でルート権限を持ちますが、実際の物理マシンでは依然として UID x を持つユーザーであるため、ユーザー間の分離の問題が解決されます。

さらに、PID は PID 名前空間を通じて分離できます。名前空間内のユーザーの観点から見ると、名前空間は独自の init プロセス (初期プロセス、PID 1) を持つ新しい Linux のようなものです。図 1.3 に示すように、他のプロセスの PID は init プロセスの PID に基づいて増加します。

図では、親名前空間のプロセス 3 の PID は 3 で、子名前空間ではその PID は 1 です。ユーザーにとって、子名前空間のプロセス 3 は init プロセスのように見えます。

Linux は、名前空間の使用を容易にするために 3 つのシステム API を提供します。

• clone() は新しいプロセスを作成し、システム コール フラグに基づいてどのタイプの Namespace が作成されるかを決定し、このプロセスの子プロセスにもこれらの Namespace が含まれます。
• setns() はプロセスを既存の名前空間に追加します。
• unshare() はプロセスを名前空間から移動します

Docker は Linux 名前空間機能を使用して、複数の Docker コンテナを相互に分離し、独立した環境を提供します。 Go 言語はそれに応じて Namespace API をカプセル化しており、関連する実装は Docker ソース コードで確認できます。

Docker リソース制限: Linux Cgroups

Docker は Linux 名前空間を使用して、プロセスが独自の個別のスペース/リソースを分離できるようにします。では、Docker はプロセスによるこれらのリソースの使用をどのように制限するのでしょうか?

Docker コンテナの本質は依然としてプロセスです。複数の Docker コンテナが実行中の場合、Docker プロセスの 1 つが大量の CPU とメモリを占有すると、他の Docker プロセスの応答が遅くなります。この状況を回避するには、Linux Cgroups テクノロジーを使用してリソースを制限できます。

Linux Cgroups (Linux Contorl Groups、略して Cgroups) は、CPU、メモリ、ストレージ、ネットワーク、デバイス アクセス権など、プロセス グループとそのサブプロセスのリソースを制限、制御、カウントできます。Cgroups を使用すると、プロセスのリソース使用量を簡単に制限し、プロセスのリアルタイム使用量をカウントできます。

• cgroups は、連携して動作する cgroup (制御グループ)、サブシステム、階層の 3 つのコンポーネントで構成されています。
• Cgroup は、プロセスをグループ化して管理するためのメカニズムです。 cgroup には通常、プロセスのグループ (または複数) が含まれます。 Cgroup 内のリソース制御は cgroup 単位で実装されます。
• サブシステムは、（複数の）リソース制御モジュールのグループです。各サブシステムは cgroup によって管理され、cgroup 内のプロセスに該当する制限と制御を課します。
• 階層は cgroup のグループ (または複数のグループ) をツリー構造に構築し、Cgropus はこれを使用して継承やその他の機能を実装できます。

3 これらは具体的にどのように連携するのでしょうか?

cgroups はシステム プロセス (cgroups) をグループ化し、階層構造を通じて独立したツリーに構築します。ツリーのノードは cgroup (プロセス グループ) です。各ツリーは 1 つ以上のサブシステムに関連付けることができ、サブシステムはツリー内の対応するグループに対して動作します。

注意すべきルールがいくつかあります。

1. サブシステムは 1 つの階層にのみ接続できますが、階層には複数のサブシステムを接続できます。 2. プロセスは複数の cgroup のメンバーになることができますが、これらの cgroup は異なる階層にのみ存在できます。 3. プロセスが子プロセスをフォークすると、子プロセスと親プロセスはデフォルトで同じ cgroup にあり、必要に応じて他の cgroup に移動できます。

Docker の階層構造: ユニオン ファイル システム

Docker イメージは階層構造になっており、各レイヤーが他のレイヤーの上に構築され、コンテンツを段階的に追加する機能が実現されていることは誰もが知っています。これはどのように達成されるのでしょうか?

この問題を理解するには、まず、Union File System (略して UnionFS) を理解する必要があります。Union File System は、Linux システム向けに設計された、他のファイル システムをユニオン マウント ポイントに結合するファイル システム サービスです。 UnionFS はブランチを使用して、異なるファイル システムのファイルとディレクトリを透過的にオーバーレイし、一貫性のある単一のファイル システムを形成します。さらに、UnionFS は Copy on Write (CoW) テクノロジーを使用して、マージされたファイル システムのリソース使用率を向上させます。 （CoW技術については次回の記事で紹介します）

Docker で使用された最初のストレージ ドライバーは AUFS (Advanced Multi-layered unification filesytem) でした。 AUFS は、パフォーマンスと信頼性を向上させるために、初期の UnionFS を完全に書き直しました。さらに、ブランチ負荷分散などの新機能も導入されました。

UnionFS と同様に、AUFS は基本ファイルシステムに新しいファイルシステムを段階的に追加し、最終的にオーバーレイを通じてファイルシステムを形成できます。通常、AUFS の最上位層は読み取りおよび書き込み可能な層であり、他の層は読み取り専用層であり、各層は通常のファイル システムです。

Docker イメージの階層化と増分追加機能は、AUFS の階層化ファイルシステム構造と増分追加機能を利用することで実現されます。これは、Docker コンテナの実行時にボリュームまたはバインドマウントが指定されていない場合、実行時に生成されたデータは Docker コンテナの終了後に失われることを意味します。

Docker ストレージ ドライバーには、AUFS に加えて、OverlayFS、Devicemapper、Btrfs、ZFS なども含まれますが、これらについてはこの記事では説明しません。

要約する

ここまでで、Docker のコア機能の基本原理がわかりました。 Docker は Linux 名前空間を使用してネットワーク、ユーザー、プロセスなどのさまざまなリソースを分離し、Linux Cgroups テクノロジを使用してリソースの使用を制限および監視し、AUFS などのストレージ ドライバーを通じて階層構造や増分更新などの機能を実装します。

現実世界の Docker では他にも多くのテクノロジーが使用されていますが、最もコアかつ基本的なテクノロジーは Linux Namespace、Linux Cgrpus、AUFS です。

Docker は現在の開発プロセスにおいて不可欠なツールとなっています。コンテナがもたらす利点により、運用・保守担当者の負担が軽減され、開発環境とオンライン環境の不整合によって生じる問題が回避されました。現在、コンテナオーケストレーション技術（K8s）は急速に発展しており、Dockerコンテナ技術は今後さらに発展していくでしょう。その本質を理解するには、時間と労力をかける価値があります。