デプロイメントゾーンのリファレンス
OutSystemsのオンプレミスインストールでのみ利用可能です。
デプロイメントゾーンごとに設定できるパラメータは以下のとおりです。
- Name
-
デプロイメントゾーンの識別名。この名前はUIの複数の場所で使用され、表示内容が意味を持ちます。
例:
ビジネスバックエンド
、サービス
、コア開発インフラ
、イントラネット
- 説明
- デプロイメントゾーンの目的。このフィールドを使用してあらゆる関連情報を保存し、ゾーンの使用方法やゾーンに追加すべきアプリケーションの種類に関する理解を深めることができます。
- Is Default for new eSpaces
- Boolean型パラメータが有効な場合、現在のデプロイメントゾーンが「デフォルトのデプロイメントゾーン」であることを示します。デプロイメントゾーンをデフォルトに設定するには、[Set as Default]をクリックします。
- デプロイメントゾーンアドレス
-
デプロイメントゾーンで動作するすべてのアプリケーションのアドレス。他のデプロイメントゾーンのアプリケーションがある特定のデプロイメントゾーンで動作するアプリケーションを参照する必要があり、環境URLを使用したくない場合、このアドレスを使用します。
このアドレスはネットワークアーキテクチャによって異なる場合があります。たとえば、フロントエンドサーバーが1台のみの場合は、「Deployment Zone Address」にPCのホスト名を指定できます。しかし、フロントエンドが複数ある場合は、「Deployment Zone Address」にこれらのフロントエンドサーバー間の通信を処理するロードバランサなどのデバイスの完全修飾ドメイン名(FQDN)を指定する必要があります。
また、デプロイメントゾーンの「Hosting Technology」によってパラメータ値が異なる場合もあります。コンテナベースのホスティングテクノロジーでは、「Deployment Zone Address」にオーケストレータの完全修飾ドメイン名(FQDN)を指定できます。この場合、リクエストを適切なコンテナへ転送することができるコンテナエンジンの着信機能またはサードパーティツールと連携します。
「推奨ネットワークアーキテクチャ」で、ご利用のネットワークアーキテクチャに内部アドレスを適合させる必要性について確認します。
プラットフォームインストールは、80番ポートおよび443番ポートで内部アドレスにアクセスできる必要があります。このデプロイメントゾーンで動作するすべてのアプリケーションは、Deployment Controller Service用に定義されたポート(デフォルトは12000)でプラットフォームインストールにアクセスできる必要があります。
このアドレスはPCの有効なドメイン名またはIPアドレスである必要があり、ポートは指定できません。
有効な例:
192.168.42.23
、intranet.mydomain.com
、rincewind.lan
無効な例:
192.168.42.23/site
、192.168.42.23:8080/site
、rincewind.lan/university
- Use HTTPS for internal communications
- Boolean型パラメータが有効な場合、別のデプロイメントゾーン内のアプリケーションにより実行される現在のデプロイメントゾーン内のアプリケーションへの通信を、すべてHTTPS経由で行います。
- Hosting Technology
-
このゾーンのすべてのアプリケーションが搭載するテクノロジーの種類を参照します。利用可能なオプションは以下のとおりです。
Classic Virtual Machines
、Docker Containers
、Amazon ECS
、Azure Container Service
、Pivotal Cloud Foundry
。以下のオプションは、コンテナベースのホスティングテクノロジーです。
Docker Containers
、Amazon ECS
、Azure Container Service
、Pivotal Cloud Foundry
。以下のオプションは、Dockerベースのコンテナテクノロジーです。
Docker Containers
、Amazon ECS
、Azure Container Service
。 - Includes all Servers
- Boolean型パラメータが有効な場合、後日追加されるサーバーも含めてすべてのサーバーが現在のデプロイメントゾーンにプラットフォームによって自動的に追加されます。このパラメータが有効な場合、デプロイメントゾーンに対するサーバーの手動での追加・削除ができなくなります。
以下のフィールドは、一部の利用可能なホスティングテクノロジーにのみ適用可能です。
- Deployment Mode
-
適用対象: すべてのコンテナベースのホスティングテクノロジー。
このデプロイメントゾーンで実行されるデプロイの種類を参照します。
Automatic
またはManual
。自動デプロイでは、手動デプロイで必要なすべてのパラメータに加えて、様々なOutSystemsのデプロイ手順を、選定した自動デプロイツールの特定のタスクに結びつけるためのURLトリガーを定義することも必要です。
- Output Files To
-
適用対象: すべてのコンテナベースのホスティングテクノロジー。
プラットフォームがアプリケーションコンテナの作成に必要なすべての成果物(ファイルセット)を格納するファイルシステム上の場所。
指定する場所は、プラットフォームをインストールした同じPC上のパスやネットワーク共有上のパスになります。
OutSystemsサービス(通常、Local Service)で使用するユーザーアカウントには、このパスに対する読み取り/書き込み権限が必要です。
例:
C:\users\eskerina\container-bundles
、\\twoflower\luggage
注記:
C:\
のパスまたは類似のパスは、プラットフォームがインストールされた同じPC内の場所を参照します。指定したディレクトリが存在しない場合は、アプリケーションをこのゾーンにパブリッシュするときに作成されます。 - Result
-
適用対象: すべてのコンテナベースのホスティングテクノロジー。
プラットフォームが要求する結果ファイルの格納場所で、よく知られた構造を持ち、アプリケーションを実行するコンテナが動作中でアクセス可能であるか、またはデプロイが失敗したかを示します。
指定する場所は、プラットフォームをインストールした同じPC上のパスやネットワーク共有上のパスになります。これまでのパラメータで構成したのと同じフォルダでもかまいません。
OutSystemsサービス(通常、Local Service)で使用するユーザーアカウントには、このパスに対する読み取り権限が必要です。
例:
C:\users\eskerina\container-results
、\\twoflower\luggage
注記:
C:\
のパスまたは類似のパスはすべて、プラットフォームがインストールされた同じPC内の場所を参照します。 - Output Config Files to
-
適用対象: すべてのコンテナベースのホスティングテクノロジー。
コンテナ内部で動作するアプリケーションおよびApplication Scheduler Serviceの両方で必要とされる構成ファイルをプラットフォームが配置するファイルシステム上の場所。各アプリケーションは指定したパス内に独自のサブフォルダを設定します。
指定する場所は、プラットフォームをインストールした同じPC上のパスやネットワーク共有上のパスになります。OutSystemsサービス(通常、Local Service)で使用するユーザーアカウントには、このパスに対する読み取り/書き込み権限が必要です。
例:
C:\users\eskerina\container-configs
、\\twoflower\luggage
注記:
C:\
のパスまたは類似のパスはすべて、プラットフォームがインストールされた同じPC内の場所を参照します。指定したディレクトリが存在しない場合は、アプリケーションをこのデプロイメントゾーンにパブリッシュするときに作成されます。 - From Image
-
適用対象: すべてのDockerベースのホスティングテクノロジー。
このデプロイメントゾーンのコンテナが基盤とするベースイメージ。このパラメータで、デフォルト(および推奨)イメージに代わる独自のベースイメージを使用するための拡張ポイントを設定します。このパラメータは、Dockerfileで使用する
FROM
ディレクティブに対応します。デフォルト(および推奨)イメージは
microsoft/dotnet-framework:4.7.1-runtime
です。ベースイメージが引き続き
microsoft/dotnet-framework:4.7.1-runtime
であり、OutSystemsによって追加された前提条件が変更されない限り、必要に応じて独自のイメージを使用することができます。中央レジストリを採用することは必要条件ではありませんが、インフラを構築してデプロイメントゾーンのコンテナに指定したベースイメージをデプロイ開始前にコンテナのランタイムで使用できるようにすることを強く推奨します。これにより、OutSystemsアプリケーションのコンテナイメージ作成に要する時間を大幅に短縮できます。
「Dockerレジストリの要件」をご覧ください。
Manual Deploymentフィールド
以下のフィールドを利用できるのは、コンテナベースのホスティングテクノロジーでManualデプロイモードを使用した場合のみです。
- Operator Timeout
-
適用対象: すべてのDockerベースのホスティングテクノロジー。
「デプロイの準備」、「デプロイ」、「構成の更新」、「アンデプロイ」の各手順中に実行される運藤担当者の各アクションに対して、Deployment Controller Serviceによって適用されるタイムアウト。
オペレータが「Operator Timeout」の分数以内にリクエストされた操作を実行しなかった場合、デプロイは失敗します。
Automatic Deploymentフィールド
以下のフィールドを利用できるのは、コンテナベースのホスティングテクノロジーでAutomaticデプロイモードを使用した場合のみです。
- コンテナ作成用URLトリガー
-
デプロイの準備手順でアプリケーションのデプロイ時に呼び出されるURL。プラットフォームは、HTTP 「GET」リクエストを設定されたURLに送信し、
2xx OK
レスポンスを要求します。URLトリガーハンドラは要求と同時に、タスクが開始されたというレスポンスを可能な限り早く返す必要があります。デプロイが始まるのは、デプロイの準備手順が完了したという結果ファイル(
.preparedone
)がResultフォルダに作成されてからとなります。この段階で、コンテナの成果物はすべて提供され、使用できる状態になるため、
docker image build
(Dockerベースのホスティングテクノロジー用)やcf push --nostart
(Pivotal Cloud Foundry用)のような操作を自動化できます。URLクエリ文字列に追加できるパラメータは以下のとおりです。
- Address: 構成されたデプロイメントゾーンアドレス。
- ApplicationName: デプロイ中のアプリケーション名
- ApplicationKey: 生成されたZIPバンドルを識別するために、OperationIdと一緒に使用されるアプリケーションキー識別子。
- OperationId: パブリッシュ操作を示すGUID。デプロイが異なれば、IDも異なります。
- TargetPath: バンドルが提供されるパス
- ResultPath: 結果ファイルを配置するパス。
- ConfigPath: アプリケーションの構成ファイルがあるパス。
- ModuleNames: アプリケーションに属するモジュール名。
こうしたクエリ文字列パラメータの値はすべて、Base64エンコードを使ってシリアライズされます。
「TargetPath」にプラットフォームが作成したアプリケーションバンドルZIPファイルのファイル名は、以下のように定義されます。
<アプリケーションキー>_<操作ID>.zip
この段階で「ResultPath」に要求された結果ファイルの名前は以下のとおりです。
<アプリケーションキー>_<操作ID>.preparedone
- コンテナ実行用URLトリガー
-
デプロイ手順でアプリケーションのデプロイ時に呼び出されるURLプラットフォームは、HTTP 「GET」リクエストを設定されたURLに送信し、
2xx OK
レスポンスを要求します。URLトリガーハンドラは要求と同時に、タスクが開始されたというレスポンスを可能な限り早く返す必要があります。デプロイが始まるのは、デプロイ手順が完了したという結果ファイル(
.deploydone
)がResultフォルダに作成されてからとなります。この段階で、
docker run
(Dockerベースのホスティングテクノロジー用)またはcf start
(Pivotal Cloud Foundry用)のような操作を自動化できます。データベースのメタモデルはすでにアップグレードされることになっているため、新バージョンのアプリケーションを起動し、旧バージョンを停止して、すべてのルーティング規則を変更するのに最適な段階です。前のフィールドに入力したのと同じクエリ文字列パラメータセットをこのURLトリガーに追加します。
この段階で「ResultPath」に要求された結果ファイルの名前は以下のとおりです。
<アプリケーションキー>_<操作ID>.deploydone
- 構成更新用URLトリガー
-
アプリケーションの構成ファイルが変更されるたびに呼び出されるURL。プラットフォームは、HTTP 「GET」リクエストを設定されたURLに送信し、
2xx OK
レスポンスを要求します。URLトリガーハンドラは要求と同時に、タスクが開始されたというレスポンスを可能な限り早く返す必要があります。デプロイが始まるのは、構成の更新手順が完了したという結果ファイル(
.configsdone
)がResultフォルダに作成されてからとなります。この段階では、以下のような操作を自動化できます。
-
Dockerベースのホスティングテクノロジーの場合: Output Config Files toフォルダに生成された構成ファイルのDockerコンテナにマウントされたフォルダへのコピー。マウントされたフォルダが同じで、コピーが不要な場合は、このURLトリガーハンドラによって、Resultフォルダに単に
.configsdone
ファイルが作成されます。 -
PCFホスティングテクノロジーの場合: Output Config Files toフォルダに生成された構成ファイルのバンドル
config
フォルダへのコピーおよびcf push
の実行による新しい構成でのアプリケーションの更新。
[Container Build Trigger URL]フィールドに入力したのと同じクエリ文字列パラメータセットをこのURLトリガーに追加します。
この段階で「ResultPath」に要求された結果ファイルの名前は以下のとおりです。
<アプリケーションキー>_<操作ID>.configsdone
-
- コンテナ削除用URLトリガー
-
コンテナにデプロイされたアプリケーションが削除されるたびに呼び出されるURL。このURLトリガーが呼び出されるのは以下の場合です。
- 元のアプリケーション名が変更された場合。
- アプリケーションが削除された場合。
- アプリケーションが別のデプロイメントゾーンに変更された場合。
プラットフォームは、HTTP 「GET」リクエストを設定されたURLに送信し、
2xx OK
レスポンスを要求します。URLトリガーハンドラは要求と同時に、タスクが開始されたというレスポンスを可能な限り早く返す必要があります。削除プロセスが始まるのは、アンデプロイ手順が完了したという結果ファイル(.undeploydone
)がResultフォルダに作成されてからとなります。この段階で、
docker rm
(Dockerベースのホスティングテクノロジー用)またはcf delete
(Pivotal Cloud Foundry用)のような操作を自動化できます。[Container Build Trigger URL]フィールドに入力したのと同じクエリ文字列パラメータセットをこのURLトリガーに追加します。
この段階で「ResultPath」に要求された結果ファイルの名前は以下のとおりです。
<アプリケーションキー>_<操作ID>.undeploydone
- External Deployment Tool Timeout
-
「デプロイの準備」、「デプロイ」、「構成の更新」、「アンデプロイ」の各手順中に実行される各外部デプロイツールアクションに対して、Deployment Controller Serviceによって適用されるタイムアウト。
外部デプロイツールが「External Deployment Tool」の分数以内にリクエストされた操作を実行しなかった場合、デプロイは失敗します。
ゾーンに関連付けられたモジュール/アプリケーションがない場合、デプロイメントゾーンのパラメータは、「Hosting Technology」を除いてほとんどすべて変更可能です。デプロイメントゾーン設定に対する変更の中には、変更を反映するためにアプリケーションの再パブリッシュが必要になるものもあります。また、アプリケーションのコンシューマも再パブリッシュが必要な場合もあります。