在 Azure 暂存槽中使用 ACS
我目前正在 Microsoft Azure 中实现一个 Web 应用程序。我关心的是如何将暂存槽与 ACS 一起使用。
我想将我的应用程序推送到暂存槽，验证它是否正常工作，然后将 VIP 交换到生产环境。
除了 ACS 的配置之外，该方法非常简单。由于暂存槽在部署期间获取随机 URL，因此需要在之后完成 ACS 配置。必须使用新的暂存槽 URL 配置 WebRole 的 web.config 和 ACS 中的依赖方应用程序。
Vittorio Bertocchi 在他的 博客文章 如何在不重新部署的情况下更新 web.config，我猜测在部署到暂存后可以使用脚本更新 ACS。
这种方法看起来相当复杂且脆弱；我正在为我的部署过程寻找一个简单而可靠的解决方案。我是否错过了什么？
由于 ACS 配置在生产槽中非常简单且直接，因此我一直在考虑跳过暂存槽中的应用程序测试，而仅使用它来执行 VIP 交换到生产环境（应用程序将在其自己的环境中进行测试） “QA”托管服务）。
您对这种方法有何看法？ Azure 中的托管服务之间有什么区别吗？
I am currently implementing a web application in Microsoft Azure. My concern is how to use the staging slot together with ACS.
I want to push my application to the staging slot, verify that it is working and then do a VIP-swap to production.
The approach is pretty straight forward, except the configuration of the ACS. Since the staging slot gets a random URL during deployment the ACS configuration needs to be done afterwards. The WebRole’s web.config and Relying Party Application in the ACS must be configured with the new staging slot URL.
Vittorio Bertocchi describes in his blog post how to update the web.config without redeploying and I guess that the ACS could be updated with a script after deployment to staging.
This approach seems quite complicated and brittle; I’m looking for a simple and solid solution for my deployment process. Is there something I have missed?
Since the ACS configuration is quite simple and straight forward in a production slot I have been thinking of skipping the testing of the application in the staging slot and only use it to perform the VIP-swap to production (the application would be tested in its own “QA” Hosted Service).
What do you think about this approach? Can there be any differences between hosted services in Azure?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
也许您的应用程序可以在重定向到 ACS 时以编程方式设置返回 URL。这会将用户在进行身份验证后重定向到暂存槽或生产槽。
这个问题向您展示了如何设置领域，但返回 URL 只是另一个参数： 一个IIS站点上的WIF跨域，动态设置realm
Perhaps your application could programmatically set the return URL when it redirects to the ACS. This would redirect the user to either the staging slot or the production slot after they authenticate.
This question shows you how to set the realm, but the return URL is just another parameter: WIF cross-domain on one IIS site, dynamically setting of realm
我通过创建一个名为“测试”的新云服务解决了这个问题。因此，当我将应用程序推送到暂存槽时，我还将另一个实例（具有不同的 web.config）推送到“测试”服务的生产槽。如果“测试”应用程序正常工作，那么我会删除测试应用程序并交换我的生产暂存槽。
这不是理想的解决方案，但它可能会解决您的问题。
I solved this by creating a new cloud service called "test". So, when I push my application to the staging slot, I also push another instance (with different web.config) to the production slot of my "test" service. If "test" application works properly, then I delete test app and swap my production-staging slots.
It is not the ideal solution, but it might solve your problem.
我只是使用主机文件条目来测试暂存实例。例如，假设您的服务托管在 myservice.cloudapp.net 中。您的暂存槽通常会获得类似 [guid].cloudapp.net 的 url，但它也会获得公共 VIP（您可以从服务的仪表板或通过执行 nslookup [guid].cloudapp.net 获得此信息）。您可以将主机文件条目添加为“[公共 VIP] myservice.cloudapp.net”。完成此操作后，您只需使用 myservice.cloudapp.net 即可创建临时实例，并且无需更改 ACS 配置。
I just use hosts file entries to test staging instances. For example, let us say your service is hosted in myservice.cloudapp.net. Your staging slot will typically get a url like [guid].cloudapp.net but it also gets a public VIP (you can get this from the service's dashboard or by doing an nslookup [guid].cloudapp.net). You can add a hosts file entry as "[Public VIP] myservice.cloudapp.net". Once you do this, you can your staging instance just by using myservice.cloudapp.net and ACS configuration need not be changed.