DockerコンテナのライフサイクルアーキテクチャとVMとの違いについて詳しく説明します。

コンテナのライフサイクル

コンテナランタイムのライフサイクル

コンテナは、分離特性を持つプロセスのセットです。docker run を使用する場合、独立したファイル システムを提供し、対応する実行プログラムを指定するためにイメージが選択されます。ここで指定する実行中のプログラムを初期プロセスと呼びます。初期プロセスが起動するとコンテナも起動します。初期プロセスが終了するとコンテナも終了します。

したがって、コンテナのライフサイクルは初期プロセスのライフサイクルと一致していると考えられます。もちろん、コンテナ内には複数の初期プロセスが存在するため、初期プロセス自体も他のサブプロセスや、docker exec によって生成される運用保守操作を生成する可能性があり、これらも初期プロセス管理の範囲に含まれます。最初のプロセスが終了すると、すべての子プロセスも終了します。これもリソースの漏洩を防ぐためです。

ただし、このアプローチにも問題があります。まず、アプリケーション内のプログラムはステートフルであることが多く、重要なデータを生成する可能性があります。コンテナが終了して削除されると、データは失われますが、これはアプリケーション側にとって受け入れられません。したがって、コンテナによって生成された重要なデータは永続化する必要があります。コンテナーは、データ ボリュームと呼ばれる指定されたディレクトリにデータを直接保存できます。

データ ボリュームにはいくつかの特性がありますが、その 1 つは、データ ボリュームのライフ サイクルがコンテナーのライフ サイクルとは独立していることです。つまり、コンテナーの作成、実行、停止、削除などの操作は、データ ボリュームとは無関係です。これは、データ ボリュームがコンテナーの永続化に使用される特別なディレクトリであるためです。簡単に言えば、データ ボリュームをコンテナーにマウントして、コンテナーが対応するディレクトリにデータを書き込むことができるようにし、コンテナーを終了してもデータが失われないようにします。

一般的に、データ ボリュームを管理する主な方法は 2 つあります。

1 つ目の方法は、bind を通じてホスト ディレクトリをコンテナ内に直接マウントする方法です。この方法は比較的シンプルですが、ホスト ディレクトリに依存し、すべてのホストを一元管理する必要があるため、運用および保守コストが発生します。

2 つ目は、ディレクトリ管理をランタイム エンジンに引き渡すことです。

コンテナプロジェクトのアーキテクチャ

Moby コンテナ エンジン アーキテクチャ

Moby は最も人気のあるコンテナ管理エンジンです。Moby デーモンは、コンテナ、イメージ、ネットワーク、ボリュームの管理を提供します。 moby デーモンが依存する最も重要なコンポーネントは containerd です。containerd は、moby デーモンから独立したコンテナ ランタイム管理エンジンであり、コンテナとイメージの管理を提供できます。

containerd の基盤となるレイヤーは、デーモン プロセスに似た containerd shim モジュールです。この設計には、いくつかの理由があります。

まず、containerd はコンテナのライフサイクルを管理する必要があり、コンテナは異なるコンテナ ランタイムによって作成される可能性があるため、柔軟なプラグイン管理が必要です。 Shim はさまざまなコンテナ ランタイム用に開発されているため、containerd から分離してプラグインを通じて管理できます。

次に、shim はプラグインとして実装されているため、containerd によって動的に引き継がれる可能性があります。この機能がないと、moby デーモンまたは containerd デーモンが予期せず終了すると、コンテナーは管理されなくなり、消えたり終了したりして、アプリケーションの動作に影響を及ぼします。

最後に、moby や containerd はいつでもアップグレードされる可能性があるため、shim メカニズムが提供されていない場合は、その場でアップグレードしたり、ビジネスに影響を与えずにアップグレードすることは不可能になります。したがって、動的テイクオーバーの機能を実装する containerd shim は非常に重要です。

上記は moby の一般的な紹介にすぎません。

コンテナとVM

コンテナとVMの違い

VM はハイパーバイザー仮想化テクノロジーを使用して CPU やメモリなどのハードウェア リソースをシミュレートし、ホスト マシン上にゲスト OS を確立できるようにします。これは、仮想マシンのインストールと呼ばれることがよくあります。

Ubuntu、CentOS、さらには Windows など、各ゲスト OS には独立したカーネルがあります。このようなゲスト OS では、各アプリケーションは互いに独立しており、VM はより優れた分離効果を提供できます。ただし、この分離効果には一定の代償が伴います。コンピューティング リソースの一部を仮想化に引き渡す必要があるため、既存のコンピューティング リソースを十分に活用することが困難になります。また、各ゲスト OS には大量のディスク領域が必要です。たとえば、Windows オペレーティング システムのインストールには 10～30G のディスク領域が必要であり、Ubuntu にも 5～6G が必要です。同時に、この方法は起動が非常に遅くなります。まさに仮想マシン技術の欠点のために、コンテナ技術が誕生したのです。

コンテナはプロセス用なので、ゲスト OS は必要ありません。必要なファイル セットを提供するには、独立したファイル システムのみが必要です。すべてのファイルの分離はプロセス レベルで行われるため、起動時間は VM よりも速く、必要なディスク領域も VM よりも小さくなります。もちろん、プロセスレベルの分離は想像したほど良くはなく、分離効果は VM よりもはるかに悪くなります。

全体：

VM と比較すると、コンテナには独自の長所と短所があるため、コンテナ技術も強力な分離に向けて発展しています。

Docker コンテナのライフサイクル アーキテクチャと VM との違いについては、上記の記事ですべて説明しました。参考になれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。