テクノロジーの選択: Docker コンテナ エンジン

私は最近 Docker と Kubernetes を勉強し、数日前に技術共有セッションを行いました。自分のスピーチの録音を聞き返してみたところ、良い PPT を作成するだけでは十分ではないことがわかりました。事前に論理的に厳密なスピーチを準備していなかったため、話している途中で行き詰まったり、技術的なポイントを見逃したり、論理的な矛盾に遭遇したりしました。

この問題を解決するために、今後は自分の技術を共有する前に、PPT の内容をもとにブログを書いて、表現のロジックを整理するつもりです。さらに、将来再度使用する必要があるかどうかはわからないため、各技術共有で使用する PPT は可能な限り優れたものにする必要があると思います。この記事は、今回の私の技術共有の記録として、PPT + 講義ノートの形式で書かれています。誰でも批判して構いません。

[[285382]]

1. Dockerの背景

通常の研究開発およびプロジェクトのシナリオでは、次のような状況が一般的です。

個人開発環境

ビッグデータ関連のプロジェクトを実行するには、CDH クラスターをインストールする必要があります。一般的な方法は、自分のコンピューターに CDH バージョンに対応する 3 つの仮想マシンを構築することです。 CDH クラスターをインストールした後、将来的にクリーンな CDH クラスターを使用する必要がある可能性があることを考慮して、将来的に環境を繰り返しインストールしないようにするために、通常は CDH クラスター全体のバックアップを作成し、コンピューターに 6 つの仮想マシン イメージが存在するようにします。

さらに、後で Ambari ビッグデータ クラスターを学習するなど、他のテクノロジを学習するときには、既存の仮想マシン環境を破壊しないように、3 つの仮想マシンを再構築する必要があり、ローカル ディスクはすぐに大量の仮想マシン イメージでいっぱいになります。

社内開発環境

企業では小規模なチームでプロジェクトに取り組むことが多く、運用部門は通常、管理するサーバー リソースから仮想マシンを割り当てて、チームによる社内開発とテストに使用します。たとえば、機械学習に関連するプロジェクトを実行します。

• シャオミンは、運用保守部門から割り当てられた仮想マシン上にAmbariクラスタを構築し、ビッグデータ関連サービスを実行しました。
• Xiaogang 氏は Python 3 で機械学習アルゴリズムを作成しました。それを仮想マシンで実行したところ、仮想マシンは Python 2 を使用しており、アルゴリズムに互換性がないことがわかりました。そこで彼は仮想マシンの Python バージョンをアップグレードしました。アルゴリズムは正常に実行されましたが、Python を使用した Ambari の一部の関数でエラーが報告される可能性があります。
• Xiao Li はアプリケーションを開発し、それを仮想マシンに配置して Tomcat を起動しました。仮想マシンが OpenJDK を実行しており、それが Tomcat の起動失敗の原因になっていることがわかりました。そこで彼は別の JDK をインストールしました。このとき、Ambari の Java コードでエラーが報告される可能性があります。
• Xiao Zhao はパフォーマンス テストにサーバー リソースを使用したいと考えていましたが、仮想マシンによってパフォーマンスが大幅に低下していることに気付きました。結局、テストを実行するために物理マシンを使用する必要があり、物理マシンの元の環境が破壊されました。
• プロジェクトが完了すると、これらの仮想マシンにインストールされたソフトウェアは役に立たなくなることがよくあります。次のプロジェクト チームは、ソフトウェアを再展開するために新しい仮想マシンを申請する必要があります。

開発/テスト/ライブ環境

R&D 担当者はコードを記述し、開発環境でテストした後、それをテスト部門に提出します。テスターはテスト環境でコードを実行するときにバグを発見します。研究開発担当者によると、開発環境にはそのようなバグはないとのことです。バグを解決するためにテスターと何度も議論した後、バージョンがリリースされました。サイトに送られ、本番環境に展開された後、再びバグが見つかります。今度はエンジニアとテスターが議論する番です。場合によっては、特殊なオンサイト環境との互換性を保つために、コードをカスタマイズして分岐する必要があり、オンサイト アップグレードが悪夢になります。

プロジェクトのアップグレードまたは移行

サイトにバージョンがリリースされアップグレードされるたびに、サイトに複数の Tomcat アプリケーションがある場合は、まず各 Tomcat を停止し、war パッケージを置き換えてから、1 つずつ再起動する必要があります。これは面倒なだけでなく、エラーが発生しやすくなります。アップグレード後に重大なバグが発生した場合は、手動でロールバックする必要があります。

さらに、プロジェクトをクラウドに移行する場合は、クラウドへの展開後に新たな一連のテストを実行する必要があります。後でクラウド ベンダーへの変更を検討する場合、同じテストを再度実行する必要がある場合があります (たとえば、データ ストレージ コンポーネントが交換された場合)。これには時間と労力がかかります。

上記のすべてのシナリオをまとめると、共通の問題は、オペレーティング システムの違いを遮断し、パフォーマンスを低下させずにアプリケーションを実行して環境依存の問題を解決できるテクノロジが存在しないことです。 Dockerが誕生しました。

2. Dockerとは何か

Docker はアプリケーション コンテナ エンジンです。

まず、コンテナとは何かについて説明します。 Linux システムは、環境の分離とリソース制御を実装するために、名前空間と CGroup テクノロジを提供します。名前空間は、Linux が提供するカーネル レベルの環境分離方法であり、プロセスの実行空間とプロセスによって作成された子プロセスを Linux スーパー親プロセスから分離できます。

名前空間は実行中の空間のみを分離でき、物理リソースは引き続きすべてのプロセスによって共有されることに注意してください。リソースの分離を実現するために、Linux システムは、プロセス グループが使用できるリソース (CPU、メモリ、ディスク IO など) を制御する CGroup テクノロジを提供します。これら 2 つのテクノロジを組み合わせることで、ユーザー空間から独立し、リソースが制限されたオブジェクトを構築できます。このようなオブジェクトはコンテナと呼ばれます。

Linux コンテナは、LXC と呼ばれる Linux システムによって提供されるコンテナ化テクノロジです。 Namespace と CGroup テクノロジを組み合わせて、コンテナ化を実装するためのよりユーザーフレンドリーなインターフェースをユーザーに提供します。 LXC は軽量のコンテナ化テクノロジーにすぎません。一部のリソースのみを制限することしかできず、ネットワーク制限、ディスク容量の使用制限などはできません。dotCloud では、LXC と以下のテクノロジーを組み合わせて Docker コンテナ エンジンを実装しています。 LXC と比較すると、Docker はより包括的なリソース制御機能を備えており、アプリケーション レベルのコンテナー エンジンです。

• Chroot: このテクノロジーは、コンテナ内に完全な Linux ファイル システムを構築できます。
• Veth: この技術は、ホスト上のネットワーク カードを仮想化してコンテナ内の eth0 ネットワーク カードとブリッジし、コンテナとホスト間、およびコンテナ間のネットワーク通信を実現します。
• UnionFS: ユニオンファイルシステム。 Docker は、このテクノロジーの「Copy on Write」機能を使用して、コンテナの起動を高速化し、リソースの使用を最小限に抑えます。このファイルシステムについては後で紹介します。
• Iptables/netfilter: これら 2 つのテクノロジーは、コンテナのネットワーク アクセス ポリシーを制御するために使用されます。
• TC: このテクノロジーは主にトラフィックの分離と帯域幅の制限に使用されます。
• クォータ: このテクノロジーは、ディスクの読み取りおよび書き込み領域のサイズを制限するために使用されます。
• Setrlimit: このテクノロジーは、コンテナ内で開かれるプロセスの数、開かれるファイルの数などを制限するために使用されます。

Docker は Linux カーネルのこれらのテクノロジーに依存しているため、Docker コンテナを実行するには少なくともカーネル バージョン 3.8 以上が必要です。公式の推奨は、カーネル バージョン 3.10 以上を使用することです。

3. 従来の仮想化技術との違い

従来の仮想化テクノロジーでは、仮想マシン (VM) とハードウェアの間にソフトウェア レイヤー、ハイパーバイザー、または仮想マシン管理プログラムが追加されます。ハイパーバイザーの動作モードは、次の 2 つのカテゴリに分けられます。

• 物理ハードウェア上で直接実行されます。たとえば、カーネルベースの KVM 仮想マシンでは、CPU が仮想化テクノロジをサポートする必要があります。
• 別のオペレーティング システムで実行します。 VMWare や VitrualBox 仮想マシンなど。

仮想マシン上で実行されるオペレーティング システムは、最終的にはハイパーバイザを介してハードウェアを共有するため、仮想マシンのゲスト OS によって発行されるすべての命令はハイパーバイザによってキャプチャされ、物理ハードウェアまたはホスト オペレーティング システムが認識できる命令に変換される必要があります。

VMWare や VirtualBox などの仮想マシンは、パフォーマンスの面でベアメタルに大きく劣りますが、ハードウェア仮想マシンをベースとした KVM は、ベアメタルの約 80% のパフォーマンスを実現できます。この仮想化の利点は、異なる仮想マシンが互いに完全に分離されているため、非常に安全であり、単一の物理マシン上で複数のカーネル オペレーティング システム (Linux や Windows など) を実行できることです。ただし、各仮想マシンはサイズが大きく、多くのリソースを消費し、起動も非常に遅くなります。

Docker エンジンはオペレーティング システム上で実行され、LXC や Chroot などのカーネル テクノロジに基づいてコンテナー環境の分離とリソース制御を実装します。コンテナが起動すると、コンテナ内のプロセスは Docker エンジンを経由せずにカーネルと直接対話します。そのため、パフォーマンスの低下はほとんどなく、ベアメタルの性能をフルに発揮できます。

ただし、Docker は Linux カーネル テクノロジーに基づいてコンテナ化を実装するため、コンテナ内で実行されるアプリケーションは Linux カーネル オペレーティング システム上でのみ実行できます。現在 Windows にインストールされている Docker エンジンは、実際には Windows に付属する Hyper-V 仮想化ツールを使用して Linux システムを自動的に作成します。コンテナ内の操作は、実際にはこの仮想システムを使用して間接的に実装されます。

4. Dockerの基本概念

Docker には主に以下の概念があります。

• エンジン: コンテナを作成および管理するためのツール。イメージを読み取ってコンテナを生成し、ウェアハウスからイメージをプルしたり、ウェアハウスにイメージを送信したりする役割を担います。
• イメージ: 仮想マシン イメージと同様に、通常は基本的なオペレーティング システム環境と複数のアプリケーションがパッケージ化されており、コンテナーを作成するためのテンプレートです。
• コンテナ: 簡略化された Linux システム環境 (ルート ユーザー権限、プロセス空間、ユーザー空間、ネットワーク空間などを含む) と、その中で実行されるアプリケーションがパッケージ化されたボックスと考えることができます。
• ウェアハウス: 画像ファイルを集中的に保存する場所。公設倉庫と私設倉庫に分かれています。現在、最大のパブリックウェアハウスは公式の Docker Hub です。さらに、国内のAlibaba CloudやTencent Cloudもパブリック倉庫を提供しています。
• ホスト: エンジンを実行しているオペレーティング システムが配置されているサーバー。

5. Dockerと仮想マシン、Git、JVMとの類似点

Docker をより直感的に理解できるように、次の 3 つの類推を示します。

上の図では、Docker のイメージ リポジトリは、従来の仮想マシンのイメージ リポジトリやイメージを保存するローカル ファイル システムに似ています。 Docker エンジンは、コンテナを起動して Spark クラスターを実行します (コンテナには基本的な Linux オペレーティング システム環境が含まれています)。これは、仮想マシン ソフトウェアが複数の仮想マシンを起動し、各仮想マシンで Spark プロセスを実行するのと似ています。 2 つの違いは、Docker コンテナ内のアプリケーションが物理リソースを使用する場合、Docker エンジンを経由せずにカーネルと直接対話することです。

Docker のリポジトリの考え方は Git と同じです。

Docker のスローガンは「あらゆるアプリをどこでもビルド、出荷、実行」です。つまり、Docker をベースにアプリケーションをビルド、ロード、実行でき、一度ビルドすればどこでも実行できるということです。 Java のスローガンは「Write Once, Run Anywhere」です。つまり、一度書けばどこでも実行できるということです。

Java は、JVM のオペレーティング システムへの適応を利用してシステムの違いを隠蔽しますが、Docker はカーネル バージョンの互換性を利用して 1 回限りのビルド、エクスポート、実行を実現します。 Linux システムのカーネルがバージョン 3.8 以上であれば、コンテナを実行できます。

もちろん、Java と同様に、アプリケーション コードが JDK10 の新機能を使用している場合は、JDK8 ベースでは実行できません。同様に、コンテナ内のアプリケーションがバージョン 4.18 のカーネル機能を使用している場合、CentOS7 (カーネル バージョン 3.10) でコンテナを起動すると、コンテナは起動できますが、ホスト オペレーティング システムのカーネルをバージョン 4.18 にアップグレードしない限り、内部のアプリケーションの機能は正常に実行できません。

6. Docker イメージ ファイル システム

Docker イメージは階層化されたストレージ形式を使用します。各イメージは他のイメージに基づいて構築できます。画像の各レイヤーは複数の画像から参照できます。上図のイメージ依存関係において、K8S イメージは実際には CentOS+GCC+GO+K8S の組み合わせとなります。

この階層構造により、イメージ レイヤーを完全に共有でき、イメージ リポジトリが占有するスペースを大幅に削減できます。ユーザーにとって、彼らが目にするコンテナは、実際には、関連するイメージ レイヤーのディレクトリを同じマウント ポイントに「統合」するために UnionFS (Union File System) を使用して Docker によって提供される全体です。ここで、UnionFS とは何かを簡単に紹介する必要があります。

UnionFS は、物理的に独立した複数のディレクトリ (ブランチとも呼ばれます) の内容を同じディレクトリにマウントできます。 UnionFS を使用すると、これらのディレクトリの読み取りおよび書き込み権限を制御できます。さらに、読み取り専用ファイルとディレクトリの場合、「Copy on Write」機能があり、読み取り専用ファイルが変更されると、変更前にファイルのコピーが書き込み可能なレイヤー（ディスク上のディレクトリの場合もあります）にコピーされます。すべての変更操作は実際にはこのファイルのコピーに対する変更であり、元の読み取り専用ファイルは変更されません。

UnionFS の使用例の 1 つは、Linux のデモンストレーション、CD-ROM の教育、商用製品のデモンストレーションに使用される Linux ディストリビューションである Knoppix です。 CD/DVD と読み取り/書き込み可能なデバイス (USB フラッシュ ドライブなど) を共同でマウントし、デモンストレーション中に CD/DVD 上のファイルに加えられた変更は、元の CD/DVD の内容を変更せずに USB フラッシュ ドライブに適用されます。

UnionFSには多くの種類があります。中でもDockerではUnionFSのアップグレード版であるAUFSがよく使われています。さらに、DeviceMapper、Overlay2、ZFS、VFS もあります。 Docker イメージの各レイヤーは、デフォルトでは /var/lib/docker/aufs/diff ディレクトリに保存されます。ユーザーがコンテナを起動すると、Docker エンジンは最初に /var/lib/docker/aufs/diff に読み取りおよび書き込み可能なレイヤー ディレクトリを作成し、次に UnionFS を使用して、読み取りおよび書き込み可能なレイヤー ディレクトリと指定されたイメージのディレクトリのレイヤーを /var/lib/docker/aufs/mnt のディレクトリにマウントします (指定されたイメージのディレクトリのレイヤーは読み取り専用モードでマウントされます)。 LXC などのテクノロジーを通じて環境の分離とリソース制御が実行され、コンテナ内のアプリケーションは、mnt ディレクトリ内の対応するマウントされたディレクトリとファイルのみに依存して実行されます。

UnionFS の write-to-copy 機能を利用すると、コンテナを起動するときに、Docker エンジンは実際には書き込み可能なレイヤーを追加して Linux コンテナを構築するだけであり、どちらもシステム リソースをほとんど消費しません。そのため、Docker コンテナは数秒で起動でき、サーバー上で数千の Docker コンテナを起動できます。しかし、従来の仮想マシンでは、サーバー上で数十のコンテナを起動することは非常に困難であり、仮想マシンの起動は非常に遅くなります。これらは、従来の仮想マシンと比較した Docker の 2 つの大きな利点です。

アプリケーションがカーネル関数を呼び出して動作するだけの場合は、アプリケーション自体をイメージを構築するための最下層として使用できます。ただし、コンテナ自体が環境を分離するため、コンテナはホスト マシン内のファイルにアクセスできません (特定のディレクトリまたはファイルがコンテナにマップされていない限り)。この場合、アプリケーション コードはカーネル関数のみを使用できます。

ただし、Linux カーネルは、プロセス管理、メモリ管理、ファイル システム管理などの基本的な低レベルの管理機能のみを提供します。実際のシナリオでは、ほぼすべてのソフトウェアはオペレーティング システムに基づいて開発されるため、オペレーティング システムのソフトウェアとランタイム ライブラリに依存する必要があることがよくあります。これらのアプリケーションの次の層が直接カーネルである場合、アプリケーションは実行できません。したがって、実際には、基盤となるアプリケーション イメージは、実行中の依存関係を補完するためにオペレーティング システム イメージに基づいていることがよくあります。

Docker のオペレーティング システム イメージは、システムを通常インストールするときに使用される ISO イメージとは異なります。 ISO イメージには、オペレーティング システム カーネルと、配布システムに含まれるすべてのディレクトリとソフトウェアが含まれています。 Docker のオペレーティング システム イメージにはシステム カーネルは含まれず、いくつかの必要なディレクトリ (/etc /proc など) と、よく使用されるソフトウェアおよびランタイム ライブラリのみが含まれます。オペレーティング システム イメージは、カーネルの上にあるアプリケーション、つまりカーネル機能をカプセル化し、ユーザーが作成したアプリケーションの実行環境を提供するツールと見なすことができます。

このようなイメージに基づいて構築されたアプリケーションは、対応するオペレーティング システム内のさまざまなソフトウェアの機能とランタイム ライブラリを利用できます。また、アプリケーションはオペレーティングシステムイメージに基づいて構築されるため、別のサーバーに移動した場合でも、オペレーティングシステムイメージ内のアプリケーションが使用する機能をホストマシンのカーネルに適合させることができれば、アプリケーションは正常に動作します。これが、一度ビルドすればどこでも実行できる理由です。

次の図は、イメージとコンテナの関係を示しています。

上の図では、Apache アプリケーションは emacs イメージに基づいて構築され、emacs は Debian システム イメージに基づいて構築されています。コンテナとして起動すると、Apache イメージ レイヤーの上に書き込み可能なレイヤーが構築され、コンテナ自体へのすべての変更は書き込み可能なレイヤーで実行されます。 Debian はこのイメージのベースイメージであり、カーネルのより高度なカプセル化を提供します。同時に、同じカーネルに基づいて他のイメージも構築されます (次の BusyBox は簡略化されたオペレーティング システム イメージです)。

このとき、問題が発生します。アプリケーションはオペレーティング システム イメージに基づいて構築されます。 OS イメージ自体が多くのスペースを占めると、イメージの配布に不便が生じますし、イメージ ウェアハウスも多くのスペースを占めることになります。これを考慮して、さまざまなシナリオに合わせて異なるオペレーティング システム イメージを構築した人もいます。以下では、最も一般的に使用されるシステム イメージをいくつか紹介します。

7. Docker ベース オペレーティング システム

上記のシステム イメージは、さまざまなシナリオに適しています。

• BusyBox: 一般的に使用される 100 以上の Linux コマンドを統合した最小限の Linux システム。サイズは 2MB 未満で、「Linux システムのスイス アーミー ナイフ」として知られています。単純なテストシナリオに適しています。
• Alpine: BusyBox よりも充実した機能を備えた、セキュリティ重視の軽量 Linux ディストリビューション システム。サイズは5MB未満で、公式サイトが推奨する基本画像です。十分な基本機能を備え、サイズが小さいため、実稼働環境で最も一般的に使用されます。
• Debian/Ubuntu: Debian シリーズのオペレーティング システム。機能が充実しており、サイズは約 170 MB で、R&D 環境に適しています。
• CentOS/Fedora: どちらも Redhat をベースにした Linux ディストリビューションで、エンタープライズ レベルのサーバーで一般的に使用されているオペレーティング システムであり、安定性が高く、サイズが約 200 MB で、実稼働環境での使用に適しています。

8. Docker永続ストレージ

先ほど紹介したコンテナ内の UnionFS リアルレプリケーションの特性によれば、コンテナ内のファイルの追加、削除、または変更は、実際には書き込み可能なレイヤー内のファイルのコピーに対して実行されます。コンテナが閉じられると、書き込み可能なレイヤーも削除され、コンテナに対するすべての変更が無効になります。したがって、コンテナ内のファイルの永続性の問題を解決する必要があります。 Docker はこれを実現するための 2 つのソリューションを提供します。

次の図に示すように、ホスト ファイル システム内のディレクトリをコンテナー内のディレクトリにマップします。このようにして、コンテナ内のこのディレクトリに作成されたすべてのファイルは、ホスト マシンの対応するディレクトリに保存されます。コンテナを閉じた後もホストマシンのディレクトリは存在し、コンテナを再度起動すると以前に作成されたファイルを読み取ることができるため、コンテナのファイルの永続性が実現されます。

もちろん、イメージに付属するファイルを変更する場合、イメージは読み取り専用であるため、ファイルの変更後に新しいイメージを構築しない限り、コンテナーが閉じられたときに変更操作は保存されないことも理解しておく必要があります。

次の図に示すように、複数のホストのディスク ディレクトリをネットワーク経由で共有ストレージに結合し、共有ストレージ内の特定のディレクトリを特定のコンテナーにマップします。この方法では、コンテナを再起動しても、シャットダウン前に作成されたファイルを読み取ることができます。 NFS は、実稼働環境での共有ストレージ ソリューションとしてよく使用されます。

9. Dockerイメージの作成方法

ミラーを作成するには 2 つの方法があります。

（１）実行中のコンテナから新しいイメージを生成する

コンテナが実行中の場合、コンテナに加えられたすべての変更はコンテナの書き込み可能なレイヤーに反映されます。 Docker は、実行中のコンテナの書き込み可能なレイヤーへの変更をオーバーレイして新しいイメージを生成できる commit コマンドを提供します。

上図のように、コンテナ内に新しく Spark コンポーネントをインストールし、コンテナを閉じると、書き込み可能なレイヤーとともに Spark コンポーネントも消えてしまいます。コンテナを閉じる前に commit コマンドを使用して新しいイメージを生成すると、新しいイメージがコンテナとして起動されたときに Spark コンポーネントがコンテナに含まれます。

この方法は比較的シンプルですが、環境変数やリスニングポートなどを直感的に設定することはできません。シンプルな使用シナリオに適しています。

（２）Dockerfileファイルを使って新しいイメージを生成する

Dockerfile は、イメージを作成する手順を定義するファイルです。 Docker エンジンは、ビルド コマンドを通じて Dockerfile を読み取り、定義された手順に従って段階的にイメージを構築します。 R&D および実装環境では、Dockerfile を通じてコン​​テナを作成するのが主流です。

Dockerfile の例を次に示します。

Docker エンジンは、上記の Dockerfile で定義された手順に従って、ssh サービスを備えた Ubuntu イメージを構築できます。

10. Dockerの使用シナリオ

軽量仮想化ソリューションとして、Docker には幅広いアプリケーション シナリオがあります。一般的なシナリオをいくつか示します。

軽量仮想マシンとして使用

Ubuntu やその他のシステムイメージを使用してコンテナを作成し、仮想マシンとして使用することができます。従来の仮想マシンと比較すると、起動が速く、使用するリソースが少なくなります。 1 台のマシンで多数のオペレーティング システム コンテナーを起動できるため、さまざまなテストを簡単に実行できます。

クラウドホストとして使用

Kubernetes などのコンテナ管理システムと組み合わせることで、多数のサーバー上でコンテナを動的に割り当て、管理できるようになります。社内では、VMWare などの仮想マシン管理プラットフォームを置き換え、Docker コンテナをクラウド ホストとして使用することもできます。

アプリケーションサービスパッケージ

Web アプリケーション サービス開発シナリオでは、Java ランタイム環境と Tomcat サーバーを基本イメージにパッケージ化できます。コード パッケージを変更した後、それを基本イメージに追加して新しいイメージを構築します。これにより、サービスを簡単にアップグレードし、バージョンを制御できます。

コンテナクラウドプラットフォームCaaS

Docker の登場により、多くのクラウド プラットフォーム プロバイダーが、コンテナ クラウド サービス (サービスとしてのコンテナ、CaaS) の提供を開始しました。以下は、IaaS、PaaS、SaaS の比較です。

IaaS (Infrastructure as a Service): 仮想マシンやその他の基本リソースをサービスとしてユーザーに提供します。ユーザーは、関連するアプリケーションをロードするためにサプライヤーから仮想マシン、ストレージ、およびその他のリソースを取得でき、これらのインフラストラクチャの面倒な管理は IaaS サプライヤーによって処理されます。主なユーザーは、企業のシステム管理者と運用保守担当者です。

PaaS (Platform as a Service): 開発プラットフォームをサービスとしてユーザーに提供します。ユーザーは、SDK、ドキュメント、テスト環境を含む開発プラットフォーム上でアプリケーションを簡単に作成できます。さらに、導入時や運用時を問わず、ユーザーはサーバー、オペレーティング システム、ネットワーク、ストレージなどのリソースの管理を気にする必要がありません。これらの面倒なタスクは PaaS プロバイダーによって処理されます。主なユーザーはエンタープライズ開発者です。

SaaS (Software as a Service): アプリケーションをサービスとして顧客に提供します。ユーザーはインターネットに接続してブラウザを使用する限り、インストールなどの些細な問題を心配することなく、クラウド上で実行されるアプリケーションを直接使用でき、ソフトウェアとハ​​ードウェアへの初期の高額な投資を回避できます。 SaaSは主に一般ユーザーを対象としています。

CaaS (Container as a Service): IaaS レベルと PaaS レベルの両方の機能を実現します。従来の IaaS および PaaS サービスと比較すると、CaaS は PaaS よりも基盤レイヤーに対してより柔軟なサポートを提供し、一方で IaaS よりも上位レイヤーのアプリケーションを制御することが容易です。同時に、Docker は VM よりもきめ細かい仮想化サービスであるため、コンピューティング リソースをより効率的に使用できます。 CaaS は、任意の物理マシン、仮想マシン、または IaaS クラウドに展開できます。

継続的インテグレーションと継続的デプロイメント

インターネット業界ではアジャイル開発が推奨されており、継続的インテグレーションとデプロイメント CI/CD が最も一般的な開発モデルです。 Docker コンテナ クラウド プラットフォームを使用すると、コードが記述されて Git/SVN にプッシュされた後、バックエンドの CaaS プラットフォームが自動的にトリガーされ、コードがテスト Docker イメージにダウンロード、コンパイル、ビルドされ、テスト環境のコンテナ サービスが置き換えられ、Jenkins または Hudson でユニット テストや統合テストが自動的に実行されます。テストに合格すると、新しいバージョンのイメージがオンライン バージョンに自動的に更新され、サービスのアップグレードが完了します。プロセス全体は完全に自動化され、一度に完了するため、操作とメンテナンスが最大限に簡素化され、オンライン環境とオフライン環境が完全に一貫していることが保証され、オンライン サービス バージョンと Git/SVN リリース ブランチも統一されます。

マイクロサービスアーキテクチャの実装課題の解決

マイクロサービスは、Spring Cloud などのマイクロサービス フレームワークに基づいて管理できますが、マイクロサービス自体はオペレーティング システム上で実行する必要があります。マイクロサービス アーキテクチャを使用して開発されたアプリケーションには、多くの場合、多数のマイクロサービスが存在するため、リソースの使用率を向上させるには、サーバー上で複数のマイクロサービスを起動する必要があり、マイクロサービス自体は一部のオペレーティング システムとのみ互換性がある場合があります。

つまり、サーバーリソースが多数ある場合（オペレーティングシステムが異なる場合あり）でも、マイクロサービス自体がオペレーティングシステムに関連している場合があるため、どのサーバーでもマイクロサービスを実行することは不可能であり、リソースの無駄や運用・保守の困難につながります。 Docker コンテナの環境分離機能を活用し、コンテナ内でマイクロサービスを実行することで、上記の問題を解決できます。

一時的なタスクの実行

ユーザーは、1 回限りのタスクを実行したいだけの場合もありますが、従来の仮想マシン方式を使用する場合、環境を構築し、タスクが完了した後にリソースを解放する必要があり、面倒です。 Docker コンテナを使用して一時的な動作環境を構築し、タスクが完了したらコンテナを閉じることができます。便利で早いです。

マルチテナント環境

Docker の環境分離機能を利用することで、異なるテナントに専用のコンテナを提供でき、実装が簡単でコストも低くなります。

11. 結論

Docker のテクノロジーは神秘的なものではありません。先人たちが蓄積してきたさまざまな成果を統合したアプリケーションレベルのコンテナ化技術です。さまざまな Linux ディストリビューションで使用されているバージョン互換のカーネル コンテナ化テクノロジを使用して、イメージを一度構築すればどこでも実行できるという効果を実現します。また、コンテナ内の基本的なオペレーティング システム イメージ レイヤーを使用して、実際のオペレーティング環境におけるオペレーティング システムの違いを隠蔽します。アプリケーションを開発する際、ユーザーは選択したオペレーティング システムとカーネル バージョンで正しく実行できることを確認するだけでよく、実際の動作環境でのシステムの違いをほとんど気にする必要がないため、効率と互換性が大幅に向上します。

しかし、実行されるコンテナが増えるにつれて、コンテナ管理は別の困難な運用と保守の問題になります。このとき、Kubernetes、Mesos、Swarm などのコンテナ管理システムを導入する必要があります。これらの技術については後ほど紹介する機会があると思います。