蓝/绿部署天青与ServiceFabric [英] Blue/Green Deployments with Azure ServiceFabric

问题描述

我目前正在建设使用Azure上ServiceFabric的ReliableActors框架的应用程序。随着我们扩大规模，我期待在做蓝/绿部署。我可以看到如何使用一个无状态的系统来做到这一点。有没有一种方法可以做到这一点使用全状态的行为？

I'm currently building an application using the ReliableActors framework on Azure ServiceFabric. As we scale up, I'm looking at doing blue/green deployments. I can see how to do this using a stateless system. Is there's a way to do this using statefull actors?

推荐答案

服务面料是所有关于滚动升级，而不是部署互换，贵宾般的交换。无状态和有状态的服务升级以同样的方式，但也有一些额外的细微差别状态，我会在后面提到。

Service Fabric is all about rolling upgrades, rather than deployment swaps, like a VIP swap. Both stateless and stateful services are upgraded the same way, but there are a few additional nuances to stateful that I'll mention later.

通过滚动升级，我的意思是升级到一个应用程序来代替完成的，一个升级域的时间，所以没有停机时间并没有突然切换。在服务织物滚动升级可以在一个安全的托管模式，该平台将移动到下一个升级域之前执行健康检查来完成，并会自动回滚，如果健康检查失败。

By rolling upgrades, I mean upgrades to an application are done in place, one upgrade domain at a time, so that there is no downtime and no sudden switch. A rolling upgrade in Service Fabric can be done in a safe "managed" mode where the platform will perform health checks before moving on to the next upgrade domain, and will automatically roll back if health checks fail.

确定，所有听起来不错。可是你怎么办蓝/绿部署升级时，总是滚动升级？

OK, that all sounds nice. But how do you do blue/green deployments when upgrades are always rolling upgrades?

这其中，应用程序类型和版本进来。不是有两个环境，它可以容纳两个运行的应用程序，服务织物具有哪些应用程序实例可以创建版本控制应用程序类型的概念。下面是如何工作的例子：

This where application types and version come in. Instead of having two "environments" that can hold two running applications, Service Fabric has this concept of versioned application types from which application instances can be created. Here's an example of how this works:

比方说，我想创建一个名为Foo的申请。我的富应用被定义为一个应用类型，称之为FooType。这类似于在C＃定义一个类。而像在C＃类，我可以创建类型的实例。每个实例都有一个唯一的名称，类似于一个类的每一个对象实例如何都有一个唯一的变量名。但是，与在C＃中的类，我FooType的版本号。然后，我可以在我的群注册应用程序类型和版本：

Let's say I want to make an application called Foo. My Foo application is defined as an application type, call it FooType. This is similar to defining a class in C#. And like class in C#, I can create instances of my type. Each instance has a unique name, similar to how each object instance of a class has a unique variable name. But unlike classes in C#, my FooType has a version number. Then I can "register" the application type and version in my cluster:

FooType 1.0

使用已注册，我可以创建应用程序的一个实例：

With that registered, I can create an instance of that application:

"fabric:/FooApp" of FooType 1.0

现在，让我们说我发展我的应用程序的2.0版本。所以，我在群集中注册我FooType 2.0版：

Now, let's say I develop version 2.0 of my application. So I register version 2.0 of my FooType in the cluster:

FooType 1.0
FooType 2.0

现在我有FooType的两个版本注册，和我仍然有1.0运行的一个实例：

Now I have both versions of FooType registered, and I still have an instance of 1.0 running:

"fabric:/FooApp" of FooType 1.0

下面就是它得到乐趣。我可以做一些有趣的事情：

Here's where it gets fun. I can do some interesting things:

我可以采取面料：/ FooApp - 的FooType 1.0一个实例 - 它升级到2.0 FooType。这将是运行的应用程序的滚动升级。

I can take "fabric:/FooApp" - an instance of FooType 1.0 - and upgrade it to FooType 2.0. This will be a rolling upgrade of that running application.

或..我可以离开面料：/ FooApp独自一人，并创建一个的我的2.0版本的应用程序的新的的实例：

Or.. I can leave "fabric:/FooApp" alone, and create a new instance of my version 2.0 application:

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

现在我有两个应用程序，运行并排端，同一群集中。一个是1.0的情况下，另一种是在2.0的实例。随着港口和应用终端的一些配置，我可以保证用户仍然会在1.0实例时，我考出2.0实例。

Now I have two applications, running side-by-side, in the same cluster. One is an instance of 1.0, and the other is an instance of 2.0. With some configuring of ports and application endpoints, I can ensure users are still going to the 1.0 instance while I test out the 2.0 instance.

大，所以我所有的测试都通过了针对2.0实例，所以现在我可以放心地走1.0实例的升级的它FooType 2.0。再次，这是该实例的滚动升级（布：/ FooApp），它不是将用户迁移到新的实例（面料：/ FooAppv2Test）。后来我去删除面料：/ FooAppv2Test因为那是只是用于测试

Great, so all my tests pass against the 2.0 instance, so now I can safely take the 1.0 instance and upgrade it to 2.0 of FooType. Again, this is a rolling upgrade of that instance (fabric:/FooApp), it's not migrating users to the new instance (fabric:/FooAppv2Test). Later I'll go and delete fabric:/FooAppv2Test because that was just for testing.

一个蓝色/绿色的好处，虽然是能够，如果新的不换再换另一部署。好吧，你仍然有1.0和注册FooType 2.0。所以，如果你的应用程序开始从1.0​​升级到2.0后，行为不端，你可以升级回1.0！事实上，你可以升级只要你想尽可能多的不同版本的应用程序类型之间的应用程序实例！而你并不需要拥有的实例的运行就像你在一个交换环境下做的，你只需要注册不同的版本，并且能够版本之间的升级版的单一应用程序实例的所有应用程序版本。

One of the benefits of blue/green though is being able to swap back to the other deployment if the new one fails. Well, you still have both 1.0 and 2.0 of FooType registered. So if your application started misbehaving after the upgrade from 1.0 to 2.0, you can just "upgrade" it back to 1.0! In fact, you can "upgrade" an application instance between as many different versions of its application type as you want! And you don't need to have instances of all your application versions running like you do in a swapping environment, you just have the different versions registered and a single application instance that can "upgrade" between versions.

我提到有状态的服务注意事项。最重要的事情有状态的服务，记住的是，应用程序的状态 - 您的用户数据 - 包含在应用程序实例（布：/ FooApp），因此您的用户看到他们的数据，你需要让他们在该实例。这就是为什么我们的滚动升级，而不是部署互换。

I mentioned caveats with stateful services. The big thing to remember with stateful services is that the application state - your users' data - is contained in the application instance (fabric:/FooApp), so for your users to see their data you need to keep them on that instance. That's why we do rolling upgrades instead of deployment swaps.

这仅仅是基本的想法。还有其他的方法可以玩弄的应用程序类型，版本和实例，这取决于你的目标是什么以及如何应用程序的工作，但这是另一次。

This is just the basic idea. There are other ways you can play around with application types, versions, and instances depending on what your goals are and how your application works, but that's for another time.

这篇关于蓝/绿部署天青与ServiceFabric的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！