我目前正在Microsoft Azure中实现一个Web应用程序 . 我关心的是如何与ACS一起使用临时插槽 .
我想将我的应用程序推送到临时插槽，验证它是否正常工作然后进行 生产环境 的VIP交换 .
除了ACS的配置外，该方法非常简单 . 由于临时插槽在部署期间获得随机URL，因此需要在之后执行ACS配置 . 必须使用新的临时插槽URL配置ACS中的WebRole的web.config和依赖方应用程序 .
Vittorio Bertocchi在他的blog post中描述了如何在不重新部署的情况下更新web.config，我想在部署到登台后可以用脚本更新ACS .
这种方法看起来相当复杂和脆弱;我正在为我的部署过程寻找一个简单而可靠的解决方案 . 有没有我错过的东西？
由于ACS配置在 生产环境 插槽中非常简单和直接，我一直在考虑在暂存插槽中跳过应用程序的测试，并且只使用它来执行VIP交换到 生产环境 （应用程序将在其自己的测试中进行测试“QA”托管服务） .
您如何看待这种方法？ Azure中的托管服务之间是否存在任何差异？
3 回答
也许您的应用程序可以在重定向到ACS时以编程方式设置返回URL . 这会在用户进行身份验证后将用户重定向到暂存插槽或 生产环境 槽 .
此问题向您展示如何设置领域，但返回URL只是另一个参数：WIF cross-domain on one IIS site, dynamically setting of realm
我通过创建一个名为“test”的新 Cloud 服务解决了这个问题 . 因此，当我将应用程序推送到临时插槽时，我还将另一个实例（使用不同的web.config）推送到我的“test”服务的 生产环境 槽中 . 如果“test”应用程序正常工作，那么我删除测试应用程序并交换我的 生产环境 阶段插槽 .
它不是理想的解决方案，但它可以解决您的问题 .
我只是使用hosts文件条目来测试登台实例 . 例如，假设您的服务托管在myservice.cloudapp.net中 . 您的临时插槽通常会获得类似[guid] .cloudapp.net的网址，但它也会获得公共VIP（您可以从服务的信息中心或通过执行nslookup [guid] .cloudapp.net获取此信息） . 您可以将主机文件条目添加为“[Public VIP] myservice.cloudapp.net” . 完成此操作后，您只需使用myservice.cloudapp.net即可暂存实例，并且无需更改ACS配置 .