JP7328922B2 - 設定装置、設定方法、及びプログラム - Google Patents

Description

本発明は、開発されたアプリケーションをアプリケーション実行装置において適切に動作させるための技術に関連するものである。

アプリケーションの導入においては、一般に、開発環境でソフトウェア（コード）を作成し、テスト環境でテストを行って、本番環境（商用環境と称してもよい）でソフトウェアのインストールや設定を行うことで、ユーザに対してサービスを提供するアプリケーションが実現される。

特開２０１８－１３３０４４号公報

近年、様々なクラウドサービスを利用して開発・構築されたアプリケーションであるクラウドネイティブのアプリケーションが普及してきている。

このようなクラウドネイティブのアプリケーションでは、開発されたアプリケーションを本番環境で適切に動作させるために、ソフトウェアのインストール等の他、クラウドやコンテナの設定等が必要となる。そのため、開発されたアプリケーションを本番環境で適切に動作させるために作成するワークフロー定義情報（作業手順）及び構成設定情報が複雑になり、その作成に大きな手間がかかるとともに、その管理も煩雑になる。なお、このような課題は、クラウドネイティブのアプリケーションに限らずに発生し得る課題である。

本発明は上記の点に鑑みてなされたものであり、アプリケーションをアプリケーション実行装置において動作させるために使用するワークフロー定義情報及び構成設定情報を効率的に作成することを可能とする技術を提供することを目的とする。

開示の技術によれば、対象アプリケーションの構成要素に基づいて作成された１以上の単位情報を用いて、前記対象アプリケーションをアプリケーション実行装置において動作させるために実行が必要な１以上のタスクの実行手順を記述したタスク実行手順情報と、前記対象アプリケーションの構成設定情報を生成する変換部と、
前記タスク実行手順情報に基づいて、前記１以上のタスクを実行する実行部と
を備える設定装置が提供される。

開示の技術によれば、アプリケーションをアプリケーション実行装置において動作させるために使用するワークフロー定義情報及び構成設定情報を効率的に作成することを可能とする技術が提供される。

本発明の実施の形態におけるシステムの全体構成図である。 設定装置の機能構成図である。 装置のハードウェア構成例を示す図である。 設定装置の動作を説明するためのフローチャートである。 デザインパターンの例を示す図である。 ワークフロー定義情報の例を示す図である。 設定装置の動作を説明するためのフローチャートである。 構成設定情報の例を示す図である。 デザインパターンの例を示す図である。 ワークフロー定義情報の生成例を説明するための図である。 ワークフロー定義情報の生成例を説明するための図である。 構成設定情報の生成例を示す図である。 構成設定情報の生成例を示す図である。

以下、図面を参照して本発明の実施の形態（本実施の形態）を説明する。以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。

以下の説明において、アプリケーションとは、あるサービスを提供するためのソフトウェアの集合であるものとする。ソフトウェアは「プログラム」あるいは「コード」と称してもよい。また、「パラメータ」はパラメータの名前を意味し、その値は「パラメータの値」と記述する。また、「ワークフロー」を「パイプライン」と呼んでもよい。

（システム構成）
図１に、本発明の実施の形態におけるシステムの構成例を示す。図１に示すように、本実施の形態のシステムは、設定装置１００とアプリケーション実行装置２００がネットワークで接続された構成を有する。

アプリケーション実行装置２００は、例えば、アプリケーションを動作させるクラウドあるいはコンテナ上の本番環境（商用環境と称してもよい）に相当する。ただし、これは例であり、アプリケーション実行装置２００は、物理的なＰＣやサーバであってもよいし、開発環境やテスト環境であってもよい。

設定装置１００は、物理的なＰＣやサーバであってもよいし、クラウド上の仮想マシン等で実現される機能であってもよい。設定装置１００の機能がアプリケーション実行装置２００に含まれていてもよい。

本実施の形態では、アプリケーションを構成する各ソフトウェアは既にできており、各アプリケーションをアプリケーション実行装置２００にインストールして、必要な設定を行うことで、アプリケーションが適切に動作する状態にすることを目的としている。

本実施の形態では、設定装置１００が、予め作成しておいた複数のデザインパターン（１つのデザインパターンでもよい）から、ワークフロー定義情報（パイプライン情報、タスク実行手順情報、作業手順、ワークフロー定義、ワークフロー定義ファイル等と称してもよい）と構成設定情報（構成設定ファイル、構成情報、構成ファイル等と称してもよい）とを自動的に生成する。

ワークフロー定義情報は、アプリケーションをアプリケーション実行装置２００上で適切に動作させるために実行する１以上のタスクの情報からなる。

構成設定情報は、アプリケーションの構成及び設定を示しており、アプリケーション実行装置２００において、どのソフトウェアをどのような設定で動作させるか等を示す情報からなる。

また、本実施の形態では、設定装置１００がワークフロー定義情報を実行する中で、自動的に構成設定情報を生成し、ワークフロー定義情報におけるデプロイのタスクでその構成設定情報を利用して、必要なソフトウェアのインストールや設定を行っている。

（デザインパターンの概要）
上記複数のデザインパターンにおける各デザインパターンは、ワークフロー定義情報の一部と構成設定情報の一部とを有する情報である。なお、デザインパターンを「単位情報」と称してもよい。

１つのアプリケーションは、複数の構成要素からなる。一例として、データベースにアクセスして、ＡＰＩでユーザに対して所定機能を提供するアプリケーションを考えると、当該アプリケーションは、例えば、データベースソフトウェアとその設定、所定機能を提供するソフトウェアとその設定、ＡＰＩを実現するためのソフトウェアとその設定の３つの構成要素に分けることができる。

本実施の形態において、上記のように分割してできた構成要素のそれぞれが、１つのデザインパターンに対応するが、これは例であり、アプリケーションをどのように分割して、どのような単位でデザインパターンを構成するかは任意である。

ただし、本実施の形態では、デザインパターンを、再利用可能なように作成することとしている。また、１つ１つのデザインパターンは、容易に管理できるようにできるだけ小さなサイズになるようにしている。つまり、アプリケーションに含まれる様々な要素を再利用可能な最小の単位でグルーピングすることでデザインパターンを構成している。デザインパターンを再利用可能にすることで、迅速かつ効率的にワークフロー定義情報と構成設定情報を生成することができる。

各デザインパターンは、それに対応するアプリケーションの構成要素についての、パラメータ、構成設定情報（必要なソフトウェア、設定内容等であり）、タスク群（当該構成要素を動作させるための手順等）を有する。なお、タスク群をパイプラインあるいはワークフローと呼んでもよい。「タスク群」は１つのタスクであってもよい。

（装置構成）
図２に、設定装置１００の機能構成例を示す。図２に示すように、設定装置１００は、入力部１１０、変換部１２０、ワークフロー実行部１３０、データ格納部１４０を備える。なお、設定装置１００は、物理的に（あるいは仮想的に）、１つの装置（サーバ等）からなるものであってもよいし、複数の装置からなるものであってもよい。例えば、変換部１２０がある装置で実現され、ワークフロー実行部１３０が別の装置で実現されてもよい。このように装置が分かれている場合、例えば、変換部１２０となる装置の記憶手段（メモリ等）とワークフロー実行部１３０となる装置の記憶手段（メモリ等）とでデータ格納部１４０が構成される。

入力部１１０は、デザインパターン、パラメータの値等を外部から入力し、これらをデータ格納部１４０に格納する。

変換部１２０は、複数のデザインパターンをデータ格納部１４０から読み出して、当該複数のデザインパターンからワークフロー定義情報を生成する。また、変換部１２０は、ワークフロー定義情報の実行時に、複数のデザインパターンとパラメータの値に基づいて、構成設定情報を生成する。なお、変換部１２０をコンパイラと呼んでもよい。

データ格納部１４０には、外部からの入力情報、変換部１２０により生成された情報等が格納されている。変換部１２０、ワークフロー実行部１３０の動作の詳細については後述する。

（ハードウェア構成例）
本実施の形態における設定装置１００は、例えば、コンピュータに、本実施の形態で説明する処理内容を記述したプログラムを実行させることにより実現可能である。この「コンピュータ」は、物理マシンであってもよいし、クラウド上の仮想マシンであってもよい。仮想マシンを使用する場合、ここで説明する「ハードウェア」は仮想的なハードウェアである。

また、変換部１２０の処理を実現するプログラムと、ワークフロー実行部１３０の処理を実現するプログラムが別々に提供されてもよい。この場合、変換部１２０は、コンピュータに、本実施の形態で説明する変換部１２０の処理内容を記述したプログラムを実行させることにより単独装置として実現することも可能である。また、ワークフロー実行部１３０は、コンピュータに、本実施の形態で説明するワークフロー実行部１３０の処理内容を記述したプログラムを実行させることにより単独装置として実現することも可能である。

設定装置１００のプログラム、変換部１２０のプログラム、ワークフロー実行部１３０のプログラムはいずれも、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メール等、ネットワークを通して提供することも可能である。

図３は、上記コンピュータのハードウェア構成例を示す図である。図３のコンピュータは、それぞれバスＢＳで相互に接続されているドライブ装置１０００、補助記憶装置１００２、メモリ装置１００３、ＣＰＵ１００４、インタフェース装置１００５、表示装置１００６、及び入力装置１００７等を有する。

当該コンピュータでの処理を実現するプログラムは、例えば、ＣＤ－ＲＯＭ又はメモリカード等の記録媒体１００１によって提供される。プログラムを記憶した記録媒体１００１がドライブ装置１０００にセットされると、プログラムが記録媒体１００１からドライブ装置１０００を介して補助記憶装置１００２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１００１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１００２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１００３は、プログラムの起動指示があった場合に、補助記憶装置１００２からプログラムを読み出して格納する。ＣＰＵ１００４は、メモリ装置１００３に格納されたプログラムに従って、当該設定装置１００（あるいは、変換部１２０、ワークフロー実行部１３０）に係る機能を実現する。インタフェース装置１００５は、ネットワークに接続するためのインタフェースとして用いられる。表示装置１００６はプログラムによるＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）等を表示する。入力装置１００７はキーボード及びマウス、ボタン、又はタッチパネル等で構成され、様々な操作指示を入力させるために用いられる。

（設定装置１００の動作例）
以下、図４、図７のフローチャートの手順に沿って、設定装置１００の動作例を説明する。まず、図４のフローチャートを参照して、ワークフロー定義情報の生成について説明する。

＜Ｓ１０１＞
Ｓ１０１において、複数のデザインパターンが入力部１１０から入力される。

この動作の前提として、アプリケーション実行装置２００で動作させようとするアプリケーション（対象アプリケーションと呼ぶ）に対応する複数のデザインパターンを作成しておく。デザインパターンは、過去に作成したもので、当該対象アプリケーションに利用できるものであれば、それを再利用してもよい。

図５に、複数のデザインパターンの例としてデザインパターン１、デザインパターン２、デザインパターン３を示す。ここでは、対象アプリケーションが構成要素１～３を有し、デザインパターン１が構成要素１に対応し、デザインパターン２が構成要素２に対応し、デザインパターン３が構成要素３に対応しているとする。

各デザインパターンは、図５に示すようなデータフォーマットを有する。すなわち、デザインパターンは、該当構成要素において必要とするパラメータを記述するブロック、該当構成要素において必要とする構成情報を記述するブロック、及び、該当構成要素において必要とするワークフロー（タスク群）を記述するブロックを有する。

例えば、デザインパターン１は、構成要素１に対して、パラメータ１、パラメータ２が必要であり、構成要素１の構成として、パラメータ１を設定したソフトウェアＡが必要であり、構成要素１を動作させるためにタスク１とタスク２（パラメータ２を使用）を実行することが必要であることを示している。デザインパターン２、３についても同様である。

なお、構成要素１を動作させるためのタスクとは、デプロイであってもよいし、デプロイの前準備の処理であってもよいし、インストールあるいは起動したソフトウェアに対する処理であってもよいし、その他の処理であってもよい。

なお、デプロイについては、本実施の形態では必ず実行するタスクであるため、デザインパターンに含めずに、変換部１２０が自動生成して、ワークフロー定義情報に含めてもよい。

図５に示すように、構成情報には、所定の単位で識別情報（名前又はＩＤ）が付与される。図５の例では、デザインパターン１及びデザインパターン２の構成情報において「構成ＡＢＣ」という名前が付けられ、デザインパターン３の構成情報において「構成ＤＥＦ」という名前が付けられている。

識別情報を付ける単位は、任意であるが、例えば、アプリケーションを構成する主要なソフトウェアの単位で名前が付けられてもよい。また、異なるデザインパターンにおいて、同じ対象に対応する構成情報には、同じ識別情報が付与される。例えば、図５のデザインパターン２のデータべースは、デザインパターン１のソフトＡにより使用されるデータベースであり、対象はソフトＡであるため、いずれも「構成ＡＢＣ」が付与されている。

図５の例では、各デザインパターンの構成情報のブロックにおいて、識別情報は１つであるが、これは例であり、構成情報に含まれる内容に応じて、複数の識別情報が付される場合もある。

後述するように、変換部１２０は、この識別情報をキーとして使用することで、複数デザインパターンにおける構成情報を合成する処理を行う。

また、図５に示すように、ワークフローにも、所定の単位で識別情報（名前又はＩＤ）が付与される。図５の例では、デザインパターン１及びデザインパターン２のワークフローにおいて「タスクＧＨＩ」という名前が付けられ、デザインパターン３のワークフローにおいて「タスクＪＫＬ」という名前が付けられている。

識別情報を付ける単位は、任意であるが、例えば、アプリケーションを構成する主要なソフトウェアの単位で名前が付けられてもよい。また、異なるデザインパターンにおいて、同じ対象に対応するワークフローには、同じ識別情報が付与される。例えば、図５のデザインパターン２のタスク１は、デザインパターン１のソフトＡに関連するタスクであり、対象はソフトＡであるため、「タスクＧＨＩ」が付与されている。

後述するように、変換部１２０は、この識別情報をキーとして使用することで、複数デザインパターンにおけるワークフローを合成する処理を行う。

また、デザインパターンにおいて、ワークフローのブロックにタスク間の依存関係が記述されてもよい。例えば、図５の例で、タスク１はタスク３の後に行わなければならない場合、「タスク１はタスク３の後に行う」旨が、各デザインパターンに記述されてもよい。

図５の例では、各デザインパターンのワークフローのブロックにおいて、識別情報は１つであるが、これは例であり、ワークフローに含まれるワークフローの内容に応じて、複数の識別情報が付される場合もある。

図９に、より具体的なデザインパターンの例を示す。なお、なお、図９～図１３では、情報をキーとバリューの形で階層的に表現するｙａｍｌと同様の形式が用いられているが、これは一例に過ぎない。デザインパターンはどのような形式で記述してもよい。また、図９～図１３は、実際に使用されるデザインパターン等のそのものを示しているわけではなく、実際に使用されるものを抽象化している。

図９の例においても、上述したとおり、デザインパターンは、パラメータのブロック、構成情報のブロック、ワークフロー（パイプライン）のブロックを有するとともに、構成情報、ワークフローにおいて、識別情報（ＩＤ、名前等）が付与されている。

＜Ｓ１０２、Ｓ１０３＞
図４のＳ１０２において、変換部１２０は、データ格納部１４０から、Ｓ１０１で入力された複数のデザインパターンを読み出し、当該複数のデザインパターンから、対象アプリケーションをアプリケーション実行装置２００で動作させるために実行が必要なタスクとその実行順序を示すワークフロー定義情報を生成する。Ｓ１０３において、変換部１２０は、ワークフロー定義情報を出力する。具体的には、下記の（１）～（４）の処理を行う。

（１）変換部１２０は、複数のデザインパターンの「ワークフロー」のブロックにおける識別情報とその内容を全て走査し、複数デザインパターン間で同じ識別情報のタスク（タスク群）を合成する。異なる識別情報であれば、タスク間の依存関係に応じた実行順序で各識別情報のタスク群を並べる。

合成するとは、複数デザインパターン間で同一のタスクがあれば、１つのタスクとし、異なるタスクであれば、タスク間の依存関係に応じた実行順序でタスクを並べることである。

また、変換部１２０は、合成において、処理内容に矛盾が生じていることを検知した場合に、競合エラーを出力して、処理を終了する。

例えば、仮に、デザインパターンＸにおける「タスクＸＹＺ」で識別されるタスク群におけるタスク１がタスク２の前に実行することとされていて、デザインパターンＹにおける「タスクＸＹＺ」で識別されるタスク群におけるタスク１がタスク２の後に実行することとされている場合、矛盾するので、競合エラーとなる。

（２）変換部１２０は、タスクの実行順序を、デザインパターンに記述された依存関係の情報（宣言）に従って決定してもよいし、データ格納部１４０に依存関係に関する情報（ソフトＡの起動はソフトＢのインストールの前に行う等）を予め格納しておいて、その情報を参照することにより決定してもよい。

（３）変換部１２０は、複数のデザインパターンにおいて要求されているパラメータを全て取得して、ワークフロー定義情報に記述する。

（４）変換部１２０は、「構成設定情報を生成するタスク」を生成し、当該タスクと上記の処理により得られるタスクの一覧、及び、パラメータの一覧を記述したワークフロー定義情報を出力する。出力したワークフロー定義情報はデータ格納部１４０に格納される。

図５のデザインパターン１～３から生成されたワークフロー定義情報の例を図６に示す。図６に示すように、当該ワークフロー定義情報において、デザインパターン１～３から取得されたパラメータ１～４が記述され、各タスクが実行順序に従った順序で記述されている。なお、図６の例における「デプロイ」は、構成設定情報に従ってソフトウェアのインストールと設定を行うタスクであり、本実施の形態では、変換部１２０が生成するタスクである。

図１０に、より具体的な３つのデザインパターンの例を示す。この３つのデザインパターンは、データベースにアクセスして、ＡＰＩでユーザに対して所定機能を提供するようなアプリケーションに対応する。具体的には、ＤＢ ｐａｔｔｅｒｎがデータベースソフトウェアとそれに関する設定についてのデザインパターンであり、Ｂａｓｅ ｐａｔｔｅｒｎが所定機能を提供するソフトウェアとその設定についてのデザインパターンであり、ＡＰＩ ｐａｔｔｅｒｎがＡＰＩを実現するためのソフトウェアとその設定についてのデザインパターンである。

Ｂａｓｅ ｐａｔｔｅｒｎにおける「ｍｙａｐｐ」は、所定機能を提供するソフトウェアである。ＤＢ ｐａｔｔｅｒｎにおいて、Ｂａｓｅ ｐａｔｔｅｒｎにおける名前「ａｐｐＤｅｐｌｏｙｍｅｎｔ」と同じ名前「ａｐｐＤｅｐｌｏｙｍｅｎｔ」の構成情報として、ｍｙａｐｐがデータベースに接続するための構成情報（接続先アドレス、ＩＤ等）が記述される。

ＡＰＩ ｐａｔｔｅｒｎには、Ｂａｓｅ ｐａｔｔｅｒｎに記述されているベースとなるソフトウェアを公開するためのポートの情報、そのポートが機能しているかどうかの死活監視を行うｐｒｏｂｅの情報等が記述される。

構成設定情報の生成において、変換部１２０により、図９の枠の部分が走査され、前述した手順により、図１１に示すような構成設定情報が生成される。図１１において、「ｃｏｍｐｉｌｅＣｏｎｆｉｇ」が、図６における「構成設定情報の生成タスク」に相当する。また、図１１において、枠で囲んだ部分が、３つのデザインパターンから取得された情報であることを示す。

次に、図７のフローチャートを参照して、構成設定情報の生成に関わる処理について説明する。ユーザからの入力等により、データ格納部１４０には、ワークフロー定義情報に記述されている各パラメータの値が格納されているとする。

＜Ｓ２０１＞
ワークフロー実行部１３０は、データ格納部１４０からワークフロー定義情報とパラメータの値を読み出し、ワークフロー定義情報の実行を開始する。ワークフロー定義情報を実行するとは、ワークフロー定義情報に記述された各タスクを、記述された順番（図６の例では上から）で実行することである。

ワークフロー実行部１３０は、ワークフロー定義情報における「構成設定情報の生成タスク」を実行すると、構成設定情報を生成するよう変換部１２０（コンパイラ）に指示する。

＜Ｓ２０２＞
Ｓ２０２において、構成設定情報の生成指示を受けた変換部１２０は、データ格納部１４０から、対象アプリケーションに対応する複数のデザインパターン、及びパラメータの値を取得する。

＜Ｓ２０３、Ｓ２０４＞
Ｓ２０３において、変換部１２０は、複数のデザインパターン、及びパラメータの値から、対象アプリケーションをアプリケーション実行装置２００で動作させるための構成設定情報を生成する。Ｓ２０４において、変換部１２０は、構成設定情報を出力する。具体的には、下記の（１）～（２）のとおりである。

（１）変換部１２０は、複数のデザインパターンの「構成情報」のブロックにおける識別情報とその内容を全て走査し、複数デザインパターン間で同じ識別情報の構成情報を合成する。異なる識別情報であれば、各識別情報の構成情報を並べる。

合成するとは、複数デザインパターン間で同一の構成情報があれば、１つの構成情報とし、異なる構成情報であれば、それらを並べることである。

また、合成において、構成情報の内容に矛盾が生じていることを検知した場合に、競合エラーとして処理を終了する。

例えば、仮に、デザインパターンＸにおける「構成ＸＹＺ」で識別される構成情報におけるソフト１がパラメータ１を必要とし、デザインパターンＹにおける「構成ＸＹＺ」で識別される構成情報におけるソフト１がパラメータ２を必要とする場合、矛盾するので、競合エラーとなる。

（２）変換部１２０は、構成情報の一覧を有する構成設定情報を出力する。出力された構成設定情報はデータ格納部１４０に格納される。

図５のデザインパターン１～３から生成された構成設定情報の例を図８に示す。図８に示すように、各デザインパターンから取得された構成情報が、パラメータの値が埋められた形で記述されている。

より具体的な例として、図１０に示した３つのデザインパターンと同じものを図１２に示す。図１２には、構成設定情報の生成において、変換部１２０が走査する部分（構成情報の部分）を枠で囲んでいる。これらの構成情報から、図１３に示す構成設定情報が生成される。図１３には、パラメータの値も示されている。図１３において、枠で囲んだ部分（本例では全部）が、３つのデザインパターンから取得された情報であることを示す。図１３には、ｍｙａｐｐというソフトウェアをインストールして、ｍｙａｐｐがデータベースへ接続するための設定を行い、ＡＰＩのポート監視のための死活監視の設定を行うこと等が記述されている。

＜Ｓ２０５＞
図７のＳ２０５において、ワークフロー実行部１３０は、変換部１２０により生成された構成設定情報をデータ格納部１４０から読み出し、ワークフロー定義情報におけるタスクの１つであるデプロイを実行する際に、当該構成設定情報に従って、アプリケーション実行装置２００に命令をすることで、ソフトウェアのインストールや設定、起動等を実行する。ワークフロー定義情報の実行が完了すると、対象アプリケーションはアプリケーション実行装置２００において動作している状態となる。

なお、上記の例では、ワークフロー定義情報の実行時に構成設定情報を生成することとしているが、これは一例である。ワークフロー定義情報の実行前に、パラメータの値の入力を受けて、ワークフロー定義情報とともに構成設定情報を生成してもよい。

（実施の形態の効果等）
以上説明したように、本実施の形態に係る技術により、アプリケーションをアプリケーション実行装置において動作させるために使用するワークフロー定義情報及び構成設定情報を効率的に作成することができる。

また、ワークフロー定義情報、構成設定情報を別々に管理するのではなく、ユースケースや運用モデル毎に、単位情報（デザインパターン）を作成・管理することとしたので、一貫した運用モデル／ポリシーのもとで情報を管理することができ、アプリケーションの開発から運用まで効果的なライフサイクル管理が可能となる。

また、再利用可能な最小単位でデザインパターンを構成することで、これまでプロジェクトごとに作成・管理していたワークフロー定義情報及び構成設定情報についての単位情報をプロジェクトをまたいで共有することができ、インフラ設計、テスト、運用モデルを共通化して、早く安全にシステム開発が可能となる。

複数のデザインパターンを合成してワークフロー定義と構成設定ファイルを自動生成する際、フォーマットにしたがって各デザインパターンの要求条件を検査することで、デザインパターンを安全に拡張することができ、スケーラブルにアプリケーションの運用モデルを管理することが可能となる。

特に、クラウドネイティブのアプリケーションにおいては、機能追加・変更を短いサイクル（アジャイル）で行うが、本実施の形態に係る技術により、機能追加・変更の作業を自動化でき、更に、アプリケーションの機能追加に伴って作業・設定内容を柔軟に変更することが可能になるので、短いサイクルでの機能追加・変更を安全かつスケーラブルに実現することが可能となる。

（実施の形態のまとめ）
本明細書には、少なくとも下記の各項に記載した設定装置、設定方法、及びプログラムが記載されている。
（第１項）
対象アプリケーションの構成要素に基づいて作成された１以上の単位情報を用いて、前記対象アプリケーションをアプリケーション実行装置において動作させるために実行が必要な１以上のタスクの実行手順を記述したタスク実行手順情報と、前記対象アプリケーションの構成設定情報を生成する変換部と、
前記タスク実行手順情報に基づいて、前記１以上のタスクを実行する実行部と
を備える設定装置。
（第２項）
前記１以上の単位情報における各単位情報は、パラメータのブロックと、構成情報のブロックと、１以上のタスクを示すブロックと、を有する
第１項に記載の設定装置。
（第３項）
前記構成情報のブロックは、１以上の構成情報を識別するための識別情報を含み、
前記変換部は、前記構成設定情報の生成において、複数の単位情報間で識別情報が同じ構成情報を合成する
第２項に記載の設定装置。
（第４項）
前記１以上のタスクを示すブロックは、１以上のタスクを識別するための識別情報を含み、
前記変換部は、前記タスク実行手順情報の生成において、複数の単位情報間で識別情報が同じ１以上のタスクを合成する
第２項又は第３項に記載の設定装置。
（第５項）
前記変換部は、複数の単位情報間で競合が発生した場合に、エラーを出力する
第１項ないし第４項のうちいずれか１項に記載の設定装置。
（第６項）
前記変換部は、前記タスク実行手順情報の中の１つのタスクとして、前記構成設定情報を生成するためのタスクを生成し、前記実行部が当該タスクを実行することにより、前記変換部は、前記構成設定情報を生成する
第１項ないし第５項のうちいずれか１項に記載の設定装置。
（第７項）
設定装置が実行する設定方法であって、
対象アプリケーションの構成要素に基づいて作成された１以上の単位情報を用いて、前記対象アプリケーションをアプリケーション実行装置において動作させるために実行が必要な１以上のタスクの実行手順を記述したタスク実行手順情報と、前記対象アプリケーションの構成設定情報を生成する変換ステップと、
前記タスク実行手順情報に基づいて、前記１以上のタスクを実行する実行ステップと
を備える設定方法。
（第８項）
コンピュータを、第１項ないし第６項のうちいずれか１項に記載の設定装置における各部として機能させるためのプログラム。

以上、本実施の形態について説明したが、本発明はかかる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１００ 設定情報
１１０ 入力部
１２０ 変換部
１３０ ワークフロー実行部
１４０ データ格納部
２００ アプリケーション実行環境
１０００ ドライブ装置
１００１ 記録媒体
１００２ 補助記憶装置
１００３ メモリ装置
１００４ ＣＰＵ
１００５ インタフェース装置
１００６ 表示装置
１００７ 入力装置

Claims (8)

1. 対象アプリケーションの構成要素に基づいて作成された１以上の単位情報を用いて、前記対象アプリケーションをアプリケーション実行装置において動作させるために実行が必要な１以上のタスクの実行手順を記述したタスク実行手順情報と、前記対象アプリケーションの構成設定情報を生成する変換部と、
   前記タスク実行手順情報に基づいて、前記１以上のタスクを実行する実行部と
   を備える設定装置。
2. 前記１以上の単位情報における各単位情報は、パラメータのブロックと、構成情報のブロックと、１以上のタスクを示すブロックと、を有する
   請求項１に記載の設定装置。
3. 前記構成情報のブロックは、１以上の構成情報を識別するための識別情報を含み、
   前記変換部は、前記構成設定情報の生成において、複数の単位情報間で識別情報が同じ構成情報を合成する
   請求項２に記載の設定装置。
4. 前記１以上のタスクを示すブロックは、１以上のタスクを識別するための識別情報を含み、
   前記変換部は、前記タスク実行手順情報の生成において、複数の単位情報間で識別情報が同じ１以上のタスクを合成する
   請求項２又は３に記載の設定装置。
5. 前記変換部は、複数の単位情報間で競合が発生した場合に、エラーを出力する
   請求項１ないし４のうちいずれか１項に記載の設定装置。
6. 前記変換部は、前記タスク実行手順情報の中の１つのタスクとして、前記構成設定情報を生成するためのタスクを生成し、前記実行部が当該タスクを実行することにより、前記変換部は、前記構成設定情報を生成する
   請求項１ないし５のうちいずれか１項に記載の設定装置。
7. 設定装置が実行する設定方法であって、
   対象アプリケーションの構成要素に基づいて作成された１以上の単位情報を用いて、前記対象アプリケーションをアプリケーション実行装置において動作させるために実行が必要な１以上のタスクの実行手順を記述したタスク実行手順情報と、前記対象アプリケーションの構成設定情報を生成する変換ステップと、
   前記タスク実行手順情報に基づいて、前記１以上のタスクを実行する実行ステップと
   を備える設定方法。
8. コンピュータを、請求項１ないし６のうちいずれか１項に記載の設定装置における各部として機能させるためのプログラム。

Images