Azure 虚拟机和规模集的自动来宾修补

项目
08/20/2024

适用于：✔️ Linux VM ✔️ Windows VM ✔️ 灵活规模集

为 Azure 虚拟机 (VM) 和规模集 (VMSS) 启用自动来宾修补有助于通过安全自动修补虚拟机来简化更新管理，使虚拟机保持安全合规，同时限制 VM 的冲击半径。

自动 VM 来宾修补具有以下特征：

在 VM 上自动下载并应用已分类为“关键”或“安全”的补丁。
在 VM 所在时区的非高峰期为 IaaS VM 应用补丁。
在所有时段为 VMSS Flex 应用补丁。
Azure 管理补丁业务流程，并遵循可用性优先原则。
监视虚拟机运行状况（通过平台运行状况信号来确定），以检测修补失败的情况。
可以通过应用程序运行状况扩展监视应用程序运行状况。
适用于所有大小的 VM。

自动 VM 来宾修补的工作原理是什么？

如果在某个 VM 上启用了自动 VM 来宾修补，则会在该 VM 上自动下载并应用可用的关键补丁和安全补丁。在每个月发布新的补丁时，此过程将自动启动。补丁评估和安装是自动的，该过程会根据配置重新启动 VM。 VM 模型上的 rebootSetting 参数优先于其他系统中的设置，例如维护配置。

VM 每隔数天定期评估，并在任意 30 天周期内多次评估，以确定适用于该 VM 的补丁。可在任何一天的 VM 非高峰期将补丁安装到 VM 上。这种自动评估确保能够尽早发现任何缺失的补丁。

在发布每月补丁后的 30 天内，将按照可用性优先业务流程安装补丁。只会根据 VM 的时区在 VM 的非高峰期安装补丁。 VM 在非高峰期必须正在运行，才能自动安装补丁。如果 VM 在定期评估期间已关闭，则会自动评估平台，并在 VM 打开后的下一次定期评估（通常在几天内）期间应用补丁（如需要）。

定义更新以及未分类为“关键”或“安全”的其他补丁不会通过自动 VM 来宾修补予以安装。若要安装属于其他分类的补丁或者要计划在你自己的自定义维护时段内安装补丁，可以使用更新管理。

通过在灵活业务流程模式下在单实例 VM 或虚拟机规模集上启用自动来宾修补，Azure 平台可以分阶段更新舰队。分阶段部署遵循 Azure 的安全部署做法，在发现最新更新出现任何问题时可以降低影响半径。建议对单个实例 VM 进行运行状况监视，并且要求对灵活业务流程模式下的虚拟机规模集进行运行状况监视，以检测与更新相关的任何问题。

可用性优先更新

Azure 跨已启用自动来宾修补的 VM 的所有公有云和私有云协调修补程序安装过程。该业务流程根据 Azure 提供的不同可用性级别，遵循可用性优先原则。

对于正在更新的一组虚拟机，Azure 平台将协调更新：

跨区域：

按照分阶段的方式在整个 Azure 中全局协调每月更新，以防全局部署失败。
一个阶段可以涵盖一个或多个区域，仅当某个阶段中符合条件的 VM 成功更新时，更新才会进入下一阶段。
地理配对的区域不会并发更新，因此它们不能处于同一区域阶段。
更新是否成功是通过跟踪 VM 在更新后的运行状况来衡量的。 VM 运行状况是通过 VM 的平台运行状况指示器跟踪的。

在区域内部：

位于不同 Azure 可用性区域中的 VM 不会使用同一更新并发更新。
不在可用性集内的 VM 将按照尽力运行的原则进行批处理，以避免对订阅中的所有 VM 进行并发更新。

在可用性集内部：

公用可用性集中的所有 VM 不会并发更新。
公用可用性集中的 VM 在更新域边界内更新，跨多个更新域的 VM 不会并发更新。
在更新域中，每次最多会更新可用性集中 20% 的 VM。对于 VM 少于 10 个的可用性集，每次会在更新域中更新一个 VM。

限制跨区域、区域内或可用性集内并发修补的 VM 数量，可限制有故障的修补对给定 VM 集的影响。通过运行状况监视，任何潜在问题都会在影响整个工作负载之前被标记出来。

给定 VM 的补丁安装日期在不同的月份都有可能不同，因为特定 VM 可能是在每月修补周期的不同批次中选取的。

安装哪些补丁？

安装的补丁取决于 VM 的推出阶段。每个月都会启动新的全局推出，此时将为单个 VM 安装已针对该 VM 评估过的所有安全补丁和关键补丁。分批跨所有 Azure 区域协调推出。

要安装的具体补丁集因 VM 配置（包括 OS 类型和评估时间）而异。如果当补丁业务流程在不同时间转到不同区域时可用的补丁较多或较少，则有可能会在不同区域中的两个相同 VM 上安装不同的补丁。类似地，位于同一区域中的、但在不同时间评估（由于可用性区域或可用性集的批次不同）VM 上可能会安装不同的补丁，但这种情况更少见。

由于自动 VM 来宾修补不会配置补丁源，因此，配置为使用不同补丁源（例如公共存储库与专用存储库）的两个类似 VM 上安装的具体补丁集也可能不同。

对于按固定节奏发布补丁的 OS 类型，配置为使用公共 OS 存储库的 VM 预期会在一个月内的不同推出阶段收到相同的补丁集。例如，配置为使用公共 Windows 更新存储库的 Windows VM。

由于每个月都会触发新的推出，如果 VM 在非高峰期处于开机状态，则 VM 在每个月至少会收到一个补丁推出。这可以确保每个月都会使用最新可用的安全补丁和关键补丁来修补 VM。若要确保安装的补丁集一致，可以配置 VM 以从你自己的专用存储库评估并下载补丁。

支持的 OS 映像

重要

自动 VM 来宾修补、按需修补程序评估和按需修补程序安装仅在从映像创建的 VM 上受支持，此类映像具有下面受支持操作系统映像列表中发布者、报价和 SKU 的确切组合。不支持自定义图像或任何其他发布者、报价以及 SKU 组合。更多的映像会定期添加进来。列表中看不到你的 SKU？通过提交映像支持请求来请求支持。

发布者	OS 产品/服务	SKU
Canonical	UbuntuServer	16.04-LTS
Canonical	UbuntuServer	16.04.0-LTS
Canonical	UbuntuServer	18.04-LTS
Canonical	UbuntuServer	18.04-LTS-gen2
Canonical	0001-com-ubuntu-pro-bionic	pro-18_04-lts
Canonical	0001-com-ubuntu-server-focal	20_04-lts
Canonical	0001-com-ubuntu-server-focal	20_04-lts-gen2
Canonical	0001-com-ubuntu-pro-focal	pro-20_04-lts
Canonical	0001-com-ubuntu-pro-focal	pro-20_04-lts-gen2
Canonical	0001-com-ubuntu-server-jammy	22_04-lts
Canonical	0001-com-ubuntu-server-jammy	22_04-lts-gen2
microsoftcblmariner	cbl-mariner	cbl-mariner-1
microsoftcblmariner	cbl-mariner	1-gen2
microsoftcblmariner	cbl-mariner	cbl-mariner-2
microsoftcblmariner	cbl-mariner	cbl-mariner-2-gen2
Redhat	RHEL	7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.8, 7_9, 7-RAW, 7-LVM
Redhat	RHEL	8、8.1、81gen2、8.2、82gen2、8_3、83-gen2、8_4、84-gen2、8_5、85-gen2、8_6、86-gen2、8_7、8_8、8-lvm、8-lvm-gen2
Redhat	RHEL	9_0、9_1、9-lvm、9-lvm-gen2
Redhat	RHEL-RAW	8-raw、8-raw-gen2
SUSE	sles-12-sp5	gen1,gen2
SUSE	sles-15-sp2	gen1,gen2
MicrosoftWindowsServer	WindowsServer	2008-R2-SP1
MicrosoftWindowsServer	WindowsServer	2012-R2-Datacenter
MicrosoftWindowsServer	WindowsServer	2012-R2-Datacenter-gensecond
MicrosoftWindowsServer	WindowsServer	2012-R2-Datacenter-smalldisk
MicrosoftWindowsServer	WindowsServer	2012-R2-Datacenter-smalldisk-g2
MicrosoftWindowsServer	WindowsServer	2016-Datacenter
MicrosoftWindowsServer	WindowsServer	2016-datacenter-gensecond
MicrosoftWindowsServer	WindowsServer	2016-Datacenter-Server-Core
MicrosoftWindowsServer	WindowsServer	2016-datacenter-smalldisk
MicrosoftWindowsServer	WindowsServer	2016-datacenter-with-containers
MicrosoftWindowsServer	WindowsServer	2019-Datacenter
MicrosoftWindowsServer	WindowsServer	2019-Datacenter-Core
MicrosoftWindowsServer	WindowsServer	2019-datacenter-gensecond
MicrosoftWindowsServer	WindowsServer	2019-datacenter-smalldisk
MicrosoftWindowsServer	WindowsServer	2019-datacenter-smalldisk-g2
MicrosoftWindowsServer	WindowsServer	2019-datacenter-with-containers
MicrosoftWindowsServer	WindowsServer	2022-datacenter
MicrosoftWindowsServer	WindowsServer	2022-datacenter-smalldisk
MicrosoftWindowsServer	WindowsServer	2022-datacenter-smalldisk-g2
MicrosoftWindowsServer	WindowsServer	2022-datacenter-g2
MicrosoftWindowsServer	WindowsServer	2022-datacenter-core
MicrosoftWindowsServer	WindowsServer	2022-datacenter-core-g2
MicrosoftWindowsServer	WindowsServer	2022-datacenter-azure-edition
MicrosoftWindowsServer	WindowsServer	2022-datacenter-azure-edition-core
MicrosoftWindowsServer	WindowsServer	2022-datacenter-azure-edition-core-smalldisk
MicrosoftWindowsServer	WindowsServer	2022-datacenter-azure-edition-smalldisk

补丁业务流程模式

Azure 上的 VM 现在支持以下补丁业务流程模式：

AutomaticByPlatform（Azure 编排的修补）：

Linux 和 Windows VM 都支持此模式。
此模式为虚拟机启用自动 VM 来宾修补，后续的补丁安装将由 Azure 协调。
在安装过程中，此模式将评估 VM 是否有可用补丁，并将详细信息保存在 Azure Resource Graph 中。
可用性优先修补需要此模式。
只有使用上述受支持 OS 平台映像创建的 VM 才支持此模式。
对于 Windows VM，设置此模式还会禁用 Windows 虚拟机上的本机自动更新，以避免重复。
若要在 Linux VM 上使用此模式，请在 VM 模板中设置属性 osProfile.linuxConfiguration.patchSettings.patchMode=AutomaticByPlatform。
若要在 Windows VM 上使用此模式，请在 VM 模板中设置属性 osProfile.windowsConfiguration.patchSettings.patchMode=AutomaticByPlatform。
启用此模式会将注册表项 SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\NoAutoUpdate 设置为 1

AutomaticByOS：

只有 Windows VM 支持此模式。
此模式在 Windows 虚拟机上启用自动更新，将通过自动更新在 VM 上安装补丁。
此模式不支持可用性优先修补。
如果未为 Windows VM 指定其他修补模式，则默认会设置此模式。
若要在 Windows VM 上使用此模式，请设置属性 osProfile.windowsConfiguration.enableAutomaticUpdates=true，并在 VM 模板中设置属性 osProfile.windowsConfiguration.patchSettings.patchMode=AutomaticByOS。
启用此模式会将注册表项 SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\NoAutoUpdate 设置为 0

手动：

只有 Windows VM 支持此模式。
此模式会在 Windows 虚拟机上禁用自动更新。使用 CLI 或 PowerShell 部署 VM 时，将 --enable-auto-updates 设置为 false 也会将 patchMode 设置为 manual，并禁用自动更新。
此模式不支持可用性优先修补。
使用自定义修补解决方案时应设置此模式。
若要在 Windows VM 上使用此模式，请设置属性 osProfile.windowsConfiguration.enableAutomaticUpdates=false，并在 VM 模板中设置属性 osProfile.windowsConfiguration.patchSettings.patchMode=Manual。
启用此模式会将注册表项 SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\NoAutoUpdate 设置为 1

ImageDefault：

只有 Linux VM 支持此模式。
此模式不支持可用性优先修补。
此模式遵循用于创建 VM 的映像中的默认修补配置。
如果未为 Linux VM 指定其他修补模式，则默认会设置此模式。
若要在 Linux VM 上使用此模式，请在 VM 模板中设置属性 osProfile.linuxConfiguration.patchSettings.patchMode=ImageDefault。

注意

对于 Windows VM，只能在首次创建 VM 时设置属性 osProfile.windowsConfiguration.enableAutomaticUpdates。这会影响某些修补模式转换。若 VM 具备 osProfile.windowsConfiguration.enableAutomaticUpdates=false，则支持在 AutomaticByPlatform 模式和手动模式之间进行切换。若 VM 具备 osProfile.windowsConfiguration.enableAutomaticUpdates=true，则支持在 AutomaticByPlatform 模式和 AutomaticByOS 模式之间进行类似切换。不支持在 AutomaticByOS 模式和手动模式之间进行切换。 Azure 建议在 VM 上启用评估模式，即使未启用 Azure 业务流程进行修补也是如此。这将允许平台每 24 小时评估 VM 是否有任何待处理的更新，并将详细信息保存在 Azure Resource Graph 中。应用或确认计算机所需的补丁配置状态时，平台会执行评估来报告合并结果。这将报告为“平台”发起的评估。

启用自动 VM 来宾修补的要求

虚拟机上必须装有适用于 Windows 或 Linux 的 Azure VM 代理。
对于 Linux VM，Azure Linux 代理的版本必须是 2.2.53.1 或更高。如果当前版本低于所需的版本，请更新 Linux 代理。
对于 Windows VM，Windows 更新服务必须在虚拟机上运行。
虚拟机必须能够访问配置的更新终结点。如果虚拟机配置为使用适用于 Linux 的专用存储库或适用于 Windows VM 的 Windows Server Update Services (WSUS)，则相关的更新终结点必须可访问。
使用计算 API 版本 2021-03-01 或更高版本来访问包括按需评估和按需修补在内的所有功能。
目前不支持自定义映像。
VMSS 灵活业务流程需要安装应用程序运行状况扩展。对于 IaaS VM，这是可选的。

启用自动 VM 来宾修补

在由可支持的平台映像创建的任何 Windows 或 Linux VM 上，可启用自动 VM 来宾修补。

适用于 Linux VM 的 REST API

以下示例说明如何启用自动 VM 来宾修补：

PUT on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVirtualMachine?api-version=2020-12-01`

{
  "location": "<location>",
  "properties": {
    "osProfile": {
      "linuxConfiguration": {
        "provisionVMAgent": true,
        "patchSettings": {
          "patchMode": "AutomaticByPlatform"
        }
      }
    }
  }
}

适用于 Windows VM 的 REST API

以下示例说明如何启用自动 VM 来宾修补：

PUT on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVirtualMachine?api-version=2020-12-01`

{
  "location": "<location>",
  "properties": {
    "osProfile": {
      "windowsConfiguration": {
        "provisionVMAgent": true,
        "enableAutomaticUpdates": true,
        "patchSettings": {
          "patchMode": "AutomaticByPlatform"
        }
      }
    }
  }
}

创建 Windows VM 时使用的 Azure PowerShell

创建 VM 时，可使用 Set-AzVMOperatingSystem cmdlet 来启用自动化 VM 来宾修补。

Set-AzVMOperatingSystem -VM $VirtualMachine -Windows -ComputerName $ComputerName -Credential $Credential -ProvisionVMAgent -EnableAutoUpdate -PatchMode "AutomaticByPlatform"

更新 Windows VM 时使用的 Azure PowerShell

可以使用 Set-AzVMOperatingSystem 和 Update-AzVM cmdlet 在现有 VM 上启用自动化 VM 来宾修补。

$VirtualMachine = Get-AzVM -ResourceGroupName "myResourceGroup" -Name "myVM"
Set-AzVMOperatingSystem -VM $VirtualMachine -PatchMode "AutomaticByPlatform"
Update-AzVM -VM $VirtualMachine

适用于 Windows VM 的 Azure CLI

创建新的 VM 时，使用 az vm create 启用自动 VM 来宾修补。以下示例为名为 myResourceGroup 的资源组中名为 myVM 的 VM 配置自动 VM 来宾修补：

az vm create --resource-group myResourceGroup --name myVM --image Win2019Datacenter --enable-agent --enable-auto-update --patch-mode AutomaticByPlatform

若要修改现有的 VM，请使用 az vm update

az vm update --resource-group myResourceGroup --name myVM --set osProfile.windowsConfiguration.enableAutomaticUpdates=true osProfile.windowsConfiguration.patchSettings.patchMode=AutomaticByPlatform

Azure 门户

使用 Azure 门户创建 VM 时，对于 Linux 和 Windows，都可以在“管理”选项卡下设置补丁业务流程模式。

显示 Azure 门户中用于启用补丁编排模式的管理选项卡。

启用和评估

注意

在 VM 上启用自动 VM 来宾更新可能需要三个多小时，因为启用过程是在 VM 的非高峰期完成的。由于评估和补丁安装只会在非高峰期进行，因此，VM 在非高峰期仍然必须运行才能应用补丁。

为 VM 启用自动 VM 来宾修补后，将在 Linux VM 上安装 Microsoft.CPlat.Core.LinuxPatchExtension 类型的 VM 扩展，或者在 Windows VM 上安装 Microsoft.CPlat.Core.WindowsPatchExtension 类型的 VM 扩展。无需手动安装或更新此扩展，因为此扩展由 Azure 平台作为自动 VM 来宾修补过程的一部分进行管理。

在 VM 上启用自动 VM 来宾更新可能需要三个多小时，因为启用过程是在 VM 的非高峰期完成的。该扩展也是在 VM 的非高峰期安装和更新的。如果在完成启用之前 VM 的非高峰期已结束，则启用过程将在下一个可用的非高峰期恢复。

当检测到 IaaS VM 或灵活业务流程模式下的规模集出现模型更改时，平台将定期调用修补配置，以确保保持一致。某些模型更改（包括但不限于更新评估模式、修补模式和扩展更新）可能会触发修补配置调用。

自动更新在大多数情况下已禁用，补丁安装将通过今后的扩展安装来完成。以下条件适用。

如果先前已通过 AutomaticByOS 修补模式在 Windows VM 上启用了自动 Windows 更新，则安装扩展时，将为 VM 禁用自动 Windows 更新。
对于 Ubuntu VM，当自动 VM 来宾修补完成启用时，会自动禁用默认的自动更新。
对于 RHEL，则需手动禁用自动更新。执行：

sudo systemctl stop packagekit

sudo systemctl mask packagekit

若要验证是否已完成自动 VM 来宾修补并已在 VM 上安装修补扩展，可以查看 VM 的实例视图。如果启用过程已完成，则扩展已安装，并且 patchStatus 下会显示 VM 的评估结果。可按如下所述的多种方式访问 VM 的实例视图。

REST API

GET on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVirtualMachine/instanceView?api-version=2020-12-01`

Azure PowerShell

结合 -Status 参数使用 Get-AzVM cmdlet 来访问 VM 的实例视图。

Get-AzVM -ResourceGroupName "myResourceGroup" -Name "myVM" -Status

PowerShell 目前仅提供有关修补扩展的信息。不久之后，还可以通过 PowerShell 获取有关 patchStatus 的信息。

Azure CLI

使用 az vm get-instance-view 访问 VM 的实例视图。

az vm get-instance-view --resource-group myResourceGroup --name myVM

了解 VM 的修补状态

实例视图响应的 patchStatus 节提供有关 VM 的最新评估以及上次补丁安装的详细信息。

可在 availablePatchSummary 节下查看 VM 的评估结果。将定期为启用了自动 VM 来宾修补的 VM 执行评估。评估后的可用补丁计数将在 criticalAndSecurityPatchCount 和 otherPatchCount 结果下提供。自动 VM 来宾修补将安装属于“关键”和“安全”补丁分类的所有已评估补丁。将跳过任何其他已评估的补丁。

可在 lastPatchInstallationSummary 节下查看 VM 的补丁安装结果。此节提供有关上次在 VM 上尝试的补丁安装的详细信息，包括已安装的、挂起的、失败的或已跳过的补丁数量。只会在 VM 的非高峰期维护时段安装补丁。在下一个非高峰维护时段，将自动重试挂起的和失败的补丁。

禁用自动 VM 来宾修补

可通过更改 VM 的修补业务流程模式来禁用自动 VM 来宾修补。

若要在 Linux VM 上禁用自动 VM 来宾修补，请将修补模式更改为 ImageDefault。

若要在 Windows VM 上启用自动 VM 来宾修补，属性 osProfile.windowsConfiguration.enableAutomaticUpdates 将确定可在 VM 上设置哪些修补模式，以及此属性只能在首次创建 VM 时进行设置。这会影响某些修补模式转换：

若 VM 具备 osProfile.windowsConfiguration.enableAutomaticUpdates=false，通过将修补模式更改为 Manual 来禁用自动 VM 访问修补。
若 VM 显示osProfile.windowsConfiguration.enableAutomaticUpdates=true，可将修补模式更改为 AutomaticByOS　来禁用自动 VM 来宾修补。
不支持在 AutomaticByOS 模式和手动模式之间进行切换。

若要设置所需的修补模式，请使用本文上述启用部分中的　API、PowerShell 和 CLI 使用情况示例。

按需补丁评估

如果已经为 VM 启用了自动 VM 来宾修补，则会在 VM 的非高峰期在 VM 上定期执行补丁评估。此过程是自动完成的，可以按照本文档前面所述，通过 VM 的实例视图查看最新评估的结果。此外，可以随时为 VM 触发按需补丁评估。补丁评估可能需要几分钟才能完成，最新评估的状态将在 VM 的实例视图上更新。

注意

按需补丁评估不会自动触发补丁安装。如果你已启用自动 VM 来宾修补，则会遵循本文档前面所述的可用性优先修补过程，在 VM 的非高峰期安装 VM 的已评估补丁和适用补丁。

REST API

使用 Assess Patches API 评估虚拟机的可用补丁。

POST on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVirtualMachine/assessPatches?api-version=2020-12-01`

Azure PowerShell

使用 Invoke-AzVmPatchAssessment cmdlet 评估虚拟机的可用补丁。

Invoke-AzVmPatchAssessment -ResourceGroupName "myResourceGroup" -VMName "myVM"

Azure CLI

使用 az vm assess-patches 评估虚拟机的可用补丁。

az vm assess-patches --resource-group myResourceGroup --name myVM

安装按需修补程序

若你已为 VM 启用了自动 VM 来宾修补，系统会于 VM 非高峰期，在 VM 上定期安装安全修补程序和关键补丁。此过程是自动完成的，如本文档前面部分所述，你可通过 VM 实例视图查看最新安装结果。

此外，你还可随时为 VM 触发按需修补评估。安装补丁可能需要几分钟才能完成，最新安装状态将在 VM 实例视图上更新。

你可以使用按需修补程序安装一种或多种修补程序的所有补丁。你还可选择包含或排除 Linux 的特定包或 Windows 特定知识库 ID。触发按需修补安装程序时，请确保在包含列表中至少指定一个补丁分类或至少一个补丁（Linux 特定包，Windows 知识库 ID）。

REST API

使用 Install Patches API 在虚拟机上安装补丁。

POST on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVirtualMachine/installPatches?api-version=2020-12-01`

Linux 请求正文示例：

{
  "maximumDuration": "PT1H",
  "Setting": "IfRequired",
  "linuxParameters": {
    "classificationsToInclude": [
      "Critical",
      "Security"
    ]
  }
}

Windows 请求正文示例：

{
  "maximumDuration": "PT1H",
  "rebootSetting": "IfRequired",
  "windowsParameters": {
    "classificationsToInclude": [
      "Critical",
      "Security"
    ]
  }
}

Azure PowerShell

使用 Invoke-AzVMInstallPatch cmdlet 在虚拟机上安装补丁。

在 Linux VM 上安装某些包的示例：

Invoke-AzVmInstallPatch -ResourceGroupName "myResourceGroup" -VMName "myVM" -MaximumDuration "PT90M" -RebootSetting "Always" -Linux -ClassificationToIncludeForLinux "Security" -PackageNameMaskToInclude ["package123"] -PackageNameMaskToExclude ["package567"]

在 Windows VM 上安装所有关键补丁的示例：

Invoke-AzVmInstallPatch -ResourceGroupName "myResourceGroup" -VMName "myVM" -MaximumDuration "PT2H" -RebootSetting "Never" -Windows   -ClassificationToIncludeForWindows Critical

在 Windows VM 上安装所有安全修补程序，同时包含和排除具有特定知识库 ID 的补丁，并排除需要重新启动的任何补丁，具体示例如下：

Invoke-AzVmInstallPatch -ResourceGroupName "myResourceGroup" -VMName "myVM" -MaximumDuration "PT90M" -RebootSetting "Always" -Windows -ClassificationToIncludeForWindows "Security" -KBNumberToInclude ["KB1234567", "KB123567"] -KBNumberToExclude ["KB1234702", "KB1234802"] -ExcludeKBsRequiringReboot

Azure CLI

使用 az vm install-patches　在虚拟机上安装补丁。

在 Linux VM 上安装所有关键补丁的示例：

az vm install-patches --resource-group myResourceGroup --name myVM --maximum-duration PT2H --reboot-setting IfRequired --classifications-to-include-linux Critical

在 Windows VM 上安装所有关键补丁和安全修补程序，同时排除需要重新启动的任何补丁，示例如下：

az vm install-patches --resource-group myResourceGroup --name myVM --maximum-duration PT2H --reboot-setting IfRequired --classifications-to-include-win Critical Security --exclude-kbs-requiring-reboot true

Canonical Images 上的严格安全部署

Microsoft 已和 Canonical 合作，使我们的客户能够及时了解 Linux OS 更新，并提高他们在 Azure 上 Ubuntu 工作负载的安全性和复原能力。通过利用 Canonical 的快照服务，Azure 现在会将同一组 Ubuntu 更新一致地应用于各个区域的舰队。

Azure 将在客户存储库中存储与包相关的更新，最长可达 90 天，具体取决于可用空间。这样，客户就可以利用更新后最长 3 个月的 VM 的严格安全部署来更新其舰队。

已启用自动修补的客户无需执行任何操作。平台将默认安装对齐时间点的包。如果无法安装基于快照的更新，Azure 将在 VM 上应用最新的包，以确保 VM 保持安全。时间点更新将在各区域的所有 VM 上保持一致，以确保同质性。客户可以在 Azure Resource Graph 和 VM 的实例视图中查看与应用的更新相关的发布日期信息。

映像生命周期结束 (EOL)

发布者可能不再支持在特定日期后为其映像生成新更新。这通常称为映像生命周期结束 (EOL)。 Azure 不建议在其 EOL 日期之后使用映像，因为这样会让服务面临安全漏洞或性能问题。 Azure 来宾修补服务 (AzGPS) 将为客户和受影响的合作伙伴传达必要的步骤。 AzGPS 将在 EOL 日期之后从支持列表中删除该映像。 Azure 上使用生命周期结束映像的 VM 可能会在映像过期后继续工作。但是，这些 VM 遇到的任何问题都不符合支持条件。

后续步骤

详细了解如何创建和管理 Windows 虚拟机

通过

Azure 虚拟机和规模集的自动来宾修补

自动 VM 来宾修补的工作原理是什么？

可用性优先更新

安装哪些补丁？

支持的 OS 映像

补丁业务流程模式

启用自动 VM 来宾修补的要求

启用自动 VM 来宾修补

适用于 Linux VM 的 REST API

适用于 Windows VM 的 REST API

创建 Windows VM 时使用的 Azure PowerShell

更新 Windows VM 时使用的 Azure PowerShell

适用于 Windows VM 的 Azure CLI

Azure 门户

启用和评估

REST API

Azure PowerShell

Azure CLI

了解 VM 的修补状态

禁用自动 VM 来宾修补

按需补丁评估

REST API

Azure PowerShell

Azure CLI

安装按需修补程序

REST API

Azure PowerShell

Azure CLI

Canonical Images 上的严格安全部署

映像生命周期结束 (EOL)

后续步骤

其他资源