Skip to main content

 

OutSystems 11オンラインヘルプ

 

OutSystems

コンテナへのデプロイ

コンテナはテクニカルプレビューです。

コンテナへのアプリケーションのデプロイは、コンテナベースのソリューションや、アーキテクチャ、ネットワーク要件に精通した上級ユーザーを対象としています。

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

OutSystemsアプリケーションは、Windows Serverを基盤としたコンテナにデプロイできます。OutSystemsは、DockerやPivotal Cloud Foundryなどの様々なホスティングテクノロジー、ならびにAmazon ECSやAzure Container ServiceなどのDockerベースの他のホスティングテクノロジーをサポートしています。

このデプロイ機能によってOutSystemsが実現するローコードの継続開発によるメリットとともに、コンテナベースのパブリッククラウドやプライベートクラウドを使用するメリットも得られます。こうしたメリットには、リソースの効率性および密度、効果的な分離、水平スケールを容易かつ迅速に実現する機能などがあります。これらは通常、アプリケーションライフサイクルのより後の段階に関連しています(Quality AssuranceやProductionなど)。

コンテナは、すべてのDevelopment以外の環境でサポートされています。これにより、アプリケーションライフサイクルの初期段階でOutSystemsが実現する高速開発サイクルのメリットを享受しつつ、Production環境で提供されるのと同等のコンテナ上で実行するアプリケーション(Quality Assurance環境内など)をテストできるようになります。

OutSystemsのコンテナ用のデプロイユニットはアプリケーションで、アプリケーションのすべてのモジュールが同じ「デプロイメントゾーン」にデプロイされます。また、OutSystemsはコンテナごとに1つのアプリケーションのみサポートします。

コンテナの推奨アプリケーションアーキテクチャ

コンテナモデルはマイクロサービスアーキテクチャに適しています。マイクロサービスアーキテクチャでは、アプリケーションは自律的なサービスの形で独立した複数のサブシステムで構成され、個別に開発、テスト、バージョン管理、デプロイ、拡張が可能です。

コンテナ内部にモノリシックアプリケーションをデプロイすることは可能ですが、通常、このアーキテクチャは推奨されません。この手法の欠点が明らかになるのは、アプリケーションを拡張する必要のある場合です。特にそのニーズがアプリケーションの一部にのみ影響する場合に顕著です。

コンテナのアプリケーションに一般に推奨されるアーキテクチャは、むしろ、個別のエンドツーエンドのドメインやビジネス機能を特定のコンテキスト境界内部に実装し、自律的に開発が可能なサービス群でアプリケーションが構成されるようなアーキテクチャです。

OutSystemsにおいて、推奨されるコンテナの利用方法は、関連するドメインデータモデルとドメインロジックを所有する小さなアプリケーションを作成することです(「主権性」目標と「分散データ管理」目標を達成するため)。つまり、それ自体はビジネスアプリケーションよりずっと小さく、REST APIを経由するなどして他のアプリケーションへのサービス提供を担うアプリケーションです。

アプリケーションが多くのモジュールを有するということは、アーキテクチャに問題がある可能性を示しています。その場合、アプリケーションをリファクタリングしてより小さなアプリケーションに分割することで、細分化されたアプリケーションのアーキテクチャ全体の拡張性を高め、コンテナのメリットをさらに活かせるようにする必要があります。

このトピックの詳細については、以下の記事の例をご覧ください。

「コンテナベースのアプリケーションおよびマイクロサービスベースのアプリケーションの設計」(Microsoft)
広範なアプリケーションを対象としていますが、OutSystemsのアプリケーションにも適用できます。特に次のセクションは、適切なアーキテクチャを使用してコンテナにバインドされたアプリケーションを開発するうえで興味深い内容です。「データ管理の課題と解決策」、「マイクロサービスごとのドメインモデル境界の特定」、「複数のマイクロサービスが生成するUIの視覚的な形状およびレイアウトを含む、マイクロサービスベースの複合UIの作成」。
「Docker参照アーキテクチャ: 拡張性と移植性の高いDockerコンテナネットワークの設計」(Docker)
強固なアーキテクチャを設計するうえで適切な出発点となります。

制限事項

コンテナにデプロイしたOutSystemsアプリケーションには、アプリケーション機能と利用可能な操作に関して一部制限があります。

利用できないアプリケーション機能

以下の機能を持つアプリケーションはコンテナにデプロイできません。

  • クライアント証明書を利用するHTTPセキュリティ。
  • UIフローや画面での統合認証。
  • SOAP Webサービスでの統合認証。
  • DB2データベースを使用するアプリケーション。
  • SEO規則を使用するアプリケーションやモジュール。

Service CenterやLifeTimeなどのシステムアプリケーションをGlobalデプロイメントゾーンに保持することが推奨されるほか、ホスティングテクノロジーがコンテナであるデプロイメントゾーンやフロントエンドサーバーを持たないデプロイメントゾーンにシステムアプリケーションを関連付けたりデプロイしたりすることはできません

localhostアドレスを使用してページをレンダリングしたり、他のアプリケーションからエンドポイントにアクセスしたりすることはできません。コンテナ内部で動作するアプリケーションの場合、localhostはコンテナ自体を参照します。OutSystemsでは、コンテナごとにアプリケーションは1つだけのため、参照されるアプリケーションは同じコンテナで実行できません。また、コンテナの特性上、2つのアプリケーションのコンテナが同じサーバー上にある保証はないため、アプリケーションはlocalhostやコンテナのエンジンホストのアドレスを使用して相互に参照してはなりません。開発者は常に、目的のアプリケーションのデプロイメントゾーンのアドレスを使用する必要があります。

利用できない操作

アプリケーションがコンテナベースのホスティングテクノロジーを使用して構成されたデプロイメントゾーンにデプロイするように設定されている場合、一部の操作が利用できません。

Service Studioでは以下の操作ができません。

  • コンテナにバインドされたアプリケーションでのモジュールの新規作成。
  • いずれかがコンテナにバインドされたアプリケーションの場合、一方のアプリケーションから他方のアプリケーションにモジュールを移動すること。
  • コンテナにバインドされたアプリケーションでのモジュールの1-Click Publishの実行。
  • コンテナにバインドされたアプリケーションの1-Click Publishの実行。
  • コンテナにバインドされたアプリケーションのモジュールの削除。
  • コンテナにバインドされたアプリケーションのモジュールのデバッグ(デバッグはアプリケーションがコンテナを使用するデプロイメントゾーンにない環境で実行する必要があります)。

Service Centerにおいて、またはOSPToolを使用した場合、以下の操作が実行できません。

  • コンテナにバインドされたアプリケーションでのモジュールの1-Click Publishの実行。
  • コンテナにバインドされたアプリケーションのモジュールの削除。
  • コンテナにバインドされたアプリケーションのモジュールの一部のサブセットを含むソリューションのダウンロードやパブリッシュ。

また、Service Centerでは以下の操作が実行できません。

  • ホスティングテクノロジーがコンテナベースのデプロイメントゾーンをデフォルトゾーンに設定すること。
  • コンテナに手動でデプロイされたアプリケーションを削除すること(こうしたアプリの削除を可能にする手順をご覧ください)。

コンテナのApplication Scheduler Service

コンテナにバインドされたアプリケーションにはそれぞれ、Application Scheduler Serviceが用意され、コンテナ内のアプリケーションにバンドルされています。このサービスに何か問題が発生した場合、コンテナは停止します。

コンテナにバインドされたアプリケーションでは、このサービスを通じてBPTやタイマーなどの非同期タスクがサポートされています。プラットフォームに付属するScheduler Serviceとよく似ていますが、処理を担当するのはコンテナ内部で動作するアプリケーションの非同期タスクのみです。

このセクションの記事

  • Was this article helpful?