(57)【特許請求の範囲】
【請求項１】
複数のレイヤーで構成される作成対象のコンテナイメージである統合イメージの前記レイヤーごとに作成された、前記レイヤーのコンポーネントのコンテナイメージであるレイヤー別イメージと、
前記レイヤー別イメージの構成定義情報に基づいて、前記レイヤー別イメージから前記統合イメージへファイルをコピーすることにより、前記複数のレイヤー別イメージを統合して、前記統合イメージを作成するイメージ統合部と、
を備えるコンテナイメージ統合システム。
【請求項２】
前記コンポーネントが依存する他の前記レイヤーの前記コンポーネントとの間の互換性の確認を行う互換性確認部、
をさらに備える請求項１に記載のコンテナイメージ統合システム。
【請求項３】
前記ファイルが、既にコピー先に存在する競合状態の場合に、前記構成定義情報に基づいて、前記ファイルの競合を解消するイメージ間競合解決部、
をさらに備える請求項１または請求項２に記載のコンテナイメージ統合システム。
【請求項４】
前記レイヤー別イメージを記憶するイメージ保持部、
をさらに備え、
前記統合イメージがＮ個のレイヤーで構成される場合、前記イメージ保持部は、Ｎ個の前記レイヤー別イメージを記憶し、下からＮ層目の前記レイヤー別イメージは、下から１〜Ｎ層それぞれの前記レイヤーに対応する前記コンポーネントを含むコンテナイメージである、
請求項１から請求項３の何れか１項に記載のコンテナイメージ統合システム。
【請求項５】
前記レイヤー別イメージの作成および更新を行うイメージ作成部、
をさらに備え、
前記イメージ作成部は、下からＮ層目の前記コンポーネントを更新する場合、下からＮ層目の前記レイヤー別イメージに対して更新処理を行う、
請求項４に記載のコンテナイメージ統合システム。
【請求項６】
前記イメージ統合部は、前記レイヤーごとの前記コンポーネントの名称とバージョン情報を定義した統合定義情報に基づいて、前記イメージ保持部から、前記名称および前記バージョン情報に一致する前記コンポーネントについて作成された前記レイヤー別イメージを読み出して、該レイヤー別イメージから前記ファイルのコピーを行う、
請求項４または請求項５に記載のコンテナイメージ統合システム。
【請求項７】
複数のレイヤーで構成される作成対象のコンテナイメージである統合イメージの前記レイヤーごとに作成された、前記レイヤーのコンポーネントのコンテナイメージであるレイヤー別イメージと、前記レイヤー別イメージの構成定義情報と、に基づいて、前記レイヤー別イメージから前記統合イメージへファイルをコピーすることにより、前記複数のレイヤー別イメージを統合して、前記統合イメージを作成する、
コンテナイメージ統合方法。
【請求項８】
コンピュータに、
複数のレイヤーで構成される作成対象のコンテナイメージである統合イメージの前記レイヤーごとに作成された、前記レイヤーのコンポーネントのコンテナイメージであるレイヤー別イメージと、前記レイヤー別イメージの構成定義情報と、に基づいて、前記レイヤー別イメージから前記統合イメージへファイルをコピーすることにより、前記複数のレイヤー別イメージを統合して、前記統合イメージを作成する処理、
を行わせるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテナイメージ統合システム、コンテナイメージ統合方法及びプログラムに関する。
【背景技術】
【０００２】
仮想化技術の１つに、OS（operating system）のカーネルを共有し、ユーザ空間を隔離するコンテナ型仮想化がある。コンテナランタイムとしては、例えば、Docker社のDockerが知られている。コンテナ型仮想化では、コンテナ上で動作させるアプリケーションに必要なファイルをまとめたファイルをコンテナイメージまたは単にイメージと呼ぶ。また、コンテナのイメージを保持する装置をコンテナレジストリまたは単にレジストリと呼ぶ。レジストリは、ローカルおよびネットワーク上に存在する。ネットワーク上のレジストリに存在するイメージからコンテナを起動する場合、コンテナランタイムは、ネットワーク上のレジストリからローカルのレジストリにイメージをダウンロードして、ローカルのレジストリのイメージを用いてコンテナを起動する。コンテナのイメージは、イメージ定義ファイルを用いて作成する。イメージ定義ファイルには、ベースとするイメージに対して行う処理が実行順に記載されている。コンテナランタイムは、イメージ定義ファイルに記載された処理を順番に実行し、レイヤー状に構築されたイメージを作成する。イメージ定義ファイルに記載された各行の処理が、構築されたイメージにおける各レイヤーに対応する。コンテナの実行時には、上位のレイヤーにあるファイルが優先して使用される。その為、新たなファイルの追加や、何れかのレイヤーのファイルの更新を行う場合、元のイメージは変更せず、差分ファイルで構成されたレイヤーを、元のイメージの上に構築し、イメージの更新を行う。
【０００３】
例えば、図１４に例示するように、イメージのレイヤー１に「/xxx/yyy/zzz-001」と「/xxx/yyy/zzz-002」の２つのファイルがあるとする。レイヤー１には含まれない「/xxx/yyy/zzz-003」というファイルを追加する場合、図１５に例示するように、レイヤー１はそのままで、追加ファイルのみを含むレイヤー２がレイヤー１の上に構築される。さらに、レイヤー１に含まれる「/xxx/yyy/zzz-002」というファイルを変更する場合、図１６に例示するように、変更されたファイルのみを含むレイヤー３がレイヤー２の上に構築される。この３つのレイヤーから構成されるイメージをコンテナ上で実行する場合、レイヤー１の「/xxx/yyy/zzz-002」は使用されず、図１７に例示するように、レイヤー１の「/xxx/yyy/zzz-001」と、レイヤー３の「/xxx/yyy/zzz-002」と、レイヤー２の「/xxx/yyy/zzz-003」の各ファイルが使用される。
【０００４】
イメージをレイヤー状に構築することにより、レイヤーを再利用することができる。例えば、図１５の例で、ファイル「/xxx/yyy/zzz-001」を変更する場合、レイヤー１とレイヤー２はそのまま再利用して、その上に変更された「/xxx/yyy/zzz-001」のみを含むレイヤー３´を追加する(図１８)。すると、レイヤー３´の「/xxx/yyy/zzz-001」とレイヤー１の「/xxx/yyy/zzz-002」とレイヤー２の「/xxx/yyy/zzz-003」を含むイメージを構築することができる(図１９)。
【０００５】
レイヤーを再利用すると、イメージの保存容量の削減、イメージ送信時の通信量・通信時間の削減、イメージ構築時の構築時間の削減という効果が得られる。イメージのレイヤーは下から順に構築されるため、レイヤーの再利用性を高めるには、下から順に更新頻度の低いものから高いものの順でイメージを構築していく必要がある。そのため、イメージを構築する際の処理の順序の入れ替えやマージを行うことで生成されるイメージのレイヤーの数や容量、再利用性を最適化する技術が提供されている。例えば、特許文献１には、イメージを構築する際の各処理をカテゴリに分類し、更新頻度の高いカテゴリに属する処理ほど上のレイヤーになるように各処理を並べ替えてイメージを最適化する技術が開示されている。
【０００６】
イメージのレイヤーの再利用についてさらに検討する。上記のように、コンテナ型仮想化では、イメージを更新する際は、更新前のレイヤーの上に更新内容を含んだ新たなレイヤーを追加するだけで、下位のレイヤーを再利用することができる。しかし、下位のレイヤーが更新されると、それより上のレイヤーも全て作り直す必要がある。例えば、OS、ライブラリ、ミドルウェア、アプリケーションによって構成されるコンテナの場合、そのイメージは、図２０に例示するようにレイヤーが形成される。つまり、最下位のレイヤー１はOSのベースイメージ、下から２番目のレイヤー２はライブラリのイメージ、３番目のレイヤー３はミドルウェアのイメージ、最上位のレイヤー４はアプリケーションのイメージである。
【０００７】
図２０の例で、ミドルウェアのイメージを提供する場合、レイヤー１〜３で構成されるイメージを提供することになる。レイヤー１のOSのベースイメージを更新すると、それに合わせてミドルウェアのイメージを作り直さなければならない。また、ミドルウェアのイメージにアプリケーションを配備している状態で、ミドルウェアにパッチを適用するには、以下の２つの方法がある。
（方法１）レイヤー４の上にミドルウェアのパッチを適用する。
（方法２）レイヤー３の上にミドルウェアのパッチを適用し、その上にアプリケーションを配備し直す。
【０００８】
（方法１）でパッチを適用した場合、イメージは以下のようなレイヤー構造となる。
レイヤー５．ミドルウェアのパッチを適用してできたレイヤー（最上位）
レイヤー４．アプリケーションを配備してできたレイヤー
レイヤー３．ミドルウェアをインストールしてできたレイヤー
レイヤー２．ライブラリをインストールしてできたレイヤー
レイヤー１．OSのベースイメージ（最下位）
【０００９】
例えば、ミドルウェアのパッチ適用状況は同じで、アプリケーションが異なるイメージを作成する場合、上記のレイヤー１〜５で構成されたイメージは、別のアプリケーションが既に配備された状態であるため、パッチ適用済みのミドルウェアのイメージとして再利用することはできない。また、中間のレイヤー３にあるミドルウェアのファイルはレイヤー５のミドルウェアのパッチ適用により不要になったファイルが含まれるため、イメージのサイズが不要に大きくなる。また、例えば、ミドルウェアのパッチ適用とアプリケーションの更新を（方法１）によって繰り返すと、ミドルウェアへのパッチ適用のレイヤーとアプリケーション更新のレイヤーが交互に重なる等して、ミドルウェアのイメージの再利用が難しくなる。
【００１０】
（方法２）でパッチを適用した場合、イメージは以下のようなレイヤー構造となり、レイヤー１〜４のミドルウェアまでのレイヤーは異なるアプリケーションを配備する際に再利用が可能になる。
レイヤー５．アプリケーションを配備してできたレイヤー（最上位）
レイヤー４．ミドルウェアのパッチを適用してできたレイヤー
レイヤー３．ミドルウェアをインストールしてできたレイヤー
レイヤー２．ライブラリをインストールしてできたレイヤー
レイヤー１．OSのベースイメージ（最下位）
しかし、イメージのレイヤーは下から順に構築する必要があるため、ミドルウェアへのパッチ適用のたびにアプリケーションを配備したイメージを作り直す必要がある。つまり、OS、ライブラリ、ミドルウェア、パッチ、アプリケーションの再インストールが必要になる。
【００１１】
また、特許文献１に記載の方法によれば、ミドルウェアのパッチ適用とアプリケーションの更新が繰り返される場合、その更新頻度によってイメージが構築されるが、更新頻度は開発運用の各フェーズで異なる場合が多い。例えば、アプリケーションの開発時には、ミドルウェア等のアプリケーション実行環境の更新頻度が低く、アプリケーションの更新頻度が高い。運用時には、アプリケーションに変更が無く、実行環境へのパッチ適用などが発生し、更新頻度が開発時とは逆になる可能性がある。そのため、各レイヤーの更新頻度が変わるたびに最適化されたイメージを作り変える必要がある。
【先行技術文献】
【特許文献】
【００１２】
【特許文献１】特開２０１９−２８６９０号公報
【発明の概要】
【発明が解決しようとする課題】
【００１３】
アプリケーションを構成する各コンポーネントのイメージの再利用性を担保しつつ、アプリケーションの実行環境のイメージを作成する方法が求められている。
【００１４】
そこでこの発明は、上述の課題を解決するコンテナイメージ統合システム、コンテナイメージ統合方法及びプログラムを提供することを目的としている。
【課題を解決するための手段】
【００１５】
本発明の一態様によれば、コンテナイメージ統合システムは、複数のレイヤーで構成される作成対象のコンテナイメージである統合イメージの前記レイヤーごとに作成された、前記レイヤーのコンポーネントのコンテナイメージであるレイヤー別イメージと、前記レイヤー別イメージの構成定義情報に基づいて、前記レイヤー別イメージから前記コンテナイメージへファイルをコピーすることにより、前記複数のレイヤー別イメージを統合して、前記統合イメージを作成するイメージ統合部と、を備える。
【００１６】
また、本発明の他の一態様は、複数のレイヤーで構成される作成対象のコンテナイメージである統合イメージの前記レイヤーごとに作成された、前記レイヤーのコンポーネントのコンテナイメージであるレイヤー別イメージと、前記レイヤー別イメージの構成定義情報と、に基づいて、前記レイヤー別イメージから前記コンテナイメージへファイルをコピーすることにより、前記複数のレイヤー別イメージを統合して、前記統合イメージを作成する、コンテナイメージ統合方法である。
【００１７】
また、本発明の他の一態様によれば、プログラムは、コンピュータに、複数のレイヤーで構成される作成対象のコンテナイメージである統合イメージの前記レイヤーごとに作成された、前記レイヤーのコンポーネントのコンテナイメージであるレイヤー別イメージと、前記レイヤー別イメージの構成定義情報と、に基づいて、前記レイヤー別イメージから前記コンテナイメージへファイルをコピーすることにより、前記複数のレイヤー別イメージを統合して、前記統合イメージを作成する処理、を実行させる。
【発明の効果】
【００１８】
本発明によれば、コンテナ型仮想化において、複数のコンテナイメージを統合することによって、目標とするコンテナイメージを作成することができる。
【図面の簡単な説明】
【００１９】
【図１】本発明の一実施形態によるコンテナイメージ統合システムの一例を示す図である。
【図２】本発明の一実施形態によるイメージの統合処理を示す第１の概略図である。
【図３】本発明の一実施形態によるイメージの統合処理を示す第２の概略図である。
【図４】本発明の一実施形態によるイメージの統合処理を示す第３の概略図である。
【図５】本発明の一実施形態によるイメージの統合処理を示す第４の概略図である。
【図６】本発明の一実施形態によるコンポーネントイメージの構成定義情報の一例を示す第１の図である。
【図７】本発明の一実施形態によるコンポーネントイメージの構成定義情報の一例を示す第２の図である。
【図８】本発明の一実施形態による統合定義情報の一例を示す図である。
【図９】本発明の一実施形態によるコンポーネントイメージの作成処理の一例を示す図である。
【図１０】本発明の一実施形態によるイメージ統合処理の一例を示す第１の図である。
【図１１】本発明の一実施形態によるイメージ統合処理の一例を示す第２の図である。
【図１２】本発明の一実施形態によるイメージ統合処理の一例を示す第３の図である。
【図１３】本発明の一実施形態によるイメージ統合処理の一例を示す第４の図である。
【図１４】レイヤー化されたイメージの更新について説明する第１の図である。
【図１５】レイヤー化されたイメージの更新について説明する第２の図である。
【図１６】レイヤー化されたイメージの更新について説明する第３の図である。
【図１７】レイヤー化されたイメージの更新について説明する第４の図である。
【図１８】レイヤー化されたイメージの更新について説明する第５の図である。
【図１９】レイヤー化されたイメージの更新について説明する第６の図である。
【図２０】コンテナ型仮想化におけるレイヤー構成の一例を示す図である。
【図２１】本発明の一実施形態におけるコンテナイメージ統合システムの最小構成を示す図である。
【図２２】本発明の一実施形態におけるコンテナイメージ統合システムのハードウェア構成の一例を示す図である。
【発明を実施するための形態】
【００２０】
以下、一実施形態に係るコンテナイメージ統合システムについて図１〜図２２を参照して説明する。
（コンテナイメージ統合システムの構成）
図１は、本発明の一実施形態によるコンテナイメージ統合システムの一例を示す図である。
図１に示すようにコンテナイメージ統合システム１は、コンテナイメージ統合装置１００と、統合イメージ保持部２００と、コンテナ実行装置３００と、を含む。コンテナイメージ統合装置１００と統合イメージ保持部２００はネットワークを介して接続されている。統合イメージ保持部２００とコンテナ実行装置３００はネットワークを介して接続されている。
【００２１】
コンテナイメージ統合装置１００は、コンテナ実行装置３００で実行されるコンテナのイメージを、後述する統合処理によって作成する。統合処理によって作成されたメージを統合イメージと呼ぶ。コンテナイメージ統合装置１００は、作成した統合イメージを統合イメージ保持部２００に保存する。統合イメージ保持部２００は、ストレージ装置である。統合イメージ保持部２００は、コンテナイメージ統合装置１００が作成した統合イメージを保持する。コンテナ実行装置３００では、コンテナランタイムが動作している。コンテナ実行装置３００は、統合イメージ保持部２００から、実行対象の統合イメージをダウンロードして、その統合イメージに基づくコンテナを起動する。そのコンテナ上では、アプリケーションが実行される。統合イメージ保持部２００は、一般的なコンテナレジストリと同様の構成を有する。コンテナ実行装置３００は、一般的なコンテナランタイムと同様の構成を有する。
【００２２】
コンテナイメージ統合装置１００は、イメージ保持部１０１と、イメージ作成部１０２と、イメージ統合部１０３と、イメージ互換性確認部１０４と、イメージ間競合解決部１０５とを有する。
【００２３】
イメージ保持部１０１は、統合イメージに基づくコンテナ上で動作するアプリケーションを構成する各コンポーネントのイメージを保持する。コンポーネントとは、統合イメージの各レイヤーに対応するソフトウェアである。各コンポーネントのイメージをコンポーネントイメージ又はレイヤー別イメージと呼ぶ。例えば、コンテナ上でアプリケーション４が動作するために、OS１、ライブラリ２、ミドルウェア３、アプリケーション４のインストールが必要な場合、アプリケーション４を構成する各コンポーネントとは、OS１、ライブラリ２、ミドルウェア３、アプリケーション４である。また、各コンポーネントのコンポーネントイメージとは、OS１のコンポーネントイメージ（レイヤー１）、ライブラリ２のコンポーネントイメージ（レイヤー２）、ミドルウェア３のコンポーネントイメージ（レイヤー３）、アプリケーション４のコンポーネントイメージ（レイヤー４）である。OS１のコンポーネントイメージは、OS１がインストールされたベースイメージである。ライブラリ２のコンポーネントイメージは、OS１、ライブラリ２をこの順にインストールしてできたイメージである。ミドルウェア３のコンポーネントイメージは、OS１、ライブラリ２、ミドルウェア３をこの順にインストールしてできたイメージである。アプリケーション４のコンポーネントイメージは、OS１、ライブラリ２、ミドルウェア３、アプリケーション４をこの順にインストールしてできたイメージである。本実施形態では、アプリケーション４が動作する統合イメージを作成するために、これら４つ（レイヤー１〜４）の独立したコンポーネントイメージを作成し、それぞれを個別に管理する。
【００２４】
また、各コンポーネントイメージに含まれるファイルの場所が独立していれば、各レイヤーのコンポーネントイメージを個別に更新しておき、各コンポーネントイメージから必要なファイルだけを抽出して、作成対象のコンテナイメージにコピーして、統合イメージを作成することができる。この様子を図２〜図４に示す。図２〜図４は、それぞれレイヤー２〜４のコンポーネントイメージである。各コンポーネントイメージの最上位レイヤーの実線で規定された範囲は、統合イメージに必要なファイルを表している。これらのファイルだけを抽出して組み合わせることによって、図５に例示するように、図２０に例示するものに比べ、サイズの小さな統合イメージを作成することができる。
【００２５】
ただし、必要なファイルを統合イメージにコピーする際には、各コンポーネントの互換性が保たれていることの確認、各コンポーネントのファイルの場所が完全には独立していない場合は、競合したファイルの解決方法を決めておく必要がある。そこで、本実施形態では、各コンポーネントについて、コンポーネントイメージに含まれる統合イメージに必要なファイルの場所、コンポーネントが依存する他のレイヤー（例えば、下位のレイヤー）のコンポーネントのバージョン情報、ファイルが競合した場合の解決方法を、次に説明するコンポーネントイメージの構成定義情報に定義しておき、この定義に基づいてチェックを行う。
【００２６】
イメージ保持部１０１は、コンポーネントイメージの構成定義情報を保持する。構成定義情報は、次の情報を含む。
（１）name：コンポーネントイメージのイメージ名
（２）version：コンポーネントイメージに含まれるコンポーネントのバージョン
（３）depends：依存するコンポーネントのイメージ名と互換性のあるバージョン範囲
（４）includes：コンポーネントイメージに含まれる統合イメージにコピーするファイルの場所
（５）excludes：コンポーネントイメージに含まれる、includesで指定されたファイルから除外する（統合イメージにコピーしない）ファイルの場所
（６）resolver:依存するコンポーネントのイメージに含まれるファイルと競合した場合の解決方法（上書き、コピーしない、内容をマージする等）
（７）after-script:イメージ統合後に実行する処理
これらの内、name、version、includesは必須の情報で、それ以外はオプショナルな情報である。
【００２７】
構成定義情報は、イメージ保持部１０１に、nameとversionの組をキーにしたテーブルＴ１００として保持してもよいし、コンポーネントイメージ自体のメタデータとして保持して、イメージ保持部１０１に保存してもよい。
テーブルＴ１００は、name、versionをキーにして、depends、includes、excludes、resolver、after-scriptの各列を持つ。テーブルＴ１００を図６に例示する。
メタデータとして保持する場合、イメージ作成に使用するイメージ定義ファイルＦ１００に構成定義情報を記載する。イメージ定義ファイルＦ１００とは、Dockerであれば、Dockerfileである。Dockerfileでは、LABEL命令によって、メタデータをイメージに持たせることができる。イメージ定義ファイルＦ１００の例を図７に示す。
【００２８】
統合イメージが、OS１、ライブラリ２、ミドルウェア３、アプリケーション４の4つのコンポーネントによって構成される場合、各コンポーネントイメージの構成定義情報は、例えば、以下のようになる。
（OS１のコンポーネントイメージ）
Name：some-os
version：7.3
includes：/*
【００２９】
（ライブラリ２のコンポーネントイメージ）
name：libaaa
version：1.0
depends：some-os (7.1 ≦ version ＜ 8.0)
includes：/usr/lib/libaaa/*
【００３０】
（ミドルウェア３のコンポーネントイメージ）
name：app-server
version：10.1
depends：libaaa (1.0 ≦ version ＜ 2.0)
includes：/opt/AppServer/*
excludes：/opt/AppServer/applications/*
after-script：/opt/AppServer/bin/after-patch.sh
【００３１】
（アプリケーション４のコンポーネントイメージ）
name：app
version：2.0
depends：app-server (10.0 ≦ version ＜ 11.0)
includes：/opt/AppServer/applications/MyApp/*, /opt/AppServer/config.xml
resolver：overwrite
【００３２】
イメージ保持部１０１は、構成定義情報をイメージ自体に持たせる場合は、一般的なコンテナレジストリと同じ構成である。構成定義情報をイメージとは別に保持する場合は、イメージ保持部１０１は、一般的なコンテナレジストリに加え、テーブルＴ１００をさらに保持する。
【００３３】
イメージ作成部１０２は、イメージ定義ファイルＦ１００に基づいて、コンテナ上で動くアプリケーションを構成する各コンポーネントのコンポーネントイメージを作成し、イメージ保持部１０１に保存する。また、イメージ作成部１０２は、各コンポーネントイメージにパッチを適用する等して、それぞれを最新の状態に更新する。イメージ作成部１０２は、更新後の各コンポーネントイメージをイメージ保持部１０１に保存する。
【００３４】
イメージ統合部１０３は、統合イメージ定義ファイルＦ２００（統合定義情報）に基づいて、コンテナ上で動くアプリケーション４を構成する各コンポーネントのコンポーネントイメージをイメージ保持部１０１から取得し、各コンポーネントイメージを統合する統合処理を行って、統合イメージを作成する。イメージ統合部１０３は、作成した統合イメージを、統合イメージ保持部２００に保存する。統合処理とは、各レイヤーのコンポーネントイメージから必要なファイルを抽出して、統合イメージの同じ場所へコピーする処理である。これは、一般にイメージを作成する処理のように、OS１のイメージにライブラリ２、ミドルウェア３、アプリケーション４を順にインストールして最終的なイメージを作成する方法とは異なる。
【００３５】
統合イメージ定義ファイルＦ２００は、統合イメージの作成に必要なコンポーネントイメージのname、versionの組を、統合処理を行う順に記載したファイルである。記載した順番にイメージが統合（ファイルがコピー）される。統合イメージ定義ファイルＦ２００の一例を図８に示す。統合イメージ定義ファイルＦ２００は、例えば、イメージ統合部１０３が有していてもよいし、コンテナイメージ統合装置１００の図示しない記憶部に保存されていてもよい。
【００３６】
イメージ統合部１０３は、イメージの統合処理時に、イメージ互換性確認部１０４を使って、イメージ間の互換性を確認し、イメージの統合処理時に、イメージ間競合解決部１０５を使って、イメージ間のファイルの競合を解決する。
【００３７】
イメージ互換性確認部１０４は、コンポーネントイメージの互換性情報（バージョン情報）をもとに、イメージ間の互換性を確認する。イメージ互換性確認部１０４は、例えば、アプリケーション４に適合するバージョンのOS１、ライブラリ２、ミドルウェア３の各コンポーネントイメージが統合処理におけるファイルのコピー元として選択されているかどうかを確認する。
【００３８】
イメージ間競合解決部１０５は、コンポーネントイメージのファイルの場所の情報（パス情報）と競合解決方法の情報（後述するresolverの値）をもとに、イメージ間のファイルの競合を解決する。例えば、統合イメージ定義ファイルＦ２００にて、ライブラリ２、ミドルウェア３の順に処理するよう記載されていて、ライブラリ２のファイルパスとミドルウェア３のファイルパスが一致（競合）する場合、競合解決方法の情報に「上書き」が設定されていれば、イメージ間競合解決部１０５は、ミドルウェア３のコンポーネントイメージに含まれるファイルの内容で、ライブラリ２のコンポーネントイメージに含まれるファイルの内容を上書きする。
【００３９】
次にコンテナイメージ統合システム１の動作について説明する。以下、上記の説明で使用した下位から順にOS１、ライブラリ２、ミドルウェア３、アプリケーション４で構成される統合イメージを作成する場合を例に説明を行う。また、イメージ定義ファイルＦ１００、統合イメージ定義ファイルＦ２００は、予め所定の位置に用意されているとする。
【００４０】
（コンポーネントイメージの作成処理）
最初にコンポーネントイメージの作成処理について図９を参照して説明する。
図９は、本発明の一実施形態によるコンポーネントイメージの作成処理の一例を示す図である。
まず、イメージ作成部１０２が、イメージ定義ファイルＦ１００に基づいて、イメージを作成する（Ｓ１０１）。イメージ定義ファイルＦ１００およびそれに基づくイメージの作成処理は、一般的なコンテナランタイムと同様である。例えば、イメージ作成部１０２は、図７に例示するイメージ定義ファイルＦ１００に基づいて、ミドルウェア３（AppServer 10.1）のコンポーネントイメージを作成する。同様にイメージ作成部１０２は、他のレイヤー１，２，４のコンポーネントイメージを作成する。
【００４１】
なお、各コンポーネントのイメージを作成する際、各イメージの最上位レイヤー以外の下位レイヤーのコンポーネントは必ずしも統合イメージで必要とされるバージョンである必要はなく、統合対象のバージョンと互換性があればよい。例えば、レイヤー４のコンポーネントイメージは、ミドルウェア３のバージョン「10.0」のコンポーネントイメージに対してアプリケーション４を配備してアプリケーションのイメージを作成しておき、統合処理時にはバージョン「10.1」のミドルウェア３がインストールされたコンポーネントイメージと統合することで、バージョン「10.1」のミドルウェア３上にアプリケーション４を配備した統合イメージを作成することができる。
【００４２】
次にイメージ作成部１０２は、作成したコンポーネントイメージをイメージ保持部１０１に保存する（Ｓ１０２）。なお、構成定義情報をテーブルＴ１００に保持する場合には、各コンポーネントのname、version等の情報をテーブルＴ１００へ登録する。構成定義情報をイメージ定義ファイルＦ１００に記載する場合は、イメージ定義ファイルＦ１００に基づいて作成されたコンポーネントイメージにそれらの情報がメタデータとして保持されるため、追加の処理は不要である。
【００４３】
（統合イメージの作成処理：統合処理）
次に図１０〜１３を用いて統合処理の流れについて説明する。
図１０〜図１３は、それぞれ、本発明の一実施形態によるイメージ統合処理の一例を示す第１の図〜第４の図である。
まず、図１０を参照する。イメージ統合部１０３が、統合イメージ定義ファイルＦ２００を読み込み、コンポーネントのイメージ名(name)とバージョン(version)の組のリストcomponentNames（リスト１）を取得する（Ｓ２０１）。componentNamesの各要素をcomponentNameとする。
次にイメージ統合部１０３は、初期状態として、コンポーネントイメージ用の空のリストcomponentImagesとその構成定義情報用の空のリストcomponentImageInfosを取得する（Ｓ２０２）。
【００４４】
次にイメージ統合部１０３は、componentNames（リスト１）の各要素（componentName）に対して、以下のＳ２０４〜Ｓ２０６の処理を繰り返す（Ｓ２０３）。
イメージ統合部１０３は、イメージ保持部１０１から、componentNameのイメージ名(name)とバージョン(version)が一致するコンポーネントイメージを取得する(Ｓ２０４)。イメージ統合部１０３は、取得したコンポーネントイメージをcomponentImageオブジェクトにセットする。
次にイメージ統合部１０３は、取得したコンポーネントイメージのメタデータ、またはイメージ保持部１０１のテーブルＴ１００の構成定義情報の中から「depends」、「includes」、「excludes」、「resolver」、「after-script」の情報の組を取得する（Ｓ２０５）。イメージ統合部１０３は、取得した情報の組をcomponentImageInfoオブジェクトにセットする。
次にイメージ統合部１０３は、componentImageをcomponentImagesに追加し、componentImageInfoをcomponentImageInfosに追加する（Ｓ２０６）。
【００４５】
続いて図１１を参照する。イメージ統合部１０３は、componentImageInfosをイメージ互換性確認部１０４に渡して、コンポーネント間の互換性確認を指示する（Ｓ２０７）。
イメージ互換性確認部１０４は、componentImageInfosの各要素に対して、以下のＳ２０９〜Ｓ２１４の処理を繰り返す（Ｓ２０８）。繰り返しにおけるcomponentImageInfosの要素をcomponentImageInfoとする。
イメージ互換性確認部１０４は、componentImageInfoの「depends」から依存コンポーネント名dependedComponentNameを取得する（Ｓ２０９）。例えば、イメージ互換性確認部１０４は、ライブラリ２の「depends」から「some-os」をdependedComponentNameとして取得する。
次にイメージ互換性確認部１０４は、componentImageInfosからコンポーネント名dependedComponentNameに合致するコンポーネントイメージのcomponentImageInfo（dependedComponentInfoとする。）を取得する（Ｓ２１０）。例えば、イメージ互換性確認部１０４は、componentImageInfosから「some-os」のcomponentImageInfoを取得し、dependedComponentInfoオブジェクトにセットする。
次にイメージ互換性確認部１０４は、Ｓ２０９で取得したcomponentImageInfoのdependsから互換性のあるバージョン範囲VersionRangeを取得し、compatibleVersionRangeとする（Ｓ２１１）。例えば、イメージ互換性確認部１０４は、ライブラリ２の「depends」から「some-os」のバージョン範囲「（7.1≦version＜8.0）」を取得し、compatibleVersionRangeオブジェクトにセットする。
次にイメージ互換性確認部１０４は、dependedComponentInfoのバージョン(version)が、compatibleVersionRangeの範囲に含まれるか確認する（Ｓ２１２）。例えば、上記の例であれば、「some-os」のバージョン「7.3」が、「（7.1≦version＜8.0）」に含まれるかどうかを判定する。
【００４６】
compatibleVersionRangeの範囲に含まれない場合（Ｓ２１２；Ｎｏ）、イメージ互換性確認部１０４は、確認失敗という結果をイメージ統合部１０３に返す（Ｓ２１３）。イメージ統合部１０３は、処理結果をイメージ統合処理エラーとして統合処理を終了する（Ｓ２１４）。
【００４７】
compatibleVersionRangeに含まれる場合（Ｓ２１２；Ｙｅｓ）、イメージ互換性確認部１０４は、ループ処理を継続し、他のコンポーネントイメージについても互換性の確認を行う。
全レイヤーの互換性確認が成功した場合、イメージ互換性確認部１０４は、確認成功という結果をイメージ統合部１０３に返す（Ｓ２１５）。イメージ統合部１０３は、処理を継続する（Ｓ２１６）。
【００４８】
続いて図１２を参照する。次にイメージ統合部１０３は、図１０のＳ２０６で作成したcomponentImagesとcomponentImageInfosの各要素を組にしたリスト２について、リスト２の各要素に対して、以下のＳ２１８〜Ｓ２２９処理を繰り返す（Ｓ２１７）。繰り返しにおけるcomponentImagesの要素をcomponentImageとし、componentImageInfosの要素をcomponentImageInfoとする。
イメージ統合部１０３は、初期状態として、現在の統合イメージimageの空のイメージと、現在の統合イメージのファイルの一覧filesの空のリストを作成する（Ｓ２１８）。
次にイメージ統合部１０３は、componentImageInfoのincludesにあるファイルのうち、excludesにあるファイルを除いたファイル（ファイルパス）の一覧を取得する（Ｓ２１９）。これをcomponentFilesとする。
【００４９】
次にイメージ統合部１０３は、componentFilesの各要素に対して以下のＳ２２１〜Ｓ２２９の処理を繰り返す（Ｓ２２０）。繰り返しにおけるcomponentFilesの要素をcomponentFileとする。
イメージ統合部１０３は、componentImageからcomponentFileにあるファイルの内容を読み込み、その内容をcomponentFileContentオブジェクトにセットする（Ｓ２２１）。
イメージ統合部１０３は、componentFileがfilesに含まれているか確認する（Ｓ２２２）。
【００５０】
filesに含まれている場合（Ｓ２２２；Ｙｅｓ）、イメージ統合部１０３は、imageからcomponentFileにあるファイルの内容を読み込み、fileContentオブジェクトにセットする（Ｓ２２３）。
次にイメージ統合部１０３は、イメージ間競合解決部１０５に、ファイルの競合の解決に必要な各種情報、例えば、componentFile（コピー元のファイルのパス情報）、fileContent（既に統合イメージに存在するファイルの内容）、componentFileContent（コピー元のファイルの内容）、componentImageInfoの「resolver」の情報を渡す（Ｓ２２４）。
次にイメージ間競合解決部１０５は、resolverの値に基づいて、ファイルの競合を解決する（Ｓ２２５）。例えば、resolverがoverwriteであれば、イメージ間競合解決部１０５は、fileContentをcomponentFileContentで上書きする。例えば、resolverの値が、現在の統合イメージに存在するfileContentの内容を優先することを意味する値であれば、イメージ間競合解決部１０５は、fileContentを優先し、componentFileContentを破棄する。例えば、resolverの値が、fileContentとcomponentFileContentの内容をマージすることを意味する値であれば、イメージ間競合解決部１０５は、fileContentにcomponentFileContentを追加する。
resolverの値が存在しない場合、既定の動作とする。例えば、既定の動作を解決失敗として、処理を終了してもよい。イメージ間競合解決部１０５は、競合解決後のファイルの内容をresolvedFileContentオブジェクトにセットする。
次にイメージ間競合解決部１０５は、resolvedFileContentをイメージ統合部１０３に返す（Ｓ２２６）。
イメージ統合部１０３は、resolvedFileContentの内容をimageのファイルパスcomponentFileに書き込む（Ｓ２２７）。
【００５１】
filesに含まれていない場合（Ｓ２２２；Ｎｏ）、イメージ統合部１０３は、componentFileContentの内容をimageのファイルパスcomponentFileに書き込む（Ｓ２２８）。イメージ統合部１０３は、リストfilesにcomponentFileを追加する（Ｓ２２９）。
【００５２】
続いて図１３を参照する。Ｓ２１７、Ｓ２２０のループ処理が完了すると、次にイメージ統合部１０３は、componentImageInfosの各要素に対して、以下のＳ２３０の処理（処理２）を繰り返す（Ｓ２２９）。繰り返しにおけるcomponentImageInfosの要素をcomponentImageInfoとする。
イメージ統合部１０３は、componentImageInfoのafter-scriptの値を取得し、値が存在すれば、after-scriptに書かれた処理をimageに対して実行し、imageを更新する（Ｓ２３０）。
最後にイメージ統合部１０３は、統合イメージimageを統合イメージ保持部２００に保存する（Ｓ２３１）。これにより、各レイヤーのコンポーネントイメージから必要なファイルをコピーすることによって統合イメージが作成される。
【００５３】
本実施形態によれば、コンテナ型仮想化のイメージの作成において、作成対象のイメージ(統合イメージ)を構成するレイヤー別にコンポーネントイメージを作成し、個別に管理する。そして、イメージ統合部１０３が、コンポーネントイメージやテーブルＴ１００に設定されたファイルパス情報を用いて、複数のコンポーネントイメージの統合処理を行う。コンポーネントイメージ間でファイルが競合する場合は、イメージ間競合解決部１０５が、その競合状態を解決する。また、イメージ互換性確認部１０４が、コンポーネントイメージの互換性をチェックして統合の可否を判断する。これらの構成により、作成対象のイメージを構成する各コンポーネントのイメージの再利用性を担保しつつ、アプリケーションの実行環境のイメージ（統合イメージ）を作成することができる。
【００５４】
本実施形態によれば、レイヤー別にコンポーネントイメージを作成し、イメージ統合部１０３が、各コンポーネントイメージから、そのコンポーネントの必要なファイルをコピーして、統合イメージを作成するので、各コンポーネントイメージを独立したファイルとして保持し、個別に更新することができる。例えば、ミドルウェア３に対するパッチ適用において、一般的なコンテナイメージへのパッチの適用方法として説明した（方法１）、（方法２）のようなイメージ作り直し（インストールのやり直し）といった手間を省き、ミドルウェア３のコンポーネントイメージへのパッチ適用処理のみを行って、最新のミドルウェア３の状態を反映したコンポーネントイメージとして管理することができる。また、コンポーネントイメージは、コンポーネント単位で作成されているので、再利用が容易である。
【００５５】
また、各コンポーネントイメージから必要なファイルを統合イメージにコピーするという構成により、各コンポーネントイメージにおいては、そのコンポーネントが依存する下位のコンポーネントのバージョンを統合時のバージョンと合わせる必要がなく、下位コンポーネントについては互換性のあるバージョンの範囲内で任意に選択してよい。
【００５６】
また、各コンポーネントイメージには、パッチ適用などにより、不要となったファイルやパッチ適用によって作成された中間レイヤーが蓄積されるが、統合イメージには、必要なファイルだけをコピーするため、統合イメージには、不要なファイルが残らず、統合イメージのサイズを小さく抑えることができる。
【００５７】
上記の実施形態では、コンテナイメージ統合装置１００がイメージ保持部１０１およびイメージ作成部１０２を有することとしたが、イメージ保持部１０１およびイメージ作成部１０２は、コンテナイメージ統合装置１００とは独立した別の装置に設けてもよい。この構成の場合、コンテナイメージ統合装置１００と別の装置とは、ネットワークを介して接続される。
【００５８】
また、イメージの統合処理時の競合解決を常に上書きで解決する場合、イメージ間競合解決部１０５は不要である。この構成の場合、図１２のＳ２２２〜Ｓ２２９の処理は、Ｓ２２８、Ｓ２２９だけでよい。
【００５９】
なお、一度、本実施形態の統合処理によって、統合イメージを作成した後で、ミドルウェア３にパッチを適用する場合は、イメージ作成部１０２が、ミドルウェア３のコンポーネントイメージにパッチ適用処理を行う。そして、イメージ統合部１０３が、レイヤー１〜４のコンポーネントイメージ（レイヤー３は、パッチ適用後のコンポーネントイメージ）を用いて、再び、図１０〜１３の処理を行って統合イメージを再作成する。このような処理であれば、再インストールによる作り直しを行わなくてよいので、（方法１）や（方法２）の処理に比べ、統合イメージの管理コストを低減することができる。
【００６０】
また、（方法１）や（方法２）の方法では、イメージの作り直しにおいて、各設定ファイルなどを再度設定し直さなければならないが、本実施形態において、統合イメージの設定内容を、レイヤー１〜４等の各コンポ―ネントイメージに対して反映させておくことで、パッチ適用などが生じた際の統合イメージの再作成の処理コストをさらに低減することができる。
【００６１】
図２１は、本発明の一実施形態におけるコンテナイメージ統合システムの最小構成を示す図である。
図２１に示すようにコンテナイメージ統合システム１は、少なくとも複数のレイヤー別イメージ１００１ａ，１００１ｂとイメージ統合部１０３とを有している。
レイヤー別イメージ１００１ａ，１００１ｂは、複数のレイヤーで構成される作成対象のコンテナイメージである統合イメージのレイヤーごとに作成された、各レイヤーのコンポーネントのコンテナイメージである。図２１に示すレイヤー別イメージ１００１ａ，１００１ｂは一例であって、コンテナイメージ統合システム１は、３つ以上のレイヤー別イメージを有していてもよい。
イメージ統合部１０３は、レイヤー別イメージ１００１ａ，１００１ｂの構成定義情報（図６、７に例示）に基づいて、レイヤー別イメージ１００１ａ，１００１ｂから作成対象のコンテナイメージへファイルをコピーすることにより、複数のレイヤー別イメージ１００１ａ，１００１ｂを統合した統合イメージを作成する。
【００６２】
図２２は、本発明の一実施形態におけるコンテナイメージ統合システムのハードウェア構成の一例を示す図である。
コンピュータ９００は、ＣＰＵ９０１、主記憶装置９０２、補助記憶装置９０３、入出力インタフェース９０４、通信インタフェース９０５を備える。上述のコンテナイメージ統合装置１００は、コンピュータ９００に実装される。そして、上述した各機能部の動作は、プログラムの形式で補助記憶装置９０３に記憶されている。ＣＰＵ９０１は、プログラムを補助記憶装置９０３から読み出して主記憶装置９０２に展開し、当該プログラムに従って上記処理を実行する。また、ＣＰＵ９０１は、プログラムに従って、記憶領域を主記憶装置９０２に確保する。また、ＣＰＵ９０１は、プログラムに従って、処理中のデータを記憶する記憶領域を補助記憶装置９０３に確保する。
【００６３】
なお、少なくとも１つの実施形態において、補助記憶装置９０３は、一時的でない有形の媒体の一例である。一時的でない有形の媒体の他の例としては、入出力インタフェース９０４を介して接続される磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、半導体メモリ等が挙げられる。また、このプログラムが通信回線によってコンピュータ９００に配信される場合、配信を受けたコンピュータ９００が当該プログラムを主記憶装置９０２に展開し、上記処理を実行しても良い。また、当該プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、当該プログラムは、前述した機能を補助記憶装置９０３に既に記憶されている他のプログラムとの組み合わせで実現するもの、いわゆる差分ファイル（差分プログラム）であっても良い。
【００６４】
その他、本発明の趣旨を逸脱しない範囲で、上記した実施の形態における構成要素を周知の構成要素に置き換えることは適宜可能である。また、この発明の技術範囲は上記の実施形態に限られるものではなく、本発明の趣旨を逸脱しない範囲において種々の変更を加えることが可能である。
【符号の説明】
【００６５】
１・・・コンテナイメージ統合システム
１００・・・コンテナイメージ統合装置
１０１・・・イメージ保持部
１０２・・・イメージ作成部
１０３・・・イメージ統合部
１０４・・・イメージ互換性確認部
１０５・・・イメージ間競合解決部
２００・・・統合イメージ保持部
３００・・・コンテナ実行装置
９００・・・コンピュータ
９０１・・・ＣＰＵ
９０２・・・主記憶装置
９０３・・・補助記憶装置
９０４・・・入出力インタフェース
９０５・・・通信インタフェース
【要約】      （修正有）【課題】複数のコンテナイメージを統合して、目標とするコンテナイメージを構築する方法を提供する。【解決手段】コンテナイメージ統合システム１において、コンテナイメージ統合装置１００は、複数のレイヤーで構成される作成対象のコンテナイメージである統合イメージのレイヤーごとに作成された、レイヤーのコンポーネントのコンテナイメージであるレイヤー別イメージと、レイヤー別イメージの構成定義情報に基づいて、レイヤー別イメージから統合イメージへファイルをコピーすることにより、複数のレイヤー別イメージを統合して、統合イメージを作成するイメージ統合部１０３とを備える。【選択図】図１【図１】
0006791323.tif 000002
【図２】
0006791323.tif 000003
【図３】
0006791323.tif 000004
【図４】
0006791323.tif 000005
【図５】
0006791323.tif 000006
【図６】
0006791323.tif 000007
【図７】
0006791323.tif 000008
【図８】
0006791323.tif 000009
【図９】
0006791323.tif 000010
【図１０】
0006791323.tif 000011
【図１１】
0006791323.tif 000012
【図１２】
0006791323.tif 000013
【図１３】
0006791323.tif 000014
【図１４】
0006791323.tif 000015
【図１５】
0006791323.tif 000016
【図１６】
0006791323.tif 000017
【図１７】
0006791323.tif 000018
【図１８】
0006791323.tif 000019
【図１９】
0006791323.tif 000020
【図２０】
0006791323.tif 000021
【図２１】
0006791323.tif 000022
【図２２】
0006791323.tif 000023