使用 Azure 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 完全是关于滚动升级，而不是像 VIP 交换那样的部署交换.无状态和有状态服务的升级方式相同，但有状态还有一些额外的细微差别，我将在后面提到.

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.

通过滚动升级，我的意思是对应用程序进行升级，一次一个升级域，这样就不会出现停机和突然切换的情况.Service Fabric 中的滚动升级可以在安全的托管"模式下完成，在这种模式下，平台将在移动到下一个升级域之前执行运行状况检查，并在运行状况检查失败时自动回滚.

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?

这是应用程序类型和版本的用武之地.Service Fabric 没有可以容纳两个正在运行的应用程序的两个环境"，而是具有版本化应用程序类型的概念，可以从中创建应用程序实例.以下是其工作原理的示例:

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 的应用程序.我的 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:

我可以采用fabric:/FooApp"——FooType 1.0 的一个实例——并将其升级到 FooType 2.0.这将是正在运行的应用程序的滚动升级.

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.

或者..我可以不理会fabric:/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的实例.通过对端口和应用程序端点进行一些配置，我可以确保用户在我测试 2.0 实例时仍然使用 1.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.同样，这是该实例 (fabric:/FooApp) 的滚动升级，它不会将用户迁移到新实例 (fabric:/FooAppv2Test).稍后我会去删除fabric:/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.

blue/green 的一个好处是，如果新部署失败，可以切换回另一个部署.好吧，您仍然注册了 FooType 的 1.0 和 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.

我提到了有状态服务的注意事项.有状态服务要记住的重要事情是应用程序状态——您的用户数据——包含在应用程序实例 (fabric:/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.

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