アプリケーションをコンテナで実行する
はじめに以下の条件を確認してください。
- コンテナへのデプロイに関する「システム要件」と「ネットワーク要件」を満たすこと。
- アプリケーションをコンテナで動作させるうえでの「推奨ネットワークアーキテクチャ」および「制限」を把握していること。
アプリケーションをコンテナで実行するには、以下に説明する一般的な手順に従う必要があります。
- コンテナ用のデプロイメントゾーンがまだない場合は、作成して構成します。
- コンテナにデプロイするアプリケーションを構成します。
- コンテナにアプリケーションをパブリッシュします。
これらの手順は、以下のセクションでさらに詳しく説明します。
コンテナのデプロイメントゾーンを作成して構成する
アプリケーションをコンテナにデプロイするには、コンテナベースのホスティングテクノロジー(Docker Containers
、Amazon ECS
、Azure Container Service
、Pivotal Cloud Foundry
)で構成された「デプロイメントゾーン」が必要になります。
デプロイメントゾーンに割り当てられたモジュールやアプリケーションがなければ、この目的のためにデプロイメントゾーンを新規作成してもよいですし、既存のデプロイメントゾーンのホスティングテクノロジーを変更してもかまいません。最低限必要なのは、コンテナ用にデプロイメントゾーンを1つ用意することであるため、以下の手順を1度だけ実行し、デプロイメントゾーンを作成してコンテナにデプロイするすべてのアプリケーションでそのデプロイメントゾーンを構成してください。
コンテナ用の新しいデプロイメントゾーンを構成するには、以下の手順を実行します。
-
基本パラメータ(名前と内部アドレス)を入力して「新しいデプロイメントゾーンを作成」します。
-
[Create]ボタンをクリックする前に、以下のコンテナベースのホスティングテクノロジーから1つを選択します。
Docker Containers
、Amazon ECS
、Azure Container Service
、Pivotal Cloud Foundry
。選択したホスティングテクノロジーに関連する個別のパラメータ値を設定するか、またはデフォルト値を使用します。
詳細については、様々な「デプロイメントゾーンパラメータ」をご覧ください。
コンテナ用のデプロイメントゾーンを作成した後は、そのデプロイメントゾーンを使用するためのアプリケーションの構成が必要になります。
コンテナとデータを共有する
構成フォルダ
個別の構成フォルダを使用することで、アプリケーションバンドルを新規作成することなく、OutSystemsアプリケーションの設定を変更できます。アプリケーションの構成設定はアプリケーションにバンドルされていませんが、アプリケーションをデプロイする場合、用意する必要があります。そうしないとアプリケーションが正常に動作しません。
コンテナベースのホスティングテクノロジーで構成されたデプロイメントゾーンにアプリケーションをデプロイする場合、デプロイメントゾーンの構成で設定されたOutput Config Files toフォルダにアプリケーション構成ファイルApp.config
がプラットフォームによって作成されます。アプリケーションが正しくデプロイされるように、このApp.config
ファイルを正しい構成フォルダにコピーする必要があります。
注記: フォルダの具体的な場所はホスティングテクノロジーによって異なります。詳細については、目的のホスティングテクノロジーの各ドキュメントをご覧ください。
OutSystemsアプリケーションの設定を変更するには、ご利用のホスティングテクノロジーが利用できる適切なフォルダに更新済み構成ファイルを配置します。すると、アプリケーションが新しい設定を自動的に取得します。
秘密フォルダ
一部のプラットフォーム機能では暗号化を使用しており、環境キーが必要になります。環境キーはコンテナコードと一緒には配布されないため、構成ファイル同様、アプリケーションを特定のコンテナベースのホスティングテクノロジーにデプロイする前に設定し、アプリケーションが正常に動作するようにする必要があります。このキーファイルの名前はprivate.key
で、OutSystemsプラットフォームのインストールフォルダにあります(通常、C:\Program Files\OutSystems\Platform Server
)。
コンテナにデプロイするアプリケーションを構成する
OutSystemsアプリケーションをコンテナにデプロイするように構成するには、以下のようにアプリケーションのデプロイメントゾーンをコンテナのデプロイメントゾーンに設定する必要があります。
-
Service Centerで[Factory] > [Applications] に進み、アプリケーション名をクリックします。
-
[Operations]タブで、Deployment Zoneパラメータをコンテナ用に構成されたデプロイメントゾーンに設定します。
-
[Apply]ボタンをクリックします。
この変更を反映するためにアプリケーションの再パブリッシュが必要になります。以下のセクションでこの操作を複数の操作に展開する場合の各操作の違いについて概要を説明します。
アプリケーションをコンテナにパブリッシュする
注記: このセクションでは、パブリッシュプロセスの概要のみを示しています。詳細については、各ホスティングテクノロジーのドキュメントをご覧ください。
「コンテナにパブリッシュする」操作は以下でさらに詳しく説明する6つの段階に分けられます。
- 1.アプリケーションをコンパイルしてバンドルを生成する(OutSystems)
- プラットフォームによってアプリケーションのコンパイル、バイナリの生成、アプリケーションバンドルの作成が行われます。バンドル(ZIPファイル)が構成されたパスに作成され、オペレータ(人間または自動デプロイツール)がさらにアクションを実行します。
- 2.コンテナイメージの作成/アプリケーションのプッシュ(オペレータ)
- オペレータはバンドルの内容を解凍し、使用しているホスティングテクノロジーに応じて、コンテナイメージを作成するか、またはアプリケーションをコンテナインフラにプッシュします。
- 3.デプロイの準備手順の結果ファイルを作成する(オペレータ)
- オペレータは、構成されたResultフォルダに要求されたファイル名で、デプロイの準備手順の結果ファイルを作成し、アプリケーションのコンテナへのデプロイが進行可能なことをプラットフォームに通知します。このファイルはデプロイが成功した場合は空になり、エラーが発生した場合はJSONコンテンツが含まれます。
- 4.コンテナを実行する(オペレータ)
- オペレータはコンテナを起動し、操作が成功した場合その識別子を取得します。
- 5.コンテナのネットワークルーティング規則を定義する(オペレータ)
- オペレータは、コンテナ内部のアプリケーションがデプロイメントゾーンの内部アドレスでアクセス可能か確認し、必要に応じてネットワークルーティング構成を定義するか、またはすでに定義された構成が今も有効か確認します(コンテナのIPアドレスが変更されると、ルーティング規則の変更も必要になる可能性があります)。
- 6.デプロイ手順の結果ファイルを作成する(オペレータ)
- オペレータは、構成されたResultフォルダに要求されたファイル名で、デプロイ手順の結果ファイルを作成し、アプリケーションのデプロイ操作の結果を出力します。デプロイの準備手順の結果ファイルと同様、このファイルはデプロイが成功した場合は空になり、エラーが発生した場合はJSONコンテンツが含まれます。
オペレータが結果ファイルを作成すると、プラットフォームがそれを検知し、デプロイ操作の結果に基づいてアプリケーションモジュールの状態の更新を続行します。
プラットフォームが結果ファイルを処理すると、オペレータが作成した最新の結果ファイルを除いて、同じアプリケーションと操作に関連する過去の結果ファイルがすべて削除されます。
たとえば、デプロイの準備手順でのコンテナへのデプロイシナリオを考えてみます。オペレータが、.preparedone
結果ファイルを正しいフォルダに配置し、プラットフォームがそれを検知すると、そのアプリケーションに関する過去の.preparedone
結果ファイルはすべて削除されます。
構成を更新する
コンテナにデプロイしたアプリケーションの構成を更新するには、名前が要求された名前と一致し、.configsdone
拡張子の付いた結果ファイルをオペレータが作成する必要があります。要求されたファイル名がビルドメッセージに表示されます。このファイルの内容は、以下に示す構成の更新操作の結果によって異なります。
- 成功
- デプロイメントゾーンの構成されたResultフォルダに要求された名前(
.configsdone
拡張子)の空のファイルを作成します。 - 失敗
-
正しいファイル名と
.configsdone
拡張子の付いたJSONファイルを作成します。内容は次に提示するテンプレートに従います。 — ユーザーが定義した以下のエラーメッセージが含まれます。{"Error":{"Message":"This user-defined error message will appear in the progress log messages in Service Center."}}
このファイルは、Resultフォルダに配置する必要があります。この情報はビルドログメッセージにも表示されます。
例:
\\twoflower\luggage\results\07897a77-3f58-4e5b-b926-a48605c0b6d0_dab321f9-72e8-44e8-ae5c-2c8212314cf6.configsdone
アプリケーションのコンテナでのアンデプロイ
注記: アンデプロイが必要になるのは、アプリケーションをコンテナのデプロイメントゾーンにデプロイした後で別のアドレスのデプロイメントゾーンにデプロイしたり、別のホスティングテクノロジーを使用するデプロイメントゾーンにデプロイする場合だけです。
コンテナのアプリケーションをアンデプロイまたは削除するには、名前が要求された名前と一致し、拡張子.undeploydone
の付いた結果ファイルをオペレータが作成する必要があります。要求されたファイル名がビルドメッセージに表示されます。このファイルの内容は、以下に示すアンデプロイ操作の結果によって異なります。
- 成功
- デプロイメントゾーンの構成されたResultフォルダに要求された名前(
.undeploydone
拡張子)の空のファイルを作成します。 - 失敗
-
正しいファイル名と
.undeploydone
拡張子の付いたJSONファイルを作成します。内容は次に提示するテンプレートに従います。 — ユーザーが定義した以下のエラーメッセージが含まれます。{"Error":{"Message":"This user-defined error message will appear in the progress log messages in Service Center."}}
このファイルは、Resultフォルダに配置する必要があります。この情報はビルドログメッセージにも表示されます。
例:
\\twoflower\luggage\results\07897a77-3f58-4e5b-b926-a48605c0b6d0_dab321f9-72e8-44e8-ae5c-2c8212314cf6.undeploydone
プラットフォームによって結果ファイルが処理されると、オペレータはコンテナをターミネートし、リバースプロキシとロードバランサのアプリケーション関連構成をすべて削除できます。
本セクションの以下の他のトピックで、ご利用のホスティングテクノロジーに即した詳細な説明をご確認ください。
自動デプロイツールを使用して「デプロイプロセスを自動化する方法」 もご覧ください。
2段階デプロイ
パブリッシュ操作には、結果ファイルの作成に伴う以下の2つの段階があります。
- 段階3(デプロイの準備手順の結果ファイルを作成する)。
- 段階6(デプロイ手順の結果ファイルを作成する)。
2段階にすることで、デプロイの準備と実際のデプロイを分離でき、必要なデータベース変更があれば実行できます。この分離が重要な理由は、データベースの変更によって現在動作中のアプリケーションが(同じ環境における従来のデプロイと)不整合状態になる可能性があるためです。
データベースへの変更を適用してからコンテナにバインドされたアプリケーションをエンドユーザーに直ちに提供できるようにするまでの時間を短縮することで、デプロイ先の環境ですでに提供されていたアプリケーションに対するデプロイプロセスの影響を最小限に抑えることができます。
このセクションの記事
- アプリケーションをDockerコンテナにデプロイする
- アプリケーションをDockerコンテナにデプロイする方法について詳しく説明しています。
- Pivotal Cloud Foundryにアプリケーションをデプロイする
- Pivotal Cloud Foundryにアプリケーションをデプロイする方法の詳細な手順について説明しています。