在Azure的云服务多租户应用程序分期 [英] Staging with a multi-tenant app in Azure Cloud Services

问题描述

我检讨分期云服务的以下文章：

I'm reviewing the following article on staging Cloud Services:

的http://www.windowsazure.com/en-us/develop/net/common-tasks/staging-deployment/

我试图定义应用程序更新的部署战略，它似乎像上面奇妙的作品非多租户应用程序。就我而言，我对VIP的依赖停留静态的，因为它是在我的A记录中使用，因为我需要支持通配符 - * .xyz.com> VIP。

I'm trying to define a deployment strategy for application updates and it seems like the above works wonderfully for non-multi-tenant apps. In my case, I have a dependency on the VIP staying static, as it is used in my A records because I need wildcard support - *.xyz.com > VIP.

还有什么其他的替代品在那里实现无缝的应用程序更新？或者 - 我应该使用通配符的CNAME呢？后者将引进更多的并发症我当前的DNS提供商（GoDaddy的）不支持通配符CNAME记录...所以Route53或者类似的东西，就必须使用。这里的任何指导将是非常美妙的。

What other alternatives are there to achieve seamless app updates? Or - should I be using wildcard CNAMEs instead? The latter will introduce more complications as my current DNS provider (GoDaddy) does not support wildcard CNAME records... so Route53 or something like that would have to be used. Any guidance here would be fantastic.

推荐答案

使用分段部署和VIP交换是有无缝更新的唯一支持的方法。

Using staging deployments and VIP swap is the only supported way to have seamless updates.

有时你会被建议作出就地升级 - 这是一个坏主意™因为一旦它开始和休息，至少你的一些情况下，你不能将它，所以你不能在生产中使用依赖它。是的，它可连续工作在测试环境中快速测试的变化，但它不是严肃的事。

Sometimes you will be advised to make in-place upgrades - that's a Bad Idea™ because once it starts and breaks at least some of your instances you can't revert it and so you cannot rely on it in production use. Yes, it can work for quickly testing changes in a testing environment but it's not for serious business.

是的，你必须使用CNAME，因为你的贵宾将在每个交换VIP重新部署更改。如果你觉得你需要通配符 - 你有两个选择 - 醚寻找供应商谁拥有它们或重新设计应用程序，以便不需要通配符

Yes, you have to use CNAME because your VIPs will change on each "swap VIP" redeployment. If you feel like you need wildcards - you have two options - ether find a provider who has them or redesign your application so that wildcards are not needed.

这篇关于在Azure的云服务多租户应用程序分期的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！