使用Azure Web/Worker角色时，用户可以指定osVersion以明确设置"Guest OS image" version。这确保了当Microsoft发布新的关键更新时，他们首先显示在一个更新的“操作系统映像”上，用户可以明确指定和测试其服务。使用Service Fabric时如何控制操作系统配置更改？
Azure服务结构如何实现？假设我将服务部署到了Azure服务结构中，并且它已运行了一个月，然后Microsoft在运行该服务的服务器上发布操作系统的更新 - 它们如何应用以便我可以先测试它们以确保它们不会打破服务？
布雷特是正确的。 SF集群基于Azure VMSS，期望客户负责修补操作系统。 https://azure.microsoft.com/en-us/documentation/articles/service-fabric-cluster-upgrade/
我们从大多数SF客户那里听说，这并非完全可取，并且他们不希望对操作系统补丁负责。
启用OPT-IN自动操作系统补丁的功能在Azure Compute团队中的确是非常高的优先级。关于如何最好地提供此功能的具体细节仍在设计中，但其目的是在年底之前启用此功能。
尽管这是一个正确的长期解决方案，但为了在短期内缓解这个问题，SF团队正在开展一系列步骤，使客户能够选择使用WU以安全方式修补其VM 。一旦这些步骤被测试完毕，我们将会发布关于它的博客并将发布详细说明步骤的文档。预计在接下来的几个月里。
这会像“客户操作系统映像”那样工作，还是会像“无论什么，补丁，我不在乎它是否破坏”？ – sharptooth
长期解决方案将类似于基于OS映像的Azure云服务“客户操作系统补丁”。 –
@ chacko-MSFT在为短期或特征记录过程方面有任何进展？ – Tim
据我了解，您目前负责自行管理SF集群节点上的修补程序。显然，将其转变为SF管理的功能是有计划的，但我不知道它可能走多远。
我个人会认为这是高优先级。使用云服务多年以来，我一直依赖于不必手动修补虚拟机。 SF在这一特定领域是一大步。
这将是一个很好的听到从这个Azure的PM ...
很多服务面料的部件都是巨大的滚动垃圾箱向后喷射。已经引入了全新的问题主机，IIS/WAS/WCF团队已经解决了需要再次开发的问题。在需要操作系统补丁管理的同时发布PAAS平台的概念是可笑的。为了增加侮辱伤害，没有从“经典云PAAS”到这个东西的迁移路径。 WEEEE我可以写我自己的服务主机。 WAS提供了十年开箱即用的东西。并非所有人都因能够通过配置来控制服务主机通信选项的所有方面而感到害怕。现在我们可以使用代码，因此调整通道配置需要完整的修补/发布周期！
自动映像基于修补，如服务结构中的云服务。
今天你没有那个选项。基于图像的修补功能正在进行中。我发布了一个路线图，以便在团队博客上获取：https://blogs.msdn.microsoft.com/azureservicefabric/2017/01/09/os-patching-for-vms-running-service-fabric/尝试一下脚本并报告您遇到的任何问题。期待您的反馈。
今天你没有这个选项。基于图像的修补功能正在进行中。我发布了一个路线图，以便在团队博客上访问：https：//blogs.msdn.microsoft.com/azureservicefabric/2017/01/09/os-patching-for-vms-running-service-fabric/尝试脚本并报告您遇到的任何问题。期待您的反馈。 –