傀儡企業 OpsWorks 的疑難排解 - AWS OpsWorks

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

傀儡企業 OpsWorks 的疑難排解

重要

該 AWS OpsWorks for Puppet Enterprise 服務於 2024 年 3 月 31 日終止使用壽命,並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載移轉至其他解決方案。如果您對移轉有任何疑問,請透過 AWS Re: post 或透過進AWS 階 Support 與 AWS Support 團隊聯絡。

本主題包含 Puppet 企業問題 OpsWorks 的一些常見問題,以及這些問題的建議解決方案。

一般疑難排解秘

若您無法建立或使用 Puppet 主伺服器,您可以檢視錯誤訊息或日誌,來協助您故障診斷問題。以下任務說明在您故障診斷 Puppet 主伺服器問題時一般開始著手的位置。如需特定錯誤和解決方案的資訊,請參閱本主題的排解特定錯誤一節。

  • 如果 Puppet 主控台無法啟動,請使用 OpsWorks 適用於 Puppet 企業主控台來檢視錯誤訊息。在 Puppet 主伺服器屬性頁面上,與啟動和執行伺服器相關的錯誤訊息會顯示在頁面的頂端。用來 OpsWorks 建立 Puppet 主機的 Puppet 企業或 Amazon EC2 服務可能會出現錯誤。 AWS CloudFormation在屬性頁面上,您也可以檢視在執行中伺服器上發生的事件,其中也可能包含故障事件訊息。

  • 為協助解決 EC2 問題,請使用 SSH 連線到您伺服器的執行個體並檢視日誌。EC2 執行個體日誌存放在 /var/log/aws/opsworks-cm 目錄。這些記錄會在 Puppet 企業啟 OpsWorks 動 Puppet 主機時擷取命令輸出。

排解特定錯誤

伺服器處於連線中斷狀態

問題:伺服器的狀態顯示為「連線中斷」。

原因:這通常發生在以外的 AWS OpsWorks 實體 OpsWorks 對 Puppet Enterprise 伺服器或其支援資源進行變更時。 AWS OpsWorks 無法連線至處於 [連線中斷] 狀態的 Puppet Enterprise 伺服器以處理維護工作,例如建立備份、套用作業系統修補程式或更新 Puppet。因此,您的伺服器可能缺少重要更新、容易受到安全性問題的影響,或者無法如預期般運作。

解決方案:請嘗試下列步驟來還原伺服器的連線。

  1. 請確定您的服務角色具有所有必要的權限。

    1. 在伺服器的 [設定] 頁面上,在 [網路和安全性] 中,選擇伺服器正在使用之服務角色的連結。這會開啟要在 IAM 主控台中檢視的服務角色。

    2. 在 [權限] 索引標籤上,確認AWSOpsWorksCMServiceRole是否位於 [權限] 原則清單中。如果未列出,請手動將受AWSOpsWorksCMServiceRole管理的原則新增至角色。

    3. 在 [信任關係] 索引標籤上,確認服務角色具有信任原則,該原則會信任opsworks-cm.amazonaws.com服務以代表您擔任角色。如需如何搭配角色使用信任政策的詳細資訊,請參閱修改角色 (主控台) 或 AWS 安全部落格文章「如何搭配 IAM 角色使用信任政策」。

  2. 請確定您的執行個體設定檔具有所有必要的權限。

    1. 在伺服器的 [設定] 頁面上,在 [網路和安全性] 中,選擇伺服器使用之執行個體設定檔的連結。這會開啟執行個體設定檔,以便在 IAM 主控台中檢視。

    2. 在 [權限] 索引標籤上,確認AmazonEC2RoleforSSMAWSOpsWorksCMInstanceProfileRole都在 [權限] 原則清單中。如果其中一個或兩個未列出,請手動將這些受管理的策略新增至角色。

    3. 在 [信任關係] 索引標籤上,確認服務角色具有信任原則,該原則會信任ec2.amazonaws.com服務以代表您擔任角色。如需如何搭配角色使用信任政策的詳細資訊,請參閱修改角色 (主控台) 或 AWS 安全部落格文章「如何搭配 IAM 角色使用信任政策」。

  3. 在 Amazon EC2 主控台中,請確定您所在的區域與 Puppet 企業伺服器所在 OpsWorks 的區域相同,然後重新啟動伺服器正在使用的 EC2 執行個體。

    1. 選擇名為aws-opsworks-cm-instance-伺服器名稱的 EC2 執行個體。

    2. 在 [執行個體狀態] 功能表上,選擇 [重新啟動

    3. 最多需要 15 分鐘,讓伺服器重新啟動並完全連線。

  4. 在 OpsWorks Puppet Enterprise 主控台的伺服器詳細資料頁面上,確認伺服器狀態現在為狀況好。

如果執行上述步驟後,伺服器狀態仍為 [連線中斷],請嘗試下列其中一個動作。

伺服器建立失敗,並顯示 "requested configuration is currently not supported" 訊息

問題:您嘗試建立 Puppet Enterprise 伺服器,但伺服器建立失敗並顯示與下列內容類似的錯誤訊息:"The requested configuration is currently not supported. Please check the documentation for supported configurations."

原因:Puppet 主伺服器可能指定了不支援的執行個體類型。若您選擇在擁有非預設租用的 VPC (例如一個專用執行個體) 中建立 Puppet 伺服器,所有指定 VPC 中的執行個體也都必須是專用或主控租用。因為有些執行個體類型 (例如 t2) 僅能使用預設租用,指定 VPC 便可能無法支援 Puppet 主伺服器執行個體類型,因此導致伺服器建立失敗。

解決方案:若您選擇具有非預設租用的 VPC,請使用支援專用租用的 m4 執行個體類型。

無法建立伺服器的亞馬遜 EC2 執行個體

問題:伺服器建立失敗,並顯示與下列內容相似的錯誤訊息:"The following resource(s) failed to create: [EC2Instance]. Failed to receive 1 resource signal(s) within the specified duration."

原因:這最有可能是因為 EC2 執行個體沒有網路存取。

解決方案:確定執行個體具有輸出網際網路存取權,且 AWS 服務代理程式能夠發出命令。確認您的 VPC (使用單一公有子網路的 VPC) 已啟用 DNS resolution (DNS 解析),並且您的子網路也已啟用 Auto-assign Public IP (自動指派公有 IP) 設定。

服務角色錯誤導致伺服器無法建立

問題:伺服器建立失敗,並顯示錯誤訊息,指出「未授權執行 sts:AssumeRole」

原因:這可能會在您使用的服務角色缺少適當的許可,無法建立新伺服器時發生。

解決方案:開啟 Puppet Enterprise 主控台;使用主控台產生新的服務角色和執行個體設定檔角色。 OpsWorks 如果您想要使用自己的服務角色,請將AWSOpsWorksCMServiceRole原則附加至該角色。確認是否列在角色的信任關係中的服務之間。確認與 Puppet 主機相關聯的服務角色已附加受AWSOpsWorksCMServiceRole管理的原則。

超過彈性 IP 地址限制

問題:伺服器建立失敗,並顯示下列錯誤訊息:"The following resource(s) failed to create: [EIP, EC2Instance]. Resource creation cancelled, the maximum number of addresses has been reached."

原因:當您的帳戶使用的彈性 IP (EIP) 地址數超過最大值時,便可能發生此情況。預設 EIP 地址限制為 5 個。

解決方案:您可以釋出現有的 EIP 地址,或刪除帳戶未使用的 EIP 地址,或者您可以聯絡 AWS 客戶 Support 以提高與您帳戶相關聯的 EIP 地址限制。

自動節點關聯失敗

問題:新 Amazon EC2 節點的無人值守或自動關聯失敗。應新增至 Puppet 主伺服器的節點並未在 Puppet Enterprise 儀表板上出現。

原因:這可能會在您沒有將 IAM 角色設為允許 opsworks-cm API 呼叫,以和新的 EC2 執行個體通訊的執行個體描述檔時發生。

解決方案:將政策連接到您的 EC2 執行個體描述檔,以允許 AssociateNodeDescribeNodeAssociationStatus API 呼叫使用 EC2,如 OpsWorks 為 Puppet 企業自動新增節點中所述。

系統維護失敗

AWS OpsWorks CM 每週執行系統維護,以確保 Puppet 伺服器的最新 AWS測試版本 (包括安全性更新) 一 OpsWorks 律在 Puppet 企業伺服器上執行。如果由於任何原因,系統維護失敗,會 AWS OpsWorks CM 通知您失敗。如需有關系統維護的更多資訊,請參閱 OpsWorks 針對 Puppet 企業的系統維護

本節說明失敗的可能原因,並建議解決方案。

服務角色或實例配置文件錯誤阻止系統維護

問題:系統維護失敗,並顯示錯誤訊息,指出「未授權執行 sts:AssumeRole」,或類似權限的錯誤訊息。

原因:當您使用的服務角色或執行個體設定檔缺乏足夠的權限,無法在伺服器上執行系統維護時,就會發生這種情況。

解決方案:確定您的服務角色和執行個體設定檔具有所有必要的權限。

  1. 請確定您的服務角色具有所有必要的權限。

    1. 在伺服器的 [設定] 頁面上,在 [網路和安全性] 中,選擇伺服器正在使用之服務角色的連結。這會開啟要在 IAM 主控台中檢視的服務角色。

    2. 在 [權限] 索引標籤上,確認AWSOpsWorksCMServiceRole已附加至服務角色。如果AWSOpsWorksCMServiceRole未列出,請將此原則新增至角色。

    3. 確認是否列在角色的信任關係中的服務之間。如需如何搭配角色使用信任政策的詳細資訊,請參閱修改角色 (主控台) 或 AWS 安全部落格文章「如何搭配 IAM 角色使用信任政策」。

  2. 請確定您的執行個體設定檔具有所有必要的權限。

    1. 在伺服器的 [設定] 頁面上,在 [網路和安全性] 中,選擇伺服器使用之執行個體設定檔的連結。這會開啟執行個體設定檔,以便在 IAM 主控台中檢視。

    2. 在 [權限] 索引標籤上,確認AmazonEC2RoleforSSMAWSOpsWorksCMInstanceProfileRole都在 [權限] 原則清單中。如果其中一個或兩個未列出,請手動將這些受管理的策略新增至角色。

    3. 在 [信任關係] 索引標籤上,確認服務角色具有信任原則,該原則會信任ec2.amazonaws.com服務以代表您擔任角色。如需如何搭配角色使用信任政策的詳細資訊,請參閱修改角色 (主控台) 或 AWS 安全部落格文章「如何搭配 IAM 角色使用信任政策」。

其他協助及支援

若您在本主題中沒有看到您的特定問題,或是您已嘗試本主題中的建議,但仍然發生問題,請造訪 AWS OpsWorks 論壇

您也可以前往 AWS Support 中心。Sup AWS port 中心是建立和管理 Sup AWS port 案例的中心。Sup AWS port 中心也包含其他實用資源的連結,例如論壇、技術常見問答集、服務健康狀態和 AWS Trusted Advisor.