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

Question

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

我尝试使用应用程序网关来代替应用程序服务并在重写规则中编辑 URL。这部分有效，但不幸的是，它有一个已记录的错误，如果有许多 Set-Cookie 需要重写，它会重写第一个并删除其余的。因此，我们无法重写应用程序网关上的标头（直到 MS 修复错误），而必须将公共 URL 一直发送到后端应用程序服务，这就是为什么我们需要在应用程序服务上定义的自定义域本身。

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

Answer 1

我认为这更像是“严重限制的解决方法”，而不是真正的“答案”，因为尽管 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 中也有助于减少延迟，尽管我还没有证明这一点。