その結果、コンテナ・プラットフォーム上で実行されるコンテナ・イメージが作成されます。コンテナ・イメージは、アプリケーションとそのすべてのソフトウェア依存関係をカプセル化したバイナリー・データを表します。 

コンテナ化により、アプリケーションを「一度書き込みをすればどこでも実行できる」ようになり、ポータブルになり、開発プロセスが高速化でき、クラウド・ベンダーのロックインを防ぐことができます。 

コンテナ化と プロセスの分離は 何十年も前から存在していました2。 コンテナ開発の歴史的な瞬間は、1979年にUnixバージョン7オペレーティング・システムの一部であるchrootの開発に伴い起きました。 Chrootは、アプリケーションのファイル・アクセスを特定のディレクトリ（ルート）とその子（またはサブプロセス）に制限することで、プロセス分離の概念を導入しました。

もう1つの重要な節目は2008年に起きました。このとき、Linuxコンテナ（LXC）がLinuxカーネルに実装され、Linux の単一インスタンスの仮想化が完全に実現できるようになりました。長年にわたり、FreeBSD jailやAIXワークロード・パーティションなどの技術によって、同様のOSレベルの仮想化が提供されてきました。

LXCは今でもよく知られたランタイムで、Linuxディストリビューションや ^{ベンダーニュートラル・プロジェクト}3の一部ですが、最新のLinuxカーネル技術も利用できます。最新のオープンソースLinux OSであるUbuntuでも、この機能が利用可能です。 

コンテナ化の詳細について、動画を見る

多くの開発者は、 Dockerが導入された2013年を現代のコンテナ時代の始まりと見ています。Dockerは、 プラットフォーム・アズ・ア・サービス（PaaS）として機能するオープンソースのコンテナ化ソフトウェア・プラットフォームであり、 開発者はコンテナを構築、導入、実行、更新、管理できます。

Dockerを使うと、Linuxカーネル（OSの基本コンポーネント）とカーネル機能（Cgroupや名前空間など）を使ってプロセスを分離し、独立したプロセスを実行できます。Dockerは基本的に、アプリケーションとその依存関係を取得し、Windows、macOS、Linuxを実行する任意のコンピューター・システムで実行できる仮想コンテナに変換します。

Dockerはクライアント・サーバー・アーキテクチャーに基づいており、基盤となる技術としてDockerエンジンが使われています。Dockerはイメージベースのデプロイ・モデルを提供し、コンピューティング環境間でのアプリの共有を容易にしています。 

混乱を避けるためにお伝えすると、Dockerコンテナ・プラットフォームという名前は、オープンソース・コンテナ化プラットフォームやDockerオープンソース・エコシステムおよびコミュニティ⁵を中心に構築された業務効率化ツールを開発する Docker, Inc. ⁴社のことも指しています。

2015年、Dockerをはじめとするコンテナ業界のリーダーは、Linux Foundation の一部であるThe Open Container Initiative^{6を設立しました} 。これは、 コンテナ形式とランタイム環境に 関するオープンな業界標準を作成することを明確な狙いとしている オープン・ガバナンス機構です。

Dockerは最も広く使われているコンテナ化ツールで、市場シェアは実に82.84％です。⁷

システム全体で何十万ものコンテナを運用すると管理できなくなる可能性があり、オーケストレーション管理ソリューションが必要になってきます。 

この課題に対処するために、 コンテナ・オーケストレーション は、次のような大量のコンテナをコンテナ・ライフサイクル全体にわたって管理する方法として登場しました。 

• プロビジョン
• 冗長性
• ヘルス・モニタリング
• リソース割り当て
• スケーリングと ロード・バランシング
• 物理ホスト間の移動

他のコンテナ・オーケストレーション・プラットフォーム（Apache Mesos、Nomad、 Docker Swarmなど）も存在しますが、 Kubernetesが業界標準となっています。

Kubernetesアーキテクチャーは、複数のマシンや環境にわたってコンテナを実行できるようにする実行クラスターで構成されています。通常、各クラスターは、コンテナ化されたアプリケーションを実行する ワーカー・ノードと、クラスターを制御する 制御プラン・ノードで構成されています。 コントロール・プレーンは、Kubernetesクラスターのオーケストレーターとして機能します。これには、APIサーバー（Kubernetesとのすべてのやりとりを管理）、コントロール・マネージャー（すべての制御プロセスを処理）、 クラウド・コントローラー・マネージャー（クラウド・プロバイダーのAPIとのインターフェース）など、いくつかのコンポーネントが含まれます。 ワーカー・ノードは、Dockerなどのコンテナ・ランタイムを使用してコンテナを実行します。ポッドはクラスター内でデプロイ可能な最小単位であり、1つまたは複数のアプリ・コンテナを保持し、ストレージやネットワーク情報などのリソースを共有します。

Kubernetesを使用すると、開発者とオペレーターは、 YAMLファイルを通じてコンテナ環境全体の望ましい状態を宣言できます。次に、Kubernetesは、特定のアプリケーションまたはワークロードの指定された数のインスタンスのデプロイ、 障害 が発生した場合のアプリケーションの再起動、ロード・バランシング、 自動スケーリング 、ゼロ・ダウンタイム・デプロイなどのアクティビティを伴う状態を確立・維持するための すべての処理作業を実行します。 Kubernetesを使用したコンテナ・オーケストレーションは 、継続的インテグレーションと継続的デリバリー （CI/CD）や DevOps パイプラインにとっても欠かせないもので、 自動化なしでは不可能です。

2015年、Googleは Cloud Native Computing財団（CNCF）^{8にKubernetesを寄贈しました}。CNCFは、Linux財団の後援の下で運営されているオープンソースかつベンダーに依存しない クラウドネイティブ ・コンピューティングのハブです。以来、Kubernetesは、コンテナベースのワークロードを実行する際に世界で最も広く使用されているコンテナ・オーケストレーション・ツールとなりました。Kubernetesは、CNCFレポートにおいて ⁹、世界で2番目に大きな オープン・ソース  ・プロジェクト（首位はLinux）であり、Fortune誌が選ぶ世界の上位企業100社の実に71%に主要なコンテナ・オーケストレーション・ツールとして選ばれています。 

Containers as a service (CaaS) とは、開発者がコンテナ化されたアプリケーションを管理し、デプロイできるようにするクラウド・コンピューティング・サービスです。どのような規模の企業でも、移植や拡張が容易なクラウド・ソリューションにアクセスできるようにします。

CaaSは、コンテナベースの仮想化とコンテナ管理プロセスの効率化ができるクラウドベースのプラットフォームです。 CaaSプロバイダーは、コンテナ・ランタイム、オーケストレーション・レイヤー、永続ストレージ管理を含む（がこれらに限定されない）多種多様な機能を提供しています。

 インフラストラクチャー・アズ・ア・サービス（IaaS） 、プラットフォーム・アズ・ア・サービス（PaaS）、ソフトウェア・アズ・ア・サービス（SaaS）と同様に、 CaaSはクラウド・サービス・プロバイダー（AWS、Google Cloud Services、IBM Cloud 、Microsoft Azure など）から従量課金制の料金体系モデルを通じて提供されており、ユーザーは使用したサービスのみに対して料金を支払います。 

開発者がコンテナを使用してマイクロサービスを構築および実行すると、管理上の懸念は個々のコンテナのライフサイクルの考慮を超えて、多数の小さなサービス（多くの場合「サービスメッシュ」と呼ばれる）が相互に接続して関係する方法にまで及びます。Istioにより、開発者は、検出、トラフィック、監視、セキュリティーなどに関連する課題を簡単に管理できるようになります。

Knative （「ケイネイティブ」と読みます）は、 サーバーレス・コンピューティング への容易な導入を提供するオープンソース・プラットフォームです。サーバーレス・コンピューティングは、開発者がサーバーやバックエンド・インフラストラクチャーをプロビジョニングまたは管理する必要がなく、アプリケーション・コードを構築して実行できるクラウド・コンピューティング・アプリケーションの開発および実行モデルです。

 サーバーレスは、リクエストを待っている間、アイドル状態のコードの進行中のインスタンスをデプロイする代わりに、必要に応じてコードを起動し、需要の変動に応じてスケールアップまたはスケールダウンし、使用していないときはコードを停止します。サーバーレスでは、コードを実際に実行するときにのみ支払いが発生するため、コンピューティング容量と電力の無駄を防ぎ、コストを削減できます。

コンテナはどこにでもデプロイできるため、コンテナ・ベースの環境の周囲に新たな攻撃対象領域が生まれます。脆弱なセキュリティー領域には、コンテナ・イメージやイメージ・レジストリー、コンテナ・ランタイム、コンテナ・オーケストレーション・プラットフォーム、ホスト・オペレーティング・システムが含まれます。

まず、企業はコンテナのセキュリティーを自社のセキュリティー・ポリシーと全体的な戦略に統合する必要があります。このような戦略には、クラウドベースのセキュリティー・ソフトウェア・ツールとともにセキュリティーのベスト・プラクティスを含める必要があります。この総合的なアプローチは、コンテナ化されたアプリケーションとその基盤となるインフラストラクチャーをコンテナのライフサイクル全体を通じて保護するように設計する必要があります。

セキュリティーのベスト・プラクティスには、複雑なネットワークのセキュリティーが常に社内外の脅威にさらされていると想定するゼロトラスト戦略が含まれます。さらに、コンテナにはDevSecOpsアプローチが必要です。DevSecOpsは、初期設計から統合やテスト、提供、導入まで、ソフトウェア開発ライフサイクルのあらゆる段階でセキュリティー・プラクティスの統合を自動化するアプリケーション開発手法です。

組織はまた、リスク軽減のために、適切なコンテナ・セキュリティー・ツールを活用する必要があります。自動化されたセキュリティー・ソリューションには、構成管理やアクセス制御、マルウェアやサイバー攻撃のスキャン、ネットワーク・セグメンテーション、監視などが含まれます。

さらに、コンテナ化されたワークロードがGDPRやHIPAAなどのコンプライアンスおよび規制基準に準拠するよう徹底するためのソフトウェア・ツールも利用できます。