VM ではなく Docker が必要であることをどのように理解すればよいでしょうか? 何を分離するかを正確に決定する必要があります。 リソースと仮想ハードウェアが保証されたシステムを分離したい場合は、VM を選択する必要があります。 実行中のアプリケーションを別のシステム プロセスとして分離する必要がある場合は、Docker が必要になります。
では、Docker コンテナと VM の違いは何でしょうか?
仮想マシン (VM) は、すべての仮想デバイスと仮想ハード ディスクを備えた仮想コンピューターであり、その上に、新しい独立した OS が、仮想デバイス ドライバー、メモリ管理、その他のコンポーネントとともにインストールされます。 つまり、XNUMX 台のコンピューター上で多数の仮想コンピューターを実行できるようにする物理ハードウェアの抽象化が得られます。
インストールされた VM は、さまざまな方法でディスク領域を占有する可能性があります。
- 固定ハードディスク容量により、仮想ハードディスクへのアクセスが高速になり、ファイルの断片化が回避されます。
- 動的メモリ割り当て。 追加のアプリケーションをインストールすると、割り当てられた最大量に達するまでメモリが動的に割り当てられます。
サーバー上の仮想マシンの数が増えると、占有スペースも増え、アプリケーションの動作に必要な環境の継続的なサポートも必要になります。
デッカー コンテナに基づいてアプリケーションを構築するためのソフトウェアです。 コンテナと仮想マシンには同様の利点がありますが、動作方法が異なります。 コンテナは場所をとらないため、 VM よりもホスト システムの共有リソースを過剰に使用するため、 VM とは異なり、ハードウェアではなく OS レベルで仮想化を提供します。 このアプローチにより、メモリ使用量が減り、導入が高速化され、スケーリングが容易になります。
コンテナーは、ホスト システムに必要なインターフェイスを提供することで、アプリケーションをカプセル化するためのより効率的なメカニズムを提供します。 この機能により、コンテナーはシステムのコアを共有できるようになり、各コンテナーは、独自のメモリ領域セット (独自の仮想アドレス空間) を持つメイン OS の別個のプロセスとして実行されます。 各コンテナの仮想アドレス空間は独自であるため、異なるメモリ領域に属するデータを変更することはできません。
Docker のネイティブ OS は Linux (Docker は Windows および MacOS でも使用できます) であり、その主な利点を利用して、分割カーネルを編成できます。 Windows 上での Docker コンテナの起動は、Linux 仮想マシン内で行われます。 コンテナはホスト システムの OS を共有し、コンテナのメイン OS は Linux です。
コンテナ - どのように機能するのか?
コンテナ コードと依存関係を組み合わせたアプリケーション レベルの抽象化です。 コンテナーは常にイメージから作成され、書き込み可能な最上位レイヤーが追加され、さまざまなパラメーターが初期化されます。 コンテナーには独自の書き込みレイヤーがあり、すべての変更がそのレイヤーに保存されるため、複数のコンテナーが同じマスター イメージへのアクセスを共有できます。
各コンテナーは、メイン ソリューション docker-compose.yml に含まれる docker-compose プロジェクト内のファイルを介して構成できます。 そこでは、コンテナー名、ポート、識別子、リソース制限、他のコンテナー間の依存関係などのさまざまなパラメーターを設定できます。 設定でコンテナー名を指定しない場合、Docker は毎回新しいコンテナーを作成し、名前をランダムに割り当てます。
コンテナーがイメージから開始されると、Docker は読み取り/書き込みファイルシステムをその下のレイヤーの上にマウントします。 ここで、Docker コンテナに実行させたいすべてのプロセスが実行されます。
Docker が初めてコンテナーを起動するとき、最初の読み取り/書き込みレイヤーは空です。 変更が発生すると、その変更はそのレイヤーに適用されます。 たとえば、ファイルを変更する場合、そのファイルはその下の読み取り専用レイヤーから読み取り/書き込みレイヤーにコピーされます。
ファイルの読み取り専用バージョンは引き続き存在しますが、コピーの下に隠されています。 ボリュームは、コンテナーのライフサイクルに関係なく、データを保存するために使用されます。 ボリュームはコンテナの作成時に初期化されます。
画像はコンテナにどのように関連付けられていますか?
イメージ - 各コンテナのメイン要素。 イメージは、プロジェクトに追加された Dockerfile から作成され、相互に階層化されてグループ化された一連のファイル システム (レイヤー) であり、読み取り専用です。 最大レイヤー数は 127 です。
各イメージの中心となるのは、FROM コマンドによって指定される基本イメージです。これは、Dockerfile イメージを生成するときのエントリ ポイントです。 各レイヤーは読み取り専用レイヤーであり、ファイル システムを変更する Dockerfile に記述された単一のコマンドによって表されます。
これらのレイヤーを XNUMX つのイメージに結合するために、Docker は高度な多層 Union ファイル システム (AuFS は UnionFS の上に構築されます) を使用します。これにより、異なるファイル レイヤーの異なるファイルとディレクトリを透過的にオーバーラップさせ、関連するファイル システムを作成できます。
レイヤーには、実行時およびビルド時に各レイヤーに関する関連情報を保存できるメタデータが含まれています。 各レイヤーには次のレイヤーへのリンクが含まれています。レイヤーにリンクがない場合、これが画像の最上位レイヤーになります。
Dockerfile には次のようなコマンドが含まれる場合があります。
- FROM - イメージの形成におけるエントリ ポイント。
- MAINTAINER - イメージの所有者の名前。
- RUN - イメージのアセンブリ中のコマンドの実行。
- ADD - ホスト ファイルを新しいイメージにコピーします。URL ファイルを指定すると、Docker はそれを指定されたディレクトリにダウンロードします。
- ENV - 環境変数。
- CMD - イメージに基づいて新しいコンテナの作成を開始します。
- ENTRYPOINT - コンテナーの起動時にコマンドが実行されます。
- WORKDIR は、CMD コマンドを実行するための作業ディレクトリです。
- USER - イメージから作成されたコンテナの UID を設定します。
- VOLUME - ホスト ディレクトリをコンテナにマウントします。
- EXPOSE は、コンテナ内でリッスンされるポートのセットです。
UnionFS はどのように機能しますか?
ユニオンFS — Linux および FreeBSD 用のサービス スタック ファイル システム (FS)。 この FS は、コピーオンライト (Copy-On-Write、COW) メカニズムを実装します。 UnionFS の作業単位はレイヤーであり、各レイヤーは、ルート自体からのディレクトリ階層を持つ独立した本格的なファイル システムと見なす必要があります。 UnionFS は他のファイルシステムのユニオンマウントを作成し、異なるファイルシステム (ブランチと呼ばれる) のファイルとディレクトリを単一のリンクされたファイルシステムにユーザーに透過的にマージできるようにします。
同じパスを持つディレクトリの内容は、結果として得られるファイル システムの XNUMX つの結合ディレクトリ (同じ名前空間内) にまとめて表示されます。
UnionFS は、次の原則に基づいてレイヤーを結合します。
- いずれかの層が最上位層となり、XNUMX 番目以降の層が下位層になります。
- ユーザーはレイヤー オブジェクトに「上から下へ」アクセスできます。つまり、 要求されたオブジェクトが「上」層にある場合は、「下」層に同じ名前のオブジェクトが存在するかどうかに関係なく、そのオブジェクトが返されます。 それ以外の場合は、「最下位」レイヤー オブジェクトが返されます。 要求されたオブジェクトがそこにも存在しない場合は、「そのようなファイルまたはディレクトリはありません」というエラーが返されます。
- 作業レイヤーは「最上位」レイヤーです。つまり、データを変更するすべてのユーザー操作は、下位レベルのレイヤーの内容に影響を与えることなく、最上位レイヤーにのみ反映されます。
Docker は、アプリケーション作業でコンテナを使用するための最も一般的なテクノロジです。 これは、Linux カーネルによって提供される cgroup と名前空間に基づいて構築されており、この分野の標準となっています。
Docker を使用すると、すべてのコンテナ間で OS カーネルを共有し、個別の OS プロセスとして実行することで、アプリケーションを迅速にデプロイし、ファイル システムを最大限に活用できます。
出所： habr.com