JP6826586B2 - 従属性に基づくコンテナ・デプロイメント方法、システム、およびプログラム - Google Patents

Description

本発明は、一般に、仮想機械に関し、より詳細には、コンテナ・デプロイメントのための方法、デバイスおよびコンピュータプログラムに関する。

仮想機械（ＶＭ）は、仮想化を創出するために広く使用されている。ＶＭは、コンピュータアーキテクチャ、及び、現実の又は仮想のコンピュータの機能に基づいて動作する。ＶＭは、物理機械の様にプログラムを実行する機械のソフトウェア実装である。単一の物理機械は、その上で実行される多数のＶＭをサポートすることができ、これらＶＭを「ハイパバイザ」と呼ばれるプログラムを使用して管理することができる。伝統的なＶＭアーキテクチャは、各ＶＭにゲストオペレーティングシステム（ＯＳ）をデプロイしなければならないので、リソースの浪費を生じさせる。

コンテナは、プロセス及び／又はリソースを隔離することを可能にする軽量な仮想化を、完全仮想化の命令翻訳機構及び／又はその他の複雑さをもたらすことを必要とせずに提供する。Ｌｉｎｕｘ Ｃｏｎｔａｉｎｅｒ（ＬＸＣ）などのコンテナ技術は、プロセス及びリソースを隔離することを可能にする軽量な仮想化を、完全仮想化の命令翻訳機構及びその他の複雑さをもたらすことを必要とせずに提供する。コンテナは、単一のホストオペレーティングシステム（ＯＳ）によって管理されるリソースを効果的に分割して隔離されたグループとし、これら隔離されたグループ間でリソース使用率に対する競合する要求をうまく均衡させる。すなわち、コンテナ技術は、共通ＯＳ及び場合によってはいくつかの適切なバイナリファイル又はライブラリの共有を可能にする。

Ｄｏｃｋｅｒは、オープンソースプロジェクトであり、これはＬｉｎｕｘ上でオペレーティングシステムレベル仮想化の抽象化及び自動化の追加レイヤを提供することによって、ソフトウェアコンテナの内部でのアプリケーションのデプロイメントを自動化する。（注：「Ｄｏｃｋｅｒ」及び「Ｌｉｎｕｘ」という用語は、世界中の様々な管轄権において商標権の対象である場合があり、本明細書においては、このような商標権が存在し得る範囲で標章によって適正に称される製品又はサービスに対して言及する場合にのみ使用される。）Ｄｏｃｋｅｒは、ｃｇｒｏｕｐ及びカーネル名前空間などのＬｉｎｕｘカーネルのリソース隔離特徴を使用して、独立した「コンテナ」が単一のＬｉｎｕｘインスタンス内で動作することを可能にし、仮想機械の起動及び維持のオーバヘッドを回避する。

本発明の目的は、コンテナ・デプロイメントのための方法、デバイスおよびコンピュータプログラムを提供することである。

一般に、本発明の例示的な実施形態は、コンテナ・デプロイメントのための方法、デバイスおよびコンピュータプログラムを含む。

一態様において、コンピュータ実装方法が提供される。上記方法によれば、第１の情報及び第２の情報が得られる。第１の情報は、デプロイされるターゲットコンテナによって必要とされるターゲットライブラリを示し、第２の情報は、複数の候補ホスト上にデプロイされた少なくとも１つのコンテナについてロード済みのライブラリを示す。次いで、ターゲットコンテナを複数の候補ホスト上にデプロイするコストが、第１の情報及び第２の情報に基づいて判定される。ターゲットホストは、判定されたコストに基づいて複数の候補ホストの中から選択され、選択されたターゲットホスト上にターゲットコンテナがデプロイされるようになっている。

別の態様において、デバイスが提供される。デバイスは、処理ユニットと、処理ユニットに結合された、命令を格納するメモリとを含む。上記命令は、処理ユニットによって実行されたときに、以下の動作、すなわち、デプロイされるターゲットコンテナによって必要とされるターゲットライブラリのセットを示す第１の情報を得ることと、複数の候補ホスト上にデプロイされた少なくとも１つのコンテナについてロード済みのライブラリのセットを示す第２の情報を得ることと、第１の情報及び前記第２の情報に基づいて、ターゲットコンテナを複数の候補ホスト上にデプロイするコストを判定することと、ターゲットコンテナをデプロイするための判定されたコストに基づいて、複数の候補ホストの中からターゲットホストを選択することと、を行う。

さらに別の態様において、コンピュータプログラム製品が提供される。コンピュータプログラム製品は、非一時的な機械可読媒体上に有形に格納され、機械実行可能命令を含む。上記命令は、デバイス上で実行されたときに、該デバイスに、デプロイされるターゲットコンテナによって必要とされるターゲットライブラリのセットを示す第１の情報を得させ、複数の候補ホスト上にデプロイされた少なくとも１つのコンテナについてロード済みのライブラリのセットを示す第２の情報を得させ、第１の情報及び第２の情報に基づいて、ターゲットコンテナを複数の候補ホスト上にデプロイするコストを判定させ、ターゲットコンテナをデプロイするための判定されたコストに基づいて、複数の候補ホストの中からターゲットホストを選択させる。

本概要は、本発明の実施形態の重要な又は必須の特徴を識別することを意図したものでもなく、本発明の範囲を限定することを意図したものでもないことを理解されたい。本発明の他の特徴は、以下の説明を通じて容易に理解できるであろう。

添付図面中の本開示のいくつかの実施形態のより詳細な説明を通じて、本開示の上記及び他の目的、特徴及び利点は、より明らかになるであろう。

図面全体を通じて、同じ又は類似の符号は、同じ又は類似の要素を表す。

本発明の実施形態を実装することができる電子デバイスのブロック図である。 本発明の実施形態によるコンテナ・デプロイメントに基づくテンプレートの模式図である。 本発明の実施形態を実装することができる環境のブロック図である。 本発明の実施形態によるコンテナ・デプロイメントのための方法のフローチャートである。 本発明の実施形態によるｄｏｃｋｅｒｆｉｌｅの一例のスクリーンショット、およびターゲットコンテナをデプロイするコストを判定するフローチャートである。 本発明によるコンテナ・デプロイメントのためのシステムのブロック図である。 本発明によるコンテナ／イメージ情報として機能するファイルのスクリーンショットである。

本発明の原理を、ここでいくつかの実施形態を参照して説明する。これらの実施形態は、単に例示の目的で説明され、当業者が本発明を理解すること及び実施することを補助するものであり、本発明の範囲に関するいかなる限定も示唆しないことを理解されたい。本明細書で説明する発明は、以下で説明する以外の種々のやり方で実施することができる。

本明細書で使用する場合、「含む」という用語は、「含むが、それらに限定されない」を意味する、オープンな用語として解釈すべきである。「基づく」という用語は、「少なくとも部分的に基づく」と解釈すべきである。「１つの実施形態」及び「実施形態」という用語は、「少なくとも１つの実施形態」と解釈すべきである。「別の実施形態」という用語は、「少なくとも１つの他の実施形態」と解釈すべきである。他の定義は、明示的及び暗黙的に、下記に含まれ得る。

最初に、本発明の実施形態を実施するのに適用可能な例示的な電子デバイス又はコンピュータシステム／サーバ１２が示された図１を参照する。コンピュータシステム／サーバ１２は、単なる例示であり、本明細書で説明する本発明の実施形態の使用又は機能の範囲に関していかなる限定を示唆することも意図しない。

図１に示すように、コンピュータシステム／サーバ１２は、汎用コンピュータデバイスの形態で示される。コンピュータシステム／サーバ１２のコンポーネントは、１つ又は複数のプロセッサ又は処理ユニット１６と、システムメモリ２８と、システムメモリ２８を含む種々のシステムコンポーネントをプロセッサ１６に結合するバス１８とを含むことができるが、これらに限定されない。

バス１８は、任意の多様なバスアーキテクチャを使用した、メモリバス又はメモリコントローラ、周辺バス、アクセラレーテッドグラフィックスポート、及びプロセッサ又はローカルバスを含む、いくつかのタイプのバス構造のいずれかのうちの１つ又は複数を表す。限定ではなく例として、このようなアーキテクチャは、インダストリー・スタンダード・アーキテクチャ（ＩＳＡ）バス、マイクロ・チャネル・アーキテクチャ（ＭＣＡ）バス、エンハンストＩＳＡ（ＥＩＳＡ）バス、ビデオ・エレクトロニクス・スタンダーズ・アソシエーション（ＶＥＳＡ）ローカルバス、及びペリフェラル・コンポーネント・インターコネクト（ＰＣＩ）バスを含む。

コンピュータシステム／サーバ１２は、典型的には、多様なコンピュータシステム可読媒体を含む。このような媒体は、コンピュータシステム／サーバ１２によってアクセス可能な任意の使用可能な媒体とすることができ、これは揮発性及び不揮発性媒体、取外し可能及び取外し不能媒体の両方を含む。

このようなメモリ２８は、ランダムアクセスメモリ（ＲＡＭ）３０及び／又はキャッシュメモリ３２などの、揮発性メモリの形態のコンピュータシステム可読媒体を含むことができる。コンピュータシステム／サーバ１２は、他の取外し可能／取外し不能、揮発性／不揮発性コンピュータシステムストレージ媒体をさらに含むことができる。単なる例示として、取外し不能な不揮発性磁気媒体（図示せず、典型的には「ハードドライブ」と称される）の読出し及び書込みのためにストレージシステム３４を設けることができる。図示されていないが、取出し可能な不揮発性磁気ディスク（例えば「フロッピーディスク」）の読出し及び書込みのための磁気ディスクドライブ、及び、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ又は他の光学媒体などの取出し可能な不揮発性光ディスクの読出し又は書込みのための光ディスクドライブを設けることができる。このような事例において、各々は、１つ又は複数の媒体インタフェースによってバス１８に接続することができる。さらに下記で示され説明されるように、メモリ２８は、本発明の実施形態の機能を実行するように構成されたプログラムモジュールのセット（例えば少なくとも１つ）を有する、少なくとも１つのプログラム製品を含むことができる。

プログラムモジュール４２のセット（少なくとも１つ）を有するプログラム／ユーティリティ４０は、限定ではなく例として、メモリ２８内に、オペレーティングシステム、１つ又は複数のアプリケーションプログラム、他のプログラムモジュール、及びプログラムデータと同様に、格納されることができる。オペレーティングシステム、１つ又は複数のアプリケーションプログラム、他のプログラムモジュール、及びプログラムデータ又はそれらのいくつかの組合せの各々は、ネットワーク環境の実装を含むことができる。プログラムモジュール４２は、一般に、本明細書で説明される本発明の実施形態の機能及び／又は方法論を実行する。

コンピュータシステム／サーバ１２は、キーボード、ポインティングデバイス、ディスプレイ２４などのような１つ又は複数の外部デバイス１４と通信することもできる。ユーザがコンピュータシステム／サーバ１２と相互作用することを可能にする１つ又は複数のデバイス、及び／又は、コンピュータシステム／サーバ１２が１つ又は複数の他のコンピューティングデバイスと通信することを可能にする任意のデバイス（例えば、ネットワークカード、モデム等）。このような通信は、入力／出力（Ｉ／Ｏ）インタフェース２２を介して行うことができる。さらにまた、コンピュータシステム／サーバ１２は、ネットワークアダプタ２０を介して、ローカルエリアネットワーク（ＬＡＮ）、汎用広域ネットワーク（ＷＡＮ）及び／又は公衆ネットワーク（例えばインターネット）などの、１つ又は複数のネットワークと通信することができる。図示したように、ネットワークアダプタ２０は、バス１８を介して、コンピュータシステム／サーバ１２の他のコンポーネントと通信する。図示していないが、他のハードウェア及び／又はソフトウェアコンポーネントをコンピュータシステム／サーバ１２と共に使用することができることを理解されたい。例として、マイクロコード、デバイスドライバ、冗長処理ユニット、外部ディスクドライブアレイ、ＲＡＩＤシステム、テープドライブ、及びデータアーカイブ・ストレージシステムなどが挙げられるがそれらに限定されない。

コンピュータシステム／サーバ１２において、Ｉ／Ｏインタフェース２２は、コンピュータシステム／サーバ１２へ入力を提供するために使用することができる種々の異なる入力デバイスの１つ又は複数をサポートし得る。例えば、入力デバイスは、キーボード、キーパッド、タッチパッド、トラックボールなどのユーザデバイスを含み得る。入力デバイスは、音声認識、タッチ及びスタイラス認識、入力デバイスに接触した及び入力デバイス近傍のジェスチャの認識、エアジェスチャの認識、頭部及び視線の追跡、音声（ｖｏｉｃｅ）及び音声（ｓｐｅｅｃｈ）認識、ユーザの脳の活動の検知、及び人工知能などの、１つ又は複数のナチュラル・ユーザインタフェース技術を実装することができる。

従属性に基づくコンテナ・デプロイメントのいくつかの例示的な実施形態を以下の段落において説明する。本発明の実施形態によれば、新たなコンテナをデプロイするとき、その新たなコンテナによって必要とされるライブラリと候補ホストにロード済みのライブラリとの従属性を考慮に入れる。一般的に言って、新たなコンテナは、必要とされるライブラリをできるだけ多く既にロード済みのホストにデプロイされる。追加のライブラリによって生じる計算のオーバヘッドを低減又は排除することによって、デプロイメントコストを最小化することができる。いくつかの実施形態において、ターゲットホストは、ライブラリの特性、ホストの作業負荷、１つ又は複数のデプロイされるその他のコンテナなどのような他の関連要因にさらに基づいて選択することが可能である。

以下の説明において、本発明の原理を、テンプレートに基づいてコンテナがデプロイされる実施形態を参照して説明する。しかしながら、テンプレートに基づくコンテナ・デプロイメントは単なる例示的な機構であり、本発明の範囲に関するいかなる限定も示唆しないことを理解されたい。代替的な実施形態において、コンテナは、任意の他の適切な機構によってデプロイすることができる。

図２は、テンプレートに基づくコンテナ・デプロイメントの模式図を示す。１つ又は複数のテンプレート２０５を前もって作成することができる。テンプレートは、コンテナをデプロイ及び構築するのに使用することができる情報を収容することができる。例えば、テンプレートは、ウェブアプリケーションがインストールされたオペレーティングシステムを収容することができる。特定のパラメータ値及び／又はネットワーク構成などの構成は、テンプレートがホスト上にデプロイされたときにインスタンス化される。例として、Ｄｏｃｋｅｒコンテナの場合、テンプレート２０５は、「イメージ」と呼ばれる。（注：「Ｄｏｃｋｅｒ」という用語は、世界中の様々な管轄権において商標権の対象である場合があり、本明細書においては、このような商標権が存在し得る範囲で標章によって適正に称される製品又はサービスに対して言及する場合にのみ使用される。）テンプレート２０５は、レジストリ２１０内にアップロードされ、格納されることができる。本明細書を全体を通してＤｏｃｋｅｒ及びＤｏｃｋｅｒ固有の要素について言及しているが、本発明の態様は、コンテナ・デプロイメントが実施される他の自動化プログラムに対しても等しく適用できることを理解されたい。

テンプレート２０５は、ホスト２１５にプロビジョニングされて、ホスト２１５上で実行されるホストＯＳ２２０上でインスタンス化され得る。コンテナエンジン２２５は、コンテナを管理及び制御するために、ホストＯＳ２２０上で実行される。ホスト２１５は、１つ又は複数のコンテナ２３０及び２４０を含むことができ、その各々は、１つ又は複数のテンプレートに基づいて構築される。Ｄｏｃｋｅｒコンテナのようなある種のコンテナの場合、テンプレートは、読出し専用イメージである。テンプレート２０５のインスタンス化は、テンプレートの最上部に書込み可能レイヤを作成することによって行われる。例えば、図２に示すように、書込み可能レイヤ２３２及び２４２は、それぞれコンテナ２３０及び２４０を構築するために作成される。

テンプレートは、「ペアレントテンプレート」と称することができる１つ又は複数のテンプレートを参照することができる。ペアレントテンプレートを有さない下層のテンプレートは、「ベーステンプレート」と称される。図２に示す例において、コンテナ２３０は、テンプレート２３１_１．．．２３１_ｉを伴い、コンテナ２４０は、テンプレート２４１_１．．．２４１_ｊを伴う。このようにして、コンテナは、書込み可能レイヤ、ペアレントテンプレート（存在する場合）に関する情報を伴うその対応するテンプレート、及び一意識別子、ネットワーク構成、リソース割当などのような追加情報によって定義することができる。

一般的に言って、テンプレートをデプロイする際に、１つ又は複数のライブラリがホスト２１５上にロードされることが必要である。Ｄｏｃｋｅｒコンテナにおいて、ライブラリはレイヤに配置されることができ、それゆえテンプレートに対する各ライブラリをレイヤとみなすことができる。例えば、図２に示すように、テンプレート２３１_１は、ライブラリ／レイヤ２３５_１．．．２３５_ｋを収容する。異なるコンテナ／テンプレートが１つ又は複数の共通のライブラリを共有することができる。このようにして、ライブラリ／レイヤは、異なるコンテナ／テンプレートの従属性を定めることができる。本発明の実施形態によれば、このような従属性を用いて、新たなコンテナの効率的なデプロイメントが達成される。

図３は、本発明の実施形態を実装することができる環境３００のブロック図を示す。図示したように、環境３００の中に、複数の候補ホスト２１５_１、．．．、２１５_Ｎ（集合的に「ホスト２１５」と称される）が存在する。候補ホスト２１５の各々は、既にその上にデプロイされた少なくとも１つのコンテナを含む。コンテナマネージャ３１０は、コンテナのデプロイメントを制御する。いくつかの実施形態において、コンテナマネージャ３１０は、例えば、図１を参照して上述したようなコンピュータシステム／サーバ１２によって実装することができる。

コンテナ（「ターゲットコンテナ」と称される）が構築される場合、コンテナマネージャ３１０は、候補ホスト２１５の中から適切なホストを選択する。この目的のために、コンテナマネージャ３１０は、ターゲットコンテナによって必要とされるライブラリ（「ターゲットライブラリ」と称される）を判定する。いくつかの実施形態において、これは、ターゲットコンテナについてのプロビジョン要件３２０を解析することによって行うことができる。例えば、テンプレートに基づくコンテナ・デプロイメントが使用される実施形態において、コンテナマネージャ３１０は、最初にターゲットコンテナをデプロイするためのテンプレートを判定し、次いでそのテンプレートのためのライブラリを判定することができる。コンテナマネージャ３１０は、候補ホスト２１５上にデプロイされたコンテナの構成情報をさらに収集する。構成情報は、候補ホスト２１５の各々の上にロード済みのライブラリを少なくとも示す。

収集された情報に基づいて、コンテナマネージャ３１０は、ターゲットコンテナを候補ホスト２１５の各々の上にデプロイするコストを、ターゲットコンテナと既存のライブラリとの間の従属性に少なくとも部分的に基づいて判定する。コンテナマネージャ３１０は、次いで、デプロイメントコストが最小化されるように、ターゲットコンテナをデプロイするのに適切なホストを選択する。理想的には、ターゲットコンテナによって必要とされるすべてのターゲットライブラリを既にロード済みのホスト２１５があれば、デプロイメントは非常に効率的になるはずである。

図４は、本発明の実施形態によるコンテナ・デプロイメントのための方法４００のフローチャートを示す。方法４００は、図３に示すようなコンテナマネージャ３１０によって実装することができる。例えば、コンテナマネージャ３１０がコンピュータシステム／サーバ１２によって実装される実施形態において、方法４００を実行するように処理ユニット１６を構成することができる。

図４に示すように、方法４００は、ステップ４１０において始められ、ここでターゲットコンテナによって必要とされるターゲットライブラリを示す情報が得られる。考察の便宜上、ステップ４１０で得られる情報を「第１の情報」と称する。第１の情報は、多くの異なる方式で得ることができる。例えば、１つの実施形態において、第１の情報は、ターゲットコンテナについてのプロビジョン要件及び／又は任意の他の構成ファイルから誘導することができる。

一例としてＤｏｃｋｅｒ技術を考えると、「ｄｏｃｋｅｒｆｉｌｅ」と呼ばれるファイルは、コンテナをどのように構築するか、及びコンテナが動作しているときに何を実行するかを記述することができる。（注：「ｄｏｃｋｅｒｆｉｌｅ」という用語は、世界中の様々な管轄権において商標権の対象である場合があり、本明細書においては、このような商標権が存在し得る範囲で標章によって適正に称される製品又はサービスに対して言及する場合にのみ使用される。）図５は、例示的なｄｏｃｋｅｒｆｉｌｅ５００のスクリーンショットを示す。公知のように、ｄｏｃｋｅｒｆｉｌｅは可読であり、アプリケーションソースコードと共に維持可能である。したがって、ターゲットコンテナについてのｄｏｃｋｅｒｆｉｌｅを解析することによって、ロードされることが必要なターゲットライブラリを判定することが可能である。ｄｏｃｋｅｒｆｉｌｅは、単なる例であり、本発明の範囲に関するいかなる限定も示唆しないことを理解されたい。ターゲットライブラリは、ターゲットコンテナに関連する他のいずれかのファイル又はメタデータを解析することによって判定することができる。他の実施形態において、プロビジョン要件の解析に加えて又はその代わりに、ターゲットライブラリは、ユーザによって明示的に指定されるか又は他の任意の方法で得ることができる。

さらに図４に示すように、方法４００は、ステップ４２０に進み、ここで複数の候補ホスト２１５上の１つ又は複数のコンテナに対してロード済みのライブラリを示す情報が得られる。考察の便宜上、ステップ４２０において得られる情報を「第２の情報」と称する。いくつかの実施形態において、第２の情報は、候補ホスト２１５の各々から収集することができる。例えば、Ｄｏｃｋｅｒシステムにおいて、ひとたびコンテナ及び／又はその構成が変化すると、ホスト２１５は、メッセージを生成して、「イベントバス」と呼ばれるコンポーネントに送信することができる。メッセージは、ホスト、ホストＯＳ、デプロイ済のコンテナなどの、ハードウェア及び／又はソフトウェア構成に関する情報を含む。コンテナマネージャ３１０は、このようなメッセージを取得して解析し、候補ホスト２１５の各々の上に既にロード済みのライブラリを判定することができる。この点に関する例示的な実施形態を以下の段落で論じる。

いくつかの実施形態において、第２の情報は、コンテナを候補ホスト２１５上にデプロイするために使用されるテンプレートの構築履歴を解析することによって得ることができる。引き続きＤｏｃｋｅｒコンテナを例として考えると、候補ホスト２１５上にコンテナを構築するために使用されるｄｏｃｋｅｒｆｉｌｅは、上述のようにアクセス可能である。これらのｄｏｃｋｅｒｆｉｌｅは、それゆえ候補ホスト２１５上のコンテナの構築履歴のレコードを維持する。コンテナマネージャ３１０は、候補ホスト２１５上に既にロード済みのライブラリを判定するために、これらのｄｏｃｋｅｒｆｉｌｅを取得して解析することができる。

候補ホスト２１５から第２の情報を収集することに加えて又はその代わりに、いくつかの実施形態において、コンテナマネージャ３１０は、ロードされたライブラリに関する情報をローカルに格納することができる。例えば、ライブラリが候補ホスト２１５上にロードされるたびに、コンテナマネージャ３１０は、レコードを更新することができる。そのような実施形態では、ステップ４２０において、コンテナマネージャ３１０は、そのローカルレコードにアクセスして、候補ホスト２１５の各々の上にロード済みのライブラリを判定することができる。他の適切な手法も可能である。

ステップ４１０はステップ４２０の前に示されているが、これは単に例証を目的とするものであり、本発明の範囲に関するいかなる限定も示唆しないことを理解されたい。第１の情報は、必ずしも第２の情報の前に収集しなければならないわけではない。他の実施形態において、第１及び第２の情報は、逆順に又は並行して得ることができる。

次に、ステップ４３０において、ターゲットコンテナを複数の候補ホスト２１５上にデプロイするコストが、第１の情報及び第２の情報に基づいて判定される。一般に、ターゲットコンテナを任意の所与の候補ホスト２１５上にデプロイするコストは、ロードすべきターゲットライブラリと、候補ターゲット機械上にロード済みのライブラリとの間の一致度に少なくとも部分的に基づいて判定される。随意に、１つ又は複数のその他の要因を考慮に入れることができる。図５は、本発明の例示的な実施形態による、所与の候補ホスト２１５上にターゲットコンテナをデプロイするコストを判定する方法５０５のフローチャートを示す。方法５０５は、候補ホスト２１５の全部又は少なくとも一部に適用することができる。

方法５０５は、ステップ５１０において始められ、ターゲットライブラリと所与の候補ホスト２１５上のライブラリとの間の一致度が、第１の情報及び第２の情報に基づいて判定される。本発明の実施形態によれば、あるライブラリと別のライブラリとが互いに機能的に等しい場合、これら２つのライブラリは一致する。すなわち、既存のライブラリをターゲットライブラリとして機能するように再使用することができるのであれば、そのターゲットライブラリは、所与の候補ホスト２１５上に一致するライブラリを有すると思われる。例えば、ターゲットライブラリが所与の候補ホスト２１５上に既にロード済みであると判定されたのであれば、一致が見いだされたことになる。別の例として、候補ホスト上の１つ又は複数の既存のライブラリがターゲットライブラリと機能的に等しいか又は類似であれば、同様に一致が見いだされたことになる。ステップ５１０において、所与の候補ホスト２１５上に一致するライブラリを有するターゲットライブラリの数を判定することが可能である。

いくつかの実施形態において、ステップ５２０において、各ターゲットライブラリを所与の候補ホストにロードするコストが判定される。異なるライブラリをロードするコストは通常異なることが認識されるであろう。例えば、ある種のライブラリは、ロードするプロセスにおいてより多くのリソース（計算リソース、ストレージリソースなど）を消費する。別の例において、異なるライブラリは、通常異なるサイズを有し、したがって異なるネットワーク帯域幅リソースを消費する。ターゲットライブラリをロードするコストは、そのサイズ、ＣＰＵ（中央処理ユニット）消費、ストレージ消費及び／又は他の関連要因に基づいて判定することができる。方法４００におけるステップ４１０及び４２０と同様に、ステップ５１０及び５２０の順序は交換することができる。

方法５０５は次にステップ５３０に進む。このステップにおいて、ターゲットコンテナを所与の候補ホスト２１５上にデプロイするコストが判定される。いくつかの実施形態では、ステップ５３０において、コストは、ステップ５１０において判定される一致度、及びステップ５２０において判定されるターゲットライブラリをロードするコストに基づいて判定される。ターゲットコンテナが、ロードすべきＮ個のターゲットライブラリＬ_１、Ｌ_２．．．Ｌ_Ｎを伴うと想定し、ここでＮは自然数を表すものとする。１つの実施形態において、ターゲットコンテナを候補ホスト２１５上にデプロイするコストは、下記のように判定され、
Ｃ＝Ｍ_１＊Ｃ_１＋Ｍ_２＊Ｃ_２．．．＋Ｍ_Ｎ＊Ｃ_Ｎ
ここで、ターゲットライブラリＬ_ｉが所与の候補ホスト２１５上に一致するライブラリを有する場合、Ｍ_ｉ＝０であり、そうでない場合、Ｍ_ｉ＝１であり（ｉ＝１．．．Ｎ）、Ｃ_ｉは、ライブラリＬ_ｉを所与の候補ホスト２１５にロードするコストを表す。

あるいは、他の実施形態において、ターゲットコンテナをデプロイするコストは、ステップ５３０において、個々のライブラリをロードするコストを考慮せずに判定することができる。例えば、場合によっては、異なるライブラリをロードするコストはほぼ同じであると仮定することが合理的である。この点において、ステップ５２０を省略することができる。従って、ステップ５３０において、ターゲットコンテナを所与の候補ホスト２１５上にデプロイするコストは、以下のように計算することができる。
Ｃ＝Ｍ_１＋Ｍ_２．．．＋Ｍ_Ｎ

引き続き図４を参照すると、いくつかの実施形態において、方法４００はステップ４４０に進み、ここで複数の候補ホスト２１５の作業負荷を示す情報が得られる。考察の便宜上、ステップ４４０において得られる情報を「第３の情報」と称する。例として、候補ホスト２１５の各々について、第３の情報は、プロセッサ使用率、メモリ使用率、ディスク使用率、ネットワーク帯域幅使用率などのうちの１つ又は複数を示すことができる。第３の情報に含まれるメトリックをそれぞれの閾値と比較することによって、各候補ホスト２１５が重い負担を負っているか否かを判定することができる。

次に、ステップ４５０において、複数の候補ホスト２１５の中からターゲットホストが選択される。本発明の実施形態によれば、ターゲットホストは、ステップ４３０において判定されたコストに少なくとも部分的に基づいて選択される。一般に、ターゲットホストは、ターゲットコンテナをデプロイするコストが十分に低くなる（閾値を下回る）ように選択される。詳細には、いくつかの実施形態において、ターゲットコンテナをデプロイするコストを最小化することができる候補ホスト２１５が、ステップ４５０においてターゲットホストとして選択される。このようにして、コンテナ／テンプレートの間の従属性の使用によって、ターゲットコンテナを効率的にデプロイすることができる。実験は、コンテナ・デプロイメントによって消費される時間を著しく低減することができることを示す。例えば、従来の手法では５〜１０分かかるスクラッチからイメージを構築する作業に対して、本発明の実施形態は、約５秒しか要しない。

いくつかの実施形態において、ステップ４５０においてターゲットホストを選択することは、ステップ４４０において判定された候補ホスト２１５の作業負荷に、さらに基づくことができる。例えば、いくつかの実施形態において、その作業負荷が所定の閾値を超える候補ホスト２１５は、最初に除外される。すなわち、ターゲットホストは、比較的低い作業負荷を有する残りの候補ホストの中から選択される。あるいは、いくつかの実施形態において、ステップ４３０において判定されたコスト及びステップ４４０において判定された作業負荷を組み合わせて、ステップ４５０においてターゲットホストを選択するためのメトリックとして機能させることができる。単なる例として、コストと作業負荷とを乗算して、メトリックとして機能させることができる。その他の任意の適切な方法も可能である。

候補ホストの作業負荷を考慮に入れることによって、現時点で過負荷のホスト上にターゲットコンテナをデプロイすることを回避することが可能である。すなわち、ホストのデプロイメントコストと作業負荷との間にはトレードオフが存在する。しかしながら、作業負荷は必ずしも考慮に入れる必要がないことを理解されたい。いくつかの実施形態において、ターゲットホストは、上述のように、判定されたコストのみに基づいて選択することができる。さらに、作業負荷に加えて又はその代わりに、ステップ４５０において候補ホスト２１５の他の特性を考慮することができる。特性の例は、性能、セキュリティ、ネットワークドメイン、製造者などを含むがこれらに限定されない。

さらに、ときには複数のコンテナをバッチでデプロイすべき場合があることが認識されるであろう。例えば、あるアプリケーションを構築するために、互いに協働する複数のコンテナをデプロイする必要があり得る。この点で、ステップ４５０において、ターゲットホストは、コンテナを個別に考慮する代わりに、複数のターゲットコンテナの総コストに基づいて選択することができる。例えば、第１のコンテナ及び第２のコンテナがデプロイされるものとする。いくつかの実施形態において、ターゲットホストを別々に選択する代わりに、ターゲットホストは、ステップ４５０において、第１及び第２のコンテナをデプロイする総コストが所定の閾値を下回るか又は最小化されるように選択することができる。このようにして、全システムの性能を改善することができる。

ターゲットコンテナは、ステップ４５０において選択されたターゲットホスト上にデプロイすることができる。現在公知であるか又は将来開発されるかいずれかの任意の適切な技術を適用して、ターゲットコンテナのデプロイメントを完成させることができる。例えば、選択されたターゲットホストに関する情報及び他のいずれかの関連情報をプロビジョンメタデータとして編成することができる。プロビジョンメタデータは、プロビジョンコマンダに提供されることができ、これが次にコンテナデプロイヤを制御して、選択されたターゲットホストに必要とされるテンプレートを分配する。ターゲットホスト上でテンプレートをインスタンス化することによって、ターゲットコンテナがデプロイされる。

詳細には、本発明の実施形態によれば、互いに機能的に関連付けられた２以上のコンテナを２以上の別々のホスト上にデプロイすることができる。すなわち、これらの関連付けられたコンテナは、異なるホストにわたって分配される。例えば、インターネットベースのアプリケーションを構築する際に、いくつかのコンテナをネットワークドメインの外部からアクセス可能なホスト上にデプロイすることができ、その一方で、他のコンテナは、内部データへのアクセスを有する異なるホスト上にデプロイされる。こうした状況に対処するために、いくつかの実施形態において、ブリッジコンポーネントをデプロイして、分配されたコンテナ間のデータ通信を可能にすることができる。１つの実施形態において、ブリッジコンポーネントは、例えば、軽量コンテナとして実装することができる。あるいは、別の実施形態において、ブリッジコンポーネントは、関連付けられたコンテナ間の通信を担当する専用コンポーネントとすることができる。

図６は、本発明によるコンテナ・デプロイメントのためのシステム６００のブロック図を示す。システム６００におけるコンテナは、Ｄｏｃｋｅｒコンテナであり、この場合、テンプレートは、上述のように読出し専用イメージである。図示したように、この例において、候補ホスト２１５_１．．．２１５_Ｎは、イベントバス６０５に通信可能に結合する。候補ホスト２１５_１．．．２１５_Ｎは、各々、コンテナ／その上にデプロイ済みのイメージに関する情報を収集する。このような情報は、イベントバス６０５へ伝送されるメッセージ内にカプセル化される。メッセージの伝送は、例えば、候補ホスト２１５上のなんらかの変化によってトリガされ得る。イベントバス６０５は、メッセージをインデックスレジストリ６１０に格納する。インデックスレジストリ６１０は、ホスト、コンテナ、コンテナエンジン、ソフトウェア／ハードウェア構成などに関連した他の任意の情報をさらに格納する。

リソースアナライザ６１５は、インデックスレジストリ６１０から情報を取得し、取得した情報を解析することができる。解析の結果は、候補ホストメタデータ６２０として編成され、これは少なくとも、例えば各候補ホスト２１５の現在の作業負荷を示す。候補ホストメタデータ６２０は、コンテナ／イメージ情報コレクタ６２５へと提供される。いくつかの実施形態において、候補ホストメタデータ６２０に基づいて、コンテナ／イメージ情報コレクタ６２５は、その作業負荷が所定の閾値を超える候補ホスト２１５を除外することができる。残りの候補ホスト２１５について、コンテナ／イメージ情報コレクタ６２５は、インデックスレジストリ６１０から、候補ホスト２１５上の既存のライブラリ又はレイヤを少なくとも示す第１の情報を収集する。第１の情報は、この例ではコンテナ／イメージ情報６３０として編成される。

図７は、コンテナ／イメージ情報６３０の一例を示す。図示した例において、コンテナ／イメージ情報６３０は、拡張マークアップ言語（ＸＭＬ）ファイル７００として実装される。コンテナ／イメージ情報６３０は、２つの候補ホストＡ及びＢに関する情報を収容している。ホストＡは、２つのコンテナを有し、ここでコンテナＡ＿ａは、４つのレイヤを含み、コンテナＡ＿ｂは、３つのレイヤを含む。ホストＢは、４つのレイヤを含む１つのコンテナＢ＿ａを有する。

図６に戻ると、コンテナ／イメージ情報６３０及びプロビジョン要件６４０の両方がプロビジョンアナライザ６４０へと提供される。プロビジョン要件６４０は、デプロイされるターゲットコンテナの要件を示す。いくつかの実施形態において、ターゲットライブラリ／レイヤを示す第２の情報は、プロビジョン要件６４０から誘導することができる。入力情報に基づいて、プロビジョンアナライザ６４０は、上述のように、適切なターゲットホスト２１５を選択することができる。選択されたターゲットホスト２１５に関する情報は、プロビジョンメタデータ６４５内に格納することができ、これも図７に示すファイル７００と同様にＸＭＬファイルとして実装することができる。

プロビジョンメタデータ６４５は、プロビジョンコマンダ６５０へと提供される。プロビジョンコマンダ６５０は、プロビジョンメタデータ６４５を解釈し、コンテナデプロイヤ６５５を制御して、選択されたターゲットホスト上にイメージを提供し及びインスタンス化して、ターゲットコンテナをデプロイする。２以上の関連付けられたコンテナが異なるホスト上にデプロイされる場合、プロビジョンコマンダ６５０は、ブリッジデプロイヤ６６０を制御してブリッジコンポーネントを構築し、デプロイされたコンテナ間の通信を可能にする。

本発明のいくつかの実施形態は、異なるホストＯＳサーバからの既存のイメージとターゲットとされるプロビジョニング要件との間の従属性解析を通じた効率的なコンテナプロビジョニングを提供するためのシステム及び装置に関する。これは、従来技術と比べて、すべての利用可能なサーバにわたって最小コストを判定してそこにイメージを構築する機構を提供するという独自の利点を有する。

本発明のいくつかの実施形態において、ホストサーバ、コンテナ、イメージ及びそれらの下層のレイヤを含むすべてのターゲットとされる環境の情報は、イベントバスに基づくｐｕｂ／ｓｕｂ機構を通じて、インデックスレジストへと摂取することができる。リソースアナライザを使用して、新たなイメージを動作させるために利用可能な候補ホストを識別する。検査機構に基づいて、各コンテナ又はイメージについての構築履歴の情報をコンテナ／イメージ情報コレクタによって取得することができる。

本発明のいくつかの実施形態において、ひとたびユーザが１つの新たなイメージを要求すると、表現されたメタデータを上記の収集されたすべての情報と共に使用して、コンテクストモデルを形成することができる。各アーチファクト（これはコンテクストモデル由来のコンテナ、イメージ、レイヤ、又はホストサーバであり得る）に対して、コスト値が割り当てられる。そして、そのアーチファクトが未だロードされていなければ、そのコストがかかることになる。コスト計算及び比較に基づいて、ターゲットとされるホストサーバの情報を含む最終的なプロビジョニングメタデータを判定することができる。

さらに、本発明のいくつかの実施形態において、プロビジョンコマンダは、プロビジョニングメタデータをポピュレートして、最適化されたホストＯＳ選択を行う。ホストＯＳの選択基準の１つは、ホストＯＳサーバ横断的なコンテナプロビジョニングを駆動することができる、ホストＯＳサーバ間のネットワーク通信能力に関する。この状況に従って、ブリッジデプロイヤは、各ホストＯＳサーバ上に２つのコンテナをプロビジョニングしてそれらを互いに接続することができる。

本発明は、システム、装置、デバイス、方法、及び／又はコンピュータプログラム製品であり得る。コンピュータプログラム製品は、本発明の態様をプロセッサに実行させるためのコンピュータ可読プログラム命令をその上に有するコンピュータ可読ストレージ媒体（単数又は複数）を含むことができる。

コンピュータ可読ストレージ媒体は、命令実行デバイスによって使用するための命令を保持及び格納することができる有形デバイスとすることができる。コンピュータ可読ストレージ媒体は、例えば、電子ストレージデバイス、磁気ストレージデバイス、光ストレージデバイス、電磁気ストレージデバイス、半導体ストレージデバイス、又は上記のものの任意の適切な組合せとすることができるがこれらに限定されない。コンピュータ可読ストレージ媒体のより具体的な例の非網羅的なリストは、ポータブル・コンピュータ・ディスケット、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、消去可能プログラム可能読み出し専用メモリ（ＥＰＲＯＭ又はフラッシュメモリ）、静的ランダムアクセスメモリ（ＳＲＡＭ）、ポータブル・コンパクトディスク読み出し専用メモリ（ＣＤ−ＲＯＭ）、デジタル多目的ディスク（ＤＶＤ）、メモリスティック、フロッピーディスク、例えばパンチカード若しくは記録された命令を有する溝内に隆起した構造などの機械式コード化デバイス、及び上記のものの任意の適切な組合せを含む。コンピュータ可読ストレージ媒体は、本明細書で用いられる場合、無線波若しくは他の自由に伝搬する電磁波、導波路若しくは他の伝送媒体を通って伝搬する電磁波（例えば光ファイバケーブルを通る光パルス）、又は電線を通って伝送される電気信号のようなそれ自体が一時的な信号と解釈すべきではない。

本明細書で説明するコンピュータ可読プログラム命令は、コンピュータ可読ストレージ媒体からそれぞれのコンピューティング／処理デバイスにダウンロードすることもでき、又は、例えばインターネット、ローカルエリアネットワーク、広域ネットワーク及び／又は無線ネットワークを経由して、外部コンピュータ若しくは外部ストレージデバイスにダウンロードすることもできる。ネットワークは、銅伝送ケーブル、光伝送ファイバ、無線伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータ及び／又はエッジサーバを含むことができる。各コンピューティング／処理デバイス内のネットワークアダプタカード又はネットワークインタフェースは、ネットワークからコンピュータ可読プログラム命令を受け取り、そのコンピュータ可読プログラム命令をそれぞれのコンピューティング／処理デバイス内のコンピュータ可読ストレージ媒体にストレージのために転送する。

本発明の動作を実行するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、機械語命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、又は、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋などのオブジェクト指向プログラミング言語及び「Ｃ」プログラミング言語若しくは類似のプログラミング言語のような従来の手続き型プログラミング言語を含む１つ若しくは複数のプログラミング言語の任意の組合せで記述されたソースコード若しくはオブジェクトコードのいずれかとすることができる。コンピュータ可読プログラム命令は、完全にユーザのコンピュータ上で実行される場合もあり、一部がユーザのコンピュータ上で、独立型ソフトウェアパッケージとして実行される場合もあり、一部がユーザのコンピュータ上で実行され、一部が遠隔コンピュータ上で実行される場合もあり、又は完全に遠隔コンピュータ若しくはサーバ上で実行される場合もある。後者のシナリオにおいては、遠隔コンピュータは、ローカルエリアネットワーク（ＬＡＮ）若しくは広域ネットワーク（ＷＡＮ）を含むいずれかのタイプのネットワークを通じてユーザのコンピュータに接続される場合もあり、又は外部コンピュータへの接続が行われる場合もある（例えば、インターネットサービスプロバイダを用いたインターネットを通じて）。幾つかの実施形態において、例えばプログラム可能論理回路、フィールドプログラム可能ゲートアレイ（ＦＰＧＡ）、又はプログラム可能論理アレイ（ＰＬＡ）を含む電子回路は、本発明の態様を実施するために、コンピュータ可読プログラム命令の状態情報を利用して電子回路を個別化することにより、コンピュータ可読プログラム命令を実行することができる。

本発明の態様は、本明細書において、本発明の実施形態による方法、装置（システム）、及びコンピュータプログラム製品のフローチャート図及び／又はブロック図を参照して説明される。フローチャート図及び／又はブロック図の各ブロック、並びにフローチャート図及び／又はブロック図のブロックの組合せは、コンピュータ可読プログラム命令によって実装することができることが理解されるであろう。

これらのコンピュータ可読プログラム命令を、汎用コンピュータ、専用コンピュータ、又は他のプログラム可能データ処理装置のプロセッサに与えてマシンを製造し、それにより、コンピュータ又は他のプログラム可能データ処理装置のプロセッサによって実行される命令が、フローチャート及び／又はブロック図の１つ又は複数のブロック内で指定された機能／動作を実装するための手段を作り出すようにすることができる。これらのコンピュータプログラム命令を、コンピュータ、プログラム可能データ処理装置、及び／又は他のデバイスを特定の方式で機能させるように指示することができるコンピュータ可読ストレージ媒体内に格納し、それにより、その中に格納された命令を有するコンピュータ可読媒体が、フローチャート及び／又はブロック図の１つ又は複数のブロックにおいて指定された機能／動作の態様を実装する命令を含む製品を含むようにすることもできる。

コンピュータ可読プログラム命令を、コンピュータ、他のプログラム可能データ処理装置又は他のデバイス上にロードして、一連の動作ステップをコンピュータ、他のプログラム可能データ処理装置又は他のデバイス上で行わせてコンピュータ実装のプロセスを生成し、それにより、コンピュータ、他のプログラム可能装置又は他のデバイス上で実行される命令が、フローチャート及び／又はブロック図の１つ又は複数のブロックにおいて指定された機能／動作を実装するようにすることもできる。

フローチャート及びブロック図は、本開示の種々の実施形態による、システム、方法、及びコンピュータプログラム製品の可能な実装の、アーキテクチャ、機能及び動作を示す。この点に関して、フローチャート又はブロック図内の各ブロックは、指定された論理機能を実装するための１つ又は複数の実行可能命令を含む、モジュール、断片、又はコードの一部を表すことができる。幾つかの代替的な実装において、ブロック内に記された機能は、図中に記された順序とは異なる順序で行われることがあることにも留意されたい。例えば、連続して示された２つのブロックは、関与する機能に応じて、実際には実質的に同時に実行されることもあり、又はこれらのブロックはときとして逆順で実行されることもある。ブロック図及び／又はフローチャート図の各ブロック、及びブロック図及び／又はフローチャート図中のブロックの組合せは、指定された機能又は動作を実行する専用ハードウェア・ベースのシステムによって実装することもでき、又は専用ハードウェアとコンピュータ命令との組合せを実行することもできることにも留意されたい。

本発明の種々の実施形態の説明は、例証の目的で提示したものであるが、網羅的であることも、又は開示された実施形態に限定することも意図しない。説明した実施形態の範囲から逸脱することなく、多くの修正及び変形が当業者には明らかであろう。本明細書で用いる用語は、実施形態の原理、実際的な用途、若しくは市場において見いだされる技術に優る技術的改善を最も良く説明するように、又は当業者が本明細書に含まれる実施形態を理解することを可能にするように、選択されたものである。

１８：バス
４０：プログラム／ユーティリティ
４２：プログラムモジュール
２０５：テンプレート
２１０：レジストリ

Claims (5)

1. コンピュータの情報処理により、仮想機械（VM）におけるプロセスおよびリソースを隔離したコンテナについてターゲットホストを選択する方法であって、
   デプロイされるターゲットコンテナによって必要とされるターゲットライブラリのセットを示す第１の情報を取得するステップと、
   複数の候補ホストを決定するステップであって、前記複数の候補ホストは、
   （ｉ）デプロイされるターゲットコンテナと同じオペレーティングシステムを利用し、
   （ｉｉ）デプロイされるターゲットコンテナによって必要とされるライブラリのセットと共通する少なくとも１つのライブラリを利用するデプロイされたコンテナを含み、
   前記複数の候補ホスト上にデプロイされた少なくとも１つのコンテナについてロード済みのライブラリのセットを示す第２の情報を取得するステップであって、前記少なくとも１つのコンテナを前記複数の候補ホスト上にデプロイするために使用された情報を含むテンプレートのセットを取得し、当該テンプレートの構築履歴を解析し、前記テンプレートの従属性を決定するステップを含む、前記取得するステップと、
   前記第１の情報、前記第２の情報および前記従属性に基づいて、複数の候補ホスト上に前記ターゲットコンテナをデプロイするコストを判定するステップと、
   前記ターゲットコンテナをデプロイするための前記コストが最小となるように、前記複数の候補ホストからターゲットホストを選択するステップであって、ここで前記ターゲットコンテナは第１のコンテナであり、
   前記ターゲットホストは、前記複数の候補ホストの中から選択された第１のホストであり、
   前記第１のコンテナを前記第１のホストにデプロイするステップと、
   前記第１のコンテナに関連付けられた第２のコンテナを、前記第１のホストとは異なる、前記複数の候補ホストから選択された第２のホストにデプロイするステップと、
   前記第１のコンテナと前記第２のコンテナとの間でデータを通信するように動作可能なブリッジコンポーネントをデプロイするステップと、
   を含む、方法。
2. 前記ターゲットコンテナをデプロイする前記コストを判定するステップは、前記複数の候補ホストの中からの所与の候補ホストに対して、
   前記第１の情報、前記第２の情報および前記従属性に基づいて、前記ターゲットライブラリのセットと前記所与の候補ホスト上にロード済みのライブラリのセットとの間の一致度を判定するステップと、
   前記一致度に少なくとも部分的に基づいて、前記ターゲットコンテナを前記所与の候補ホスト上にデプロイする前記コストを判定するステップと、
   を含む、請求項１に記載の方法。
3. 請求項１〜２の何れか１項に記載の方法の各ステップをハードウェアによる手段として構成した、コンピュータシステム。
4. 請求項１〜２のいずれか１項に記載の方法の各ステップをコンピュータに実行させる、コンピュータプログラム。
5. 請求項４に記載の前記コンピュータプログラムをコンピュータ可読ストレージ媒体上に格納した、ストレージ媒体。

Images