コンテナ化
黒と青の背景
コンテナ化とは

コンテナ化テクノロジーの歴史、このテクノロジーを活用する利点、さらにこのテクノロジーと仮想化との関係についてご説明します。

コンテナ化 とは、 オペレーティングシステム (OS)  ライブラリと、コンテナと呼ばれる (任意のインフラストラクチャで一貫して実行される) 単一の軽量実行可能ファイルを作成するためのコードを実行するために必要な 依存関係 のみを含むソフトウェアコードのパッケージ化です。  仮想マシン (VM)  よりも ポータブル でリソース効率の高いコンテナーは、 最新 のクラウドネイティブアプリケーション の事実上のコンピューティングユニットになっています。

コンテナ化の導入により、開発者はアプリケーションをより迅速かつ安全に作成およびデプロイできます。 従来の手法では、コードは特定のコンピューティング環境で開発されます。そのため、このコードを新しい場所に移して実行すると、バグやエラーが発生することがよくあります。 例えば、開発者がデスクトップ・コンピューターから仮想マシン (VM) へ、あるいはLinuxからWindowsオペレーティング・システムへコードを移した場合などです。 コンテナ化を活用すると、アプリケーション・コードを関連する構成ファイル、ライブラリー、さらには実行に必要な依存関係とバンドルすることで、この問題を解消できます。 この単一のソフトウェア・パッケージ、つまり「コンテナ」は、ホスト・オペレーティング・システムから分離された結果、単独で動作し、移植できるようになり、任意のプラットフォームまたはクラウド上で問題なく稼働します。

コンテナ化 と プロセスの分離 の概念は数十年にわたって存在してきましたが、2013年にシンプルな開発者ツールと普遍的なパッケージ化手法を提供するコンテナの業界標準である、 オープンソース の Docker  Engine が登場すると、このテクノロジーは加速的に受け入れられるようになりました。  今日、組織はコンテナ化をますます使用して、新しいアプリケーションを作成し、クラウド用の既存のアプリケーションを最新化しています。 最近のIBMの調査  (PDF、1.4 MB) では、コンテナー採用者の61%が、過去2年間に構築した新しいアプリケーションの50%以上でコンテナーを使用していると報告しています。採用者の64%は、既存のアプリケーションの50%以上が今後2年間でコンテナに入れられると予想していました。

コンテナは「軽量」と呼ばれることが多く、マシンのオペレーティングシステムカーネルを共有し、各アプリケーション内でオペレーティングシステムを関連付けるオーバーヘッドを必要としないことを意味します。 コンテナは本質的にVMよりも容量が小さく、始動にかかる時間も短いため、1つのVMを実行するのに必要な計算能力ではるかに多くのコンテナを実行できます。 これにより、サーバーの効率性を向上させ、サーバーやライセンス交付にかかるコストを削減できます。

おそらく最も重要なのは、コンテナ化により、アプリケーションを「一度作成すればどこでも実行できる」ことです。 この移植性により、 開発がスピードアップし、クラウドベンダーのロックインが防止され、障害の分離、管理の容易さ、セキュリティの簡素化など、その他の注目すべき利点が提供されます (以下を参照)。

概要の詳細については、このビデオ「コンテナ化の説明」を参照してください。

エンタープライズ内のコンテナ - 新しい IBM リサーチ・ドキュメント、波のように押し寄せるコンテナの勢い、Kubernetes の採用

ebook を読む (PDF、1.4 MB)


アプリケーションのコンテナ化

コンテナは、アプリケーション・コードを関連する構成ファイル、ライブラリー、実行に必要な依存関係すべてとともにバンドルした単一の実行可能ソフトウェア・パッケージとして、アプリケーションをカプセル化します。 コンテナ化されたアプリケーションは、オペレーティング・ システムのコピーをバンドルしていないという点で「分離」されていると言えます。 その代わりに、ホストのオペレーティング・システムには、オープンソース・ランタイム・エンジン(Dockerランタイム・エンジンなど)がインストールされます。 このエンジンは、コンテナが同じコンピューター・システム上の他のコンテナとオペレーティング・システムを共有するための基盤の役割を果たします。

他のコンテナ層 (共通のバイナリーやライブラリーなど) も、複数のコンテナ間で共有できます。 これにより、各アプリケーション内でオペレーティング・システムを実行するためのオーバーヘッドが不要となり、コンテナの容量の縮小、および始動までの時間の短縮が可能となるため、 サーバーの効率性向上につながります。 アプリケーションをコンテナとして分離することで、1つのコンテナに存在する悪意のあるコードが他のコンテナに影響を与えたり、ホストシステムに侵入したりする可能性も低くなります。

ホスト・オペレーティング・システムから分離することにより、コンテナ化されたアプリケーションは移植可能になり、任意のプラットフォームまたはクラウド上で一様にかつ一貫して実行できます。 コンテナは、デスクトップコンピューターから仮想マシン (VM) に、またはLinuxからWindowsオペレーティングシステムに簡単に転送でき、仮想化インフラストラクチャまたは従来の「ベアメタル」サーバー(クラウド内の オンプレミス)で一貫して実行されます。 そのため、ソフトウェア開発者は自分が最も使いやすいツールやプロセスを引き続き使用できます。

企業がアプリケーションの開発と管理に対する優れた手法としてコンテナ化を急速に導入しているのには、しかるべき理由があります。 コンテナ化によって、アプリケーションが従来型のモノリス(単一層のソフトウェア・アプリケーション)であるか、モジュラー・マイクロサービス (疎結合サービスの集合) であるかにかかわらず、開発者はアプリケーションの作成とデプロイをより迅速かつ安全に行うことができます。 また、クラウド・ベースの新しいアプリケーションを、コンテナ化されたマイクロサービスとして新たに構築して、複雑なアプリケーションを、それぞれが特定の目的に特化した、管理しやすい一連の小さなサービスに分割できます。 さらに、既存のアプリケーションを、計算リソースをより効率的に使用するコンテナ (またはコンテナ化されたマイクロサービス) に再パッケージすることもできます。

クラウドと従来の IT の最高の機能を組み合わせる-コンテナーは、ベンダーロックインなしでどこからでもワークロードを構築および管理できるオープンハイブリッドクラウド戦略の鍵です。

詳細はこちら


メリットの詳細

コンテナ化は、開発者や開発チームに大きな利点を提供します。 以下にその一部を紹介します。

  • ポータビリティー: コンテナにより、ホスト・オペレーティング・システムから分離された(結び付けられたり、依存したりしない)実行可能ソフトウェア・パッケージが作成されます。この結果、コンテナは移植可能となり、任意のプラットフォームまたはクラウド上で一様にかつ一貫して稼働することができます。 
  • 俊敏性: コンテナを実行するためのオープンソースのDocker Engineによって、シンプルな開発者ツールと、LinuxとWindowsの両方のオペレーティング・システムで動作する普遍的なパッケージ化手法を提供するコンテナの業界標準が導入されました。 コンテナのエコシステムは、 Open Container Initiative(OCI)によって管理されるエンジンに移行しました。 ソフトウェア開発者は、引き続きアジャイルまたはDevOpsのツールやプロセスを使用して、アプリケーションの迅速な開発と機能強化を図ることができます。
  • スピード: Cコンテナは、よく「軽量」であると言われます。これは、コンテナがマシンのオペレーティング・システム(OS)カーネルを共有するため、余分なオーバーヘッドで動きが取れなくなるということがないことを意味します。 これにより、サーバーの効率性を向上させることができるだけでなく、ブートすべきオペレーティング・システムがないために、サーバーとライセンス交付にかかるコストを削減できると同時に、始動にかかる時間を短縮することもできます。
  • 障害分離: コンテナ化されたアプリケーションはそれぞれ分離され、他のアプリケーションから独立して動作します。 コンテナの1つで障害が発生しても、他のコンテナの継続的な稼働に影響が及ぶことはありません。 開発チームは、他のコンテナにダウン時間を発生させることなく、1つのコンテナ内の技術的な問題を識別し、修正できます。 また、コンテナ・エンジンは、任意のOSセキュリティー分離技法(SELinuxアクセス制御など)を活用して、コンテナ内の障害を分離することができます。
  • 効率性: コンテナ化された環境で実行されるソフトウェアは、マシンのOSカーネルを共有します。また、1つのコンテナ内のアプリケーション層は複数のコンテナで共有できます。 そのため、コンテナは本質的にVMよりも容量が小さく、始動にかかる時間も短いため、1つのVMを実行するのに必要な計算能力ではるかに多くのコンテナを実行できます。 これにより、サーバーの効率性を向上させ、サーバーやライセンス交付にかかるコストを削減できます。
  • 簡単管理: コンテナーオーケストレーションプラットフォームは、コンテナー化されたワークロードとサービスのインストール、スケーリング、および管理を自動化します。 コンテナ・オーケストレーション・プラットフォームは、コンテナ化されたアプリケーションのスケーリング、アプリケーションの新規バージョンのロールアウト、さらにモニタリング、ロギング、デバッグなどの機能の提供を始めとする、各種の管理タスクを容易にします。 Kubernetesとは、おそらく最も人気のあるコンテナ・オーケストレーション・システムです。本来はLinuxのコンテナ機能を自動化するためのオープンソース・テクノロジーです (最初は、Borgと呼ばれるGoogle社の社内プロジェクトをベースにして、同社によってオープンソース化されました)。 Kubernetesは、Dockerなどの多くのコンテナ・エンジンと連携しますが、コンテナ・イメージのフォーマットやランタイムに関するOpen Container Initiative (OCI) 標準に準拠する、あらゆるコンテナ・システムとも連携します。
  • セキュリティ: アプリケーションをコンテナとして分離することで、悪意のあるコードの侵入が他のコンテナやホスト・システムに影響を及ぼすのを防ぐことができます。 さらに、セキュリティー権限を定義することで、不要なコンポーネントがコンテナに入るのをブロックしたり、不要なリソースとの通信を制限したりすることができます。
注目の製品

Red Hat OpenShift on IBM Cloud

IBM Cloud Satellite


コンテナ化の種類

コンテナ・ベースのソリューションに対する関心やその活用が急速に高まったことで、コンテナ・テクノロジーやソフトウェア・コードのパッケージ化手法に関する標準が必要となりました。 2015年6月にDocker社などの業界リーダーによって設立されたOpen Container Initiative(OCI)は、コンテナ・テクノロジーに関する一般的で、最小限のオープンな標準と仕様の作成を推進しています。 そのため、OCIはオープンソース・エンジンの選択肢の拡大を支援しています。 ユーザーは特定のベンダーのテクノロジーにロックインされるのではなく、OCIが認定するテクノロジーを活用し、多様なDevOpsツールを使用してコンテナ化されたアプリケーションを構築して、希望するインフラストラクチャー上で一貫して実行できるようになります。

現在、Dockerは最もよく知られ、広く使用されているコンテナ・エンジン・テクノロジーの1つですが、使用可能な選択肢は他にもあります。 エコシステムは、 機能やデフォルトは異なる場合がありますが、これらがOCIの仕様を採用・活用して進化していくことにより、ベンダーに依存せず、複数のオペレーティング・システムで稼働し、複数の環境で使用できるソリューションになります。


マイクロサービスとコンテナ化

今やさまざまな規模のソフトウェア会社が、従来のモノリシックなモデル(ソフトウェア・アプリケーションおよび関連するユーザー・インターフェースと基盤となるデータベースを、単一のサーバー・プラットフォーム上の単一ユニットに統合する)ではなく、マイクロサービスを優れたアプリケーション開発・管理手法として活用しています。 マイクロサービスでは、複雑なアプリケーションは、それぞれが独自のデータベースと独自のビジネス・ロジックを備えた、より小さく、より特化した一連のサービスに分割されます。 個々のマイクロサービスは、共通インターフェース(APIなど)およびRESTインターフェース(HTTPなど)を介して相互に通信します。 マイクロサービスを使用すると、開発チームはアプリケーション全体に影響を与えることなく、そのアプリケーションの特定の領域を更新して、開発、テスト、 およびデプロイのそれぞれのプロセスを迅速化できます。

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

さらに、マイクロサービスとコンテナ化を一緒に使用するとうまく連携します。 アプリケーションが従来のモノリス型であるか、モジュラー・マイクロサービスであるかにかかわらず、コンテナはすべてのアプリケーションの軽量のカプセル化を可能にします。 コンテナ内に作成されたマイクロサービスは、開発プロセスおよびベンダー互換性 (ベンダー・ロックインなし) における移植性に加えて、開発者の俊敏性、障害分離、サーバーの効率性、インストール/スケーリング/管理の自動化、セキュリティー層などの、コンテナ化固有の利点をすべて提供します。

今日の通信は、ユーザーが迅速かつ効率的にアプリケーションを開発できるクラウド・ベースへと急速に移行しています。 クラウド・ベースのアプリケーションとデータには、あらゆるインターネット接続デバイスからアクセスできるため、チーム・メンバーはリモートでも、移動中でも作業ができます。 基盤となるインフラストラクチャーはクラウド・サービス・プロバイダー(CSP)によって管理されるため、企業はサーバーやその他の機器にかかるコストを節減できるだけでなく、自動ネットワーク・バックアップ機能によってより高い信頼性を確保できます。 クラウド・インフラストラクチャーは、オンデマンドでスケーリングでき、ロード要件の変化に応じて、コンピューティング・リソース、容量、 およびインフラストラクチャーを動的に調整できます。 さらに、CSPは定期的にオファリングを更新して、ユーザーが最新の革新的なテクノロジーにアクセスできるようにします。

コンテナ、マイクロサービス、クラウドコンピューティングは連携して、アプリケーションの開発とデリバリーを、従来の方法や環境では不可能であった新たなレベルに導いています。 これらの次世代の手法は、ソフトウェア開発ライフサイクルに俊敏性、効率性、信頼性、さらにはセキュリティーをもたらします。その結果、アプリケーションや機能拡張をエンド・ユーザーや市場に迅速にデリバリーできるようになります。

マイクロサービスの詳細については、「マイクロサービスとは」をご覧ください。


高い安全性

コンテナ化されたアプリケーションは、分離されたプロセスとして実行でき、また他のコンテナから独立して作動できるため、本質的に一定レベルのセキュリティーを確保しています。 真の意味で分離されているため、悪意のあるコードが他のコンテナに影響を与えたり、ホスト・システムに侵入したりするのを防ぐことができます。 ただし、コンテナ内のアプリケーション層は、多くの場合、コンテナ間で共有されます。 リソースの効率性の観点から見るとこれは利点ですが、他方でコンテナ間での干渉やセキュリティー・ブリーチ(抜け穴)の発生につながります。 また、複数のコンテナを同じホスト・オペレーティング・システムに関連付けることができるため、共有オペレーティング・システムについても同じことが言えます。 共通のオペレーティング・システムに対するセキュリティーの脅威は、関連するすべてのコンテナに影響を及ぼす可能性があります。また逆に、コンテナ侵害がホスト・オペレーティング・システムにまで至る可能性もあります。

しかし、コンテナイメージ自体はどうですか? コンテナ内にパッケージされたアプリケーションやオープンソース・コンポーネントは、どのようにしてセキュリティーを向上させることができるのでしょうか。 Dockerなどのコンテナ・テクノロジー・プロバイダーは、引き続きコンテナのセキュリティー問題に積極的に対応しています。 セキュリティーはプラットフォームに本質的に備わっている必要があり、個別に実装および構成されたソリューションであってはならないという考えの下に、コンテナ化では、「デフォルトでの保護(Secure By Default)」の手法が採用されています。 この目的を達成するために、コンテナ・エンジンは、基盤となるオペレーティング・システムに固有のすべてのデフォルトの分離プロパティーをサポートします。 セキュリティー権限を定義することで、不要なコンポーネントがコンテナに入るのを自動的にブロックしたり、不要なリソースとの通信を制限したりすることができます。

例えば、Linux Namespaceは、各コンテナに対してシステムの分離されたビューを提供するのに役立ちます。これには、ネットワーキング、マウント・ポイント、プロセスID、ユーザーID、プロセス間通信、ホスト名設定が含まれます。 Namespaceを使用して、各コンテナ内のプロセスからこれらのリソースにアクセスすることを制限できます。 通常、 管理者は、シンプルなユーザー・インターフェースを使用して、各コンテナ化されたアプリケーションに対し、このような「分離制約」を容易に作成し、管理できます。

研究者は、Linuxコンテナのセキュリティーのさらなる強化に取り組んでいます。幅広いセキュリティー・ソリューションを利用して、企業全体で脅威の検知と対処を自動化したり、業界標準やセキュリティー・ポリシーを遵守するためにコンプライアンスをモニターおよび適用したり、アプリケーションやエンドポイントでの安全なデータ・フローを確保したりできます。

あらゆる規模の組織間でコンテナセキュリティを拡張するための戦略について学ぶ


仮想化とコンテナ化

コンテナはしばしば仮想マシン (VM) と比較されます。これは、どちらのテクノロジーも、単一の環境で複数のタイプのソフトウェア(LinuxやWindowsベース)を実行できるようにして、有意な計算効率を実現するためです。 しかし、コンテナ・テクノロジーが仮想化に勝る重要な利点を提供することが分かってきたため、コンテナ・テクノロジーは急速にITの専門家に支持されるテクノロジーとなりつつあります。

仮想化テクノロジーでは、複数のオペレーティング・システムとソフトウェア・アプリケーションが同時に稼働して、単一の物理コンピューターのリソースを共有できます。 例えば、IT部門では、WindowsとLinuxの両方を、 あるいは1つのオペレーティング・システムの複数のバージョンを、同じサーバー上で複数のアプリケーションとともに実行できます。 それぞれのアプリケーションとその関連ファイル、ライブラリー、 依存関係 (オペレーティング・システム(OS)のコピーを含む) は、VMとしてまとめてパッケージ化されます。 複数のVMが1つの物理マシン上で稼働するため、資本、運用、エネルギーのコストを大幅に削減できる可能性があります。

仮想化の概要については、「2019年の仮想化」ビデオと「仮想化:完全ガイド」をご覧ください。

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

先に述べたように、コンテナはよく「軽量」であると言われます。これは、コンテナがマシンのOSカーネルを共有し、(VMの場合とは異なり) 各アプリケーション内でOSを関連付けるためのオーバーヘッドを必要としないからです。 他のコンテナ層(共通のバイナリーやライブラリーなど)も複数のコンテナ間で共有して、コンテナの容量をVMよりも小さくし、始動にかかる時間もより短くできます。 1つのVMを実行するのに必要な計算能力で複数のコンテナを実行できるため、サーバーの効率性を向上させ、サーバーやライセンス交付にかかるコストをさらに削減できます。


コンテナ化とIBMクラウド

簡単に述べると、仮想化では、1つのアプリケーションにサーバー全体を提供する必要がありません。 また、コンテナ化では、1つのアプリケーションにOS全体を提供する必要がありません。 コンテナ化テクノロジー使用の利点には、移植性、俊敏性、障害分離、管理の容易さ、セキュリティーなどがあります。

エンタープライズコンテナプラットフォームは、複数のパブリッククラウドとプライベートクラウドにおいてオーケストレーションを提供し、環境を統合してビジネスパフォーマンスと運用パフォーマンスを向上させます。 これは、ベンダーロックインを回避し、一貫性のある場所でワークロードを構築および実行し、すべてのITを最適化および最新化できる、オープンハイブリッドクラウド戦略の重要なコンポーネントです。

次のステップに進みます:

IBM Cloudアカウントで今すぐ始めましょう。


関連ソリューション

ITの最適化とモダナイズ

オープンなハイブリッドクラウド戦略を採用すると、ベンダーの囲い込みなしにあらゆる場所でワークロードを構築して管理できます。


Red Hat OpenShift on IBM Cloud

Red Hat OpenShift on IBM Cloudは、パブリック環境やハイブリッド環境でOpenShiftを活用して、俊敏性、市場への即応性、拡張性、信頼性の向上を図ります。


IBM Cloud Satellite

IBM Cloud Satelliteでは、オンプレミス、エッジ、パブリッククラウドなどのあらゆる環境で、一貫したクラウド・サービスを利用できます。


ハイブリッドクラウド・ストレージのソリューション

ハイブリッドクラウド・ストレージを使ってコンテナ対応のエンタープライズ・ストレージをオンプレミスとクラウド・ストレージ環境全体に簡単かつシームレスに導入します。


クラウド・サービス

複雑なハイブリッドIT管理を簡素化して、可視性、管理の容易性、柔軟性を向上させます。