JP2019101866A - アプリケーションの更新方法およびプログラム - Google Patents

Abstract

【課題】ユーザーが仮想マシンによるサービスを利用できない時間を短縮すること。【解決手段】サーバーは、ユーザーのプロセスを実行する仮想的な環境を構成するコンテナを複数収容する。更新管理コンテナ１１０は、Ａｐｐコンテナ１５０にインストールされているアプリＡの更新を検知すると、状態Ｂとして示されるように、新しいコンテナ（Ａｐｐコンテナ１６０）を作成する。更新管理コンテナ１１０は、更新後のアプリＡをＡｐｐコンテナ１６０にインストールする。更新後のアプリＡが正常に動作することを確認すると、更新管理コンテナ１１０は、プロキシコンテナ１２０およびＤＮＳコンテナ１３０に、Ａｐｐコンテナ１５０のアドレスからＡｐｐコンテナ１６０のアドレスに、アプリＡのアドレスが変更されたことを通知する。その後、更新管理コンテナ１１０は、状態Ｃとして示されるように、Ａｐｐコンテナ１５０を削除する。【選択図】図４

Description

本開示は、アプリケーションの更新方法およびプログラムに関し、特に、プロセスを実行する仮想的な環境を構成するコンテナにインストールされたアプリケーションの更新方法およびプログラムに関する。

従来、仮想マシンを利用したサービスの提供について種々検討されている。たとえば、特開２０１２−２５２７０４号公報（特許文献１）は、２つの仮想マシンテンプレートを介して交互にシステムを更新することを開示する。

特開２０１２−２５２７０４号公報

特許文献１に記載のシステムの更新は、第一仮想マシンテンプレートを電源オフ状態に設定した後、第二仮想マシンテンプレートを電源オン状態に設定する手順を含む。したがって、ユーザーが比較的長い間仮想マシンによるサービスを利用できない、という事態が生じ得る。

本開示は、係る実情に鑑み考え出されたものであり、その目的は、ユーザーが仮想マシンによるサービスを利用できない時間を短縮することである。

本開示のある局面に従うと、ユーザーのプロセスを実行する仮想的な環境を構成するコンテナを２以上収容する情報処理装置において、コンテナにインストールされたアプリケーションを更新する方法が提供される。２以上のコンテナは、第１のアプリケーションをインストールされた第１のコンテナと、情報処理装置の各コンテナにインストールされたアプリケーションの更新を管理する更新管理コンテナと、２以上のコンテナのそれぞれのアドレスを管理するアドレス管理コンテナとを含む。方法は、更新管理コンテナが、情報処理装置において第２のコンテナを作成するステップと、更新管理コンテナが、第２のコンテナに更新後の第１のアプリケーションをインストールするステップと、更新管理コンテナが、第２のコンテナにおける、更新後の第１のアプリケーションの動作を確認するステップと、更新管理コンテナが、更新後の第１のアプリケーションの動作の確認後、アドレス管理コンテナに、第１のアプリケーションに対応するアドレスの変更を通知するステップとを備える。アドレスの変更は、第１のコンテナのアドレスから第２のコンテナのアドレスへの変更である。

情報処理装置において、２以上のコンテナのそれぞれはホストＯＳ（オペレーティングシステム）上で動作してもよい。情報処理装置は、ホストＯＳ上でコンテナの作成および削除を実行するシステムマネージャーをインストールされていてもよい。更新管理コンテナが第２のコンテナを作成するステップは、更新管理コンテナが、ホストＯＳに、コンテナの作成を依頼するステップと、ホストＯＳが、更新管理コンテナからの作成の依頼に応じて、システムマネージャーに、コンテナの作成を依頼するステップと、システムマネージャーが、ホストＯＳからの作成の依頼に応じて、第２のコンテナを作成するステップとを含んでいてもよい。

方法は、更新管理コンテナが、アドレス管理コンテナにアドレスの変更を通知した後、ホストＯＳに、第１のコンテナの削除を依頼するステップと、ホストＯＳが、更新管理コンテナからの削除の依頼に応じて、システムマネージャーに、第１のコンテナの削除を依頼するステップと、システムマネージャーが、ホストＯＳからの削除の依頼に応じて、第１のコンテナを削除するステップとをさらに備えていてもよい。

方法は、更新管理コンテナが、更新後の第１のアプリケーションのマニュアルを取得するステップをさらに備えていてもよい。更新管理コンテナは、マニュアルに従って、更新後の第１のアプリケーションの動作を確認してもよい。

方法は、更新管理コンテナが、更新後の第１のアプリケーションの動作の確認後、第１のコンテナに対して、第１のアプリケーションに対するユーザーからのリクエストを第２のコンテナに転送することを指示するステップをさらに備えていてもよい。

更新管理コンテナは、第１のコンテナによって構成されていてもよい。第１のアプリケーションは、情報処理装置の各コンテナにインストールされたアプリケーションの更新を管理するためのアプリケーションであってもよい。

本開示の他の局面に従うと、コンピューターのプロセッサーに、上記方法を実行させるように構成されたプログラムが提供される。

本開示によれば、更新管理コンテナは、第１のコンテナにインストールされた第１のアプリケーションが更新される場合、新たに第２のコンテナを作成し、当該第２のコンテナに更新後の第１のアプリケーションをインストールする。更新後の第１のアプリケーションの動作の確認後、更新管理コンテナは、アドレス管理コンテナに、第１のアプリケーションに対応するアドレスの変更を通知する。この変更により、第１のアプリケーションに対応するアドレスは、第１のコンテナのアドレスから第２のコンテナのアドレスへと変更される。

ユーザーは、更新後の第１のアプリケーションが第２のコンテナにインストールされている間、第１のコンテナにインストールされた更新前の第１のアプリケーションを利用できる。これにより、ユーザーが第１のアプリケーションのサービスを利用できない時間が短縮される。

情報処理装置を含むネットワークシステムの概略的な構成を示す図である。 情報処理機器１００のハードウェアブロック図である。 サーバー部２０の機能的な構成を階層的に示すブロック図である。 サーバー部２０における、アプリケーション更新時の処理の概要を説明するための図である。 サーバー部２０におけるアプリＡの更新時の処理の流れを模式的に示す図である。 アプリＡの更新時に、サーバー部２０において実行される処理シーケンスである。 更新管理コンテナ１１０によるアプリケーションについてのマニュアルの取得についてのシーケンスを表わす図である。 リクエストの転送が指示される状況を説明するための図である。 旧コンテナに対する切替モードの設定のシーケンスを示す図である。 サーバー部２０における、更新管理コンテナ１１０の更新を模式的に示す図である。 更新管理コンテナの更新のシーケンスを示す図である。

以下に、図面を参照しつつ、ユーザーのプロセスを実行する仮想的な環境を構成するコンテナを包含するサーバーの実施の形態について説明する。以下の説明では、同一の部品および構成要素には同一の符号を付してある。それらの名称および機能も同じである。したがって、これらの説明は繰り返さない。

［１．サーバーの構成］
本実施の形態では、サーバーは、情報処理装置の一部として構成される。図１は、情報処理装置を含むネットワークシステムの概略的な構成を示す図である。

図１に示されるように、ネットワークシステム１０００において、情報処理機器１００は、ネットワークＮを介して端末５００と通信する。ネットワークＮは、ＬＡＮ（ローカルエリアネットワーク）であってもよいし、グローバルネットワークであってもよい。端末５００は、たとえば、パーソナルコンピューター、スマートフォン、または、タブレット端末である。

一例として、情報処理機器１００は、サーバーとＭＦＰ（Multi-Functional Peripheral：画像形成装置）とがそれぞれの筐体を連結して一体に構成された機器として実現される。情報処理機器１００は、プリンター部１０と、サーバー部２０と、操作パネル３０とを備える。操作パネル３０は、プリンター部１０およびサーバー部２０のユーザーインターフェースとして利用される。

図２は、情報処理機器１００のハードウェアブロック図である。以下、プリンター部１０とサーバー部２０のそれぞれの構成を説明する。

（プリンター部１０）
プリンター部１０は、プリンター部１０全体を制御するためのＣＰＵ（Central Processing Unit）１９０と、記憶部１９１とを含む。記憶部１９１は、たとえば、不揮発性メモリーによって実現される。記憶部１９１に格納される情報は、ＣＰＵ１９０によって実行されるプログラム、および、当該プログラムの実行に利用されるデータを含んでいてもよい。

プリンター部１０は、さらに、画像処理部１５１と、画像形成部１５２と、画像読取部１５３と、内部インターフェース１８０とを含む。画像処理部１５１は、入力された画像データを処理することにより、たとえば出力される画像の拡大・縮小等の処理を実行する。画像処理部１５１は、たとえば画像処理用のプロセッサーおよびメモリーによって実現される。画像形成部１５２は、トナーカートリッジ、記録用紙を収容するための用紙トレイ、および、感光体等の、記録用紙に画像を形成するためのハードウェア資源、ならびに、記録用紙を搬送するためのハードウェア資源によって実現される。画像読取部１５３は、スキャナー等の、原稿の画像データを作成するように構成されたハードウェア資源によって実現される。画像処理部１５１、画像形成部１５２、および、画像読取部１５３のそれぞれの機能は、画像形成装置においてよく知られたものであるから、ここでは詳細な説明は繰返さない。

内部インターフェース１８０は、サーバー部２０との通信のインターフェースとして機能し、たとえばＬＡＮ（Local Area Network）カードによって実現される。

（サーバー部２０）
サーバー部２０は、サーバー部２０全体を制御するためのＣＰＵ２５０と、ネットワーク通信部２６０と、記憶部２７０と、内部インターフェース２８０とを含む。

ネットワーク通信部２６０は、グローバルネットワークを介して端末５００等の外部機器との間でデータの送受信を実行するように構成された、ハードウェア資源によって実現される。当該ハードウェア資源の一例は、ネットワークカードである。ＣＰＵ２５０は、ネットワーク通信部２６０を介して外部機器と通信する。

記憶部２７０は、たとえば、不揮発性メモリーによって実現される。記憶部２７０に格納される情報は、ＣＰＵ２５０によって実行されるプログラム、および、当該プログラムの実行に利用されるデータを含んでいてもよい。

ＣＰＵ２５０は、さらに、操作パネル３０を制御するように構成されている。操作パネル３０は、制御用回路３５０と、有機ＥＬ（Electro Luminescence）ディスプレイ等によって実現される表示部３６０と、タッチセンサー等によって実現される操作部３７０と、非接触カードリーダー等によって実現されるカードリーダー３８０とを含む。

制御用回路３５０は、ＣＰＵ２５０からの制御信号に従って、表示部３６０の表示動作を制御する。操作部３７０は、入力された情報を制御用回路３５０へ出力する。制御用回路３５０は、操作部３７０から入力された情報に応じた信号をＣＰＵ２５０へ出力する。制御用回路３５０は、ＣＰＵ２５０からの制御信号に応じて、カードリーダー３８０によって読み込まれたデータをサーバー部２０に転送する。

［２．サーバーの機能的な構成］
図３は、サーバー部２０の機能的な構成を階層的に示すブロック図である。サーバー部２０の機能的な構成は、たとえば、ＣＰＵ２５０が所与のプログラムを実行することによって実現される。

図３に示すように、サーバー部２０は、例えばLinux（登録商標）サーバーとして機能する。サーバー部２０は、物理マシン１０１上で稼働するホストＯＳ（オペレーティングシステム）１０２と、ホストＯＳ１０２上で動作するシステム管理ソフトウェア１０４とを有する。物理マシン１０１は、たとえば、ＣＰＵ２５０および記憶部２７０によって実現される。ホストＯＳ１０２上で動作するユーザープロセスのそれぞれは、各ユーザープロセスが対応するコンテナ内に閉じ込められている。システム管理ソフトウェア１０４は、コンテナ管理用の制御プログラムの一例である。代表的なコンテナ管理用の制御プログラムはＤＯＣＫＥＲ（登録商標）である。

ホストＯＳ１０２の内部は、物理リソースを管理する「カーネル空間」と、ユーザープロセスを実行する「ユーザー空間」とに分けられる。コンテナ型の仮想化では、ユーザー空間が複数に分けられ、それぞれのユーザープロセスから見えるリソースが制限される。このように、単一のユーザープロセス、あるいはいくつかのユーザープロセスをまとめて閉じ込めたユーザー空間が「コンテナ」である。

一例では、コンテナ型の仮想化において、すべてのプロセスはサーバー部２０にインストールされたホストＯＳ１０２上で直接動作する。コンテナ内のプロセスは実際の貨物輸送のコンテナのように隔離された空間に入っているので、あるコンテナの内部から他のコンテナの内部を見ることはできない。この隔離された空間を作り出すのはホストＯＳのカーネルの機能である。ホストＯＳを通して使用できるコンピュータのリソースをコンテナごとに隔離して、ホストＯＳ上で直接動作するプロセスや他のコンテナから独立した空間を作り出すことにより、リソースが分割、分配、制限される。コンテナの起動は、ＯＳから見ると単にプロセスが起動しているだけであるため、通常のプロセスが起動するのとほとんど差がなく、非常に速く起動することができる。他の例では、コンテナ型の仮想化において、各コンテナ内のプロセスが、それぞれのコンテナ内のＯＳ上で動作していてもよい。

サーバー部２０において、ＬＸＤ（Linux Container Daemon）１０３は、管理者に対して、アプリケーションを利用するシステムの設定全般を実施するための、管理画面を提供する。当該管理画面からはユーザーアカウントの追加削除など各種の設定が行える。ＬＸＤ１０３は、サーバー部２０において、コンテナを作成し、コンテナを削除する。ＬＸＤ１０３は、さらに、サーバー部２０のＣＰＵ使用率、メモリ使用率、起動コンテナ数を始めとしたリソース情報のほか、コンテナが正常に作成／削除されたかのログ情報を一元的に管理、閲覧する機能を提供する。これにより、システムの管理運用や障害発生時のトラブル解析を容易にする。ＬＸＤ１０３は、システムマネージャーの一例である。

図３では、システム管理ソフトウェア１０４上に５つのコンテナ（更新管理コンテナ１１０，プロキシコンテナ１２０，ＤＮＳコンテナ１３０，Ａｐｐコンテナ１４０，Ａｐｐコンテナ１５０）が示されている。更新管理コンテナ１１０，プロキシコンテナ１２０，ＤＮＳコンテナ１３０，Ａｐｐコンテナ１４０，Ａｐｐコンテナ１５０のそれぞれは、アプリケーションを利用したサービスを提供する。サーバー部２０は、個々のコンテナによるサービスを提供してもよいし、２以上のコンテナのサービスを連携させることによるサービスを提供してもよい。

更新管理コンテナ１１０は、サーバー部２０内の各コンテナにインストールされたアプリケーションの更新を管理する。更新管理コンテナ１１０によって提供されるサービスは、Registration Serviceとも呼ばれる。

プロキシコンテナ１２０は、サーバー部２０内の各コンテナへのリクエストを、各コンテナのアドレスに変換する。プロキシコンテナ１２０は、たとえば、ＣＰＵ２５０がNginx（登録商標）等のＷｅｂサーバーアプリケーションを実行することによって実現される。

ＤＮＳ（Domain Name Service）コンテナ１３０は、プロキシコンテナ１２０からの依頼に応じて、各コンテナへのリクエストを各コンテナのアドレスに変換する。

プロキシコンテナ１２０およびＤＮＳコンテナ１３０は、サーバー部２０内の各コンテナのアドレスを管理する。したがって、プロキシコンテナ１２０およびＤＮＳコンテナ１３０は、アドレス管理コンテナの一例である。

Ａｐｐコンテナ１４０およびＡｐｐコンテナ１５０のそれぞれは、ユーザーにサービスを提供するためのアプリケーションをインストールされている。図３では、Ａｐｐコンテナ１４０およびＡｐｐコンテナ１５０のそれぞれにインストールされたアプリケーションの種類を区別するために、「アプリケーション［１］」および「アプリケーション［２］」の標記が利用されている。サーバー部２０に含まれるＡｐｐコンテナの数は、図３に示された「２」に限定されない。

［３．アプリケーション更新時の処理の概要］
図４は、サーバー部２０における、アプリケーション更新時の処理の概要を説明するための図である。図４には、３つの状態Ａ〜Ｃが示されている。状態Ａでは、Ａｐｐコンテナとして、「Ａｐｐコンテナ１５０」が示されている。以下、図４を参照して、Ａｐｐコンテナ１５０にインストールされているアプリケーションの更新時の処理の流れを概略的に説明する。

更新管理コンテナ１１０は、Ａｐｐコンテナ１５０にインストールされているアプリケーション（仮に、「アプリＡ」とする）の更新を検知すると、状態Ｂとして示されるように、新しいコンテナ（Ａｐｐコンテナ１６０）を作成する。更新管理コンテナ１１０は、たとえば、外部の装置（「アプリＡ」を管理するサーバー）からの通知によって、当該アプリケーションの更新を検知する。

更新管理コンテナ１１０は、更新後のアプリＡをＡｐｐコンテナ１６０にインストールし、更新後のアプリＡの動作を確認する。更新後のアプリＡが正常に動作することを確認すると、更新管理コンテナ１１０は、プロキシコンテナ１２０およびＤＮＳコンテナ１３０に、Ａｐｐコンテナ１５０のアドレスからＡｐｐコンテナ１６０のアドレスに、アプリＡのアドレスが変更されたことを通知する。これにより、プロキシコンテナ１２０およびＤＮＳコンテナ１３０のそれぞれは、それぞれの内部に格納されたアプリケーションとコンテナのアドレスとの対応関係を変更する。アプリＡのサービスを提供するコンテナが、Ａｐｐコンテナ１５０からＡｐｐコンテナ１６０へと変更される。

その後、更新管理コンテナ１１０は、状態Ｃとして示されるように、Ａｐｐコンテナ１５０を削除する。

サーバー部２０では、更新管理コンテナ１１０がＡｐｐコンテナ１６０の作成およびアプリＡのサービスの接続先の切替（プロキシコンテナ１２０およびＤＮＳコンテナ１３０におけるアドレス設定の変更）を管理する。これにより、サーバー部２０が顧客のオンプレミス内で配置された場合であっても、上記コンテナの作成および接続先の切替が簡易にかつ低コストで実現される。

サーバー部２０では、アプリＡの更新が通知された後、更新後のアプリＡをインストールされたＡｐｐコンテナ１６０の正常な動作が確認されるまでは、更新前のアプリＡをインストールされたＡｐｐコンテナ１５０がサービスを提供する。これにより、ユーザーがアプリＡのサービスを利用できない時間が短縮され得る。

［４．アプリケーション更新時の処理の模式的な流れ］
図５は、サーバー部２０におけるアプリＡの更新時の処理の流れを模式的に示す図である。図５に示された４つの段階（［１］〜［４］）に従って、アプリＡの更新時の処理の流れを説明する。

段階［１］（新コンテナ作成）は、更新管理コンテナ１１０が、Ａｐｐコンテナ１６０を作成する段階を表わす。段階［１］では、アプリＡのサービスは、Ａｐｐコンテナ１５０からユーザー９００へ提供されている。本明細書では、「ユーザー９００」による処理は、ユーザー９００が操作する端末による処理を意味する。

段階［２］（コンテナ作成完了）は、更新管理コンテナ１１０が、Ａｐｐコンテナ１６０の作成を完了した段階を表わす。

段階［３］（接続先切替）は、更新管理コンテナ１１０が、Ａｐｐコンテナ１６０にインストールされたアプリＡの正常な動作を確認した後、プロキシコンテナ１２０およびＤＮＳコンテナ１３０に、アプリＡのアドレスを、Ａｐｐコンテナ１５０のアドレスからＡｐｐコンテナ１６０のアドレスに変更することを通知する段階を表わす。

段階［４］（旧コンテナ削除）は、更新管理コンテナ１１０が、Ａｐｐコンテナ１５０をサーバー部２０から削除する段階を表わす。プロキシコンテナ１２０およびＤＮＳコンテナ１３０が段階［３］においてアプリＡに対応するアドレスをＡｐｐコンテナ１５０のアドレスからＡｐｐコンテナ１６０のアドレスへと変更しているので、段階［４］では、アプリＡのサービスは、Ａｐｐコンテナ１６０からユーザー９００へ提供される。

［５．アプリケーション更新時の処理シーケンス］
図６は、アプリＡの更新時に、サーバー部２０において実行される処理シーケンスである。図６中の「Ｓ１」等の符号に従って、処理シーケンスを説明する。

更新管理コンテナ１１０は、アプリＡの更新の通知を受信すると、ステップＳ１にて、ホストＯＳ１０２に、新しいコンテナの作成を依頼する。ホストＯＳ１０２は、ステップＳ１．１にて更新管理コンテナ１１０からの依頼を受信すると、ステップＳ１．１．１にて、ＬＸＤ１０３に、新しいコンテナの作成を依頼する。

ステップＳ１．１．１．１にて、ＬＸＤ１０３は、図４等に示されたように、ホストＯＳ１０２上に新しいコンテナ（Ａｐｐコンテナ１６０）を作成する。ＬＸＤ１０３は、Ａｐｐコンテナ１６０の作成を完了すると、当該完了をホストＯＳ１０２に通知する。ホストＯＳ１０２は、ＬＸＤ１０３から当該通知を受けると、更新管理コンテナ１１０にＡｐｐコンテナ１６０の作成の完了を通知する。

ステップＳ２にて、更新管理コンテナ１１０は、Ａｐｐコンテナ１６０に、更新後の（新バージョンの）アプリＡのインストールを開始する。ステップＳ３にて、更新管理コンテナ１１０は、当該インストールの進捗を監視する。ステップＳ４は、更新管理コンテナ１１０が、更新後のアプリＡのインストールの完了を確認したタイミングを表わす。

ステップＳ５にて、更新管理コンテナ１１０は、更新後のアプリＡが正常に動作するかを確認する。たとえば、更新管理コンテナ１１０は、予め定められたリクエストをＡｐｐコンテナ１６０に送信し、Ａｐｐコンテナ１６０から予め定められた応答を得られたことを条件として、更新後のアプリＡが正常に動作すると判断する。

更新後のアプリＡが正常に動作すると判断すると、ステップＳ６にて、更新管理コンテナ１１０は、プロキシコンテナ１２０（およびＤＮＳコンテナ１３０）に、アプリＡに対応するアドレス（接続先）の設定の切替を依頼する。プロキシコンテナ１２０（およびＤＮＳコンテナ１３０）は、当該依頼に応じて設定を切り替える。プロキシコンテナ１２０（およびＤＮＳコンテナ１３０）において設定が切り替えられることにより、アプリＡのサービスの提供元が、Ａｐｐコンテナ１５０からＡｐｐコンテナ１６０へと切り替えられる。

ステップＳ７にて、更新管理コンテナ１１０は、ホストＯＳ１０２に、Ａｐｐコンテナ１５０の削除を依頼する。更新管理コンテナ１１０からの依頼に応じて、ステップＳ７．１にて、ホストＯＳ１０２は、ＬＸＤ１０３に、Ａｐｐコンテナ１５０の削除を依頼する。当該依頼は、たとえばバッチファイル（batファイル）の実行によって実現される。ホストＯＳ１０２からの依頼に応じて、ステップＳ７．１．１．１にて、ＬＸＤ１０３は、Ａｐｐコンテナ１５０を削除する。

図６では、期間ＤＡが、Ａｐｐコンテナ１５０がアプリＡ（更新前）のサービスを提供する期間を表わす。期間ＤＢが、Ａｐｐコンテナ１６０がアプリＡ（更新後）のサービスを提供する期間を表わす。期間ＤＸは、更新管理コンテナ１１０が、プロキシコンテナ１２０（およびＤＮＳコンテナ１３０）に設定の切替を依頼してから、プロキシコンテナ１２０（およびＤＮＳコンテナ１３０）において設定の切替が完了するまでの期間を表わす。

図６に示されるように、サーバー部２０では、アプリＡの更新時に、アプリＡのサービスが提供されない期間は期間ＤＸによって示される。一方、アプリＡの更新時に、Ａｐｐコンテナ１５０においてアプリケーションの更新が行なわれた場合、アプリＡのサービスが提供されない期間は、期間ＤＸだけでなく期間ＤＡも含む。サーバー部２０では、Ａｐｐコンテナ１６０が作成され、当該Ａｐｐコンテナ１６０に更新後のアプリケーションがインストールされることにより、アプリＡのサービスが提供されない期間が短縮される。

［６．インストール監視用のマニュアルの取得］
図６のステップＳ３において説明されたように、更新管理コンテナ１１０は、アプリケーションのインストールの進捗を監視する。更新管理コンテナ１１０は、アプリケーションの更新時にマニュアルを取得し、当該マニュアルに従って上記インストールの進捗を監視してもよい。図７は、更新管理コンテナ１１０によるアプリケーションについてのマニュアルの取得についてのシーケンスを表わす。図７は、図６に示されたシーケンスのうち、ステップＳ３に関連した部分のみを示す。図７内の「Ｓ０」等の符号に従って、シーケンスを説明する。

図７の例では、ステップＳ０にて、ユーザー９００が、更新管理システム１０４Ａに、サーバー部２０内のアプリＡの更新を依頼する。より具体的には、ユーザー９００は、端末を利用して、更新管理システム１０４Ａに上記依頼を送信する。更新管理システム１０４Ａは、サーバー部２０内に配置されていてもよいし、サーバー部２０外であってもよい。

ステップＳ０における依頼に応じて、ステップＳ０．１にて、更新管理システム１０４Ａは、更新管理コンテナ１１０に、ログ監視マニュアルを送信する。ログ監視マニュアルは、アプリＡのインストールの進捗の監視に利用される。ログ監視マニュアルは、たとえば、インストールに関するログファイルとインストール状況とを関連付ける。

ステップＳ３にて、更新管理コンテナ１１０は、Ａｐｐコンテナ１６０に対する、更新後のアプリケーションのインストールの進捗を監視する。一例では、更新管理コンテナ１１０は、Ａｐｐコンテナ１６０に、インストールに関するログを要求する。Ａｐｐコンテナ１６０は、更新管理コンテナ１１０にログファイルを送信する。更新管理コンテナ１１０は、上記ログ監視マニュアルを参照することにより、Ａｐｐコンテナ１６０から受信したログファイルに基づいてインストールの進捗状況を特定する。

特定された進捗状況が再インストールを要する状況であれば、ステップＳ３．１にて、更新管理コンテナ１１０は、Ａｐｐコンテナ１６０に対して、更新後のアプリケーションを再インストールする。

特定された進捗状況がＡｐｐコンテナ１６０の再構築を要するものであれば、ステップＳ３．２にて、更新管理コンテナ１１０は、ホストＯＳ１０２に対して、新しいコンテナの作成を依頼する。ステップＳ３．２の依頼に応じて、ホストＯＳ１０２は、ステップＳ１．１．１（図６）と同様に、ＬＸＤ１０３に新しいコンテナの作成を依頼する。その後、ＬＸＤ１０３は、ステップＳ１．１．１．１（図６）と同様に、ホストＯＳ１０２上に新しいコンテナを作成する。

特定された進捗状況が、Ａｐｐコンテナ１６０において更新後のアプリケーションのインストールが正常に完了した状況であれば、図６のステップＳ４以降に制御が進められる。

図７に示されるように、更新管理コンテナ１１０が、マニュアルを取得し、当該マニュアルに従ってインストールの進捗を管理することにより、アプリケーションのインストールにおけるエラーが確実に検知される。特に、サーバー部２０では、複数のコンテナのそれぞれに、ホストＯＳ１０２とは別のＯＳが存在する。したがって、複数のコンテナのそれぞれが、互いに別の空間を構成する。したがって、各コンテナへのアプリケーションのインストールにおいて、ホストＯＳ１０２がエラーを検知することが困難な場合がある。図７の例では、更新管理コンテナ１１０が、上記マニュアルを取得して、インストールの進捗を管理するため、確実にエラーが検知される。

［７．旧コンテナから新コンテナへのリクエストの転送］
サーバー部２０において、新しいコンテナへのアプリケーションのインストールが完了すると、更新管理コンテナ１１０は、更新前のコンテナにリクエストの転送を指示してもよい。これにより、更新前のコンテナへのリクエストが処理されないままコンテナが切替られて、ユーザーと更新前のコンテナとの間のセッションが途切れる、という事態が回避され得る。

図８は、リクエストの転送が指示される状況を説明するための図である。図８に示された「Ａ１」等の符号に従って、リクエストの転送に関連した処理を説明する。

「Ａ１：切替モードに設定」では、「Ａ１：切替モードに設定」として示されるように、更新管理コンテナ１１０は、旧コンテナ（Ａｐｐコンテナ１５０）を切替モードに設定する。

その後、Ａｐｐコンテナ１５０は、「Ａ２：新リクエスト」として示されるように、ユーザー９００からのリクエストを受けると、「Ａ３：転送」として示されるように、新コンテナ（Ａｐｐコンテナ１６０）に当該リクエストを転送する。

Ａｐｐコンテナ１６０は、「Ａ４：レスポンス」として示されるように、転送されたリクエストに対するレスポンスをＡｐｐコンテナ１５０に送信する。Ａｐｐコンテナ１５０は、「Ａ５：レスポンス」として示されるように、Ａｐｐコンテナ１６０からのレスポンスをユーザー９００へ送信する。

Ａｐｐコンテナ１５０は、切替モードに設定された後、予め定められた期間ユーザーからリクエストを受けなければ、その旨を更新管理コンテナ１１０へ通知する。更新管理コンテナ１１０は、Ａｐｐコンテナ１５０からの通知を受けると、図６のステップＳ６として説明されたように、プロキシコンテナ１２０（およびＤＮＳコンテナ１３０）に、アプリケーションに対応するアドレス（接続先）の設定の切替を依頼する。

図９は、旧コンテナに対する切替モードの設定のシーケンスを示す図である。図９は、図６に示されたシーケンスのうち、ステップＳ６に関連した部分のみを示す。図９に示された「Ｓ５．１」等の符号に従って、シーケンスを説明する。

図９の例では、更新管理コンテナ１１０は、ステップＳ５（図６）において更新後のアプリＡが正常に動作することを確認した後、ステップＳ５．１を実行する。ステップＳ５．１にて、更新管理コンテナ１１０は、Ａｐｐコンテナ１５０に、切替モードに移行することを指示する。

その後、ステップＳ５．２にてユーザー９００からリクエストを受けると、ステップＳ５．３にて、Ａｐｐコンテナ１５０は、当該リクエストをＡｐｐコンテナ１６０へ転送する。図９のステップＳ５．２は、図８の「Ａ２」に対応する。図９のステップＳ５．３は、図８の「Ａ３」に対応する。Ａｐｐコンテナ１６０は、当該リクエストに対するレスポンスをＡｐｐコンテナ１５０に送信する。Ａｐｐコンテナ１５０は、Ａｐｐコンテナ１６０からのレスポンスをユーザー９００に送信する。

切替モードに設定された後、予め定められた期間ユーザー９００からのリクエストを受けなければ、ステップＳ５．４にて、Ａｐｐコンテナ１５０は、更新管理コンテナ１１０にその旨を通知する。図９では、当該通知が「終了通知」として示されている。

更新管理コンテナ１１０は、Ａｐｐコンテナ１５０から「終了通知」を受けると、ステップＳ６にて、プロキシコンテナ１２０（およびＤＮＳコンテナ１３０）に、アプリケーション（アプリＡ）に対応するアドレスの設定の切替を依頼する。ステップＳ７にて、プロキシコンテナ１２０（およびＤＮＳコンテナ１３０）は、アプリＡに対応するアドレスの設定を切り替える。

［８．更新管理コンテナの更新］
図１０は、サーバー部２０における、更新管理コンテナ１１０の更新を模式的に示す図である。図１０中の「Ｂ１」等の符号に従って、更新管理コンテナ１１０の更新の流れを説明する。

更新管理コンテナ１１０は、「Ｂ１：新管理コンテナ作成」として記載されるように、当該更新管理コンテナ１１０にインストールされたアプリケーションの更新時期が到来したことを検知すると、他のコンテナにインストールされたアプリケーションの更新と同様に、新しいコンテナを作成する。図１０において、新しく作成されたコンテナは、更新管理コンテナ１１０Ａとして示されている。

「Ｂ２：新管理コンテナ作成完了」として記載されるように、新しいコンテナの作成が完了すると、更新管理コンテナ１１０は、当該新しいコンテナに、更新後のアプリケーションをインストールする。インストールされるアプリケーションは、各コンテナのアプリケーションの更新を管理するためのアプリケーションである。

その後、「Ｂ３：接続先切替」として記載されるように、更新管理コンテナ１１０は、プロキシコンテナ１２０（およびＤＮＳコンテナ１３０）に、更新管理コンテナに対応するアドレスの設定の切替を依頼する。

その後、「Ｂ４：削除依頼」として記載されるように、更新管理コンテナ１１０は、ホストＯＳ１０２に対して、更新管理コンテナ１１０の削除を依頼する。これに応じて、「Ｂ５：削除実行」として示されるように更新管理コンテナ１１０が削除される。その後、サーバー部２０では、更新管理コンテナ１１０Ａによって、各コンテナにインストールされたアプリケーションの更新が管理される。

図１１は、更新管理コンテナの更新のシーケンスを示す図である。図１１中の「Ｓ１」等の符号に従って、シーケンスを説明する。

更新管理コンテナ１１０は、当該更新管理コンテナ１１０にインストールされたアプリケーションの更新の通知を受信すると、ステップＳ１にて、ホストＯＳ１０２に、新しいコンテナの作成を依頼する。ホストＯＳ１０２は、ステップＳ１．１にて更新管理コンテナ１１０からの依頼を受信すると、ステップＳ１．１．１にて、ＬＸＤ１０３に、新しいコンテナの作成を依頼する。

ステップＳ１．１．１．１にて、ＬＸＤ１０３は、ホストＯＳ１０２上に新しいコンテナ（更新管理コンテナ１１０Ａ）を作成する。ＬＸＤ１０３は、更新管理コンテナ１１０Ａの作成を完了すると、当該完了をホストＯＳ１０２に通知する。ホストＯＳ１０２は、ＬＸＤ１０３から当該通知を受けると、更新管理コンテナ１１０に更新管理コンテナ１１０Ａの作成の完了を通知する。

ステップＳ２にて、更新管理コンテナ１１０は、更新管理コンテナ１１０Ａに、更新後の（新バージョンの）アプリケーションのインストールを開始する。ステップＳ３にて、更新管理コンテナ１１０は、当該インストールの進捗を監視する。ステップＳ４は、更新管理コンテナ１１０が、更新後のアプリケーションのインストールの完了を確認したタイミングを表わす。

ステップＳ５にて、更新管理コンテナ１１０は、更新後のアプリケーションが正常に動作するかを確認する。たとえば、更新管理コンテナ１１０は、予め定められたリクエストを更新管理コンテナ１１０Ａに送信し、更新管理コンテナ１１０Ａから予め定められた応答を得られたことを条件として、更新後のアプリケーションが正常に動作すると判断する。

更新後のアプリケーションが正常に動作すると判断すると、ステップＳ６にて、更新管理コンテナ１１０は、プロキシコンテナ１２０（およびＤＮＳコンテナ１３０）に、更新管理コンテナに対応するアドレス（接続先）の設定の切替を依頼する。プロキシコンテナ１２０（およびＤＮＳコンテナ１３０）は、当該依頼に応じて設定を切り替える。プロキシコンテナ１２０（およびＤＮＳコンテナ１３０）において設定が切り替えられることにより、更新管理コンテナのサービスの提供元が、更新管理コンテナ１１０から更新管理コンテナ１１０Ａへと切り替えられる。

ステップＳ７にて、更新管理コンテナ１１０は、ホストＯＳ１０２に、当該更新管理コンテナ１１０の削除を依頼する。更新管理コンテナ１１０からの依頼に応じて、ステップＳ７．１にて、ホストＯＳ１０２は、ＬＸＤ１０３に、Ａｐｐコンテナ１５０の削除を依頼する。当該依頼は、たとえばバッチファイル（batファイル）の実行によって実現される。ホストＯＳ１０２からの依頼に応じて、ステップＳ７．１．１．１にて、ＬＸＤ１０３は、更新管理コンテナ１１０を削除する。

今回開示された各実施の形態は全ての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内での全ての変更が含まれることが意図される。また、実施の形態および各変形例において説明された発明は、可能な限り、単独でも、組合わせても、実施することが意図される。

１０ プリンター部、２０ サーバー部、３０ 操作パネル、１００ 情報処理機器、１０１ 物理マシン、１０４ システム管理ソフトウェア、１０４Ａ 更新管理システム、１１０，１１０Ａ 更新管理コンテナ、１２０ プロキシコンテナ、１３０ ＤＮＳコンテナ、１４０，１５０，１６０ Ａｐｐコンテナ。

Claims (7)

1. ユーザーのプロセスを実行する仮想的な環境を構成するコンテナを２以上収容する情報処理装置において、コンテナにインストールされたアプリケーションを更新する方法であって、
   前記２以上のコンテナは、第１のアプリケーションをインストールされた第１のコンテナと、前記情報処理装置の各コンテナにインストールされたアプリケーションの更新を管理する更新管理コンテナと、前記２以上のコンテナのそれぞれのアドレスを管理するアドレス管理コンテナとを含み、
   前記方法は、
   前記更新管理コンテナが、前記情報処理装置において第２のコンテナを作成するステップと、
   前記更新管理コンテナが、前記第２のコンテナに更新後の前記第１のアプリケーションをインストールするステップと、
   前記更新管理コンテナが、前記第２のコンテナにおける、前記更新後の第１のアプリケーションの動作を確認するステップと、
   前記更新管理コンテナが、前記更新後の第１のアプリケーションの動作の確認後、前記アドレス管理コンテナに、前記第１のアプリケーションに対応するアドレスの変更を通知するステップとを備え、
   前記アドレスの変更は、前記第１のコンテナのアドレスから前記第２のコンテナのアドレスへの変更である、方法。
2. 前記情報処理装置において、前記２以上のコンテナのそれぞれはホストＯＳ（オペレーティングシステム）上で動作し、
   前記情報処理装置は、前記ホストＯＳ上でコンテナの作成および削除を実行するシステムマネージャーをインストールされており、
   前記更新管理コンテナが前記第２のコンテナを作成するステップは、
   前記更新管理コンテナが、前記ホストＯＳに、コンテナの作成を依頼するステップと、
   前記ホストＯＳが、前記更新管理コンテナからの作成の依頼に応じて、前記システムマネージャーに、コンテナの作成を依頼するステップと、
   前記システムマネージャーが、前記ホストＯＳからの作成の依頼に応じて、前記第２のコンテナを作成するステップとを含む、請求項１に記載の方法。
3. 前記方法は、
   前記更新管理コンテナが、前記アドレス管理コンテナにアドレスの変更を通知した後、前記ホストＯＳに、前記第１のコンテナの削除を依頼するステップと、
   前記ホストＯＳが、前記更新管理コンテナからの削除の依頼に応じて、前記システムマネージャーに、前記第１のコンテナの削除を依頼するステップと、
   前記システムマネージャーが、前記ホストＯＳからの削除の依頼に応じて、前記第１のコンテナを削除するステップとをさらに備える、請求項２に記載の方法。
4. 前記更新管理コンテナが、前記更新後の第１のアプリケーションのマニュアルを取得するステップをさらに備え、
   前記更新管理コンテナは、前記マニュアルに従って、前記更新後の第１のアプリケーションの動作を確認する、請求項１〜請求項３のいずれか１項に記載の方法。
5. 前記更新管理コンテナが、前記更新後の第１のアプリケーションの動作の確認後、前記第１のコンテナに対して、前記第１のアプリケーションに対するユーザーからのリクエストを前記第２のコンテナに転送することを指示するステップをさらに備える、請求項１〜請求項４のいずれか１項に記載の方法。
6. 前記更新管理コンテナは、前記第１のコンテナによって構成され、
   前記第１のアプリケーションは、前記情報処理装置の各コンテナにインストールされたアプリケーションの更新を管理するためのアプリケーションである、請求項１〜請求項５のいずれか１項に記載の方法。
7. コンピューターのプロセッサーに、請求項１〜請求項６のいずれか１項に記載の方法を実行させるように構成されたプログラム。

Images