コンテナは、アプリケーション・コードがそのライブラリーおよび依存関係とともに、一般的な方法でパッケージ化されたソフトウェアの実行可能ユニットであり、デスクトップ、従来のIT、クラウドなど、どこでも実行できるようになっています。
これを実現するために、コンテナはオペレーティング・システム(OS)仮想化(Linuxネームスペースとcgroups、Windowsサイロおよびジョブ・オブジェクトなど)の機能を利用してプロセスを分離し、それらのプロセスがアクセスできるCPU、メモリー、ディスクの量を管理します。
コンテナは、仮想マシンとは異なり、個々のインスタンスにゲストOSを含める必要がなく、代わりにホストOSの機能とリソースを利用できるため、小さく、高速で、移植可能です。
コンテナは、FreeBSD JailsやAIX Workload Partitionsなどのバージョンで何十年も前に初登場したものですが、大部分の現代の開発者は、2013年を Dockerが導入された現代のコンテナ時代の始まりとして認識しています。
コンテナをよりよく理解する1つの方法は 、コンテナが従来の 仮想マシン(VM)と、どのように異なるかを理解することです。 従来の 仮想化(オンプレミスであれクラウド内であれ)では、物理ハードウェアを仮想化するのに ハイパーバイザー が活用されています。 このため各VMには、ゲストOS、OSの実行に必要なハードウェアの仮想コピー、アプリケーションとそれに関連するライブラリーや依存関係が含まれています。
基盤となるハードウェアを仮想化する代わりに、コンテナはオペレーティング・システム(通常はLinux)を仮想化するので、個々のコンテナにはアプリケーションとそのライブラリーおよび依存関係 のみ が含まれます。 コンテナが非常に軽量であり、高速で移植性が高い理由は、ゲストOSが存在しない点にあります。
この比較の詳細については、「コンテナとVM:違いは何ですか?(Containers vs. VMs: What's the difference?)」(英語)をご参照ください。
特にVMと比較した場合のコンテナの主な利点は、コンテナを軽量でポータブルにする抽象化のレベルを提供している点です。 コンテナの主要なメリットには次のようなものがあります。
軽量: コンテナはマシンのOSカーネルを共有するため、アプリケーションごとの完全なOSインスタンスが不要になり、コンテナ・ファイルが小さくてリソースを節約できます。 サイズが、特に仮想マシンと比較して小さいため、コンテナは素早くスピンアップでき、水平方向に拡張できる クラウドネイティブ のアプリケーションをより適切にサポートできます。
ポータブルでプラットフォームに依存しない: コンテナはそのすべての依存関係を保持します。つまり、ソフトウェアを一度作成した後は、ラップトップ、クラウド、およびオンプレミスのコンピューティング環境全体で再構成せずに実行できます。
最新の開発とアーキテクチャーをサポート: プラットフォーム間でのデプロイメントの移植性/一貫性とサイズの小ささの組み合わせにより、コンテナは、 DevOps、 サーバーレス 、 マイクロサービス(小さな増分で定期的なコード展開で構築されるもの)などの最新の開発とアプリケーション・パターンに最適です。
使用率の向上: 以前のVMと同様に、コンテナを使用すると、開発者とオペレーターは物理マシンのCPUとメモリの使用率を向上させることができます。 コンテナはさらに進んで、マイクロサービス・アーキテクチャーも可能にするため、アプリケーション・コンポーネントはよりきめ細かく展開し、拡張縮小することができます。これは、単一のコンポーネントで負荷による困難が生じ、モノリシック・アプリケーション全体を拡大する必要がある場合に魅力的な代替手段です。
最近のIBMの調査(PDF、1.4 MB)で、開発者とIT業界のエグゼクティブは、コンテナの使用について他にも多くのメリットを報告しました。
レポート全体をダウンロード :企業におけるコンテナ(PDF、1.4 MB)
コンテナは、特にクラウド環境でますます目立つようになっています。 多くの組織は、まさにアプリケーションとワークロードの汎用コンピューティング・プラットフォームとして、VMの代わりとしてコンテナを検討しています。 しかし、その非常に広い範囲の中で、コンテナが特に関連する重要なユース・ケースがあります。
コンテナを利用するには、ソフトウェアを別の方法で設計しパッケージ化する必要があります。一般的に コンテナ化と呼ばれるプロセスのことです。
アプリケーションをコンテナ化する場合、そのプロセスには、関連する環境変数、構成ファイル、ライブラリー、ソフトウェアの依存関係でアプリケーションをパッケージ化することが含まれます。 その結果、コンテナ・プラットフォームで実行できるコンテナ・イメージが作成されます。
Kubernetesによるコンテナ・オーケストレーション
企業がコンテナを採用し始めると(多くの場合、最新のクラウドネイティブ・アーキテクチャーの一部として)、個々のコンテナの単純さは、分散システム全体で数百(場合によっては数千)のコンテナを管理することの複雑さと衝突し始めることになりました。
この課題に対処するために、 コンテナ・オーケストレーション が、ライフサイクル全体にわたって多数のコンテナを管理する方法として台頭しました。次のような要素が含まれます。
数多くのコンテナ・オーケストレーション用プラットフォーム(Apache Mesos、Nomad、Docker Swarmなど)が作成されましたが、2014年にGoogleによって導入されたオープンソース・プロジェクト、 Kubernetesが、 すぐに最も人気のあるコンテナ・オーケストレーション・プラットフォームになりました。業界の大多数がこのプラットフォームで標準化しました。
Kubernetesを使用することにより、開発者とオペレーターは YAMLファイルを介してコンテナ環境全体の望ましい状態を宣言できます。その後、Kubernetesは、所定 の アプリケーションやワークロード の 指定数のインスタンスをデプロイする、アプリケーションが失敗した場合は再起動する、ロード・バランシングする、自動スケーリングする、ダウンタイム・ゼロでデプロイする 等のアクティビティーを使って、あらゆるハードワークを行い、宣言の状態を確立し、保持します。
Kubernetesは現在、Linux Foundationの支援を受けたベンダーに依存しない業界グループ、Cloud Native Computing Foundation(CNCF)によって運営されています。
以下の動画では、Kubernetesの仕組みの概要についてご説明します。
アプリケーションをパッケージ化して実行するための一般的な方法としてコンテナが勢いを増し続けるにつれ、実動のユース・ケースを強化し、拡張するように設計されたツールとプロジェクトのエコシステムは成長し続けます。 Kubernetes以外で、コンテナ・エコシステムで最も人気のあるプロジェクトは、IstioとKnativeの2つです。
Istio
開発者がコンテナを活用してマイクロサービス・アーキテクチャーを構築して実行するにつれて、管理上の懸念は、個々のコンテナのライフサイクルの考慮事項を超え、多数の小さなサービス(多くの場合「サービス・メッシュ」と呼ばれる)が相互に接続し関連する方法にまでおよびます。 Istioは、開発者が検出、トラフィック、監視、セキュリティーなどに関連する課題をより簡単に管理できるようにするために作成されました。
Knative
サーバーレス・アーキテクチャーも、特にクラウドネイティブ・コミュニティー内で人気がさらに高まっています。 例えばKnativeは、コンテナ化されたサービスを サーバーレス関数としてデプロイできるという大きな価値を提供します。
サーバーレス関数は、サーバーのように常に稼働して必要なときに応答するのではなく、「ゼロにスケーリング」できます。つまり、呼び出されない限り、まったく実行されません。 このモデルを数万のコンテナに適用すると、コンピューティング能力を大幅に節約できます。
以下の動画では、Knativeについて詳しくご説明します。
Red Hat OpenShift on IBM Cloudは、パブリック環境やハイブリッド環境でOpenShiftを活用して、俊敏性、市場への即応性、拡張性、信頼性の向上を図ります。
IBM Cloud Satelliteでは、オンプレミス、エッジ、パブリッククラウドなどのあらゆる環境で、一貫したクラウド・サービスをご利用いただけます。
コンテナ・イメージ、バッチ・ジョブ、またはソースコードをサーバーレス・ワークロードとして実行します。サイジング、デプロイ、ネットワーキング、スケーリングは不要です。
IBM Cloud Container Registryは、イメージを管理し、安全上の問題を監視できる専用レジストリーを提供します。