本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
故障診斷 Puppet Enterprise 的 OpsWorks
重要
AWS OpsWorks for Puppet Enterprise 此服務已於 2024 年 3 月 31 日終止,並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問,請透過 AWS re:Post
本主題包含一些常見的 OpsWorks for Puppet Enterprise 問題,以及針對這些問題的建議解決方案。
一般疑難排解秘訣
若您無法建立或使用 Puppet 主伺服器,您可以檢視錯誤訊息或日誌,來協助您故障診斷問題。以下任務說明在您故障診斷 Puppet 主伺服器問題時一般開始著手的位置。如需特定錯誤和解決方案的資訊,請參閱本主題的針對特定錯誤進行故障診斷一節。
如果 Puppet 主控端無法啟動,請使用 OpsWorks for Puppet Enterprise 主控台檢視錯誤訊息。在 Puppet 主伺服器屬性頁面上,與啟動和執行伺服器相關的錯誤訊息會顯示在頁面的頂端。錯誤可能來自 OpsWorks for Puppet Enterprise AWS CloudFormation或 Amazon EC2,這些服務用於建立 Puppet 主伺服器。在屬性頁面上,您也可以檢視在執行中伺服器上發生的事件,其中也可能包含故障事件訊息。
為協助解決 EC2 問題,請使用 SSH 連線到您伺服器的執行個體並檢視日誌。EC2 執行個體日誌存放在
/var/log/aws/opsworks-cm
目錄。這些日誌會在 OpsWorks for Puppet Enterprise 啟動 Puppet 主控端時擷取命令輸出。
針對特定錯誤進行故障診斷
主題
伺服器處於連線中斷狀態
問題:伺服器的狀態顯示為連線中斷。
原因:當 外部的實體對 OpsWorks for Puppet Enterprise 伺服器或其支援資源 AWS OpsWorks 進行變更時,這最常發生。 AWS OpsWorks 無法連線到連線中斷狀態的 Puppet Enterprise 伺服器,以處理維護任務,例如建立備份、套用作業系統修補程式或更新 Puppet。因此,您的伺服器可能缺少重要的更新、容易發生安全問題,或者無法如預期般運作。
解決方案:嘗試下列步驟來還原伺服器的連線。
-
請確定您的服務角色具有所有必要的許可。
-
在伺服器的設定頁面上,在網路和安全性中,選擇伺服器正在使用之服務角色的連結。這會開啟要在 IAM 主控台中檢視的服務角色。
-
在許可索引標籤上,確認
AWSOpsWorksCMServiceRole
位於許可政策清單中。如果未列出,請手動將AWSOpsWorksCMServiceRole
受管政策新增至角色。 -
在信任關係索引標籤上,確認服務角色具有信任政策,信任
opsworks-cm.amazonaws.com
服務代表您擔任角色。如需如何搭配角色使用信任政策的詳細資訊,請參閱修改角色 (主控台) 或 AWS 安全部落格文章,如何搭配 IAM 角色使用信任政策。
-
-
請確定您的執行個體設定檔具有所有必要的許可。
-
在伺服器的設定頁面上,在網路和安全性中,選擇伺服器正在使用的執行個體描述檔連結。這會開啟執行個體設定檔,以便在 IAM 主控台中檢視。
-
在許可索引標籤上,確認
AmazonEC2RoleforSSM
和AWSOpsWorksCMInstanceProfileRole
都位於許可政策清單中。如果其中之一或兩者未列出,請手動將這些受管政策新增至角色。 -
在信任關係索引標籤上,確認服務角色具有信任政策,信任
ec2.amazonaws.com
服務代表您擔任角色。如需如何將信任政策與角色搭配使用的詳細資訊,請參閱修改角色 (主控台) 或 AWS 安全部落格文章:如何將信任政策與 IAM 角色搭配使用。
-
-
在 Amazon EC2 主控台中,請確定您位於與 OpsWorks for Puppet Enterprise 伺服器相同的區域,然後重新啟動伺服器正在使用的 EC2 執行個體。
-
選擇名為
aws-opsworks-cm-instance-
server-name
的 EC2 執行個體。 -
在執行個體狀態功能表中,選擇重新啟動執行個體。
-
您的伺服器最多需要 15 分鐘才能重新啟動並完全上線。
-
-
在 OpsWorks for 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 執行個體類型。
無法建立伺服器的 Amazon 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) 設定。
服務角色錯誤導致伺服器無法建立
問題:伺服器建立失敗,並顯示下列錯誤訊息:"Not authorized to perform sts:AssumeRole."
原因:這可能會在您使用的服務角色缺少適當的許可,無法建立新伺服器時發生。
解決方案:開啟 OpsWorks for Puppet Enterprise 主控台;使用主控台產生新的服務角色和執行個體描述檔角色。若您偏好使用您自己的服務角色,請將 AWSOpsWorksCMServiceRole 政策連接到角色。確認 opsworks-cm.amazonaws.com 已列在角色信任關係中的服務之間。確認與 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 客戶支援,以增加與您的帳戶相關聯的 EIP 地址限制。
自動節點關聯失敗
問題:新 Amazon EC2 節點的全自動或自動關聯失敗。應新增至 Puppet 主伺服器的節點並未在 Puppet Enterprise 儀表板上出現。
原因:這可能會在您沒有將 IAM 角色設為允許 opsworks-cm
API 呼叫,以和新的 EC2 執行個體通訊的執行個體描述檔時發生。
解決方案:將政策連接到您的 EC2 執行個體描述檔,以允許 AssociateNode
和 DescribeNodeAssociationStatus
API 呼叫使用 EC2,如在 Puppet Enterprise 的 OpsWorks 中自動新增節點中所述。
系統維護失敗
AWS OpsWorks CM 會執行每週系統維護,以確保 AWS Puppet 伺服器的最新版本,包括安全性更新,一律在 OpsWorks for Puppet Enterprise 伺服器上執行。如果系統維護因任何原因失敗, 會 AWS OpsWorks CM 通知您失敗。如需系統維護的詳細資訊,請參閱OpsWorks for Puppet Enterprise 中的系統維護。
本節說明失敗的可能原因,並建議解決方案。
服務角色或執行個體描述檔錯誤導致系統維護無法進行
問題:系統維護失敗,並出現錯誤訊息,指出「未獲授權執行 sts:AssumeRole」,或有關許可的類似錯誤訊息。
原因:當您正在使用的服務角色或執行個體描述檔缺少足夠的許可,在伺服器上執行系統維護時,可能會發生這種情況。
解決方案:確保您的服務角色和執行個體描述檔具有所有必要的許可。
請確定您的服務角色具有所有必要的許可。
在伺服器的設定頁面上,於網路和安全性中,選擇伺服器正在使用之服務角色的連結。這會開啟要在 IAM 主控台中檢視的服務角色。
在許可索引標籤上,確認
AWSOpsWorksCMServiceRole
已連接至服務角色。如果AWSOpsWorksCMServiceRole
未列出,請將此政策新增至角色。確認 opsworks-cm.amazonaws.com 已列在角色信任關係中的服務之間。如需如何將信任政策與角色搭配使用的詳細資訊,請參閱修改角色 (主控台) 或 AWS 安全部落格文章:如何將信任政策與 IAM 角色搭配使用
。
請確定您的執行個體設定檔具有所有必要的許可。
在伺服器的設定頁面上,在網路和安全性中,選擇伺服器正在使用的執行個體描述檔連結。這會開啟執行個體設定檔,以便在 IAM 主控台中檢視。
在許可索引標籤上,確認
AmazonEC2RoleforSSM
和AWSOpsWorksCMInstanceProfileRole
都位於許可政策清單中。如果其中之一或兩者未列出,請手動將這些受管政策新增至角色。在信任關係索引標籤上,確認服務角色具有信任政策,信任
ec2.amazonaws.com
服務代表您擔任角色。如需如何將信任政策與角色搭配使用的詳細資訊,請參閱修改角色 (主控台) 或 AWS 安全部落格文章,如何將信任政策與 IAM 角色搭配使用。
其他協助及支援
若您在本主題中沒有看到您的特定問題,或是您已嘗試本主題中的建議,但仍然發生問題,請造訪 AWS OpsWorks
論壇
您也可以前往 AWS Support 中心