コンテナ化されたアプリケーションは「分離」されています。つまり、オペレーティング・システムのコピーにはバンドルされていません。代わりに、オープンソースのコンテナ・ランタイムまたはコンテナ・エンジン（Dockerランタイム・エンジンなど）がホストのオペレーティング・システムにインストールされ、コンテナが同じコンピューティング・システム上の他のコンテナとオペレーティング・システムを共有するための経路となります。

共通バイナリー（bin）やライブラリーのような他のコンテナ層は、複数のコンテナ間で共有できます。この機能により、各アプリケーション内でオペレーティング・システムを実行するオーバーヘッドがなくなり、コンテナはVMよりも容量が小さく、起動が速くなるため、サーバー効率が向上します。また、アプリケーションをコンテナとして分離することで、あるコンテナ内の悪意のあるコードが他のコンテナに影響を与えたり、ホスト・システムに侵入したりする可能性が低くなります。

ホスト・オペレーティング・システムからの抽象化によって、コンテナ化されたアプリケーションは移植可能になり、あらゆるプラットフォームまたはクラウドで均一かつ一貫して実行できるようになります。コンテナは、デスクトップ・コンピューターから仮想マシン（VM）へ、あるいはLinuxからWindowsオペレーティング・システムへ簡単に転送できます。また、コンテナは、オンプレミスまたはクラウド・データセンターの仮想化インフラストラクチャーや従来のベアメタル・サーバー上で一貫して実行されます。

コンテナ化により、ソフトウェア開発者は、アプリケーションが従来のモノリス（単一層のソフトウェア・アプリケーション）であるか、またはマイクロサービス・アーキテクチャー上に構築されたモジュール型アプリケーションであるかに関係なく、アプリケーションをより迅速かつ安全に作成し、デプロイできるようになります。開発者は、コンテナ化されたマイクロサービスとして、新しいクラウドベースのアプリケーションを最初から構築し、複雑なアプリケーションを、より小さく、専門化された、管理可能な一連のサービスに分割することができます。また、既存のアプリケーションをコンテナ（またはコンテナ化されたマイクロサービス）に再パッケージ化し、コンピュート・リソースをより効率的に使用することもできます。

仮想化ではハイパーバイザーを利用します。ハイパーバイザーは、物理コンピューターまたはサーバー上に配置されるソフトウェア層で、これにより物理コンピューターがオペレーティング・システムとアプリケーションをハードウェアから分離することができます。仮想化テクノロジーにより、複数のオペレーティング・システムおよびソフトウェア・アプリケーションを同時に実行し、単一の物理コンピューターまたはホスト・マシンのリソース（例えば、CPU、ストレージ、メモリー）を共有できます。例えば、IT組織はWindowsとLinuxの両方、または複数のバージョンのオペレーティング・システムを、さまざまなアプリケーションとともに同じサーバー上で稼働させることができます。

各アプリケーションとそれに関連するファイル・システム、ライブラリー、その他の依存関係（オペレーティング・システム（OS）のコピーを含む）は、VMとしてパッケージ化されます。単一の物理マシン上で複数のVMを実行すると、資本コスト、運用コスト、エネルギー・コストを大幅に節約できます。

一方、コンテナ化はコンピュート・リソースをさらに効率的に使用します。コンテナは、アプリケーションコードとその実行に必要なすべての依存関係をバンドルした、単一の実行可能なソフトウェア・パッケージを作成します。しかし、VMとは異なり、コンテナはOSのコピーをバンドルしていません。代わりに、コンテナ・ランタイム・エンジンがホスト・システムのオペレーティング・システム、つまり「ホストOS」にインストールされ、コンピューティング・システム上のすべてのコンテナが同じOSを共有するための経路になります。

コンテナはしばしば「軽量」と呼ばれます。これらはマシンのOSカーネルを共有し、（VMの場合のように）各アプリケーション内でOSを関連付けるオーバーヘッドが不要です。その他のコンテナ層（共通binやライブラリー）も複数のコンテナ間で共有できるため、コンテナは本質的にVMよりも容量が小さく、起動が速くなります。複数のコンテナを単一のVMと同じコンピュート容量で実行できるため、サーバー効率がさらに向上し、サーバーとライセンスのコストが削減されます。

次のビデオでは、コンテナとVMの比較を詳しく説明しています。

コンテナベースのソリューションが増加するにつれて、コンテナ・テクノロジーやソフトウェア・コードのパッケージ化手法に関する標準が必要となりました。Open Container Initiative（OCI）²は、Dockerとその他の業界リーダーによって2015年6月に設立されたLinuxプロジェクトで、コンテナ・テクノロジーに関する共通で最小限のオープンな標準と仕様を推進する方法として登場しました。それ以来、OCIはオープンソース・エンジンの選択肢を広げ、ユーザーがベンダー・ロックインを回避できるよう支援してきました。また、開発者は、多様なDevOpsツールを使用してコンテナ化されたアプリケーションを構築し、選択したインフラストラクチャー上で一貫して実行できる、OCI認定テクノロジーを利用することもできます。

混乱を避けるため、DockerとはDocker, Inc.³も指しています。同社は、Dockerコンテナ・テクノロジーを基盤とした生産性向上ツールを開発する企業です。また、Dockerは、Docker, Inc.をはじめとする多くの組織や個人が貢献しているDockerオープンソース・プロジェクト²にも関連しています。

Dockerは最もよく知られ、よく使用されているコンテナ・エンジン・テクノロジーですが、より広範なエコシステムは、containerdや、CoreOS rkt、Mesos Containerizer、LXC Linux Containers、OpenVZ、crio-d などの他の代替手段で標準化されています。

コンテナ・オーケストレーション・プラットフォームは、コンテナのデプロイメント、ネットワーク、負荷分散、拡張性、可用性などの管理をスケジュールし、自動化します。

最も人気のあるコンテナ・オーケストレーション・ツールであるKubernetesは、Linuxのコンテナ機能を自動化するオープンソース・テクノロジー（もともとはGoogleがオープンソース化したもので、Borgと呼ばれる社内プロジェクトがベースになっている）です。Kubernetesは、Docker Engineのような多くのコンテナ・エンジンと連携します。また、コンテナ・イメージのフォーマットとランタイムに関するOpen Container Initiative（OCI）標準に準拠するコンテナ・システムであれば、どのようなものでも動作します。

Kubernetesは業界標準ですが、他の一般的なコンテナ・オーケストレーション・プラットフォームには、Apache Mesos、Nomad、 Docker Swarmなどがあります。

コンテナ・オーケストレーションの詳細については、Kubernetesの仕組みを説明する次のビデオをご覧ください。

コンテナ化は、アプリケーションのモダナイゼーションに不可欠な要素です。これは、モノリシックな（レガシーな）アプリケーションを、あらゆるクラウド環境に統合するように設計されたマイクロサービス・アーキテクチャー上に構築されているクラウドネイティブ・アプリケーションに変換するプロセスのことです。

マイクロサービスは、ソフトウェア・アプリケーションと、関連するユーザー・インターフェースおよび基礎となるデータベースを、単一サーバー・プラットフォーム上の単一のユニットに統合する以前のモノリシック・モデルと比較すると、アプリケーション開発と管理のための優れたアプローチです。マイクロサービスでは、複雑なアプリケーションは、それぞれが独自のデータベースと独自のビジネス・ロジックを持つ、より小さく、より特化した一連のサービスに分割されます。マイクロサービスは、共通インターフェース（APIなど）とRESTインターフェース（HTTPなど）を介して通信します。マイクロサービスを使用することで、開発チームはアプリケーション全体に影響を与えることなく、アプリケーションの特定領域の更新に集中できるため、開発、テスト、デプロイメントが迅速化されます。

マイクロサービスとコンテナ化の背後にある概念は似ています。どちらも、基本的にアプリケーションを、移植可能かつスケーラブルで、効率性が高く、管理しやすい、より小さなサービスあるいはコンポーネントの集合に変換するソフトウェア開発手法です。

さらに、マイクロサービスとコンテナ化は一緒に使用するとうまく機能します。アプリケーションが従来のモノリス型であるか、モジュラー・マイクロサービスであるかにかかわらず、コンテナはすべてのアプリケーションの軽量のカプセル化を可能にします。コンテナ内で開発されたマイクロサービスは、移植性など、コンテナ化の固有のメリットをすべて備えています。

全体として、コンテナ、マイクロサービス、クラウド・コンピューティングが統合され、アプリケーションの開発とデリバリーが新たなレベルに引き上げられました。これらのテクノロジーはDevOpsワークフローを簡素化し、継続的インテグレーションおよび継続的デリバリー（CI/CD）パイプラインをサポートしてソフトウェア開発を加速します。これらの次世代のアプローチは、ソフトウェア開発ライフサイクルに俊敏性、効率性、信頼性をもたらし、コンテナ化されたアプリや機能拡張をユーザーや市場に迅速に提供することにつながっています。

組織はクラウドへの移行を続けています。クラウドでは、ユーザーはアプリケーションを迅速かつ効率的に開発できます。コンテナ化は、クラウド移行のための重要なビジネス・ユースケースとなっています。クラウド移行とは、データ、アプリケーション、ワークロードをオンプレミスのデータセンターからクラウドベースのインフラストラクチャーへ、またはあるクラウド環境から別のクラウド環境へ移行するプロセスです。

クラウド移行は、組織のハイブリッドクラウド環境にとって不可欠な要素です。これは、オンプレミス、パブリッククラウド、プライベートクラウドのサービスを組み合わせて、クラウド環境全体にわたってワークロード管理をサポートし、自動化する、柔軟でコスト効率の高い単一のITインフラストラクチャーを構築するプロセスです。

今日、クラウドベースのアプリケーションとデータは、インターネットに接続されたあらゆるデバイスからアクセスできるため、チーム・メンバーはリモートでも外出先でも仕事ができます。クラウド・サービス・プロバイダー（CSP）（例えば、Amazon Web Services（AWS）、Google Cloud Services、IBM® Cloud、Microsoft Azure）は、基盤となるインフラストラクチャーを管理することで、サーバーやその他の機器のコストを削減し、また信頼性を高めるために自動化されたネットワーク・バックアップを提供します。クラウド・インフラストラクチャーはオンデマンドで拡張し、負荷要件の変化に応じてコンピューティング・リソース、容量、インフラストラクチャーを動的に調整します。さらに、CSPは定期的にサービスを更新し、ユーザーが生成AIのような最新の革新的なテクノロジーに継続的にアクセスできるようにします。

大手クラウド・サービス・プロバイダーの多くは、Container as a service（CaaS）を提供しています。本質的に、Infrastructure as a service（IaaS）のサブセットであるCaaSは、クラウド・コンピューティング・スタックにおけるIaaSとPlatform as a service（PaaS）の中間に位置し、IaaSが提供する制御とPaaSの簡便さのバランスが取れています。

CaaSは、コンテナベースの仮想化とコンテナ管理プロセスの効率化ができるクラウドベースのプラットフォームです。 CaaSはまた、コンテナ・ランタイム、オーケストレーション・レイヤー、永続ストレージ管理も提供します。2022年、世界のCaaS市場は約20億米ドルと評価されました。⁵

サーバーレス・コンピューティング（サーバーレス）は、開発者がサーバーやバックエンド・インフラストラクチャーのプロビジョニングや管理を行わずにアプリケーション・コードを構築および実行できるようにする、クラウド・コンピューティング・アプリケーションの開発および実行モデルです。

サーバーレス・コンピューティングでは、クラウド・サービス・プロバイダーがオン・デマンドでマシン・リソースを割り当て、顧客に代わってサーバーを保守します。 具体的には、開発者とクラウド・サービス・プロバイダーは、コードの実行に必要なクラウド・インフラストラクチャーのプロビジョニングと、必要に応じオン・デマンドでインフラストラクチャーのスケールアップ・スケールダウンを処理します。プロバイダーは従量課金制の料金モデルを採用しています。

サーバーレス・コンピューティングでは、チームがインフラストラクチャーの管理ではなくコーディングに集中できるため開発者の生産性を上げることができます。対照的に、コンテナは制御性と柔軟性に優れ、既存のアプリケーションの管理やクラウドへの移行に便利です。 

このような対策は、コンテナ化プラットフォーム、コンテナ・イメージ、オーケストレーション・プラットフォーム、個々のコンテナとアプリケーションなど、すべてのスタック・レイヤーに対応しなければなりません。 

何よりもまず、コンテナのセキュリティポリシーは、 ゼロトラスト ・フレームワークを中心に展開しなければなりません。この モデルを採用することで、すべてのユーザー接続を検証し承認でき、やりとりが組織のセキュリティ・ポリシーの条件付き要件を満たしていることを担保できます。ゼロトラスト・セキュリティ戦略では、できるだけ多くのデータ・ソースからのコンテキストを使用して、動的ポリシーに基づきすべてのデバイス、ネットワーク・フロー、接続を認証・認可します。

アプリケーションのデプロイとスケーリングにオーケストレーション・プラットフォームなどのコンテナ化技術を利用する組織が増えるにつれ、コンテナ・セキュリティはますます大きな懸念事項となってきています。Red Hat社⁶のレポートによると、脆弱性と構成ミスはコンテナ環境とKubernetes環境におけるセキュリティ上の最大の懸念事項です。 

前述したように、コンテナ化されたアプリケーションは、独立したプロセスとして実行でき、他のコンテナから独立して動作できるため、本質的に一定レベルのセキュリティーを備えています。これにより、悪意のあるコードが他のコンテナに影響を与えたり、ホストシステムに侵入したりするのを防ぐことができます。ただし、コンテナ内のアプリケーション層はコンテナ間で共有されることがよくあります。これはリソース効率に関していえば有益ですが、コンテナ間の干渉やセキュリティ侵害への扉を開くことにもつながります。共有のOS（オペレーティング・システム）についても同じことが言えます。複数のコンテナを同じホストOSに関連付けることが可能だからです。共有のOSへのセキュリティ脅威は、関連するすべてのコンテナに影響を与える可能性があります。また逆に、コンテナ侵害ではホストOSに侵入する可能性があります。

しかし、コンテナ・イメージ自体に関連するリスクと脆弱性についてはどうでしょうか。堅牢なコンテナ化戦略には、「セキュア・バイ・デフォルト（デフォルトでセキュア）」アプローチが含まれます。これは、セキュリティがプラットフォームに固有のものであり、個別に展開および構成されたソリューションではないことを意味します。この目的を達成するため、コンテナ・エンジンは、基盤となるOSにおいてデフォルトの独立したプロパティをすべてサポートします。セキュリティ権限を定義して、不要なコンポーネントがコンテナに入るのを自動的にブロックしたり、不要なリソースとの通信を制限したりできます。

たとえば、Linux名前空間により、システムで独立したビューを各コンテナに提供できます。これには、ネットワーク、マウント・ポイント、プロセスID、ユーザーID、プロセス間通信、ホスト名の設定が含まれます。名前空間により、各コンテナ内のプロセスを通じたこれらのリソースへのアクセスを制限できます。通常、名前空間をサポートしていないサブシステムにはコンテナ内からアクセスできません。管理者は、シンプルなユーザー・インターフェースを通じて、コンテナ化された各アプリケーション上でこれらの「独立した制約」を簡単に作成し管理できます。

さらに、企業全体の脅威の検出と対応を自動化するために、幅広いコンテナ・セキュリティ・ソリューションを利用できます。これらのツールにより、セキュリティ・ポリシーを監視し適用して業界標準を満たしデータの安全なフローを確保できます。例えば、セキュリティ管理ソフトウェア・ツールにより、CI/CDパイプラインの自動化、本番前の脆弱性のブロック、リアルタイムの可視性による不審なアクティビティの調査が可能になります。このアプローチはDevSecOpsに該当し、これはソフトウェア開発ライフサイクルのあらゆるレベルで、セキュリティ対策の統合を自動化するアプリケーションおよび開発プロセスです。