Skip to main content

 

 

 

 

Template:OutSystems/Documentation_KB/Breadcrumb_New_Layout

 

 

Template:OutSystems/OSLanguageSwitcher

 

 

 

OutSystems

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

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

コンテナのデプロイメントゾーンは、デプロイメントゾーンアドレスをコンテナクラスタマネージャのアドレスまたは、クラスタの前に配置したロードバランサに設定するのが一般的です。

接続要件

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

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

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

  1. Configuration Toolを開きます。

  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のネットワーク要件」をご覧ください。

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

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

すべてのデプロイメントゾーンの設定アドレスがネットワークのレイアウトおよびトポロジに適合することを確認する必要があります。

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

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

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

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

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

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

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

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

まずコンテナを試すには、複数のコンテナを使用するよう構成された単一のデプロイメントゾーンを使用することを強く推奨します。これにより開発インフラでコンテナを使用するメリットを評価できるようになり、複数のコンテナゾーンを扱う余計な手間がかかりません。

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

以下に、より高度なシナリオの例を示します。コンテナ用のデプロイメントゾーンが複数あることが有効な場合があります。

高度なシナリオ #1

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

推奨: 「元のイメージ」が異なる構成を持つデプロイメントゾーンを作成します。

高度なシナリオ #2

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

推奨: アドレスの異なるデプロイメントゾーンを作成します。