疑難排解 AWS OpsWorks 棧

重要

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

本節包含一些常見的 AWS OpsWorks 堆疊問題及其解決方案。

無法管理執行個體

問題：您再也無法管理以前能管理的執行個體。在某些情況下，日誌可能會顯示類似下列內容的錯誤。

Aws::CharlieInstanceService::Errors::UnrecognizedClientException - The security token included in the request is invalid.

原因：此問題可能會在執行個體依存之 AWS OpsWorks 以外的資源遭到編輯或刪除時發生。以下是可能會中斷與執行個體通訊之資源變更的範例。

• 與執行個體相關聯的 IAM 使用者或角色遭到意外刪除，位於 AWS OpsWorks Stacks 之外。這會導致執行個體上安裝的 AWS OpsWorks 代理程式與 AWS OpsWorks 堆疊服務之間的通訊失敗。與執行個體關聯的 使用者需要在執行個體的生命存續期間內存在。

• 在執行個體離線時編輯磁碟區或儲存體組態，可能會使執行個體無法管理。

• 手動將 EC2 執行個體新增至 ELB。 AWS OpsWorks 每次執行個體進入或離開線上狀態時，都會重新設定指派的 Elastic Load Balancing 器。 AWS OpsWorks 只會將其知道的執行個體視為有效成員；會移除在外部 AWS OpsWorks或透過其他程序新增的執行個體。每一個其他的執行個體都會遭到移除。

解決方案：請勿刪除執行個體所依賴的 IAM 使用者或角色。若可能的話，請只在依存執行個體執行時編輯磁碟區或儲存體組態。用 AWS OpsWorks 於管理執行個體的負載平衡器或 EIP 成員資格。 AWS OpsWorks 註冊執行個體時，若要避免在意外刪除使用者時發生管理已註冊執行個體的問題，請將--use-instance-profile參數新增至您的register命令，以改用執行個體的內建執行個體設定檔。

在 Chef 執行之後，執行個體無法開機

問題：於設定為使用自訂技術指南的 Chef 11.10 或較舊版本的堆疊上，在使用社群技術指南的 Chef 執行之後，執行個體無法開機。日誌訊息可能會表示配方編譯失敗 ("Recipe Compile Error")，或是因為找不到依存項目而無法載入。

原因：最有可能的原因是自訂或社群技術指南不支援堆疊所使用的 Chef 版本。一些熱門的社群技術指南，例如 apt 和 build-essential 與 Chef 11.10 有已知的相容性問題。

解決方案：在已開啟「使用自訂 Chef 食譜」設定的 Stack AWS OpsWorks 堆疊上，自訂或社群食譜必須始終支援堆疊使用的 Chef 版本。請將社群技術指南固定 (即將技術指南版本編號設為特定版本) 在與您在堆疊設定中設定之 Chef 版本相容的版本。若要尋找支援的社群技術指南版本，請檢視編譯失敗之技術指南的變更記錄，並只使用您堆疊可支援的最近版本。若要固定技術指南的版本，請在您自訂技術指南儲存庫的 Berksfile 中指定明確的版本編號。例如 cookbook 'build-essential', '= 3.2.0'。

圖層的實例全部通過 Elastic Load Balancing Health 狀態檢查

問題：您將 Elastic Load Balancing 負載平衡器連接到應用程式伺服器層，但所有執行個體都無法通過健康狀態檢查。

原因：建立 Elastic Load Balancing 負載平衡器時，必須指定負載平衡器呼叫的 ping 路徑，以判斷執行個體是否健全狀態。請務必指定適合您應用程式的 ping 路徑。預設值為 /index.html。若您的應用程式不包含 index.html，您必須指定適當的路徑，否則運作狀態檢查將會失敗。例如，Chef 11 Linux 堆疊入門中使用的 SimplePHPApp 應用程式並未使用 index.html。那些伺服器的適當 ping 路徑為 /。

解決方案：編輯負載平衡器的 ping 路徑。如需詳細資訊，請參閱 Elastic Load Balancing

無法與 Elastic Load Balancing Load Balancer 通訊

問題：您建立 Elastic Load Balancing 負載平衡器並將其附加到應用程式伺服器層，但是當您按一下負載平衡器的 DNS 名稱或 IP 位址以執行應用程式時，您會收到下列錯誤：「遠端伺服器沒有回應」。

原因：如果您的堆棧在默認 VPC 中運行，則在該區域中創建 Elastic Load Balancing 器時，必須指定安全組。安全群組必須具備輸入規則，允許來自您 IP 地址的傳入流量。若您指定 default VPC security group (預設 VPC 安全群組)，預設的輸入規則不會接受任何傳入流量。

解決方案：編輯安全群組輸入規則，以接受來自適當 IP 地址的傳入流量。

1. 在 Amazon EC2 主控台的導覽窗格中按一下「安全群組」。

2. 選取負載平衡器的安全群組。

3. 按一下 Inbound (傳入) 標籤上的 Edit (編輯)。

4. 新增一條輸入規則，並將其中的 Source (來源) 設為適當的 CIDR。

   例如，指定 Anywhere (任何位置) 會將 CIDR 設為 0.0.0.0/0，即指示負載平衡器接受來自任何 IP 地址的傳入流量。

匯入的現場部署執行個體在重新啟動之後無法完成磁碟區設定

問題：您重新啟動已匯入 AWS OpsWorks Stacks 的 EC2 執行個體，堆疊主控台會顯示為執行個體狀態失敗。 AWS OpsWorks 這可能會在 Chef 11 或 Chef 12 執行個體上發生。

原因：AWS OpsWorks Stacks 於設定程序中可能無法將磁碟區連接至您的執行個體。其中一個可能的原因是 AWS OpsWorks Stacks 在您執行 setup 命令時覆寫了您執行個體上的磁碟區組態。

解決方案：開啟執行個體的 Details (詳細資訊) 頁面，檢查 Volumes (磁碟區) 區域內的磁碟區組態。請注意，您只能在您的執行個體處於 stopped (已停止) 狀態時才能變更您的磁碟區組態。請確認每個磁碟區都有指定的掛載點和名稱。重新啟動執行個體之前，請確認您在 AWS OpsWorks Stacks 中的設定中提供了正確的掛載點。

EBS 磁碟區在重新開機後無法重新連接

問題：您可以使用 Amazon EC2 主控台將 Amazon EBS 磁碟區連接到執行個體，但是當您重新啟動執行個體時，磁碟區不再連接。

原因： AWS OpsWorks 堆疊只能重新連接其知道的 Amazon EBS 磁碟區，這些磁碟區僅限於以下內容：

• 由 AWS OpsWorks 堆疊建立的磁碟區。

• 來自您帳戶的磁碟區，且已藉 Resources (資源) 頁面明確向堆疊註冊。

解決方案：僅使用 AWS OpsWorks 堆疊主控台、API 或 CLI 來管理您的 Amazon EBS 磁碟區。如果您想要將帳戶的其中一個 Amazon EBS 磁碟區與堆疊搭配使用，請使用堆疊的資源頁面來註冊磁碟區並將其附加到執行個體。如需詳細資訊，請參閱 資源管理。

無法刪除 AWS OpsWorks Stacks 安全群組

問題：刪除堆疊後，有許多 AWS OpsWorks 堆疊安全性群組無法刪除。

原因：安全群組必須依照特定順序進行刪除。

解決方案：首先，請確認沒有任何執行個體正在使用安全群組。接著，依照以下順序刪除下列任何安全群組 (若有的話)：

1. AWS-OpsWorks 空白服務器

2. AWS-監控主服務OpsWorks器

3. AWS-DB-OpsWorks 主服務器

4. AWS-快取記憶體伺服OpsWorks器

5. AWS-OpsWorks 自訂伺服器

6. AWS-節點應用程序服務OpsWorks器

7. AWS-PHP-應用程序服務OpsWorks器

8. AWS-軌道應用程序服務OpsWorks器

9. AWS-OpsWorks 網絡服務器

10. AWS-默認服務OpsWorks器

11. AWS-OpsWorks LB-服務器

意外刪除了 AWS OpsWorks 堆疊安全群組

問題：您已刪除其中一個「 AWS OpsWorks 堆疊」安全性群組，並需要重新建立該群組。

原因：這些安全群組通常都是意外遭到刪除。

解決方案：重新建立的群組必須是和原始群組完全一模一樣的複本，其群組名稱也要有相同的大小寫。與其手動重新建立群組，建議的方法為讓 AWS OpsWorks Stacks 為您執行這項任務。只要在同一個 AWS 區域建立新堆疊 — 如果存在 VPC， AWS OpsWorks Stacks 就會自動重新建立所有內建安全群組，包括您刪除的安全群組。您接著可以刪除您不再需要使用的堆疊，安全群組仍會留下。

Chef 日誌無故終止

問題：Chef 日誌無故終止。日誌的最後沒有指出成功執行或顯示異常和堆疊追蹤。

原因：此行為通常是因為記憶體不足。

解決方案：建立更大的執行個體，並使用代理程式 CLI run_command 命令重新執行配方。如需詳細資訊，請參閱 執行配方。

無法更新技術指南

問題：您更新您的技術指南，但堆疊的執行個體仍然執行舊的配方。

原因: AWS OpsWorks 堆棧在每個實例上緩存食譜，並從緩存中運行配方，而不是存儲庫。當您啟動新的執行個體時， AWS OpsWorks Stacks 會將您的食譜從儲存庫下載到執行個體的快取中。但是，若您之後修改您的自訂技術指南， AWS OpsWorks Stacks 不會自動更新線上執行個體的快取。

解決方案：執行「更新 Cookbooks 堆 AWS OpsWorks 疊」命令，明確指示「堆疊」以更新線上執行個體的食譜快取。

執行個體停滯在開機中狀態

問題：當您重新啟動執行個體，或自動修復自動予以重新啟動時，啟動操作停滯在 booting 狀態。

原因：此問題其中一個可能的原因是 VPC 組態，包含預設 VPC。執行個體必須始終能夠與 AWS OpsWorks Stack 服務、Amazon S3 以及套件、食譜和應用程式存放庫進行通訊。例如，如果您從預設 VPC 中移除預設閘道，執行個體就會失去與 AWS OpsWorks 堆疊服務的連線。由於 AWS OpsWorks 堆疊無法再與執行個體代理程式通訊，因此會將執行個體視為失敗並 auto 復執行個體。不過，若沒有連線， AWS OpsWorks Stack 就無法在已修復的執行個體上安裝執行個體代理程式。如果沒有代理程式， AWS OpsWorks 堆疊就無法在執行個體上執行安裝程式方法，因此啟動作業無法進行超出「開機」狀態。

解決方案：修改您的 VPC 組態，讓您的執行個體具備需要的連線能力。

執行個體未預期的重新啟動

問題：已停止的執行個體未預期的重新啟動。

原因 1：如果您已為執行個體啟用 auto 修復功能， AWS OpsWorks Stacks 會定期對關聯的 Amazon EC2 執行個體執行運作狀態檢查，並重新啟動任何運作狀態不良的執行個體。如果您使用 Amazon EC2 主控台、API 或 CLI 停止或終止堆 AWS OpsWorks 疊受管執行個體，則不會通知 AWS OpsWorks 堆疊。因此，它會將已停止的執行個體視為運作狀態不良，並自動重新啟動它。

解決方案：僅使用 AWS OpsWorks Stacks 主控台、API 或 CLI 管理您的執行個體。如果您使用「 AWS OpsWorks 堆疊」來停止或刪除執行個體，則不會重新啟動該執行個體。如需詳細資訊，請參閱 手動啟動、停止和重新開機全年無休的執行個體 及 刪除 AWS OpsWorks 堆疊實例。

原因 2：執行個體可能會因為各種原因而故障。如果您已啟用自 auto 修復， AWS OpsWorks 堆疊會自動重新啟動失敗的執行個體

解決方案：這是一般作業；除非您不希望 AWS OpsWorks Stack 重新啟動失敗的執行個體，否則無需執行任何動作。在這種情況下，建議您停用自動修復。

opsworks-agent 程序在執行個體上執行

問題：您的執行個體上有數個 opsworks-agent 程序正在執行。例如：

aws 24543 0.0 1.3 172360 53332 ? S Feb24 0:29 opsworks-agent: master 24543
aws 24545 0.1 2.0 208932 79224 ? S Feb24 22:02 opsworks-agent: keep_alive of master 24543
aws 24557 0.0 2.0 209012 79412 ? S Feb24 8:04 opsworks-agent: statistics of master 24543
aws 24559 0.0 2.2 216604 86992 ? S Feb24 4:14 opsworks-agent: process_command of master 24

原因：這些是維持代理程式正常操作所需的程序。他們會執行像是處理部署，以及將持續連線訊息傳送回服務等任務。

解決方案：這是正常行為。請不要停止這些程序，否則會影響代理程式的操作。

未預期的 execute_recipes 命令

問題：執行個體詳細資訊頁面上的 Logs (日誌) 區段包含未預期的 execute_recipes 命令。未預期的 execute_recipes 命令也會顯示在 Stack (堆疊) 和 Deployments (部署) 頁面上。

原因：此問題通常是因許可變更而造成。當您變更使用者或群組的安全殼層或 sudo 權限時， AWS OpsWorks Stack 會執行execute_recipes以更新堆疊的執行個體，並觸發 Configuration 事件。另一個 execute_recipes 命令的來源是 AWS OpsWorks Stacks，其會更新執行個體代理程式。

解決方案：這是正常操作，您不需要採取任何行動。

若要查看 execute_recipes 命令執行的動作是什麼，請前往 Deployments (部署) 頁面，然後按一下命令的時間戳記。這會開啟命令的詳細資訊頁面，列出執行的關鍵配方。例如，以下詳細資訊頁面是執行 ssh_users 以更新 SSH 許可的 execute_recipes 命令。

若要查看所有詳細資料，請按一下命令的「記錄」欄中的「顯示」，以顯示關聯的 Chef 記錄。搜尋記錄檔Run List。 AWS OpsWorks 堆棧維護配方將下OpsWorks Custom Run List。例如，以下是在先前螢幕擷取畫面中顯示之 execute_recipes 命令的 run list，顯示每個與命令關聯的配方。

[2014-02-21T17:16:30+00:00] INFO: OpsWorks Custom Run List: ["opsworks_stack_state_sync",
  "ssh_users", "test_suite", "opsworks_cleanup"]