Skip to main content

 

 

 

 
Language:

 

 
 
 
OutSystems

ダウンタイムなしでコンテナテクノロジーにデプロイされたアプリをアップグレードする

注記: このドキュメントでは明示的に「アプリケーション」と表記していますが、これはコンテナベースのホスティングテクノロジーのデプロイユニットであるため、「アプリケーション」は「モジュール」の集まりを表すことを常に意識してください。

これまでは、OutSystemsプラットフォームがIIS(OutSystems 11では「Classic Virtual Machines」デプロイメントテクノロジーとして知られています)と直接(および排他的に)インタラクションした場合、新しいアプリケーションバージョンのデプロイメント中または構成の更新時にダウンタイムなしを実現しても、ほとんど影響がありませんでした。

現在、コンテナで実行されるアプリケーションがサポートされるようになったため、こうしたプロセスの実行時にダウンタイムなしを実現するには、使用しているホスティングテクノロジーに応じて追加の手順を実行する必要があります。

このドキュメントで提供される情報は主に、LifeTimeを使用して環境間でステージングされるアプリケーションを対象としています。ただし、単一環境のシナリオでも対象になるシナリオがいくつかあります。たとえば、アプリケーションの構成を更新する場合や、Service Centerを使用して「Classic Virtual Machines」からコンテナベースのホスティングテクノロジーに移行する場合などです。

はじめに

このドキュメントでは、以下を前提としています。

また、このセクションで紹介するガイドラインでは、以下を前提としています。

  • 「メインのロードバランサとリバースプロキシ」には、明示的なルールが定義されていないアプリケーションモジュールについて、OutSystems Platform Serverを指すというデフォルトの規則がある。

  • 「メインのロードバランサとリバースプロキシ」には、選択したコンテナベースのホスティングテクノロジーにデプロイされたOutSystemsアプリケーションモジュールについて、固有の書き換え規則がある。

これらの手順は手動で実行できますが、デプロイメントゾーンの構成の「Automated Mode」で提供される「Container Run」拡張フックを使用して自動的に実行する必要があります。

必要に応じて、示されている手順を固有のネットワークインフラ設定に適用します。

デプロイ戦略

提供されているガイドラインでは、異なるホスティングテクノロジーでダウンタイムなしのデプロイを実現するために、以下の2つの一般的なデプロイ戦略のいずれかに従います。

Blue-Green

Blue-Greenデプロイ戦略とは、本番環境(Blue)とアイドル環境(Green)という2つの同一の環境を用意して、Blue環境に影響を及ぼすことなくGreen環境を個別にテストできるデプロイ戦略です。テスト後、Blue環境からGreen環境にトラフィックを切り替えます。

この戦略は「Classic Virtual Machines」からコンテナベースのホスティングテクノロジーへの移行に最適であり、影響を最小限に抑えることができます。

Blue-Greenデプロイ戦略の図

ローリングアップデート

ローリングアップデート戦略とは、アプリケーションを順次更新していくデプロイ戦略です。新しいアプリケーションバージョンのコンテナをリリースするたびに、古いバージョンを置き換えていきます。このプロセスは、各レプリカについて順次実行されます。

この戦略はリソース使用量が最適化されるため、バージョン更新に最適です。

ローリングアップデートデプロイ戦略の図

  • Was this article helpful?