Azure 蓝绿部署的挑战与经验

引言

在 AWS 上使用 OctopusDeploy 实现了蓝绿部署后，我最近有机会使用 Microsoft Azure 堆栈实现了类似的解决方案。在这种情况下，我们正在将 .NET 上的 Sitecore 8.2 部署到多个 Azure 区域，并进行自动化故障转移。

以下文章描述了一些高级方法和挑战。

注意预览版

Azure 的第一个挑战是许多功能仍处于预览状态。预览条款和条件不允许用于生产场景，并且基本不受支持。请务必查阅文档，因为 Azure 并不总是清楚哪些处于预览状态，哪些不是。

我们开始使用 Azure 规模集实现自动缩放，但遇到了许多可靠性问题。最后，我们转向了可用性组和固定数量的服务器。Azure 仍然允许您通过更新堆栈来缩放，但这更像是一个手动过程。令我惊讶的是 Azure 在此功能上落后了多少。AWS 在这方面具有优势，拥有一个成熟得多的解决方案，并且已经存在了多年。

当然，Azure 提供了完全托管的 WebApps 作为运行服务器的替代方案，类似于 AWS ElasticBeanStalk。不幸的是，它目前不适合 Sitecore 等产品，但脱离托管服务器的趋势正在迅速到来。

只能有一个

需要注意的一点是，Azure 正在迁移其旧版 Web 门户和新版门户。同样，PowerShell Cmdlets 正在从旧版 API 迁移到新的 AzureRM API。如果您不知道自己使用的是哪种，所有 AzureRM Cmdlets 都以 AzureRM 为前缀。在模式之间切换的旧机制已消失。

每组 Cmdlets 都有不同的身份验证实现，在进行自动化时，您永远不应混合搭配。使用以 AzureRM 为前缀的 Cmdlets 非常重要，否则您将遇到问题，尤其是我发现 SQL Azure 方面的问题。在混合 API 时，SQL Azure 经常会卡住，无法识别已删除的数据库实际上已被删除。一个 Cmdlets 集会报告数据库存在，另一个则会争辩说它已被删除。

AzureRM 是未来，旧版 API 正在被淘汰。AzureRM API 存在一些差距，但它们正在迅速赶上，并且大多数事情都是可能的。寻找文档通常是最具挑战性的。

应用程序而非用户

Azure 中的身份验证是一团糟，尤其是在 PowerShell 中。同一个电子邮件地址可以与一个组织或一个 live 帐户相关联。这允许您通过门户使用相同的电子邮件登录完全不同的帐户，但 Azure PowerShell 在这些情况下并不那么智能或有帮助。旧版 Azure PowerShell 和 AzureRM 根据您使用的帐户类型以及是否允许您从 PowerShell 进行身份验证而表现不同。您并不总能使用所需的凭据进行身份验证，错误会让您一无所获。您可能会想把电脑扔出窗外。忍住。还是有希望的。

Live 帐户无法通过 PowerShell 与 AzureRM 一起使用，但与组织关联的帐户可以。大多数文档建议下载并使用 PublishSettingsFile。这是一个旧版解决方案，它会在本地计算机上安装一个证书，并允许您使用您的帐户向 Azure 进行身份验证。它还包含大量与您的帐户相关的敏感凭据信息，因此不适合检入源代码管理或随意放在服务器上。我发现这在自动化方面效果不佳，并且我不想在自动化过程中到处使用我的凭据。然而，您咨询的客户不太可能给您一个组织帐户，因此在 AzureRM 自动化方面这可能是一个问题。

相反，我发现可以使用具有公用/专用令牌的 AD 应用程序进行设置，并使用它从 PowerShell 向 AzureRM 进行身份验证。这绕过了对组织服务帐户的需求，并且工作正常。请注意，这不适用于旧版 Azure PowerShell Cmdlets，因此您必须承诺在所有地方都使用 AzureRM。是的，有时这很痛苦！

设置 AD 应用程序允许您像在 PowerShell 中使用用户名/密码一样进行身份验证。密码是临时的，最多可使用 2 年。它不与个人帐户关联，因此非常适合自动化。我使用 PowerShell SecureString 加密来保护应用程序密码并将其保存在源代码管理中。稍后会详细介绍。

设置 AD 应用程序

• 在旧版 Azure 门户中导航到 Active Directory
• 选择与您的订阅关联的 AD
• 选择应用程序并选择添加
• 提供一个名称，并勾选“Web 应用程序和/或 Web API”
• 为“登录 URL”和“应用程序 ID URL”添加任何唯一的 URI
• 创建后，单击配置
• “客户端 ID”是用作身份验证的服务用户名
• 在密钥下创建一个新密钥，并将长度设置为 2 年
• 显示的密钥是用于身份验证的服务密码
• 在新 Azure 门户中，您现在可以选择您的命名应用程序并分配权限

要在 PowerShell 中对 AzureRM 进行身份验证，请按以下方式使用上述凭据

$password = ConvertTo-SecureString -String $servicePassword -AsPlainText -Force
$credential = New-Object -TypeName System.Management.Automation.PSCredential `
                         -ArgumentList $serviceUserName, $password

Login-AzureRmAccount -Credential $credential `
                         -SubscriptionId $subscriptionId `
                         -TenantId $tenantId `
                         -ServicePrincipal

注意：订阅和租户是可选的，但如果未指定，您可能会在多租户和多订阅帐户中遇到问题。您不会知道原因。

放牧牛群

如果您信奉“牛群而非宠物”的理念，那么您应该考虑对您的环境堆栈进行脚本化并妥善组织。ResourceGroups 用于此目的，相当于 AWS 中的 Stacks。

Azure 中的模板类似于 AWS CloudFormation 模板，采用声明性的 JSON 格式。文档很糟糕，主要在Github上通过示例进行描述。您也可以直接从门户本身反向工程模板，但需要对其进行重构。不过，这是一个学习的好方法。

与 AWS 一样，自动化配置的最佳方法是向 API 传递模板和参数（应答文件）。您还可以传递可以与 ResourceGroups 关联的键/值标记。您还可以将标记分配给模板内的各个资源。标记可用于将变量传递给在服务器上运行的配置脚本。例如，它们可用于在自动化安装期间将 OctopusDeploy Tentacle 绑定到特定的环境名称。标记不应用于传递秘密。

Create-AzureResourceGroup -infrastructureTemplate $infrastructureTemplate `
    -templateParams $paramsFilePath `
    -resourceGroupName $resourceGroupName `
    -rgRegion $location `
    -tags @{Name="environment";Value=$Environment}

调试模板错误很困难，但 JSON 中有一些可以传递的冗长输出。通常更容易在门户的“部署”选项卡下查看错误的详细信息。

如果配置失败，以下是一种在 try/catch 块中记录更好错误消息的粗略方法

(Get-AzureRmLog -Status Failed -ResourceGroup $resourceGroupName -DetailedOutput).Properties `
                         | ?{ $_.Content -and $_.Content["statusMessage"] } `
                         | %{ $_.Content["statusMessage"] } | Select-object -first 1

蓝绿酱

一旦您将基础设施视为代码，通过实现 AzureRM 模板并自动化所有内容，您就拥有了牛群而非宠物。然后，实现蓝绿部署会变得更容易，并且是实现零停机发布的好方法。它允许您安全地滚动推出代码、内容甚至基础设施的更改。

蓝绿部署涉及启动一个副本环境，然后将整个堆栈切换到生产环境，通常是通过 DNS 更改。由于 DNS 在整个网络和设备上被大量缓存，因此当它部署在 CDN 后面时效果最好。使用 CDN 时，面向公众的 DNS 保持不变，只有源 DNS 记录在后台进行切换。因此，切换是无缝的，因为 CDN 像浏览器一样擅长遵守 TTL。请记住，在上线时也要自动化清除 CDN 缓存。

Azure 正在开发Azure DNS，以提供一个可脚本化的 DNS 解决方案，类似于 AWS 上的 Route53。一旦该解决方案摆脱预览状态，它将为在 Azure 上实现蓝绿部署提供改进的方法。在此期间，有 TrafficManager。TrafficManager 是一个基于 DNS 的解决方案，允许您将流量路由到不同的终结点。在这种情况下，它允许在部署期间更改蓝或绿环境之间的路由。

要使用 TrafficManager 实现蓝绿部署，请设置 2 个 TrafficManager 实例来代表生产和预生产。在每个 TrafficManager 实例中，设置 2 个终结点，然后使用外部终结点选项，该选项允许您将流量路由到给定的 URL。将一个终结点指向您的蓝堆栈，另一个指向绿堆栈。在选择为生产环境的 TrafficManager 上，禁用蓝终结点，使绿成为生产环境。在预生产 TrafficManager 上，禁用绿终结点，使蓝成为预生产环境。

接下来，创建一个 PowerShell 脚本来自动化切换启用的/禁用的终结点状态设置。该脚本应更新两个 TrafficManager 并同步两个 TrafficManager 之间的配置。最好创建一个实用 PowerShell 函数来查找当前的生产或预生产颜色。这可以用于在不使用预生产环境时自动化拆除预生产环境，或在定位部署时使用。它避免了人为错误，并将当前的蓝绿状态作为单一事实来源。

这只是实现蓝绿部署的冰山一角。在蓝绿部署期间旋转整个堆栈非常重要，包括数据库和内容。这其中有许多超出本文范围的挑战，但如果做得好，可以实现无缝上线和回滚能力。如果您在蓝绿部署期间修改了生产数据，那么您就做错了。

失败的信心

复杂的灾难恢复计划和备用服务器的日子已经一去不复返了。如果您像对待牛群一样对待您的基础设施，并遵守将基础设施视为代码的良好实践，那么就没什么可担心的了。当然，妥善保管您的资产并保持数据冗余仍然至关重要，但尽可能多地将其保存在源代码管理中。黄金法则是永远不要手动登录服务器并配置任何东西！一旦完成艰苦的工作，扩展到多个数据中心就很容易了。最简单的方法就是更改脚本中的变量。

Azure 提供了一些出色的 SQL 复制功能，可以将您的数据推送到世界各地作为只读副本。所有这些都可以通过 PowerShell 进行自动化，并集成到您的部署序列中。我们使用 SQL Azure 复制在世界各地的其他位置启动 Sitecore 交付实例，并在所有实例中实现蓝绿部署。

当您拥有多个数据中心时，可以使用第二个 TrafficManagers 来在位置之间自动故障转移，如果一个位置的健康检查失败。这可以通过具有优先级模式的 TrafficManager 来实现。或者，在 TrafficManager 中使用性能模式，将流量自动路由到离用户最近的数据中心。同样，如果一个位置变得不健康，它将自动将流量重定向到下一个健康的 location。当使用优先级模式时，您可以始终将最低优先级的终结点设置为回退到静态占位页。

蛋糕是谎言

Azure 自动化存在的问题之一是它往往会欺骗您。不是开玩笑。谎言。

某个项可能会报告为已删除，但它不会立即允许您创建具有相同名称的新项。它会告诉您资源已存在。事实上，我仍然不知道在删除项后多久才能用相同的名称重新配置它。我通常会等待 5-10 分钟，否则它会抱怨。

这种行为可能会给自动化脚本带来问题，如果您频繁地拆除和重新配置资源。SQL Azure 似乎是服务器名称的最大问题。对于数据库来说，这通常没问题，所以除了测试我们的模板之外，这并不是一个主要问题。

伸出援手

Azure 负载均衡器的一个好处是所有出站流量将源自负载均衡器的 IP 地址，而不是单个服务器的 IP 地址。这可以简化服务之间的防火墙规则设置，并且在需要利用 IP 限制时很有用。

当使用监听模式下的 OctopusDeploy Tentacles 时，我建议在负载均衡器上使用 NAT 规则。为每个服务器设置唯一的端口 NAT 路由允许 OctopusDeploy 服务器连接到每个服务器。您还需要允许 OctopusDeploy 服务器 IP 访问这些端口。防火墙规则都可以通过 PowerShell 配置或集成到模板中进行自动化。我们在配置过程中动态查找 Octopus 服务器 IP 地址，并为当前服务器添加特定的防火墙规则。

伙计，我的数据在哪儿

任何涉及数据库的可重复部署过程的一个关键部分是重置初始状态以避免数据污染。对于 Sitecore，我们需要在每次部署开始时将所有内容数据库重置为生产环境的最新副本。

有两种方法可以自动化这一点。要么通过脚本备份/恢复数据库，要么使用 Azure 数据库复制功能。我们发现 Azure 数据库复制速度更快，而备份/恢复则相当脆弱。

在我们的案例中，我们将生产和非生产环境分开到 2 个订阅中，以增强安全性。不幸的是，数据库复制在订阅之间不起作用。为了最大限度地缩短部署时间，我们设置了计划任务，在夜间将生产数据库备份/恢复到非生产订阅中的备用服务器。然后，我们在所有测试环境部署中使用数据库复制。对于生产部署，我们直接使用生产环境复制。

摘要

Azure 并非没有挑战，并且在许多方面与 AWS 相比成熟度较低。然而，它正在大幅改进其云服务，并推出了许多功能。一旦这些功能摆脱预览状态，Azure 将在云服务器产品方面更好地与 AWS 并驾齐驱，并提供更好的自动缩放和自我修复支持。

在 Azure 和 AWS 上实现了相同的概念部署管道后，令人欣慰的是，持续交付的原则可以应用于任何地方并保持有效。自动化是关键，但有时最大的挑战是实现供应商 API 的稳定性和可重复性。准备好构建重试机制以处理意外的故障。

成功实现后，持续交付和一键式部署会带来巨大的满足感。其回报是低风险和高上市速度。然而，要达到成熟还需要大量投资。