2016-03-08 2 views
11

現在Azure ServiceFabricのReliableActorsフレームワークを使用してアプリケーションを構築しています。私たちがスケールアップするにつれ、私は青緑の展開を検討しています。私はステートレスなシステムを使ってこれを行う方法を見ることができます。ステートフルな俳優を使ってこれを行う方法はありますか?Azure ServiceFabricを使用した青/緑のデプロイ

答えて

25

サービスファブリックは、すべてVIPスワップのようなデプロイメントスワップではなく、ローリングアップグレードに関するものです。ステートレスサービスとステートフルサービスの両方が同じようにアップグレードされますが、後で言及するステートフルなニュアンスがいくつかあります。

ローリングアップグレードでは、一度に1つのアップグレードドメインでアプリケーションのアップグレードが行われるため、ダウンタイムや突然の切り替えは発生しません。サービスファブリックのローリングアップグレードは、プラットフォームが次のアップグレードドメインに移行する前にヘルスチェックを実行し、ヘルスチェックが失敗した場合に自動的にロールバックする安全な "管理"モードで実行できます。

OK、これはすべていいですね。しかし、アップグレードが常にアップグレードを圧延しているときは、どのように青/緑の導入を行うのですか?

2つの実行中のアプリケーションを保持できる2つの "環境"を持つ代わりに、Service Fabricにはアプリケーションインスタンスを作成できるバージョン管理されたアプリケーションタイプの概念があります。これはどのように動作するかの例です:

私はFooというアプリケーションを作りたいとしましょう。私のFooアプリケーションはアプリケーションタイプとして定義され、FooTypeと呼ばれます。これはC#でクラスを定義するのと同様です。 C#のクラスと同様に、自分のタイプのインスタンスを作成できます。各インスタンスには、クラスの各オブジェクトインスタンスが一意の変数名を持つ方法と同様に、一意の名前が付けられます。しかし、C#のクラスとは異なり、私のFooTypeはバージョン番号を持っています。そして、私は、クラスタ内のアプリケーションの種類とバージョン「登録」することができますことを、登録して

FooType 1.0 

を、私は、そのアプリケーションのインスタンスを作成することができます。

"fabric:/FooApp" of FooType 1.0 

さて、私はバージョン2.0を開発しましょう私のアプリケーションの。だから私は、クラスタ内の私のFooTypeのバージョン2.0を登録します。

FooType 1.0 
FooType 2.0 

は今、私はFooTypeの両方のバージョンが登録されており、私はまだ1.0ランニングのインスタンスを持っている:それは楽しみを取得する場所

"fabric:/FooApp" of FooType 1.0 

ここです。私はいくつか興味深いことをすることができます:

FooType 1.0のインスタンスである "fabric:/ FooApp"をFooType 2.0にアップグレードすることができます。これは、実行中のアプリケーションのローリングアップグレードになります。

か..私は「生地:/ FooApp」残すことができますのみを、そして私のバージョン2.0アプリケーションの新しいインスタンスを作成します。今、私はサイドバイサイドを実行している、二つのアプリケーションを持っている

"fabric:/FooApp" of FooType 1.0 
"fabric:/FooAppv2Test" of FooType 2.0 

同じクラスタ内に存在します。 1つは1.0のインスタンスであり、もう1つは2.0のインスタンスです。ポートとアプリケーションエンドポイントの設定によっては、2.0インスタンスをテストしている間にユーザーがまだ1.0インスタンスに移動していることを確認できます。

偉大なので、すべての私のテストは、2.0インスタンスに渡すので、今私は安全に1を取ることができます。0インスタンスと FooTypeの2.0にそれをアップグレードします。ここでも、これはそのインスタンス(fabric:/ FooApp)のローリングアップグレードであり、ユーザーを新しいインスタンス(fabric:/ FooAppv2Test)に移行するわけではありません。後で私はファブリック:/ FooAppv2Testを削除します。これはテストのためのものだからです。

ブルー/グリーンのメリットの1つは、新しいものが失敗した場合でも他のデプロイメントに戻すことができることです。まあ、まだFooTypeの1.0と2.0の両方が登録されています。したがって、1.0から2.0へのアップグレード後にアプリケーションが誤動作を起こした場合は、1.0に戻してアップグレードすることができます。実際には、アプリケーション・インスタンスを必要な数の異なるバージョン間で「アップグレード」することができます。また、スワップ環境のようにすべてのアプリケーションバージョンのインスタンスを実行する必要はありません。異なるバージョンの登録済みと、バージョン間での「アップグレード」が可能な単一のアプリケーションインスタンスだけです。

ステートフルサービスの警告がありました。ステートフルなサービスで覚えておくべき重要なことは、アプリケーションの状態(ユーザーのデータ)がアプリケーションインスタンス(ファブリック:/ FooApp)に含まれているため、ユーザーがそのデータを見ることができるようにすることです。そのため、デプロイメントスワップの代わりにローリングアップグレードを行っています。

これは単なる基本的な考えです。アプリケーションタイプ、バージョン、およびインスタンスを使用して遊ぶ方法は、目標とアプリケーションの仕方によって異なりますが、それは別の時間です。

+0

これは役に立ちました。ありがとう、Vaclav。私の考えでは、青/緑スタイルのデプロイメントのメリットの1つは、スワップ全体を実行する前に、通常はロードバランサを経由して2番目のサービスにトリプルを行って確実に機能させることです。 SFで同様の検証を行う方法はありますか? – blackSphere

+1

ステートレスサービスの場合、これを設定してv1.0とv2.0のインスタンスを作成することができます。また、自分のルーティングによってv2.0にトラフィックをファンネルできるようになり、徐々にスケールアップしてv1.0を縮小します。ステートフルなサービスでは、状態自体がアプリケーションインスタンスの内部にあるため、少し面倒です。ユーザーをアプリケーションの新しいインスタンスに送信すると、そのデータはそこに存在しません。これは単に一般的なステートフルなものの性質なので、Service Fabricは非常に堅牢でファーストクラスのローリングアップグレードを備えています。 –

+1

また、アプリケーション全体が一度にアップグレードされないため、ローリングアップグレードは「細流化」していると主張します。一度に1スライスずつアップグレードし、いつでもヘルスチェックが失敗した場合(カスタムヘルスチェックを行うことができます)、ロールバックされます。ですから、それを自動トリクルスルー展開と考えることができ、私たちはいくつかの自動化を愛しています! –

関連する問題