使用Azure Web /辅助角色时，用户可以指定osVersion来明确设置"Guest OS image" version。这可确保当Microsoft发布新的关键更新时，它们首先显示在较新的“操作系统映像”上，用户可以在其上明确指定和测试其服务。
Azure Service Fabric如何实现相同的目标？假设我将我的服务部署到Azure Service Fabric并且它已经运行了一个月，然后Microsoft在运行服务的服务器上发布操作系统的更新 - 它们是如何应用的，以便我可以先测试它们以确保它们不会打破服务？
答案 0 :(得分：4)
布雷特是对的。 SF群集基于Azure VMSS，并且期望客户负责修补操作系统。 https://azure.microsoft.com/en-us/documentation/articles/service-fabric-cluster-upgrade/
我们从大多数SF客户那里听说，这根本不可取，并且他们不想对操作系统修补负责。
启用OPT-IN自动操作系统修补的功能确实是Azure Compute团队中的一个非常重要的优先事项。关于如何最好地提供此功能的具体细节仍在设计中，但目的是在年底之前启用此功能。
尽管这是一个正确的长期解决方案，但为了在短期内缓解此问题，SF团队正在制定一系列步骤，使客户能够选择以安全的方式使用WU修补其VM。测试完步骤后，我们将对其进行博客，并发布详细说明步骤的文档。预计在接下来的几个月内。
答案 1 :(得分：3)
据我了解，您目前负责自行管理SF群集节点上的修补程序。显然，这是一个SF管理功能的计划，但我不知道它可能会走多远。
我个人会将此作为高度优先事项。使用云服务多年后，我已经开始依赖于永远不必手动修补我的VM。 SF是这一特定领域的一大倒退。
很高兴听到Azure PM的消息......
答案 2 :(得分：1)
自动基于映像的修补，如服务结构中的云服务。
今天你没有这个选择。基于映像的修补功能正在进行中。我发布了一个路线图，以便在团队博客上发布：https://blogs.msdn.microsoft.com/azureservicefabric/2017/01/09/os-patching-for-vms-running-service-fabric/试用脚本并报告您遇到的任何问题。期待您的反馈。
答案 3 :(得分：0)
Service Fabric的许多部分都是巨大的滚动垃圾箱向后发射。已经引入了全新的问题主机，IIS / WAS / WCF团队已经解决了需要再次开发的问题。在需要操作系统补丁管理的同时发布PAAS平台的概念是可笑的。为了增加对伤害的侮辱，没有来自经典云PAAS＆＃34;这个东西。我可以写自己的服务主持人。由WAS开箱十年提供的东西。并非所有人都害怕能够通过配置控制服务主机通信选项的所有方面。现在我们开始使用代码，因此调整通道配置需要完整的补丁/发布周期！