傀儡企業 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. 在 [權限] 索引標籤上，確認AmazonEC2RoleforSSM和AWSOpsWorksCMInstanceProfileRole都在 [權限] 原則清單中。如果其中一個或兩個未列出，請手動將這些受管理的策略新增至角色。

    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 執行個體描述檔，以允許 AssociateNode 和 DescribeNodeAssociationStatus 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. 在 [權限] 索引標籤上，確認AmazonEC2RoleforSSM和AWSOpsWorksCMInstanceProfileRole都在 [權限] 原則清單中。如果其中一個或兩個未列出，請手動將這些受管理的策略新增至角色。

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

其他協助及支援

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

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