(57)【要約】      （修正有）【課題】様々なアプリケーション毎に仮想化イメージを構築するインフラ構築担当者であっても容易に仮想化イメージを起動可能にする。【解決手段】ユーザにより作成又は更新されたアプリケーションプログラムを管理するアプリケーションプログラム管理装置と接続可能な、特定のプロセスを他のプロセスと独立して動作させる仮想的な環境であるコンテナを収容するコンテナ収容装置であって、アプリケーションプログラム管理装置で管理されているアプリケーションプログラムを自動的に取得し、取得された特定のプロセスを実行するためのアプリケーションプログラムを動作可能に展開する。展開されたアプリケーションプログラムによる特定のプロセスを仮想的な環境にあるコンテナとして起動させる。【選択図】なし【特許請求の範囲】
【請求項１】
ユーザにより作成又は更新されたアプリケーションプログラムを管理するアプリケーションプログラム管理装置と接続可能な、特定のプロセスを他のプロセスと独立して動作させる仮想的な環境であるコンテナを収容するコンテナ収容装置であって、
前記アプリケーションプログラム管理装置で管理されているアプリケーションプログラムを取得するアプリケーションプログラム取得手段と、
前記アプリケーションプログラム取得手段により取得された特定のプロセスを実行するためのアプリケーションプログラムを動作可能に展開するアプリケーションプログラム展開手段と、
前記アプリケーションプログラム展開手段により展開されたアプリケーションプログラムによる特定のプロセスを仮想的な環境にあるコンテナとして起動させるコンテナ起動手段と、
を有することを特徴とするコンテナ収容装置。
【請求項２】
前記アプリケーションプログラム取得手段により取得される前記アプリケーションプログラム管理装置にある前記アプリケーションプログラムは、前記コンテナ収容装置に取得されると、アプリケーションプログラム名を変更するアプリケーションプログラム名変更手段を有することを特徴とする請求項１に記載のコンテナ収容装置。
【請求項３】
前記アプリケーションプログラム取得手段は、前記アプリケーションプログラム管理装置への認証情報を保持しており、該アプリケーションプログラム管理装置からアプリケーションプログラムを取得する際に、該認証情報を使って該アプリケーションプログラム管理装置への認証処理を行い、該アプリケーションプログラムを取得することを特徴とする請求項１又は２に記載のコンテナ収容装置。
【請求項４】
ユーザにより作成又は更新されたアプリケーションプログラムを管理するアプリケーションプログラム管理装置と、
前記アプリケーションプログラム管理装置と接続可能な、特定のプロセスを他のプロセスと独立して動作させる仮想的な環境であるコンテナを収容するコンテナ収容装置とを有するシステムであって、
前記コンテナ収容装置は、
前記アプリケーションプログラム管理装置で管理されているアプリケーションプログラムを取得するアプリケーションプログラム取得手段と、
前記アプリケーションプログラム取得手段により取得された特定のプロセスを実行するためのアプリケーションプログラムを動作可能に展開するアプリケーションプログラム展開手段と、
前記アプリケーションプログラム展開手段により展開されたアプリケーションプログラムによる特定のプロセスを仮想的な環境にあるコンテナとして起動させるコンテナ起動手段と、
を有することを特徴とするシステム。
【請求項５】
前記アプリケーションプログラム管理装置は、
アプリケーションプログラムが前記ユーザにより作成あるいは更新し、確定されると、前記アプリケーションプログラム取得手段が取得する位置に前記アプリケーションプログラムをコピーするアプリケーションプログラムコピー手段
を有することを特徴とする請求項４に記載のシステム。
【請求項６】
ユーザにより作成又は更新されたアプリケーションプログラムを管理するアプリケーションプログラム管理装置と接続可能な、特定のプロセスを他のプロセスと独立して動作させる仮想的な環境であるコンテナを収容するコンテナ収容装置におけるコンテナ収容方法であって、
前記アプリケーションプログラム管理装置で管理されているアプリケーションプログラムを取得するアプリケーションプログラム取得方法と、
前記アプリケーションプログラム取得方法により取得された特定のプロセスを実行するためのアプリケーションプログラムを動作可能に展開するアプリケーションプログラム展開方法と、
前記アプリケーションプログラム展開方法により展開されたアプリケーションプログラムによる特定のプロセスを仮想的な環境にあるコンテナとして起動させるコンテナ起動方法と、
を有することを特徴とするコンテナ収容方法。
【請求項７】
ユーザにより作成又は更新されたアプリケーションプログラムを管理するアプリケーションプログラム管理装置と接続可能な、特定のプロセスを他のプロセスと独立して動作させる仮想的な環境であるコンテナを収容するコンテナ収容装置におけるプログラムであって、
前記コンテナ収容装置を、
前記アプリケーションプログラム管理装置で管理されているアプリケーションプログラムを取得するアプリケーションプログラム取得手段と、
前記アプリケーションプログラム取得手段により取得された特定のプロセスを実行するためのアプリケーションプログラムを動作可能に展開するアプリケーションプログラム展開手段と、
前記アプリケーションプログラム展開手段により展開されたアプリケーションプログラムによる特定のプロセスを仮想的な環境にあるコンテナとして起動させるコンテナ起動手段として動作させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、仮想化サーバを構築する際の情報処理システム、情報処理方法及びプログラムに関する。
【背景技術】
【０００２】
近年広く用いられる仮想化サーバには効率性や仕組みの違いによりいくつかの方式があり、ＯＳが起動し利用可能になるまでの待ち時間を短くすることができるコンテナ型仮想化技術により実現されたものがある。
【０００３】
特許文献１によると、サーバリソースをユーザ間で共用する共用ホスティングサービスにおいて、リソースの制御をユーザ毎に適切に行う技術が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１７−１１１７６１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
特許文献１の技術では、コンテナ収納装置の場合、複数のコンテナ（仮想的な環境）は、関連するアプリケーション毎にカーネル単位で隔離されて作成・動作している。
【０００６】
システム開発する場合、アプリケーションの開発はアプリ開発担当者が担当し、開発されたアプリケーションを実行環境でリリース（すなわち、カーネル空間を管理）するのはインフラ構築担当者が分担してそれぞれ行うことが広く行われている。
【０００７】
アプリケーションはカーネル単位で隔離されて作成されているため、アプリ開発担当者が開発されたアプリケーションを実行させるまでには、まずアプリ開発担当者がカーネル空間の構築のためインフラ構築担当者に対してリリース依頼をする必要がある。
【０００８】
しかしながら、インフラ構築担当者は様々なアプリケーション毎に仮想化イメージを構築する依頼を受けるため、依頼を受けたインフラ構築担当者は、アプリ開発担当者からの依頼毎にテスト実行するアプリケーションプログラムを受け取り、所定のフォルダに配置してテスト実行環境を構築しなければならず、複数の実行環境変更依頼があった場合、迅速な作業が難しくなる。そのため、仮想化イメージを起動しアプリケーションを実装可能にしたコンテナが利用可能になるまでの待ち時間を短くするといったコンテナ型仮想化技術の特長を十分に生かすことができないという課題があった。
【０００９】
そこで本発明は、様々なアプリケーション毎に仮想化イメージを構築するインフラ構築担当者であっても容易に仮想化イメージを起動可能にするという課題を解決する。
【課題を解決するための手段】
【００１０】
本発明は、ユーザにより作成又は更新されたアプリケーションプログラムを管理するアプリケーションプログラム管理装置と接続可能な、特定のプロセスを他のプロセスと独立して動作させる仮想的な環境であるコンテナを収容するコンテナ収容装置であって、前記アプリケーションプログラム管理装置で管理されているアプリケーションプログラムを取得するアプリケーションプログラム取得手段と、前記アプリケーションプログラム取得手段により取得された特定のプロセスを実行するためのアプリケーションプログラムを動作可能に展開するアプリケーションプログラム展開手段と、前記アプリケーションプログラム展開手段により展開されたアプリケーションプログラムによる特定のプロセスを仮想的な環境にあるコンテナとして起動させるコンテナ起動手段と、を有することを特徴とする。
【発明の効果】
【００１１】
本発明によれば、様々なアプリケーション毎に仮想化イメージを構築するインフラ構築担当者であっても容易に仮想化イメージを起動可能にし、複数の実行環境変更依頼であっても短時間で複数のコンテナを構築させることを可能とする。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施形態における、システム構成の一例を示すブロック図である。
【図２】本発明の実施形態における、情報処理装置に適応されるハードウェア構成の一例を示すブロック図である。
【図３】本発明の実施形態における、開発担当者クライアント１０１及びインフラ担当者クライアント１０２により実行される事前処理の流れである。
【図４】本発明の実施形態における、Ｄｏｃｋｅｒサーバ１１１でテスト環境を構築するために実行される処理の流れである。
【図５】本発明の実施形態における、Ｄｏｃｋｅｒサーバ１１１で実行されるＤｏｃｋｅｒイメージをビルドする処理の一例を説明するフローチャートである。
【図６】本発明の実施形態における、バージョン管理サーバ１１２のアプリケーションプログラムのフォルダ構成の変化を中心に説明した図である。
【図７】本発明の実施形態における、複数のアプリケーションプログラム毎に起動されるコンテナによって構成されるシステムの例を説明する模式図である。
【図８】本発明の実施形態における、インフラ担当者クライアント１０２からＤｏｃｋｅｒサーバ１１１に送信されるＤｏｃｋｅｒｆｉｌｅの一例である。
【発明を実施するための形態】
【００１３】
以下、図面を参照して、本発明の実施形態を詳細に説明する。
【００１４】
図１は、本発明の実施形態における、システム構成の一例を示すブロック図である。
【００１５】
図１に示すように、本実施の形態に係るシステムは、Ｄｏｃｋｅｒサーバ１１１とバージョン管理サーバ１１２、開発担当者クライアント１０１、インフラ担当者クライアント１０２を有する。
【００１６】
Ｄｏｃｋｅｒサーバ１１１とバージョン管理サーバ１１２、開発担当者クライアント１０１、インフラ担当者クライアント１０２はそれぞれ、イントラネット１２０により接続されており、お互いに通信が可能である。また、Ｄｏｃｋｅｒサーバ１１１とバージョン管理サーバ１１２、開発担当者クライアント１０１とインフラ担当者クライアント１０２はそれぞれ、１つ又は複数の物理的な情報処理装置であってもよいし、１つ又は複数の仮想サーバやクライアントであってもよい。
【００１７】
Ｄｏｃｋｅｒサーバ１１１は、各ユーザに対して共用ホスティングサービスを提供する装置であり、Ｄｏｃｋｅｒサーバ１１１内に複数のコンテナが作成される。各コンテナは、コンテナ内で利用するリソースが他のコンテナとは隔離されている。
【００１８】
Ｄｏｃｋｅｒサーバ１１１は、インフラ担当者クライアント１０２からの指示（具体的にはＤｏｃｋｅｒｆｉｌｅ）によって、Ｄｏｃｋｅｒ向けのコンテナ共有サービス「Ｄｏｃｋｅｒハブ」からインターネットを経由してＯＳ環境とアプリケーションを含んだイメージを入手する。このイメージは、一般的に，「Ｄｏｃｋｅｒイメージ」と呼ばれ、Ｌｉｎｕｘ（登録商標）ＯＳやアプリケーションを含んだ一種のテンプレートである。すでにＤｏｃｋｅｒハブに用意されているイメージをそのまま利用することができるため、ＯＳやアプリケーションのインストールや初期設定等に係る煩雑な作業工数の大幅な削減が可能となる。
【００１９】
バージョン管理サーバ１１２は、図示しない運用サーバもしくはＤｏｃｋｅｒサーバ１１１で稼働するアプリケーションを開発するプログラムファイルの変更履歴を管理するサーバである。管理されているプログラムファイルは過去の変更点や変更日付毎に復元が可能であり、変更履歴のプログラムファイルを実行する際には、ブランチとしてプロジェクトを分岐させ、タグを付けてテスト実行させることがある。
【００２０】
開発担当者クライアント１０１は、図示しない運用サーバもしくはＤｏｃｋｅｒサーバ１１１で稼働するアプリケーションを開発する開発担当者が使用する情報処理端末であり、開発担当者がアプリケーションのソースコードを作成、編集してバージョン管理サーバ１１２に登録するためのクライアントである。
【００２１】
インフラ担当者クライアント１０２は、Ｄｏｃｋｅｒサーバ１１１が入手したＤｏｃｋｅｒイメージに含まれるＯＳやアプリケーションの設定を変更させるための「ＤｏｃｋｅｒＦｉｌｅ」をインフラ担当者が作成させてＤｏｃｋｅｒサーバ１１１にアップロードする情報処理端末である。本発明のＤｏｃｋｅｒＦｉｌｅには開発担当者が開発したアプリケーションをバージョン管理サーバからチェックアウトさせて開発したアプリケーションをＤｏｃｋｅｒサーバ１１１に展開させる処理も含まれている。
【００２２】
図２は、本発明の実施形態における開発担当者クライアント１０１、インフラ担当者クライアント１０２、Ｄｏｃｋｅｒサーバ１１１、バージョン管理サーバ１１２などに適応される情報処理装置のハードウェア構成の一例を示すブロック図である。
【００２３】
図２に示すように、情報処理装置は、システムバス２０４を介してＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）２０１、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）２０２、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）２０３、入力コントローラ２０５、ビデオコントローラ２０６、メモリコントローラ２０７、よび通信Ｉ／Ｆコントローラ２０８が接続される。
【００２４】
ＣＰＵ２０１は、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。
【００２５】
ＲＯＭ２０２あるいは外部メモリ２１１は、ＣＰＵ２０１が実行する制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ／Ｏｕｔｐｕｔ  Ｓｙｓｔｅｍ）やＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）や、本情報処理方法を実現するためのコンピュータ読み取り実行可能なプログラムおよび必要な各種データ（データテーブルを含む）を保持している。
【００２６】
ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＯＭ２０２あるいは外部メモリ２１１からＲＡＭ２０３にロードし、ロードしたプログラムを実行することで各種動作を実現する。
【００２７】
入力コントローラ２０５は、キーボード２０９や不図示のマウス等のポインティングデバイス等の入力装置からの入力を制御する。入力装置がタッチパネルの場合、ユーザがタッチパネルに表示されたアイコンやカーソルやボタンに合わせて押下（指等でタッチ）することにより、各種の指示を行うことができることとする。
【００２８】
また、タッチパネルは、マルチタッチスクリーンなどの、複数の指でタッチされた位置を検出することが可能なタッチパネルであってもよい。
【００２９】
ビデオコントローラ２０６は、ディスプレイ２１０などの外部出力装置への表示を制御する。ディスプレイは本体と一体になったノート型パソコンのディスプレイも含まれるものとする。なお、外部出力装置はディスプレイに限ったものははく、例えばプロジェクタであってもよい。また、前述のタッチ操作を受け付け可能な装置については、入力装置も提供する。
【００３０】
なおビデオコントローラ２０６は、表示制御を行うためのビデオメモリ（ＶＲＡＭ）を制御することが可能で、ビデオメモリ領域としてＲＡＭ２０３の一部を利用することもできるし、別途専用のビデオメモリを設けることも可能である。
【００３１】
メモリコントローラ２０７は、外部メモリ２１１へのアクセスを制御する。外部メモリとしては、ブートプログラム、各種アプリケーション、フォントデータ、ユーザファイル、編集ファイル、および各種データ等を記憶する外部記憶装置（ハードディスク）、フレキシブルディスク（ＦＤ）、或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等を利用可能である。
【００３２】
通信Ｉ／Ｆコントローラ２０８は、ネットワークを介して外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いた通信やＩＳＤＮなどの電話回線、および携帯電話の３Ｇ回線を用いた通信が可能である。
【００３３】
尚、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ディスプレイ２１０上での表示を可能としている。
【００３４】
ハードウェア上で動作する各種プログラムは、外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０３にロードされることによりＣＰＵ２０１によって実行されるものである。
【００３５】
なお、全ての装置がこれらの構成を備えているわけではなく、必要なものを夫々備えていればよい。
【００３６】
次に、図３〜図５のフローチャートを参照して、本発明の実施形態におけるＤｏｃｋｅｒサーバ１１１とバージョン管理サーバ１１２の処理について説明する。
【００３７】
図３は、本発明の実施形態における、開発担当者クライアント１０１及びインフラ担当者クライアント１０２により実行される事前処理の流れであり、図中のＳ３０１〜Ｓ３１２は各情報処理装置の各ステップを示す。各ステップの処理は、それぞれのシステムの外部メモリ２１１に格納されたアプリケーションプログラムを、それぞれのシステムのＣＰＵ２０１がＲＡＭ２０３上にロードして実行することにより実現される。
【００３８】
図３の３００のフローチャートは、開発担当者が開発担当者クライアント１０１からＤｏｃｋｅｒサーバで稼働するアプリケーションを開発する際に動作する処理の流れの例である。
【００３９】
ステップＳ３０１において、開発担当者クライアント１０１は、開発担当者クライアント１０１で作成、編集されたソースコードやコンパイル済のアプリケーションプログラムをバージョン管理サーバ１１２のリポジトリにコミットさせる。リポジトリとは、アプリケーションに寄与するライブラリを、Ｄｏｃｋｅｒ環境や運用環境に自動ダウンロード・インストール・アップデートするために、集められ登録されているデータベースであり、コミットとは、そのリポジトリに作成、編集したプログラムもしくはその差分情報を登録する行為である。
【００４０】
ステップＳ３０２において、バージョン管理サーバ１１２は、受信した編集済ソースコードやコンパイル済のアプリケーションプログラムをコミットする。すなわち、作成済あるいは編集済のアプリケーションプログラムをリポジトリに登録する。
【００４１】
なお、アプリケーションを開発する処理は、３００のフローチャートのように開発担当者クライアント１０１で編集されたプログラムをまとめてコミットさせても良いし、開発担当者クライアント１０１から編集する度にバージョン管理サーバ１１２に格納し、所定のタイミングでコミットさせても良い。ソースコーディングの手法については任意の方法で良く、バージョン管理サーバ１１２のリポジトリに登録される方法であれば、手法は問わない。
【００４２】
図３の３１０のフローチャートは、インフラ担当者がインフラ担当者クライアント１０２からＤｏｃｋｅｒサーバ１１１にインフラ環境を構築する処理の流れの例である。
【００４３】
ステップＳ３１１において、インフラ担当者クライアント１０２は、開発担当者がテストするコンテナ用のテスト環境を生成するために、インフラ担当者により入力されたＤｏｃｋｅｒｆｉｌｅをＤｏｃｋｅｒサーバ１１１に送信する。Ｄｏｃｋｅｒｆｉｌｅとは、Ｄｏｃｋｅｒサーバ１１１にインフラ環境を構築させるためのスクリプトである。インフラ担当者が入力するＤｏｃｋｅｒｆｉｌｅの例を図８を参照して説明する。
【００４４】
図８は、本発明の実施形態における、インフラ担当者クライアント１０２からＤｏｃｋｅｒサーバ１１１に送信されるＤｏｃｋｅｒｆｉｌｅの一例である。
【００４５】
図８には、２つのＤｏｃｋｅｒｆｉｌｅを併記しており、左側の８００が従来のＤｏｃｋｅｒｆｉｌｅ、右側の８１０が本発明におけるＤｏｃｋｅｒｆｉｌｅである。Ｄｏｃｋｅｒｆｉｌｅの登録内容は、図５のフローチャートの説明で後述する。
【００４６】
次のステップＳ３１２において、Ｄｏｃｋｅｒサーバ１１１は、インフラ担当者クライアント１０２から送信されたＤｏｃｋｅｒｆｉｌｅを受信し、外部メモリ２１１に保存する。
【００４７】
次に、図４を参照して、本実施例のＤｏｃｋｅｒサーバ１１１におけるテスト環境構築処理の流れを説明する。
【００４８】
図４は、本発明の実施形態における、Ｄｏｃｋｅｒサーバ１１１でテスト環境を構築するために実行される処理の流れであり、図中のＳ４０１〜Ｓ４０９は各情報処理装置の各ステップを示す。各ステップの処理は、それぞれのシステムの外部メモリ２１１に格納されたアプリケーションプログラムを、それぞれのシステムのＣＰＵ２０１がＲＡＭ２０３上にロードして実行することにより実現される。
【００４９】
図４のフローチャートは、開発担当者により、Ｄｏｃｋｅｒサーバ１１１で構築しているアプリケーションをテストする際に開始される。
【００５０】
まず、ステップＳ４０１において、開発担当者クライアント１０１は、開発担当者からテスト用ブランチ作成依頼を受け付ける。テスト用ブランチ作成依頼を受け付けると、開発担当者クライアント１０１は、ブランチの作成を受けたバージョンのアプリケーションプログラムを、バージョン管理サーバ１１２の「ｂｒａｎｃｈｅｓ」フォルダにコピーさせる命令を送信する。この処理はアプリケーションプログラムをｂｒａｎｃｈｅｓフォルダへコミットさせる処理でもある。
【００５１】
次に、ステップＳ４０２において、バージョン管理サーバ１１２は、開発担当者クライアント１０１から受け付けたバージョンのアプリケーションプログラムをｂｒａｎｃｈｅｓフォルダにコピーし、フォルダの名前（ｗａｒファイルの名前）に所定のタグを付ける。具体的なタグを付ける例は図６で後述する。
【００５２】
次に、ステップＳ４０３において、ｂｒａｎｃｈｅｓフォルダにコピーされたフォルダ（ｗａｒファイル）の内容を、Ｄｏｃｋｅｒフォルダにコピーし、テスト用ブランチ作成の終了を開発担当者クライアント１０１に通知する。
【００５３】
次に、ステップＳ４０４において、開発担当者クライアント１０１は、開発担当者の指示により、インフラ担当者クライアント１０２にテスト環境構築の依頼を送信する。
【００５４】
テスト環境構築依頼を受信したインフラ担当者クライアント１０２は、次のステップＳ４０５において、インフラ担当者の指示によりＤｏｃｋｅｒサーバ１１１にテスト環境構築するために、ステップＳ３１２でＤｏｃｋｅｒサーバ１１１が受信したＤｏｃｋｅｒｆｉｌｅの実行指示を送信する。
【００５５】
次に、ステップＳ４０６において、Ｄｏｃｋｅｒサーバ１１１は、ステップＳ３１２で受信したＤｏｃｋｅｒｆｉｌｅからＤｏｃｋｅｒイメージをビルドする処理を実行する。ステップＳ４０６の処理を図５、図８を参照して説明する。
【００５６】
図５は、本発明の実施形態における、Ｄｏｃｋｅｒサーバ１１１で実行されるＤｏｃｋｅｒイメージをビルドする処理の一例を説明するフローチャートであり、図中のＳ５０１〜Ｓ５０７は各情報処理装置の各ステップを示す。各ステップの処理は、それぞれのシステムの外部メモリ２１１に格納されたアプリケーションプログラムを、それぞれのシステムのＣＰＵ２０１がＲＡＭ２０３上にロードして実行することにより実現される。
【００５７】
図５のフローチャートは、図４のステップＳ４０６のようにＤｏｃｋｅｒｆｉｌｅからＤｏｃｋｅｒイメージをビルドする処理が実行されると、開始される処理の流れである。
【００５８】
まず、ステップＳ５０１において、Ｄｏｃｋｅｒサーバ１１１は、インターネット上にあるＤｏｃｋｅｒハブからＯＳのＤｏｃｋｅｒイメージを取得する。図８のＤｏｃｋｅｒｆｉｌｅの例を参照して説明する。なお、図８は、２つのＤｏｃｋｅｒｆｉｌｅを併記しており、左側の８００が従来のＤｏｃｋｅｒｆｉｌｅ、右側の８１０が本発明におけるＤｏｃｋｅｒｆｉｌｅである。下部の二重線より上側の処理内容は８００、８１０とも同じであるので、二重線より上側の処理内容は従来のＤｏｃｋｅｒｆｉｌｅ８００側で説明する。
【００５９】
ＤｏｃｋｅｒハブからＯＳのＤｏｃｋｅｒイメージを取得するステップＳ５０１の処理に対応するＤｏｃｋｅｒｆｉｌｅのスクリプトは図８の８０１である。８０１の場合、ダウンロードするＯＳは、ＣｅｎｔＯＳのバージョン番号７．３である。なお、Ｄｏｃｋｅｒハブからのダウンロードは、最初だけであり、２回目以降はＤｏｃｋｅｒサーバ２０１に存在するＯＳのＤｏｃｋｅｒイメージを使用する。
【００６０】
次のステップＳ５０２において、Ｄｏｃｋｅｒサーバ１１１は、ＯＳの情報設定を行う。図８のＤｏｃｋｅｒｆｉｌｅを例にＯＳの情報設定の例を説明する。
【００６１】
ステップＳ５０２の処理に対応するＤｏｃｋｅｒｆｉｌｅのスクリプトは図８の８０２以降であり、８０２では、ｒｏｏｔのパスワードを変更（図８では、ｒｏｏｔｐａｓｓｗｏｒｄ）し、ネットワークのプロキシ設定をそれぞれ変更、タイムゾーンを東京に設定している。
【００６２】
次のステップＳ５０３において、Ｄｏｃｋｅｒサーバ１１１は、自身が有するミドルウェアのインストールを行う。図８のＤｏｃｋｅｒｆｉｌｅを参照して説明する。
【００６３】
ステップＳ５０３の処理に対応するＤｏｃｋｅｒｆｉｌｅのスクリプトは図８の８０３以降であり、８０３以降でＤｏｃｋｅｒサーバ１１１は、サーブレットコンテナであるミドルウェアＴｏｍｃａｔをＤｏｃｋｅｒサーバ２０１に展開し、設定ファイルをコピーして、Ｔｏｍｃａｔを自動起動する。
【００６４】
次のステップＳ５０４において、Ｄｏｃｋｅｒサーバ１１１は、ステップＳ４０３でバージョン管理サーバ１１２によりコピーされたＤｏｃｋｅｒフォルダの所定のファイル（アプリケーションプログラム）をチェックアウト（Ｄｏｃｋｅｒサーバ１１１にワーキングコピーを作成）し、アプリケーションプログラムを展開する。図８のＤｏｃｋｅｒｆｉｌｅを参照して説明する。
【００６５】
ステップＳ５０４の処理に対応するＤｏｃｋｅｒｆｉｌｅのスクリプトは図８の８１１であり、８１１では、Ｄｏｃｋｅｒサーバ１１１は、バージョン管理サーバ１１２の所定のファイル（図８の場合、ｈｔｔｐ：／／〜／ｄｏｃｋｅｒ／ｍｏｄｕｌｅＡ．ｗａｒ）をＤｏｃｋｅｒサーバ１１１の所定のファイル（図８の場合、／ｏｐｔ／ｔｏｍｃａｔ／ｗｅｂａｐｐｓ／ｍｏｄｕｌｅＡ．ｗａｒ）としてワーキングコピーを作成し、アプリケーションプログラムを展開する。なお、バージョン管理サーバ１１２にログインする際のアカウントやパスワードは８１３で定義されている。
【００６６】
次のステップＳ５０５において、バージョン管理サーバ１１２は、ステップＳ４０３でＤｏｃｋｅｒフォルダにコピーされたアプリケーションプログラムをチェックアウト（Ｄｏｃｋｅｒサーバ１１１にワーキングコピーを作成）する。
【００６７】
次に、ステップＳ５０６において、Ｄｏｃｋｅｒサーバ１１１は、バージョン管理サーバ１１２のＤｏｃｋｅｒフォルダ内にあるアプリケーションプログラムが後日、誤ってチェックアウトされるのを防ぐため、ステップＳ５０４でチェックアウトを指示したファイルをリネームする命令を送信する。図８のＤｏｃｋｅｒｆｉｌｅを参照して説明する。
【００６８】
ステップＳ５０６の処理に対応するＤｏｃｋｅｒｆｉｌｅのスクリプトは図８の８１２であり、８１２では、Ｄｏｃｋｅｒサーバ１１１が、バージョン管理サーバ１１２の所定のファイルのファイル名（図８の場合、ｍｏｄｕｌｅＡ．ｗａｒ）をリネーム（図８の場合、ｍｏｄｕｌｅＡ．ｗａｒ＿０．１．０）する。ステップＳ５０５と同じように、バージョン管理サーバ１１２にログインする際のアカウントやパスワードは８１３で定義されているので、その値を利用する。
【００６９】
次に、ステップＳ５０７において、バージョン管理サーバ１１２は、ステップＳ５０５でチェックアウトされたファイルをリネームする。この処理により、後日Ｄｏｃｋｅｒフォルダの該当ファイルをチェックアウトしようとしても、ファイル名が異なるので、誤ってチェックアウトされてしまうリスクを減らすことができる。
【００７０】
以上、図５のフローチャートに則ったＤｏｃｋｅｒｆｉｌｅを実行する事により、ＯＳのイメージやミドルウェアだけでなく、開発担当者が作成したアプリケーションプログラムも自動でＤｏｃｋｅｒサーバ１１１に展開することができる。また、開発担当者はバージョン管理サーバ１１２を管理するだけでよく、インフラ担当者はＤｏｃｋｅｒサーバ１１１の管理のみで、テスト環境を構築することができ、サーバごとの操作の煩わしさから解放される。
【００７１】
ちなみに、従来のアプリケーションプログラムのＤｏｃｋｅｒサーバ１１１への展開方法を図８の８００を参照して説明する。まず、Ｄｏｃｋｅｒｆｉｌｅを実行する事前に、バージョン管理サーバ１１２からチェックアウトしたアプリケーションプログラムファイル（図８の８００の場合、ｍｏｄｕｌｅＡ．ｗａｒ）を、Ｄｏｃｋｅｒサーバ１１１上の所定のフォルダのファイル（図８の８００の場合、［Ｄｏｃｋｅｒｆｉｌｅが格納されているフォルダ］／ｏｐｔ／ｔｏｍｃａｔ／ｗｅｂａｐｐｓ／ｍｏｄｕｌｅＡ．ｗａｒ）に差し替える必要がある。その後、図８の８００のＤｏｃｋｅｒｆｉｌｅを実行し、８０１〜８０３までの処理は、上記と同じ処理を実行する。最後に８０４で、Ｄｏｃｋｅｒｆｉｌｅ実行前に差し替えたアプリケーションプログラム（図８の８００の場合、［Ｄｏｃｋｅｒｆｉｌｅが格納されているフォルダ］／ｏｐｔ／ｔｏｍｃａｔ／ｗｅｂａｐｐｓ／ｍｏｄｕｌｅＡ．ｗａｒ）を所定のフォルダ（図８の８００の場合、／ｏｐｔ／ｔｏｍｃａｔ／ｗｅｂａｐｐｓ／）にコピーしてアプリケーションプログラムの実行（テスト）環境実行の準備が完了する。
【００７２】
以上のように、従来の処理をインフラ担当者が実行しようとすると、インフラ担当者がバージョン管理サーバ１１２にログインし、作成・修正されたアプリケーションプログラムを事前にチェックアウトして、Ｄｏｃｋｅｒサーバ１１１にコピーする必要があった。開発担当者とインフラ担当者それぞれが分業している場合、インフラ担当者が管轄外のバージョン管理サーバ１１２にログインする処理は煩雑になり、設定ミスを起こす可能性が増える。この課題を本発明では解決できる。図４のフローチャートの説明に戻る。
【００７３】
図４のステップＳ４０６において、ＤｏｃｋｅｒｆｉｌｅからＤｏｃｋｅｒイメージをビルドする処理が終了すると、次のステップＳ４０７へと処理を遷移し、インフラ担当者クライアント１０２は、Ｄｏｃｋｅｒサーバ１１１にアプリケーションプログラムを実行するコンテナをＤｏｃｋｅｒイメージから起動するような指示（ｒｕｎ命令）を送信する。
【００７４】
コンテナを起動する指示を受け付けたＤｏｃｋｅｒサーバ１１１は、次のステップＳ４０８でコンテナを起動し、Ｄｏｃｋｅｒサーバ１１１のテスト環境を実行させる。
【００７５】
次に、ステップＳ４０９において、インフラ担当者クライアント１０２は、テスト環境構築完了通知を開発担当者クライアント１０１に送信し、以降で開発担当者は、テスト実行環境を使って様々なテストを行う。
【００７６】
以上の処理により、インフラ担当者は開発担当者が作成・修正したアプリケーションプログラムに関して、ファイルのコピーやＤｏｃｋｅｒｆｉｌｅの修正などを行わず、テスト実行環境を容易に構築することが可能となる。
【００７７】
図４と図５の処理を図６を参照して説明する。図６は、本発明の実施形態における、バージョン管理サーバ１１２のアプリケーションプログラムのフォルダ構成の変化を中心に説明した図である。
【００７８】
図６のバージョン管理サーバ１１２の列に記載されているフォルダ構成図は、クライアントやＤｏｃｋｅｒサーバからの指示により、アプリケーションプログラムが遷移する先もしくはコピー先を示す。
【００７９】
図６の６０１では、開発担当者が開発担当者クライアント１０１からアプリケーションプログラムを開発し、所定の動作をするレベルまで開発した段階で、アプリケーションプログラムをコミット（ステップＳ３０１）し、作成されたアプリケーションプログラムをｔｒｕｎｋフォルダに保存する（ステップＳ３０２）。
【００８０】
６０２では、インフラ担当者がインフラ担当者クライアント１０２からテスト実行するアプリケーションプログラムで使用するＯＳやミドルウェアのＤｏｃｋｅｒイメージを作成するためのＤｏｃｋｅｒｆｉｌｅを作成（ステップＳ３１１）し、Ｄｏｃｋｅｒサーバ１１１は、作成されたＤｏｃｋｅｒｆｉｌｅを保存する（ステップＳ３１２）。
【００８１】
６０３では、開発担当者が開発担当者クライアント１０１からテスト実行するアプリケーションプログラムのブランチを作成（ステップＳ４０１）し、バージョン管理サーバ１１２上の、ｂｒａｎｃｈｅｓフォルダにタグを付けてコピーされる（ステップＳ４０２）。図６の例では、ｍｏｄｕｌｅＡファイルに「＿ｖｅｒ２０１７１２０１」タグが追加されている。
【００８２】
また、ｂｒａｎｃｈｅｓフォルダにコピーされると、ブランチ作成されたアプリケーションプログラムは、ｄｏｃｋｅｒフォルダに自動的にコピーされる（ステップＳ４０３）。
【００８３】
ステップＳ４０４でインフラ担当者が開発担当者からテスト環境構築指示を受け付けると、６０４では、インフラ担当者がインフラ担当者クライアント１０２からＤｏｃｋｅｒビルドを実行する指示を行い（ステップＳ４０５）、Ｄｏｃｋｅｒサーバ１１１はステップＳ３１２で保存したＤｏｃｋｅｒｆｉｌｅからＤｏｃｋｅｒイメージをビルドする処理を開始する（ステップＳ４０６）。
【００８４】
Ｄｏｃｋｅｒイメージをビルドする処理のステップＳ４０６の処理の中で、まず、Ｄｏｃｋｅｒサーバ１１１は、ＯＳやミドルウェアのイメージをダウンロード、インストールを行い（ステップＳ５０１〜Ｓ５０３）、次にバージョン管理サーバ１１２のアプリケーションプログラムをチェックアウトする（ステップＳ５０４）。チェックアウトされるアプリケーションプログラムは、バージョン管理サーバ１１２からＤｏｃｋｅｒサーバ１１１にチェックアウトされる（ステップＳ５０５）。チェックアウトされるファイルはＤｏｃｋｅｒフォルダ以下のファイルであり、Ｄｏｃｋｅｒサーバ１１１の所定のフォルダに展開される。
【００８５】
次にＤｏｃｋｅｒサーバ１１１は、バージョン管理サーバ１１２のチェックアウトされたファイルのリネームの指示を行い（ステップＳ５０６）、バージョン管理サーバ１１２は、チェックアウトされたファイルをリネームする（ステップＳ５０７）。図６のれいでは、ｍｏｄｕｌｅＡファイルに「＿２０１７１２０１」が追加されている。
【００８６】
ビルド完了通知を受け取ったインフラ担当者は、６０５において、インフラ担当者クライアント１０２からＤｏｃｋｅｒサーバ１１１でビルドされたＤｏｃｋｅｒイメージのコンテナを起動させる指示（ｒｕｎ）を送信（ステップＳ４０７）し、Ｄｏｃｋｅｒサーバ１１１はＤｏｃｋｅｒイメージのコンテナを起動する（ステップＳ４０８）。Ｄｏｃｋｅｒサーバ１１１によりコンテナが起動されるとテスト環境構築完了通知を開発担当者クライアント１０１に送信（ステップＳ４０９）し、本発明の処理を終える。この後、開発担当者（もしくはテスト担当者）は、Ｄｏｃｋｅｒサーバ１１１のアプリケーションプログラムの様々なテストを行うことが出来る。
【００８７】
図７を参照して、図４と図５のフローチャートの結果、生成され、起動されるＤｏｃｋｅｒコンテナで形成されるシステムのイメージを説明する。
【００８８】
図７は、本発明の実施形態における、複数のアプリケーションプログラム毎に起動されるコンテナによって構成されるシステムの例を説明する模式図である。
【００８９】
図７のバージョン管理サーバ１１２には、複数のアプリケーションプログラムが記憶されており、たとえば７００には、ａｐｓｅｒｖｅｒＡプロジェクトであるアプリケーションプログラムが記憶されている。同様にｄｂｓｅｒｖｅｒＡプロジェクト、ｓｔｕｂａｐｓｅｒｖｅｒＡプロジェクト、ｓｔｕｂｄｂｓｅｒｖｅｒＡプロジェクト、ｄｒｉｖｅｒａｐｓｅｒｖｅｒＡプロジェクトも記憶されている。
【００９０】
これらの記憶されている各サーバ毎のアプリケーションプログラムがステップＳ５０４のチェックアウト処理によりＤｏｃｋｅｒサーバ１１１の所定のフォルダにコピーされる。コピーされたイメージがたとえば７１０であり、それぞれのアプリケーションプログラム毎にステップＳ３１１で作成されたＤｏｃｋｅｒｆｉｌｅとＤｏｃｋｅｒハブから取得した各種ミドルウェアインストーラを保持している（Ｄｏｃｋｅｒイメージ作成プロジェクト群）。
【００９１】
Ｄｏｃｋｅｒイメージ作成プロジェクト群からＤｏｃｋｅｒビルドを実行すると、たとえば７２０のようなＤｏｃｋｅｒイメージが生成され、それらがＤｏｃｋｅｒリポジトリに保存される。
【００９２】
Ｄｏｃｋｅｒリポジトリに保存されたそれぞれのＤｏｃｋｅｒイメージからｒｕｎ（コンテナ起動：ステップＳ４０８）を実行すると、たとえば７３０のように、ａｐｓｅｒｖｅｒＡサーバ（図７の場合、ＩＤ管理ＡＰサーバ）のコンテナが起動される。同様にｄｂｓｅｒｖｅｒＡプロジェクト、ｓｔｕｂａｐｓｅｒｖｅｒＡプロジェクト、ｓｔｕｂｄｂｓｅｒｖｅｒＡプロジェクト、ｄｒｉｖｅｒａｐｓｅｒｖｅｒＡプロジェクトそれぞれのサーバのコンテナも起動され、システムのテスト環境が構築できる。
【００９３】
以上の処理により、開発担当者が作成・修正したアプリケーションプログラムをインフラ担当者のみでテスト環境を構築することができる効果がある。
【００９４】
なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
【００９５】
本実施の形態に係るＤｏｃｋｅｒサーバ１１１やバージョン管理サーバ１１２は、例えば、１つ又は複数のコンピュータに、本実施の形態で説明する処理内容を記述したプログラムを実行させることにより実現可能である。すなわち、Ｄｏｃｋｅｒサーバ１１１が有する機能は、当該コンピュータに内蔵されるＣＰＵやメモリ、ハードディスクなどのハードウェア資源を用いて、Ｄｏｃｋｅｒサーバ１１１で実施される処理に対応するプログラムを実行することによって実現することが可能である。上記プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配付したりすることが可能である。また、上記プログラムをインターネットや電子メールなど、ネットワークを通して提供することも可能である。
【００９６】
また、本発明におけるプログラムは、図３〜５の処理をコンピュータに実行させるプログラムである。なお、本発明におけるプログラムは、図３〜５の各処理ごとのプログラムであってもよい。
【００９７】
以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読み出し、実行することによっても本発明の目的が達成されることは言うまでもない。
【００９８】
この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記録した記録媒体は本発明を構成することになる。
【００９９】
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ、シリコンディスク等を用いることが出来る。
【０１００】
また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１０１】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１０２】
また、本発明は、複数の機器から構成されるシステムに適用しても、ひとつの機器から成る装置に適用しても良い。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０１０３】
さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。
【符号の説明】
【０１０４】
１０１  開発担当者クライアント
１０２  インフラ担当者クライアント
１１１  Ｄｏｃｋｅｒサーバ
１１２  バージョン管理サーバ
２０１  ＣＰＵ
２０２  ＲＯＭ
２０３  ＲＡＭ
２０４  システムバス
２０５  入力コントローラ
２０６  ビデオコントローラ
２０７  メモリコントローラ
２０８  通信Ｉ／Ｆ（インタフェース）コントローラ
２０９  入力装置
２１０  ディスプレイ装置
２１１  外部メモリ
【図１】
2019133509.tif 000002
【図２】
2019133509.tif 000003
【図３】
2019133509.tif 000004
【図４】
2019133509.tif 000005
【図５】
2019133509.tif 000006
【図６】
2019133509.tif 000007
【図７】
2019133509.tif 000008
【図８】
2019133509.tif 000009