コンテナーを定義する
Contoso がさまざまなワークロードを移行および仮想化する中で、ワークロードの一部をコンテナー化するオプションが生じる可能性があります。 Windows Server 管理者は、コンテナーを評価し、そのしくみと使用する利点を把握することになります。 利点としては、モビリティ、機敏性、効率の向上、サーバー密度などがあります。 これらの利点はすべて、サーバー ワークロードのさらなる最適化と開発環境の一貫性に寄与します。
コンテナーとは
コンテナーは、アプリケーションとそのすべての依存関係をパッケージ化し、実行されるホスト オペレーティング システム (OS) から抽象化するために使用されます。 コンテナーにより、開発と実行の環境が軽量になり、開発中にアプリケーションの実行や共有が容易になります。 コンテナーはホスト OS から分離されているだけでなく、他のコンテナーからも分離されています。 分離されたコンテナーには仮想ランタイムを利用できます。これにより、その中で実行されるアプリのセキュリティと信頼性を向上させることもできます。
従来、ソフトウェア アプリケーションは、サポートされているプロセッサ、ハードウェア、および OS プラットフォーム上で動作するように開発されていました。 通常、ソフトウェア アプリケーションには、さまざまなランタイム プラットフォームをサポートするために追加のコーディングが必要です。 このように多様なコンピューティング システムがある中で、複数のコンピューティング環境間の移植性をサポートするには、より効率的なソフトウェア開発および管理プラットフォームが必要です。 コンテナーは、そのような移植性を実現するために役立ちます。
コンテナーを使用する利点
コンテナーを使用する利点は次のとおりです。
どこでも実行できること。 コンテナーは、Linux、Windows、Mac オペレーティング システムなどのさまざまなプラットフォーム上で実行できます。 ローカル ワークステーション上、オンプレミスのデータセンターにあるサーバー上でこれらをホストすることや、クラウドにプロビジョニングすることができます。
分離。 アプリケーション側から見ると、コンテナーは完全な OS のように見えます。 CPU、メモリ、ストレージ、およびネットワーク リソースは、コンテナー内で仮想化され、ホスト プラットフォームやその他のアプリケーションから分離されています。
効率の向上。 コンテナーは、迅速なデプロイ、更新、スケールアップが可能であり、よりアジャイルな開発、テスト、運用のライフサイクルをサポートします。 消費するリソースの点で効率的であるため、フットプリントが小さくなり、サーバーの密度を高めることができます。
一貫性のある開発環境。 開発者は、Java、.NET、Python、Node.js などのさまざまな開発言語をサポートする、一貫性のある予測可能な開発環境としてコンテナーを使用しています。 開発者は、アプリケーションがどこにデプロイされたとしても、コンテナーのおかげで、意図したとおりにアプリケーションが動作することを確信できます。
コンテナーのしくみ
標準の Windows コンピューターのプロセッサには、"カーネル モード" と "ユーザー モード" という 2 つの異なるモードがあります。 コア OS コンポーネントとほとんどのデバイス ドライバーはカーネル モードで実行されますが、アプリケーションはユーザー モードで実行されます。
コンピューターにコンテナー テクノロジをインストールすると、各コンテナーには、ホスト OS 上でアプリを実行するために使用される分離された軽量のサイロが作成されます。 コンテナーは、ホスト オペレーティング システムのカーネルをベースに構築され、ファイル システムとレジストリにアクセスするためにほとんどの部分が共有されます。
各コンテナーには、ユーザー モード システム ファイルの独自のコピーがあり、他のコンテナーやホスト独自のユーザー モード環境からは分離されています。 ユーザー モードを分離する機能はコンテナー基本イメージによって提供されます。これは、パッケージ化されたアプリをサポートするために必要なユーザー モード システム ファイルで構成されます。 コンテナー ベース イメージ テンプレートには、コンテナー化されたアプリから使用される OS サービスのうち、ホストのカーネル モード レイヤーには用意されていない (または制限されている) 基礎的なレイヤーが用意されています。
アプリケーションとコードの変更が行われるレイヤーは、これらの構築済みのコンテナー基本 OS イメージ レイヤー上にあります。 これらのベース OS レイヤーは、アプリケーションやコードの変更に積極的に使用されるコンテナー レイヤーとは別に開発および更新されます。 ベース レイヤーは更新されずにローカルの作業環境にプルされ、ベース レイヤー上で実行されるコンテナー レイヤーで作業が開始されます。 これにより、より小さく、より軽量で、よりポータブルな開発環境を実現できます。
独自のコンテナー イメージを構築してアプリケーションをホストする場合は、まず、コンテナー基本 OS イメージまたは必要な依存関係を持つ事前構築済みのコンテナー イメージを利用します。 これらのレイヤーの上に、コンテナーで実行するアプリケーションを使用して独自のレイヤーを構築します。 コンテナー イメージを作成する各操作では、最後のものの上に構築します。 これによりイメージ サイズが追加されますが、OS、フレームワーク、依存関係、およびアプリケーション レイヤーを簡単に分離できます。
コンテナーとマイクロサービス
マイクロサービス アプリケーションは、単一のアプリケーションが多くの疎結合で独立してデプロイ可能であるより小さなコンポーネント、またはサービスで構成されるクラウド ネイティブアーキテクチャ アプローチとして定義されています。 これらのより小さなコンポーネントまたはサービスはそれぞれコンテナーで表すことができます。 しかし、コンテナーで必ずしもマイクロサービス アーキテクチャが実装されるとは限りません。
コンテナーはモノリシック アプリケーションをホストできますが、その目的のために設計されていませんでした。 既定では、Docker (または別のコンテナー ランタイム) とコンテナー オーケストレーターは、コンテナーを常に安全に削除または除去でき、必要に応じて単に別のコンテナーを代わりにすることができると想定します。 VM では、VM ディスクに書き込むようにアプリケーションを構成した場合、その VM を安全に停止して起動できます。VM が安全に起動して操作を続行するのと同様に、データはディスクに保持されます。 コンテナーを使用する場合、あるコンテナーを除去し、別のものを代わりにすると、そのコンテナー イメージの既存のレイヤーのみが存在することになります。 マイクロサービス環境では、状態とデータが持続している場合、これは問題にならないはずです。
コンテナーを実行して VM とほぼ同じように管理できますが、状態とデータの分離のプラクティスを採用し、確実にコンテナーを持続的に削除できるようにすることをお勧めします。 これにより、DevOps などの他のプラクティスを利用できます。
実際には、コンテナー イメージとそのレイヤー内にデータまたは状態を格納する必要はありません。 代わりに、任意のコンテナー インスタンスがアクセスできるようにする外部永続ストレージを使用する必要があります。