Skip to main content

 

OutSystems 11オンラインヘルプ

 

OutSystems

アプリケーションをコンテナで実行する

まずはじめに、以下の条件を確認してください。

アプリケーションをコンテナで実行するには、以下に概説されている一般的な手順を実行する必要があります。

  1. コンテナのデプロイゾーンがまだない場合は、作成して構成します。
  2. コンテナにデプロイするアプリケーションを構成します。
  3. コンテナにアプリケーションをパブリッシュします。

これらの手順は、以下のセクションでさらに詳しく説明します。

コンテナのデプロイゾーンを作成して構成する

アプリケーションをコンテナにデプロイするには、コンテナベースのホスティングテクノロジー(Docker ContainersAmazon ECSAzure Container ServicePivotal Cloud Foundry)で構成されたデプロイゾーンが必要です。

デプロイゾーンに関連付けられたモジュールやアプリケーションがない場合に限り、この目的のために新しいデプロイゾーンを作成したり、既存のデプロイゾーンのホスティングテクノロジーを変更したりできます。最低限必要な要件は、各コンテナがデプロイゾーンを1つ持つことであるため、以下の手順を一度だけ実行してデプロイゾーンを作成し、コンテナにデプロイするすべてのアプリケーションでそのデプロイゾーンを構成します。

コンテナの新しいデプロイゾーンを構成するには、以下の手順を実行します。

  1. 基本パラメータ(名前と内部アドレス)を入力して新しいデプロイゾーンを作成します。

  2. [Create]ボタンをクリックする前に、コンテナベースのホスティングテクノロジーを1つ選択します(Docker ContainersAmazon ECSAzure Container ServicePivotal Cloud Foundry)。

    選択したホスティングテクノロジーに関連する特定のパラメータの値を設定するか、またはデフォルト値を使用する必要があります。
    詳細については、様々なデプロイゾーンパラメータをご覧ください。

コンテナのデプロイゾーンを作成した後は、そのデプロイゾーンを使用するためにアプリケーションを構成する必要があります。

コンテナとデータを共有する

構成フォルダ

個別の構成フォルダを使用することで、新しいアプリケーションバンドルを作成することなく、OutSystemsアプリケーションの設定を変更できます。アプリケーション構成の設定はアプリケーションにバンドルされていませんが、アプリケーションをデプロイする際に使用できる必要があります。そうしないと、アプリケーションが正常に動作しません。

コンテナベースのホスティングテクノロジーで構成されたデプロイゾーンにアプリケーションをデプロイする場合、デプロイゾーンの構成で設定されたOutput Config Files toフォルダにApp.configアプリケーション構成ファイルがプラットフォームによって書き込まれます。アプリケーションが正しくデプロイされるように、このApp.configファイルを正しい構成フォルダにコピーする必要があります。

注記: フォルダの正確な場所はホスティングテクノロジーによって異なります。詳細については、目的のホスティングテクノロジーのドキュメントをご覧ください。

OutSystemsアプリケーションの設定を変更するには、ご利用のホスティングテクノロジーが利用できる適切なフォルダに更新された構成ファイルを配置します。すると、アプリケーションが新しい設定を自動的に取得するようになります。

秘密フォルダ

一部のプラットフォーム機能では暗号化を使用しており、環境キーが必要です。環境キーはコンテナコードと一緒には配布されません。構成ファイル同様に、アプリケーションを特定のコンテナベースのホスティングテクノロジーにデプロイする前に設定し、アプリケーションが正常に動作するようにする必要があります。このキーファイルの名前はprivate.keyで、OutSystemsプラットフォームのインストールフォルダ(通常はC:\Program Files\OutSystems\Platform Server)にあります。

コンテナにデプロイするようにアプリケーションを構成する

OutSystemsアプリケーションをコンテナにデプロイするように構成するには、以下のようにアプリケーションのデプロイゾーンをコンテナのデプロイゾーンに設定する必要があります。

  1. Service Centerで、[Factory] > [Applications]に移動して、アプリケーション名をクリックします。

  2. [Operations]タブで、「Deployment Zone」パラメータをコンテナに構成されたデプロイゾーンに設定します。

  3. [Apply]ボタンをクリックします。

この変更を反映するために、アプリケーションを再パブリッシュする必要があります。以下のセクションでは、デプロイ時のこのオペレーションの違いについて概説します。

アプリケーションをコンテナにパブリッシュする

「コンテナにパブリッシュする」オペレーションは、以下でさらに詳しく説明する6つの段階に分けられます。

1. アプリケーションをコンパイルしてバンドルを生成する(OutSystems)
プラットフォームによってアプリケーションのコンパイル、バイナリの生成、アプリケーションバンドルの作成が行われます。オペレータ(人間または自動化されたデプロイツール)がさらにアクションを実行するために、バンドル(ZIPファイル)が構成されたパスに作成されます。
2. コンテナイメージを作成する/アプリケーションをプッシュする(オペレータ)
オペレータはバンドルの内容を解凍し、使用しているホスティングテクノロジーに応じて、コンテナイメージを作成するか、またはアプリケーションをコンテナインフラにプッシュします。
3. デプロイの準備手順の結果ファイルを作成する(オペレータ)
オペレータは、構成済みのResultフォルダに想定されるファイル名と内容で「デプロイの準備」手順の結果ファイルを作成し、コンテナへのアプリケーションのデプロイが実行可能なことをプラットフォームに通知します。
4. コンテナを実行する(オペレータ)
オペレータはコンテナを起動し、オペレーションが成功した場合はその識別子を取得します。
5. コンテナのネットワークルーティング規則を定義する(オペレータ)
オペレータは、デプロイゾーンの内部アドレスを使用してコンテナ内部のアプリケーションにアクセスできることを確認し、必要に応じてネットワークルーティング構成を定義するか、またはすでに定義された構成が今も有効かどうかを確認します(コンテナのIPアドレスが変更されると、ルーティング規則の変更も必要になる可能性があります)。
6. デプロイ手順の結果ファイルを作成する(オペレータ)
オペレータは、構成済みのResultフォルダに想定されるファイル名と内容で「デプロイ」手順の結果ファイルを作成し、アプリケーションのデプロイオペレーションの結果を出力します。

オペレータが結果ファイルを作成すると、プラットフォームがそれを検出し、デプロイオペレーションの結果に基づいてアプリケーションモジュールの状態の更新を実行します。

プラットフォームが結果ファイルを処理すると、オペレータが作成した最新の結果ファイルを除き、同じアプリケーションとオペレーションに関連する過去のすべての結果ファイルは削除されます。

たとえば、デプロイの準備手順にあるコンテナにデプロイする場合を検討します。オペレータが、.preparedone結果ファイルを正しいフォルダに配置し、プラットフォームがそれを検出すると、そのアプリケーションに関連する過去のすべての.preparedone結果ファイルは削除されます。

構成を更新する

コンテナにデプロイしたアプリケーションの構成を更新するには、名前が想定される値と一致し、拡張子が.configsdoneである結果ファイルをオペレータが作成する必要があります。このファイルは、Resultフォルダに配置する必要があります(同じ情報がビルドログメッセージに表示されます)。

例: 
`\\twoflower\luggage\results\07897a77-3f58-4e5b-b926-a48605c0b6d0_dab321f9-72e8-44e8-ae5c-2c8212314cf6.configsdone`

このファイルの内容は、構成の更新オペレーションの結果によって異なります。

成功した場合
デプロイゾーンの構成済みのResultフォルダに想定される名前(.configsdone拡張子)の空のファイルを作成します。
失敗した場合

正しいファイル名で拡張子が.configsdoneであるJSONファイルを作成します。内容は次に示すテンプレートに従います(ユーザーが定義した以下のエラーメッセージが含まれています)。

{"Error":{"Message":"This user-defined error message will appear in the progress log messages in Service Center."}}

コンテナ内のアプリケーションをアンデプロイする

注記: アンデプロイオペレーションが必要になるのは、アプリケーションをコンテナのデプロイゾーンにデプロイした後で別のアドレスのデプロイゾーンにデプロイしたり、別のホスティングテクノロジーを使用するデプロイゾーンにデプロイしたりする場合のみです。

コンテナでアプリケーションをアンデプロイまたは削除するには、名前が想定される値と一致し、拡張子が.undeploydoneである結果ファイルをオペレータが作成する必要があります。このファイルは、Resultフォルダに配置する必要があります(同じ情報がビルドログメッセージに表示されます)。

例: 
`\\twoflower\luggage\results\07897a77-3f58-4e5b-b926-a48605c0b6d0_dab321f9-72e8-44e8-ae5c-2c8212314cf6.undeploydone`

このファイルの内容は、アンデプロイオペレーションの結果によって異なります。

成功した場合
デプロイゾーンの構成済みのResultフォルダに想定される名前(.undeploydone拡張子)の空のファイルを作成します。
失敗した場合

正しいファイル名で拡張子が.undeploydoneであるJSONファイルを作成します。内容は次に示すテンプレートに従います(ユーザーが定義した以下のエラーメッセージが含まれています)。

{"Error":{"Message":"This user-defined error message will appear in the progress log messages in Service Center."}}

プラットフォームによって結果ファイルが処理されると、オペレータはコンテナをターミネートし、リバースプロキシとロードバランサのアプリケーションに関連する構成をすべて削除できます。

ご利用のホスティングテクノロジーに応じた詳細な手順については、このセクションの別のトピックをご覧ください。

自動デプロイツールを使用してデプロイプロセスを自動化する方法もご覧ください。

2段階デプロイ

パブリッシュオペレーションには、結果ファイルの作成を伴う段階が2つあります。

  • 第3段階(デプロイの準備手順の結果ファイルを作成する)。
  • 第6段階(デプロイ手順の結果ファイルを作成する)。

2段階にすることで、デプロイの準備と、必要なデータベースの変更が発生する実際のデプロイを分離できます。この分離が重要な理由は、データベースの変更によって現在動作中のアプリケーションが(同じ環境の以前のデプロイと)不整合な状態になる可能性があるからです。

データベースへの変更を適用してから、コンテナにバインドされたアプリケーションをエンドユーザーが利用できる状態にするまでの時間を短縮することで、デプロイ先の環境ですでに提供されていたアプリケーションに対するデプロイプロセスの影響を最小限に抑えることができます。

このセクションの記事

  • Was this article helpful?