AMS 標準修補 - AMS 進階使用者指南
支援的作業系統支援的修補程式修補和基礎設施設計AMS 標準修補失敗

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

AMS 標準修補

AMS 支援使用 AMS 標準修補模型的現有客戶，但此模型不適用於新客戶，並且正在淘汰以有利於 AMS Patch Orchestrator。

AMS 標準修補的一般修補程式內容包括支援作業系統的廠商更新，以及預先安裝支援作業系統的軟體 （例如 IIS 和 Apache Server)。

在 AMS 加入期間，您可以指定修補需求、政策、頻率和偏好的修補時段。這些組態意味著您可以避免讓應用程式一次完全離線以進行基礎設施修補，因此您可以控制何時修補哪些基礎設施。

注意

本主題中所述的修補程序僅適用於您的堆疊。AMS 基礎設施會在個別程序期間修補。AWS Managed Services 維護時段 （或維護時段） 會執行 AWS Managed Services (AMS) 的維護活動，並在每個月的第二個星期四太平洋時間下午 3 點至下午 4 點重複執行。AMS 可能會變更維護時段，但需提前 48 小時通知。您可以在加入時設定 AMS 修補程式時段，或者核准或拒絕每月修補程式服務通知。

AMS 會定期掃描受管 Amazon EC2 執行個體，以透過作業系統更新功能取得更新。我們也定期更新 環境中支援的 AMS 基礎 Amazon Machine Image AMIs)。

驗證後，AMS AMI 版本會與所有 AMS 帳戶共用。您可以使用 DescribeImages Amazon EC2 API 呼叫或使用 Amazon EC2 主控台來檢視可用的 AWS AMI 版本。若要尋找可用的 AMS AMIs，請參閱 尋找 AMI IDs、AMS。

AMS 只會在您要求時執行臨機操作修補排程。先前 AMS 會傳送通知；目前不會傳送通知。

注意

根據預設，AMS 會使用 Systems Manager 來套用修補程式，方法是讓套件管理員 (Linux) 或系統更新服務 (Windows) 查詢其預設儲存庫，以查看可用的新套件。如果在day-to-day操作過程中，您已使用預設套件管理員在 Linux 主機上安裝套件，該套件管理員也會在軟體可用時為該軟體挑選新套件。在這種情況下，您可能想要採取修補動作 （本節說明） 來選擇退出該執行個體。

支援的作業系統

支援的作業系統 (x86-64)

  • Amazon Linux 2023

  • Amazon Linux 2 (預期的 AMS 支援結束日期為 2026 年 6 月 30 日）

  • Oracle Linux 9.x、8.x

  • Red Hat Enterprise Linux (RHEL) 9.x、8.x

  • SUSE Linux Enterprise Server 15 SP6

  • SUSE Linux Enterprise Server for SAP 15 SP3 及更新版本

  • Microsoft Windows Server 2022、2019、2016

  • Ubuntu 20.04、22.04、24.04

支援的作業系統 (ARM64)

  • Amazon Linux 2023

  • Amazon Linux 2 (預期的 AMS 支援結束日期為 2026 年 6 月 30 日）

支援的修補程式

AWS Managed Services 主要支援作業系統層級的修補。安裝的修補程式可能因作業系統而有所不同。

重要

所有更新都會從執行個體上設定的 Systems Manager 修補程式基準服務遠端儲存庫下載，並在本主題稍後說明。執行個體必須能夠連線到儲存庫，才能執行修補。

若要針對交付您要自行維護之套件的儲存庫選擇退出修補程式基準服務，請執行下列命令來停用儲存庫：

yum-config-manager DASHDASHdisable REPOSITORY_NAME

使用下列命令擷取目前設定的儲存庫清單：

yum repolist

  • Amazon Linux 預先設定的儲存庫 （通常是四個）：

    儲存庫 ID 儲存庫名稱

    amzn-main/latest

    amzn-main-Base

    amzn-updates/latest

    amzn-updates-Base

    epel/x86_64

    Enterprise Linux 6 - x86_64 的額外套件

    pbis

    PBIS 套件更新

  • Red Hat Enterprise Linux 預先設定的儲存庫 （五個用於 Red Hat Enterprise Linux 7，五個用於 Red Hat Enterprise Linux 6)：

    儲存庫 ID 儲存庫名稱

    rhui-REGION-client-config-server-7/x86_64

    Red Hat Update Infrastructure 2.0 用戶端組態伺服器

    rhui-REGION-rhel-server-releases/7Server/x86_64

    Red Hat Enterprise Linux 伺服器 7

    rhui-REGION-rhel-server-releases/7Server/x86_64

    Red Hat Enterprise Linux Server 7 RH Common(RPMs

    epel/x86_64

    適用於 Enterprise Linux 7 的額外套件 - x86_64

    pbis

    PBIS 套件更新

    儲存庫 ID 儲存庫名稱

    rhui-REGION-client-config-server-6

    Red Hat 更新基礎設施 2.0

    rhui-REGION-rhel-server-releases

    Red Hat Enterprise Linux Server 6 (RPMs)

    rhui-REGION-rhel-server-rh-common

    Red Hat Enterprise Linux Server 6 RH Common (RPMs)

    Epel

    Enterprise Linux 6 - x86_64 的額外套件

    pbis

    PBIS 套件更新

  • CentOS 7 預先設定的儲存庫 （通常五個）：

    儲存庫 ID 儲存庫名稱

    base/7/x86_64

    CentOS-7 - 基礎

    更新/7/x86_64

    CentOS-7 - 更新

    extras/7/x86_64

    CentOS-7 - 額外項目

    epel/x86_64

    適用於 Enterprise Linux 7 的額外套件 - x86_64

    pbis

    PBIS 套件更新

  • 對於 Microsoft Windows Server，所有更新都是使用 Windows Update Agent 進行偵測和安裝，其設定為使用 Windows Update 目錄 （不包括 Microsoft Update 的更新）。

    在 Microsoft Windows 作業系統上，修補程式管理員會使用 Microsoft 的 cab 檔案 wsusscn2.cab 作為可用作業系統安全性更新的來源。此檔案包含有關 Microsoft 發佈之安全相關更新的資訊。修補程式管理員會定期從 Microsoft 下載此檔案，並使用它來更新適用於 Windows 執行個體的修補程式集。此檔案僅包含 Microsoft 識別為與安全性相關的更新。修補程式管理員在處理檔案中的資訊時，也會移除已被較新的更新所取代的更新。因此，只有最新的更新會顯示出來並提供安裝。例如，如果 KB4012214 取代 KB3135456，則修補程式管理員中只會提供 KB4012214 做為更新。

    若要進一步了解 wsusscn2.cab 檔案，請參閱 Microsoft 文章使用 WUA 離線掃描更新。

修補和基礎設施設計

AMS 根據您的基礎設施設計採用不同的修補方法：可變或不可變 （如需詳細定義，請參閱 AMS 金鑰術語)。

使用可變基礎設施時，修補作業會使用傳統就地方法，分別由 AMS 操作工程師安裝更新至 Amazon EC2 執行個體。此修補方法用於非 Auto Scaling 群組的堆疊，並包含單一 Amazon EC2 執行個體或數個執行個體。在此案例中，取代執行個體或堆疊所依據的 AMI 會銷毀自第一次部署以來對該系統所做的所有變更，因此不會這麼做。更新會套用至執行中的系統，您可能會因為應用程式或系統重新啟動而發生系統停機 （取決於堆疊組態）。這可以透過藍/綠更新策略來緩解。如需詳細資訊，請參閱AWS CodeDeploy 介紹藍/綠部署。

使用不可變的基礎設施時，修補方法是 AMI 取代。不可變執行個體會使用更新的 AMI 統一更新，以取代 Auto Scaling 群組組態中指定的 AMI。AMS 版本每月更新 （即修補） AMIs，通常是修補程式週二的一週。下一節說明運作方式。

AMS 標準修補失敗

如果更新失敗，AMS 會執行分析以了解失敗原因，並向您傳達分析結果。如果失敗可歸因於 AMS，則在維護時段內，我們會重試更新。否則，AMS 會為失敗的執行個體更新建立服務通知，並等待您的指示。

對於可歸因於您系統的故障，您可以提交具有新修補程式 RFC 的服務請求來更新執行個體。