本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # CodeDeploy 故障診斷 使用本節中的主題，以協助解決使用 CodeDeploy 時可能遇到的問題和錯誤。 **注意** 您可以藉由檢閱在部署程序期間建立的日誌檔，識別許多部署故障的原因。為了簡化，我們建議您使用 Amazon CloudWatch Logs 集中監控日誌檔案，而不是依執行個體檢視它們。如需相關資訊，請參閱[使用 Amazon CloudWatch 工具監控部署](monitoring-cloudwatch.md)。 **Topics** + [一般故障診斷問題](troubleshooting-general.md) + [故障診斷 EC2/現場部署問題](troubleshooting-deployments.md) + [對 Amazon ECS 部署問題進行故障診斷](troubleshooting-ecs.md) + [疑難排解 AWS Lambda 部署問題](troubleshooting-deployments-lambda.md) + [對部署群組問題​進行故障診斷](troubleshooting-deployment-groups.md) + [對執行個體問題進行故障診斷](troubleshooting-ec2-instances.md) + [對 GitHub 字符問題進行故障診斷](troubleshooting-github-token-issues.md) + [對 Amazon EC2 Auto Scaling 問題進行故障診斷](troubleshooting-auto-scaling.md) + [的錯誤代碼 AWS CodeDeploy](error-codes.md) # 一般故障診斷問題 **Topics** + [一般故障診斷檢查清單](#troubleshooting-checklist) + [CodeDeploy 部署資源僅在某些 AWS 區域中支援](#troubleshooting-supported-regions) + [本指南中的程序與 CodeDeploy 主控台不相符](#troubleshooting-old-console) + [無法使用必要的 IAM 角色](#troubleshooting-iam-cloudformation) + [使用某些文字編輯器來建立 AppSpec 檔案和 shell 指令碼會導致部署失敗](#troubleshooting-text-editors) + [使用 macOS 的 Finder 套用應用程式修訂可能導致失敗](#troubleshooting-bundle-with-finder) ## 一般故障診斷檢查清單 您可以使用以下檢查清單來排除故障的部署。 1. 請參閱 [檢視 CodeDeploy 部署詳細資訊](deployments-view-details.md) 和 [使用 CodeDeploy 檢視執行個體詳細資訊](instances-view-details.md) 以判斷部署失敗的原因。如果您無法判斷原因，請檢閱此檢查清單中的項目。 1. 請檢查執行個體的設定是否正確： + 是否使用指定的 EC2 金鑰對啟動執行個體？ 如需詳細資訊，請參閱《Amazon [EC2 使用者指南》中的 EC2 金鑰對](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2-key-pairs.html)。 *Amazon EC2 * + 是否已將正確的 IAM 執行個體描述檔連接至執行個體？ 如需詳細資訊，請參閱[設定 Amazon EC2 執行個體以使用 CodeDeploy](instances-ec2-configure.md)及[步驟 4：為您的 Amazon EC2 執行個體建立 IAM 執行個體描述檔](getting-started-create-iam-instance-profile.md)。 + 該執行個體是否有加上標籤？ 如需詳細資訊，請參閱《*Amazon EC2 使用者指南*》[中的在主控台中使用標籤](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console)。 + CodeDeploy 代理程式是否已在執行個體上安裝、更新和執行？ 如需詳細資訊，請參閱[管理 CodeDeploy 代理程式操作](codedeploy-agent-operations.md)。若要檢查已安裝的代理程式版本，請參閱 [判斷 CodeDeploy 代理程式的版本](codedeploy-agent-operations-version.md)。 1. 檢查應用程式和部署群組設定： + 若要查看您的應用程式設定的詳細資訊，請參閱 [使用 CodeDeploy 檢視應用程式詳細資訊](applications-view-details.md)。 + 若要查看您的部署群組設定的詳細資訊，請參閱[使用 CodeDeploy 檢視部署群組詳細資訊](deployment-groups-view-details.md)。 1. 確認是否已正確設定應用程式修訂版： + 檢查 AppSpec 檔案的格式。如需詳細資訊，請參閱[將應用程式規格檔案新增至 CodeDeploy 的修訂版](application-revisions-appspec-file.md)及[CodeDeploy AppSpec 檔案參考](reference-appspec-file.md)。 + 檢查您的 Amazon S3 儲存貯體或 GitHub 儲存庫，確認您的應用程式修訂版位於預期的位置。 + 檢閱 CodeDeploy 應用程式修訂版的詳細資訊，以確保其已正確註冊。如需相關資訊，請參閱[使用 CodeDeploy 檢視應用程式修訂詳細資訊](application-revisions-view-details.md)。 + 如果您是從 Amazon S3 部署，請檢查您的 Amazon S3 儲存貯體，以確認已授予 CodeDeploy 下載應用程式修訂版的許可。如需儲存貯體政策的資訊，請參閱 [部署先決條件](deployments-create-prerequisites.md)。 + 如果您是從 GitHub 部署，請檢查您的 GitHub 儲存庫，以確認 CodeDeploy 已獲得下載應用程式修訂版的許可。如需詳細資訊，請參閱[使用 CodeDeploy 建立部署](deployments-create.md)及[在 CodeDeploy 中使用應用程式進行 GitHub 身分驗證](integrations-partners-github.md#behaviors-authentication)。 1. 檢查服務角色的設定是否正確。如需相關資訊，請參閱[步驟 2：建立 CodeDeploy 的服務角色](getting-started-create-service-role.md)。 1. 確認您依照中 [CodeDeploy 入門](getting-started-codedeploy.md) 的步驟執行： + 已佈建具有適當許可的使用者。 + 選擇安裝或升級，並設定 AWS CLI。 + 建立 IAM 執行個體描述檔和服務角色。 如需詳細資訊，請參閱[的身分和存取管理 AWS CodeDeploy](security-iam.md)。 1. 確認您使用的是 1 AWS CLI .6.1 版或更新版本。若要檢查安裝的版本，請呼叫 **aws --version**。 如果您仍然無法排除故障的部署，請檢閱本主題中的其他問題。 ## CodeDeploy 部署資源僅在某些 AWS 區域中支援 如果您看不到或無法存取來自 或 AWS CLI CodeDeploy 主控台的應用程式、部署群組、執行個體或其他部署資源，請確定您正在參考 區域[和端點](https://docs.aws.amazon.com/general/latest/gr/rande.html#codedeploy_region)中 AWS 列出的其中一個區域*AWS 一般參考*。 在 CodeDeploy 部署中使用的 EC2 執行個體和 Amazon EC2 Auto Scaling 群組必須在其中一個 AWS 區域中啟動和建立。 如果您使用的是 AWS CLI，請從 執行 **aws configure**命令 AWS CLI。然後，您可以檢視和設定預設 AWS 區域。 如果您使用的是 CodeDeploy 主控台，請在導覽列上，從區域選擇器中選擇其中一個支援 AWS 的區域。 **重要** 若要在中國 （北京） 區域或中國 （寧夏） 區域使用 服務，您必須擁有這些區域的 帳戶和登入資料。其他 AWS 區域的帳戶和登入資料不適用於北京和寧夏區域，反之亦然。 此版本的 CodeDeploy *使用者指南中不包含有關中國區域的一些資源的資訊，例如 CodeDeploy Resource Kit 儲存貯體名稱和 CodeDeploy * CodeDeploy 代理程式安裝程序。 如需詳細資訊： 中國 （北京） 區域的 [CodeDeploy](http://docs.amazonaws.cn/en_us/aws/latest/userguide/codedeploy.html) 入門 *[AWS](http://docs.amazonaws.cn/en_us/aws/latest/userguide/introduction.html) * *中國區域的 CodeDeploy 使用者指南 *([英文版本](http://docs.amazonaws.cn/en_us/codedeploy/latest/userguide/welcome.html) \$1 [中文版本](http://docs.amazonaws.cn/codedeploy/latest/userguide/welcome.html)) ## 本指南中的程序與 CodeDeploy 主控台不相符 本指南中的程序反映新的主控台設計。如果您正在使用較舊版本的主控台，本指南中的許多概念和基本程序仍適用 。若要存取新主控台的說明，請選擇資訊圖示。 ## 無法使用必要的 IAM 角色 如果您依賴作為 AWS CloudFormation 堆疊的一部分建立的 IAM 執行個體描述檔或服務角色，如果您刪除堆疊，則所有 IAM 角色也會刪除。這可能是為什麼 IAM 角色不再顯示在 IAM 主控台中，且 CodeDeploy 不再如預期般運作。若要修正此問題，您必須手動重新建立已刪除的 IAM 角色。 ## 使用某些文字編輯器來建立 AppSpec 檔案和 shell 指令碼會導致部署失敗 有些文字編輯器將引進不符合、非列印字元到檔案裡。如果您使用文字編輯器來建立或修改 AppSpec 檔案或 Shell 指令碼檔案，以在 Amazon Linux、Ubuntu Server 或 RHEL 執行個體上執行，則依賴這些檔案的任何部署都可能會失敗。當 CodeDeploy 在部署期間使用這些檔案時，這些字元的存在可能會導致hard-to-troubleshoot的 AppSpec 檔案驗證失敗和指令碼執行失敗。 在 CodeDeploy 主控台中，在部署的事件詳細資訊頁面上，選擇**檢視日誌**。（或者，您可以使用 AWS CLI 呼叫 [get-deployment-instance](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-instance.html) 命令。) 尋找錯誤，例如：`invalid character`、`command not found`，或 `file not found`。 若要解決此問題，我們有以下建議： + 請勿使用會在您的 AppSpec 檔案和 shell 指令碼檔案中加入非列印字元的文字編輯器，例如換行符號 (`^M` 字元)。 + 使用文字編輯器顯示非列印字元，例如 AppSpec 檔案和 shell 指令碼檔案中的換行符號在，因此您可以尋找和移除任何可能加入非列印字元。如需這些類型文字編輯器的範例，請至網際網路搜尋顯示換行符號的文字編輯器。 + 使用在 Amazon Linux、Ubuntu Server 或 RHEL 執行個體上執行的文字編輯器，建立在 Amazon Linux、Ubuntu Server 或 RHEL 執行個體上執行的 shell 指令碼檔案。如需這些類型文字編輯器的範例，請至網際網路搜尋「Linux shell 指令碼編輯器」。 + 如果您必須使用 Windows 或 macOS 中的文字編輯器來建立 shell 指令碼檔案以在 Amazon Linux、Ubuntu Server 或 RHEL 執行個體上執行，請使用程式或公用程式，將 Windows 或 macOS 格式的文字轉換為 Unix 格式。如需這些程式和公用程式的範例，請至網際網路搜尋「DOS 轉換 UNIX」或「Mac 轉換 UNIX」。請務必在目標作業系統上測試轉換過的 shell 指令碼檔案。 ## 使用 macOS 的 Finder 套用應用程式修訂可能導致失敗 如果您在 Mac 上使用 Finder 圖形使用者介面 (GUI) 應用程式將 AppSpec 檔案和相關檔案和指令碼綁定 (zip) 到應用程式修訂版封存檔 (.zip) 檔案中，部署可能會失敗。這是因為 Finder 在 .zip 檔案中建立中繼`__MACOSX`資料夾，並將元件檔案放入其中。CodeDeploy 找不到元件檔案，因此部署失敗。 若要解決此問題，建議您使用 AWS CLI 呼叫 [push](https://docs.aws.amazon.com/cli/latest/reference/deploy/push.html) 命令，將元件檔案壓縮為預期的結構。或者，您可以使用 GUI 的終端機壓縮元件檔案。終端機不會建立中繼 `__MACOSX` 資料夾。 # 故障診斷 EC2/現場部署問題 **Topics** + [CodeDeploy 外掛程式 CommandPoller 缺少登入資料錯誤](#troubleshooting-agent-commandpoller-error) + [部署失敗訊息：「PKCS7 簽章訊息驗證失敗」](#troubleshooting-deployments-agent-SHA-256) + [部署或重新部署相同的檔案到同一個執行個體裡時，發生錯誤訊息「部署失敗，因為指定的檔案已存在於此位置」](#troubleshooting-same-files-different-app-name) + [長檔案路徑會導致「沒有此類檔案或目錄」錯誤](#troubleshooting-long-file-paths) + [長時間執行的程序可能導致部署失敗](#troubleshooting-long-running-processes) + [故障診斷未回報錯誤給部署日誌的 AllowTraffic 生命週期事件失敗](#troubleshooting-deployments-allowtraffic-no-logs) + [故障診斷失敗的 ApplicationStop、 BeforeBlockTraffic 或 AfterBlockTraffic 部署生命週期事件](#troubleshooting-deployments-lifecycle-event-failures) + [故障診斷錯誤訊息為「UnknownError：未開啟讀取」的已失敗 DownloadBundle 部署生命週期事件](#troubleshooting-deployments-downloadbundle) + [對所有生命週期事件略過錯誤進行故障診斷](#troubleshooting-skipped-lifecycle-events) + [Windows PowerShell 指令碼在預設情況下無法使用 64 位元版本的 Windows PowerShell](#troubleshooting-deployments-powershell) **注意** 您可以藉由檢閱在部署程序期間建立的日誌檔，識別許多部署故障的原因。為了簡化，我們建議您使用 Amazon CloudWatch Logs 集中監控日誌檔案，而不是依執行個體檢視它們。如需詳細資訊，請參閱在 [ CloudWatch Logs 主控台中檢視 CodeDeploy 日誌](https://aws.amazon.com/blogs/devops/view-aws-codedeploy-logs-in-amazon-cloudwatch-console/)。 **提示** 如需自動化與 EC2/現場部署相關的許多疑難排解任務的 Runbook，請參閱 *AWS Systems Manager Automation Runbook 參考*中的 [AWSSupport-TroubleshootCodeDeploy](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awssupport-troubleshootcodedeploy.html)。 ## CodeDeploy 外掛程式 CommandPoller 缺少登入資料錯誤 如果您收到與 `InstanceAgent::Plugins::CodeDeployPlugin::CommandPoller: Missing credentials - please check if this instance was started with an IAM instance profile` 類似的錯誤，可能是由以下其中一項造成： + 您部署到的執行個體沒有與其相關聯的 IAM 執行個體描述檔。 + 您的 IAM 執行個體描述檔未設定正確的許可。 IAM 執行個體描述檔會授予 CodeDeploy 代理程式與 CodeDeploy 通訊的許可，以及從 Amazon S3 下載修訂的許可。若為 EC2 執行個體，請參閱[的身分和存取管理 AWS CodeDeploy](security-iam.md)。如需現場部署執行個體的詳細資訊，請參閱 [使用 CodeDeploy 的內部部署執行個體](instances-on-premises.md)。 ## 部署失敗訊息：「PKCS7 簽章訊息驗證失敗」 此錯誤訊息表示執行個體正在執行僅支援 SHA-1 雜湊演算法的 CodeDeploy 代理程式版本。在 2015 年 11 月發行的 CodeDeploy 代理程式 1.0.1.854 版中推出了對 SHA-2 雜湊演算法的支援。 CodeDeploy 自 2016 年 10 月 17 日起，如果安裝的 CodeDeploy 代理程式版本早於 1.0.1.854，則部署會失敗。如需詳細資訊，請參閱[AWS 切換到 SSL 憑證的 SHA256 雜湊演算法](https://aws.amazon.com/security/security-bulletins/aws-to-switch-to-sha256-hash-algorithm-for-ssl-certificates/)、[通知：淘汰 CodeDeploy 1.0.1.85 版之前的主機代理](https://forums.aws.amazon.com/thread.jspa?threadID=223319)程式，以及 [更新 CodeDeploy 代理程式](codedeploy-agent-operations-update.md)。 ## 部署或重新部署相同的檔案到同一個執行個體裡時，發生錯誤訊息「部署失敗，因為指定的檔案已存在於此位置」 當 CodeDeploy 嘗試將檔案部署到執行個體，但具有相同名稱的檔案已存在於指定的目標位置時，該執行個體的部署可能會失敗。您可能會收到「部署失敗，因為指定的檔案已存在於此位置：*location-name*」的錯誤訊息。這是因為在每次部署期間，CodeDeploy 會先刪除先前部署中的所有檔案，這些檔案會列在清除日誌檔案中。如果目標安裝資料夾中有未列在此清除檔案中的檔案，根據預設，CodeDeploy 代理程式會將此解譯為錯誤，並使部署失敗。 **注意** 在 Amazon Linux、RHEL 和 Ubuntu Server 執行個體上，清除檔案位於 中`/opt/codedeploy-agent/deployment-root/deployment-instructions/`。在 Windows Server 執行個體上，位置為 `C:\ProgramData\Amazon\CodeDeploy\deployment-instructions\`。 最簡單防止此錯誤發生的方式是指定選項，以避免預設行為使部署失敗。對於每個部署，您可以選擇是否使部署失敗、是否覆寫這些未列在清除檔案中的檔案，或是否保留已存在於執行個體中的檔案。 覆寫選項功能很實用，例如：在最後一次部署後，您手動將檔案放置到執行個體上，然後新增相同名稱的檔案到下一個應用程式修定版中。 您可以選擇為放置到執行個體的檔案選擇保留選項，選擇您下一個部署想要含有的檔案，此舉一來則可以不用將這些檔案加入到應用程式修訂套件中。如果您的應用程式檔案已在生產環境中，而且您想要第一次使用 CodeDeploy 部署，則保留選項也很有用。如需詳細資訊，請參閱[建立 EC2/現場部署運算平台部署 （主控台）](deployments-create-console.md)及[具有現有內容的轉返行為](deployments-rollback-and-redeploy.md#deployments-rollback-and-redeploy-content-options)。 ### 對 `The deployment failed because a specified file already exists at this location` 部署問題進行故障診斷 如果您選擇不指定選項來覆寫或保留 CodeDeploy 在目標部署位置偵測到的內容 （或者如果您未指定任何部署選項來處理程式設計命令中的現有內容），您可以選擇對錯誤進行疑難排解。 以下資訊僅適用於當您選擇不保留或覆寫內容。 如果您嘗試重新部署具有相同名稱和位置的檔案，則如果您使用先前使用的相同基礎部署群組 ID 指定應用程式名稱和部署群組，則重新部署更有可能成功。CodeDeploy 使用基礎部署群組 ID 來識別要在重新部署之前移除的檔案。 部署新的檔案或重新部署相同的檔案到執行個體上，其失敗的可能原因： + 重新部署同個修訂時，您指定不同的應用程式名稱到同一個執行個體上。重新部署失敗，因為即使部署群組名稱是相同的，但使用不同的應用程式名稱表示使用不同的基礎部署群組 ID。 + 您刪除了應用程式的部署群組後並為其重建，接著嘗試將相同修訂重新部署至該部署群組。重新部署失敗，因為即使部署群組名稱相同，CodeDeploy 也會參考不同的基礎部署群組 ID。 + 您已在 CodeDeploy 中刪除應用程式和部署群組，然後建立與您刪除的應用程式和部署群組名稱相同的新應用程式和部署群組。然後，您嘗試重新部署之前部署到部署群組的修訂到新建立且有相同名稱的部署群組裡。重新部署失敗，因為即使應用程式和部署群組名稱相同，CodeDeploy 仍會參考您刪除的部署群組 ID。 + 您部署修訂到部署群組裡，然後部署相同的修訂至同一個執行個體裡的另一個部署群組。第二個部署失敗，因為 CodeDeploy 參考不同的基礎部署群組 ID。 + 您部署修訂到一個部署群組裡，然後部署另一個的修訂至同一個執行個體裡的另一個部署群組。在相同位置中，至少有一個相同名稱的檔案，在此位置中，第二部署群組會嘗試部署。第二個部署失敗，因為 CodeDeploy 在第二個部署開始之前不會移除現有的檔案。兩種部署 > 參考不同的部署群組 ID。 + 您已在 CodeDeploy 中部署修訂版，但至少有一個檔案具有相同名稱且位於相同位置。部署失敗，因為根據預設，CodeDeploy 在部署開始之前不會移除現有的檔案。 若要解決這些情況，請執行以下其中一項： + 將檔案從先前部署的位置和執行個體中移除，然後再部署一次。 + 在修訂版的 AppSpec 檔案中，在 ApplicationStop 或 BeforeInstall 部署生命週期事件中，指定自訂指令碼來刪除任何位置中符合您修訂版即將安裝之檔案的檔案。 + 部署或重新部署檔案到先前並不屬於部署的位置或執行個體上。 + 在刪除應用程式或部署群組之前，請部署包含 AppSpec 檔案的修訂版，該檔案不會指定要複製到執行個體的檔案。對於部署，指定應用程式名稱和部署群組名稱，其使用相同的基本應用程式和您將要刪除的部署群組相同的 ID。（您可以使用 [get-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-group.html) 命令來擷取部署群組 ID。) CodeDeploy 使用基礎部署群組 ID 和 AppSpec 檔案來移除在先前成功部署中安裝的所有檔案。 ## 長檔案路徑會導致「沒有此類檔案或目錄」錯誤 針對 Windows 執行個體的部署，如果您在 Apppec.yml 檔案的檔案區段中有大於 260 個字元的檔案路徑，您可能會看到部署失敗，並出現類似以下的錯誤： `No such file or directory @ dir_s_mkdir - C:\your-long-file-path` 發生此錯誤是因為 Windows 預設不允許超過 260 個字元的檔案路徑，如 [Microsoft 文件](https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=powershell#enable-long-paths-in-windows-10-version-1607-and-later)中所述。 對於 CodeDeploy 代理程式 1.4.0 版或更新版本，您可以採用兩種方式啟用長檔案路徑，取決於代理程式安裝程序： 如果尚未安裝 CodeDeploy 代理程式： 1. 在您計劃安裝 CodeDeploy 代理程式的機器上，使用此命令啟用 `LongPathsEnabled` Windows 登錄機碼： ``` New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force ``` 1. 安裝 CodeDeploy 代理程式。如需詳細資訊，請參閱[安裝 CodeDeploy 代理程式](codedeploy-agent-operations-install.md)。 如果已安裝 CodeDeploy 代理程式： 1. 在 CodeDeploy 代理程式機器上，使用此命令啟用 `LongPathsEnabled` Windows 登錄機碼： ``` New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force ``` 1. 重新啟動 CodeDeploy 代理程式，讓登錄機碼變更生效。若要重新啟動代理程式，請使用下列命令： ``` powershell.exe -Command Restart-Service -Name codedeployagent ``` ## 長時間執行的程序可能導致部署失敗 對於 Amazon Linux、Ubuntu Server 和 RHEL 執行個體的部署，如果您有啟動長時間執行程序的部署指令碼，CodeDeploy 可能會在部署生命週期事件中花費很長時間等待，然後讓部署失敗。這是因為如果程序執行的時間超過預期該事件中的前景和背景程序，CodeDeploy 會停止並使部署失敗，即使程序仍如預期般執行。 例如，應用程式修訂在其根目錄下包含兩個檔案：`after-install.sh` 和 `sleep.sh`。其 AppSpec 檔案包含下列指示： ``` version: 0.0 os: linux files: - source: ./sleep.sh destination: /tmp hooks: AfterInstall: - location: after-install.sh timeout: 60 ``` `after-install.sh` 檔案會在 AfterInstall 應用程式生命週期事件期間執行。以下是其內容： ``` #!/bin/bash /tmp/sleep.sh ``` `sleep.sh` 檔案包含下列內容，會使程式暫停執行三分鐘 (180 秒)，模擬某些長時間執行的程序： ``` #!/bin/bash sleep 180 ``` 當 `after-install.sh`呼叫 時`sleep.sh`， `sleep.sh`會啟動並執行三分鐘 (180 秒），也就是 CodeDeploy 預期 `sleep.sh`（以及依關聯） 停止執行的兩分鐘 (120 秒`after-install.sh`)。在一分鐘 (60 秒） 逾時後，CodeDeploy 會在 AfterInstall 應用程式生命週期事件停止並失敗部署，即使 `sleep.sh` 繼續如預期般執行。隨即會顯示下列錯誤： `Script at specified location: after-install.sh failed to complete in 60 seconds`. 僅在 `after-install.sh` 中新增 `&` 符號，無法在背景執行 `sleep.sh`。 ``` #!/bin/bash # Do not do this. /tmp/sleep.sh & ``` 這樣做可讓部署處於等待狀態長達預設一小時的部署生命週期事件逾時期間，之後 CodeDeploy 會停止並在 AfterInstall 應用程式生命週期事件中失敗部署。 在 中`after-install.sh`，呼叫 `sleep.sh`，如下所示，這可讓 CodeDeploy 在程序開始執行後繼續： ``` #!/bin/bash /tmp/sleep.sh > /dev/null 2> /dev/null < /dev/null & ``` 在之前的呼叫中，`sleep.sh` 是您希望在背景開始執行的程序名稱，該程序會將 stdout、stderr 和 stdin 重新導向至 `/dev/null`。 ## 故障診斷未回報錯誤給部署日誌的 AllowTraffic 生命週期事件失敗 在某些情況下，在 AllowTraffic 生命週期事件中，藍/綠部署會失敗，但部署日誌中並未指出此失敗之原因。 此失敗通常是由於 Elastic Load Balancing 中用於管理部署群組流量的 Classic Load Balancer、Application Load Balancer 或 Network Load Balancer 運作狀態檢查設定不正確所致。 若要解決該問題，請檢閱和修正負載平衡器的運作狀況檢查裡任何的錯誤。 對於 Classic Load Balancer，請參閱 *Classic Load Balancer 使用者指南*中的[設定運作狀態檢查](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-healthchecks.html)，以及 *Elastic Load Balancing API 參考版本 2012-06-01* 中的 [ConfigureHealthCheck](https://docs.aws.amazon.com/elasticloadbalancing/2012-06-01/APIReference/API_ConfigureHealthCheck.html)。 對於 Application Load Balancer，請參閱 *Application Load Balancer 使用者指南*中的[目標群組的運作狀態檢查](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html)。 對於 Network Load Balancer，請參閱 *Network Load Balancer 使用者指南*中的[目標群組的運作狀態檢查](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-health-checks.html)。 ## 故障診斷失敗的 ApplicationStop、 BeforeBlockTraffic 或 AfterBlockTraffic 部署生命週期事件 在部署期間，CodeDeploy 代理程式會在先前成功部署的 AppSpec 檔案中執行針對 ApplicationStop、 BeforeBlockTraffic 和 AfterBlockTraffic 指定的指令碼。(在目前的部署中，所有其他執行的指令碼皆源自 AppSpec 檔案)。如果這些指令碼中的其中一個包含錯誤且不能執行成功，則部署會失敗。 失敗的可能原因有： + CodeDeploy 代理程式會在正確的位置找到`deployment-group-id_last_successful_install`檔案，但`deployment-group-id_last_successful_install`檔案中列出的位置不存在。 **在 Amazon Linux、Ubuntu Server 和 RHEL 執行個體**上，此檔案必須存在於 中`/opt/codedeploy-agent/deployment-root/deployment-instructions`。 **在 Windows Server 執行個體**上，此檔案必須存放在 `C:\ProgramData\Amazon\CodeDeploy\deployment-instructions` 資料夾中。 + 在 `deployment-group-id_last_successful_install` 檔案中列出的位置中，AppSpec 檔案無效或指令碼無法成功執行。 + 此指令碼內含無法更正的錯誤，所以永遠不會順利執行。 使用 CodeDeploy 主控台來調查部署在這些事件期間可能失敗的原因。在部署的詳細資訊頁面上，選擇 **View events (檢閱事件)**。在執行個體的詳細資訊頁面，請在 **ApplicationStop**、**BeforeBlockTraffic** 或是 **AfterBlockTraffic** 列中，​選擇**檢視日誌**。或使用 AWS CLI 呼叫 [get-deployment-instance](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-instance.html) 命令。 如果失敗原因是來自上一次成功部署但從未順利執行部署當中的指令碼，請建立部署並指定應將 ApplicationStop、BeforeBlockTraffic 和 ​AfterBlockTraffic 失敗予以忽略。有兩種方式可以進行： + 使用 CodeDeploy 主控台建立部署。在 **Create deployment (建立部署)** 頁面，**ApplicationStop lifecycle event failure (ApplicationStop 生命週期事件失敗)** 下，請選擇 **Don't fail the deployment to an instance if this lifecycle event on the instance fails (勿失敗部署到執行個體上，若此生命週期事件在執行個體裡失敗)**。 + 使用 AWS CLI 呼叫 **[create-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html)**命令並包含 `--ignore-application-stop-failures`選項。 當您再次部署應用程式修訂，此部署會持續，即使這三個生命週期事件中的任何一個故障。如果新的修訂版包含這些生命週期事件的修正指令碼，則未來部署可在不套用此修正而成功執行。 ## 故障診斷錯誤訊息為「UnknownError：未開啟讀取」的已失敗 DownloadBundle 部署生命週期事件 如果您嘗試從 Amazon S3 部署應用程式修訂版，且部署在 DownloadBundle 部署生命週期事件期間失敗，並發生錯誤`UnknownError: not opened for reading`： + 發生內部 Amazon S3 服務錯誤。請再次部署應用程式修訂。 + EC2 執行個體上的 IAM 執行個體描述檔沒有存取 Amazon S3 中應用程式修訂版的許可。如需 Amazon S3 儲存貯體政策的詳細資訊，請參閱 [將 CodeDeploy 的修訂推送至 Amazon S3 （僅限 EC2/內部部署部署）](application-revisions-push.md)和 [部署先決條件](deployments-create-prerequisites.md)。 + 您部署到的執行個體與一個 AWS 區域 （例如，美國西部 （奧勒岡）) 相關聯，但包含應用程式修訂的 Amazon S3 儲存貯體與另一個 AWS 區域 （例如，美國東部 （維吉尼亞北部）) 相關聯。請確定應用程式修訂版位於與執行個體相同 AWS 區域相關聯的 Amazon S3 儲存貯體中。 在部署的事件詳細資訊頁面，於 **Download bundle (下載套用)** 列，選取 **View logs (檢視日誌)**。或使用 AWS CLI 呼叫 [get-deployment-instance](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-instance.html) 命令。如果發生此錯誤，輸出中應出現錯誤碼為 `UnknownError` 和錯誤訊息為 `not opened for reading` 的錯誤。 判斷此錯誤的原因： 1. 在至少一個執行個體上啟用有線登入，然後再部署應用程式修訂一次。 1. 檢查有線日誌檔尋找錯誤。此問題的常見錯誤訊息包含「拒絕存取」。 1. 檢查完日誌檔案後，我們建議您停用線路日誌記錄，以減少日誌檔案大小以及未來在執行個體上以純文字形式顯示在輸出中的敏感資訊量。 如需有關如何尋找線路記錄檔案以及啟用和停用線路記錄的資訊，請參閱 [CodeDeploy 代理程式組態參考](https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-agent-configuration.html)`:log_aws_wire:`中的 。 ## 對所有生命週期事件略過錯誤進行故障診斷 如果略過 EC2 或內部部署的所有生命週期事件，您可能會收到類似 的錯誤`The overall deployment failed because too many individual instances failed deployment, too few healthy instances are available for deployment, or some instances in your deployment group are experiencing problems. (Error code: HEALTH_CONSTRAINTS)`。以下是一些可能的原因和解決方案： + CodeDeploy 代理程式可能不會在執行個體上安裝或執行。若要判斷 CodeDeploy 代理程式是否正在執行： + 對於 Amazon Linux RHEL 或 Ubuntu 伺服器，請執行下列動作： ``` systemctl status codedeploy-agent ``` + 對於 Windows，請執行下列動作： ``` powershell.exe -Command Get-Service -Name CodeDeployagent ``` 如果 CodeDeploy 代理程式未安裝或執行，請參閱 [驗證 CodeDeploy 代理程式是否正在執行](codedeploy-agent-operations-verify.md)。 您的執行個體可能無法使用連接埠 443 連線到 CodeDeploy 或 Amazon S3 公有端點。 Amazon S3 請嘗試執行下列其中一項操作： + 將公有 IP 地址指派給執行個體，並使用其路由表允許網際網路存取。請確定與執行個體關聯的安全群組允許透過連接埠 443 (HTTPS) 進行對外存取。如需詳細資訊，請參閱[CodeDeploy 代理程式的通訊協定和連接埠](codedeploy-agent.md#codedeploy-agent-outbound-port)。 + 如果執行個體是在私有子網路中佈建的，則使用 NAT 閘道，而非路由表中的網際網路閘道。如需更多詳細資訊，請參閱 [NAT 閘道](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)。 + CodeDeploy 的服務角色可能沒有必要的許可。若要設定 CodeDeploy 服務角色，請參閱 [步驟 2：建立 CodeDeploy 的服務角色](getting-started-create-service-role.md)。 + 如果您使用 HTTP 代理，請確定已在 CodeDeploy 代理程式組態檔案中`:proxy_uri:`的設定中指定。如需詳細資訊，請參閱[CodeDeploy 代理程式組態參考](reference-agent-configuration.md)。 + 您部署執行個體的日期和時間簽章，可能不符合您部署請求的日期和時間簽章。在 CodeDeploy 代理程式日誌檔案中尋找類似 `Cannot reach InstanceService: Aws::CodeDeployCommand::Errors::InvalidSignatureException - Signature expired`的錯誤。如果您看到此錯誤，請遵循以下步驟 [對 “InvalidSignatureException – Signature expired: [time] is now earlier than [time]” 部署錯誤進行故障診斷](troubleshooting-ec2-instances.md#troubleshooting-instance-time-failures)。如需詳細資訊，請參閱[檢視 CodeDeploy EC2/現場部署的日誌資料](deployments-view-logs.md)。 + CodeDeploy 代理程式可能會停止執行，因為執行個體的記憶體或硬碟空間不足。透過更新 CodeDeploy 代理程式組態中的 `max_revisions`設定，嘗試降低執行個體上封存部署的數量。如果您為 EC2 執行個體執行此操作，但問題仍然存在，請考慮使用較大的執行個體。例如，如果您的執行個體類型是 `t2.small`，請嘗試使用 `t2.medium`。如需詳細資訊，請參閱 [CodeDeploy 代理程式安裝的檔案](codedeploy-agent.md#codedeploy-agent-install-files)、 [CodeDeploy 代理程式組態參考](reference-agent-configuration.md)和[執行個體類型](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)。 + 您要部署的執行個體可能未連接 IAM 執行個體描述檔，或者可能已連接沒有必要許可的 IAM 執行個體描述檔。 + 如果 IAM 執行個體描述檔未連接到您的執行個體，請建立具有所需許可的執行個體描述檔，然後連接它。 + 如果 IAM 執行個體描述檔已連接至您的執行個體，請確定其具有必要的許可。 在您確定連接的執行個體描述檔已設定所需許可後，請重新啟動您的執行個體。如需詳細資訊，請參閱《Amazon EC2 使用者指南》中的 [步驟 4：為您的 Amazon EC2 執行個體建立 IAM 執行個體描述檔](getting-started-create-iam-instance-profile.md)和 Amazon EC2 的 IAM 角色。 [ Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-EC2.html) *Amazon EC2 * ## Windows PowerShell 指令碼在預設情況下無法使用 64 位元版本的 Windows PowerShell 如果做為部署一部分執行的 Windows PowerShell 指令碼依賴 64 位元功能 (例如，因為該指令碼佔用多於 32 位元應用程式允許的記憶體，或呼叫的程式庫僅在 64 位元版本中提供)，則指令碼可能會當機或無法按預期執行。這是因為 CodeDeploy 預設會使用 32 位元版本的 Windows PowerShell 來執行屬於應用程式修訂一部分的 Windows PowerShell 指令碼。 將類似下述的程式碼，新增至必須使用 64 位元版本 Windows PowerShell 執行的任何指令碼開頭： ``` # Are you running in 32-bit mode? # (\SysWOW64\ = 32-bit mode) if ($PSHOME -like "*SysWOW64*") { Write-Warning "Restarting this script under 64-bit Windows PowerShell." # Restart this script under 64-bit Windows PowerShell. # (\SysNative\ redirects to \System32\ for 64-bit mode) & (Join-Path ($PSHOME -replace "SysWOW64", "SysNative") powershell.exe) -File ` (Join-Path $PSScriptRoot $MyInvocation.MyCommand) @args # Exit 32-bit script. Exit $LastExitCode } # Was restart successful? Write-Warning "Hello from $PSHOME" Write-Warning " (\SysWOW64\ = 32-bit mode, \System32\ = 64-bit mode)" Write-Warning "Original arguments (if any): $args" # Your 64-bit script code follows here... # ... ``` 儘管此程式碼中的檔案路徑資訊看起來可能違反直覺，但 32 位元 Windows PowerShell 使用類似下述的路徑： `c:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe` 64 位元 Windows PowerShell 使用類似下述的路徑： `c:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe` # 對 Amazon ECS 部署問題進行故障診斷 **Topics** + [等待替換任務集時發生逾時](#troubleshooting-ecs-timeout) + [等待通知繼續時發生逾時](#troubleshooting-ecs-timeout-notif) + [IAM 角色沒有足夠的許可](#troubleshooting-ecs-iam) + [部署在等待狀態回呼時逾時](#troubleshooting-ecs-timeout-callback) + [部署失敗，因為一或多個生命週期事件驗證函數失敗](#troubleshooting-ecs-lifecycle) + [由於下列錯誤，ELB 無法更新：主要任務集目標群組必須位於接聽程式後方](#troubleshooting-ecs-elb) + [使用 Auto Scaling 時，我的部署有時會失敗](#troubleshooting-ecs-auto-scaling) + [只有 ALB 支援逐步流量路由，請在建立/更新部署群組時使用 AllAtOnce 流量路由](#troubleshooting-ecs-lb) + [即使我的部署成功，替代任務集仍無法通過 Elastic Load Balancing 運作狀態檢查，而且我的應用程式已關閉](#troubleshooting-ecs-task-set-stability) + [我可以將多個負載平衡器連接到部署群組嗎？](#troubleshooting-ecs-lb-multi) + [我可以在沒有負載平衡器的情況下執行 CodeDeploy 藍/綠部署嗎？](#troubleshooting-ecs-lb-bg) + [如何在部署期間使用新資訊更新 Amazon ECS 服務？](#troubleshooting-ecs-exec) ## 等待替換任務集時發生逾時 **問題**：使用 CodeDeploy 部署 Amazon ECS 應用程式時，您會看到下列錯誤訊息： `The deployment timed out while waiting for the replacement task set to become healthy. This time out period is 60 minutes.` **可能原因**：如果您的任務定義檔案或其他部署相關檔案發生錯誤，可能會發生此錯誤。例如，如果您的任務定義檔案中的 `image` 欄位有錯別字，Amazon ECS 會嘗試提取錯誤的容器映像並持續失敗，導致此錯誤。 **可能的修正和後續步驟**： + 修正任務定義檔案和其他檔案中的印刷錯誤和組態問題。 + 檢查相關的 Amazon ECS 服務事件，並了解取代任務無法正常運作的原因。如需 Amazon ECS 事件的詳細資訊，請參閱《[Amazon Elastic Container Service 開發人員指南》中的 Amazon ECS 事件](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)。 ** + 請參閱《[Amazon Elastic Container Service 開發人員指南》中的 Amazon ECS 疑難排解](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshooting.html)一節，了解與事件中訊息相關的錯誤。 ** ## 等待通知繼續時發生逾時 **問題**：使用 CodeDeploy 部署 Amazon ECS 應用程式時，您會看到下列錯誤訊息： `The deployment timed out while waiting for a notification to continue. This time out period is n minutes.` **可能原因**：如果您在建立部署群組時在**指定重新路由流量**欄位中指定等待時間，但部署無法在等待時間過期之前完成，則可能會發生此錯誤。 **可能的修正和後續步驟**： + 在您的部署群組中，設定**指定何時將流量重新路由**到更長的時間並重新部署。如需詳細資訊，請參閱[建立 Amazon ECS 部署的部署群組 （主控台）](deployment-groups-create-ecs.md)。 + 在您的部署群組中，變更**指定何時立即將流量重新路由**至**重新路由流量**並重新部署。如需詳細資訊，請參閱[建立 Amazon ECS 部署的部署群組 （主控台）](deployment-groups-create-ecs.md)。 + 重新部署 ，然後執行 [https://docs.aws.amazon.com/cli/latest/reference/deploy/continue-deployment.html](https://docs.aws.amazon.com/cli/latest/reference/deploy/continue-deployment.html) AWS CLI 命令，並將 `--deployment-wait-type`選項設定為 `READY_WAIT`。請務必在**指定何時重新路由流量**過期中指定的時間*之前*執行此命令。 ## IAM 角色沒有足夠的許可 **問題**：使用 CodeDeploy 部署 Amazon ECS 應用程式時，您會看到下列錯誤訊息： `The IAM role role-arn does not give you permission to perform operations in the following AWS service: AWSLambda.` **可能原因**：如果您在 [AppSpec 檔案的 `Hooks`區段](reference-appspec-file-structure-hooks.md#appspec-hooks-ecs)中指定 Lambda 函數，但未將 CodeDeploy 許可授予 Lambda 服務，則可能會發生此錯誤。 **可能修正**：將 `lambda:InvokeFunction` 許可新增至 CodeDeploy 服務角色。若要新增此許可，請將下列其中一個 AWS受管政策新增至角色： **AWSCodeDeployRoleForECS**或 **AWSCodeDeployRoleForECSLimited**。如需這些政策以及如何將其新增至 CodeDeploy 服務角色的詳細資訊，請參閱 [步驟 2：建立 CodeDeploy 的服務角色](getting-started-create-service-role.md)。 ## 部署在等待狀態回呼時逾時 **問題**：使用 CodeDeploy 部署 Amazon ECS 應用程式時，您會看到下列錯誤訊息： `The deployment timed out while waiting for a status callback. CodeDeploy expects a status callback within one hour after a deployment hook is invoked.` **可能原因**：如果您在 [AppSpec 檔案的 `Hooks`區段](reference-appspec-file-structure-hooks.md#appspec-hooks-ecs)中指定 Lambda 函數，但 Lambda 函數無法呼叫必要的 `PutLifecycleEventHookExecutionStatus` API 將 `Succeeded`或 `Failed` 狀態傳回 CodeDeploy，則可能會發生此錯誤。 **可能的修正和後續步驟**： + 將 `codedeploy:putlifecycleEventHookExecutionStatus` 許可新增至您在 AppSpec 檔案中指定的 Lambda 函數所使用的 Lambda 執行角色。此許可授予 Lambda 函數將 `Succeeded`或 狀態傳回 `Failed` CodeDeploy 的能力。如需 Lambda 執行角色的詳細資訊，請參閱*AWS Lambda 《 使用者指南*》中的 [Lambda 執行角色](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)。 + 檢查您的 Lambda 函數程式碼和執行日誌，確認您的 Lambda 函數正在呼叫 CodeDeploy 的 `PutLifecycleEventHookExecutionStatus` API，以通知 CodeDeploy 生命週期驗證測試`Succeeded`或 `Failed`。如需 `putlifecycleEventHookExecutionStatus` API 的相關資訊，請參閱*AWS CodeDeploy 《 API 參考*》中的 [PutLifecycleEventHookExecutionStatus](https://docs.aws.amazon.com/codedeploy/latest/APIReference/API_PutLifecycleEventHookExecutionStatus.html)。如需 Lambda 執行日誌的資訊，請參閱[存取 Amazon CloudWatch logs AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html)。 ## 部署失敗，因為一或多個生命週期事件驗證函數失敗 **問題**：使用 CodeDeploy 部署 Amazon ECS 應用程式時，您會看到下列錯誤訊息： `The deployment failed because one or more of the lifecycle event validation functions failed.` **可能原因**：如果您在 [AppSpec 檔案的 `Hooks`區段](reference-appspec-file-structure-hooks.md#appspec-hooks-ecs)中指定 Lambda 函數，但 Lambda 函數在呼叫 時傳回 `Failed` CodeDeploy，則可能會發生此錯誤`PutLifecycleEventHookExecutionStatus`。此失敗會向 CodeDeploy 指出生命週期驗證測試失敗。 **可能的後續步驟**：檢查您的 Lambda 執行日誌，了解驗證測試程式碼失敗的原因。如需 Lambda 執行日誌的資訊，請參閱[存取 Amazon CloudWatch logs AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html)。 ## 由於下列錯誤，ELB 無法更新：主要任務集目標群組必須位於接聽程式後方 **問題**：使用 CodeDeploy 部署 Amazon ECS 應用程式時，您會看到下列錯誤訊息： `The ELB could not be updated due to the following error: Primary taskset target group must be behind listener` **可能原因**：如果您已設定選用的測試接聽程式，且設定的目標群組錯誤，則可能會發生此錯誤。如需 CodeDeploy 中測試接聽程式的詳細資訊，請參閱 [開始 Amazon ECS 部署之前](deployment-steps-ecs.md#deployment-steps-prerequisites-ecs)和 [Amazon ECS 部署期間會發生什麼情況](deployment-steps-ecs.md#deployment-steps-what-happens)。如需任務集的詳細資訊，請參閱《*Amazon Elastic Container Service API 參考*》中的 [TaskSet](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_TaskSet.html)，以及《 *AWS CLI 命令參考*》Amazon ECS 區段中的 [describe-task-set](https://docs.aws.amazon.com/cli/latest/reference/ecs/describe-task-set.html)。 **可能修正**：確定 Elastic Load Balancing 的生產接聽程式和測試接聽程式都指向目前為您的工作負載提供服務的目標群組。有三個地方可以檢查： + 在 Amazon EC2 中，在負載平衡器的**接聽程式和規則**設定中。如需詳細資訊，請參閱《[Application Load Balancer 使用者指南](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html)》中的 *Application Load Balancer *接聽程式，或[《Network Load Balancer 使用者指南》中的 Network Load Balancer 接聽](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-listeners.html)程式。 ** + 在 Amazon ECS 中，在您的叢集中，在您的服務**的網路**組態下。如需詳細資訊，請參閱《*Amazon Elastic Container Service 開發人員指南*》中的 [Application Load Balancer 和 Network Load Balancer 考量](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/load-balancer-types.html#alb-considerations)事項。 + 在 CodeDeploy 的部署群組設定中。如需詳細資訊，請參閱[建立 Amazon ECS 部署的部署群組 （主控台）](deployment-groups-create-ecs.md)。 ## 使用 Auto Scaling 時，我的部署有時會失敗 **問題**：您使用 Auto Scaling 搭配 CodeDeploy，並注意到您的部署偶爾會失敗。如需此問題症狀的詳細資訊，請參閱《*Amazon Elastic Container Service 開發人員指南*》中的 主題：[針對設定為使用服務自動擴展和藍/綠部署類型的服務，自動擴展不會在部署期間遭到封鎖，但在某些情況下部署可能會失敗](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-type-bluegreen.html#deployment-type-bluegreen-considerations)。 **可能原因**：如果 CodeDeploy 和 Auto Scaling 程序發生衝突，可能會發生此問題。 **可能修正**：使用 `RegisterScalableTarget` API （或對應的`register-scalable-target` AWS CLI 命令） 在 CodeDeploy 部署期間暫停和繼續 Auto Scaling 程序。如需詳細資訊，請參閱《[Application Auto Scaling 使用者指南》中的暫停和恢復](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-suspend-resume-scaling.html) *Application Auto Scaling *的擴展。 **注意** CodeDeploy 無法`RegisterScaleableTarget`直接呼叫 。若要使用此 API，您必須設定 CodeDeploy 將通知或事件傳送至 Amazon Simple Notification Service （或 Amazon CloudWatch)。然後，您必須將 Amazon SNS （或 CloudWatch) 設定為呼叫 Lambda 函數，並將 Lambda 函數設定為呼叫 `RegisterScalableTarget` API。必須呼叫 `RegisterScalableTarget` API，並將 `SuspendedState` 參數設為 `true`以暫停 Auto Scaling 操作，並繼續`false`操作。 CodeDeploy 傳送的通知或事件必須在部署開始 （觸發 Auto Scaling 暫停操作） 或部署成功、失敗或停止 （觸發 Auto Scaling 繼續操作） 時發生。 如需如何設定 CodeDeploy 以產生 Amazon SNS 通知或 CloudWatch 事件的詳細資訊，請參閱 [使用 Amazon CloudWatch Events 監控部署](monitoring-cloudwatch-events.md)。 和 [使用 Amazon SNS 事件通知監控部署](monitoring-sns-event-notifications.md)。 ## 只有 ALB 支援逐步流量路由，請在建立/更新部署群組時使用 AllAtOnce 流量路由 **問題**：在 CodeDeploy 中建立或更新部署群組時，您會看到下列錯誤訊息： `Only ALB supports gradual traffic routing, use AllAtOnce Traffic routing instead when you create/update Deployment group.` **可能原因**：如果您使用 Network Load Balancer 並嘗試使用 以外的預先定義部署組態，則可能會發生此錯誤`CodeDeployDefault.ECSAllAtOnce`。 **可能的修正：** + 將預先定義的部署組態變更為 `CodeDeployDefault.ECSAllAtOnce`。這是 Network Load Balancer 唯一支援的預先定義部署組態。 如需預先定義部署組態的詳細資訊，請參閱 [Amazon ECS 運算平台的預先定義部署組態](deployment-configurations.md#deployment-configurations-predefined-ecs)。 + 將負載平衡器變更為 Application Load Balancer。Application Load Balancer 的 支援所有預先定義的部署組態。如需建立 Application Load Balancer 的詳細資訊，請參閱 [設定 CodeDeploy Amazon ECS 部署的負載平衡器、目標群組和接聽程式](deployment-groups-create-load-balancer-for-ecs.md)。 ## 即使我的部署成功，替代任務集仍無法通過 Elastic Load Balancing 運作狀態檢查，而且我的應用程式已關閉 **問題**：即使 CodeDeploy 指出我的部署成功，替代任務集仍無法通過 Elastic Load Balancing 的運作狀態檢查，而且我的應用程式已關閉。 **可能原因**：如果您執行 CodeDeploy all-at-once部署，且取代 （綠色） 任務集包含導致 Elastic Load Balancing 運作狀態檢查失敗的錯誤程式碼，則可能會發生此問題。使用all-at-once部署組態時，負載平衡器的運作狀態檢查會在流量轉移到替代任務集*後* （即 CodeDeploy 的`AllowTraffic`生命週期事件發生*後*) 開始執行。這就是為什麼在流量轉移之後，您會在替代任務集上看到運作狀態檢查失敗，但之前不會失敗。如需 CodeDeploy 產生之生命週期事件的相關資訊，請參閱 [Amazon ECS 部署期間會發生什麼情況](deployment-steps-ecs.md#deployment-steps-what-happens)。 **可能的修正：** + 將您的部署組態從all-at-once變更為 Canary 或線性。在 Canary 或線性組態中，負載平衡器的運作狀態檢查會在取代任務集上開始執行，同時 CodeDeploy 會在取代環境中安裝您的應用程式，並在流量轉移*之前* （即`Install`生命週期事件期間和`AllowTraffic`事件*之前*)。透過允許檢查在應用程式安裝期間執行，但在流量轉移之前，將偵測到錯誤的應用程式程式碼，並在應用程式公開可用之前導致部署失敗。 如需如何設定 Canary 或線性部署的資訊，請參閱 [使用 CodeDeploy 變更部署群組設定](deployment-groups-edit.md)。 如需在 Amazon ECS 部署期間執行之 CodeDeploy 生命週期事件的相關資訊，請參閱 [Amazon ECS 部署期間會發生什麼情況](deployment-steps-ecs.md#deployment-steps-what-happens)。 **注意** Canary 和線性部署組態僅支援 Application Load Balancer。 + 如果您想要保留all-at-once部署組態，請設定測試接聽程式，並使用`BeforeAllowTraffic`生命週期掛鉤檢查替換任務集的運作狀態。如需詳細資訊，請參閱[Amazon ECS 部署的生命週期事件掛鉤清單](reference-appspec-file-structure-hooks.md#reference-appspec-file-structure-hooks-list-ecs)。 ## 我可以將多個負載平衡器連接到部署群組嗎？ 否。如果您想要使用多個 Application Load Balancer 或 Network Load Balancer，請使用 Amazon ECS 滾動更新，而不是 CodeDeploy 藍/綠部署。如需滾動更新的詳細資訊，請參閱《*Amazon Elastic Container Service 開發人員指南*》中的[滾動更新](https://docs.aws.amazon.com/AmazonECS/latest/userguide/deployment-type-ecs.html)。如需搭配 Amazon ECS 使用多個負載平衡器的詳細資訊，請參閱《*Amazon Elastic Container Service 開發人員指南*》中的[向服務註冊多個目標群組](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/register-multiple-targetgroups.html)。 ## 我可以在沒有負載平衡器的情況下執行 CodeDeploy 藍/綠部署嗎？ 否，如果沒有負載平衡器，您就無法執行 CodeDeploy 藍/綠部署。如果您無法使用負載平衡器，請改用 Amazon ECS 的滾動更新功能。如需 Amazon ECS 滾動更新的詳細資訊，請參閱《*Amazon Elastic Container Service 開發人員指南*》中的[滾動更新](https://docs.aws.amazon.com/AmazonECS/latest/userguide/deployment-type-ecs.html)。 ## 如何在部署期間使用新資訊更新 Amazon ECS 服務？ 若要讓 CodeDeploy 在執行部署時使用新參數更新您的 Amazon ECS 服務，請在 AppSpec 檔案的 `resources`區段中指定 參數。CodeDeploy 僅支援幾個 Amazon ECS 參數，例如任務定義檔案和容器名稱參數。如需 CodeDeploy 可更新之 Amazon ECS 參數的完整清單，請參閱 [Amazon ECS 部署的 AppSpec 'resources' 區段](reference-appspec-file-structure-resources.md#reference-appspec-file-structure-resources-ecs)。 **注意** 如果您需要使用 CodeDeploy 不支援的參數來更新 Amazon ECS 服務，請完成下列任務： 使用您要更新的參數呼叫 Amazon ECS 的 `UpdateService` API。如需可更新參數的完整清單，請參閱《*Amazon Elastic Container Service API 參考*》中的 [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)。 若要將變更套用至任務，請建立新的 Amazon ECS 藍/綠部署。如需詳細資訊，請參閱[建立 Amazon ECS 運算平台部署 （主控台）](deployments-create-console-ecs.md)。 # 疑難排解 AWS Lambda 部署問題 **Topics** + [AWS Lambda 部署會在手動停止尚未設定轉返的 Lambda 部署後失敗](#troubleshooting-manually-stopped-lambda-deployment) ## AWS Lambda 部署會在手動停止尚未設定轉返的 Lambda 部署後失敗 在某些情況下，部署中指定的 Lambda 函數別名可能會參考函數的兩個不同版本。結果是後續嘗試部署 Lambda 函數失敗。當 Lambda 部署未設定轉返且手動停止時，可能會進入此狀態。若要繼續，請使用 AWS Lambda 主控台來確定 函數未設定為在兩個版本之間轉移流量： 1. 登入 AWS 管理主控台 ，並在 https：//[https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/) 開啟 AWS Lambda 主控台。 1. 從左側窗格中，選擇 **Functions (函數)**。 1. 選取 CodeDeploy 部署中 Lambda 函數的名稱。 1. 從**別名**中，選擇 CodeDeploy 部署中使用的別名，然後選擇**編輯**。 1. 從**加權別名**中，選擇 **none**。這可確保不會將別名設定為將流量的百分比或權重轉移至多個版本。請記錄在 **Version (版本)** 中選取的版本。 1. 選擇**儲存**。 1. 開啟 CodeDeploy 主控台，並嘗試部署步驟 5 下拉式功能表中顯示的版本。 # 對部署群組問題​進行故障診斷 ## 將執行個體加入標籤做為部署群組的一部分，不會自動將應用程式部署至新執行個體 CodeDeploy 不會自動將您的應用程式部署到新標記的執行個體。您必須在部署群組中建立新的部署。 您可以使用 CodeDeploy 來啟用自動部署至 Amazon EC2 Auto Scaling 群組中的新 EC2 執行個體。 Amazon EC2 如需詳細資訊，請參閱[將 CodeDeploy 與 Amazon EC2 Auto Scaling 整合](integrations-aws-auto-scaling.md)。 # 對執行個體問題進行故障診斷 **Topics** + [標籤必須正確設定](#troubleshooting-EC2-tags) + [AWS CodeDeploy 代理程式必須在執行個體上安裝並執行](#troubleshooting-sds-agent) + [如果執行個體在部署期間終止，在最多一小時內部署不會失敗](#troubleshooting-one-hour-timeout) + [分析日誌檔案以調查執行個體的部署失敗](#troubleshooting-deploy-failures) + [如果不小心刪除新的 CodeDeploy 日誌檔案](#troubleshooting-create-new-log-file) + [對 “InvalidSignatureException – Signature expired: [time] is now earlier than [time]” 部署錯誤進行故障診斷](#troubleshooting-instance-time-failures) ## 標籤必須正確設定 使用 [list-deployment-instances](https://docs.aws.amazon.com/cli/latest/reference/deploy/list-deployment-instances.html) 命令，確認用於部署的執行個體已正確標記。如果輸出中缺少 EC2 執行個體，請使用 EC2 主控台確認已在執行個體上設定標籤。如需詳細資訊，請參閱《*Amazon EC2 使用者指南*》中的[在主控台中使用標籤](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console)。 **注意** 如果您標記執行個體並立即使用 CodeDeploy 來部署應用程式，則執行個體可能不會包含在部署中。這是因為可能需要幾分鐘的時間CodeDeploy 才能讀取標籤。建議您在為執行個體套用標籤與嘗試對執行個體進行部署之間等待至少五分鐘。 ## AWS CodeDeploy 代理程式必須在執行個體上安裝並執行 若要驗證是否已在執行個體上安裝和執行 CodeDeploy 代理程式，請參閱 [驗證 CodeDeploy 代理程式是否正在執行](codedeploy-agent-operations-verify.md)。 若要安裝、解除安裝或重新安裝 CodeDeploy 代理程式，請參閱 [安裝 CodeDeploy 代理程式](codedeploy-agent-operations-install.md)。 ## 如果執行個體在部署期間終止，在最多一小時內部署不會失敗 CodeDeploy 為每個要執行到完成的部署生命週期事件提供一小時的時段。這為長時間執行的指令碼提供足夠的時間。 如果指令碼在生命週期事件進行時未執行到完成 （例如，如果執行個體已終止或 CodeDeploy 代理程式已關閉），部署狀態最多可能需要一小時才會顯示為失敗。即使在指令碼中指定的逾時期間短於一小時，也會發生此情況。這是因為當執行個體終止時，CodeDeploy 代理程式會關閉且無法處理更多指令碼。 如果執行個體在生命週期事件之間或在第一個生命週期事件步驟開始之前終止，逾時將在五分鐘後發生。 ## 分析日誌檔案以調查執行個體的部署失敗 如果部署中的執行個體具有 `Succeeded` 以外的任何狀態，您可以檢閱部署日誌檔案資料來協助識別問題。如需存取部署日誌資料的詳細資訊，請參閱[檢視 CodeDeploy EC2/現場部署的日誌資料](deployments-view-logs.md)。 ## 如果不小心刪除新的 CodeDeploy 日誌檔案 如果您意外刪除執行個體上的部署日誌檔案，CodeDeploy 不會建立替代日誌檔案。若要建立新的日誌檔案，請登入執行個體，然後執行這些命令： **對於 Amazon Linux、Ubuntu Server 或 RHEL 執行個體**，請依序執行這些命令，一次一個： ``` systemctl stop codedeploy-agent ``` ``` systemctl start codedeploy-agent ``` **對於 Windows Server 執行個體**： ``` powershell.exe -Command Restart-Service -Name codedeployagent ``` ## 對 “InvalidSignatureException – Signature expired: [time] is now earlier than [time]” 部署錯誤進行故障診斷 CodeDeploy 需要準確的時間參考來執行其操作。如果執行個體上的日期和時間未正確設定，則可能不符合 CodeDeploy 拒絕的部署請求的簽章日期。 若要避免與時間設定不正確相關的部署失敗，請參閱下列主題： + [設定您 Linux 執行個體的時間](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html) + [設定 Windows 執行個體的時間](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/windows-set-time.html) # 對 GitHub 字符問題進行故障診斷 ## 無效的 GitHub OAuth 字符 2017 年 6 月之後建立的 CodeDeploy 應用程式會 AWS 為每個區域使用 GitHub OAuth 權杖。使用與特定 AWS 區域繫結的字符可讓您更妥善地控制哪些 CodeDeploy 應用程式可存取 GitHub 儲存庫。 如果您收到 GitHub 字符錯誤，可能是因為您擁有現在已無效的較舊字符。 **修正無效的 GitHub OAuth 字符** 1. 使用下列其中一種方法移除舊字符： + 若要使用 API 移除舊字符，請使用 [ DeleteGitHubAccountToken](https://docs.aws.amazon.com/codedeploy/latest/APIReference/API_DeleteGitHubAccountToken.html)。 + 若要使用 移除舊字符 AWS Command Line Interface： 1. 前往字符所在的電腦。 1. 確定此電腦上 AWS CLI 已安裝 。如需安裝說明，請參閱*AWS Command Line Interface 《 使用者指南*》中的[安裝、更新和解除安裝 AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) 1. 在字符所在的電腦上輸入下列命令： **aws delete-git-hub-account-token** 如需命令語法的詳細資訊，請參閱 [delete-git-hub-account-token](https://docs.aws.amazon.com/cli/latest/reference/deploy/delete-git-hub-account-token.html)。 1. 新增新的 OAuth 字符。如需詳細資訊，請參閱[將 CodeDeploy 與 GitHub 整合](integrations-partners-github.md)。 ## GitHub OAuth 字符超出數量上限 當您建立 CodeDeploy 部署時，允許的 GitHub 權杖數目上限為 10。如果您收到 GitHub OAuth 字符錯誤，請確保您的字符不高於 10 個。如果您有超過 10 個字符，則最初建立的字符將會無效。例如，如果您有 11 個字符，您建立的第一個字符將會無效。如果您有 12 個字符，您建立的前兩個字符將會無效。如需有關使用 CodeDeploy API 移除舊字符的資訊，請參閱 [ DeleteGitHubAccountToken](https://docs.aws.amazon.com/codedeploy/latest/APIReference/API_DeleteGitHubAccountToken.html)。 # 對 Amazon EC2 Auto Scaling 問題進行故障診斷 **Topics** + [一般 Amazon EC2 Auto Scaling 疑難排解](#troubleshooting-auto-scaling-general) + [「CodeDeployRole 不允許您在下列 AWS 服務中執行操作：AmazonAutoScaling」錯誤](#troubleshooting-auto-scaling-permissions-error) + [在部署修訂之前，Amazon EC2 Auto Scaling 群組中的執行個體會持續佈建和終止](#troubleshooting-auto-scaling-provision-termination-loop) + [終止或重新啟動 Amazon EC2 Auto Scaling 執行個體可能會導致部署失敗](#troubleshooting-auto-scaling-reboot) + [避免將多個部署群組與單一 Amazon EC2 Auto Scaling 群組建立關聯](#troubleshooting-multiple-depgroups) + [Amazon EC2 Auto Scaling 群組中的 EC2 執行個體無法啟動並收到錯誤「Heartbeat Timeout」 Amazon EC2](#troubleshooting-auto-scaling-heartbeat) + [不相符的 Amazon EC2 Auto Scaling 生命週期關聯可能會導致 Amazon EC2 Auto Scaling 群組的自動部署停止或失敗](#troubleshooting-auto-scaling-hooks) + [「部署失敗，因為找不到部署群組的執行個體」錯誤](#troubleshooting-deployment-failed-because-no-instances-found) ## 一般 Amazon EC2 Auto Scaling 疑難排解 部署至 Amazon EC2 Auto Scaling 群組中的 EC2 執行個體可能會失敗，原因如下： Amazon EC2 + **Amazon EC2 Auto Scaling 會持續啟動和終止 EC2 執行個體。**如果 CodeDeploy 無法自動部署應用程式修訂版，Amazon EC2 Auto Scaling 會持續啟動和終止 EC2 執行個體。 取消 Amazon EC2 Auto Scaling 群組與 CodeDeploy 部署群組的關聯，或變更 Amazon EC2 Auto Scaling 群組的組態，以便所需的執行個體數量符合目前執行個體數量 （因此 Amazon EC2 Auto Scaling 無法啟動任何其他 EC2 執行個體）。如需詳細資訊，請參閱 [使用 CodeDeploy 變更部署群組設定](deployment-groups-edit.md)或 [Manual Scaling for Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-manual-scaling.html)。 + **CodeDeploy 代理程式沒有回應。**如果在啟動或啟動 EC2 執行個體後立即執行的初始化指令碼 （例如 cloud-init 指令碼） 需要超過一小時才能執行，則可能不會安裝 CodeDeploy 代理程式。CodeDeploy 具有一小時逾時，可讓 CodeDeploy 代理程式回應待定的部署。若要解決此問題，請將您的初始化指令碼移至 CodeDeploy 應用程式修訂版。 + **Amazon EC2 Auto Scaling 群組中的 EC2 執行個體會在部署期間重新啟動。 Amazon EC2 ** 如果在部署期間重新啟動 EC2 執行個體，或在處理部署命令時關閉 CodeDeploy 代理程式，您的部署可能會失敗。如需詳細資訊，請參閱[終止或重新啟動 Amazon EC2 Auto Scaling 執行個體可能會導致部署失敗](#troubleshooting-auto-scaling-reboot)。 + **多個應用程式修訂會同時部署到 Amazon EC2 Auto Scaling 群組中的相同 EC2 執行個體。 Amazon EC2 ** 如果其中一個部署的指令碼執行超過幾分鐘，則同時將多個應用程式修訂版部署到 Amazon EC2 Auto Scaling 群組中的相同 EC2 執行個體可能會失敗。 Amazon EC2 請勿將多個應用程式修訂版部署到 Amazon EC2 Auto Scaling 群組中的相同 EC2 執行個體。 Amazon EC2 + **作為 Amazon EC2 Auto Scaling 群組一部分啟動的新 EC2 執行個體的部署失敗。 Amazon EC2 ** 在此案例中，在部署中執行指令碼可防止在 Amazon EC2 Auto Scaling 群組中啟動 EC2 執行個體。 Amazon EC2 (Amazon EC2 Auto Scaling 群組中的其他 EC2 執行個體可能似乎正常執行。) Amazon EC2 若要解決這個問題，請確保先完成所有其他指令碼： + **CodeDeploy 代理程式不包含在您的 AMI 中**：如果您在啟動新執行個體時使用 **cfn-init**命令來安裝 CodeDeploy 代理程式，請將代理程式安裝指令碼放在 CloudFormation 範本的 `cfn-init`區段結尾。 + **CodeDeploy 代理程式包含在 AMI 中**：設定 AMI，讓代理程式在執行個體建立時處於 `Stopped` 狀態，然後包含啟動代理程式的`cfn-init`指令碼，做為指令碼程式庫中的最後一個步驟。 ## 「CodeDeployRole 不允許您在下列 AWS 服務中執行操作：AmazonAutoScaling」錯誤 使用以啟動範本建立的 Auto Scaling 群組的部署需要下列許可。這些是 `AWSCodeDeployRole` AWS 受管政策授予的許可之外的額外許可。 + `EC2:RunInstances` + `EC2:CreateTags` + `iam:PassRole` 如何缺少這些許可，您可能會收到此錯誤。如需詳細資訊，請參閱《Amazon EC2 Auto Scaling 使用者指南》中的「[教學課程：使用 CodeDeploy 將應用程式部署至 Auto Scaling 群組](tutorials-auto-scaling-group.md)建立 Auto Scaling 群組的啟動範本」和[「許可](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-templates.html#launch-templates-permissions)」。 [ Auto Scaling ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-launch-template.html) *Amazon EC2 Auto Scaling * ## 在部署修訂之前，Amazon EC2 Auto Scaling 群組中的執行個體會持續佈建和終止 在某些情況下，錯誤可能會阻止成功部署到 Amazon EC2 Auto Scaling 群組中新佈建的執行個體。因此沒有執行正常的執行個體，也沒有成功的部署。由於部署無法成功執行或成功完成，因此執行個體在建立後很快就會終止。然後，Amazon EC2 Auto Scaling 群組組態會導致佈建另一批執行個體，嘗試滿足運作狀態良好的最低主機需求。這個批次也會終止，此循環會繼續下去。 可能的原因包括： + 失敗的 Amazon EC2 Auto Scaling 群組運作狀態檢查。 + 應用程式修訂中的錯誤。 若要解決此問題，請遵循這些步驟： 1. 手動建立不屬於 Amazon EC2 Auto Scaling 群組的 EC2 執行個體。 Amazon EC2 使用唯一的 EC2 執行個體標籤，為執行個體加入標籤。 1. 將新執行個體新增至受影響的部署群組。 1. 將沒有錯誤的新應用程式修訂部署至部署群組。 這會提示 Amazon EC2 Auto Scaling 群組將應用程式修訂部署到 Amazon EC2 Auto Scaling 群組中的未來執行個體。 **注意** 確認部署成功後，請刪除您建立的執行個體，以避免持續向 AWS 您的帳戶收取費用。 ## 終止或重新啟動 Amazon EC2 Auto Scaling 執行個體可能會導致部署失敗 如果 EC2 執行個體是透過 Amazon EC2 Auto Scaling 啟動，且執行個體隨後終止或重新啟動，則該執行個體的部署可能會失敗，原因如下： + 在進行中的部署期間，縮減事件或任何其他終止事件會導致執行個體與 Amazon EC2 Auto Scaling 群組分離，然後終止。由於部署無法完成，因此將會失敗。 + 執行個體會重新啟動，但執行個體需要超過五分鐘才能啟動。CodeDeploy 將此視為逾時。該服務會使所有目前和未來對該執行個體的部署失敗。 解決此問題： + 一般而言，請確保在終止或重新啟動執行個體之前完成所有部署。請確保在執行個體啟動或重新啟動後，啟動所有部署。 + 如果您為 Amazon EC2 Auto Scaling 組態指定 Windows Server 基礎 Amazon Machine Image (AMI)，並使用 EC2Config 服務設定執行個體的電腦名稱，則部署可能會失敗。若要修正此問題，請在 Windows Server 基礎 AMI 中，清除 **EC2 服務屬性****的一般**索引標籤上的**設定電腦名稱**。清除此核取方塊後，系統會針對使用該 Windows Server 基礎 AMI 啟動的所有新 Windows Server Amazon EC2 Auto Scaling 執行個體停用此行為。對於啟用此行為的 Windows Server Amazon EC2 Auto Scaling 執行個體，您不需要清除此核取方塊。只需在重新啟動後，將失敗的部署重新部署至這些執行個體。 ## 避免將多個部署群組與單一 Amazon EC2 Auto Scaling 群組建立關聯 最佳實務是，您應該只將一個部署群組與每個 Amazon EC2 Auto Scaling 群組建立關聯。 這是因為如果 Amazon EC2 Auto Scaling 擴展具有與多個部署群組相關聯掛鉤的執行個體，它會一次傳送所有掛鉤的通知。這會導致每個執行個體的多個部署同時啟動。當多個部署同時將命令傳送至 CodeDeploy 代理程式時，生命週期事件與部署開始或上一個生命週期事件結束之間的五分鐘逾時可能會到達。如果發生這種情況，部署即會失敗，即使部署程序如預期執行。 **注意** 生命週期事件中指令碼的預設逾時為 30 分鐘。您可以在 AppSpec 檔案中將逾時變更為不同的值。如需詳細資訊，請參閱[為 EC2/現場部署新增 AppSpec 檔案](application-revisions-appspec-file.md#add-appspec-file-server)。 如果同時出現一個以上的部署嘗試，當部署發生時，會無法控制順序。 最後，如果部署到任何執行個體失敗，Amazon EC2 Auto Scaling 會立即終止執行個體。當第一個執行個體關閉時，其他執行中的部署開始失敗。由於 CodeDeploy 有一個一小時的逾時，讓 CodeDeploy 代理程式回應待定部署，因此每個執行個體最多可能需要 60 分鐘才能逾時。 如需 Amazon EC2 Auto Scaling 的詳細資訊，請參閱[幕後：CodeDeploy 和 Auto Scaling 整合](https://aws.amazon.com/blogs/devops/under-the-hood-aws-codedeploy-and-auto-scaling-integration/)。 ## Amazon EC2 Auto Scaling 群組中的 EC2 執行個體無法啟動並收到錯誤「Heartbeat Timeout」 Amazon EC2 Amazon EC2 Auto Scaling 群組可能無法啟動新的 EC2 執行個體，產生類似下列的訊息： `Launching a new EC2 instance . Status Reason: Instance failed to complete user's Lifecycle Action: Lifecycle Action with token was abandoned: Heartbeat Timeout`. 此訊息通常會指出下列項目之一： + 已達到與 AWS 帳戶相關聯的並行部署數目上限。如需部署限制的詳細資訊，請參閱 [CodeDeploy 配額](limits.md)。 + Auto Scaling 群組嘗試太快啟動太多 EC2 執行個體。針對每個新執行個體呼叫 [RecordLifecycleActionHeartbeat](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_RecordLifecycleActionHeartbeat.html) 或 [CompleteLifecycleAction](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_CompleteLifecycleAction.html) 的 API 已調節。 + 在更新或刪除其相關聯的部署群組之前，CodeDeploy 中的應用程式已刪除。 當您刪除應用程式或部署群組時，CodeDeploy 會嘗試清除與其相關聯的任何 Amazon EC2 Auto Scaling 掛鉤，但可能會保留一些掛鉤。如果您執行命令來刪除部署群組，輸出中會傳回剩餘關聯。不過，如果您執行命令來刪除應用程式，剩餘關聯不會在輸出中出現。 因此，做為最佳實務，您應該先刪除所有與應用程式建立關聯的部署群組，再刪除應用程式。您可以使用命令輸出，來識別必須手動刪除的生命週期關聯。 如果您收到「Heartbeat Timeout」錯誤訊息，則可以透過執行下列操作來判斷剩餘的生命週期關聯是否為原因，並解決問題： 1. 執行以下任意一項： + 呼叫 [delete-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/delete-deployment-group.html) 命令，刪除與 Auto Scaling 群組相關聯的部署群組，這會導致活動訊號逾時。 + 使用非空的 Auto Scaling 群組名稱清單呼叫 [update-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/update-deployment-group.html) 命令，以分離所有 CodeDeploy 受管 Auto Scaling 生命週期關聯。 例如，輸入下列 AWS CLI 命令： `aws deploy update-deployment-group --application-name my-example-app --current-deployment-group-name my-deployment-group --auto-scaling-groups` 另一個範例是，如果您使用 CodeDeploy API 搭配 Java，請呼叫 `UpdateDeploymentGroup`並`autoScalingGroups`設為 `new ArrayList()`。這會將 `autoScalingGroups` 設定為空白清單，並移除現有的清單。請勿使用 `null`，這是預設值，因為這會`autoScalingGroups`保持原狀，這不是您想要的。 檢查呼叫的輸出。如果輸出包含具有 Amazon EC2 Auto Scaling 生命週期關聯清單的`hooksNotCleanedUp`結構，則會有剩餘的生命週期關聯。 1. 呼叫 [describe-lifecycle-hooks](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/describe-lifecycle-hooks.html) 命令，指定與無法啟動的 Amazon EC2 EC2 Auto Scaling 群組名稱。在輸出中，尋找下列任何項目： + Amazon EC2 Auto Scaling 生命週期關聯名稱，對應於您在步驟 1 中識別的`hooksNotCleanedUp`結構。 + Amazon EC2 Auto Scaling 生命週期關聯名稱，其中包含與失敗的 Auto Scaling 群組相關聯的部署群組名稱。 + 可能導致 CodeDeploy 部署活動訊號逾時的 Amazon EC2 Auto Scaling 生命週期掛鉤名稱。 1. 如果勾點屬於步驟 2 中列出的其中一個類別，請呼叫 [delete-lifecycle-hook](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/delete-lifecycle-hook.html) 命令將其刪除。在通話中指定 Amazon EC2 Auto Scaling 群組和生命週期掛鉤。 **重要** 僅刪除造成問題的勾點，如步驟 2 所述。如果您刪除可行的勾點，您的部署可能會失敗，或者 CodeDeploy 可能無法部署應用程式修訂版以擴展 EC2 執行個體。 1. 使用所需的 Auto Scaling 群組名稱呼叫 [update-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/update-deployment-group.html) 或 [create-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment-group.html) 命令。CodeDeploy 會使用新的 UUID 重新安裝 Auto Scaling 掛鉤。 UUIDs **注意** 如果您從 CodeDeploy 部署群組分離 Auto Scaling 群組，任何進行中的部署到 Auto Scaling 群組都可能會失敗，而且 Auto Scaling 群組向外擴展的新 EC2 執行個體將不會收到 CodeDeploy 的應用程式修訂版。若要讓 Auto Scaling 再次使用 CodeDeploy，您需要將 Auto Scaling 群組重新連接至部署群組，並呼叫新的 `CreateDeployment` 來啟動整個機群的部署。 ## 不相符的 Amazon EC2 Auto Scaling 生命週期關聯可能會導致 Amazon EC2 Auto Scaling 群組的自動部署停止或失敗 Amazon EC2 Auto Scaling 和 CodeDeploy 使用生命週期掛鉤來判斷在 Amazon EC2 Auto Scaling 群組中啟動 EC2 執行個體之後，應該部署哪些應用程式修訂版。如果生命週期掛鉤和這些掛鉤的相關資訊在 Amazon EC2 Auto Scaling 和 CodeDeploy 中不相符，則自動部署可能會停止或失敗。 如果部署至 Amazon EC2 Auto Scaling 群組失敗，請參閱 Amazon EC2 Auto Scaling 和 CodeDeploy 中的生命週期關聯名稱是否相符。如果沒有，請使用這些 AWS CLI 命令呼叫。 首先，取得 Amazon EC2 Auto Scaling 群組和部署群組的生命週期關聯名稱清單： 1. 呼叫 [describe-lifecycle-hooks](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/describe-lifecycle-hooks.html) 命令，指定與 CodeDeploy 中的部署群組相關聯的 Amazon EC2 Auto Scaling 群組名稱。在輸出的 `LifecycleHooks` 清單中，記錄每個 `LifecycleHookName` 值。 1. 呼叫 [get-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-group.html) 命令，指定與 Amazon EC2 Auto Scaling 群組相關聯的部署群組名稱。在輸出的`autoScalingGroups`清單中，尋找名稱值符合 Amazon EC2 Auto Scaling 群組名稱的每個項目，然後記下對應的`hook`值。 現在比較兩組生命週期關聯的名稱。如果完全相符 (字元對字元)，那麼這就不是問題所在。您可能想要嘗試本節其他部分所述的其他 Amazon EC2 Auto Scaling 疑難排解步驟。 不過，如果兩組生命週期關聯名稱不完全相符 (字元對字元)，請執行下列作業： 1. 如果在 **describe-lifecycle-hooks** 命令輸出中包含在 **get-deployment-group** 命令輸出中未包含的生命週期關聯名稱，則執行以下作業： 1. 對 **describe-lifecycle-hooks** 命令輸出中的每個生命週期關聯名稱，呼叫 [delete-lifecycle-hook](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/delete-lifecycle-hook.html) 命令。 1. 呼叫 [update-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/update-deployment-group.html) 命令，指定原始 Amazon EC2 Auto Scaling 群組的名稱。CodeDeploy 在 Amazon EC2 Auto Scaling 群組中建立新的替換生命週期掛鉤，並將生命週期掛鉤與部署群組建立關聯。現在當新的執行個體新增至 Amazon EC2 Auto Scaling 群組時，自動部署應該會繼續。 1. 如果在 **get-deployment-group** 命令輸出中包含在 **describe-lifecycle-hooks** 命令輸出中未包含的生命週期關聯名稱，則執行以下作業： 1. 呼叫 [update-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/update-deployment-group.html) 命令，但不指定原始 Amazon EC2 Auto Scaling 群組的名稱。 1. 再次呼叫 **update-deployment-group**命令，但這次指定原始 Amazon EC2 Auto Scaling 群組的名稱。CodeDeploy 會在 Amazon EC2 Auto Scaling 群組中重新建立缺少的生命週期關聯。現在當新的執行個體新增至 Amazon EC2 Auto Scaling 群組時，自動部署應該會繼續。 在您取得兩組完全相符的生命週期關聯名稱後，角色的字元、應用程式修訂應再次部署到新的執行個體，但只會在新增至 Amazon EC2 Auto Scaling 群組時部署到新的執行個體。部署不會自動部署到已在 Amazon EC2 Auto Scaling 群組中的執行個體。 ## 「部署失敗，因為找不到部署群組的執行個體」錯誤 如果您看到下列 CodeDeploy 錯誤，請閱讀本節： `The deployment failed because no instances were found for your deployment group. Check your deployment group settings to make sure the tags for your EC2 instances or Auto Scaling groups correctly identify the instances you want to deploy to, and then try again.` 此錯誤的可能原因包括： 1. 您的部署群組設定包括 EC2 執行個體、內部部署執行個體或 Auto Scaling 群組不正確的標籤。若要修正此問題，請檢查您的標籤是否正確，然後重新部署您的應用程式。 1. 您的機群會在部署開始後橫向擴展。在此案例中，您會在機群中看到`InService`狀態為運作狀態良好的執行個體，但也會看到上述錯誤。若要修正此問題，請重新部署您的應用程式。 1. 您的 Auto Scaling 群組不包含任何處於 `InService` 狀態的執行個體。在此案例中，當您嘗試進行整個機群部署時，部署會失敗，並顯示上述錯誤訊息，因為 CodeDeploy 至少需要一個執行個體處於 `InService` 狀態。您可能沒有`InService`處於 狀態之執行個體的原因有很多。其中一些包括： + 您已將 Auto Scaling 群組大小排定 （或手動設定） 為 `0`。 + Auto Scaling 偵測到錯誤的 EC2 執行個體 （例如，EC2 執行個體發生硬體故障），因此全部取消，沒有任何執行個體處於 `InService` 狀態。 + 在從 `0`擴展至 的橫向擴展事件期間`1`，CodeDeploy 部署了先前成功的修訂 （稱為*上次成功的修訂*)，該修訂自上次部署以來變得運作狀態不佳。這會導致向外擴展執行個體上的部署失敗，進而導致 Auto Scaling 取消執行個體，因此沒有執行個體處於 `InService` 狀態。 如果您發現沒有`InService`處於 狀態的執行個體，請依下列程序 所述對問題進行故障診斷[To troubleshoot the error if there are no instances in the InService state](#ToTroubleshootIfNoInServiceInstances)。 **在 InService 狀態中沒有執行個體時疑難排解錯誤** 1. 在 Amazon EC2 主控台中**，驗證所需容量**設定。如果為零，請將其設定為正數。等待執行個體成為 `InService`，這表示部署成功。您已修正此問題，可以略過此故障診斷程序的其餘步驟。如需設定**所需容量**設定的資訊，請參閱《Amazon EC2 [ Auto Scaling 使用者指南》中的設定 Auto Scaling 群組的容量限制](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-capacity-limits.html)。 *Amazon EC2 Auto Scaling * 1. 如果 Auto Scaling 持續嘗試啟動新的 EC2 執行個體以滿足所需的容量，但永遠無法完成向外擴展，通常是由於 Auto Scaling 生命週期關聯失敗所致。針對此問題進行故障診斷，如下所示： 1. 若要檢查哪些 Auto Scaling 生命週期關聯事件失敗，請參閱《Amazon EC2 Auto [ Scaling 使用者指南》中的驗證 Auto Scaling 群組的擴展活動](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-verify-scaling-activity.html)。 Auto Scaling 1. 如果失敗的勾點名稱為 `CodeDeploy-managed-automatic-launch-deployment-hook-DEPLOYMENT_GROUP_NAME`，請前往 CodeDeploy、尋找部署群組，並尋找 Auto Scaling 啟動的失敗部署。然後調查部署失敗的原因。 1. 如果您了解部署失敗的原因 （例如，CloudWatch 警示發生），而且可以在不變更修訂的情況下修正問題，請立即執行此操作。 1. 如果在調查後，您判斷 CodeDeploy 的*上次成功修訂*不再運作狀態良好，且 Auto Scaling 群組中沒有運作狀態良好的執行個體，則您處於部署死結情況。若要解決此問題，您必須暫時從 Auto Scaling 群組移除 CodeDeploy 的生命週期掛鉤，然後重新安裝掛鉤並重新部署新的 （良好） 修訂，以修正錯誤的 CodeDeploy 修訂。如需說明，請參閱： + [To fix the deployment deadlock issue (CLI)](#ToFixDeployDeadlockCLI) + [To fix the deployment deadlock issue (console)](#ToFixDeployDeadlockConsole) **修正部署死結問題 (CLI)** 1. （選用） 封鎖造成 CodeDeploy 錯誤的 CI/CD 管道，以便在修正此問題時不會發生非預期的部署。 1. 請記下您目前的 Auto Scaling **DesiredCapacity** 設定： `aws autoscaling describe-auto-scaling-groups --auto-scaling-group-name ASG_NAME` 您可能需要在此程序結束時縮減至此數字。 1. 將您的 Auto Scaling **DesiredCapacity** 設定設為 `1`。如果您所需的容量大於開頭的容量`1`，這是選用的。透過將其縮減為 `1`，執行個體稍後佈建和部署所需的時間會縮短，進而加快故障診斷速度。如果您的 Auto Scaling 所需容量最初設定為 `0`，您必須將其增加為 `1`。這是強制性的。 aws autoscaling set-desired-capacity --auto-scaling-group-name *ASG\$1NAME* --desired-capacity 1 **注意** 此程序的其餘步驟假設您已將 **DesiredCapacity** 設定為 `1`。 此時，Auto Scaling 會嘗試擴展至一個執行個體。然後，由於 CodeDeploy 新增的勾點仍然存在，CodeDeploy 會嘗試部署；部署失敗；Auto Scaling 會取消執行個體；而 Auto Scaling 會嘗試重新啟動執行個體，以達到所需的容量，再次失敗。您正在取消重新啟動迴圈。 1. 從部署群組取消註冊 Auto Scaling 群組： **警告** 下列命令將啟動沒有軟體的新 EC2 執行個體。在執行 命令之前，請確定不接受執行任何軟體的 Auto Scaling `InService`執行個體。例如，確保與執行個體相關聯的負載平衡器不會在沒有軟體的情況下將流量傳送至此主機。 **重要** 使用如下所示的 CodeDeploy 命令來移除勾點。請勿透過 Auto Scaling 服務移除掛鉤，因為 CodeDeploy 無法辨識移除。 `aws deploy update-deployment-group --application-name APPLICATION_NAME --current-deployment-group-name DEPLOYMENT_GROUP_NAME --auto-scaling-groups` 執行此命令後，會發生下列情況： 1. CodeDeploy 會從部署群組取消註冊 Auto Scaling 群組。 1. CodeDeploy 會從 Auto Scaling 群組中移除 Auto Scaling 生命週期關聯。 1. 由於造成部署失敗的掛鉤不再存在，Auto Scaling 會取消現有的 EC2 執行個體，並立即啟動新的 EC2 執行個體，以擴展至所需的容量。新的執行個體應該很快就會進入 `InService` 狀態。新執行個體不包含軟體。 1. 等待 EC2 執行個體進入 `InService` 狀態。若要驗證其狀態，請使用下列命令： `aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names ASG_NAME --query AutoScalingGroups[0].Instances[*].LifecycleState` 1. 將勾點新增至 EC2 執行個體： **重要** 使用如下所示的 CodeDeploy 命令來新增勾點。請勿使用 Auto Scaling 服務新增掛鉤，因為 CodeDeploy 無法辨識新增項目。 `aws deploy update-deployment-group --application-name APPLICATION_NAME --current-deployment-group-name DEPLOYMENT_GROUP_NAME --auto-scaling-groups ASG_NAME` 執行此命令後，會發生下列情況： 1. CodeDeploy 會將 Auto Scaling 生命週期掛鉤重新安裝至 EC2 執行個體 1. CodeDeploy 會使用部署群組重新註冊 Auto Scaling 群組。 1. 使用您知道運作狀態良好且想要使用的 Amazon S3 或 GitHub 修訂版，建立整個機群的部署。 例如，如果修訂版是名為 的 Amazon S3 儲存貯體中的 .zip 檔案`my-revision-bucket`，且物件索引鍵為 `httpd_app.zip`，請輸入下列命令： `aws deploy create-deployment --application-name APPLICATION_NAME --deployment-group-name DEPLOYMENT_GROUP_NAME --revision "revisionType=S3,s3Location={bucket=my-revision-bucket,bundleType=zip,key=httpd_app.zip}"` 由於 Auto Scaling 群組中現在有一個`InService`執行個體，因此此部署應該可以運作，而且您不應再看到錯誤 *部署失敗，因為找不到部署群組的執行個體*。 1. 部署成功後，如果您之前已向內擴展，請將 Auto Scaling 群組縮減至原始容量： `aws autoscaling set-desired-capacity --auto-scaling-group-name ASG_NAME --desired-capacity ORIGINAL_CAPACITY` **修正部署死結問題 （主控台）** 1. （選用） 封鎖造成 CodeDeploy 錯誤的 CI/CD 管道，以便在修正此問題時不會發生非預期的部署。 1. 前往 Amazon EC2 主控台，並記下您的 Auto Scaling **所需容量**設定。您可能需要在此程序結束時縮減至此數字。如需尋找此設定的資訊，請參閱[設定 Auto Scaling 群組的容量限制](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-capacity-limits.html)。 1. 將所需的 EC2 執行個體數量設定為 `1`： 如果您所需的容量大於開頭的容量`1`，這是選用的。透過將其縮減為 `1`，執行個體稍後佈建和部署所需的時間會縮短，進而加快故障診斷速度。如果您的 Auto Scaling **所需容量**最初設定為 `0`，您必須將其增加為 `1`。這是強制性的。 **注意** 此程序的其餘步驟假設您已將**所需容量**設定為 `1`。 1. 前往網址 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) 開啟 Amazon EC2 主控台，然後從導覽窗格中選擇 **Auto Scaling 群組**。 1. 選擇適當的區域。 1. 前往有問題的 Auto Scaling 群組。 1. 在**群組詳細資訊**中，選擇**編輯**。 1. 將**所需的容量**設定為 **1**。 1. 選擇**更新**。 1. 從部署群組取消註冊 Auto Scaling 群組： **警告** 下列子步驟將啟動沒有軟體的新 EC2 執行個體。在執行 命令之前，請確定不接受執行任何軟體的 Auto Scaling `InService`執行個體。例如，確保與執行個體相關聯的負載平衡器不會在沒有軟體的情況下將流量傳送至此主機。 1. 前往 [https://console.aws.amazon.com/codedeploy/](https://console.aws.amazon.com/codedeploy/) 開啟 CodeDeploy 主控台。 1. 選擇適當的區域。 1. 在導覽窗格中，選擇 **Applications (應用程式)**。 1. 選擇 CodeDeploy 應用程式的名稱。 1. 選擇 CodeDeploy 部署群組的名稱。 1. 選擇**編輯**。 1. 在**環境組態**中，取消選取 **Amazon EC2 Auto Scaling 群組**。 **注意** 如果未定義環境組態，則主控台不允許您儲存組態。若要略過檢查，請暫時新增 的標籤`On-premises`，`EC2`否則您知道 不會解析到任何主機。若要新增標籤，請選取 **Amazon EC2 執行個體**或**內部部署執行個體**，然後新增 **EC2**或 的標籤**金鑰****On-premises**。您可以將標籤**值**保留空白。 1. 選擇**儲存變更**。 完成這些子步驟後，會發生下列情況： 1. CodeDeploy 會從部署群組取消註冊 Auto Scaling 群組。 1. CodeDeploy 會從 Auto Scaling 群組中移除 Auto Scaling 生命週期關聯。 1. 由於造成部署失敗的掛鉤不再存在，Auto Scaling 會取消現有的 EC2 執行個體，並立即啟動新的 EC2 執行個體，以擴展至所需的容量。新的執行個體應該很快就會進入 `InService` 狀態。新執行個體不包含軟體。 1. 等待 EC2 執行個體進入 `InService` 狀態。若要驗證其狀態： 1. 前往 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) 開啟 Amazon EC2 主控台。 1. 在導覽窗格中，選擇 **Auto Scaling Groups (AS 安全群組)**。 1. 選擇 Auto Scaling 群組。 1. 在內容窗格中，選擇**執行個體管理**索引標籤。 1. 在**執行個體**下，請確定**生命週期**資料欄在執行個體旁指出 **InService**。 1. 使用與移除 Auto Scaling 群組相同的方法，向 CodeDeploy 部署群組重新註冊 Auto Scaling 群組： 1. 前往 [https://console.aws.amazon.com/codedeploy/](https://console.aws.amazon.com/codedeploy/) 開啟 CodeDeploy 主控台。 1. 選擇適當的區域。 1. 在導覽窗格中，選擇 **Applications (應用程式)**。 1. 選擇 CodeDeploy 應用程式的名稱。 1. 選擇 CodeDeploy 部署群組的名稱。 1. 選擇**編輯**。 1. 在**環境組態**中，選取 **Amazon EC2 Auto Scaling 群組**，然後從清單中選取 Auto Scaling 群組。 1. 在 **Amazon EC2 執行個體**或**內部部署執行個體**下，尋找您新增的標籤並將其移除。 1. 取消選取 **Amazon EC2 執行個體**或**內部部署執行個體**旁的核取方塊。 1. 選擇**儲存變更**。 此組態會將生命週期關聯重新安裝至 Auto Scaling 群組。 1. 使用您知道運作狀態良好且想要使用的 Amazon S3 或 GitHub 修訂版，建立整個機群的部署。 例如，如果修訂版是名為 的 Amazon S3 儲存貯體中的 .zip 檔案`my-revision-bucket`，且物件索引鍵為 `httpd_app.zip`，請執行下列動作： 1. 在 CodeDeploy 主控台的**部署群組**頁面中，選擇**建立部署**。 1. 針對 **Revision type (修訂版類型)**，選擇 **My application is stored in Amazon S3 (我的應用程式存放在 Amazon S3)**。 1. 針對**修訂位置**，選擇 `s3://my-revision-bucket/httpd_app.zip`。 1. 針對**修訂版檔案類型**，選擇 `.zip`。 1. 選擇 **Create deployment (建立部署)**。 由於 Auto Scaling 群組中現在有一個`InService`執行個體，因此此部署應該可以運作，而且您不應再看到錯誤 *部署失敗，因為找不到部署群組的執行個體*。 1. 部署成功後，如果您之前已向內擴展，請將 Auto Scaling 群組縮減至原始容量： 1. 前往網址 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) 開啟 Amazon EC2 主控台，然後從導覽窗格中選擇 **Auto Scaling 群組**。 1. 選擇適當的區域。 1. 移至 Auto Scaling 群組。 1. 在**群組詳細資訊**中，選擇**編輯**。 1. 將**所需容量**設回其原始值。 1. 選擇**更新**。 # 的錯誤代碼 AWS CodeDeploy 本主題提供有關 CodeDeploy 錯誤的參考資訊。 **** | 錯誤程式碼 | 描述 | | --- | --- | | `AGENT_ISSUE` | 部署失敗，因為 CodeDeploy 代理程式發生問題。請確定已在此部署群組的所有執行個體上安裝和執行代理程式。 進一步了解： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/codedeploy/latest/userguide/error-codes.html) | | `AUTO_SCALING_IAM_ROLE_PERMISSIONS` | 與您的部署群組相關聯的服務角色沒有在下列 AWS 服務中執行操作所需的許可。 進一步了解： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/codedeploy/latest/userguide/error-codes.html) | | `HEALTH_CONSTRAINTS` | 整體部署失敗，因為太多個別執行個體讓部署失敗、太少運作狀態良好的執行個體可用於部署，或部署群組中的一些執行個體發生問題。 進一步了解： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/codedeploy/latest/userguide/error-codes.html) | | `HEALTH_CONSTRAINTS_INVALID` | 部署無法啟動，因為沒有部署組態所定義的運作狀態良好執行個體數目下限。您可以更新部署組態來減少所需的運作狀態良好執行個體數目，或增加此部署群組中的執行個體數目。 進一步了解： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/codedeploy/latest/userguide/error-codes.html) | | `IAM_ROLE_MISSING` | 部署失敗，因為沒有服務角色具有針對部署群組所指定的服務角色名稱。請確定您使用正確的服務角色名稱。 進一步了解： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/codedeploy/latest/userguide/error-codes.html) | | `IAM_ROLE_PERMISSIONS` | CodeDeploy 沒有擔任角色所需的許可，或者您使用的 IAM 角色不會授予您在 AWS 服務中執行操作的許可。 進一步了解： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/codedeploy/latest/userguide/error-codes.html) | | `NO_INSTANCES` | 這可能由以下其中一項造成。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/codedeploy/latest/userguide/error-codes.html) 進一步了解： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/codedeploy/latest/userguide/error-codes.html) | | `OVER_MAX_INSTANCES` | 部署失敗，因為設為部署目標的執行個體數目多於您帳戶允許的執行個體數目。若要減少設為此部署目標的執行個體數目，請更新此部署群組的標籤設定，或刪除一些目標執行個體。或者，您可以聯絡 AWS 支援 請求提高限制。 進一步了解： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/codedeploy/latest/userguide/error-codes.html) | | `THROTTLED` | 部署失敗，因為提出的請求超過 AWS CodeDeploy IAM 角色允許的 。請嘗試減少請求數目。 進一步了解： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/codedeploy/latest/userguide/error-codes.html) | | `UNABLE_TO_SEND_ASG` | 部署失敗，因為部署群組未正確設定其 Amazon EC2 Auto Scaling 群組。在 CodeDeploy 主控台中，從部署群組中刪除 Amazon EC2 Auto Scaling 群組，然後再次新增。 進一步了解： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/codedeploy/latest/userguide/error-codes.html) | ## 相關主題 [CodeDeploy 故障診斷](troubleshooting.md)