2017-06-05 2 views
4

サービスファブリック上のWeb APIのビルドと、AzureのWebアプリケーションのいくつかのWebプロジェクトがあります。私たちは、展開時に旧バージョンのアプリケーションに簡単に戻ってCDパイプラインを改善したいと考えています。サービスファブリックを使用したCDパイプラインの改良

だから何を思い付くことはサービスの生地のためにそれが徐々に新しいバージョンのインスタンスにユーザーを移動したり、単にスイッチを入れるとするすべてのトラフィックを送信するのかどうかとトラフィックをルーティングステージングのための他のアプリを作成です新しいバージョンを一度にすべて。

WebappsとService Fabricの両方をサポートするソリューションが必要です。 ステートフルサービスのパターンと経験を提供すると、 となるでしょう。

参照

https://azure.microsoft.com/en-us/resources/videos/azure-websites-deployment-slots-for-staging-sites/

B.Continuous配信パイプラインを交換する

A.Webアプリスロットenter image description here

PS: 私はスワップがステートフルなサービスには意味がないことを知っています。データを保存して一貫性を保つためには、ローリングアップグレードが必要です。

答えて

1

Azure Api Managementを使用することを検討してください。これで、Service Fabric(trelloを確認してください)が適切にサポートされます。それは、トラフィックの漸進的な増加を提供しないことを除いて、基礎となる技術に対して外部的かつ不可知論的であるため、両方のバージョン管理を解決するはずです。

+0

OctopusなどのCIシステムはこれをトリガーしますか? –

+0

これは、(Service Fabricアプリケーションのアップグレード)ルートには移動しないでください。ここで定義します:https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-application-upgrade-チュートリアル –

+0

私はSFとWebAppの両方の上でAPIのmgmtをリバースプロキシとして意図していました。ルーティングルールを定義することで、トラフィックを基になるAPIに誘導できます。たとえば、V2のAPIを含む2つ目のアプリケーションインスタンスを追加して、それにトラフィックを誘導することができます。サービスバージョンを安全にパッチできるように、定期的なアップグレードメカニズムを使用して、失敗時のロールバックを確実に行う必要があります。 – LoekD

関連する問題