Skip to main content

 

OutSystems 11オンラインヘルプ

 

OutSystems

推奨ネットワークアーキテクチャ

OutSystemsでコンテナを最大限に活用するためには、コンテナベースのデプロイゾーンで定義されたアドレスのロードバランサとリバースプロキシを有するネットワークトポロジを採用する必要があります。この機能は、制限された方法でコンテナクラスタ自体によって提供されるか、またはスタンドアローンのソフトウェアコンポーネントによって提供されます。

コンテナのデプロイゾーンの内部アドレスは通常、コンテナクラスタマネージャーのアドレスまたは、クラスタの前に配置したロードバランサに設定します。

接続要件

コンテナのインフラは、プラットフォームデータベース、ロギングデータベース、セッションデータベース、OutSystems Deployment Controller Serviceに接続できる必要があります。つまり、Configurationツールで構成されたサーバー名が有効でコンテナ内部からアクセスできる必要があります

「localhost」をデータベースサーバー名として使用しないでください。アプリケーションがコンテナ内部で動作している場合は機能しません(ローカルホストからはデータベースにアクセスできません)。

構成を確認するには、以下の手順を実行します。

  1. Configurationツールを開きます。

  2. [Platform]タブで、[Database] > [Server]フィールドが正しく構成されていることを検証します。

  3. [Log]タブで、[Database] > [Server]フィールドが正しく構成されていることを検証します。

  4. [Session]タブで、[Database] > [Server]フィールドが正しく構成されていることを検証します。

  5. [Controller]タブで、[Deployment Controller Service] > [Deployment Controller Server]フィールドが正しく構成されていることを検証します。

  6. [Cache]タブで、[Cache Invalidation Service] > [Host]フィールドが正しく構成されていることを検証します。

    注記: Platform Serverのデプロイコントローラのポート(12000)は、コンテナランタイムからの接続を許可する必要があります。要件の完全なリストについては、OutSystemsのネットワーク要件をご覧ください。

デプロイゾーンのアドレスを構成する

デプロイゾーンのInternal Addressアトリビュートは、同じゾーンまたは異なるゾーンで特定のモジュールが他のモジュールを参照することを許可します(SOAPまたはRESTの呼び出し、プロセス参照、他のモジュールからのリソース参照など)。OutSystemsは、プロデューサモジュールをデプロイしたデプロイゾーンのアドレスを使用して、すべてのサーバー側の呼び出し/リダイレクトを生成します。

すべてのデプロイゾーンに構成したアドレスが、ネットワークのレイアウトやトポロジに適合することを確認する必要があります。

サーバーが1台の場合、Hostnameパラメータに従って[Internal Address]フィールドを環境のアドレスに設定できます。パラメータは、[Service Center]> [Administration] > [Environment Configuration] > [Hostname]で構成します。

要素 説明
OutSystemsアプリケーションにアクセスするユーザーデバイス(モバイルまたはデスクトップ)。
プラットフォームがアプリケーションのメタデータを保存したり、アプリケーションがビジネスデータを保存したりするために使用するデータベース(オンプレミスまたはクラウド上)。
同じIISサーバーで稼働するアプリケーションとともに仮想マシンまたはクラウド上にインストールされたOutSystemsプラットフォーム(使用するアプリケーションプールは異なる場合があります)。

ファーム環境(複数のサーバーを使用する場合)では、デプロイゾーンの内部アドレスはデプロイゾーンのサーバー全体に負荷を分散するよう構成されたロードバランサのアドレスにする必要があります。

要素 説明
メインのロードバランサおよびリバースプロキシ - www.mydomain.netのアドレスを公開し、/AppXおよび/AppYをアプリケーションが利用可能なサーバーにマッピングするように設定されています。
デプロイゾーンのロードバランサ - デプロイゾーンに構成されたサーバー間で負荷を分散します。
OutSystemsアプリケーションにアクセス可能な2番目(または3番目)のサーバー。仮想マシンまたはクラウド上にインストールされ、プラットフォームからアクセスできます。
「イントラネット」デプロイゾーン 顧客定義のゾーン、環境内で構成された一部のサーバーのみが含まれます(図の3台のうちの2台)。

コンテナにデプロイする場合、デプロイゾーンの内部アドレスは通常、コンテナクラスタマネージャー/オーケストレータ(またはクラスタの前に配置したロードバランサ)のアドレスと同じです。つまり、コンテナのデプロイゾーンの内部および外部のアプリケーションはすべて、クラスタのアドレスを使用してそのデプロイゾーンのアプリケーションにアクセスします。

要素 説明
コンテナのロードバランサおよびリバースプロキシ - コンテナクラスタのアドレスを公開し、/AppZおよび/AppWをアプリケーション利用可能なコンテナにマッピングするように設定されています。クラスタで利用可能なコンテナ間にリクエストを分配します。クラスタが直接提供する場合や、スタンドアローンのアプライアンスとしてインストールされる場合があります。
アプリケーションを含むコンテナをデプロイするコンテナクラスタのノード。仮想マシンまたはクラウド上にインストールされ、プラットフォームからアクセスできます。
「コンテナ」デプロイゾーン コンテナクラスタを表す顧客定義のゾーンです。その中ですべてのアプリケーションはコンテナにデプロイされます。

クライアント側の呼び出し(ブラウザやモバイルデバイスで動作するすべてのコード)は環境URLに依存しているため、一般向けに公開されているアプリケーションが環境URLを利用してアクセスできるようにネットワークトポロジを構成します。

コンテナに複数のデプロイゾーンを使用する

コンテナを試してみる場合は、複数のコンテナを使用するように構成された単一のデプロイゾーンを使用したコンテナから始めることを強く推奨します。これにより、複数のコンテナゾーンを処理するという余計な負荷をかけることなく、開発インフラでコンテナを使用するメリットを検証できます。

OutSystemsで使用するコンテナテクノロジーの習熟度が向上するにつれて、より複雑なシナリオを検討したり、コンテナで使用するデプロイゾーンを追加することを考えたりするようになるでしょう。

以下により高度なシナリオの例を示します。コンテナに複数のデプロイゾーンを使用すると便利です。

高度なシナリオ #1

一部のアプリケーションでのみ必要とされるライブラリを追加でバンドルする(さらに、そうしたライブラリを他のアプリケーションのイメージで利用できないようにする)ために、コンテナにバインドされた一部のアプリケーションが異なるベースイメージを持つ必要があります。

提案: 「元のイメージ」が異なる構成を持つデプロイゾーンを作成してください。

高度なシナリオ #2

コンテナにバインドされたアプリケーションには、外部から(環境URLによって)アクセスできる必要があるものあれば、バックオフィスのアプリケーションからのみアクセスできればよいものもあります。

提案: アドレスが異なるデプロイゾーンを作成してください。