在 Devops 部署期间添加 Azure Web 应用服务自定义域答案

【问题标题】：Adding Azure Web App Service Custom Domain during Devops Deployment在 Devops 部署期间添加 Azure Web 应用服务自定义域
【发布时间】：2020-05-15 12:19:11
【问题描述】：

应用服务自定义域需要在部署时进行验证，这反过来又需要 DNS CNAME 指向新的应用服务名称。但是，应用服务名称是动态创建的，因此我们不知道它在部署时的名称。这个https://docs.microsoft.com/en-us/azure/app-service/manage-custom-dns-migrate-domain 几乎解决了这个问题，但它也需要您在部署之前知道应用服务名称。

我尝试使用应用网关代替坐在应用服务前面并在重写规则中编辑 URL。这部分有效，但不幸的是，它有一个记录在案的错误，如果要重写许多 Set-Cookie，它会重写第一个并删除其余的。因此，我们不能重写 App Gateway 上的标头（直到 MS 修复错误），而是必须将公共 URL 一直发送到后端 App Service，因此我们需要在 App Service 上定义自定义域自己。

问题是：如果在创建应用服务之前我不知道应用服务的名称，如何在使用 Azure Devops 进行部署时在应用服务上创建自定义域？

【问题讨论】：

无法获得您的最新信息，Simon 的解决方法对您有帮助吗？或者，如果您有任何疑问，请随时在此处分享。
嗨休。不，西蒙的建议不起作用。您能否确认 Azure Devops 和自定义域（在部署时选择了应用名称）不兼容？

标签： azure-devops azure-web-app-service

【解决方案1】：

我遇到了和你一样的问题，OP - 和你一样，如果有必要手动创建 DNS 记录，我觉得尝试通过管道应用自定义 DNS 配置完全没有意义。那么 CI/CD 的意义何在？！

我公司的 DNS 是通过 Cloudflare 运行的，所以我对这个问题的解决方案是……

在 Cloudflare 中创建一个 API 令牌，有权管理相关域的 DNS - 存储在 Azure Key Vault 中，并使用变量组注入管道（通过服务连接）
部署仅包含资源的初始 ARM 模板，包括应用服务，没有应用任何 DNS 配置
初始 ARM 模板声明网站名称、应用服务计划名称、自定义域验证 ID 以及管道中进一步需要的任何其他内容的输出变量
我编写了一个 PowerShell 脚本，它获取上一步的输出变量，并对 Cloudflare 进行 REST 调用以检查 CNAME 和 TXT 记录是否存在 - 如果不存在，则创建它们。如果有，请更新它们。（因为可能发生了一些变化！）
部署第二个 ARM 模板，该模板仅将自定义域配置应用于所需的任何应用服务

我目前的管道已经到了在 Cloudflare 中更新 DNS 的地步 - 我在第二个模板部署中出错，因为我忘记传递它的参数，呵呵。

这不是 100% 理想的，但它是一种可靠的解决方法，IMO，并且不需要手动步骤。当我完全完成它时，我会报告，如果你需要，我很乐意在那时分享代码 sn-ps。

编辑：这个解决方案似乎奏效了！我已经将我正在使用的应用程序部署到两个全新的环境中，这些环境根本没有配置资源，也没有预先存在的 DNS 条目。一切都很完美！

EDIT2：我应该提到，我为另一个项目第二次经历了这个过程 - 但我改用了 Terraform，这是一个更加流畅的体验！根本不需要弄乱 PowerShell 或嵌套部署！一切正常！ :)

【讨论】：

您好，感谢您的回复。上周我重新审视了它，因为它提升了优先级堆栈，事实上，我在上周末得到了一些工作，这与你所说的非常相似，但在一个管道中（我作弊了！）。我认为正确的做法是让我点击“回答您的问题”按钮并解释我在那里做了什么，所以我会这样做。
我应该提一下，我为另一个项目第二次经历了这个过程 - 但我改用了 Terraform，它的体验要顺畅得多！根本不需要弄乱 PowerShell 或嵌套部署！一切正常！ :)

【解决方案2】：

也许有几个选项，有ARM template support 或CLI command。这两者都可以分别使用 AzureResourceGroupDeployment@2 任务或 AzureCLI@2 任务从 Azure DevOps 自动化。

请注意，当您创建应用服务时，可以指定名称，只要它是唯一的（请参阅CLI ref 或first parameter in the ARM template）。

希望这会有所帮助！

【讨论】：

不幸的是，ARM 模板具有精确的约束，即它们需要在部署之前进行验证。我承认我没有尝试过 CLI（或者实际上直接使用 REST）。为了完整起见，我会尝试一下。
不，CLI 不起作用：“从 asuid.testhost.contoso.com 指向 57a84ad06c4860292aa5eec9a295b0fb60386cef4d3ead6a9c7a0669ab87d20e 的 TXT 记录未找到。替代 CNAME 记录 awverify.testhost.contoso.com to也找不到 azurewebsites.net。”
能否在创建时指定应用的名称？ ARM 模板的第一个参数是 webAppName。
管道本身会创建应用名称。一旦它被创建，我们就知道它的名字是什么（例如作为管道的输出）。到那时，为时已晚。好吧，除非我们手动创建 DNS 记录，然后手动添加自定义域，但这违背了 CD 管道的意义！仅当您预先定义应用名称时，您的建议才有效。但即便如此，您仍然必须在部署之前创建 DNS 条目，我仍然认为这是一个严重的遗漏，并且否定了 CD 的意义。
我个人认为在部署时间之前依赖一个已知的应用程序名称是可以的。如果不是，您可以在初始部署后使用 Azure CLI 以编程方式创建自定义域。不确定您使用的是哪个 DNS 提供商，但如果它类似于 CloudFlare，您也可以调用 API 来创建它。

【解决方案3】：

我认为这更像是“解决严重限制”而不是真正的“答案”，因为尽管 Microsoft 最近对验证过程进行了一些更改，但它们仍然需要验证，这与 CI/ CD 管道。我希望在未来，它们允许受信任的进程绕过域所有权验证。同时，作为一种解决方法，我们只是将 DNS 移至 Microsoft 自己 - 即 Azure DNS。 Azure DNS 满足我们的 HA 要求，但请注意，它（尚）不支持 DNSSec。完成后，我们修改了我们的管道：

部署应用服务（在我们的例子中通过 ARM 模板，但 CLI 就足够了）
通过 ARM 输出解析名称以从应用服务名称创建一个变量（在我们的例子中通过 bash 脚本）
在 Azure DNS 中创建单个 awverify CNAME 记录（使用 CLI）
添加 60 秒延迟任务
此时执行所有其他管道任务（我们有很多，所以它会占用时间）
将自定义域名添加到应用服务（使用 CLI）
上传并绑定 SSL 证书（再次使用 CLI）

在这种情况下，awverify 记录和自定义域名任务之间有足够的差距。我们已经多次运行这个管道并且没有失败（好吧，无论如何都不是这个原因！;-)），所以有可能降低 60 秒的延迟。我相信在 Azure DNS 中使用它也有助于减少延迟，尽管我还没有证明这一点。

【讨论】：