コンテナとは

コンテナは、オペレーティングシステム（OS）仮想化の形式を利用します。この仮想化では、OSカーネルの機能（Linux名前空間とcgroup、Windowsサイロとジョブオブジェクトなど）を使用してプロセスを分離し、それらのプロセスがアクセスできるCPU、メモリ、およびディスクの量を制御できます。

コンテナは、 仮想マシン （VM）よりも移植性とリソース効率が高いため、 最新のクラウドネイティブ・アプリケーションの 事実上の 標準的な コンピューティング・ユニット となっています。さらに、コンテナは、ハイブリッド・ マルチクラウドが設定する基盤となるITインフラストラクチャー（オンプレミス、 プライベートクラウド、 パブリッククラウド や、複数のクラウド・ベンダーによる複数のクラウド・サービスなどの組み合わせ）にとって重要です。

Business  Research Insight¹のレポートによると、世界のコンテナ技術市場は2021年に4億9,640万米ドルと評価され、2031年までに31億2,342万米ドルに達すると予想されており、年平均成長率（CAGR）は19.8%です。

コンテナについて理解を深める1つの方法は、 物理コンピューターの仮想表現またはエミュレーションである 従来の仮想マシン（VM）との違いを調べることです。VMはゲストと呼ばれることが多く、VMが実行される物理マシンはホストと呼ばれます。

仮想化技術がVMを可能にしています。ハイパーバイザー（小さなソフトウェア層）が、各VMに物理的なコンピューティング・リソース（プロセッサー、メモリ、ストレージなど）を割り当てます。これにより、各VMが他のVMから分離され、相互に干渉しなくなります。ここでの各VMには、ゲストOS、OSの実行に必要なハードウェアの仮想コピー、アプリケーション、関連するライブラリと依存関係が含まれます。VMware社は、ハイパーバイザーに基づく仮想化技術を開発し、商品化した最初の企業の1つです。

コンテナ技術では、基盤となるハードウェアを仮想化する代わりに、オペレーティング・システム（通常はLinux）を仮想化し、各コンテナにはアプリケーションとそのライブラリ、設定ファイル、依存 関係のみが 含まれるようにしています。ゲストOSがないため、コンテナはVMより軽量、高速でポータブルです。

コンテナと仮想マシンは相互に排他的ではありません。例えば、組織は、VMでコンテナを実行して分離とセキュリティーを強化し、自動化、バックアップ、監視のために既にインストールされているツールを活用することで、両方の技術を活用できます。

この比較の詳細については、「コンテナvs VM： その違いとは」をご覧ください。動画を見る：

コンテナの主なメリットは、特にVMと比較して、軽量でポータブルな抽象化レベルを提供できることです。主なメリットは次のとおりです。

IBMの調査では、開発者とIT幹部がコンテナを使用したことによるその他の多くのメリットを報告しています。レポート全文をご覧ください： 「 企業におけるコンテナ」

コンテナは、 コンテナ化、 つまりオペレーティング・システム（OS） とその関連する環境変数、構成ファイル、ライブラリ、ソフトウェア依存関係のみを含むソフトウェア・コードのパッケージ化に依存しています。

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

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

コンテナ化と プロセスの分離は 何十年も前から存在していました²。 コンテナ開発の歴史的な瞬間は、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は、 Platform-as-a-Service（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は、コンテナベースのワークロードの実行に世界で最も広く使用されるコンテナ・オーケストレーション・ツールになりました。CNCFレポート⁹では、Kubernetesは、世界で2番目に大きなオープンソース・プロジェクト（首位はLinux）で、Fortune誌が選ぶ世界の上位企業100社の実に71％により主要コンテナ・オーケストレーション・ツールとして選ばれています。

CaaS（Containers-as-a-Service）とは、開発者がコンテナ化されたアプリケーションを管理・導入できるようにする クラウド・コンピューティング ・サービスで、これにより、あらゆる規模の企業がポータブルでスケーラブルなクラウド・ソリューションにアクセスできるようになります。

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

 Infrastructure-as-a-Service（IaaS）、Platform-as-a-Service（PaaS）、Software-as-a-Service（SaaS）と同様に、 CaaSはクラウド・サービス・プロバイダー（AWS、Google Cloud Services、IBM Cloud 、Microsoft Azure など）から従量課金制の料金体系モデルを通じて提供されており、ユーザーは使用したサービスのみに対して料金を支払います。 

組織は、コンテナを使って以下に対応できます。

Kubernetes以外にも、コンテナ・エコシステムで最も人気のある2プロジェクトが、IstioとKnativeです。

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

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

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

コンテナはハイブリッドクラウド環境全体でのソフトウェア開発と導入において重要な役割を果たしているため、組織はコンテナ化されたワークロードが社内外のセキュリティー脅威に対して安全であることを確認する必要があります。

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

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

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

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

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