【发布时间】：2014-01-01 01:01:31
【问题描述】：
How is VIP swapping + CNAMEs better than IP swapping + A records?
作为上述内容的延续 - 由于 issues I'm having 在 Azure 中使用 CNAME，我非常接近恢复到 A 记录。
来自Azure docs，声明：
但是请注意，因为 IP 地址的生命周期是相关联的 对于部署，重要的是不要删除您的部署，如果 您需要 IP 地址才能保留。方便的是，一个IP地址 给定的部署槽（生产或登台）在使用时保持不变 Windows Azure 中的两种升级机制：VIP 交换和就地 升级。
我有myapp.cloudapp.net，当前指向1.1.1.1 的VIP。如果我想将我的应用程序的一个版本部署到 Staging，我将使用我的应用程序启动 Staging 插槽，进行一些测试，然后通过 VIP 交换进行无缝升级。应用程序现在将使用2.2.2.2 - 尽管此时我再次进行 DNS 查找，myapp.cloudapp.net 的 A 记录仍将指向 1.1.1.1，因为 VIP 交换对 DNS 没有影响，对吧？
如果是这样，那么当我终止暂存部署以节省成本时会发生什么？ 1.1.1.1 和 2.2.2.2 都会保留给我的服务吗？我希望如此，因为这意味着我的 A 记录可以一直指向 1.1.1.1，通过分段部署依赖它，而不必担心 CNAME 的麻烦。但这意味着this answer 不正确。
如果不是，那么这意味着 VIP 交换确实对 DNS 记录有影响，对吗？否则，我可以这样做：
- 1.1.1.1 > 2.2.2.2，丢弃暂存，1.1.1.1 被回收
- 再次启动 staging，2.2.2.2 > 3.3.3.3，但 DNS A 记录仍指向 myapp.cloudapp.net 的 1.1.1.1。
最后一点没有任何意义，所以要么 DNS 记录 得到更新，要么 3.3.3.3 永远不会出现，并且 1.1.1.1 和 2.2.2.2 总是在一起，因为只要我的云服务没有被删除。
我对这件事感到非常困惑 - 任何指导都会很棒。
更新 - 我刚刚测试了以下内容：
CHECK DNS - get 1.1.1.1
READ PROD - get 1.1.1.1
DEPLOY STAGING
READ STAGING - get 2.2.2.2
VIP SWAP
READ PROD - get 1.1.1.1
READ STAGING - get 2.2.2.2
CHECK DNS - get 1.1.1.1
KILL STAGING DEPLOYMENT
READ PROD - get 1.1.1.1
看来可以使用A记录 - 即使在登台/生产之间切换时，PROD VIP 保持不变，但部署会被交换。删除 staging 并重新部署 staging 会获得一个新的辅助 VIP，但主要 VIP 确实保持不变。我会等到比我更可靠的人可以在这里插话，然后再将其发布为答案。
【问题讨论】：
-
哎哟。这看起来像是新行为。是的，我现在可以重现它。
标签： azure dns azure-web-roles