JP2021039393A - パッケージ化支援システムおよびパッケージ化支援方法 - Google Patents

Abstract

【課題】ＩＴシステムを容易にパッケージ化し得るパッケージ化支援システムを提供する。【解決手段】パッケージを識別可能な識別情報と、パッケージのもとになるソースコードを識別可能な識別情報と、パッケージのインスタンスを識別可能な識別情報とが対応付けられた対応関係情報を記憶する記憶装置と、利用者が操作する端末から所定のインスタンスのパッケージ化の指示を受信したことに基づいて、対応関係情報をもとに所定のインスタンスと対応付けられている所定のソースコードを第１の管理部から取得して出力するパッケージ化部と、を設けるようにした。【選択図】図１

Description

本発明は、パッケージ化支援システムおよびパッケージ化支援方法に関し、例えば、インスタンスのパッケージ化を支援するパッケージ化支援システムおよびパッケージ化支援方法に適用して好適なものである。

近年、ＩＴ（Information Technology）リソースの仮想化が進んでいる。仮想化の技術は、物理サーバを論理的に分割することで複数のサーバと見せる仮想サーバ、サーバで動作するＯＳ（Operating System）のプロセス単位に論理分割し、１つのサーバのように見せるコンテナ等、多様化している。

また、仮想化したＩＴリソースを効率的に管理したり運用したりするためのオーケストレーションツールについても様々なソフトウェアが開発されている。例えば、オープンソースソフトウェア（Open Source Software、以下ＯＳＳ）では、ＯｐｅｎＳｔａｃｋ、Ｋｕｂｅｒｎｅｔｅｓ等がある。

こうした技術の発達により、ＩＴの柔軟な運用が容易となったことから、仮想化したＩＴリソース、ＩＴリソース上で動作するアプリケーションをネットワーク経由で利用者に提供するクラウドサービスも多く提供されている状況にある。

オーケストレーションツール、クラウドサービス等の利用が進むにつれ、これらを使いこなす技術として、ソースコードによりＩＴリソース、サービス等を管理し、アプリケーションが動作するシステムを構築して運用することを可能とするＩａＣ（Infrastructure as a Code）が盛んになっている。

ＩａＣを実現するパッケージツールとしては、ＯＳＳとして開発されるＨｅｌｍ（https://helm.sh/）、ＯＳＳとして開発されるＴｅｒｒａｆｏｒｍ（https://www.terraform.io/）等がある。こうしたパッケージツールにおいて、ＩａＣのソースコードは、システムの構成を記述したひな型（テンプレート）のファイル群と、テンプレートに与える変数およびデフォルト値を記述した変数ファイルとで構成されることが一般的である。

こうしたＩａＣの技術を活用し、マーケットプレイスの提供、利用等も盛んになっている。マーケットプレイスとは、利用可能なアプリケーションを構成する要素（アプリケーション自体のバイナリ、設定ファイル等）を１つの単位にまとめたもの（以下、パッケージ）が多数登録されており、その中からパッケージを選択することで意図するシステムが自動的に構築されて利用できるようになるものである。

一般に、パッケージの登録は、クラウドサービス、アプリケーション等を開発する事業者が、自らが提供するサービス、アプリケーション等の利用を促進するために行うことが多い。また、複数の事業者が１つのマーケットプレイスを共有するエコシステムが形成されることも多い。他方、マーケットプレイスの利用者は、意図するシステムを全て構築する手間を省くために利用することが多い。こうした背景から、パッケージを登録する事業者と、利用する利用者とは基本的に異なるものである。

このようなマーケットプレイスへのパッケージの登録と利用とのライフサイクルを考えたとき、利用者があるパッケージを選択することで構築したシステムを改変し、新たなシステム（アプリケーション）を開発し、そして再度パッケージとしてマーケットプレイスに登録するといったユースケースも考えられる。このとき、新たにパッケージとして登録したい利用者（新たなパッケージの提供者）は、パッケージの登録のための知識を有しているとは限らない。結果、パッケージ化のための知識がない新たなパッケージの提供者は、この知識を学習した上で、新たなパッケージのための検討が必要となり、パッケージの登録までに手間および時間がかかる。

特表２０１４−５２３０２６号公報

特許文献１では、利用者が構築したシステムの情報をもとに、予め定義された静的なパッケージのひな型から適切なものを選択し、利用者（すなわち新たなパッケージの提供者）に提示する技術が開示されている。

しかしながら、特許文献１に記載の技術を用いても、マーケットプレイスで当該利用者が利用したパッケージ、すなわち利用者が今回登録したいシステムのもとになったパッケージの情報を利用者が知る術がない。結果、もとになったパッケージに含まれていたパッケージ化のための知見が活かされず、利用者は、構築したり改変したりしたアプリケーションのインスタンスを適切にパッケージ化ができない、または再度パッケージ化のための検討が必要となり時間がかかってしまう。

本発明は、以上の点を考慮してなされたもので、インスタンスを容易にパッケージ化し得るパッケージ化支援システム等を提案しようとするものである。

かかる課題を解決するため本発明においては、ソースコードを管理する第１の管理部と、ソースコードもとに作成されるパッケージを管理し、利用者が操作する端末から指示されたパッケージをインスタンスとして所定の実行環境において利用可能にするマーケットプレイスシステムと通信可能なパッケージ化支援システムであって、パッケージを識別可能な識別情報と、前記パッケージのもとになるソースコードを識別可能な識別情報と、前記パッケージのインスタンスを識別可能な識別情報とが対応付けられた対応関係情報を記憶する記憶装置と、利用者が操作する端末から所定のインスタンスのパッケージ化の指示を受信したことに基づいて、前記対応関係情報をもとに前記所定のインスタンスと対応付けられている所定のソースコードを前記第１の管理部から取得して出力するパッケージ化部と、を設けるようにした。

上記構成では、利用者は、パッケージ化を所望するインスタンスを指定することで、インスタンスと対応付けられているソースコードが出力される。よって、ユーザは、例えば、出力されたソースコードを用いることができ、つまり利用者自身でソースコードを特定して取得する必要がなくなるので、インスタンスのパッケージ化を容易に行うことができるようになる。

本発明によれば、パッケージ化を支援することができる。

第１の実施の形態によるパッケージシステムに係る構成の一例を示す図である。 第１の実施の形態によるパッケージソースコードのディレクトリ構成の一例を示す図である。 第１の実施の形態によるポータル画面の一例を示す図である。 第１の実施の形態によるデプロイ処理に係るデータの一例を示す図である。 第１の実施の形態によるパッケージ化支援システムに係る構成の一例を示す図である。 第１の実施の形態によるＣＩ管理情報の一例を示す図である。 第１の実施の形態によるパッケージ管理情報の一例を示す図である。 第１の実施の形態によるインスタンス管理情報の一例を示す図である。 第１の実施の形態による対応関係情報の一例を示す図である。 第１の実施の形態による変換ルール情報の一例を示す図である。 第１の実施の形態による変更差分情報の一例を示す図である。 第１の実施の形態によるデプロイ処理に係るフローチャートの一例を示す図である。 第１の実施の形態によるパッケージ化支援処理に係るフローチャートの一例を示す図である。 第１の実施の形態によるイメージ化処理に係るフローチャートの一例を示す図である。 第１の実施の形態によるテンプレート情報生成処理に係るフローチャートの一例を示す図である。 第１の実施の形態によるテンプレート情報生成処理に係るフローチャートの一例を示す図である。 第１の実施の形態によるパッケージ化支援画面の一例を示す図である。 第２の実施の形態によるパッケージ化支援システムに係る構成の一例を示す図である。

（１）第１の実施の形態
以下図面について、本発明の一実施の形態を詳述する。本実施の形態では、プログラムの開発支援、特に、ＩＴシステム全体をソースコードとして記述し、ソースコードを用いてシステムを構築する方法（ＩａＣ）の開発を支援する技術に関して説明する。本実施の形態は、一例であって、本実施の形態に示す要素（構成、対象、用途等）以外の要素に適用してもよい。

図１において、１００は全体として本実施の形態によるパッケージシステムを示す。

図１は、パッケージシステム１００に係る構成の一例を示す図である。パッケージシステム１００は、リポジトリ１１０と、ＣＩ（Continuous Integration）システム１２０と、マーケットプレイスシステム１３０と、実行環境１４０と、パッケージ化支援システム１５０とを含んで構成される。

パッケージをマーケットプレイスシステム１３０に登録する提供者１０１は、マーケットプレイスシステム１３０に登録するパッケージのもとになるパッケージソースコード１１１を指定されたリポジトリ１１０に登録する。リポジトリ１１０の例としては、クラウドサービスでは、ＧｉｔＨｕｂ（https://github.com/）、ＯＳＳでは、ＧｉｔＬａｂといったものである。パッケージソースコード１１１の例については、図２を用いて後述する。

なお、図１では、マーケットプレイスシステム１３０に含まれる複数のパッケージのパッケージソースコード１１１を、１つのリポジトリ１１０で管理する例を示しているが、パッケージに対応するパッケージソースコード１１１ごとにリポジトリ１１０が分かれている構成であってもよい。

ここで、パッケージとは、マーケットプレイスシステム１３０に登録する単位であり、パッケージ単位に対応したシステムが構築されるものである。なお、詳細は後述するが、パッケージは、マーケットプレイスシステム１３０で管理したり表示したりするための各種の情報、システムを構築するためのインストールイメージ１３１の実体または参照、システム上で動作するアプリケーションのアプリイメージ１３２の実体または参照等からなるものである。

登録されたパッケージソースコード１１１は、ＣＩシステム１２０によりパッケージのビルド（作成）が行われる。パッケージのビルド（ビルド処理）とは、パッケージソースコード１１１から、インストールを実行するためのインストールイメージ１３１、仮想サーバ、コンテナ等で実行されるアプリインスタンス１４１のアプリイメージ１３２、マーケットプレイスシステム１３０で表示したり管理したりするためのパッケージ管理情報１３３等を生成する処理のことである。

インストールイメージ１３１としては、インストール処理を実行するバイナリ情報、ＣＮＡＢ（Cloud Native Application Bundles、https://cnab.io/）が定めるインストールのためのコンテナイメージ、パッケージソースコード１１１の一部または全部、パッケージソースコード１１１の一部または全部をｔａｒ等でアーカイブ（圧縮）した情報、パッケージソースコード１１１をコンパイルしたバイナリ等が挙げられる。同様に、アプリイメージ１３２としては、アプリインスタンス１４１を実行するためのバイナリ、仮想サーバのイメージ、コンテナイメージ等である。なお、パッケージ管理情報１３３については、図７を用いて後述する。

ビルド処理は、パッケージソースコード１１１の登録等を契機として自動的に開始することが一般的である。本実施の形態では、ＣＩシステム１２０がビルド処理を行う。ＣＩシステム１２０の例としては、Ｊｅｎｋｉｎｓ（https://jenkins.io/）、ＧｉｔＬａｂ−ＣＩ（https://docs.gitlab.com/ee/ci/）等、有償無償問わず、様々な資源（ソフトウェア、サービス等）が提供されている。ビルド処理の指定方法については、選択する資源により異なり、ＣＩシステム１２０内部に情報を持つ場合、パッケージソースコード１１１の一部に含まれる場合等がある。

ビルド処理により作成されたインストールイメージ１３１、アプリイメージ１３２およびパッケージ管理情報１３３は、マーケットプレイスシステム１３０の記憶装置（レジストリ１３４等）に登録される。レジストリ１３４は、便宜上、マーケットプレイスシステム１３０の内に含まれるように記述しているが、マーケットプレイスシステム１３０の外側に設けられていてもよい。また、マーケットプレイスシステム１３０は、パッケージ管理情報１３３等を用いて、マーケットプレイスシステム１３０の利用者１０２に対してポータル画面１３５を表示装置に表示する。ポータル画面１３５の例については、図３を用いて後述する。

利用者１０２は、ポータル画面１３５を用いて今回、利用したいパッケージを選択する。利用者１０２がパッケージを選択すると、マーケットプレイスシステム１３０は、選択されたパッケージのインストールイメージ１３１を用いて実行環境１４０にデプロイ処理を実施する。実行環境１４０は、パッケージを動作させるための環境である。実行環境１４０は、例えば、パブリッククラウドサービス、プライベートクラウドサービス、ＯｐｅｎＳｔａｃｋ、Ｋｕｂｅｒｎｅｔｅｓ等のオーケストレーションツールで管理されるＩＴリソースのクラスタ等である。また、利用者１０２が選択したパッケージを動作させる実行環境１４０については、利用者１０２が指定する形式であってもよいし、マーケットプレイスシステム１３０が自動的に選択する形式であってもよい。加えて、マーケットプレイスシステム１３０は、複数の利用者１０２で共用されることが一般である。このとき実行環境１４０は、利用者１０２毎に異なる実行環境であってもよいし、１つの実行環境を共用する形であってもよい。

マーケットプレイスシステム１３０によるデプロイ処理が行われた結果、実行環境１４０には、アプリイメージ１３２の実行状態であるアプリインスタンス１４１、アプリインスタンス１４１の動作を規定した設定ファイルであるＣｏｎｆｉｇ１４２等からなる、パッケージに対応したシステム（以下、インスタンス１４３）が構築される。ここで、アプリインスタンス１４１は、Ｃｏｎｆｉｇ１４２の記述に応じて、１または複数であってよい。

そして、利用者１０２は、構築されたインスタンス１４３に必要な変更を加え、利用者１０２の用途にあった開発（インスタンス１４３に対する変更）を行う。パッケージとして再度登録できるものが開発できた利用者１０２は、パッケージ化支援システム１５０を用いて、開発したＩＴシステム（例えば、インスタンス１４３）のパッケージ化を行う。

パッケージ化支援システム１５０は、パッケージ化部１５１と、利用者１０２からの入出力を受け付けるパッケージ化支援画面１５２とを備え、利用者１０２が開発したインスタンス１４３のパッケージの登録等を支援する。

なお、以降の図および説明では、実行環境１４０としては、Ｋｕｂｅｒｎｅｔｅｓ、デプロイ処理としては、Ｈｅｌｍ、インストールイメージ１３１としては、Ｈｅｌｍを内包したＣＮＡＢに従うコンテナイメージを例に挙げて説明する。しかしながら、本実施の形態は、上述の構成に限られるものではない。例えば、実行環境１４０としては、パブリッククラウドサービスのＩａａＳ（Infrastructure as a Service）、実行環境１４０に構築する対象としては、コンテナではなく仮想サーバ、デプロイ処理としては、Ｔｅｒｒａｆｒｏｍといった組合せを採用してもよい。

図２は、パッケージソースコード１１１のディレクトリ構成の一例を示す図である。本例は、コンテナによるインストールイメージ１３１と、アプリインスタンス１４１が入ったコンテナとしてアプリイメージ１３２を作成するものである。

パッケージソースコード１１１には、実行環境１４０への実際のデプロイ処理を行うためのツールを格納したｂｉｎディレクトリ２０１、Ｃｏｎｆｉｇ１４２を作成するためのひな型のファイル群であるｃｈａｒｔディレクトリ２０２、インストールイメージ１３１を作成するためのＤｏｃｋｅｒｆｉｌｅ２０３、パッケージ管理情報１３３を作成するためのデータ、メタデータ等を記述したｂｕｎｄｌｅ．ｊｓｏｎ２０４、アプリイメージ１３２を作成するためのファイル群を格納したａｐｐｓディレクトリ２０５等が含まれる。

パッケージソースコード１１１を用いてＣＩシステム１２０がビルド処理を行うこととなる。より具体的には、インストールイメージ１３１の作成として、実行環境１４０への実際のデプロイ処理を行うツールであるｈｅｌｍコマンド２０６、ｃｈａｒｔディレクトリ２０２等を含んだコンテナイメージが作成される。この場合、実際のデプロイ処理は、コンテナイメージの実行を経由してｈｅｌｍコマンド２０６がｃｈａｒｔディレクトリ２０２を伴って実行されることでデプロイ処理が行われる。ｃｈａｒｔディレクトリ２０２には、ひな型のファイル群（一例がｄｅｐｌｏｙ．ｙａｍｌ２０７）、ひな型のファイル群に与える変数および当該変数のデフォルト値を指定する変数ファイル（一例がｖａｌｕｅｓ．ｙａｍｌ２０８）等が含まれる。ｄｅｐｌｏｙ．ｙａｍｌ２０７およびｖａｌｕｅｓ．ｙａｍｌ２０８については、図４を用いて後述する。また、ａｐｐｓディレクトリ２０５の情報等を用いてアプリイメージ１３２も同様に作成される。

以降、ひな型のファイル群であるｃｈａｒｔディレクトリ２０２全体をテンプレート情報、ｄｅｐｌｏｙ．ｙａｍｌ２０７のようなひな型のファイルをテンプレートファイル、ｖａｌｕｅｓ．ｙａｍｌ２０８のような変数およびデフォルト値を含むファイルを変数ファイルと呼ぶこととする。

図３は、ポータル画面１３５の一例を示す図である。

ポータル画面１３５では、デプロイ処理するパッケージが利用者１０２により選択される画面を示している。この他、ポータル画面１３５は、デプロイ処理により構築されたインスタンス１４３の情報、当該情報を管理するための画面等を備えていてもよい。

ポータル画面１３５におけるパッケージの選択では、例えば、パッケージをフィルタするためのキーワードを表示するペイン３１０、パッケージの一覧を表示するペイン３２０、選択しているパッケージの情報３３１、デプロイ処理を実行するためのデプロイボタン３３２等を表示するペイン３３０等が含まれる。１つのパッケージを示すパッケージ表示３２１には、パッケージの識別子、パッケージの名称、パッケージのバージョン等が表示される。さらに、パッケージ表示３２１を押下することにより、別画面にて詳細情報、例えば、より詳細な説明、使い方、使用上の注意事項、問合せ先等の情報が表示されるような機能を備えていてもよい。

図４は、デプロイ処理に係るデータの一例を示す図である。図４を用いて、インストールイメージ１３１に含まれるテンプレート情報（ｄｅｐｌｏｙ．ｙａｍｌ２０７、ｖａｌｕｅｓ．ｙａｍｌ２０８等）と、テンプレート情報からデプロイ処理によって生成されるＣｏｎｆｉｇ１４２との関係を説明する。

テンプレート情報は、一般に、Ｃｏｎｆｉｇ１４２のひな型であるｄｅｐｌｏｙ．ｙａｍｌ２０７のようなテンプレートファイル群と、Ｃｏｎｆｉｇ１４２のひな型に与える変数および当該変数のデフォルト値が定義されたｖａｌｕｅｓ．ｙａｍｌ２０８のような形式である変数ファイルとを含む。

例えば、記述４０１（「ｉｍａｇｅ：｛｛．Ｖａｌｕｅｓ．ｉｍａｇｅ｝｝」）は、ｖａｌｕｅｓ．ｙａｍｌ２０８に定義された記述４１１（「ｉｍａｇｅ：ＮｏｄｅＲＥＤ：１」）を読み込むことを意味している。以降、例えば、「ｉｍａｇｅ：｛｛．Ｖａｌｕｅｓ．ｉｍａｇｅ｝｝」のうち「ｉｍａｇｅ：」（特にｉｍａｇｅ）をｋｅｙと呼び、｛｛．Ｖａｌｕｅｓ．ｉｍａｇｅ｝｝」の部分をｖａｌｕｅと呼ぶ。特に、上述のようにｋｅｙに対するｖａｌｕｅが変数（本例では、｛｛｝｝で表記）となっている場合は（ｋｅｙが）「変数化」されている、と呼ぶこととする。また、例えば、変数化を示す「｛｛．Ｖａｌｕｅｓ．ｉｍａｇｅ｝｝」のうち、「.Ｖａｌｕｅｓ.」は変数ファイルに記述されたＫｅｙを参照することを示す接頭語であり、変数ファイルにおける変数のデフォルト値（読み込み箇所）を特定可能な表記である「ｉｍａｇｅ」を変数ｋｅｙ（変数識別子）と呼ぶ。

そして、デプロイ処理時に、変数ｋｅｙ「ｉｍａｇｅ」の変数に値を指定しなければ、デフォルト値である「ＮｏｄｅＲＥＤ：１」が用いられ、この場合、Ｃｏｎｆｉｇ１４２の記述４２１が生成される。なお、デプロイ処理時に、別の値、例えば、変数ｋｅｙ「ｉｍａｇｅ」の変数に値「ＦｌｏｗＥｄｉｔｏｒ：１」を指定すれば、記述４２１は、「ｉｍａｇｅ：ＦｌｏｗＥｄｉｔｏｒ：１」のように生成される。

さらに、テンプレートファイルには、プログラム的な要素、例えば、記述４０２のような要素（例えば、ｉｆ文）を含んでいてもよい。これによって、対応する変数である記述４１２が「ｔｒｕｅ」である場合に、Ｃｏｎｆｉｇ１４２上に記述４２２のように現れ、逆に「ｆａｌｓｅ」の場合は、現れないような制御を行うことができる。

以上のようにしてアプリインスタンス１４１の動作等を規定するＣｏｎｆｉｇ１４２が生成される。Ｃｏｎｆｉｇ１４２は、一般に、表現する動作の概念に対応付いた階層構造で表現されることが多い。例えば、「ｉｍａｇｅ：ＮｏｄｅＲＥＤ：１」は、「ｓｐｅｃ」を親として持つオブジェクトの要素の１つであることを意味している。この特徴を用い、ルートからの階層を「.」を用いてつなげることで、特定の要素を一意に表すこととする。この表現においては、記述４２１は、「ｓｐｅｃ．ｉｍａｇｅ：ＮｏｄｅＲＥＤ：１」のように表現される。テンプレートファイルが複数存在（ｄｅｐｌｏｙ．ｙａｍｌ２０７以外も存在）するような場合には、最初にファイル名を付加する等で対応することができる。

以上は、ｈｅｌｍの流儀に従い、ＹＡＭＬと呼ばれるｋｅｙとｖａｌｕｅとの形式で表現されるが、ＹＡＭＬ以外の形式、例えば、ＪＳＯＮ等、別の形式であってもよい。ここで、ｋｅｙとｖａｌｕｅとは、例えば、記述４２１の例では、「ｉｍａｇｅ」、「ｓｐｅｃ．ｉｍａｇｅ」がｋｅｙであり、「ＮｏｄｅＲＥＤ：１」がｖａｌｕｅのことである。

図５は、パッケージ化支援システム１５０に係る構成の一例を示す図である。

図５に示すように、リポジトリ１１０と、ＣＩシステム１２０と、マーケットプレイスシステム１３０と、実行環境１４０と、パッケージ化支援システム１５０と、開発者（例えば、利用者１０２）が開発等に使用する端末５０１との各構成要素は、ネットワーク５１１を介して通信可能に接続されている。

各構成要素は、ＣＰＵ（Central Processing Unit）、メモリ、ハードディスク等を備える計算機で動作（機能）する。各構成要素の動作は、それぞれ物理的に異なる計算機上で動作していてもよいし、仮想サーバと呼ばれる物理的な計算機を論理的に分割された計算機の単位で動作していてもよい。また、各構成要素の動作は、１台の計算機または複数の計算機のクラスタ上で実行されるタスク（プロセス、コンテナとも呼ばれる）単位であってもよい。

また、ネットワーク５１１は、インターネット、ローカルエリアネットワーク（ＬＡＮ： Local Area Network）、専用の通信網、ＶＬＡＮ（Virtual Local Area Network）等に代表される仮想的なネットワークであってもよい。各構成要素と、端末５０１および実行環境１４０の間のネットワークは、利用する利用者１０２の違いから、ネットワークセグメントが異なっていたり、ファイアウォール等で論理的に通信制御されていたりすることが一般的である。さらに、端末５０１および実行環境１４０も、利用者１０２の手元にある計算機とパブリッククラウドサービスとのように異なることもある。

リポジトリ１１０は、パッケージソースコード１１１を１または複数記憶する。リポジトリ１１０は、マーケットプレイスシステム１３０にインストールイメージ１３１、アプリイメージ１３２およびパッケージ管理情報１３３を追加するに十分な情報を備えているならば、複数のリポジトリ１１０からなっていてもよい。また、パッケージソースコード１１１が複数の単位、例えば、インストールイメージ１３１、アプリイメージ１３２、パッケージ管理情報１３３といった構成要素単位にソースコードが分かれていてもよい。

ＣＩシステム１２０は、ＣＩ管理情報５２１を用いてパッケージソースコード１１１をビルドし、マーケットプレイスシステム１３０にインストールイメージ１３１とアプリイメージ１３２とを登録するとともに、パッケージ管理情報１３３にパッケージ情報を追加する。なお、本実施の形態において、ＣＩシステム１２０は、必須ではなく、ビルド処理とマーケットプレイスシステム１３０への各種情報の登録とを人が手作業で行い、ＣＩ管理情報５２１をデータベース等に登録するといった形態であってもよい。

マーケットプレイスシステム１３０は、インストールイメージ１３１およびアプリイメージ１３２を格納したレジストリ１３４と、パッケージ管理情報１３３と、インスタンス管理情報５３１と、ポータル情報出力部５３２と、デプロイ部５３３とを備える。

インストールイメージ１３１、アプリイメージ１３２、パッケージ管理情報１３３、インスタンス管理情報５３１等の各種の情報、ポータル情報出力部５３２、デプロイ部５３３を実現するためのプログラム等は、図示は省略する１以上の記憶装置に記憶されている。

なお、マーケットプレイスシステム１３０の機能（ポータル情報出力部５３２、デプロイ部５３３等）は、例えば、ＣＰＵがプログラムをメモリに読み出して実行すること（ソフトウェア）により実現されてもよいし、専用の回路等のハードウェアにより実現されてもよいし、ソフトウェアとハードウェアとが組み合わされて実現されてもよい。

ポータル情報出力部５３２は、ポータル画面１３５を、端末５０１または図示は省略する表示装置に表示し、デプロイ部５３３等に指示を渡す処理を行う。デプロイ部５３３は、ポータル情報出力部５３２からの指示を受け、実行環境１４０へのデプロイ処理を行う。デプロイ部５３３の処理については後述する。パッケージ管理情報１３３は、ポータル画面１３５に表示する情報、デプロイ部５３３が用いる情報を保持する。インスタンス管理情報５３１は、パッケージと、パッケージをデプロイした実行環境１４０で実際に動作する実体（インスタンス１４３）とを管理する情報である。なお、インスタンス管理情報５３１については、図９を用いて後述する。

レジストリ１３４は、インストールイメージ１３１およびアプリイメージ１３２を記憶する。レジストリ１３４は、便宜上１つとしているが、パッケージ管理情報１３３と結びつくのであれば、複数であってもよい。レジストリ１３４の例は、インストールイメージ１３１およびアプリイメージ１３２が何れもコンテナイメージである場合は、ＤｏｃｋｅｒＲｅｇｉｓｔｒｙ等に代表されるコンテナレジストリであり、バイナリである場合は、バイナリを配布する機能を有した各種レジストリである。さらには、異なる複数種類のイメージ（例えば、バイナリおよびコンテナ）が混在する場合は、レジストリ１３４は、複数の異なる種類のレジストリ１３４からなるものであってもよい。レジストリ１３４は、その他、オブジェクトストレージ装置等、ネットワーク経由で利用できるストレージ装置等であってもよい。

実行環境１４０は、デプロイ処理されたパッケージのインスタンス１４３が動作する環境である。実行環境１４０としては、クラウドサービスでもよいし、物理サーバのクラスタ等であってもよい。また、実行環境１４０については、便宜上１つで表現しているが、パッケージによっては複数かつ異なる環境（例えば、仮想サーバが動作する環境と、ＳａａＳ（Software as a Service）と呼ばれるアプリケーションをクラウド型で提供するサービス）が混在するようなものであってもよい。

パッケージ化支援システム１５０は、対応関係情報５４１と、変換ルール情報５４２と、変更差分情報５４３と、パッケージ化部１５１と、イメージ化部５４４と、開発支援画面を利用者１０２に表示するための支援情報出力部５４５とを備える。

対応関係情報５４１、変換ルール情報５４２、変更差分情報５４３等の各種の情報、パッケージ化部１５１、イメージ化部５４４、支援情報出力部５４５等を実現するためのプログラム等は、図示は省略する１以上の記憶装置に記憶されている。

なお、パッケージ化支援システム１５０の機能（パッケージ化部１５１、イメージ化部５４４、支援情報出力部５４５等）は、例えば、ＣＰＵがプログラムをメモリに読み出して実行すること（ソフトウェア）により実現されてもよいし、専用の回路等のハードウェアにより実現されてもよいし、ソフトウェアとハードウェアとが組み合わされて実現されてもよい。付言するならば、パッケージ化支援システム１５０の各構成要素の詳細については後述する。

端末５０１は、利用者１０２がマーケットプレイスシステム１３０を用いてパッケージを選択したり、デプロイ処理の指示を行ったり、デプロイ処理されたパッケージのインスタンス１４３を管理したり、インスタンス１４３を変更（開発）したり、パッケージ化支援システム１５０を用いてパッケージを作成したりする作業用の端末である。

なお、ポータル情報出力部５３２が提供する画面、支援情報出力部５４５が提供する画面等には、例えば、端末５０１がブラウザによりアクセスして利用する形態がある。この他、ポータル情報出力部５３２および支援情報出力部５４５は、ＡＰＩ（Application Program Interface）を提供し、描画処理を行うプログラムが、端末５０１に事前にダウンロードされてインストールされ、設定が行われた上で使うものであってもよい。また、実行環境１４０等が端末５０１と同等の機能を備える場合は、端末５０１は、構成要素としてなくてもよい。

図６は、ＣＩ管理情報５２１の一例を示す図である。

ＣＩ管理情報５２１は、パッケージソースコード１１１を一意に識別するための識別子であるソースＩＤ６０１、パッケージを一意に識別するための識別子であるパッケージＩＤ６０２、インストールイメージ１３１を一意に識別するための識別子であるインストーラＩＤ６０３、アプリイメージ１３２を一意に識別するための識別子であるアプリイメージＩＤ６０４等の情報を保持する。

ソースＩＤ６０１は、例えば、パッケージソースコード１１１が格納されたリポジトリ１１０上のＵＲＬ（Uniform Resource Locator）等である。パッケージＩＤ６０２は、パッケージ管理情報１３３内と共通の識別子であり、一意にパッケージを識別するための識別子である。パッケージＩＤ６０２の発行は、ＣＩシステム１２０が行ってもよいし、マーケットプレイスシステム１３０が行ってもよいし、提供者１０１が指定する形態であってもよい。インストーラＩＤ６０３は、インストーラを識別するためのＩＤであり、例えば、インストールイメージ１３１が格納された場所のＵＲＬ等である。インストールイメージ１３１がインストールのためのコンテナイメージである場合は、当該コンテナイメージが格納されたレジストリ１３４上のパスおよびバージョン等のタグ情報（例えば、registry-url/pathto/image:tag）、コンテナイメージを特定するためのハッシュ値等である。アプリイメージＩＤ６０４も同様にアプリイメージ１３２へのＵＲＬ等である。

ＩＤ群（ソースＩＤ６０１、パッケージＩＤ６０２、インストーラＩＤ６０３およびアプリイメージＩＤ６０４）の関係は、パッケージＩＤ６０２を主キーとして（１つに対して）、ソースＩＤ６０１、インストーラＩＤ６０３およびアプリイメージＩＤ６０４の各々は、１または複数であってもよい。また、アプリイメージＩＤ６０４は、ＣＩ管理情報５２１に直接含まれず、インストーラＩＤ６０３が指すインストールイメージ１３１の中に含まれるような形態であってもよい。

図７は、パッケージ管理情報１３３の一例を示す図である。

パッケージ管理情報１３３は、ＣＩ管理情報５２１に含まれるパッケージＩＤ６０２と同じ意味であるパッケージＩＤ７０１と、同じくインストーラＩＤ６０３と同じ意味であるインストーラＩＤ７０２との情報を保持する。

さらに、パッケージ管理情報１３３は、マーケットプレイスシステム１３０の管理上の情報と、ポータル画面１３５に表示するための情報とを含むメタデータ７０３（Ｍｅｔａｄａｔａ）の情報を保持する。例えば、メタデータ７０３は、ポータル画面１３５に表示する際のタイトル７０４（Ｔｉｔｌｅ）、説明文７０５（Ｄｅｓｃｒｉｐｔｉｏｎ）、その他、当該パッケージが使用できるエリア７０６（Ｒｅｇｉｏｎ）、使用できる言語７０７（Ｌａｎｇｕａｇｅ）、使用が想定される分野７０８（Ｆｉｅｌｄ）、使用可能な国等、利用者１０２の属性に応じてパッケージの表示有無等を制御するため情報等である。メタデータ７０３は、提供者１０１が入力することを想定しており、対応するパッケージソースコード１１１の情報に含まれることが一般的である。この他、利用者１０１がマーケットプレイスシステム１３０を用いて入力する形態であってもよいし、推定可能な情報については、ＣＩシステム１２０、マーケットプレイスシステム１３０の中で補完するような形態であってもよい。

なお、１つのパッケージＩＤ７０１に対してインストーラＩＤ７０２が複数であってもよく、対応するインストールイメージ１３１に実行順序がある場合は、実行順序の情報を含んでいてもよい。また、マーケットプレイスシステム１３０としてインストール時に標準で指定するパラメータがある場合（例えば、標準で使用するアプリイメージ１３２が格納されたレジストリ１３４のＵＲＬ等）がある場合は、その値をパッケージ管理情報１３３が保持するようにしてもよい。

図８は、インスタンス管理情報５３１の一例を示す図である。

インスタンス管理情報５３１は、実行環境１４０にデプロイ処理したパッケージの実体（インスタンス１４３）の一意な識別子であるインスタンスＩＤ８０１、デプロイ処理したパッケージを識別するためのパッケージＩＤ８０２、成功、失敗等のデプロイ処理の結果の情報であるステータス８０３（Ｓｔａｔｕｓ）、デプロイ処理を実施したりデプロイ処理を管理したりする利用者１０２を一意に識別する利用者ＩＤ８０４（ＵｓｅｒＩＤ）、実行環境１４０を特定するための情報であるプラットフォーム８０５（Ｐｌａｔｆｏｒｍ）、プラットフォーム８０５にアクセスするための認証情報であるクレデンシャル８０６（Ｃｒｅｄｅｎｔｉａｌ）、デプロイ処理時に利用者１０２が入力してインストールイメージ１３１に設定された入力値８０７（ＩｎｐｕｔＶａｌｕｅｓ：デフォルト値）等の情報を保持する。

インスタンスＩＤ８０１は、マーケットプレイスシステム１３０上でデプロイ処理したパッケージの実体を一意に識別して管理するものであり、例えば、マーケットプレイスシステム１３０が自動的に発行するようなものである。インスタンスＩＤ８０１については、一意性が担保されるＵＵＩＤ（Universal Unique Identifier）、パッケージＩＤおよび通し番号等で生成することができる。利用者ＩＤ８０４は、利用者１０２を一意に識別するためのものであり、例えば、ポータル画面１３５にログインする際に入力するものである。

さらに、実際のデプロイ処理では、デプロイ先である実行環境１４０の情報（アクセス先等）であるプラットフォーム８０５とプラットフォーム８０５にアクセスするための情報（アクセスキー、シークレットキー、パスワード等）であるクレデンシャル８０６が必要であることから、インスタンス管理情報５３１は、こうした情報を保持している。利用者ＩＤ８０４、プラットフォーム８０５およびクレデンシャル８０６については、利用者１０２が実行環境１４０を準備する場合は、デプロイ処理時に、ポータル画面１３５から入力を受け付けることで、マーケットプレイスシステム１３０は、取得することができる。

また、マーケットプレイスシステム１３０自体が実行環境１４０を用意する場合は、マーケットプレイスシステム１３０自身がデプロイ処理時に、プラットフォーム８０５およびクレデンシャル８０６の情報を補完することができる。なお、クレデンシャル８０６は、秘密情報であることから、何らかの暗号化処理等が実施されていることが一般的である。また、入力値８０７は、ｖａｌｕｅｓ．ｙａｍｌ２０８のような変数ファイルのデフォルト値から変更した値の集合である。なお、インスタンス管理情報５３１を用いたデプロイ処理については、後述のフローチャートを用いて説明する。

図９は、対応関係情報５４１の一例を示す図である。

対応関係情報５４１は、インスタンスＩＤ９０１、パッケージＩＤ９０２、ソースＩＤ９０３、差分ＩＤ９０４（ＤｉｆｆＩＤ）、イメージ変更Ｆｌａｇ９０５等の情報を保持する。

インスタンスＩＤ９０１、パッケージＩＤ９０２およびソースＩＤ９０３は、ＣＩ管理情報５２１、パッケージ管理情報１３３等の同名のＩＤと同じ意味であり、ＣＩ管理情報５２１およびパッケージ管理情報１３３の情報を組み合わせて生成されるものである。

差分ＩＤ９０４およびイメージ変更Ｆｌａｇ９０５は、デプロイ処理されたインスタンス１４３に対して利用者１０２が行った変更に関する情報である。差分ＩＤ９０４は、Ｃｏｎｆｉｇ１４２に対して利用者１０２が行った変更の内容を一意に識別するための識別子である。差分ＩＤ９０４が指す内容については、図１１を用いて後述する。

また、イメージ変更Ｆｌａｇ９０５は、デプロイ処理されて実行環境１４０で動作するアプリインスタンス１４１のアプリイメージ１３２に対して変更が行われたかを判断するための情報である。イメージ変更Ｆｌａｇ９０５では、変更がある場合は「ｔｒｕｅ」、変更がない場合は「ｆａｌｓｅ」として管理される。ここで、イメージ変更Ｆｌａｇ９０５とは、アプリインスタンス１４１に対して、もとになったアプリイメージ１３２から変更があったか否かを判断するフラグ情報である。アプリイメージ１３２の変更の例としては、アプリインスタンス１４１が備えるインターフェースを用いた設定の変更、設定ファイルの変更、アプリインスタンス１４１に含まれるバイナリに対するパッチ適用等いったものである。

イメージ変更Ｆｌａｇ９０５が必要となるのは、開発したインスタンス１４３をパッケージ化する場合、もとになったアプリイメージ１３２に対する変更も、新たに作成するパッケージに反映したい場合が多々あるためである。そこで、現在、実行環境１４０内で動いているアプリインスタンス１４１を新たなアプリイメージ１３２とし、新たなパッケージに含めることで上述のニーズに対応するものとする。

なお、イメージ変更Ｆｌａｇ９０５の設定（値）は、例えば、利用者１０２がパッケージ化支援システム１５０を利用するときに入力する形で取得してもよいし、もとになったアプリイメージ１３２との差分から自動的に判断するような形であってもよいし、利用者によるアプリインスタンス１４１への操作ログから判断するような形であってもよい。また、インスタンス１４３が複数のアプリイメージ１３２からなる場合は、イメージ変更Ｆｌａｇ９０５は、アプリイメージ１３２ごとに変更の有無が記載されるような形態であってもよい。対応関係情報５４１の生成および利用については、フローチャートを用いて後述する。

図１０は、変換ルール情報５４２の一例を示す図である。

変換ルール情報５４２は、優先度を意味するプライオリティ１００１（Ｐｒｉｏｒｉｔｙ）、変換ルールの対象となるｋｅｙを意味するターゲットキー１００２（ＴａｒｇｅｔＫｅｙ）、対応を分岐するためのフラグ情報としての値変更Ｆｌａｇ１００３および変数化Ｆｌａｇ１００４等の情報を保持する。変換ルール情報５４２は、実行環境１４０で動作するインスタンス１４３のＣｏｎｆｉｇ１４２等をパッケージ化する際に、どのように変更するかを定めたものであり、変換ルール情報５４２の１行が１つの変更ルールを示している。

プライオリティ１００１は、優先度情報であり、適用する優先度を意味し、本例では、「１」が優先度が最も高く、数が大きいほど優先度が低いことを意味する。また、変換ルール情報５４２に定義されないものという意味で末尾に「ｄｅｆａｕｌｔ」といった概念を含んでいてもよい。

ターゲットキー１００２（ＴａｒｇｅｔＫｅｙ）は、Ｃｏｎｆｉｇ１４２内に含まれるｋｅｙ（例えば、記述４２１の「ｉｍａｇｅ」）に対応する。なお、ここでは、ｋｅｙの単体のみで記述しているが、これ以外の記述として正規表現による記載、階層構造を含んだ記述（例えば、記述４２１では「ｓｐｅｃ．ｉｍａｇｅ」）であってもよい。

値変更Ｆｌａｇ１００３と変数化Ｆｌａｇ１００４とは、Ｃｏｎｆｉｇ１４２のもとになったパッケージのテンプレート情報から、新たなパッケージのテンプレート情報を生成する際に、どのように変更するかを制御するためのフラグである。当該フラグの具体的な用法についてはフローチャートを用いて後述するが、当該フラグは、ｋｅｙの特性に応じて変数化するか否かと、今回のインスタンス１４３の値を採用するか否かと、を判断するための情報である。

例えば、以下のような場合に用いることを想定するものである。「ｓｅｃｒｅｔ」、「ｐａｓｓｗｏｒｄ」等のように、インスタンス１４３毎に固有かつ秘密にすべき情報に対応するｋｅｙである場合、もとのパッケージから変更しない（値変更Ｆｌａｇ１００３が「ｆａｌｓｅ」）、かつ、仮に変数ファイルになくテンプレートファイルに直接記載されている（例えば、ｄｅｐｌｏｙ．ｙａｍｌ２０７に記載されている）場合には、次のパッケージでも変数として扱わない（変数化Ｆｌａｇ１００４も「ｆａｌｓｅ」）、といった処理を行うものである。この他、「ｖｏｌｕｍｅ」、「ｉｐａｄｄｒｅｓｓ」のように、インスタンス１４３に固有ではある（すなわち、インスタンス１４３毎に変更となる）が、変数化されていないのであれば、変数化すべきようなものもある。この場合には、インスタンス１４３の値が有用とならないため、値変更Ｆｌａｇ１００３を「ｆａｌｓｅ」、変数化Ｆｌａｇ１００４を「ｔｒｕｅ」と表現する。

変換ルール情報５４２は、提供者１０１、マーケットプレイスシステム１３０およびパッケージ化支援システム１５０の管理者等により、利用者１０２がパッケージ化支援システム１５０を利用するより前に定義が行われるものである。

図１１は、変更差分情報５４３の一例を示す図である。

変更差分情報５４３は、対応関係情報５４１の差分ＩＤ９０４と対応付く識別子である差分ＩＤ１１０１（ＤｉｆｆＩＤ）、Ｃｏｎｆｉｇ１４２のｋｅｙの値を特定するための情報であるターゲットキーパス１１０２（ＴａｒｇｅｔＫｅｙＰａｔｈ）、変更前の値である変更前１１０３（Ｂｅｆｏｒｅ）と、変更後（すなわちパッケージ化の開始時）の値である変更後１１０４（Ａｆｔｅｒ）等の情報を保持する。変更前１１０３および変更後１１０４は、ターゲットキーパス１１０２毎に保持される。

例えば、図１１において、「ｓｐｅｃ．ｒｅｓｏｕｒｃｅ．ｒｅｑｕｅｓｔ．ｃｐｕ」で特定されるＣｏｎｆｉｇ１４２上の値は、利用者１０２により、「２」から「４」へ変更されたことを示している。また、変更前１１０３が「−」とは、利用者１０２等によって追加されたことを示し、同じく変更後１１０４が「−」とは、利用者１０２等によって削除されたことを示している。また、変更前１１０３と変更後１１０４との両方に値がある場合は、値が変更されたことを示している。

変更差分情報５４３の具体的な生成方法および用法については、フローチャートを用いて後述する。

図１２は、デプロイ処理に係るフローチャートの一例を示す図である。デプロイ処理は、基本的には、デプロイ部５３３が行う処理である。

デプロイ部５３３は、指示待ち状態で待機し、ポータル情報出力部５３２から、利用者１０２がポータル画面１３５において選択したパッケージＩＤおよび入力値（デフォルト値から変更する値）、デプロイ処理に必要なその他の情報（デプロイ先、すなわちプラットフォーム８０５、クレデンシャル８０６）等を受け取る（ステップＳ１２０１）。なお、ポータル情報出力部５３２がインスタンス管理情報５３１に入力値等を更新（追加）し、デプロイ部５３３は、今回対象となるインスタンスＩＤを受け取った上で、デプロイ処理に必要な情報をインスタンス管理情報５３１から参照する形態であってもよい。

続いて、デプロイ部５３３は、パッケージ管理情報１３３を参照し、選択されたパッケージに対応するインストーラＩＤ７０２を特定し、特定したインストーラＩＤ７０２を用いて、対応するインストールイメージ１３１をレジストリ１３４から取得する（ステップＳ１２０２）。インストールイメージ１３１の取得の例としては、例えば、コンテナ型である場合は、コンテナイメージのｐｕｌｌ処理に対応する。

続いて、デプロイ部５３３は、ステップＳ１２０２で取得したインストールイメージ１３１に、ステップＳ１２０１で取得した入力値を伴ってデプロイ処理を実行する（ステップＳ１２０３）。例えば、コンテナ型のインストールイメージ１３１である場合、デプロイ部５３３は、入力値を環境変数としたうえでｒｕｎ処理を行う。また、デプロイ先の実行環境１４０によって処理が変わる場合、デプロイ先に伴う分岐処理については、インストールイメージ１３１内で選択する方法であってもよいし、インストールイメージ１３１がデプロイ先ごとに分かれており、デプロイ先に合わせてインストールイメージ１３１を選択するような方法であってもよい。

なお、デプロイ先の実行環境１４０が、例えば、ｋｕｂｅｒｎｅｔｅｓのようにデプロイ処理されたＣｏｎｆｉｇ１４２に基づいて自動的にＣｏｎｆｉｇ１４２に記載されたアプリインスタンス１４１に対応するアプリイメージ１３２を取得するものではない場合、デプロイ部５３３は、Ｃｏｎｆｉｇ１４２に含まれるアプリインスタンス１４１に対するアプリイメージ１３２をレジストリ１３４から取得し、デプロイ先の実行環境１４０に登録（配信）するといった処理を合わせて行ってもよい。これは、仮想サーバをＩＴリソースとして提供するサービスであるＩａａＳ等の場合によく見られるものである。

続いて、デプロイ部５３３は、デプロイ処理の完了後、デプロイ先の実行環境１４０から実行結果を取得し、インスタンス管理情報５３１を更新し、ポータル情報出力部５３２に通知する（ステップＳ１２０４）。デプロイ処理が同期処理の場合は、デプロイ部５３３は、ステップＳ１２０３およびステップＳ１２０４を連続して行うことができるが、仮に非同期処理の場合は、一定間隔でデプロイ先の実行環境１４０から状態を取得する（ポーリングする）ことを行ってもよい。

また、デプロイ部５３３は、インスタンス管理情報５３１のステータス８０３を、デプロイ処理の状態に合わせて、Ｗａｉｔｉｎｇ→Ｄｅｐｌｏｙｉｎｇ→Ｓｕｃｃｅｓｓ（またはＦａｉｌｅｄ）等のように更新していってもよい。

なお、デプロイ部５３３は、デプロイ先の実行環境１４０からの実行結果を取得する理由は、デプロイ先の実行環境１４０がＣｏｎｆｉｇ１４２の情報に基づいて自動的に決まるパラメータではあるが、ポータル画面１３５に結果として表示したいものも存在するためである。例えば、内部的な管理ＩＤ、プライベートネットワークのＩＰアドレス、アクセス先のＵＲＬ等が、よく見られる要素である。

デプロイ部５３３は、以上の処理を行ったのち、ステップＳ１２０１（指示待ち状態）に処理を戻す。

図１３は、利用者１０２がデプロイ処理されたインスタンス１４３を用いて開発した新たなインスタンス１４３（アプリケーション、ソリューションとも呼ばれる）を、パッケージとしてマーケットプレイスシステム１３０に登録するためのパッケージ化支援処理に係るフローチャートの一例を示す図である。パッケージ化支援処理は、基本的には、パッケージ化部１５１が行う処理である。

パッケージ化部１５１は、利用者１０２による、支援情報出力部５４５が表示するパッケージ化支援画面１５２からの指示に基づいて処理を開始する。パッケージ化部１５１は、パッケージ化支援画面１５２へ入力として、パッケージ化の対象となるインスタンス１４３のインスタンスＩＤを入力として受け付ける。さらに、パッケージ化部１５１は、当該インスタンス１４３が動作する実行環境１４０から必要な情報を取得するため、実行環境１４０にアクセスするためのクレデンシャルを入力として受け取ってもよい。なお、クレデンシャルについては、パッケージ化部１５１は、入力されたインスタンスＩＤをｋｅｙとして、後述のステップＳ１３０１の処理の過程でインスタンス管理情報５３１から取得してもよい。

以降、ステップＳ１３０１〜ステップＳ１３０３では、対応関係情報５４１のレコード（１行）が生成される。

まず、パッケージ化部１５１は、入力されたインスタンス１４３のインスタンスＩＤと、当該インスタンス１４３のもとになったパッケージのソースＩＤとの関係を取得する（ステップＳ１３０１）。より具体的には、パッケージ化部１５１は、マーケットプレイスシステム１３０からインスタンス管理情報５３１を取得し、インスタンスＩＤ８０１を参照し、入力されたインスタンスＩＤに対応するパッケージＩＤ８０２を特定する。さらに、パッケージ化部１５１は、ＣＩシステム１２０からＣＩ管理情報５２１を取得し、パッケージＩＤ６０２を参照し、特定したパッケージＩＤ８０２に一致するソースＩＤ６０１を特定する。以上の処理により、パッケージ化部１５１は、入力されたインスタンスＩＤ、特定したパッケージＩＤ８０２およびソースＩＤ６０１を、対応関係情報５４１のインスタンスＩＤ９０１、パッケージＩＤ９０２およびソースＩＤ９０３とする。

続いて、パッケージ化部１５１は、利用者１０２による、Ｃｏｎｆｉｇ１４２に関する変更の差分を作成（変更差分情報５４３を更新）する（ステップＳ１３０２）。パッケージ化部１５１が作成したものの一例が、変更差分情報５４３の１つの差分ＩＤ１１０１に示されるような情報の集合である。

変更の差分を生成する方法の一例としては、次のようなものがある。まず、パッケージ化部１５１は、今回対象とするインスタンス１４１のインスタンスＩＤ９０１に対応付けられたソースＩＤ９０３から、テンプレート情報を取得し、デフォルト値（すなわち、変数ファイルに記述された、変更していない変数の値）で生成されるＣｏｎｆｉｇ１４２（以下、デフォルトＣｏｎｆｉｇ）を作成する。この処理は、例えば、ｄｒｙ ｒｕｎ機能のような形でインストールイメージ１３１、インストールイメージ１３１の中に含まれるデプロイ処理を行うツールを用いることで実行してもよい。

そして、パッケージ化部１５１は、利用者１０２が変更したＣｏｎｆｉｇ１４２を実行環境１４０から取得し、デフォルトＣｏｎｆｉｇとの差分をとる（例えば、ｄｉｆｆコマンドを発行する）ことにより、変更部分の行を特定する。パッケージ化部１５１は、特定した変更部分の各行のｋｅｙについて、親をたどることでルートからのパス（例えば、ターゲットキーパス１１０２の「ｓｐｅｃ．ｒｅｓｏｕｒｃｅ．ｒｅｑｕｅｓｔ．ｃｐｕ」）を特定する。

そして、パッケージ化部１５１は、変更の種類が値の更新（すなわちｋｅｙ自体はデフォルトＣｏｎｆｉｇにも変更後のＣｏｎｆｉｇ１４２にも存在し、値のみが変更）である場合、変更前１１０３にデフォルトＣｏｎｆｉｇの当該行の値（ｖａｌｕｅ）を設定し、変更後１１０４にＣｏｎｆｉｇ１４２の当該行の値（ｖａｌｕｅ）を設定する。パッケージ化部１５１は、変更の種類が追加（すなわち、デフォルトＣｏｎｆｉｇには存在しない）である場合、変更前１１０３に存在しないこと意味する「−」を設定し、変更後１１０４にＣｏｎｆｉｇ１４２の当該行の値（ｖａｌｕｅ）を設定する。パッケージ化部１５１は、変更の種類が削除（すなわち、デフォルトＣｏｎｆｉｇのみに存在）である場合、変更前１１０３にデフォルトＣｏｎｆｉｇの当該行の値を設定し、変更後１１０４に存在しないこと意味する「−」を設定する。

以上のように、パッケージ化部１５１は、変更されたｋｅｙ（ターゲットキーパス１１０２）に対する変更の前後の値（変更前１１０３および変更後１１０４）を作成し、変更差分情報５４３を更新する。

さらに、パッケージ化部１５１は、利用者１０２による、アプリイメージ１３２に関する変更があるかを特定する（ステップＳ１３０３）。一例としては、パッケージ化支援画面１５２の入力として、変更を加えた（または、別のアプリイメージ１３２としたい）アプリインスタンス１４１（表示上はもとになったアプリイメージ１３２でもよい）を利用者１０２自身に入力してもらい、入力された情報を使うことである。

また、パッケージ化部１５１は、Ｃｏｎｆｉｇ１４２から実行環境１４０で動作するアプリインスタンス１４１を特定し、アプリインスタンス１４１のアプリイメージ１３２と、もとになったレジストリ１３４に格納されたアプリイメージ１３２との差分をとることで変更されたアプリイメージ１３２を特定してもよい。差分のとり方としては、全比較のほか、コンテナ型ではハッシュ値を用いた比較を行うことができる。また、パッケージ化部１５１は、一律（すなわち全て）の実行環境１４０で動くアプリインスタンス１４１のアプリイメージ１３２を変更ありとして扱ってもよい。このようにして特定したアプリイメージ１３２の変更の有無を対応関係情報５４１のイメージ変更Ｆｌａｇ９０５の値（変更ありなら「ｔｒｕｅ」、変更なしなら「ｆａｌｓｅ」）に設定する。

以降で、パッケージ化に伴うイメージ化の処理（ステップＳ１３０４とステップＳ１３０５）、パッケージソースコード１１１（Ｃｏｎｆｉｇ１４２のもとになるテンプレート情報）への反映処理（ステップＳ１３０６）について説明する。なお、これらら２つの処理は、イメージ化の処理により生成される新しいアプリイメージＩＤも反映処理に用いることから、この順として記載して説明している。

まず、イメージ化の処理について説明する。パッケージ化部１５１は、パッケージ化の対象となるインスタンス１４３に対するイメージ変更Ｆｌａｇ９０５を参照し、アプリイメージ１３２に変更が発生したか否かを判定する（ステップＳ１３０４）。パッケージ化部１５１は、変更が発生したと判定した場合（イメージ変更Ｆｌａｇ９０５が「ｔｒｕｅ」である場合）、ステップＳ１３０５に処理を移し、変更が発生していないと判定した場合（イメージ変更Ｆｌａｇ９０５が「ｆａｌｓｅ」である場合）、ステップＳ１３０６に処理を移す。なお、パッケージ化部１５１は、インスタンス１４３に複数のアプリインスタンス１４１が含まれる場合、アプリイメージ１３２ごとに本処理を実施する。

そして、パッケージ化部１５１は、変更が発生したと判定した場合、イメージ化部５４４に当該アプリインスタンス１４１のアプリイメージ１３２の生成（イメージ化）を指示する（ステップＳ１３０５）。イメージ化部５４４によるイメージ化処理については、図１４に示すフローチャートを用いて後述する。

その後、パッケージ化部１５１は、パッケージソースコード１１１（テンプレート情報）への反映処理を実施する（ステップＳ１３０６）。反映処理（テンプレート情報生成処理）については、図１５および図１６に示すフローチャートを用いて後述する。

パッケージ化部１５１は、以上の処理結果を支援情報出力部５４５に渡し、支援情報出力部５４５がパッケージ化支援画面１５２に結果を表示する（ステップＳ１３０７）。なお、パッケージ化支援画面１５２の表示例については、図１７を用いて後述する。

そして、パッケージ化部１５１は、パッケージ化支援処理を終了する。なお、パッケージ化部１５１は、パッケージ化支援処理の終了の前に、パッケージ化支援画面１５２において利用者１０２に提示した結果でパッケージを登録するか否かを判断するダイアログを表示し、利用者１０２が登録を選択した場合に、今回生成した結果一式（テンプレート情報、パッケージソースコード１１１、およびアプリイメージ１３２）を新たなパッケージとしてリポジトリ１１０、レジストリ１３４等に格納する、といった処理を行ってもよい。

なお、ステップＳ１３０２では、パッケージ化部１５１は、ソースＩＤ９０３からテンプレート情報を取得すると説明したが、これ以外の情報、バイナリ（例えば、ｂｉｎディレクトリ２０１に含まれるバイナリ、ａｐｐｓディレクトリ２０５に含まれる情報、その他、テストコード等）、すなわちパッケージソースコード１１１一式、および、対象のパッケージＩＤに関連付けられた一式をまとめて取得してもよい（以下、これら情報をパッケージ関連情報と呼ぶ）。

そして、パッケージ化部１５１は、ステップＳ１３０７の利用者１０２への結果表示に合わせてパッケージ関連情報を表示させ、さらには、新たなパッケージの登録において、パッケージ化支援処理で作成したテンプレート情報と合わせて、取得したパッケージ関連情報も登録する、といった処理を行ってもよい。

図１４は、イメージ化処理に係るフローチャートの一例を示す図である。イメージ化処理は、基本的には、イメージ化部５４４が行う処理である。

イメージ化部５４４は、実行環境１４０上で動作するアプリインスタンス１４１のうちイメージ化するもの（ステップＳ１３０５でパッケージ化部１５１によりイメージ化が指示されたアプリイメージ１３２）について処理を開始する。

まず、イメージ化部５４４は、実行環境１４０がアプリイメージ１３２の取得のインターフェース（Ｉ／Ｆ）を備える等により、実行環境１４０から取得したいアプリインスタンス１４１をアプリイメージ１３２として取得可能であるか否かを判定する（ステップＳ１４０１）。イメージ化部５４４は、アプリイメージ１３２を取得可能であると判定した場合、ステップＳ１４０２に処理を移し、アプリイメージ１３２を取得可能でないと判定した場合、ステップＳ１４０３に処理を移す。

ここで、「アプリイメージ１３２として取得可能」とは、例えば、以下のようなものである。

（例１）実行環境１４０が備えるＡＰＩとして、取得したいアプリインスタンス１４１のＩＤ等をｋｅｙとして、アプリイメージ１３２の実体を取得する機能を備える場合

（例２）（例１）に示す方法、関連するツールを組み合わせることでアプリイメージ１３２を取得できる場合
具体例としては、コンテナエンジンがｄｏｃｋｅｒであるｋｕｂｅｒｎｅｔｅｓであり、かつ、管理権限でこれらを管理できる場合、ｋｕｂｅｃｔｌコマンド（ｋｕｂｅｒｎｅｔｅｓの管理ＣＬＩ（Command Line Interface））を用いて取得したいアプリインスタンス１４１が動作するＮｏｄｅ（ｋｕｂｅｒｎｅｔｅｓクラスタを構成する仮想サーバ）を特定し、特定したＮｏｄｅに対してｓｓｈ（Secure Shell）等の手段によりログインし、ｄｏｃｋｅｒコマンド（ｄｏｃｋｅｒの管理ＣＬＩ）によりイメージ化（ｄｏｃｋｅｒ ｃｏｍｍｉｔ）を実施する方法等である。

（例３）（例２）に類似する方法として、実行環境１４０上で、イメージ化処理用のＡｇｅｎｔを動作させ、Ａｇｅｎｔを経由してアプリインスタンス１４１に対応するアプリイメージ１３２を取得できる場合
例えば、ｋｕｂｅｒｎｅｔｅｓでｄｉｎｄ（docker in docker）コンテナをＡｇｅｎｔとして動作させ、ｄｉｎｄコンテナ内でｄｏｃｋｅｒコマンドによりイメージ化する方法である。

なお、上記の手段については、イメージ化部５４４が、実行環境１４０の種類（すなわちプラットフォーム８０５の種類）ごとに異なる方法を保持し、使い分ける形であってもよい。

アプリイメージ１３２を取得する手段がある場合は、イメージ化部５４４は、上述の手段を用いて、アプリイメージ１３２を取得する（ステップＳ１４０２）。

一方、アプリイメージ１３２が直接は取得できない場合は、イメージ化部５４４は、代替処理として、アプリインスタンス１４１内のデータをコピー（フルバックアップ）する（ステップＳ１４０３）。例えば、イメージ化部５４４は、ｋｕｂｅｒｎｅｔｅｓである場合は、対象とするアプリインスタンス１４１に対して「ｋｕｂｅｃｔｌ ｃｐ ｛ｓｏｕｒｃｅ＿ｐａｔｈ｝｛ｔａｒｇｅｔ＿ｐａｔｈ｝」（｛｝内は変数）コマンドを使うことにより、実行中のアプリインスタンス１４１内のデータを全て吸い出すことができる。また、こうしたバックアップを行うためのツール等をアプリインスタンス１４１内、実行環境１４０上で動作させておき、それを用いるものであってもよい。

なお、以上は、アプリインスタンス１４１内の全てのデータをコピーすることを前提に説明しているが、Ｃｏｎｆｉｇ１４２等により利用者１０２が自由に変更できる場所が特定できる場合は、イメージ化部５４４は、その範囲に絞ってコピーを行ってもよい。一例としては、ｋｕｂｅｒｎｅｔｅｓのＣｏｎｆｉｇ１４２である場合は、ＰＶ（Persistent Volume）として当該アプリイメージ１３２にマウントされた記憶領域のみをコピーすれば、基本的には十分である。

イメージ化部５４４は、コピーしたのち、もとになった（すなわちオリジナル）のアプリイメージ１３２を（イメージ化部５４４が動作する場所において）アプリインスタンス１４１として実行し、コピーしたデータを上書きした上で当該アプリインスタンス１４１をイメージ化することにより、利用者１０２が変更を加えたアプリイメージ１３２を再現することができる。

イメージ化部５４４は、このように取得したアプリイメージ１３２の実体に対して、もとになったアプリイメージ１３２のアプリイメージＩＤ６０４とは別のＩＤを付与し、レジストリ１３４に新たに付与した別のＩＤで保存を行う（ステップＳ１４０４）。ここで、別のＩＤとは、全体で一意なＩＤであり、例えば、もとになったアプリイメージ１３２のアプリイメージＩＤ６０４に利用者１０２の識別子、インスタンスＩＤ等の情報をもとにした識別子、ＵＵＩＤ等である。

なお、レジストリ１３４への保存は、このタイミングではなく、パッケージ化部１５１のステップＳ１３０７が終了し、利用者１０２に結果の提示および利用者１０２の登録の承諾をもって実施するような形態であってもよい。ステップＳ１３０７の後にステップＳ１４０４を実施する場合、利用者１０２による変更の結果も反映することができるメリットがある。

そして、イメージ化部５４４は、今回対象とするインスタンス１４３に対応する変更差分情報５４３に変更を追記する。すなわち、イメージ化部５４４は、対象のインスタンス１４３に一致する差分ＩＤ１１０１に対して、取得または生成されたアプリイメージ１３２を指し示す場所（例えば、「ｓｐｅｃ．ｉｍａｇｅ」等）をターゲットキーパス１１０２に設定し、変更前１１０３にもとになったアプリイメージＩＤ６０４を設定し、変更後１１０４に新たに付与したアプリイメージＩＤを設定する。

イメージ化部５４４は、以上の処理を行い、結果の成否、実行結果等をパッケージ化部１５１に通知し、イメージ化処理を終了する。

図１５および図１６は、テンプレート情報生成処理に係るフローチャートの一例を示す図である。テンプレート情報生成処理は、基本的には、パッケージ化部１５１が行う処理である。

まず、パッケージ化部１５１は、対応関係情報５４１を参照し、パッケージ化の対象とするインスタンス１４３のソースＩＤ９０３を用いてリポジトリ１１０からパッケージソースコード１１１の実体（以下、元ソースコード）取得する（ステップＳ１５０１）。

なお、パッケージ化部１５１は、ステップＳ１５０１と合わせて、インスタンス管理情報５３１から対象とするインスタンス１４３の入力値８０７を取得し、ステップＳ１５０１で取得したパッケージソースコード１１１の変数ファイル（例えば、ｖａｌｕｅｓ．ｙａｍｌ２０８）の値を上書きしてもよい。ただし、ステップＳ１３０２で述べたように、入力値８０７の変更も変更差分情報５４３に含まれるはずであることから、通常は入力値８０７の変数ファイルへの反映は不要である。

次に、パッケージ化部１５１は、対象とするインスタンス１４３の変更である、変更差分情報５４３のインスタンス１４３に対応する差分ＩＤ１１０１が示す変更の集合（例えば、「ｄｉｆｆ１」に含まれる｛ターゲットキーパス１１０２、変更前１１０３、変更後１１０４｝の集合）を用いて、元ソースコードに対して、以降の書き換え処理を実施する（ステップＳ１５０２〜ステップＳ１５１０）。

まず、パッケージ化部１５１は、変更の集合における処理対象とするターゲットキーパス１１０２について、階層構造を利用し、元ソースコード上での場所（行、すなわち変更部分）を特定する（ステップＳ１５０３）。

次に、パッケージ化部１５１は、当該ターゲットキーパス１１０２に対応する変更前１１０３と変更後１１０４との値から変更の種別を判別する（ステップＳ１５０４）。より具体的には、パッケージ化部１５１は、変更前１１０３が「−」である場合は「追加」と判断してステップＳ１５０５に処理を移し、変更後１１０４が「−」である場合は「削除」と判断してステップＳ１５０６に処理を移し、それ以外（両方ともに値がある）の場合は、「更新」と判断してステップＳ１５０７に処理を移す。

パッケージ化部１５１は、変更の種別が追加である場合、ターゲットキーパス１１０２が追加の場合（すなわち、元ソースコードのテンプレートファイル上には存在しない場合）、親ｋｅｙの直後に、ターゲットキーパス１１０２および変更後１１０４の値を挿入する（ステップＳ１５０５）。例えば、パッケージ化部１５１は、ターゲットキーパス１１０２の値が「ｓｐｅｃ．ｎａｍｅ」であり、変更後１１０４の値が「４」であるとき、ｄｅｐｌｏｙ．ｙａｍｌ２０７に挿入する場合、「ｓｐｅｃ：」の次の行に「ｓｐｅｃ．ｎａｍｅ：４」を挿入する。親ｋｅｙの直後に挿入する理由は、そうしないと（例えば、ｄｅｐｌｏｙ．ｙａｍｌ２０７で「ｒｅｓｏｕｒｃｅ：」に挿入してしまうと）以降の行の親子関係が変わってしまい、本来の意味をなさなくなるためである。

この挿入処理について、パッケージ化部１５１は、値変更Ｆｌａｇ１００３を考慮した値の変更処理を行ってもよい。詳細は、ステップＳ１５０７で説明するが、値変更Ｆｌａｇ１００３とは、今回使用した値（ターゲットキーパス１１０２をキーと見たときの値）をパッケージに反映するか否かを判定するフラグである。この意味を挿入処理でも採用する。パッケージ化部１５１は、ターゲットキーパス１１０２に対応するターゲットキー１００２の値変更Ｆｌａｇ１００３が「ｔｒｕｅ」である場合は、変更後１１０４の値をそのまま利用し、「ｆａｌｓｅ」である場合は、空（ｎｕｌｌ）、変更前１１０３の値（本例では、「−」）、変更後１１０４ではないダミー値等に書き換えるといった処理を行ってもよい。

また、パッケージ化部１５１は、利用者１０２によるＣｏｎｆｉｇ１４２の修正では、利用者１０２自身が新規に作成、または既存のアプリイメージ１３２に関する設定をＣｏｎｆｉｇ１４２に追加し、アプリインスタンス１４１として動作させる場合がある。例えば、実行環境１４０がｋｕｂｅｒｎｅｔｅｓである場合、ｓｉｄｅｃａｒと呼ばれるデザインパターン等を実現するため、Ｃｏｎｆｉｇ１４２にアプリイメージ１３２を追記することでアプリインスタンス１４１を追加するということは、一般的に行われる操作である。このため、ターゲットキーパス１１０２がアプリインスタンス１４１の追加によるアプリイメージ１３２の追加である場合（例えば、ｋｅｙに「ｉｍａｇｅ」を含む場合）、利用者１０２が追加したアプリインスタンス１４１のイメージ化として、イメージ化部５４４の一連の処理を実施してもよい。

また、パッケージ化部１５１は、変更の種別が削除である場合、元ソースコードのターゲットキーパス１１０２に該当する行（変更内容）を削除する（ステップＳ１５０６）。

また、パッケージ化部１５１は、変更の種別が更新である場合、ターゲットキーパス１１０２に対応する値部分を変更前１１０３から変更後１１０４に変更、または変数化したうえで変数ファイルに追記する、という処理を行う（ステップＳ１５０７）。詳細については図１６を用いて後述する。

基本的には、ターゲットキーパス１１０２は、テンプレートファイルで１箇所であるが、特定の条件下では複数の箇所がマッチする場合（例えば、以下に示す場合）がある。パッケージ化部１５１は、特定の条件に合致する記述があるか否か（ターゲットキーパス１１０２が他にも存在するか否か）を判定する（ステップＳ１５０８）。パッケージ化部１５１は、ターゲットキーパス１１０２が他にも存在すると判定した場合、ステップＳ１５０９に処理を移し、ターゲットキーパス１１０２が他にも存在しないと判定した場合、未処理の変更があるときは、ステップＳ１５０３に処理を移し、未処理の変更がないときは、テンプレート情報生成処理を終了する。

（例１）ターゲットキーパス１１０２が正規表現、配列等により記述されている場合
（例２）テンプレートファイルがプログラム的な条件分岐（ｉｆ／ｅｌｓｅ、ｗｈｉｌｅ、ｓｗｉｃｈ／ｃａｓｅ等）を含み、処理が分岐している場合
（例えば、｛｛ｉｆ．Ｖａｌｕｅｓ．ｆｌａｇ｝｝ｓｐｅｃ．ｉｍａｇｅ：Ａ｛｛ｅｌｓｅ｝｝ｓｐｅｃ．ｉｍａｇｅ：Ｂ｛｛ｅｎｄ｝｝では、「ｓｐｅｃ．ｉｍａｇｅ」は、同じ意味で２か所に表れる）

そして、パッケージ化部１５１は、上記のように、合致する記述が複数ある場合は、以上までの処理で書き換えていない各部分（テンプレートファイルの未書き換えである各行）それぞれについて同種の書き換え処理、すなわちステップＳ１５０４以降の処理を実施する（ステップＳ１５０９）。

パッケージ化部１５１は、以上の処理を、差分ＩＤ１１０１に含まれるターゲットキーパス１１０２全てについて行い、テンプレート情報生成処理を終了する。

図１６を用いて、ステップＳ１５０７の詳細を説明する。

まず、パッケージ化部１５１は、更新の対象となるターゲットキーパス１１０２に一致するｋｅｙに対する値（すなわち「ｋｅｙ：ｖａｌｕｅ」のｖａｌｕｅ部分）が変数化されているか否かを判定する（ステップＳ１６０１）。パッケージ化部１５１は、今回の対象が変数化されていると判定した場合、ステップＳ１６０４に処理を移し、今回の対象が変数化されていないと判定した場合、ステップＳ１６０２に処理を移す。

ここで、変数化とは、変数ファイルで指定する形になっているという意味である。例えば、ｄｅｐｌｏｙ．ｙａｍｌ２０７の「｛｛．Ｖａｌｕｅｓ．ｎａｍｅ｝｝」等が該当する。

変数化されていない場合、パッケージ化部１５１は、変換ルール情報５４２を参照し、対象のターゲットキーパス１１０２のターゲットキー１００２に合致する変数化Ｆｌａｇ１００４を取得する。ここで、ターゲットキー１００２に合致とは、例えば、ターゲットキーパス１１０２が「ｓｐｅｃ．ｉｍａｇｅ」である場合に、末尾のキーである「ｉｍａｇｅ」に合致するものを、プライオリティ１００１が高いものから順に調べる、という意味である。なお、ターゲットキー１００２が正規表現で記述されている場合は、親ｋｅｙを含めての合致となってもよい。

そして、パッケージ化部１５１は、初めて条件に合致した（すなわち一番優先度が高いターゲットキー１００２に合致した）変数化Ｆｌａｇ１００４が「ｔｒｕｅ」であるか否かを判定する（ステップＳ１６０２）。パッケージ化部１５１は、「ｔｒｕｅ」であると判定した場合、ステップＳ１６０３に処理を移し、「ｆａｌｓｅ」であると判定した場合、ステップＳ１６０４に処理を移す。

変数化Ｆｌａｇ１００４が「ｔｒｕｅ」である場合、変数化してよいという意味であり、パッケージ化部１５１は、更新の対象となるターゲットキーパス１１０２の変数化を行う。より具体的には、パッケージ化部１５１は、変数ファイルに含まれる変数ｋｅｙに存在しない新たな変数ｋｅｙを１つ決定し、対象のターゲットキーパス１１０２の値（ｖａｌｕｅ）部分を決定した変数ｋｅｙが意味する変数で置き換える、という処理を行う。

例えば、パッケージ化部１５１は、ターゲットキーパス１１０２がｄｅｐｌｏｙ．ｙａｍｌ２０７の「ｓｐｅｃ．ｒｅｓｏｕｒｃｅ．ｒｅｑｕｅｓｔ．ｃｐｕ」であり、ｖａｌｕｅｓ．ｙａｍｌ２０８に含まれないｋｅｙとして「ｒｅｑ−ｃｐｕ」が利用できる場合、同ｄｅｐｌｏｙ．ｙａｍｌの値が「２」であるものを「｛｛．Ｖａｌｕｅｓ．ｒｅｑ−ｃｐｕ｝｝」とし、ｖａｌｕｅｓ．ｙａｍｌ２０８に「ｒｅｑ−ｃｐｕ：」を挿入する。このとき、ｖａｌｕｅｓ．ｙａｍｌ２０８に記載するデフォルト値については、パッケージ化部１５１は、ステップＳ１６０４〜ステップＳ１６０６の結果をもとに決定する。

変数ｋｅｙについては、ｖａｌｕｅｓ．ｙａｍｌ２０８に含まれない（かつ、デプロイ処理で用いるツールが定める変数の規則に反しない）限り、何でもよい。しかしながら、より適切な決め方としては、ターゲットキー１００２またはターゲットキーパス１１０２ごとに、対応する変数ｋｅｙとしてよく使われている文字列を用いることである。これを実現するため、現在リポジトリ１１０内に存在する全パッケージソースコード１１１における全テンプレートファイルを調査し、ターゲットキーパス１１０２ごとに使われている変数ｋｅｙの頻度を算出し、最も頻度が高いものを優先的に用いることである。例えば、リポジトリ１１０に含まれる全パッケージソースコード１１１およびテンプレートファイルを調査したところ、「ｓｐｅｃ．ｒｅｓｏｕｒｃｅ．ｒｅｑｕｅｓｔ．ｃｐｕ：｛｛．Ｖａｌｕｅｓ．ｒｅｑ−ｃｐｕ｝｝」が５回、「ｓｐｅｃ．ｒｅｓｏｕｒｃｅ．ｒｅｑｕｅｓｔ．ｃｐｕ：｛｛．Ｖａｌｕｅｓ．ｒｅｑ．ｃｐｕ｝｝」が２回である場合、「ｒｅｑ−ｃｐｕ」を変数ｋｅｙとして優先的に使用することを意味する。

なお、パッケージ化部１５１は、変数化するか否かの判断として、他のパッケージのパッケージソースコード１１１のテンプレートファイルでよく変数化されている場合は変数化する、といった処理を行ってもよい。より具体的には、今回対象とするパッケージ以外のパッケージのパッケージソースコード１１１のテンプレートファイルにおいて、当該ターゲットキーパス１１０２で特定される箇所が一定（しきい値）以上の変数化されている場合、今回の処理でも変数化する、といった処理を行うというものである。例えば、全パッケージのパッケージソースコード１１１に含まれるテンプレートファイルのターゲットキーパス１１０２「ｓｐｅｃ．ｒｅｓｏｕｒｃｅ．ｒｅｑｕｅｓｔ．ｃｐｕ」に対応する値が、変数となっているか（すなわち図３の例で「｛｛．Ｖａｌｕｅｓ．ｒｅｑ−ｃｐｕ｝｝」等となっているか）否か（すなわち図３の例で「２」等の固定値となっているか）をカウントする。そして、ターゲットキーパス１１０２に一致する値が変数化されている数が一定回数以上（例えば、２回以上）または一定割合以上（例えば、５０％以上）である場合、今回も変数化する、といった処理を行うものである。

ステップＳ１６０２で行った処理と同様に、パッケージ化部１５１は、更新の対象となるターゲットキーパス１１０２に合致する値変更Ｆｌａｇ１００３を取得し、取得した値変更Ｆｌａｇ１００３の値が「ｔｒｕｅ」であるか否かを判定する（ステップＳ１６０４）。パッケージ化部１５１は、「ｔｒｕｅ」であると判定した場合、ステップＳ１６０５に処理を移し、「ｆａｌｓｅ」であると判定した場合、ステップＳ１６０６に処理を移す。

値変更Ｆｌａｇ１００３の値が「ｔｒｕｅ」である場合、今回の値を採用する（デフォルト値を変更する）という意味であり、パッケージ化部１５１は、ターゲットキーパス１１０２に対応する値として変更後１１０４の値に書き換える（ステップＳ１６０５）。変数化を行っている場合は、パッケージ化部１５１は、変数ファイルの今回追加した変数のデフォルト値として変更後１１０４の値を用いる。

値変更Ｆｌａｇ１００３の値が「ｆａｌｓｅ」である場合、もとのパッケージソースコード１１１の値（変更前１１０３の値）をそのまま利用するという意味であり、パッケージ化部１５１は、ターゲットキーパス１１０２に対応する値として変更前１１０３をそのまま利用する（ステップＳ１６０６）。変数化している場合は、パッケージ化部１５１は、同じくデフォルト値として変更前１１０３の値を用いる。

パッケージ化部１５１は、以上の処理を行って、ステップＳ１５０８以降の処理を行う。

以上、本実施の形態では、パッケージ化の対象となるＣｏｎｆｉｇ１４２は、テンプレート情報および利用者１０２による入力を元にデプロイで生成され、利用者１０２による変更が行われる、としていた。しかしながら、オーケストレーションツール、実行環境１４０等により、利用者１０２が意図しない変更がＣｏｎｆｉｇ１４２に発生する場合がある。例えば、Ｋｕｂｅｒｎｅｔｅｓでは、内部管理のため、デプロイされた時刻（ｋｅｙの例：ＴｉｍｅＳｔａｍｐ）、Ｋｕｂｅｒｎｅｔｅｓ上での一意な識別子（ｋｅｙの例：ＵＵＩＤ）等が自動的にデプロイしたＣｏｎｆｉｇ１４２に挿入（追記）される場合がある。こうした自動挿入のｋｅｙは、インスタンス１４３固有のものであり、パッケージ化の対象から除外すべきものである。よって、Ｃｏｎｆｉｇ１４２において、こうした自動挿入されたｋｅｙを、次に述べるような方法で除外する処理を行ってもよい。

一例としては、一般に自動挿入される箇所（ｋｅｙ）は決まっていることから自動挿入のため変更と判定しない箇所とを事前に定義しておき、変更差分情報の更新（ステップＳ１３０２）において自動挿入の箇所を変更と判定しない、すなわち変更差分情報５４３から除外する、という方法である。また、別の一例としては、変更差分情報５４３としては自動挿入部分も変更として考慮しておき、変更内容の反映挿入処理（ステップＳ１５０５）において、事前に定義された自動挿入の箇所の情報をもとに自動挿入ならば除外する、すなわち自動挿入の箇所は挿入しない、という方法である。

図１７は、パッケージ化支援画面１５２の一例を示す図である。

パッケージ化支援画面１５２は、利用者１０２から今回対象とするインスタンス１４３の識別子１７０１、実行環境１４０にアクセスするための情報１７０２等を受け取り、パッケージ化の結果を利用者１０２に表示する。

このうち、結果として表示される情報が、パッケージ化部１５１の行った処理の結果である（新たなテンプレートファイルがテンプレートファイル１７１０であり、新たな変数ファイルが変数ファイル１７２０である）。さらに、変数化を行った部分１７１１、イメージ化を新たに行ったことによる新たなイメージＩＤ１７２１、値を変更した部分１７２２等、パッケージ化部１５１によって変更が行われた箇所は、変更を強調表示するような表示がなされてもよい。

さらに、イメージ化部５４４がイメージ化を行っている場合は、新たにイメージ化したアプリイメージＩＤやその処理の概要を合わせて表示し、利用者１０２に確認、修正等を行わせるようなインターフェースを備えてもよい。また、新たなパッケージのメタデータ７０３の作成、もとのパッケージに含まれていた付加情報（テストケース、管理情報等）を編集するため、利用者１０２が編集可能な形式で、もとになったパッケージのメタデータ７０３、付加情報等もパッケージ化支援画面１５２に表示する、といったことを行ってもよい。

本実施の形態では、例えば、マーケットプレイスの利用者が、登録されたパッケージを用いて新たなシステムを開発し、新たなシステムを再度マーケットプレイスに登録するユースケースにおいて、もとになったパッケージの情報と開発されたシステムの情報とから、今回登録するシステムのパッケージの内容が提案される。これにより、パッケージ化に関して十分な知識を有しない利用者であっても、新たなパッケージの登録が容易となる。

（２）第２の実施の形態
第１の実施の形態では、実行環境１４０がイメージ化のＡＰＩを備えない場合の代替処理として、データをコピーする処理（ステップＳ１４０３）を例示した。しかしながら、コピーする方法は、処理のオーバーヘッド、アプリイメージ１３２の再現性の観点から充分でない場合がある。一方、利用者１０２がアプリインスタンス１４１を変更する方法の１つとして、利用者１０２側でＣＩシステムを用意し、ＣＩシステムにより、もとのアプリイメージ１３２を用いて新たなアプリイメージ１３２を作成し、新たに作成したアプリイメージ１３２をアプリインスタンス１４１として動作させる場合もある。このとき、上述の特徴を利用することにより、ステップＳ１４０３の問題を解決できる場合がある。本実施の形態では、この点ついて主に説明する。

図１８は、本実施の形態のパッケージ化支援システム１５０に係る構成の一例を示す図である。

図１８に示すように、パッケージシステム１８００は、図５に示すパッケージシステム１００の構成に加えて、利用者用リポジトリ１８１０と利用者用ＣＩシステム１８２０とを含んで構成される。

利用者用リポジトリ１８１０には、アプリイメージ１３２を変更するためのソースコード１８１１が格納されている。一例としてアプリイメージ１３２がコンテナ型である場合は、修正内容をアプリイメージ１３２に反映するもとになる設定ファイルおよびスクリプト、アプリイメージ１３２をビルドするためのビルドファイル（例えば、Ｄｏｃｋｅｒｆｉｌｅ）等である。このうちビルドファイルのイメージ指定（ＤｏｃｋｅｒｆｉｌｅではＦＲＯＭ）に、今回対象とするアプリインスタンス１４１のもとになったパッケージに含まれるアプリイメージ１３２のアプリイメージＩＤ６０４を指定する。

そして、利用者用ＣＩシステム１８２０は、ソースコード１８１１の情報から、ＣＩシステム１２０が行ったのと同様の処理を行い、利用者１０２が変更したアプリイメージ１３２を生成（ビルド）する。なお、利用者用ＣＩシステム１８２０は、アプリイメージ１３２のビルドに加えて、実行環境１４０のインスタンス１４３内に含まれるアプリインスタンス１４１を、今回新たにビルドしたアプリイメージ１３２の実行状態であるアプリインスタンス１４１への差し替える処理を行ってもよい。

また、パッケージシステム１８００では、上述の差し替えを行うための要素として、利用者１０２が作成したアプリイメージ１３２を登録し、保持するための利用者用レジストリを備えていてもよい。また、利用者用レジストリの代わりにレジストリ１３４に利用者用の領域を持ち、ここに利用者１０２が変更したアプリイメージ１３２を登録して保持するような構成であってもよい。

このようなパッケージシステム１８００において、イメージ化部５４４は、アプリイメージ１３２の作成の２種類の方法（例えば、ステップＳ１４０２に示す取得による方法、ステップＳ１４０３に示すコピーによる方法）に加えて、以下に示すビルドによる方法を実施してもよい。なお、優先する順番としては、再現性が高く処理のコストが低いという観点からは、取得による方法（ステップＳ１４０２）、ビルドによる方法（後述）、コピーによる方法（ステップＳ１４０３）の順が好適である。

以降でビルドによる方法について説明する。

イメージ化部５４４は、利用者１０２がアプリイメージ１３２の変更のために作成したソースコード１８１１を特定するためのソースＩＤを入力として処理を行う。このソースＩＤの入手は、例えば、パッケージ化支援画面１５２において利用者１０２からの入力、Ｃｏｎｆｉｇ１４２にメタ情報（例えば、自由に記載できるメタデータ領域上のコメント、独自拡張ラベル等）として記述（Ｃｏｎｆｉｇ１４２で記入された情報がある場合）、実行環境１４０および利用者用ＣＩシステム１８２０のログから判定（何れもログが取得可能な場合）、によって実施することができる。

そして、イメージ化部５４４は、ソースコード１８１１に含まれるビルドファイルをもとに、利用者１０２のアプリイメージ１３２を再現（ビルド）し、これを新たなアプリイメージ１３２とする。この他、ＣＩシステム１２０、利用者用ＣＩシステム１８２０が利用可能な場合は、その処理を用いてアプリイメージ１３２を取得（またはアプリイメージ１３２が格納されたレジストリ１３４のアプリイメージＩＤ６０４）によりアプリイメージ１３２の作成の代わりとしてもよい。

本実施の形態によれば、実行環境からアプリイメージを取得できない場合であっても、利用者用ＣＩシステムを用いてアプリイメージを作成することができる。

（３）第３の実施の形態
第１の実施の形態で示したパッケージ管理情報１３３において、パッケージＩＤ７０１とインストーラＩＤ７０２との紐付けと、ポータル画面１３５に表示するため等に利用するメタデータ７０３およびパッケージＩＤ７０１の関係とは、更新のタイミングの違い、実装上の都合等から別々の情報（以下、パッケージＩＤ７０１とインストーラＩＤ７０２とからなるデプロイ管理情報と、メタデータ７０３とパッケージＩＤ７０１とからなるポータル表示情報）に分かれていることもある。

さらには、ポータル表示情報は、ソースコード１１１から生成するのではなく、ポータル画面１３５を用いて提供者１０１が記載するような形態も考えられる。

このように、パッケージ管理情報１３３が、デプロイ管理情報とポータル管理情報とのように２つの情報に分かれる場合であっても、パッケージ化の支援（本アイデアの提供）は可能である。パッケージ化部１５１は、本質的には、デプロイ管理情報があるならば、処理を実施可能であるため、パッケージ管理情報１３３の代わりにデプロイ管理情報を取得すればよい。さらに、パッケージ化の支援という意味において、パッケージ化部１５１がマーケットプレイスシステム１３０からポータル管理情報を取得し、参考情報としてパッケージ化支援画面１５２に表示する等してもよい。

（４）他の実施の形態
なお、上述の実施の形態においては、本発明をパッケージ化支援システムに適用するようにした場合について述べたが、本発明はこれに限らず、この他種々のシステム、装置、方法、プログラムに広く適用することができる。

また、上述の実施の形態において、各テーブルの構成は一例であり、１つのテーブルは、２以上のテーブルに分割されてもよいし、２以上のテーブルの全部または一部が１つのテーブルであってもよい。

また、上述の実施の形態において、説明の便宜上、ＸＸテーブル、ＸＸファイルを用いて各種のデータを説明したが、データ構造は限定されるものではなく、ＸＸ情報等と表現してもよい。

また、上記の説明において、各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記憶装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

上述した実施の形態は、例えば、以下の特徴的な構成を有する。

ソースコード（例えば、パッケージソースコード１１１）を管理する第１の管理部（例えば、リポジトリ１１０）と、ソースコードもとに作成されるパッケージを管理し、利用者（例えば、利用者１０２）が操作する端末から指示されたパッケージをインスタンス（例えば、インスタンス１４３）として所定の実行環境（例えば、実行環境１４０）において利用可能にするマーケットプレイスシステム（例えば、マーケットプレイスシステム１３０）と通信可能なパッケージ化支援システム（例えば、パッケージ化支援システム１５０）であって、パッケージを識別可能な識別情報（例えば、パッケージＩＤ９０２）と、上記パッケージのもとになるソースコードを識別可能な識別情報（例えば、ソースＩＤ９０３）と、上記パッケージのインスタンスを識別可能な識別情報（例えば、インスタンスＩＤ９０１）とが対応付けられた対応関係情報（例えば、対応関係情報５４１）を記憶する記憶装置と、利用者が操作する端末（例えば、端末５０１）から所定のインスタンスのパッケージ化の指示を受信したことに基づいて、上記対応関係情報をもとに上記所定のインスタンスと対応付けられている所定のソースコードを上記第１の管理部から取得して出力するパッケージ化部と、を備える。

上記構成では、利用者は、パッケージ化を所望するインスタンスを指定することで、インスタンスと対応付けられているソースコードが出力される。よって、ユーザは、例えば、出力されたソースコードを用いることができ、つまり利用者自身でソースコードを特定して取得する必要がなくなるので、インスタンスのパッケージ化を容易に行うことができるようになる。

上記パッケージ化部は、上記所定のソースコードから生成されるインスタンスの動作を規定した第１の設定ファイル（例えば、デフォルトＣｏｎｆｉｇ）と、上記所定のインスタンスの動作を規定した第２の設定ファイル（例えば、パッケージ化時点のＣｏｎｆｉｇ１４２）と、を比較し、上記第１の設定ファイルから変更された値を抽出し、抽出した値を上記所定のソースコードに反映して出力する。

上記構成によれば、インスタンスに対する変更が反映されたソースコードが出力されるので、例えば、利用者は、変更した内容を自身でソースコードに反映する手間を省くことができ、インスタンスのパッケージ化をより容易にかつ適切に行うことができるようになる。

上記第１の管理部により管理されているソースコードは、上記ソースコードから生成されるインスタンスの動作を規定した設定ファイルのひな型であり、予め定められた値である固定値と値を代入するための変数とを含むひな型情報（例えば、テンプレートファイル、ｄｅｐｌｏｙ．ｙａｍｌ２０７）と、上記変数に代入する値を含む変数情報（例えば、変数ファイル、ｖａｌｕｅｓ．ｙａｍｌ２０８）とを含んで構成され、上記パッケージ化部は、抽出した値が変数に代入される値であるか否かを判定し、抽出した値が変数に代入される値でないと判定した場合、抽出した値を代入するための変数を上記所定のソースコードのひな型情報に追加する。

上記構成によれば、変更された値については変数化することで、例えば、変更される可能性が高いものを変数として次の利用者に提案することができるようになる。

上記パッケージ化部は、上記第１の管理部により管理されているソースコードから、上記変数を識別するためのターゲットキーパスにおいて用いられている変数識別子の出現頻度を算出する。

上記構成では、例えば、出現頻度および変数識別子を利用者が見比べて変数識別子を決定したり、出現頻度が最も高い変数識別子をパッケージ化部が設定したりすることができるので、インスタンスのパッケージ化をより容易にかつ適切に行うことができるようになる。

上記第２の設定ファイルには、上記所定のインスタンスとして実行される１以上のアプリインスタンスのイメージ（例えば、アプリイメージ１３２）のイメージ識別子（例えば、「ＮｏｄｅＲＥＤ：１」、アプリイメージＩＤ６０４）が含まれ、上記パッケージ化部は、上記イメージに変更があったか否かを判定し、上記イメージに変更があったと判定した場合、上記イメージを管理する第２の管理部（例えば、レジストリ１３４）において変更後のイメージを一意に識別可能なイメージ識別子を決定し、決定したイメージ識別子を上記所定のソースコードに反映して出力する。

上記構成では、変更後のイメージのイメージ識別子がソースコードに反映されるので、例えば、利用者が、ソースコードのどこを変更すればよいのか、イメージ識別子として何を用いてよいかわからない事態を回避することができる。

上記パッケージ化部は、上記所定の実行環境から上記変更後のイメージを取得する。

上記構成によれば、例えば、変更後のイメージを作成する利用者の手間を省くことができる。

上記パッケージ化部は、上記所定の実行環境が上記変更後のイメージを取得するためのインターフェース（例えば、イメージを取得するためのＡＰＩ、ＳＳＨ、エージェント等）を備えるか否かを判定し、上記インターフェースを備えないと判定した場合、上記変更後のイメージの実行状態であるアプリインスタンス（例えば、アプリインスタンス１４１）に含まれるデータをコピーして上記変更後のイメージを作成する。

上記構成によれば、例えば、変更後のイメージを作成する利用者の手間を省くことができる。

上記所定のインスタンスとして実行されるアプリインスタンスのイメージを変更するためのソースコード（例えば、ソースコード１８１１）を管理する第３の管理部（例えば、利用者用リポジトリ１８１０）と通信可能であり、上記パッケージ化部は、上記所定の実行環境が上記変更後のイメージを取得するためのインターフェースを備えるか否かを判定し、上記インターフェースを備えないと判定した場合、上記第３の管理部が管理するソースコードをもとに上記変更後のイメージを作成する。

上記構成によれば、例えば、変更後のイメージを作成する利用者の手間を省くことができる。

ひな型情報の値を変数とするか否かが規定された変換ルール情報（例えば、変換ルール情報５４２）を記憶する記憶装置を備え、上記パッケージ化部は、抽出した値が変数に代入される値でないと判定し、かつ、上記変換ルール情報をもとに、抽出した値を変数とすると判定した場合、抽出した値を代入するための変数を上記所定のソースコードのひな型情報に追加する。

上記構成では、意味があるものを変数にすることができるので、例えば、パスワード等、変数とする必要がないものを変数としてしまう事態を回避することができる。

インスタンスの動作を規定した設定ファイルの値を用いるか、上記インスタンスのもとになったソースコードの値を用いるかが規定された変換ルール情報を記憶する記憶装置を備え、上記パッケージ化部は、上記変換ルール情報をもとに、抽出した値について上記第２の設定ファイルの値を用いると判定した場合、抽出した値を上記所定のソースコードに反映して出力する。

上記構成によれば、例えば、ＩＰアドレス等、システムに固有な値を設定するような値を設定してしまう事態、パスワード等、利用者に固有な値を設定してしまう事態を回避することができる。

上記パッケージ化部は、抽出した値を上記所定のソースコードに反映した結果を表示装置に表示する。

上記構成では、生成されたソースコードが表示されるので、例えば、利用者は、ソースコードを容易に確認することができる。

また上述した構成については、本発明の要旨を超えない範囲において、適宜に、変更したり、組み替えたり、組み合わせたり、省略したりしてもよい。

１００……パッケージシステム、１１０……リポジトリ、１２０……ＣＩシステム、１３０……マーケットプレイスシステム、１４０……実行環境、１５０……パッケージ化支援システム。

Claims (12)

1. ソースコードを管理する第１の管理部と、ソースコードもとに作成されるパッケージを管理し、利用者が操作する端末から指示されたパッケージをインスタンスとして所定の実行環境において利用可能にするマーケットプレイスシステムと通信可能なパッケージ化支援システムであって、
   パッケージを識別可能な識別情報と、前記パッケージのもとになるソースコードを識別可能な識別情報と、前記パッケージのインスタンスを識別可能な識別情報とが対応付けられた対応関係情報を記憶する記憶装置と、
   利用者が操作する端末から所定のインスタンスのパッケージ化の指示を受信したことに基づいて、前記対応関係情報をもとに前記所定のインスタンスと対応付けられている所定のソースコードを前記第１の管理部から取得して出力するパッケージ化部と、
   を備えるパッケージ化支援システム。
2. 前記パッケージ化部は、前記所定のソースコードから生成されるインスタンスの動作を規定した第１の設定ファイルと、前記所定のインスタンスの動作を規定した第２の設定ファイルと、を比較し、前記第１の設定ファイルから変更された値を抽出し、抽出した値を前記所定のソースコードに反映して出力する、
   請求項１に記載のパッケージ化支援システム。
3. 前記第１の管理部により管理されているソースコードは、前記ソースコードから生成されるインスタンスの動作を規定した設定ファイルのひな型であり、予め定められた値である固定値と値を代入するための変数とを含むひな型情報と、前記変数に代入する値を含む変数情報とを含んで構成され、
   前記パッケージ化部は、抽出した値が変数に代入される値であるか否かを判定し、抽出した値が変数に代入される値でないと判定した場合、抽出した値を代入するための変数を前記所定のソースコードのひな型情報に追加する、
   請求項２に記載のパッケージ化支援システム。
4. 前記パッケージ化部は、前記第１の管理部により管理されているソースコードから、前記変数を識別するためのターゲットキーパスにおいて用いられている変数識別子の出現頻度を算出する、
   請求項３に記載のパッケージ化支援システム。
5. 前記第２の設定ファイルには、前記所定のインスタンスとして実行される１以上のアプリインスタンスのイメージのイメージ識別子が含まれ、
   前記パッケージ化部は、前記イメージに変更があったか否かを判定し、前記イメージに変更があったと判定した場合、前記イメージを管理する第２の管理部において変更後のイメージを一意に識別可能なイメージ識別子を決定し、決定したイメージ識別子を前記所定のソースコードに反映して出力する、
   請求項２に記載のパッケージ化支援システム。
6. 前記パッケージ化部は、前記所定の実行環境から前記変更後のイメージを取得する、
   請求項５に記載のパッケージ化支援システム。
7. 前記パッケージ化部は、前記所定の実行環境が前記変更後のイメージを取得するためのインターフェースを備えるか否かを判定し、前記インターフェースを備えないと判定した場合、前記変更後のイメージの実行状態であるアプリインスタンスに含まれるデータをコピーして前記変更後のイメージを作成する、
   請求項６に記載のパッケージ化支援システム。
8. 前記所定のインスタンスとして実行されるアプリインスタンスのイメージを変更するためのソースコードを管理する第３の管理部と通信可能であり、
   前記パッケージ化部は、前記所定の実行環境が前記変更後のイメージを取得するためのインターフェースを備えるか否かを判定し、前記インターフェースを備えないと判定した場合、前記第３の管理部が管理するソースコードをもとに前記変更後のイメージを作成する、
   請求項６に記載のパッケージ化支援システム。
9. ひな型情報の値を変数とするか否かが規定された変換ルール情報を記憶する記憶装置を備え、
   前記パッケージ化部は、抽出した値が変数に代入される値でないと判定し、かつ、前記変換ルール情報をもとに、抽出した値を変数とすると判定した場合、抽出した値を代入するための変数を前記所定のソースコードのひな型情報に追加する、
   請求項３に記載のパッケージ化支援システム。
10. インスタンスの動作を規定した設定ファイルの値を用いるか、前記インスタンスのもとになったソースコードの値を用いるかが規定された変換ルール情報を記憶する記憶装置を備え、
    前記パッケージ化部は、前記変換ルール情報をもとに、抽出した値について前記第２の設定ファイルの値を用いると判定した場合、抽出した値を前記所定のソースコードに反映して出力する、
    請求項２に記載のパッケージ化支援システム。
11. 前記パッケージ化部は、抽出した値を前記所定のソースコードに反映した結果を表示装置に表示する、
    請求項２に記載のパッケージ化支援システム。
12. ソースコードを管理する第１の管理部と、ソースコードもとに作成されるパッケージを管理し、利用者が操作する端末から指示されたパッケージをインスタンスとして所定の実行環境において利用可能にするマーケットプレイスシステムと通信可能なパッケージ化支援システムに係るパッケージ化支援方法であって、
    前記パッケージ化支援システムは、パッケージを識別可能な識別情報と、前記パッケージのもとになるソースコードを識別可能な識別情報と、前記パッケージのインスタンスを識別可能な識別情報とが対応付けられた対応関係情報を記憶する記憶装置と、計算機とを備え、
    前記計算機は、
    利用者が操作する端末から所定のインスタンスのパッケージ化の指示を受信し、
    前記対応関係情報をもとに前記所定のインスタンスと対応付けられている所定のソースコードを前記第１の管理部から取得して出力する、
    パッケージ化支援方法。

Images