特開 2024-162883 計算機環境構築システム及び計算機環境構築方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024162883

(43)【公開日】2024-11-21

(54)【発明の名称】計算機環境構築システム及び計算機環境構築方法

(51)【国際特許分類】

   G06F 8/60 20180101AFI20241114BHJP

【ＦＩ】

G06F8/60

【審査請求】未請求

【請求項の数】12

【出願形態】ＯＬ

(21)【出願番号】P 2023078847

(22)【出願日】2023-05-11

(71)【出願人】

【識別番号】000005108

【氏名又は名称】株式会社日立製作所

(74)【代理人】

【識別番号】110000925

【氏名又は名称】弁理士法人信友国際特許事務所

(72)【発明者】

【氏名】金 成昊

(72)【発明者】

【氏名】角尾 晋一

(72)【発明者】

【氏名】大塚 祐策

(72)【発明者】

【氏名】西山 泰史

(72)【発明者】

【氏名】綿引 博章

【テーマコード（参考）】

5B376

【Ｆターム（参考）】

5B376AA14

5B376AA32

5B376AB01

5B376AB13

5B376AB43

(57)【要約】

【課題】修正対象を容易に明確化可能な、既存のソフトウェア資産の移行先の計算機環境を提供する。
【解決手段】本発明の一態様の仮想環境構築システム１は、新たな計算機環境への移行対象のアプリケーションを構成する各要素間における論理的関係及び依存性の情報に基づいて、要素を複数のレイヤのうちのいずれかのレイヤに割り当てる階層化情報生成部１０と、複数のレイヤを含むコンテナを生成して、該コンテナを実環境におけるノードに配備する配備・更新管理部２０と、を備える。
【選択図】図３

【特許請求の範囲】

【請求項1】

新たな計算機環境への移行対象のアプリケーションを構成する各要素間における論理的関係及び依存性の情報に基づいて、前記要素を複数のレイヤのうちのいずれかのレイヤに割り当てる階層化情報生成部と、
複数の前記レイヤを含む独立実行環境を生成して、該独立実行環境を実環境におけるノードに配備する配備管理部と、を備えた
計算機環境構築システム。

【請求項2】

前記配備管理部は、前記各要素間における論理的関係及び依存性の情報に基づいて、前記ノードに配置された前記要素を特定して修正する
請求項１に記載の計算機環境構築システム。

【請求項3】

前記配備管理部は、前記独立実行環境を、前記アプリケーションのパッケージの単位で生成する
請求項２に記載の計算機環境構築システム。

【請求項4】

前記階層化情報生成部は、前記アプリケーションのソースコードの修正履歴の情報に基づいて、アプリケーションを構成する各要素間における論理的関係及び依存性の情報、並びに、前記要素の前記レイヤへの割り当て結果の情報を記した階層構成テーブルを生成し、
前記配備管理部は、前記階層構成テーブルに記載の情報に基づいて前記独立実行環境の前記ノードへの配備、及び、前記独立実行環境に配備された前記要素の修正を行う
請求項３に記載の計算機環境構築システム。

【請求項5】

複数の前記レイヤは、第１のレイヤ、前記第１のレイヤの上に配置される第２のレイヤ、及び、前記第２のレイヤの上に配置される第３のレイヤを含み、
前記階層化情報生成部は、複数の前記パッケージによって共有される設定に関する前記要素を前記第１のレイヤに配置し、前記要素が有する機能の単位で共有される設定に関する前記要素を前記第２のレイヤに配置し、前記パッケージによって使用される設定に関する前記要素を前記第３のレイヤに配置する
請求項４に記載の計算機環境構築システム。

【請求項6】

前記論理的関係は、前記パッケージが有する機能により示される関係であり、前記依存性は、前記要素が他の要素により呼び出される場合における呼び出し元の前記要素の重複度、及び、前記要素の修正頻度により示される情報である
請求項５に記載の計算機環境構築システム。

【請求項7】

前記階層化情報生成部は、呼び出し元の前記要素の前記重複度が所定の閾値を超える前記要素を前記第１のレイヤに配置し、前記第１のレイヤに配置された前記要素のうち、前記修正頻度が所定の閾値を超える前記要素は、前記第１のレイヤから前記第２のレイヤに移動させる
請求項６に記載の計算機環境構築システム。

【請求項8】

前記配備管理部は、前記独立実行環境のうち、前記要素が有する機能毎に区切られた前記第２のレイヤの一区分に対応付けられた複数の前記独立実行環境を、一つのノードに配備する
請求項７に記載の計算機環境構築システム。

【請求項9】

前記要素は、前記アプリケーションの実行ファイル、共有ライブラリファイルを含み、
前記要素の他の要素による呼び出しは、前記共有ライブラリファイル内の関数を介して行われる
請求項８に記載の計算機環境構築システム。

【請求項10】

前記独立実行環境は、仮想化技術により形成される仮想マシンである
請求項１に記載の計算機環境構築システム。

【請求項11】

前記独立実行環境は、コンテナ型仮想化技術により仮想化されるコンテナである
請求項１に記載の計算機環境構築システム。

【請求項12】

新たな計算機環境への移行対象のアプリケーションを構成する各要素間における論理的関係及び依存性の情報に基づいて、前記要素を複数のレイヤのうちのいずれかのレイヤに割り当てる手順と、
複数の前記レイヤを含む独立実行環境を生成して、該独立実行環境を実環境におけるノードに配備する手順と、を含む
計算機環境構築方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、計算機環境構築システム及び計算機環境構築方法に関する。

【背景技術】

【0002】

従来、制御システム又はインフラシステム向け等の既存ソフトウェア資産（リソース）を、新しいハードウェアやＯＳ（Operating System）、又は、仮想化環境等の新しいＩＴ技術環境へ移行することにより、既存財産の活用を図ることが行われている。

【0003】

仮想化技術を用いたシステムの構築について、例えば、特許文献１に、物理的なノードの中に、仮想的なコンピュータ（バーチャル（仮想）マシン）を作り出し、同じ物理ノード内において複数の異なるＯＳを並列に実行する技術が開示されている。特許文献１に記載の技術によれば、物理デバイスを効率よく使用することが可能となり、リソース管理コストの低減が期待される。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特許第７１１８２３０号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

ところで、近年、既存のソフトウェア資産におけるソフトウェアの機能又はパッケージ等の実行単位で独立した実行環境を形成し、形成された各実行環境を移行後の新たな計算機環境に配備することが行われている。独立した実行環境は、例えば、ソフトウェアスタックや、仮想マシン、コンテナ型仮想化技術により生成されるコンテナなどにより構築可能である。独立した各実行環境においては、ソフトウェアの実行に必要なライブラリファイルやプログラムなどが、階層化して配置される。

【0006】

したがって、実行環境の独立化の単位や、階層化の構造が適切に設定されていない場合、新環境の運用に基づくソフトウェアの修正や、新機能の追加などの作業時に、対応する修正箇所を明確化できなかったり、修正対象が膨大となってしまったりする可能性がある。

【0007】

本発明は、上記の状況を考慮してなされたものであり、本発明の目的は、修正対象を容易に明確化可能な、既存のソフトウェア資産の移行先の計算機環境を提供することにある。

【課題を解決するための手段】

【0008】

本発明の一態様に係る計算機環境構築システムは、新たな計算機環境への移行対象のアプリケーションを構成する各要素間における論理的関係及び依存性の情報に基づいて、要素を複数のレイヤのうちのいずれかのレイヤに割り当てる階層化情報生成部と、複数のレイヤを含む独立実行環境を生成して、該独立環境を実環境におけるノードに配備する配備管理部と、を備える。

【発明の効果】

【0009】

本発明の少なくとも一態様によれば、修正対象を容易に明確化可能な、既存のソフトウェア資産の移行先の計算機環境が提供される。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

【図面の簡単な説明】

【0010】

【図1】本発明の第１の実施形態に係るコンテナ化対象の既存のミドルウェアのパッケージ構成例を示す図である。

【図2】本発明の第１の実施形態に係るコンテナイメージの構成例を示す図である。

【図3】本発明の第１の実施形態に係る仮想化環境構築システムの機能構成例を示すブロック図である。

【図4】本発明の第１の実施形態に係る仮想化環境構築システムのハードウェア構成例を示すブロック図である。

【図5】本発明の第１の実施形態に係るライブラリリストの構成例を示す図である。

【図6】本発明の第１の実施形態に係る階層構成テーブルの構成例を示す図である。

【図7】本発明の第１の実施形態に係るライブラリリスト生成部によるライブラリリストの生成処理の手順の例を示すフローチャートである。

【図8】本発明の第１の実施形態に係る分類部による階層構成テーブルの生成処理の手順の例を示すフローチャートである。

【図9】本発明の第１の実施形態に係る階層構成テーブルの生成過程の例を示す図である。

【図10】本発明の第１の実施形態に係るイメージ生成部によるコンテナイメージ生成処理の手順の例を示すフローチャートである。

【図11】本発明の第１の実施形態に係るイメージ生成部によるコンテナイメージ生成処理の手順の例を示すフローチャートである。

【図12】本発明の第１の実施形態に係る各レイヤに配備されるビルド後生成物名が記載された設計ファイルの例を示す図である。

【図13】本発明の第１の実施形態に係るコンテナイメージの生成過程の例を示す図である。

【図14】本発明の第１の実施形態に係る配備判断部による配備判断処理の手順の例を示すフローチャートである。

【図15】本発明の第１の実施形態に係る配備・更新管理部２０の更新管理部２３による更新管理処理の手順の例を示すフローチャートである。

【図16】本発明の第２の実施形態に係るソフトウェアスタックの構成例を示す図である。

【図17】本発明の第２の実施形態に係る計算機環境構築システムの機能構成例を示すブロック図である。

【図18】本発明の第２の実施形態に係るソフトウェアスタックの生成過程の例を示す図である。

【発明を実施するための形態】

【0011】

以下、本発明の実施形態を、図を用いて説明する。各図において、同一の構成には同一の符号を付す。以下の記載および図面は、本発明を説明するための例示であって、説明の明確化のため、適宜、省略および簡略化がなされている。本発明は、他の種々の形態でも実施する事が可能である。特に限定しない限り、各構成要素は単数でも複数でも構わない。

【0012】

＜第１の実施形態＞
本発明の第１の実施形態では、本発明の計算機環境構築システムの一例である仮想化環境構築システムが、既存のソフトウェア資産であるミドルウェアのアプリケーションを、コンテナ型仮想化技術を用いてコンテナ化する。コンテナ型仮想化は、ホストＯＳ上に「コンテナ」と呼ばれる独立空間（独立実行環境の一例）を形成し、各独立空間においてアプリケーションの実行環境を構築する技術である。各コンテナは、論理的に分離されたホストＯＳの各リソースを共有して、それぞれが分離して動作可能であるため、ユーザは、各コンテナをあたかも個別のサーバのように扱うことができる。

【0013】

本実施形態では、例えば、製造ラインの各装置又は機器の制御を行うミドルウェアを構成する各アプリケーションをコンテナ化する場合を想定する。保守性の観点から、アプリケーションのパッケージの単位でコンテナ化することが好ましい。

【0014】

図１は、コンテナ化対象の既存のミドルウェアのパッケージ構成例を示す図である。図１に示す各ブロックはそれぞれパッケージを示し、各ブロック内の「Ｎｃ」、「Ｎｂ」等の文字は、パッケージの名称を示す。パッケージの名称の大文字部分には、パッケージの機能ごとに区分した場合における各区分に対応する文字が割り振られている。例えば、「Ｎ」は、各パッケージ間において共有される機能を提供するパッケージに割り振られ、「Ｇ」は、画像表示関連の処理を行う機能を有するパッケージに割り振られ、「Ｄ」は、データ処理を行う機能を有するパッケージに割り振られる。

【0015】

図中における矢印は、各パッケージ間における情報の入出力の方向を示す。矢印によって示されるパッケージ間の連携は、ＤＬＬ（Dynamic Link Library）ファイル（共有ライブラリファイルの一例）を介して行われる。したがって、図１に例示したミドルウェアのように、各パッケージ間の連携が密に行われる場合には、ＤＬＬファイル及びパッケージのコンテナ化を適切に行わないと、ある修正が行われた場合における修正対象のコンテナの数が、非常に多くなる等の問題が起こり得る。

【0016】

本実施形態に係る仮想化環境構築システムは、修正が行われる場合における修正対象（範囲）を容易かつ明確に特定可能とする区分によって、既存のソフトウェア資産をコンテナ化する。具体的には、仮想化環境構築システムは、既存のパッケージの機能等により示されるパッケージ同士の論理的関係や、パッケージ間における情報の入出力等により示される依存関係などの情報に基づいて、コンテナを構築する。

【0017】

図２は、コンテナイメージの構成例を示す図である。コンテナイメージは、コンテナとして実行するアプリケーションや、アプリケーションが依存するライブラリ群、コンテナ自体の設定等が記載されたバイナリデータである。そして、コマンドを用いてコンテナイメージを実行させることによりコンテナが生成され、コンテナが実行される。

【0018】

コンテナイメージは、図２に示すようにレイヤ構造をしている。図２に示すコンテナイメージは、最下層から順に、ＯＳベースイメージ、共通設定イメージ、レイヤ１の共通ライブラリイメージ、レイヤ２のグループライブラリイメージ、レイヤ３のパッケージイメージが積層されている。

【0019】

共通設定イメージには、ＯＳのレジストリの設定や、環境変数の設定、セキュリティに関する設定等が記載される。レイヤ１（第１のレイヤの一例）の共通ライブラリイメージには、すべてのパッケージにおいて共通して使用されるＤＬＬファイル及び設定内容等が記載される。

【0020】

レイヤ２（第２のレイヤの一例）のグループライブラリイメージには、画像表示機能や、データ処理機能などの、機能の各グループにおいて共通して使用されるＤＬＬファイル及び設定内容が記載される。つまり、レイヤ２のグループライブラリイメージは、パッケージが有する各機能に対応して生成される。

【0021】

レイヤ３（第３のレイヤの一例）のパッケージイメージには、単一のパッケージが依存するＤＬＬファイル及び設定内容等が記載される。図２に示すレイヤ３のパッケージイメージは、図１に示した各パッケージの単位で生成される。図２に示すレイヤ３における「Ｇａ」、「Ｇｂ」等の名称は、図１に示したパッケージの名称と対応している。そして、図２において一点鎖線の枠によって囲われた縦割りの領域が、一つのコンテナに対応する。また、一点鎖線の枠よりも広い破線の枠は、実環境における各ノード（端末装置）に搭載されるコンテナイメージの範囲を示す。

【0022】

図２に示すように、レイヤ２のグループライブラリイメージは、画像表示機能やデータ処理機能などの単位で分けて生成されるため、コンテナが実装されるノードと機能とを容易にかつ明確に対応付けることが可能となる。これにより、開発環境より修正の要請があった場合における修正範囲（修正対象のコンテナ）の特定も容易となる。

【0023】

また、図２に示すコンテナイメージでは、他のＤＬＬファイルへの依存度がより低いＤＬＬファイルが、より下位のレイヤに配置される。依存性が低いＤＬＬファイルとは、他のＤＬＬファイル又はパッケージによる参照数が多いファイル、及び／又は、修正頻度（回数）が少ないファイルである。つまり、本実施形態では、仮想化環境構築システムは、ＤＬＬファイルの依存関係やパッケージの修正履歴などの情報に基づいて、コンテナイメージを生成する。

【0024】

［仮想化環境構築システムの構成］
次に、図３を参照して、本実施形態に係る仮想化環境構築システムの構成について説明する。図３は、仮想化環境構築システム１の機能構成例を示すブロック図である。

【0025】

図３に示すように、仮想化環境構築システム１（仮想化環境構築システムの一例）は、階層化情報生成部１０と、配備・更新管理部２０と、を備える。仮想化環境構築システム１における階層化情報生成部１０及び配備・更新管理部２０は、同一の装置内に設けられてもよく、ネットワークにより接続された別々の装置にそれぞれ配備されてもよい。

【0026】

（階層化情報生成部）
階層化情報生成部１０は、ＤＬＬファイルの依存関係やパッケージの修正履歴などの情報を格納した階層構成テーブル１４を生成し、該階層構成テーブル１４の情報に基づいて、コンテナイメージを生成する。配備・更新管理部２０は、階層構成テーブル１４に記載の情報に基づいてコンテナをノードに配備するとともに、ユーザから入力された修正内容に基づいて、コンテナ内の情報を修正又は更新する。

【0027】

階層化情報生成部１０は、ライブラリリスト生成部１２（図においては「ＬＩＢリスト生成部」と表記）と、分類部１３と、階層構成テーブル１４と、イメージ生成部１５と、を備える。

【0028】

ライブラリリスト生成部１２は、コンテナ化対象の各パッケージのソースコード（以下、単に「ソース」とも称する）の修正ログの情報に基づいて、階層構成テーブル１４の元となるライブラリリスト１２１（図５参照）を生成する。ライブラリリスト１２１は、各パッケージが依存するＤＬＬファイルの情報、各ＤＬＬファイルが呼び出す関数（Ｉ／Ｆ関数）の情報、各パッケージに含まれるＤＬＬファイルや実行プログラム等の修正回数の情報等を格納したリストである。ライブラリリスト１２１については、後述の図５を参照して詳述し、ライブラリリスト１２１の生成手順については、後述の図７を参照して詳述する。

【0029】

ライブラリリスト生成部１２は、パッケージのソース、例えば実行バイナリファイルの修正ログを、ｄｕｍｐｂｉｎ等のツールを使用して取得する。なお、実行バイナリファイルがＩＬ（Intermediate language）形式で記載されている場合には、ライブラリリスト生成部１２は、ｉｌｄａｓｍ等のツールを使用して、実行バイナリファイルの修正ログを取得可能である。

【0030】

また、ライブラリリスト生成部１２は、取得した各ソースのビルド用ファイルから、ビルド後の生成物をリストアップし、ビルド後生成物のそれぞれにおける依存ＤＬＬファイル、使用関数の各情報を取得する。ビルド用ファイルには、例えば、ソリューションファイル等がある。ビルド後生成物には、実行されるプロセスの名前や、ＤＬＬファイル等のライブラリなどの情報が含まれる。

【0031】

さらに、ライブラリリスト生成部１２は、例えばｇｉｔ ｌｏｇ等のコマンドを用いてソースのコミットログを取得し、取得したコミットログの情報に基づいて、各パッケージにおける修正頻度、例えば修正回数の情報を取得する。そして、ライブラリリスト生成部１２は、取得したこれらの情報を用いてライブラリリスト１２１を生成する。なお、ライブラリリスト生成部１２が修正履歴を取得する方法は、上記以外の方法であってもよい。

【0032】

分類部１３は、ライブラリリスト生成部１２によって生成されたライブラリリスト１２１の情報に基づいて、コンテナイメージ生成の際又は修正の際に参照される、階層構成テーブル１４を生成する。階層構成テーブル１４は、ライブラリリスト１２１に格納された各ＤＬＬファイルに関する情報や、各ＤＬＬファイルのコンテナイメージのレイヤへの分類結果などが格納されたテーブルである。階層構成テーブル１４の構成例については、後述の図６を参照して詳述する。

【0033】

分類部１３は、参照元のパッケージの重複数がより多いＤＬＬファイル、及び／又は、修正頻度の低いＤＬＬファイルが、より下位のレイヤに配置されるように、各ＤＬＬファイルを分類する。そして、ライブラリリスト１２１に記載の情報、及び、各ＤＬＬファイルの分類結果の情報を用いて、階層構成テーブル１４を生成する。分類部１３による階層構成テーブル１４の生成処理については、後述の図８及び図９を参照して詳述する。

【0034】

イメージ生成部１５は、分類部１３によって生成された階層構成テーブル１４に記載の内容に基づいて、コンテナイメージを生成する。イメージ生成部１５が生成したコンテナイメージは、リポジトリ１５１（図においては「ｒｅｐｏ」と表記）に格納される。イメージ生成部１５によるコンテナイメージ生成処理については、後述の図１０～図１２を参照して詳述する。なお、イメージ生成部１５によって生成されたコンテナイメージは、サービスとして提供されるＤｏｃｋｅｒ Ｈｕｂ等のレジストリや、レジストリ構築ツールを用いて構築されたレジストリなどに格納されてもよい。

【0035】

（配備・更新管理部）
配備・更新管理部２０（配備管理部の一例）は、配備判断部２１と、配備部２２と、更新管理部２３と、を備える。
配備判断部２１は、階層構成テーブル１４に記載の情報に基づいて、各コンテナのノードにおける配備を決定する。より詳細には、配備判断部２１は、同一の機能グループのコンテナは、同一のノードに配備する決定を行う。配備判断部２１による配備判断処理については、後述の図１３を参照して詳述する。

【0036】

配備部２２は、配備判断部２１によって決定された配備の内容に基づいて、実際にコンテナをノードに配備（デプロイ）する。
更新管理部２３は、開発環境より修正の指示を受け付けた場合、階層構成テーブル１４を参照して修正対象のコンテナイメージを特定及び修正し、修正内容と対応するコンテナイメージの差分をダウンロードすることにより、コンテナの修正を行う。更新管理部２３による更新管理処理については、後述の図１５を参照して詳述する。

【0037】

［計算機のハードウェア構成例］
次に、本実施形態に係る仮想化環境構築システム１の機能を実現するための装置のハードウェア構成について、図４を参照して説明する。

【0038】

図４は、仮想化環境構築システム１のハードウェア構成例を示すブロック図である。図４に示す計算機２００は、いわゆるコンピュータとして用いられるハードウェアである。

【0039】

計算機２００は、バスＢにそれぞれ接続された制御部２１０と、不揮発性ストレージ２２０と、表示部２３０と、操作入力部２４０と、通信Ｉ／Ｆ（Interface）２５０と、を備える。

【0040】

制御部２１０は、ＣＰＵ（Central Processing Unit）２１１と、ＲＯＭ（Read Only Memory）２１２と、ＲＡＭ（Random Access Memory）２１３と、を備える。

【0041】

ＣＰＵ２１１は、本実施形態に係る各機能を実現するソフトウェアのプログラムコードをＲＯＭ２１２から読み出してＲＡＭ２１３に展開して実行する。ＲＡＭ２１３には、演算処理の途中に発生した変数やパラメータ等が一時的に書き込まれる。

【0042】

仮想化環境構築システム１の階層化情報生成部１０及び配備・更新管理部２０の各機能は、ＣＰＵ２１１がＲＯＭ２１２から該当するプログラムコードを読み出してＲＡＭ２１３に展開して実行することにより実現される。

【0043】

なお、制御部２１０は、ＣＰＵ２１１の代わりに、ＭＰＵ（Micro-Processing Unit）等の処理装置を備えてもよい。もしくは、制御部２１０は、特定の処理を行う専用回路（例えばＦＰＧＡ（Field-Programmable Gate Array）やＡＳＩＣ（Application Specific Integrated Circuit）等）を含んでもよい。

【0044】

不揮発性ストレージ２２０としては、例えば、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フレキシブルディスク、光ディスク、光磁気ディスク、ＣＤ－ＲＯＭ、ＣＤ－Ｒ、不揮発性のメモリカード等を用いることができる。この不揮発性ストレージ２２０には、ＯＳ（Operating System）、各種のパラメータの他に、計算機２００を機能させるためのプログラム等が記録される。なお、プログラムは、ＲＯＭ２１２に格納されてもよい

【0045】

表示部２３０は、例えば、ＬＣＤ（Liquid Crystal Display）等で構成されるモニタであり、計算機２００で行われる処理の結果等を表示する。
操作入力部２４０は、例えば、キーボード、マウス、タッチセンサ等によって構成され、ユーザによる操作に応じた操作信号を生成してＣＰＵ２１１に供給する。
なお、表示部２３０と操作入力部２４０とは、タッチパネルとして一体に構成されてもよい。また、計算機２００は、表示部２３０及び操作入力部２４０を備えない構成とされてもよい。

【0046】

プログラムは、コンピュータが読取り可能なプログラムコードの形態で格納され、ＣＰＵ２１１は、当該プログラムコードに従った動作を逐次実行する。つまり、ＲＯＭ２１２又は不揮発性ストレージ２２０は、コンピュータによって実行されるプログラムを格納した、コンピュータ読取可能な非一過性の記録媒体の一例として用いられる。

【0047】

仮想化環境構築システム１の階層化情報生成部１０のソース１１、階層構成テーブル１４及びリポジトリ１５１は、不揮発性ストレージ２２０又はＲＯＭ２１２内に形成される。

【0048】

通信Ｉ／Ｆ２５０には、例えば、ＮＩＣ（Network Interface Card）等が用いられ、ネットワーク又は通信線を介して外部装置との間で各種のデータを送受信することが可能である。

【0049】

［ライブラリリストの構成例］
次に、図５を参照して、ライブラリリスト生成部１２（図３参照）によって生成されるライブラリリスト１２１の構成について説明する。図５は、ライブラリリスト１２１の構成例を示す図である。

【0050】

図５に示すように、ライブラリリスト１２１は、「パッケージ名」（図においては「ＰＫＧ名」と表記）、「ビルド後生成物」、「依存ＤＬＬ名」、「ＤＬＬ内関数名」及び「修正頻度」の各項目を有する。

【0051】

「パッケージ名」の項目には、パッケージの名称が格納される。「ビルド後生成物」の項目には、ビルド後の生成物の情報が格納される。「依存ＤＬＬ名」の項目には、パッケージが依存するＤＬＬファイルの名称が格納される。「ＤＬＬ内関数名」の項目には、ＤＬＬファイル内に記載された、パッケージ又は他のＤＬＬファイル等により呼び出される関数の情報が格納される。「修正頻度」の項目には、過去にそのパッケージが修正された回数の情報が格納される。

【0052】

［階層構成テーブルの構成例］
次に、図６を参照して、イメージ生成部１５（図３参照）によって生成される階層構成テーブル１４の構成について説明する。図６は、階層構成テーブル１４の構成例を示す図である。

【0053】

図６に示すように、階層構成テーブル１４は、「ＤＬＬ名」、「使用パッケージリスト」、「修正頻度」、「使用パッケージ数」、「重複度」、「所属パッケージ」及び「レイヤ」の各項目を有する。（図において、「パッケージ」は「ＰＫＧ」と表記）

【0054】

「ＤＬＬ名」の項目には、ＤＬＬファイルの名称が格納される。「使用パッケージリスト」の項目には、そのＤＬＬファイルを使用するパッケージ名の情報が格納される。「修正頻度」の項目には、ＤＬＬファイルに加えられた修正の回数が格納される。「使用パッケージ数」の項目には、そのＤＬＬファイルを使用しているパッケージの数が格納される。

【0055】

「重複度」の項目には、そのＤＬＬファイルを使用しているパッケージの数、すなわち、パッケージから見た場合におけるそのＤＬＬファイル参照の重複数の情報が格納される。「所属パッケージ」の項目には、コンテナにおいてそのＤＬＬファイルが割り当てられる（所属する）パッケージの名称が格納される。

【0056】

「レイヤ」の項目には、ＤＬＬファイルが配置されるレイヤの情報が格納される。レイヤの情報には、レイヤ１の共通ライブラリイメージ、レイヤ２のグループライブラリイメージ、レイヤ３のパッケージライブラリイメージ（図２参照）がある。

【0057】

上述したように、分類部１３は、参照元のパッケージの重複数がより多いＤＬＬファイル、及び／又は、修正頻度の低いＤＬＬファイルが、より下位のレイヤに配置されるように、各ＤＬＬファイルを分類する。なお、階層構成テーブル１４には、重複度を優先して決定したレイヤへの分類結果と、修正頻度を優先して決定したレイヤへの分類結果との両方が記載されてもよい。

【0058】

または、レイヤへの分類時に参照する情報として、重複度、修正頻度以外の情報が用いられてもよい。例えば、ＤＬＬファイル（ライブラリ）のサイズ（データ量）の情報等が参照されてもよい。参照元のパッケージやＤＬＬファイルの数が多い（重複度の高い）ＤＬＬファイルは、ファイル容量が大きくなる傾向があるため、分類部１３は、サイズの大きいＤＬＬファイルを、より下位のレイヤに割り当てることができる。

【0059】

［ライブラリリスト生成処理］
次に、図７を参照して、ライブラリリスト生成部１２（図３参照）によるライブラリリスト１２１の生成処理について説明する。図７は、ライブラリリスト生成部１２によるライブラリリスト１２１の生成処理の手順の例を示すフローチャートである。

【0060】

まず、ライブラリリスト生成部１２は、パッケージの各ソースの修正ログを収集する（ステップＳ１）。次いで、ライブラリリスト生成部１２は、ステップＳ１で収集した各ソースのビルド用ファイルから、ビルド後の生成物をリストアップする（ステップＳ２）。

【0061】

次いで、ライブラリリスト生成部１２は、ＤＬＬ情報取得処理を開始する（ステップＳ３）。ＤＬＬ情報取得処理は、ＤＬＬ情報取得対象のビルド後生成物の数だけ繰り返し行われる。ＤＬＬ情報取得処理において、ライブラリリスト生成部１２は、ビルド後生成物のバイナリ情報から、ビルド後生成物が使用するＤＬＬファイルの情報を取得する（ステップＳ４）。

【0062】

次いで、ライブラリリスト生成部１２は、ステップＳ４で取得したＤＬＬファイルの情報から、該ＤＬＬファイルが依存している他のＤＬＬファイルの情報、及び、該ＤＬＬファイルが呼び出す関数（Ｉ／Ｆ関数）の各情報を取得する（ステップＳ５）。

【0063】

次いで、ライブラリリスト生成部１２は、依存するＤＬＬファイルはあったか否かを判定する（ステップＳ６）。ステップＳ６で、依存するＤＬＬファイルはないと判定された場合（ステップＳ６がＮＯ判定の場合）、ライブラリリスト生成部１２は、ステップＳ４に戻って処理を行う。すなわち、ライブラリリスト生成部１２は、次のビルド後生成物のＤＬＬファイル情報を取得する。

【0064】

一方、ステップＳ６で、依存するＤＬＬファイルはあると判定された場合（ステップＳ６がＹＥＳ判定の場合）、ライブラリリスト生成部１２は、ステップＳ５の処理を行う。そして、ライブラリリスト生成部１２は、ＤＬＬ情報取得対象のビルド後生成物がなくなった時点で、ＤＬＬ情報取得処理を終了する。

【0065】

ＤＬＬ情報取得処理の終了後、ライブラリリスト生成部１２は、ＤＬＬ情報取得処理によって取得した情報と、コミットログ等から収集した修正履歴（回数）の情報とを用いて、ライブラリリスト１２１を生成する（ステップＳ７）。ステップＳ７の処理後、ライブラリリスト生成部１２によるライブラリリスト生成処理は終了する。

【0066】

［階層構成テーブル生成処理］
次に、分類部１３による階層構成テーブル１４の生成処理について説明する。図８は、分類部１３による階層構成テーブル１４の生成処理の手順の例を示すフローチャートである。

【0067】

分類部１３は、フェーズ１～フェーズ３（図中においてはＰＨ１～ＰＨ３と表記）の３段階の処理を行うことにより、階層構成テーブル１４を生成する。まず、分類部１３は、ライブラリリスト１２１を読み込み、各ＤＬＬファイルの統計データを生成する（ステップＳ１１）。統計データとは、そのＤＬＬファイルを使用するパッケージの重複数、そのＤＬＬファイルが所属（依存）しているパッケージ名、修正頻度の情報により構成されるデータである。

【0068】

次いで、分類部１３は、フェーズ１の処理として、各ＤＬＬファイルのレイヤ１～レイヤ３への割り当て処理を行う（ステップＳ１２）。該割り当て処理は、割当て対象のＤＬＬファイルの数だけ繰り返し行われる。

【0069】

フェーズ１の処理として、分類部１３は、まず、パッケージの重複数が所定の閾値を超えるＤＬＬファイルを、レイヤ１（共通ライブラリイメージ）に割り当てる（ステップＳ１３）。パッケージの重複数の閾値は、例えば、全パッケージ数に対する重複数の割合（％）等によって示される。

【0070】

次いで、分類部１３は、パッケージの重複がない、使用パッケージ数が“１”であるＤＬＬファイルを、レイヤ３に割り当てる（ステップＳ１４）。使用パッケージ数が１つであるとは、すなわち、そのパッケージのみが使用するＤＬＬファイルであることを意味する。したがって、分類部１３は、このようなＤＬＬファイルを、パッケージ自身が配備される最上位のレイヤ３（パッケージイメージ）に割り当てる。

【0071】

次いで、分類部１３は、レイヤ１又はレイヤ３への割り当てが行われていないＤＬＬファイルを、レイヤ２（グループライブラリイメージ）に割り当てる（ステップＳ１５）。割当対象のＤＬＬファイルがなくなった時点で、分類部１３は、各ＤＬＬファイルのレイヤ１～レイヤ３への割り当て処理を終了する。

【0072】

次いで、分類部１３は、フェーズ２として、ステップＳ１１で生成した統計データにおける修正頻度の情報に基づいて、レイヤ１に割り当て済みのＤＬＬファイルを対象としたレイヤ割り当て調整を行う（ステップＳ１６）。具体的には、分類部１３は、ステップＳ１３でレイヤ１に割り当てたＤＬＬファイルのうち、修正回数が所定の閾値以上であるＤＬＬファイルを、レイヤ１からレイヤ２に移動させる。

【0073】

例えば、図２に示した画像表示処理機能を有する各コンテナに対しては、ユーザによる仕様変更の指示等に基づいて、修正が頻繁に行われる可能性が高い。このような機能に対応するＤＬＬファイルをレイヤ２に移動させ、レイヤ２の各機能グループの単位でコンテナをノードに実装させることにより、修正の範囲をノード（図２に示す例ではノード１）内に限定させることが可能となる。

【0074】

次いで、分類部１３は、フェーズ３として、ステップＳ１１で生成した統計データにおける、そのＤＬＬファイルが所属（依存）しているパッケージ名の情報に基づいて、レイヤ２内におけるＤＬＬファイルの配置調整を行う（ステップＳ１７）。具体的には、分類部１３は、ＤＬＬファイルが所属（依存）しているパッケージ名の情報に基づいて、レイヤ２を機能グループ単位に分割し、該機能グループに該当するＤＬＬファイルを、該機能グループに移動させる。図２には、機能グループが「画像表示処理」、「データ処理」及び「サーバ処理」の３つに分割された例を示している。

【0075】

次いで、分類部１３は、ステップＳ１１で作成した各ＤＬＬファイルの統計データと、ステップＳ１３～ステップＳ１７において行った各ＤＬＬファイルの各レイヤへの割り当て結果の情報を用いて、階層構成テーブル１４を生成する（ステップＳ１８）。ステップＳ１８の処理後、分類部１３による階層構成テーブル生成処理は終了する。

【0076】

図９は、階層構成テーブル１４の生成過程の例を示す図である。図９には、フェーズ１～フェーズ３の各処理の実行後におけるコンテナイメージの構成例を示す。図８のステップＳ１３において、分類部１３によってフェーズ１の処理が行われると、コンテナイメージは、図９の左側に示す状態となる。つまり、ＯＳベースイメージ及び共通設定イメージの上に、共通ライブラリイメージ（レイヤ１）、グループライブラリイメージ（レイヤ２）、パッケージイメージ（レイヤ３）が積層された状態となる。

【0077】

図８のステップＳ１６において、分類部１３によってフェーズ２の処理が行われると、コンテナイメージは、図９の中央に示す状態となる。なお、図９の中央に示すコンテナイメージにおいては、ＯＳベースイメージ及び共通設定イメージの図示を省略している。図９の中央に示すコンテナイメージでは、左側に示すコンテナイメージと比較して、共通ライブラリイメージ（レイヤ１）の層が薄くなり、グループライブラリイメージ（レイヤ２）の層が厚くなっている。フェーズ２の処理によって、共通ライブラリイメージ（レイヤ１）に割り当てられていたＤＬＬファイルがグループライブラリイメージ（レイヤ２）に移動したためである。

【0078】

図８のステップＳ１７において、分類部１３によってフェーズ３の処理が行われると、コンテナイメージは、図９の右側に示す状態となる。なお、図９の右側に示すコンテナイメージにおいても、ＯＳベースイメージ及び共通設定イメージの図示を省略している。図９の右端に示すコンテナイメージでは、グループライブラリイメージ（レイヤ２）が、「画像処理機能」、「サーバ機能」等の各機能グループ単位に分割されている。なお、機能グループの分割数は３つに限定されず、他の数であってもよい。

【0079】

［コンテナイメージ生成処理］
次に、イメージ生成部１５によるコンテナイメージ生成処理について説明する。図１０及び図１１は、イメージ生成部１５によるコンテナイメージ生成処理の手順の例を示すフローチャートである。

【0080】

まず、階層化情報生成部１０のイメージ生成部１５（図３参照）は、ライブラリリスト１２１（図５参照）のビルド後生成物の項目の中から、コンテナイメージ生成対象のビルド後生成物名を取得する（ステップＳ２１）。次いで、イメージ生成部１５は、レイヤ１のコンテナイメージ生成処理を行う（ステップＳ２２）。レイヤ１のコンテナイメージ生成処理は、階層構成テーブル１４においてレイヤ１に割り当てられたＤＬＬファイルの数だけ繰り返し行われる。

【0081】

レイヤ１のコンテナイメージ生成処理において、イメージ生成部１５は、まず、階層構成テーブル１４を参照して、レイヤ１に配置するビルド後生成物名をリストアップ（取得）し、コンテナイメージの元となる設計ファイルＦｃ１（図１２参照）を生成する（ステップＳ２３）。

【0082】

図１２は、各レイヤに配備されるビルド後生成物名が記載された設計ファイルの例を示す図である。
図１２には、図１０のステップＳ２３によって生成されたレイヤ１用の設計ファイルＦｃ１と、後述する処理により生成されるレイヤ２用の設計ファイルＦｃ２、及び、レイヤ３用の設計ファイルＦｃ３とが示されている。図１２の各設計ファイルＦｃ１～Ｆｃ３には、レイヤ１～３のそれぞれに配置されるビルド後生成物の名称が記載されている。

【0083】

図１０のステップＳ２３の処理後、イメージ生成部１５は、各パッケージのインストーラを起動して、ステップＳ２３で生成した設計ファイルＦｃ１に記載のビルド後生成物をインストールすることにより、レイヤ１のコンテナイメージを生成する（ステップＳ２４）。

【0084】

次いで、イメージ生成部１５は、レイヤ２のコンテナイメージ生成処理を行う（ステップＳ２５）。レイヤ２のコンテナイメージ生成処理において、イメージ生成部１５は、まず、レイヤ１をベースイメージに設定する（ステップＳ２６）。次いで、イメージ生成部１５は、階層構成テーブル１４を参照して、レイヤ２に配置するビルド後生成物名をリストアップ（取得）して、設計ファイルＦｃ２（図１２参照）を生成する（ステップＳ２７）。次いで、イメージ生成部１５は、ステップＳ２７で生成した設計ファイルＦｃ２に記載のビルド後生成物をインストールすることにより、レイヤ２のコンテナイメージを生成する（ステップＳ２８）。

【0085】

上述したステップＳ２７及びステップＳ２８の処理は、階層構成テーブル１４においてレイヤ２に割り当てられたＤＬＬファイルの数だけ繰り返し行われる。

【0086】

次いで、イメージ生成部１５は、レイヤ３のコンテナイメージ生成処理を行う（図１１のステップＳ２９）。レイヤ３のコンテナイメージ生成処理において、イメージ生成部１５は、まず、レイヤ２をベースイメージに設定する（ステップＳ３０）。次いで、イメージ生成部１５は、階層構成テーブル１４を参照して、レイヤ３に配置するビルド後生成物名をリストアップ（取得）して、設計ファイルＦｃ３（図１２参照）を生成する（ステップＳ３１）。次いで、イメージ生成部１５は、ステップＳ３１で生成した設計ファイルＦｃ３に記載のビルド後生成物をインストールすることにより、レイヤ３のコンテナイメージを生成する（ステップＳ３２）。

【0087】

上述したステップＳ３１及びステップＳ３２の処理は、階層構成テーブル１４においてレイヤ３に割り当てられたＤＬＬファイルの数だけ繰り返し行われる。ステップＳ３２の処理後、イメージ生成部１５によるコンテナイメージ生成処理は終了する。なお、イメージ生成部１５によるコンテナイメージ生成処理は、Ｄｏｃｋｅｒｆｉｌｅ等の機能を用いて行われてもよい。

【0088】

図１３は、コンテナイメージの生成過程の例を示す図である。図１３Ａは、ＯＳベースイメージ及び共通設定イメージの上に、レイヤ１（共通ライブラリイメージ）が形成された状態を示す。図１３Ｂは、レイヤ１上に、複数のレイヤ２（グループライブラリイメージ）が形成された状態を示す。図１３Ｃは、レイヤ２の上にレイヤ３（パッケージイメージ）が形成された状態を示す。

【0089】

［配備判断処理］
次に、図１４を参照して、配備・更新管理部２０の配備判断部２１による配備判断処理について説明する。図１４は、配備判断部２１による配備判断処理の手順の例を示すフローチャートである。

【0090】

まず、配備判断部２１は、階層構成テーブル１４に記載の内容に基づいて、不図示のノードに配備する対象物（ＤＬＬファイル、パッケージ等）の所属グループ（レイヤ３のグループ）を特定する（ステップＳ４１）。階層構成テーブル１４（図６参照）の所属パッケージの項目には、パッケージの名称が記載されているため、該パッケージ名から所属するグループを特定する。

【0091】

次いで、配備判断部２１は、レイヤ２における同一の機能グループに属する（対応付けられた）ＤＬＬファイル、パッケージ等を、同一のノードに配備する（ステップＳ４２）。ステップＳ４２の処理後、配備判断部２１による配備判断処理は終了する。

【0092】

例えば、図２に示したように、一つのノード１に、レイヤ３のパッケージ「Ｇａ」、「Ｇｂ」、「Ｇｃ」のそれぞれに属する３つのコンテナが配備されるとする。そして、「Ｇａ」、「Ｇｂ」、「Ｇｃ」の順に対応するコンテナが１個ずつノードに配備されるとする。「Ｇａ」、「Ｇｂ」、「Ｇｃ」は、同じ画像表示機能に属するパッケージであるため、同じレイヤ２に属する。すなわち、同じレイヤ２のコンテイメージを共通して使用する。

【0093】

したがって、例えば２つ目の「Ｇｂ」のグループのコンテナのイメージを生成する場合、配備部２２（図３参照）は、１つ目の「Ｇａ」のグループのコンテナ生成時に既に生成されたレイヤ１、レイヤ２のコンテナイメージを流用することが可能となる。つまり、配備部２２は、「Ｇｂ」のグループのコンテナの配備時には、配備部２２は、「Ｇａ」のコンテナイメージとの差分、すなわち、レイヤ３のパッケージ部分のコンテナイメージのみをダウンロード（リポジトリ１５１（図３参照）から取得）し、デプロイするのみでよくなる。つまり、本実施形態によれば、各コンテナがダウンロードすべきデータの量を削減でき、かつ、コンテナイメージの生成に要する時間も節減できる。

【0094】

［更新管理処理］
次に、図１５を参照して、配備・更新管理部２０の更新管理部２３による更新管理処理について説明する。図１５は、配備・更新管理部２０の更新管理部２３による更新管理処理の手順の例を示すフローチャートである。

【0095】

開発環境より修正の要求があった場合、更新管理部２３は、まず、階層構成テーブル１４に記載の内容に基づいて、修正対象となるライブラリ（ＤＬＬファイル）の依存関係を特定する（ステップＳ５１）。次いで、更新管理部２３は、ステップＳ５１で特定した依存関係にあるライブラリのコンテナイメージを更新する（ステップＳ５２）。具体的には、更新管理部２３は、コンテナイメージの元となる設計ファイルの該当箇所を修正し、該設計ファイルからコンテナイメージをビルドする。

【0096】

次いで、更新管理部２３は、ステップＳ５２で更新されたコンテナイメージと、現在のコンテナイメージとの差分を、リポジトリ１５１からダウンロードする（ステップＳ５３）。次いで、更新管理部２３は、更新後のコンテナイメージを再び起動させる（ステップＳ５４）。コンテナの再起動にあたり、起動順等の起動の条件が設定されている場合には、更新管理部２３は、該条件が満たされた場合に再起動する。ステップＳ５４の処理後、更新管理部２３による更新管理処理は終了する。

【0097】

上述した実施形態に係る仮想化環境構築システム１は、仮想化対象のアプリケーション（パッケージ）を構成する各要素間における論理的関係及び依存性の情報に基づいて、仮想化環境を構成する複数のレイヤのうちのいずれかのレイヤに要素を割り当てる階層化情報生成部１０を有する。さらに、仮想化環境構築システム１は、複数のレイヤを含む独立空間としてのコンテナを生成して、該コンテナを実環境におけるノードに配備するとともに、各要素間における論理的関係及び依存性の情報に基づいて、ノードに配備された要素を特定して修正する配備・更新管理部２０を有する。したがって、本実施形態によれば、修正対象を容易に明確化可能な仮想化環境が提供される。

【0098】

また、上述した実施形態では、配備・更新管理部２０は、コンテナを、アプリケーションのパッケージの単位で生成する。したがって、本実施形態によれば、配備・更新管理部２０は、開発環境より修正の指示があった場合における修正箇所を、パッケージの単位で生成されたコンテナを対象として探すことができるため、修正対象を容易に明確化できる。

【0099】

また、上述した実施形態では、階層化情報生成部１０は、アプリケーションのソースコードの修正履歴の情報に基づいて、パッケージを構成する各ＤＬＬファイル間における論理的関係及び依存性の情報、並びに、ＤＬＬファイルのレイヤへの割り当て結果の情報を記した階層構成テーブル１４を生成する。そして、配備・更新管理部２０は、階層構成テーブル１４に記載の情報に基づいてコンテナのノードへの配備、及び、コンテナの修正を行う。したがって、本実施形態によれば、配備・更新管理部２０は、階層構成テーブル１４に記載の情報に基づいて、修正対象のコンテナ及びコンテナ内のＤＬＬファイル等を容易に特定できる。

【0100】

また、上述した実施形態では、コンテナには、最下層のレイヤ１～最上層のレイヤ３の３層のレイヤを含む。そして、階層化情報生成部１０は、複数のパッケージによって共有される設定に関する要素（ＤＬＬファイル等）をレイヤ１に配置し、パッケージが有する機能の単位で共有される設定に関する要素（ＤＬＬファイル等）を第レイヤ２に配置する。さらに、階層化情報生成部１０は、パッケージによって使用される設定に関する要素（ＤＬＬファイル等）をレイヤ３に配置する。

【0101】

また、上述した実施形態では、階層化情報生成部１０は、呼び出し元のＤＬＬファイルの重複度が所定の閾値を超える要素をレイヤ１に配置し、レイヤに配置されたＤＬＬファイルのうち、修正頻度が所定の閾値を超える要素は、レイヤ１からレイヤ２に移動させる。これにより、レイヤ１には、参照元のＤＬＬファイルの重複数が多く、かつ、修正頻度の少ないＤＬＬファイルが配置され、レイヤ２には、パッケージの機能の単位で共有されるＤＬＬファイルであり、かつ、修正頻度がある程度多いＤＬＬファイルが配置される。

【0102】

コンテナイメージは、下位のレイヤとの差分の情報で構成されるため、レイヤが上層になる程、下位のレイヤに対する依存性は高くなる。したがって、本実施形態によれば、修正が頻繁に行われることが想定されるＤＬＬファイルほど、上位のレイヤに配置されるため、修正頻度が頻繁になると想定されるパッケージの、修正時における修正対象範囲を、狭域化することができる。

【0103】

また、上述した実施の形態では、配備・更新管理部２０は、コンテナのうち、パッケージの機能グループの単位で設けられたレイヤ２の一区分に対応付けられた複数のコンテナを、一つのノードに配備する。これにより、同一のノードに配備される２つ目以降のコンテナにおいては、１つ目に設定済みのコンテナが有する情報との差分の情報のみをダウンロードすればよくなるため、コンテナに格納されるデータの少量化、及び、コンテナ生成作業に要する時間の短縮化を図ることができる。

【0104】

さらに、上述した実施形態では、仮想化技術としてコンテナ型仮想化技術を用いることにより、各コンテナ内のアプリケーション動作環境を独立させることがでるため、可搬性を高めることができる。また、一つ一つのコンテナを独立した計算機環境とみなせるため、コンテナが含む共有ライブラリを、各コンテナ間において重複させることも可能となる。

【0105】

なお、上述した各実施形態では、計算機環境構築システム１がコンテナ型仮想化技術を用いて仮想化環境を構築する例を挙げたが、本発明はこれに限定されない。レイヤ構造を有する独立実行環境を構成可能な仮想化技術であれば、コンテナ型仮想化技術以外の仮想化技術が用いられてもよい。

【0106】

＜第２の実施形態＞
次に、図１６～図１８を参照して、本発明の第２の実施形態について説明する。第２の実施形態において、本発明に係る計算機環境構築システムは、ソフトウェア（ソリューション）スタックの技術を用いて、既存のソフトウェア資産を計算機（ベアマシン）に移行する。ソフトウェアスタックは、互いに相互運用性のあるプロトコルやソフトウェアを積み重ね、全体として一つのシステムや機能を実現する手法である。

【0107】

図１６は、第２の実施形態に係る構成ファイルイメージの構成例を示す図である。ソフトウェアスタックは、ベアマシン上で動作するＯＳを利用するため、ＯＳベースイメージの階層を持たない。それ以外の階層の構成については、図２に示した第１の実施形態に係るコンテナイメージと同様である。本実施形態に係る構成ファイルイメージも、図８に示した手順により生成される階層構成テーブル１４（図６参照）に基づいて、階層化情報生成部１０のイメージ生成部１５（図１７参照）によって生成される。

【0108】

図１７は、第２の実施形態に係る計算機環境構築システム１Ａの機能構成例を示すブロック図である。図１７に示す計算機環境構築システム１Ａが、図３に示した第１の実施形態に係る仮想化環境構築装置１と異なる点は、階層化情報生成部１０のイメージ生成部１５が、コンテナイメージではなく、ソフトウェアスタックの構成ファイルイメージを生成する点と、配備・更新管理部２０による配備先が、ベアマシン上の実環境である点である。

【0109】

図１８は、本実施形態に係る構成ファイルイメージの生成過程の例を示す図である。図１８に示す構成ファイルイメージの生成過程と、図１３に示した第１の実施形態に係るコンテナイメージの生成過程との違いは、本実施形態に係る構成ファイルイメージは、ＯＳベースイメージの階層を含まない点である。また、本実施形態では、図１８中に破線の枠によって囲われた領域を構成するのは、各レイヤに割り当てられたファイルとなる。

【0110】

上述した第２の実施形態によっても、つまり、既存のソフトウェア資産の移行先の環境が、物理環境におけるベアマシンである場合にも、第１の実施形態によって得られる効果と同様の効果を得ることができる。

【0111】

なお、上述した実施形態は本発明を分かりやすく説明するためにシステムの構成を詳細且つ具体的に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。

【0112】

また、図３及び図４において実線又は矢印で示した制御線又は情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

【0113】

また、本明細書において、時系列的な処理を記述する処理ステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）をも含むものである。

【0114】

また、上述した本開示の各実施形態にかかる計算機環境構築システムの各構成要素は、それぞれのハードウェアがネットワークを介して互いに情報を送受信できるならば、いずれのハードウェアに実装されてもよい。また、ある処理部により実施される処理が、１つのハードウェアにより実現されてもよいし、複数のハードウェアによる分散処理により実現されてもよい。

【符号の説明】

【0115】

１…仮想化環境構築システム、１Ａ…計算機環境構築システム、１０…階層化情報生成部、１２…ライブラリリスト生成部、１３…分類部、１４…階層構成テーブル、１５…イメージ生成部、２０…配備・更新管理部、２１…配備判断部、２２…配備部、２３…更新管理部、１２１…ライブラリリスト

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】