どのようなときに Docker コンテナーを使用するか

完了

ここまで説明したように、Docker には使用できる機能がいくつかあります。 ここでは、開発チームと運用チームにとっての Docker の利点について説明します。 また、Docker が最適な選択肢とはならないシナリオもいくつか紹介します。

これらの側面は、Docker が自分のコンテナー化戦略に適しているかどうかを判断するのに役立ちます。

以前の説明を思い出してください。チームは、注文追跡ポータルを開発して発行する際に、多数の課題に直面しています。 チームは次のソリューションを探しています。

  • ホスティング環境を簡単に管理する。
  • ソフトウェアの配信方法が継続されることを保証する。
  • サーバー ハードウェアを効率的に使用できるようにする。
  • アプリケーションの移植性を可能にする。

Docker は、これらの課題に対する解決策です。 これまでに説明したすべての利点を見てみましょう。

Docker の利点

Docker を使用すると、コンテナー化によって提供される利点をすぐに利用できるようになります。

ハードウェアの効率的な使用

コンテナーは、仮想マシン (VM) を使用せずに実行されます。 説明したように、コンテナーは、ファイル システム、ネットワーク管理、プロセス スケジューリング、メモリ管理などの機能について、ホスト カーネルに依存しています。

Diagram contrasting VM resource use versus Docker resource use.

VM と比較すると、VM 内で実行されているアプリケーションにカーネル機能を提供するために、VM には OS がインストールされている必要があることがわかります。 VM の OS にもディスク領域、メモリ、および CPU 時間が必要であることに注意してください。 VM と付加的な OS 要件をなくすことで、ホスト上のリソースを解放し、他のコンテナーを実行するために使用できます。

コンテナーの分離

Docker コンテナーでは、互いに影響を与えずに、同じホスト上で複数のコンテナーを同時に実行するためのセキュリティ機能が提供されます。 説明したように、コンテナーが分離されるようにデータ ストレージとネットワーク構成の両方を構成したり、特定のコンテナー間でデータと接続を共有したりすることができます。

この機能を、VM を使用する場合と比較してみましょう。

Diagram that shows a physical host running multiple VMs.

2 つの VM が実行されている物理ホストがあるものとします。 相互に分離して実行する必要がある 3 つのアプリケーションがあります。 1 つ目のアプリを VM1 上にデプロイし、2 つ目のアプリを VM2 上にデプロイして、これら 2 つのアプリを相互に分離することにします。 3 つ目のアプリケーションをインストールする場合、このパターンを続けるには、別の VM をインストールする必要があります。

アプリケーションの移植性

コンテナーは、デスクトップ、物理サーバー、VM、クラウド内など、ほとんどすべての場所で実行されます。 このランタイムの互換性により、コンテナー化されたアプリケーションは、異なる環境間で簡単に移動することができます。

コンテナーは軽量であるため、VM のような低速のスタートアップやシャットダウンに悩まされることがありません。 この側面により、再デプロイや、他のデプロイ シナリオ (スケーリング アップやスケーリング ダウンなど) が、円滑で高速になります。

アプリケーションの配信

Docker では、コンテナーがアプリケーションの配布に使用される単位です。 この概念により、開発者チームと運用チームの両方が、標準化されたコンテナー形式を確実に使用できます。 開発者はソフトウェアの開発に集中する、および運用チームはソフトウェアのデプロイと管理に集中することができます。

開発チームによってアプリケーションのビルドがリリースされた後は、デプロイ システムのすべてのステップでコンテナーを使用できます。 コンテナーは継続的インテグレーションに理想的な候補であり、ビルドから運用までの時間が短縮されます。

ホスティング環境の管理

アプリケーションの環境は、コンテナーの内部に構成されます。 このコンテインメントにより、運用チームはアプリケーションの環境のきめ細かい管理を柔軟に行うことができます。 チームは、OS の更新プログラムを監視して、セキュリティ パッチを 1 回適用し、必要に応じて更新されたコンテナーをロールアウトすることができます。

また、チームは、他のコンテナーに影響を与えることなく、インストール、更新、削除するアプリケーションを管理することもできます。 各コンテナーは分離されており、そのリソース制限は他のコンテナーとは別個に割り当てられます。

クラウドのデプロイ

Docker コンテナーは、Azure のコンテナー化サービスで使用される既定のコンテナー アーキテクチャであり、他の多くのクラウド プラットフォームでもサポートされています。

たとえば、Azure Container Instances、Azure App Service、Azure Kubernetes Service に Docker コンテナーをデプロイすることができます。 これらの各オプションでは、さまざまな機能が提供されています。

たとえば、Azure Container Instances を使用すると、インフラストラクチャを管理するオーバーヘッドがなくなり、アプリケーションの設計と構築に専念できます。 また、オーケストレーションするコンテナーが多数ある場合は、Azure Kubernetes Service を使用すると、大規模なコンテナーのデプロイを簡単にデプロイして管理することができます。

どのようなときに Docker コンテナーを使用しないか

Docker コンテナーには多くの利点がありますが、コンテナーがすべての要件に適合するとは限らないことにご留意ください。 注意すべき点がいくつかあります。

セキュリティと仮想化

コンテナーでは、あるレベルの分離が提供されます。 ただし、コンテナーでは 1 つのホスト OS カーネルが共有されるので、それが単一の攻撃ポイントになる可能性があります。

Windows ホストで提供される追加の分離モデルに基づき、専用の VM を使ってハイパーバイザー レベルでコンテナーを分離できます。 このモードは Hyper-V 分離モードと呼ばれ、コンテナーとコンテナー ホストの間にもう 1 つのセキュリティ レイヤーが追加されます。

また、ストレージとネットワークなどの側面も検討し、セキュリティのすべての側面を確実に考慮する必要もあります。 たとえば、すべてのコンテナーでは、既定でブリッジ ネットワークが使用され、IP アドレスを使用して相互にアクセスできます。

コンテナー化によりすべてのアプリケーションにメリットがあるとは限りません。 そのような場合では、VM を使用する方が、より合理的な場合があります。

サービスの監視

アプリケーションとコンテナーの管理は、従来の VM のデプロイよりも複雑です。 実行中のコンテナーの状態を示すログ機能はありますが、コンテナー内のサービスに関するより詳細な情報を監視するのは困難です。

たとえば、Docker には docker stats コマンドがあります。 このコマンドでは、CPU 使用率、メモリ使用率、ディスクへの書き込み I/O、送受信されたネットワーク データ、割り当てられたプロセス ID など、コンテナーに関する情報が返されます。 この情報は即時のデータ ストリームとして役立ちますが、そのデータは格納されないため、集計は行われません。 一定期間にわたって意味のあるデータのキャプチャを行うには、サードパーティ製ソフトウェアをインストールする必要があります。