JP7047497B2 - 操作制御方法、情報処理装置および操作制御プログラム - Google Patents

Description

本発明は、操作制御方法等に関する。

近年、開発されたアプリケーションを任意の環境で再現するための技術として、ＶＭ（Virtual Machine）仮想化の技術やコンテナ型仮想化の技術が知られている。ＶＭ仮想化は、ホスト上に、ＶＭを起動して、特定の環境を再現する。コンテナ型仮想化は、ホスト上のＯＳ（Operating System）のカーネルの上にコンテナと呼ばれる仮想的なユーザ空間を提供して、特定の環境を再現する。

ＶＭは、ホスト上に別のＯＳを動かすための仮想化ソフトを導入する必要がある。一方、コンテナ型仮想化は、ＶＭと同じく特定の環境を再現する点では同じであるものの、ホスト上のＯＳのカーネルをそのまま使うため、仮想化ソフトを必要とせず、起動が素速く、オーバヘッドも小さい。コンテナ型仮想化のプロジェクトには、例えば、Ｄｏｃｋｅｒ（登録商標）が挙げられる。

ここで、Ｄｏｃｋｅｒの利用例を、図１０を参照して説明する。図１０は、Ｄｏｃｋｅｒの利用例を示す参考図である。図１０に示すように、Ｄｏｃｋｅｒのコンテナとしてアプリケーションを実行可能にするためには、アプリケーションの開発者は、実行環境を定義するＤｏｃｋｅｒｆｉｌｅとアプリケーションのソースコードとを準備する（ａ１，ａ２）。ここでいうＤｏｃｋｅｒｆｉｌｅとは、アプリケーションの実行環境を定義したファイルのことをいう。

アプリケーションの開発者は、Ｄｏｃｋｅｒｆｉｌｅとアプリケーションのソースコードを用いてＤｏｃｋｅｒイメージをビルドする（ａ３）。ここでは、アプリケーションの開発者は、ＯＳがＵｂｕｎｔｕである場合のＤｏｃｋｅｒイメージをビルドする。このアプリケーションを利用するユーザは、実行用のマシンにＯＳがＵｂｕｎｔｕである場合のＤｏｃｋｅｒイメージを取得し、コンテナを起動する。ここでは、アプリケーション開発者である「ｈｏｇｅ」が作成したアプリケーション「ａｐｐ１」のＤｏｃｋｅｒイメージ「ｈｏｇｅ／ａｐｐ１：ｖ１」がビルドされる。なお、ｖ１は、後述するＤｏｃｋｅｒタグである。ｖ１は、例えば、Ｕｂｕｎｔｕであるバージョンであることを示す。

ユーザが、このアプリケーションを利用する場合には、実行用のマシンにＤｏｃｋｅｒイメージを取得（ｐｕｌｌ）し（ａ４）、コンテナを起動する（ａ５）。コンテナは、利用しているライブラリやＯＳを含めてアプリケーションが動作する環境をそのまま再現する。したがって、ユーザは、このコンテナで動くアプリケーションが必要とするＯＳやツールを意識する必要はない。

また、既にＤｏｃｋｅｒイメージ化したアプリケーションの開発が進み、以前より改善されたアプリケーションのイメージが利用される場合や、目的に合わせて異なるイメージが利用される場合がある。かかる場合には、前述のＤｏｃｋｅｒタグと呼ばれるＤｏｃｋｅｒイメージを識別するための名前をつけることができる。例えば、“apache_server”という名前のＤｏｃｋｅｒイメージがあったとする。ＯＳにおいて、ＣｅｎｔＯｓであるバージョンと、Ｕｂｕｎｔｕであるバージョンとが区別される場合には、それぞれ“apache_server:centos”と“apatche_server:ubuntu”とタグが付与されても良い。

特開２０１６－１３０８８７号公報 特表２００７－５３８３１３号公報 特開２０１７－１０７５５５号公報

しかしながら、コンテナ上で大規模なデータを用いるアプリケーションを動かすには、問題がある。

１つ目の問題は、Ｄｏｃｋｅｒイメージに大規模なデータを埋め込むと、このイメージの取得やコンテナの起動に時間がかかり、コンテナの起動が素速いというＤｏｃｋｅｒそのもののメリットが失われるという問題がある。なお、コンテナの中には、１０ＧＢ（ギガバイト）までしかデータを埋め込むことができないという制限があるので、Ｄｏｃｋｅｒイメージに大規模なデータを埋め込むこと自体難しいという問題もある。特に、機械学習の学習用データや学習用モデルは、データが大規模になりがちであるので、このような問題が起こり得る。

かかる問題については、コンテナが外部のストレージをマウントすることで解消することが可能である。例えば、データが学習用データである場合、Ｄｏｃｋｅｒが、コンテナの中に学習用データや学習用モデルを埋め込むのではなく、コンテナを起動する際に外部のストレージに保存されたこれらのデータをマウントすることで解消することが可能である。

ところが、外部のストレージにデータを保存しておく方法では、Ｄｏｃｋｅｒイメージだけでなく、このイメージに付随するデータの管理が必要になる。したがって、ユーザは、コンテナの起動時に、Ｄｏｃｋｅｒイメージとデータとの組み合わせを把握しなければならず、組み合わせの管理が煩雑になるという２つ目の問題がある。特に、データが学習用データである場合、マウントすべきデータは、学習に用いられたデータ、生成された学習用モデル、再学習する際に用いられたデータ、再学習した結果によって生成された学習用モデルなど多岐に渡る。アプリケーションが改善された場合には、バージョンの数だけ、Ｄｏｃｋｅｒイメージとデータとの組み合わせが増える。また、ユーザは、データの保存場所のどのパスに学習用データや学習用モデルが保存されているのか、どのデータをマウントするのかを把握しなければならない。したがって、ユーザは、コンテナの起動時に、Ｄｏｃｋｅｒイメージとデータとの組み合わせを把握しなければならず、組み合わせの管理が煩雑になる。

なお、上記課題は、Ｄｏｃｋｅｒだけではなく、ｒｋｔやＬＸＣ等のコンテナ型仮想化の技術にも同様に生じる課題である。

１つの側面では、ユーザが、利用するデータの保存場所や利用するアプリケーション実行環境イメージの組み合わせを把握しなくても、コンテナ上でアプリケーションを利用することを目的とする。

１つの態様では、コンピュータが、アプリケーションの実行環境が配置される領域を示すコンテナの起動方法を定義する際に、データ操作のインターフェースの定義に従って、前記アプリケーションが用いるデータを保存し、前記アプリケーションの実行環境のイメージを保存し、コンテナ操作のインターフェースの定義に従って、前記アプリケーションの実行環境のイメージの情報に、前記コンテナの中で前記アプリケーションが用いるデータのデータ情報を付加した前記コンテナの起動方法の定義を、定義情報に登録する、処理を実行する。

１つの態様によれば、ユーザが、利用するデータの保存場所や利用するアプリケーション実行環境イメージの組み合わせを把握しなくても、コンテナ上でアプリケーションを利用することが可能となる。

図１は、実施例に係る管理装置を含むシステムの処理の一例を示す図である。 図２は、実施例に係る管理装置の構成を示す機能ブロック図である。 図３は、実施例に係るカタログ情報のフォーマットの一例を示す図である。 図４は、実施例に係るカタログ情報のフォーマットの別の例を示す図である。 図５は、実施例に係るカタログ操作のシーケンスの一例を示す図である。 図６は、実施例に係るサービス起動のシーケンスの一例を示す図である。 図７は、実施例に係るカタログ操作のシーケンスの別の例を示す図である。 図８は、実施例に係る管理装置の用途の一例を示す図である。 図９は、操作制御プログラムを実行するコンピュータの一例を示す図である。 図１０は、Ｄｏｃｋｅｒの利用例を示す参考図である。

以下に、本願の開示する操作制御方法、情報処理装置および操作制御プログラムの実施例を図面に基づいて詳細に説明する。なお、実施例では、コンテナ型仮想化のプロジェクトとしてＤｏｃｋｅｒを適用した場合を説明する。実施例によりこの発明が限定されるものではない。

［管理装置を含むシステムの処理の一例］
図１は、実施例に係る管理装置を含むシステムの処理の一例を示す図である。図１に示すように、管理装置１は、インターフェースとして、カタログ操作、サービス操作およびデータの保存操作を有する。カタログ操作のインターフェースは、コンテナ実行基盤（サービス用サーバ）上で動くことになるコンテナの起動方法の定義を登録するために用いられる。なお、コンテナの起動方法の定義のことを「カタログ」というものとする。また、サービス操作のインターフェースは、コンテナを起動するサービスを行うために用いられる。サービス操作のインターフェースは、ＷｅｂＡＰＩ（Application Programming Interface）の機能を持つサービスであっても良い。また、データの保存操作のインターフェースは、コンテナ実行基盤（サービス用サーバ）が利用するデータを保存するために用いられる。

Ｄｏｃｋｅｒのコンテナとしてアプリケーションを実行可能にするために、アプリケーション開発者は、予め、実行環境を定義するＤｏｃｋｅｒｆｉｌｅとアプリケーションのソースコードとを準備し、これらを用いてＤｏｃｋｅｒイメージをビルドする。そして、アプリケーション開発者は、ビルドされたＤｏｃｋｅｒイメージをレジストリ（Ｄｏｃｋｅｒイメージの置き場）に登録する。なお、Ｄｏｃｋｅｒイメージのビルドおよびレジストリへの登録は、コード管理ツールによってなされても良い。なお、コード管理ツールの説明は、後述する。

このような状況の下、アプリケーション開発者は、アプリケーションにより用いられるデータの保存操作のインターフェースに従って、指定するデータをデータ置き場に保存する（Ｓ１１０）。データ置き場は、コンテナ実行基盤（サービス用サーバ）にあっても良いし、別個の分散ファイルシステムにあっても良い。データは、例えば、機械学習の学習モデルであったり、機械学習の学習データであったりする。そして、データの保存操作のインターフェースは、データ置き場の具体的なデータのパスをデータ情報２１に登録する（Ｓ１２０）。

アプリケーション開発者は、カタログ操作のインターフェースに従って、カタログをカタログ情報２２に登録する（Ｓ１３０）。カタログには、Ｄｏｃｋｅｒイメージの名前、通信で用いられるポート、環境変数、データの種類、データのパスおよびコンテナ内のマウントパスが含まれる。カタログは、カタログ名およびバージョンによって識別される。

ユーザが、あるサービスを利用したいとき、カタログ名およびバージョンを指定して、サービス操作のインターフェースを呼び出す。サービス操作のインターフェースは、カタログ情報２２を参照し、指定されたカタログ名およびバージョンに対するカタログを取得する（Ｓ１４０）。また、サービス操作のインターフェースは、データ情報２１を参照し、カタログに設定されたデータのパスに対するデータ置き場の具体的なデータのパスを取得する（Ｓ１５０）。そして、サービス操作のインターフェースは、コンテナの起動をコンテナ実行基盤（サービス用サーバ）に依頼する（Ｓ１６０）。コンテナの起動依頼には、カタログに含まれるＤｏｃｋｅｒイメージの名前、ポート、環境変数、データのパス、コンテナ内のマウントパスおよびデータ置き場の具体的なデータのパスが含まれる。

すると、コンテナの起動依頼を受け付けたサービス用サーバのＤｏｃｋｅｒが、レジストリから、Ｄｏｃｋｅｒイメージの名前に対応するＤｏｃｋｅｒイメージを取得（ｐｕｌｌ）する（Ｓ１６１）。そして、Ｄｏｃｋｅｒは、取得したＤｏｃｋｅｒイメージを用いてコンテナを起動する（Ｓ１６２）。そして、Ｄｏｃｋｅｒは、データ置き場から、データ置き場の具体的なデータのパスに対応するデータを取得し、取得したデータをコンテナ内のマウントパスにマウントする（Ｓ１６３，Ｓ１６４）。

例えば、ユーザが、カタログ名として「ａｐｐ１」、バージョンとして「ｖ１」を指定した場合、サービス操作のインターフェースは、カタログ情報を参照し、指定されたカタログ名「ａｐｐ１」およびバージョン「ｖ１」に対するカタログを取得する。カタログには、Ｄｏｃｋｅｒイメージの名前として「ｈｏｇｅ／ａｐｐ１：ｖ１」、通信で用いられるポート、環境変数が含まれるとする。加えて、カタログには、データの種類が学習モデルである場合の、データのパスおよびコンテナ内のマウントパスが含まれるとする。加えて、カタログには、データの種類が学習データである場合のデータのパスおよびコンテナ内のマウントパスが含まれるとする。

そして、サービス操作のインターフェースは、データ情報２１を参照し、指定されたカタログ名「ａｐｐ１」およびバージョン「ｖ１」に対するデータ置き場の具体的なデータのパスを取得する。そして、サービス操作のインターフェースは、コンテナの起動をコンテナ実行基盤（サービス用サーバ）に依頼する。コンテナの起動依頼には、カタログに含まれるＤｏｃｋｅｒイメージの名前「ｈｏｇｅ／ａｐｐ１：ｖ１」、ポート、環境変数、データのパス、コンテナ内のマウントパスおよびデータ置き場の具体的なデータのパスが含まれる。

すると、コンテナの起動依頼を受け付けたサービス用サーバのＤｏｃｋｅｒが、レジストリから、Ｄｏｃｋｅｒイメージの名前「ｈｏｇｅ／ａｐｐ１：ｖ１」に対応するＤｏｃｋｅｒイメージを取得（ｐｕｌｌ）する。そして、Ｄｏｃｋｅｒは、取得したＤｏｃｋｅｒイメージを用いてコンテナを起動する。そして、Ｄｏｃｋｅｒは、データ置き場から、データ置き場の具体的なデータのパスに対応するデータ「ａｐｐ１の学習モデル」を取得し、取得したデータをコンテナ内のマウントパスにマウントする（Ｓ１６３）。Ｄｏｃｋｅｒは、データ置き場から、データ置き場の具体的なデータのパスに対応するデータ「ａｐｐ１の学習データ」を取得し、取得したデータをコンテナ内のマウントパスにマウントする（Ｓ１６４）。

このようにして、アプリケーション開発者がカタログ操作のインターフェースの定義に従ってコンテナの起動方法の定義（カタログ）を登録する。この結果、ユーザは、データの保存場所や利用するＤｏｃｋｅｒイメージの組合せを意識しなくても、カタログの名前およびバージョンを指定するだけで、コンテナ上でアプリケーションを利用することができる。

［管理装置の構成］
図２は、実施例に係る管理装置の構成を示す機能ブロック図である。図２に示すように、管理装置１は、制御部１０および記憶部２０を有する。

制御部１０は、ＣＰＵ（Central Processing Unit）などの電子回路に対応する。そして、制御部１０は、各種の処理手順を規定したプログラムや制御データを格納するための内部メモリを有し、これらによって種々の処理を実行する。制御部１０は、データ操作部１１、カタログ操作部１２、サービス操作部１３およびコード管理連携部１４を有する。なお、データ操作部１１は、第１の操作部の一例である。サービス操作部１３は、第２の操作部の一例である。

記憶部２０は、例えば、ＲＡＭ、フラッシュメモリ（Flash Memory）などの半導体メモリ素子、または、ハードディスク、光ディスクなどの記憶装置である。記憶部２０は、データ情報２１およびカタログ情報２２を有する。

データ情報２１は、カタログで定義されたデータの実際の置き場の情報である。例えば、データ情報２１は、カタログおよびバージョンと、実際にデータが保存されているデータのパスとを対応付けた情報である。なお、データ情報２１は、後述するデータ操作部１１によって生成される。

カタログ情報２２は、複数のカタログの集合である。カタログは、コンテナの起動方法を定義した情報である。なお、カタログ情報２２は、カタログ操作部１２によって生成される。

ここで、カタログ情報２２のフォーマットの一例を、図３を参照して説明する。図３は、実施例に係るカタログ情報のフォーマットの一例を示す図である。図３に示すように、カタログ情報２２は、管理装置１のファイルシステムの任意のパス（図３では、／ｃａｔａｌｏｇ＿ｄａｔｅ）配下に保存される。任意のパス配下では、カタログＩＤ（IDentifier）ごとにディレクトリが区切られる。そして、区切られた各ディレクトリ配下にコンテナの起動定義が保存される。

コンテナの起動定義には、ｄｏｃｋｅｒ＿ｉｍａｇｅ、ｐｏｒｔｓ、ｅｎｖｓ、ａｓｓｅｔとしてｄａｔａｄｉｒとｍｏｄｅｌｄｉｒが含まれる。ｄｏｃｋｅｒ＿ｉｍａｇｅは、Ｄｏｃｋｅｒイメージの名前である。Ｄｏｃｋｅｒイメージの名前には、ユーザ名、イメージ名およびバージョンが含まれる。なお、イメージ名は、カタログ名と同じであっても良い。ｐｏｒｔｓは、通信で用いられるポート名である。ｅｎｖｓは、環境変数である。ｄａｔａｄｉｒには、データの種類が学習データ等のデータである場合のデータの指定（ｐａｔｈ）およびコンテナ内のマウントパス（ｍｏｕｎｔｄｉｒ）が含まれる。ｍｏｄｅｌｄｉｒには、データの種類が学習モデル等のモデルである場合のデータの指定（ｐａｔｈ）およびコンテナ内のマウントパス（ｍｏｕｎｔｄｉｒ）が含まれる。

一例として、カタログＩＤが「００１」である場合には、コンテナの起動定義として「ｃｏｎｔａｉｎｅｒ１．ｙｍｌ」と「ｃｏｎｔａｉｎｅｒ２．ｙｍｌ」とが存在する。すなわち、２個のコンテナの起動定義が設定されている。コンテナの起動定義が「ｃｏｎｔａｉｎｅｒ１．ｙｍｌ」である場合に、ｄｏｃｋｅｒ＿ｉｍａｇｅ（Ｄｏｃｋｅｒイメージの名前）として「ｋｕｒｏｍｔ／ａｐｐ１：ｖ１」が定義されている。ｄｏｃｋｅｒ＿ｉｍａｇｅの中の「ｋｕｒｏｍｔ」がユーザ名である。「ａｐｐ１」がイメージ名であり、カタログ名である。「ｖ１」がカタログのバージョンである。ｄａｔａｄｉｒには、ｍｏｕｎｔｄｉｒとして「／ｔｒａｉｎ」、ｐａｔｈとして「ｄａｔａｓｅｔ」が定義されている。すなわち、「ｄａｔａｓｅｔ」のデータは、マウントディレクトリの「／ｔｒａｉｎ」にマウントされることが定義されている。ｍｏｄｅｌｄｉｒには、ｍｏｕｎｔｄｉｒとして「／ｍｏｄｅｌ」、ｐａｔｈとして「ｍｏｄｅｌ」が定義されている。すなわち、「ｍｏｄｅｌ」の学習モデルは、マウントディレクトリの「／ｍｏｄｅｌ」にマウントされることが定義されている。

また、カタログ情報２２のフォーマットの別の例を、図４を参照して説明する。図４は、実施例に係るカタログ情報のフォーマットの別の例を示す図である。図４に示すカタログ情報２２は、テーブル形式のフォーマットで表わしたものである。図４に示すカタログ情報２２の１行目は、図３で示したｄｏｃｋｅｒ＿ｉｍａｇｅが「ｋｕｒｏｍｔ／ａｐｐ１：ｖ１」である場合のカタログの内容と同じ情報である。

図４に示すように、カタログ情報２２は、ｃａｔａｌｏｇ＿ｉｄ、ｃａｔａｌｏｇ＿ｖｅｒｓｉｏｎ、ｄｏｃｋｅｒ＿ｉｍａｇｅ、ｐｏｒｔ、Ｅｎｖｓおよびａｓｓｅｔを対応付けた情報である。ａｓｓｅｔは、ｄａｔａｄｉｒおよびｍｏｄｅｌｄｉｒが含まれる。ｄａｔａｄｉｒには、ｍｏｕｎｔｄｉｒおよびｐａｔｈが含まれる。ｍｏｄｅｌｄｉｒには、ｍｏｕｎｔｄｉｒおよびｐａｔｈが含まれる。ｃａｔａｌｏｇ＿ｉｄは、図３のカタログＩＤに対応する。ｃａｔａｌｏｇ＿ｖｅｒｓｉｏｎは、カタログのバージョンであり、Ｄｏｃｋｅｒタグに対応する情報である。ｄｏｃｋｅｒ＿ｉｍａｇｅは、図３のｄｏｃｋｅｒ＿ｉｍａｇｅに対応する。ｄｏｃｋｅｒ＿ｉｍａｇｅの中のバージョンが、前述したｃａｔａｌｏｇ＿ｖｅｒｓｉｏｎに対応する。ｐｏｒｔは、図３のｐｏｒｔｓに対応する。ａｓｓｅｔは、図３のａｓｓｅｔに対応する。

図２に戻って、データ操作部１１は、データ操作のインターフェースの定義に従って、アプリケーションが用いるデータをデータ置き場に保存する。データ置き場は、例えば、コンテナ実行基盤であっても良いし、別個の分散ファイルシステムであっても良い。また、データ操作部１１は、保存したデータのデータ情報をデータ情報２１に追加する。データ情報には、例えば、保存したデータについて、データ置き場の具体的なデータのパスが含まれる。

カタログ操作部１２は、カタログ操作のインターフェースの定義に従って、アプリケーションの実行環境のイメージの情報に、アプリケーションが用いるデータの情報を付加したコンテナの起動方法の定義情報を、カタログとしてカタログ情報２２に登録する。データの情報には、例えば、データの種類、データの指定（ｐａｔｈ）およびコンテナ内のマウントパスが含まれる。データの種類には、例えば、学習データ等のデータや学習モデル等のモデルが含まれる。

サービス操作部１３は、サービス操作のインターフェースの定義に従って、カタログ情報２２を参照し、カタログ名およびカタログのバージョンに対するコンテナを起動する。例えば、サービス操作部１３は、ユーザによってカタログ名およびカタログのバージョンが指定されると、カタログ情報２２を参照し、指定されたカタログ名が示すカタログＩＤおよびカタログのバージョンに対するカタログを取得する。サービス操作部１３は、データ情報２１を参照し、取得したカタログに指定されたデータやモデルに対するデータ置き場のそれぞれの具体的なデータのパスを取得する。そして、サービス操作部１３は、Ｄｏｃｋｅｒに対して、コンテナの起動を依頼する。コンテナの起動依頼には、カタログに含まれるＤｏｃｋｅｒイメージの名前、ポート、環境変数、データのパス、コンテナ内のマウントパスおよびデータ置き場の具体的なデータのパスが含まれる。

コード管理連携部１４は、アプリケーションのソースコードを管理するコード管理ツールを利用する場合に、当該ツールと連携する機能部である。例えば、コード管理連携部１４は、コード管理ツールに対して、Ｄｏｃｋｅｒイメージのビルドを依頼する。コード管理ツールは、依頼を受け付けると、自身が管理しているアプリケーションのソースコードおよびＤｏｃｋｅｒファイルを用いて、Ｄｏｃｋｅｒイメージをビルドする。そして、コード管理ツールは、ビルドしたＤｏｃｋｅｒイメージをレジストリ（Ｄｏｃｋｅｒイメージの置き場）に登録する。なお、コード管理ツールには、例えば、Ｇｉｔｌａｂが挙げられる。Ｇｉｔｌａｂは、Ｇｉｔコマンドを使ったソースコード管理のプラットフォームであり、アプリケーションのソースコードをプロジェクトとして管理する。また、Ｇｉｔｌａｂは、プロジェクトのコードを流用して別の機能を実装するためのブランチという概念や、ある時点でのコードを保存するタグという概念を持つ。また、Ｇｉｔｌａｂは、プロジェクトにあるアプリケーションのソースコードとＤｏｃｋｅｒファイルを使い、Ｄｏｃｋｅｒイメージをビルドしてレジストリに登録する機能を持つ。

［カタログ操作のシーケンスの一例］
図５は、実施例に係るカタログ操作のシーケンスの一例を示す図である。図５では、コード管理連携部１４およびコード管理ツールを利用しない場合を説明する。また、図５では、データが学習データおよびモデルである場合を説明する。なお、図５では、アプリケーション開発者が実行する処理を破線で示すものとする。

図５に示すように、アプリケーション開発者（例えば、ユーザ名「ｋｕｒｏｍｔ」）が、アプリケーション（ａｐｐ１）を開発する（Ｓ１１）。アプリケーション開発者が、アプリケーション（ａｐｐ１）からアクセスする学習データを作成するとともに、学習データからモデルを作成する（Ｓ１２）。そして、アプリケーション開発者が、作成した学習データとモデルの登録を管理装置１に依頼する（Ｓ１３）。

管理装置１では、データ操作部１１が、学習データとモデルとをそれぞれ分散ファイルシステム２に登録する（Ｓ１４，Ｓ１５）。そして、データ操作部１１は、登録したデータの情報をデータ情報２１に追加する（Ｓ１６）。例えば、データ操作部１１は、登録した学習データの分散ファイルシステム２上の具体的なデータのパスをデータ情報２１に追加する。データ操作部１１は、登録したモデルの、分散ファイルシステム２上の具体的なデータのパスをデータ情報２１に追加する。

続いて、アプリケーション開発者が、Ｄｏｃｋｅｒファイルを作成する（Ｓ１７）。アプリケーション開発者は、作成したＤｏｃｋｅｒファイルとアプリケーションのソースコードを用いて、Ｄｏｃｋｅｒイメージをビルドする（Ｓ１８）。そして、アプリケーション開発者は、ＤｏｃｋｅｒイメージをＤｏｃｋｅｒレジストリ３に登録する（Ｓ１９）。Ｄｏｃｋｅｒレジストリ３には、Ｄｏｃｋｅｒイメージ名として「ｋｕｒｏｍｔ／ａｐｐ１：ｖ１」のＤｏｃｋｅｒイメージが登録される。

続いて、アプリケーション開発者が、カタログの登録を管理装置１に依頼する（Ｓ２０）。例えば、ユーザ名が「ｋｕｒｏｍｔ」のアプリケーション開発者は、「ｃａｔａｌｏｇ＿ｎａｍｅ＝ａｐｐ１，ｖｅｒｓｉｏｎ＝ｖ１，ｄａｔａｄｉｒ＝｛ｍｏｕｎｔｄｉｒ＝／ｔｒａｉｎ，ｐａｔｈ＝ｄａｔａｓｅｔ｝，ｍｏｄｅｌｄｉｒ＝｛ｍｏｕｎｔｄｉｒ＝／ｍｏｄｅｌ，ｐａｔｈ＝ｍｏｄｅｌ｝」をパラメータとするカタログの登録依頼を管理装置１に送信したとする。すなわち、カタログ名（ｃａｔａｌｏｇ＿ｎａｍｅ）として「ａｐｐ１」、バージョン（ｖｅｒｓｉｏｎ）として「ｖ１」がパラメータに含まれている。学習データのデータディレクトリ（ｄａｔａｄｉｒ）として、学習データの指定（ｐａｔｈ）としての「ｄａｔａｓｅｔ」およびコンテナ内のマウントパスとしての「／ｔｒａｉｎ」がパラメータに含まれる。そして、モデルのモデルディレクトリ（ｍｏｄｅｌｄｉｒ）として、モデルの指定（ｐａｔｈ）としての「ｍｏｄｅｌ」およびコンテナ内のマウントパス（ｍｏｕｎｔｄｉｒ）としての「／ｍｏｄｅｌ」がパラメータに含まれる。なお、パラメータには、環境変数やポート等の実行引数の情報が追加されても良い。

管理装置１では、カタログ操作部１２が、カタログの登録依頼を受け付けると、登録依頼のパラメータを用いてカタログ定義を生成し、カタログ定義を登録する（Ｓ２１）。例えば、カタログ操作部１２は、登録を依頼したユーザ名、パラメータに含まれるカタログ名、バージョンから得られるＤｏｃｋｅｒイメージの名前をカタログに設定する。カタログ操作部１２は、パラメータに含まれる学習データのデータディレクトリおよびモデルのモデルディレクトリをカタログに設定する。そして、カタログ操作部１２は、このカタログをカタログ情報２２に登録する。なお、パラメータに環境変数やポート等の実行引数の情報が含まれている場合には、カタログ操作部１２は、これらの情報もカタログに設定して、このカタログをカタログ情報２２に登録する。つまり、カタログ操作部１２は、分散ファイルシステム２上のａｐｐ１用の学習データとａｐｐ１用のモデルをマウントするａｐｐ１：ｖ１コンテナの起動方法の定義をカタログとしてカタログ情報２２に登録する。

［サービス起動のシーケンスの一例］
図６は、実施例に係るサービス起動のシーケンスの一例を示す図である。図６では、データが学習データおよびモデルである場合を説明する。

図６に示すように、ユーザが、カタログ名が「ａｐｐ１」であり、バージョンが「ｖ１」であるサービスを利用したい場合に、カタログ名として「ａｐｐ１」、バージョンとして「ｖ１」、サービス名として「ｍｙｓｅｒｖｉｃｅ」を指定したサービスの立ち上げを依頼する（Ｓ３１）。例えば、ユーザは、「ｃａｔａｌｏｇ＿ｎａｍｅ＝ａｐｐ１，ｖｅｒｓｉｏｎ＝ｖ１，ｎａｍｅ＝ｍｙｓｅｒｖｉｃｅ」をパラメータとするサービスの立ち上げ依頼を管理装置１に送信する。なお、サービス名は、ユーザによって任意に指定されれば良い。

管理装置１では、サービス操作部１３が、サービスの立ち上げを受け付けると、立ち上げ依頼のパラメータを用いて、カタログ情報２２からカタログを読み込む（Ｓ３２）。例えば、サービス操作部１３は、カタログ情報２２を参照して、カタログ名「ａｐｐ１」、バージョン「ｖ１」に対するカタログを読み込む。

サービス操作部１３は、カタログに設定された学習データの指定やモデルの指定を用いて、データ情報２１から該当するデータの情報を読み込む（Ｓ３３）。例えば、サービス操作部１３は、カタログから、学習データの指定（ｐａｔｈ）として「ｄａｔａｓｅｔ」を取得する。サービス操作部１３は、カタログから、モデルの指定（ｐａｔｈ）として「ｍｏｄｅｌ」を取得する。そして、サービス操作部１３は、データ情報２１を参照して、学習データの指定（ｐａｔｈ）を示す「ｄａｔａｓｅｔ」に対する、分散ファイルシステム２上の具体的なデータのパスを取得する。サービス操作部１３は、データ情報２１を参照して、モデルの指定（ｐａｔｈ）を示す「ｍｏｄｅｌ」に対する、分散ファイルシステム２上の具体的なデータのパスを取得する。

サービス操作部１３は、コンテナ実行基盤４に対して、コンテナの起動を依頼する（Ｓ３４）。例えば、サービス操作部１３は、カタログに含まれるＤｏｃｋｅｒイメージの名前、ポート、環境変数、学習データおよびモデルの指定（ｐａｔｈ）、コンテナ内のマウントパスをパラメータとするコンテナの起動依頼を送信する。さらに、コンテナの起動依頼には、学習データおよびモデルの指定（ｐａｔｈ）に対する分散ファイルシステム２上の具体的なデータのパスが含まれる。

コンテナ実行基盤４では、Ｄｏｃｋｅｒが、コンテナの起動依頼を受け付けると、起動依頼のパラメータからＤｏｃｋｅｒイメージの名前を取得する。そして、Ｄｏｃｋｅｒは、取得したＤｏｃｋｅｒイメージの名前に対するＤｏｃｋｅｒイメージをＤｏｃｋｅｒレジストリから取得する（Ｓ３５）。ここでは、Ｄｏｃｋｅｒは、Ｄｏｃｋｅｒイメージ名が「ｋｕｒｏｍｔ／ａｐｐ１：ｖ１」であるＤｏｃｋｅｒイメージを取得する。

Ｄｏｃｋｅｒは、取得したＤｏｃｋｅｒイメージを用いてコンテナを起動する（Ｓ３６）。

続いて、Ｄｏｃｋｅｒは、起動依頼のパラメータから、学習データの指定（ｐａｔｈ）に対する、コンテナ内のマウントパスおよび分散ファイルシステム２上の具体的なデータのパスを取得する。Ｄｏｃｋｅｒは、分散ファイルシステム２上の具体的なデータのパスから、学習データの指定（ｐａｔｈ）に対する学習データを取得する（Ｓ３７）。そして、Ｄｏｃｋｅｒは、取得した学習データを、コンテナ内のマウントパスにマウントする（Ｓ３８）。

同様に、Ｄｏｃｋｅｒは、起動依頼のパラメータから、モデルの指定（ｐａｔｈ）に対する、コンテナ内のマウントパスおよび分散ファイルシステム２上の具体的なデータのパスを取得する。Ｄｏｃｋｅｒは、分散ファイルシステム２上の具体的なデータのパスから、モデルの指定（ｐａｔｈ）に対するモデルデータを取得する（Ｓ３９）。そして、Ｄｏｃｋｅｒは、取得したモデルデータを、コンテナ内のマウントパスにマウントする（Ｓ４０）。

管理装置１では、サービス操作部１３が、Ｄｏｃｋｅｒからコンテナの起動完了を受け付けると、ユーザに対してサービスの立ち上げ完了を通知する（Ｓ４１）。

ユーザは、サービスの立ち上げ完了を取得すると、立ち上がったコンテナに対して、例えばＷｅｂＡＰＩを通じて各種機能を利用する（Ｓ４２）。

これにより、ユーザは、コンテナ上で学習データ等のデータサイズが大きいデータを利用する場合であっても、コンテナを起動する際に外部のストレージに保存されたデータをマウントするので、Ｄｏｃｋｅｒイメージに大規模なデータを埋め込まなくても良い。すなわち、ユーザは、コンテナの中に埋め込まれるデータのデータ量の制限を気にしないで、コンテナを起動することができる。また、ユーザは、データの保存場所や利用するＤｏｃｋｅｒイメージの組合せを意識しなくても、コンテナ上でアプリケーションを利用することができるようになる。

［カタログ操作のシーケンスの別の例］
図７は、実施例に係るカタログ操作のシーケンスの別の例を示す図である。図７では、コード管理連携部１４およびコード管理ツールを利用する場合を説明する。また、図７では、データが学習データおよびモデルである場合を説明する。なお、図７では、アプリケーション開発者が実行する処理を破線で示すものとする。

図７に示すように、アプリケーション開発者（例えば、ユーザ名「ｋｕｒｏｍｔ」）が、アプリケーション（ａｐｐ１）を開発する（Ｓ５１）。アプリケーション開発者が、アプリケーション（ａｐｐ１）からアクセスする学習データを作成するとともに、学習データからモデルを作成する（Ｓ５２）。そして、アプリケーション開発者が、作成した学習データとモデルの登録を管理装置１に依頼する（Ｓ５３）。

管理装置１では、データ操作部１１が、学習データとモデルとをそれぞれ分散ファイルシステム２に登録する（Ｓ５４，Ｓ５５）。そして、データ操作部１１は、登録したデータの情報をデータ情報２１に追加する（Ｓ５６）。例えば、データ操作部１１は、登録した学習データの分散ファイルシステム２上の具体的なデータのパスをデータ情報２１に追加する。データ操作部１１は、登録したモデルの、分散ファイルシステム２上の具体的なデータのパスをデータ情報２１に追加する。

続いて、アプリケーション開発者が、Ｄｏｃｋｅｒファイルを作成する（Ｓ５７）。アプリケーション開発者は、作成したＤｏｃｋｅｒファイルとアプリケーションのソースコードとをＧｉｔｌａｂに対してコミットする（Ｓ５８）。例えば、アプリケーション開発者は、作成したＤｏｃｋｅｒファイルとアプリケーションのソースコードとをＧｉｔｌａｂのａｐｐ１プロジェクトのｍａｓｔｅｒブランチにコミットしたとする。

そして、アプリケーション開発者が、カタログの登録を管理装置１に依頼する（Ｓ５９）。例えば、ユーザ名が「ｋｕｒｏｍｔ」のアプリケーション開発者は、「ｐｒｏｊｅｃｔ＝ａｐｐ１，ｒｅｆ＝ｍａｓｔｅｒ，ｃａｔａｌｏｇ＿ｎａｍｅ＝ａｐｐ１，ｖｅｒｓｉｏｎ＝ｖ１，ｄａｔａｄｉｒ＝｛ｍｏｕｎｔｄｉｒ＝／ｔｒａｉｎ，ｐａｔｈ＝ｄａｔａｓｅｔ｝，ｍｏｄｅｌｄｉｒ＝｛ｍｏｕｎｔｄｉｒ＝／ｍｏｄｅｌ，ｐａｔｈ＝ｍｏｄｅｌ｝」をパラメータとするカタログの登録依頼を管理装置１に送信したとする。すなわち、Ｇｉｔｌａｂ５上のプロジェクト（ｐｒｏｊｅｃｔ）名として「ａｐｐ１」、ブランチ（ｒｅｆ）名として「ｍａｓｔｅｒ」がパラメータに含まれている。そして、カタログ名（ｃａｔａｌｏｇ＿ｎａｍｅ）として「ａｐｐ１」、バージョン（ｖｅｒｓｉｏｎ）として「ｖ１」がパラメータに含まれている。学習データのデータディレクトリ（ｄａｔａｄｉｒ）として、学習データの指定（ｐａｔｈ）としての「ｄａｔａｓｅｔ」およびコンテナ内のマウントパスとしての「／ｔｒａｉｎ」がパラメータに含まれる。そして、モデルのモデルディレクトリ（ｍｏｄｅｌｄｉｒ）として、モデルの指定（ｐａｔｈ）としての「ｍｏｄｅｌ」およびコンテナ内のマウントパス（ｍｏｕｎｔｄｉｒ）としての「／ｍｏｄｅｌ」がパラメータに含まれる。なお、パラメータには、環境変数やポート等の実行引数の情報が追加されても良い。

管理装置１では、カタログ操作部１２が、カタログの登録依頼を受け付けると、登録依頼のパラメータから、Ｄｏｃｋｅｒイメージのビルド対象のコードがあるプロジェクトおよびブランチを取得する。カタログ操作部１２は、ａｐｐ１プロジェクトのｍａｓｔｅｒブランチにあるコードのＤｏｃｋｅｒイメージのビルドを、コード管理連携部１４を連携させてＧｉｔｌａｂ５に依頼する（Ｓ６０，Ｓ６１）。

Ｇｉｔｌａｂ５では、Ｄｏｃｋｅｒイメージのビルドの依頼を受け付けると、Ｇｉｔｌａｂ Ｒｕｎｎｅｒが、ａｐｐ１プロジェクトのｍａｓｔｅｒブランチにあるＤｏｃｋｅｒファイルとアプリケーションのソースコードを取得する（Ｓ６２）。Ｇｉｔｌａｂ Ｒｕｎｎｅｒは、取得したＤｏｃｋｅｒファイルとアプリケーションのソースコードを用いて、Ｄｏｃｋｅｒイメージをビルドする（Ｓ６３）。そして、Ｇｉｔｌａｂ Ｒｕｎｎｅｒは、ＤｏｃｋｅｒイメージをＤｏｃｋｅｒレジストリ３に登録する（Ｓ６４）。Ｄｏｃｋｅｒレジストリ３には、Ｄｏｃｋｅｒイメージ名として「ｋｕｒｏｍｔ／ａｐｐ１：ｖ１」のＤｏｃｋｅｒイメージが登録される。そして、Ｇｉｔｌａｂ５では、Ｄｏｃｋｅｒイメージのビルドの完了を、コード管理連携部１４を連携させてカタログ操作部１２に通知する（Ｓ６５，Ｓ６６）。

管理装置１では、カタログ操作部１２が、ビルドが完了したコードを保存するために、ｖ１のタグでコードを保存するように、コード管理連携部１４を連携させてＧｉｔｌａｂ５に依頼する（Ｓ６７，Ｓ６８）。

Ｇｉｔｌａｂ５では、ｖ１のタグでコードを保存する旨の依頼を受け付けると、ｖ１のタグを生成し、ａｐｐ１プロジェクトのｍａｓｔｅｒブランチにあるＤｏｃｋｅｒファイルとアプリケーションのソースコードをｖ１のタグで保存する（Ｓ６９）。

続いて、管理装置１では、カタログ操作部１２が、アプリケーション開発者からの登録依頼のパラメータを用いてカタログ定義を生成し、カタログ定義を登録する（Ｓ７０）。例えば、カタログ操作部１２は、登録を依頼したユーザ名、パラメータに含まれるカタログ名、バージョンから得られるＤｏｃｋｅｒイメージの名前をカタログに設定する。カタログ操作部１２は、パラメータに含まれる学習データのデータディレクトリおよびモデルのモデルディレクトリをカタログに設定する。そして、カタログ操作部１２は、このカタログをカタログ情報２２に登録する。なお、パラメータに環境変数やポート等の実行引数の情報が含まれている場合には、カタログ操作部１２は、これらの情報もカタログに設定して、このカタログをカタログ情報２２に登録する。つまり、カタログ操作部１２は、分散ファイルシステム２上のａｐｐ１用の学習データとａｐｐ１用のモデルをマウントするａｐｐ１：ｖ１コンテナの起動方法の定義をカタログとしてカタログ情報２２に登録する。

［管理装置の用途］
図８は、実施例に係る管理装置の用途の一例を示す図である。図８では、株価予測に用いる場合を説明する。

図８に示すように、機械学習の知識を持つアプリケーションの開発者が、株価予測のモデルを作成したので、サービスとして公開する。すると、アプリケーションの開発者は、株価予測のモデルの登録を管理装置１に依頼する（Ｓ８１）。すると、管理装置１のデータ操作部１１は、登録依頼された株価予測のモデルをデータ格納部３´に登録する（Ｓ８２）。加えて、データ操作部１１は、登録されたモデルのデータ格納部３´上の具体的なデータのパスをデータ情報２１に追加する。

そして、アプリケーションの開発者が、株価予測のＷｅｂＡＰＩ（ａｐｐｘ）を株価予測のモデルのデータ（ｘｘｘ）と紐付けた情報をカタログとして登録するように、管理装置１に依頼する（Ｓ８３）。例えば、ユーザ名が「ｋｕｒｏｍｔ」のアプリケーション開発者は、「ｃａｔａｌｏｇ＿ｎａｍｅ＝ａｐｐｘ，ｖｅｒｓｉｏｎ＝ｖ１，ｍｏｄｅｌｄｉｒ＝｛ｍｏｕｎｔｄｉｒ＝／ｍｏｄｅｌ，ｐａｔｈ＝ｘｘｘ｝」をパラメータとするカタログの登録依頼を管理装置１に送信する。

すると、管理装置１のカタログ操作部１２は、登録依頼のパラメータを用いてカタログ定義を生成し、カタログ定義をカタログ情報２２に登録する。

ここで、機械学習やＤｏｃｋｅｒコンテナの知識を持たないユーザが、手持ちの株価データを使い、明日の株価を予測したいとする。すると、ユーザは、利用したいカタログ名と、バージョンを指定して、株価予測のサービスの起動を依頼する（Ｓ８４）。例えば、ユーザは、カタログ名が「ａｐｐｘ」であり、バージョンが「ｖ１」であるサービスを利用する場合に、カタログ名として「ａｐｐｘ」、バージョンとして「ｖ１」、サービス名として「ｓｓｓ」のサービスの起動依頼を管理装置１に送信する。

すると、管理装置１のサービス操作部１３は、カタログ情報２２を参照して、カタログ名「ａｐｐｘ」、バージョン「ｖ１」に対するカタログを読み込む。サービス操作部１３は、カタログに設定されたモデルの指定（ｐａｔｈ）を用いて、データ情報２１から当該モデルのデータ格納部３´上の具体的なデータパスを読み込む。そして、サービス操作部１３は、カタログの内容およびモデルの具体的なデータパスをパラメータとするコンテナの起動依頼を、実行環境４´に対して送信する（Ｓ８５）。

実行環境４´では、Ｄｏｃｋｅｒが、株価予測のＤｏｃｋｅｒイメージを用いて株価予測サービスのコンテナを起動する。そして、Ｄｏｃｋｅｒは、起動依頼のパラメータからモデルの指定（ｐａｔｈ）に対する、コンテナ内のマウントパスおよびデータ格納部３´上の具体的なデータパスを取得する。そして、Ｄｏｃｋｅｒは、取得したデータパスから株価予測モデルを取得し、取得したモデルを、コンテナ内のマウントパスにマウントする（Ｓ８６）。

そして、ユーザは、実行環境４´に起動されたコンテナ上で動く株価予測のサービスを利用して、明日の株価を予測する（Ｓ８７）。

このようにして、機械学習の詳細な知識を持たないユーザが、開発者のデータを使って、開発者が用意したコンテナの起動方法を知ることなく、自己のために機械学習をするためのサービスを立ち上げることができる。また、ユーザは、コンテナ上でデータのサイズが大きいサービスを動かす場合であっても、コンテナを起動する際に外部のストレージに保存されたデータをマウントするので、Ｄｏｃｋｅｒイメージに大規模なデータを埋め込まなくても良い。すなわち、ユーザは、コンテナの中に埋め込むデータ量の制限を気にしないで、コンテナを起動することができる。また、ユーザは、データの保存場所や利用するＤｏｃｋｅｒイメージの組合せを意識しなくても、コンテナ上で動くサービスを利用することができる。

［実施例の効果］
実施例によると、管理装置１は、アプリケーションの実行環境が配置される領域を示すコンテナの起動方法を定義する際に、データ操作のインターフェースの定義に従って、アプリケーションが用いるデータを保存する。管理装置１は、アプリケーションの実行環境のイメージを保存する。管理装置１は、コンテナ操作のインターフェースの定義に従って、アプリケーションの実行環境のイメージの情報に、コンテナの中でアプリケーションが用いるデータのデータ情報を付加したコンテナの起動方法をカタログ情報２２に登録する。かかる構成によれば、管理装置１は、コンテナの起動方法を登録することで、ユーザがデータの保存場所や利用するアプリケーションの実行環境のイメージの組合せを意識しなくても、コンテナでアプリケーションを利用することができる。

また、カタログ情報２２は、アプリケーションの実行環境のイメージの名称、イメージのバージョン、データを保存した位置およびデータをマウントする位置を含む情報である。かかる構成によれば、管理装置１は、コンテナの起動方法をカタログとして登録することで、ユーザが、使用したいデータの保存場所や利用するアプリケーション実行環境イメージの組合せを意識しなくても、アプリケーションを利用することができる。

また、管理装置１は、サービス操作のインターフェースの定義に従って、カタログ情報２２を参照し、コンテナの起動方法としてのカタログの識別情報および当該カタログのバージョンに対するコンテナを起動する、かかる構成によれば、管理装置１は、カタログの識別情報と当該カタログのバージョンを用いて、該当するコンテナを起動することで、ユーザが、使用したいデータの保存場所や利用するアプリケーション実行環境イメージの組合せを意識しなくても、アプリケーションを利用することができる。

また、管理装置１は、アプリケーションの開発者によって実施されるコンテナ操作のインターフェースの定義に従って、コンテナ操作に対応するカタログをカタログ情報２２に登録する。管理装置１は、ユーザによって実施されるサービス操作のインターフェースの定義に従って、コンテナを起動する。かかる構成によれば、ユーザは、容易にアプリケーションを利用する環境を再現できる。

［その他］
なお、上記実施例では、ユーザが、カタログ名およびカタログのバージョンをパラメータとするサービスの立ち上げ依頼を管理装置１に送信すると説明した。そして、管理装置１では、サービス操作部１３が、指定されたカタログ名およびカタログのバージョンに対するカタログを用いてＤｏｃｋｅｒに対してコンテナの立ち上げを依頼する。しかしながら、ユーザは、これに限定されず、カタログ名およびカタログのバージョンの他、さらに、自身のデータの情報をパラメータとするサービスの立ち上げ依頼を管理装置１に送信しても良い。例えば、ユーザは、「ｃａｔａｌｏｇ＿ｎａｍｅ＝ａｐｐ１，ｖｅｒｓｉｏｎ＝ｖ１，ｎａｍｅ＝ｍｙｓｅｒｖｉｃｅ，ｄａｔａｄｉｒ＝｛ｍｏｕｎｔｄｉｒ＝／ｙｙｙ，ｐａｔｈ＝ｄａｔａｙｙｙ｝」をパラメータとするサービスの立ち上げ依頼を管理装置１に送信する。ここで、ｄａｔａｄｉｒには、自身のデータの情報が指定される。すなわち、ｄａｔａｄｉｒには、ｍｏｕｎｔｄｉｒとして「／ｙｙｙ」、ｐａｔｈとして「ｄａｔａｙｙｙ」が指定されている。すなわち、「ｄａｔａｙｙｙ」のデータは、コンテナ上のマウントディレクトリの「／ｙｙｙ」にマウントされることが指定されている。なお、サービス名（ｎａｍｅ）は、ユーザによって任意に指定されれば良い。

また、上記実施例の管理装置１は、既知のパーソナルコンピュータ、ワークステーションなどの情報処理装置に、上記した制御部１０および記憶部２０などの各機能を搭載することによって実現することができる。

また、上記実施例では、図示した装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、装置の分散・統合の具体的態様は図示のものに限られず、その全部または一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、データ操作部１１とカタログ操作部１２とを統合しても良い。カタログ操作部１２は、コード管理連携部１４を利用する場合と、利用しない場合とに分散しても良い。記憶部２０を管理装置１の外部装置としてネットワーク経由で接続するようにしても良い。

また、上記実施例で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーション等のコンピュータで実行することによって実現することができる。そこで、以下では、図２に示した管理装置１と同様の機能を実現するプログラムを実行するコンピュータの一例を説明する。図９は、操作制御プログラムを実行するコンピュータの一例を示す図である。

図９に示すように、コンピュータ２００は、各種演算処理を実行するＣＰＵ２０３と、ユーザからのデータの入力を受け付ける入力装置２１５と、表示装置２０９を制御する表示制御部２０７とを有する。また、コンピュータ２００は、記憶媒体からプログラム等を読取るドライブ装置２１３と、ネットワークを介して他のコンピュータとの間でデータの授受を行う通信制御部２１７とを有する。また、コンピュータ２００は、各種情報を一時記憶するメモリ２０１と、ＨＤＤ２０５を有する。そして、メモリ２０１、ＣＰＵ２０３、ＨＤＤ２０５、表示制御部２０７、ドライブ装置２１３、入力装置２１５、通信制御部２１７は、バス２１９で接続されている。

ドライブ装置２１３は、例えばリムーバブルディスク２１１用の装置である。ＨＤＤ２０５は、操作制御プログラム２０５ａおよび操作制御関連情報２０５ｂを記憶する。

ＣＰＵ２０３は、操作制御プログラム２０５ａを読み出して、メモリ２０１に展開し、プロセスとして実行する。かかるプロセスは、管理装置１の各機能部に対応する。操作制御関連情報２０５ｂは、データ情報２１およびカタログ情報２２に対応する。そして、例えばリムーバブルディスク２１１が、操作制御プログラム２０５ａ等の各情報を記憶する。

なお、操作制御プログラム２０５ａについては、必ずしも最初からＨＤＤ（Hard Disk Drive）２０５に記憶させておかなくても良い。例えば、コンピュータ２００に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ－ＲＯＭ（Compact Disk Read Only Memory）、ＤＶＤ（Digital Versatile Disk）、光磁気ディスク、ＩＣ（Integrated Circuit）カード等の「可搬用の物理媒体」に当該プログラムを記憶させておく。そして、コンピュータ２００がこれらから操作制御プログラム２０５ａを読み出して実行するようにしても良い。

１ 管理装置
１０ 制御部
１１ データ操作部
１２ カタログ操作部
１３ サービス操作部
１４ コード管理連携部
２０ 記憶部
２１ データ情報
２２ カタログ情報

Claims (4)

1. コンピュータが、
   所定のアプリケーションの実行環境が配置される領域を示すコンテナの起動方法を定義する際に、データ操作のインターフェースの定義に従って、前記アプリケーションが用いるデータをデータの保存場所に保存し、
   前記アプリケーションの実行環境だけのイメージをイメージの保存場所に保存し、
   コンテナ操作のインターフェースの定義に従って、前記アプリケーションの実行環境のイメージの情報に、前記コンテナの中で前記アプリケーションが用いるデータのデータ情報を付加した定義情報であって前記アプリケーションの実行環境のイメージの名称、前記イメージのバージョン、前記データを保存した保存場所および前記コンテナの中で前記データをマウントする場所を含む定義情報を、記憶部に登録し、
   前記イメージの名称および前記イメージのバージョンを受け付けると、前記記憶部から前記イメージの名称および前記イメージのバージョンに対応する前記定義情報を取得し、サービス操作のインターフェースの定義に従って、前記定義情報に基づいて、前記イメージのバージョンに対するコンテナを起動する
   処理を実行する
   処理を実行することを特徴とする操作制御方法。
2. 前記記憶部に登録する処理は、アプリケーションの開発者によって実施されるコンテナ操作のインターフェースの定義に従って、前記コンテナ操作に対応する前記定義情報を前記記憶部に登録し、
   前記コンテナを起動する処理は、ユーザによって実施されるサービス操作のインターフェースの定義に従って、前記コンテナを起動する
   ことを特徴とする請求項１に記載の操作制御方法。
3. 所定のアプリケーションの実行環境が配置される領域を示すコンテナの起動方法を定義する際に、データ操作のインターフェースの定義に従って、前記アプリケーションが用いるデータをデータの保存場所に保存する第１の操作部と、
   前記アプリケーションの実行環境だけのイメージをイメージの保存場所に保存する保存部と、
   コンテナ操作のインターフェースの定義に従って、前記アプリケーションの実行環境のイメージの情報に、前記コンテナの中で前記アプリケーションが用いるデータのデータ情報を付加した定義情報であって前記アプリケーションの実行環境のイメージの名称、前記イメージのバージョン、前記データを保存した保存場所および前記コンテナの中で前記データをマウントする場所を含む定義情報を、記憶部に登録する第２の操作部と、
   前記イメージの名称および前記イメージのバージョンを受け付けると、前記記憶部から前記イメージの名称および前記イメージのバージョンに対応する前記定義情報を取得し、サービス操作のインターフェースの定義に従って、前記定義情報に基づいて、前記イメージのバージョンに対するコンテナを起動する起動部と、
   を有することを特徴とする情報処理装置。
4. 所定のアプリケーションの実行環境が配置される領域を示すコンテナの起動方法を定義する際に、データ操作のインターフェースの定義に従って、前記アプリケーションが用いるデータをデータの保存場所に保存し、
   前記アプリケーションの実行環境だけのイメージをイメージの保存場所に保存し、
   コンテナ操作のインターフェースの定義に従って、前記アプリケーションの実行環境のイメージの情報に、前記コンテナの中で前記アプリケーションが用いるデータのデータ情報を付加した定義情報であって前記アプリケーションの実行環境のイメージの名称、前記イメージのバージョン、前記データを保存した保存場所および前記コンテナの中で前記データをマウントする場所を含む定義情報を、記憶部に登録し、
   前記イメージの名称および前記イメージのバージョンを受け付けると、前記記憶部から前記イメージの名称および前記イメージのバージョンに対応する前記定義情報を取得し、サービス操作のインターフェースの定義に従って、前記定義情報に基づいて、前記イメージのバージョンに対するコンテナを起動する
   処理をコンピュータに実行させることを特徴とする操作制御プログラム。

Images