本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 故障排除 CodeDeploy
使用本节中的主题来帮助解决您在使用时可能遇到的问题和错误 CodeDeploy。
**注意**
可以通过查看部署过程中创建的日志文件来确定很多部署失败的原因。为简单起见，我们建议使用 Amazon Log CloudWatch s 来集中监控日志文件，而不是逐个实例查看它们。有关信息，请参阅[使用 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)。
+ 是否已将正确的 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)和[GitHub 使用中的应用程序进行身份验证 CodeDeploy](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. 确认您使用的是 AWS CLI 版本 1.6.1 或更高版本。要检查已安装的版本，请调用 **aws --version**。
如果您仍无法排查失败部署的问题，请查看本主题中的其他问题。
## CodeDeploy 只有某些 AWS 区域支持部署资源
如果您在或 CodeDeploy 控制台中看不到或无法访问应用程序、部署组、实例或其他部署资源，请确保您引用的是区域和中[终端节点](https://docs.aws.amazon.com/general/latest/gr/rande.html#codedeploy_region)中*AWS 一般参考*列出的其中一个 AWS 区域。 AWS CLI
CodeDeploy 部署中使用的 EC2 实例和 Amazon EC2 Auto Scaling 群组必须在其中一个 AWS 区域启动和创建。
如果您使用的是 AWS CLI，请从中运行**aws configure**命令 AWS CLI。然后，您可以查看和设置您的默认 AWS 区域。
如果您使用的是 CodeDeploy 控制台，请在导航栏的区域选择器中选择一个支持的 AWS 区域。
**重要**
要使用中国（北京）区域或中国（宁夏）区域中的服务，您必须拥有特定于这些区域的账户和凭证。其他 AWS 区域的账户和凭证不适用于北京和宁夏区域，反之亦然。
有关中国区域某些资源的信息， CodeDeploy 例如资源套件存储桶名称 CodeDeploy 和代理安装过程，未包含在本版本的*用户指南CodeDeploy 中*。
有关更多信息：
[CodeDeploy](http://docs.amazonaws.cn/en_us/aws/latest/userguide/codedeploy.html)in *[中国（北京） 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 脚本文件中显示非打印字符（例如回车符）的文本编辑器，这样您就可以查找和删除任何可能引入的字符。有关这些类型的文本编辑器的示例，请在 Internet 上搜索“显示回车的文本编辑器”。
+ 使用在 Amazon Linux、Ubuntu Server 或 RHEL 实例上运行的文本编辑器创建在 Amazon Linux、Ubuntu Server 或 RHEL 实例上运行的 shell 脚本文件。有关这些类型的文本编辑器的示例，请在 Internet 上搜索“Linux Shell 脚本编辑器”。
+ 如果您必须使用 Windows 或 macOS 中的文本编辑器来创建要在 Amazon Linux、Ubuntu Server 或 RHEL 实例上运行的 Shell 脚本文件，请使用可将 Windows 或 macOS 格式的文本转换为 Unix 格式的程序或实用工具。有关这些程序和实用工具的示例，请在 Internet 上搜索“DOS 到 UNIX”或“Mac 到 UNIX”。请确保在目标操作系统上测试转换后的 Shell 脚本文件。
## 使用 macOS 中的 Finder 捆绑应用程序修订可能会导致部署失败
如果您在 Mac 上使用 Finder 图形用户界面 (GUI) 应用程序将 AppSpec 文件及相关文件和脚本捆绑 (zip) 到应用程序修订存档 (.zip) 文件中，则部署可能会失败。这是因为，Finder 将在 .zip 文件中创建一个中间 `__MACOSX` 文件夹并将组件文件放入其中。 CodeDeploy 找不到组件文件，因此部署失败。
要解决此问题，我们建议您使用调用 p [ush](https://docs.aws.amazon.com/cli/latest/reference/deploy/push.html) 命令，该命令会将组件文件压缩到预期的结构中。 AWS CLI 或者，您可以使用 Terminal（而不是 GUI）来压缩组件文件。Terminal 不创建中间 `__MACOSX` 文件夹。
# 排查 EC2/本地部署问题
**Topics**
+ [CodeDeploy 插件 CommandPoller 缺少凭据错误](#troubleshooting-agent-commandpoller-error)
+ [部署失败并显示消息 “ PKCS7 已签名邮件验证失败”](#troubleshooting-deployments-agent-SHA-256)
+ [将相同的文件部署或重新部署到相同的实例位置失败，出现错误“The deployment failed because a specified file already exists at this location”](#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)
+ [使用以下命令对失败的 DownloadBundle 部署生命周期事件进行故障排除 UnknownError：未打开供读取](#troubleshooting-deployments-downloadbundle)
+ [排查所有生命周期事件跳过错误](#troubleshooting-skipped-lifecycle-events)
+ [默认情况下，Windows PowerShell 脚本无法使用 64 位版本 PowerShell 的 Windows](#troubleshooting-deployments-powershell)
**注意**
通过查看部署过程中创建的日志文件可以确定很多部署失败的原因。为简单起见，我们建议使用 Amazon Log CloudWatch s 来集中监控日志文件，而不是逐个实例查看它们。有关信息，请参阅[在 CodeDeploy 日志控制台中查看 CloudWatch 日志](https://aws.amazon.com/blogs/devops/view-aws-codedeploy-logs-in-amazon-cloudwatch-console/)。
**提示**
*有关自动执行与 EC2/本地部署相关的许多故障排除任务的运行手册，请参阅 S [AWSSupport-TroubleshootCodeDeploy](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awssupport-troubleshootcodedeploy.html)ystems Manager AWS Automation 运行手册参考中。*
## CodeDeploy 插件 CommandPoller 缺少凭据错误
如果您收到类似于 `InstanceAgent::Plugins::CodeDeployPlugin::CommandPoller: Missing credentials - please check if this instance was started with an IAM instance profile` 的错误，可能是由于下列原因之一导致：
+ 您要部署的实例没有与之关联的 IAM 实例配置文件。
+ 您的 IAM 实例配置文件没有配置正确的权限。
IAM 实例配置文件授予 CodeDeploy 代理与 Amazon S3 通信 CodeDeploy以及从 Amazon S3 下载您的修订版的权限。对于 EC2 实例，请参阅 [的身份和访问管理 AWS CodeDeploy](security-iam.md)。对于本地实例，请参阅[使用本地实例 CodeDeploy](instances-on-premises.md)。
## 部署失败并显示消息 “ PKCS7 已签名邮件验证失败”
此错误消息表示实例运行的 CodeDeploy 代理版本仅支持 SHA-1 哈希算法。2015 年 11 月发布的 CodeDeploy 代理版本 1.0.1.854 中引入了对 SHA-2 哈希算法的支持。自 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/)[早于 1.0.1.85 版本 CodeDeploy 的主机代理](https://forums.aws.amazon.com/thread.jspa?threadID=223319)，以及。[更新代 CodeDeploy 理](codedeploy-agent-operations-update.md)
## 将相同的文件部署或重新部署到相同的实例位置失败，出现错误“The deployment failed because a specified file already exists at this location”
当 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 没有删除现有文件。两个部署都引用了不同的部署组 IDs。
+ 您在中部署了修订版 CodeDeploy，但至少有一个名称相同且位于相同位置的文件。部署失败的原因是，默认情况下，在部署开始之前 CodeDeploy 不会删除现有文件。
要处理这些情况，请执行下列操作之一：
+ 从文件之前部署到的位置和实例中删除文件，然后尝试重新部署。
+ 在您的修订 AppSpec 文件中，在 ApplicationStop 或 BeforeInstall部署生命周期事件中，指定一个自定义脚本，以删除与您的修订将要安装的文件匹配的任何位置的文件。
+ 将文件部署或重新部署到不属于之前的部署的位置或实例。
+ 在删除应用程序或部署组之前，请部署一个修订版，该修订包含一个 AppSpec 文件，该文件没有指定要复制到实例的文件。对于部署，请指定应用程序名称和部署组名称，这些名称和部署组使用与要删除的应用程序和部署组 IDs 相同的底层应用程序和部署组。（您可以使用[get-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-group.html)命令来检索部署组 ID。） CodeDeploy使用底层部署组 ID 和 AppSpec 文件删除其在先前成功部署中安装的所有文件。
## 长文件路径会导致“没有这样的文件或目录”错误
对于到 Windows 实例的部署，如果您的 appspec.yml 文件的“files”部分的文件路径大于 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` 文件包含以下内容，它会使程序执行暂停 3 分钟（180 秒），并模拟某个长时间运行的进程：
```
#!/bin/bash
sleep 180
```
当`after-install.sh`呼叫时`sleep.sh`，`sleep.sh`启动并运行三分钟（180 秒），也就是说，比 CodeDeploy 预期停止运行的时间晚了两分钟`sleep.sh`（120 秒`after-install.sh`）（根据关系）。超时一分钟（60 秒）后，即使部署`sleep.sh`继续按预期运行，也会在 AfterInstall 应用程序生命周期事件中 CodeDeploy 停止部署并失败。将显示以下错误：
`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 &
```
这样做可能会使部署在默认的一小时部署生命周期事件超时时间内处于待处理状态，之后部署会像以前一样在 AfterInstall 应用程序生命周期事件中 CodeDeploy 停止部署并失败。
在中`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 生命周期事件进行故障排除
在某些情况下， blue/green 部署在 AllowTraffic 生命周期事件期间会失败，但部署日志并未指出失败的原因。
这种故障通常是由于在 Elastic Load Balancing 中，用于管理部署组流量的经典负载均衡器、应用程序负载均衡器或网络负载均衡器的运行状况检查配置不正确造成的。
要解决这一问题，请检查并更正负载均衡器的运行状况检查配置中的错误。
有关传统负载均衡器，请参阅经典负载均衡器*用户指南和 Elastic Load Balancing* *API 参考版本 2012-06-01 [ConfigureHealthCheck](https://docs.aws.amazon.com/elasticloadbalancing/2012-06-01/APIReference/API_ConfigureHealthCheck.html)*中的[配置运行状况](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-healthchecks.html)检查。
对于应用程序负载均衡器，请参阅《应用程序负载均衡器用户指南》**中的[目标组的运行状况检查](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html)。
对于网络负载均衡器，请参阅《网络负载均衡器用户指南》**中的[目标组的运行状况检查](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-health-checks.html)。
## 对失败 ApplicationStop BeforeBlockTraffic、或 AfterBlockTraffic 部署生命周期事件进行故障排除
在部署期间， CodeDeploy 代理会运行上一次成功部署 AppSpec 的文件 AfterBlockTraffic 中为 ApplicationStop BeforeBlockTraffic、和指定的脚本。（所有其他脚本都从当前部署中的 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 控制台调查在上述任何事件期间部署可能失败的原因。在部署的详细信息页上，选择**查看事件**。在实例的详细信息页面上，在**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 控制台创建部署。在**创建部署**页面的**ApplicationStop 生命周期事件失败**下，选择**实例上的此生命周期事件失败时不要使实例的部署失败**。
+ 使用调 AWS CLI 用**[create-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html)**命令并添加`--ignore-application-stop-failures`选项。
当您重新部署应用程序修订时，部署将继续，即使这三个生命周期事件中的任一事件失败也是如此。如果新的修订已包含针对这些生命周期事件的修复脚本，未来的部署无需应用此修复就能成功。
## 使用以下命令对失败的 DownloadBundle 部署生命周期事件进行故障排除 UnknownError：未打开供读取
如果您尝试从 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 存储桶中。
在部署的事件详细信息页的**下载服务包**行中，选择**查看日志**。或者使用 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. 查看线路日志记录文件以找到错误。此问题的常见错误消息包括短语“access denied”。
1. 在查看日志文件后，建议您禁用线路日志记录以减小日志文件的大小并减少将来可能会在实例上的输出中以纯文本格式出现的敏感信息量。
有关如何查找线路日志文件以及如何启用和禁用线路日志记录的信息，请参阅`:log_aws_wire:`[CodeDeploy 代理配置参考中的](https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-agent-configuration.html)。
## 排查所有生命周期事件跳过错误
如果跳过了 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 公有终端节点。请尝试以下任一操作：
+ 将公有 IP 地址分配到实例并使用其路由表来允许 Internet 访问。确保与实例关联的安全组允许端口 443（HTTPS）上的出站访问。有关更多信息，请参阅 [CodeDeploy 代理的通信协议和端口](codedeploy-agent.md#codedeploy-agent-outbound-port)。
+ 如果是在私有子网中预配置了实例，请在路由表中使用 NAT 网关而不是 Internet 网关。有关更多信息，请参阅 [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 — 签名已过期：[时间] 现在早于 [时间]” 部署错误](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 角色](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-EC2.html)。
## 默认情况下，Windows PowerShell 脚本无法使用 64 位版本 PowerShell 的 Windows
如果在部署过程中运行的 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 支持渐进式流量路由，在 create/update 部署组时改用 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)
## 等待替换任务集时出现超时
**问题**：在使用以下方式部署 Amazon ECS 应用程序时，您会看到以下错误消息 CodeDeploy：
`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 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)部分，了解与事件消息相关的错误。
## 等待通知继续时出现超时
**问题**：在使用以下方式部署 Amazon ECS 应用程序时，您会看到以下错误消息 CodeDeploy：
`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)。
+ 重新部署，然后在`--deployment-wait-type`选项设置为`READY_WAIT`的情况下运行[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 命令。确保在**指定重新路由流量的时间**中指定的时间结束*之前* 运行此命令。
## IAM 角色没有足够的权限
**问题**：在使用以下方式部署 Amazon ECS 应用程序时，您会看到以下错误消息 CodeDeploy：
`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 服务的权限，则可能会发生此错误。
**可能的解决方法**：为 CodeDeploy 服务角色添加`lambda:InvokeFunction`权限。要添加此权限，请向该角色添加以下 AWS托管策略之一：**AWSCodeDeployRoleForECS** 或 **AWSCodeDeployRoleForECSLimited**。有关这些策略以及如何将其添加到 CodeDeploy 服务角色的信息，请参阅[步骤 2：为创建服务角色 CodeDeploy](getting-started-create-service-role.md)。
## 等待状态回调时部署超时
**问题**：在使用以下方式部署 Amazon ECS 应用程序时，您会看到以下错误消息 CodeDeploy：
`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`部分指定了 Lambda 函数，但是 Lambda `Succeeded` 函数无法调用必要的](reference-appspec-file-structure-hooks.md#appspec-hooks-ecs) `PutLifecycleEventHookExecutionStatus` API 来返回或状态，则可能会发生此错误。`Failed` CodeDeploy
**可能的解决方法和后续步骤**：
+ 向您在文件中指定的 Lambda 函数使用的 Lambda 执行角色添加`codedeploy:putlifecycleEventHookExecutionStatus`权限。 AppSpec 此权限授予 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 执行日志的信息，请参阅访问[亚马逊 CloudWatch 日志](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html)。 AWS Lambda
## 由于一个或多个生命周期事件验证函数失败，部署失败
**问题**：在使用以下方式部署 Amazon ECS 应用程序时，您会看到以下错误消息 CodeDeploy：
`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 执行日志的信息，请参阅访问[亚马逊 CloudWatch 日志](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html)。 AWS Lambda
## 由于以下错误，ELB 无法更新：主任务集目标组必须位于监听器之后
**问题**：在使用以下方式部署 Amazon ECS 应用程序时，您会看到以下错误消息 CodeDeploy：
`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)。有关任务集的更多信息，请参阅[TaskSet](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_TaskSet.html)《*亚马逊弹性容器服务 API 参考*》和[describe-task-set](https://docs.aws.amazon.com/cli/latest/reference/ecs/describe-task-set.html)《*AWS CLI 命令参考*》的 Amazon ECS 部分。
**可能的解决方法**：确保 Elastic Load Balancing 的生产侦听器和测试侦听器都指向当前为您的工作负载提供服务的目标组。有三个地方需要检查：
+ 在 Amazon EC2 中，在您的负载均衡器的**侦听器和规则**设置中。有关更多信息，请参阅《应用程序负载均衡器用户指南》**中的[应用程序负载均衡器侦听器](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html)，或《网络负载均衡器用户指南》**中的[网络负载均衡器侦听器](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-listeners.html)。
+ 在 Amazon ECS 中，在您的集群中的服务的**网络**配置下。有关更多信息，请参阅《Amazon Elastic Container Service 开发人员指南》**中的[应用程序负载均衡器和网络负载均衡器注意事项](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 开发者指南》中标题为 “对于配置为使用服务自动扩展的服务*[以及 blue/green 部署类型，在部署期间不会阻止自动扩展，但在某些情况下部署可能会失败](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-type-bluegreen.html#deployment-type-bluegreen-considerations)。
**可能的原因**：如果 CodeDeploy 和 Auto Scaling 进程发生冲突，则可能会出现此问题。
**可能的解决方法**：在 CodeDeploy 部署期间使用 `RegisterScalableTarget` API（或相应的`register-scalable-target` AWS CLI 命令）暂停和恢复 Auto Scaling 进程。有关更多信息，请参阅《Application Auto Scaling 用户指南》**中的[暂停和恢复 Application Auto Scaling 扩缩](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-suspend-resume-scaling.html)。
**注意**
CodeDeploy 无法`RegisterScaleableTarget`直接打电话。要使用此 API，您必须配置 CodeDeploy 为向亚马逊简单通知服务（或亚马逊 CloudWatch）发送通知或事件。然后，您必须将 Amazon SNS（或 CloudWatch）配置为调用 Lambda 函数，并配置 Lambda 函数以调用该 API。`RegisterScalableTarget`调用 `RegisterScalableTarget` API 时必须将 `SuspendedState` 参数设置为 `true` 以暂停 Auto Scaling 操作，然后设置为 `false` 以恢复这些操作。
CodeDeploy 发送的通知或事件必须在部署开始（触发 Auto Scaling 暂停操作）或部署成功、失败或停止（触发 Auto Scaling 恢复操作）时发生。
有关如何配置 CodeDeploy 以生成 Amazon SNS 通知或 CloudWatch事件的信息，请参阅[使用 Amazon CloudWatch 事件监控部署](monitoring-cloudwatch-events.md)。和。[使用 Amazon SNS 事件通知监控部署](monitoring-sns-event-notifications.md)
## 只有 ALB 支持渐进式流量路由，在 create/update 部署组时改用 AllAtOnce 流量路由
**问题**：在中创建或更新部署组时，您会看到以下错误消息 CodeDeploy：
`Only ALB supports gradual traffic routing, use AllAtOnce Traffic routing instead when you create/update Deployment group.`
**可能的原因**：如果您使用的是网络负载均衡器并尝试使用除 `CodeDeployDefault.ECSAllAtOnce` 之外的预定义部署配置，则可能会发生此错误。
**可能的修复方法：**
+ 将您的预定义部署配置更改为 `CodeDeployDefault.ECSAllAtOnce`。这是网络负载均衡器支持的唯一预定义部署配置。
有关预定义部署配置的更多信息，请参阅[Amazon ECS 计算平台的预定义部署配置](deployment-configurations.md#deployment-configurations-predefined-ecs)。
+ 将您的负载均衡器更改为应用程序负载均衡器。应用程序负载均衡器支持所有预定义的部署配置。有关创建应用程序负载均衡器的更多信息，请参阅[为 A CodeDeploy mazon 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部署配置，在流量转移到替换任务集*之后（也就是说，`AllowTraffic`生命周期事件发生之后*），负载均衡器的运行状况检查就会开始 CodeDeploy对替换任务集运行。*这就是为什么在流量转移之后，替换任务集的运行状况检查会失败，而在流量转移前却没有。有关 CodeDeploy 生成的生命周期事件的信息，请参阅[在 Amazon ECS 部署过程中发生的事件](deployment-steps-ecs.md#deployment-steps-what-happens)。
**可能的修复方法：**
+ 将部署配置从更改 all-at-once为灰色或线性。*在灰度或线性配置中，在替换环境中 CodeDeploy 安装应用程序时，在流量转移之前（即`Install`生命周期事件期间和事件发生*之前*），负载均衡器的运行状况检查开始在替换任务集上`AllowTraffic`运行。*通过允许在应用程序安装期间但在流量转移之前运行检查，可以在应用程序公开可用之前检测到错误的应用程序代码并导致部署失败。
有关如何配置金丝雀部署或线性部署的信息，请参阅[使用更改部署组设置 CodeDeploy](deployment-groups-edit.md)。
有关在 Amazon ECS 部署期间运行的 CodeDeploy 生命周期事件的信息，请参阅[在 Amazon ECS 部署过程中发生的事件](deployment-steps-ecs.md#deployment-steps-what-happens)。
**注意**
只有应用程序负载均衡器支持金丝雀和线性部署配置。
+ 如果要保留 all-at-once部署配置，请设置测试侦听器并使用`BeforeAllowTraffic`生命周期挂钩检查替换任务集的运行状况。有关更多信息，请参阅 [用于 Amazon ECS 部署的生命周期事件挂钩的列表](reference-appspec-file-structure-hooks.md#reference-appspec-file-structure-hooks-list-ecs)。
## 我能否将多个负载均衡器连接到一个部署组？
不是。 如果您想使用多个应用程序负载均衡器或网络负载均衡器，请使用 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 服务？
要在您的 Amazon ECS 服务进行部署时使用新参数对其进行 CodeDeploy 更新，请在 AppSpec 文件`resources`部分中指定该参数。仅支持少数 Amazon ECS 参数 CodeDeploy，例如任务定义文件和容器名称参数。有关 CodeDeploy 可以更新的 Amazon ECS 参数的完整列表，请参阅[AppSpec Amazon ECS 部署的 “资源” 部分](reference-appspec-file-structure-resources.md#reference-appspec-file-structure-resources-ecs)。
**注意**
如果您需要使用不支持的参数更新 Amazon ECS 服务 CodeDeploy，请完成以下任务：
使用您要更新的参数调用 Amazon ECS 的 `UpdateService` API。有关可更新的参数的完整列表，请参阅[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)《*亚马逊弹性容器服务 API 参考*》。
要将更改应用于任务，请创建新的 Amazon ECS blue/green 部署。有关更多信息，请参阅 [创建 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 管理控制台 并打开 AWS Lambda 控制台，网址为[https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/)。
1. 在左侧窗格中，选择**函数**。
1. 选择部署中的 Lambda 函数的 CodeDeploy 名称。
1. 从 “**别**名” 中，选择 CodeDeploy 部署中使用的别名，然后选择 “**编辑”**。
1. 从**加权别名**中选择 **none**。这可确保别名不配置为将流量百分比、权重转移到多个版本。记下在**版本**中选择的版本。
1. 选择**保存**。
1. 打开 CodeDeploy 控制台，尝试部署步骤 5 中下拉菜单中显示的版本。
# 排查部署组问题
## 标记作为部署组的一部分的实例不会自动将您的应用程序部署到新实例
CodeDeploy 不会自动将您的应用程序部署到新标记的实例。您必须在部署组中创建新的部署。
您可以使用 CodeDeploy 在 Amazon EC2 Auto Scaling 群组中启用对新 EC2 实例的自动部署。有关更多信息，请参阅 [CodeDeploy 与亚马逊 EC2 Auto Scaling 集成](integrations-aws-auto-scaling.md)。
# 排查实例问题
**Topics**
+ [必须正确设置标签](#troubleshooting-EC2-tags)
+ [AWS CodeDeploy 必须在实例上安装并运行代理](#troubleshooting-sds-agent)
+ [如果实例在部署期间终止，在最多 1 小时内部署不会失败。](#troubleshooting-one-hour-timeout)
+ [分析日志文件以调查针对实例的部署失败](#troubleshooting-deploy-failures)
+ [如果 CodeDeploy 日志文件被意外删除，请创建一个新的日志文件](#troubleshooting-create-new-log-file)
+ [疑难解答 “InvalidSignatureException — 签名已过期：[时间] 现在早于 [时间]” 部署错误](#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 才能读取标签。建议您在标记实例和尝试对实例进行部署之间等待至少 5 分钟。
## AWS CodeDeploy 必须在实例上安装并运行代理
要验证 CodeDeploy 代理是否已在实例上安装并正在运行，请参阅[验证 CodeDeploy 代理是否正在运行](codedeploy-agent-operations-verify.md)。
要安装、卸载或重新安装 CodeDeploy 代理，请参阅[安装代 CodeDeploy 理](codedeploy-agent-operations-install.md)。
## 如果实例在部署期间终止，在最多 1 小时内部署不会失败。
CodeDeploy 为每个部署生命周期事件提供一小时的时间段，让其运行直至完成。这为长时间运行的脚本提供了足够的时间。
如果在生命周期事件进行期间（例如，如果实例终止或 CodeDeploy 代理关闭），则部署状态最多可能需要一个小时才能显示为 “失败”。即使脚本中指定的超时时段不到 1 小时，也会发生此情况。这是因为当实例终止时， CodeDeploy 代理会关闭，无法处理更多脚本。
不过，如果实例在生命周期事件之间或在第一个生命周期事件步骤开始之前终止，则超时将在 5 分钟后发生。
## 分析日志文件以调查针对实例的部署失败
如果部署中的实例具有 `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 — 签名已过期：[时间] 现在早于 [时间]” 部署错误
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 令牌无效
CodeDeploy 2017 年 6 月之后创建的应用程序使用每个 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 实例无法启动，收到错误“心跳超时”](#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 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)或 [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 实例在部署期间会重新启动。**如果 EC2 实例在部署期间重启或 CodeDeploy 代理在处理部署命令时关闭，则您的部署可能会失败。有关更多信息，请参阅 [终止或重启 Amazon EC2 Auto Scaling 实例可能会导致部署失败](#troubleshooting-auto-scaling-reboot)。
+ **同时向一个 Amazon EC2 Auto Scaling 组中的相同 EC2 实例部署多个应用程序修订。**同时向一个 Amazon EC2 Auto Scaling 组中的相同 EC2 实例部署多个应用程序修订可能会失败（如果部署之一具有运行几分钟以上的脚本）。请勿将多个应用程序修订部署到一个 Amazon EC2 Auto Scaling 组中的相同 EC2 实例。
+ **对于作为 Amazon EC2 Auto Scaling 组的一部分启动的新 EC2 实例，部署将失败。**这种情况下，在部署中运行脚本可能会阻止 Amazon EC2 Auto Scaling 组中的 EC2 实例启动。（Amazon EC2 Auto Scaling 组中的其他 EC2 实例可能看起来运行正常。） 要解决此问题，请确保先完成所有其他脚本：
+ **CodeDeploy 代理不包含在您的 AMI** 中：如果您在启动新实例时使用**cfn-init**命令安装代理，请将代理安装脚本放在 CloudFormation 模板`cfn-init`部分的末尾。 CodeDeploy
+ **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/create-launch-template.html)和[权限](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-templates.html#launch-templates-permissions)。
## 在部署修订之前，Amazon EC2 Auto Scaling 组中的实例不断被预置和终止
在某些情况下，一个错误可能导致无法在 Amazon EC2 Auto Scaling 组中成功部署新预置的实例。结果是没有运行正常的实例，部署失败。由于无法运行部署或无法成功完成部署，实例在创建之后很快即被终止。Amazon EC2 Auto Scaling 组配置将预置另一组实例，试图达到正常运行的主机数的最低要求。这批实例也会被终止，并不断进行这一循环。
可能的原因包括：
+ 未通过 Amazon EC2 Auto Scaling 组运行状况检查。
+ 应用程序修订中有错误
要解决这一问题，请遵循以下步骤：
1. 手动创建不是 Amazon EC2 Auto Scaling 组一部分的 EC2 实例。用唯一的 EC2 实例标签标记该实例。
1. 将这个新实例添加到受影响的部署组。
1. 将没有错误的新应用程序修订部署到部署组。
这会提示 Amazon EC2 Auto Scaling 组将应用程序修订部署到 Amazon EC2 Auto Scaling 组中未来的实例。
**注意**
确认部署成功后，请删除您创建的实例，以避免持续向您的 AWS 账户收费。
## 终止或重启 Amazon EC2 Auto Scaling 实例可能会导致部署失败
如果通过 Amazon EC2 Auto Scaling 启动 EC2 实例，然后终止或重启该实例，则到该实例的部署可能会因以下原因而失败：
+ 在部署正在进行时，缩减事件或任何其他终止事件将导致实例与 Amazon EC2 Auto Scaling 组分离并终止。由于无法完成部署，因此它将失败。
+ 实例已重启，但需要五分钟以上的时间才能启动实例。 CodeDeploy 将此视为超时。该服务将针对该实例的所有当前和将来部署失败。
解决此问题：
+ 一般来说，请确保实例终止或重启之前完成所有部署。确保所有部署在实例启动或重启后开始。
+ 如果您为 Amazon EC2 Auto Scaling 配置指定基于 Windows 服务器的亚马逊系统映像 (AMI)，并使用 EC2配置服务设置实例的计算机名称，则部署可能会失败。要修复此问题，请在 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 实例无法启动，收到错误“心跳超时”
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)命令，以分离所有由托管的 Auto CodeDeploy 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` 保持原样，这不是您想要的。
检查调用的输出。如果输出包含一个 `hooksNotCleanedUp` 结构和一个 Amazon EC2 Auto Scaling 生命周期挂钩列表，则存在剩余的生命周期挂钩。
1. 调用[describe-lifecycle-hooks](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/describe-lifecycle-hooks.html)命令，指定与启动失败的 EC2 实例关联的 Amazon 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使用新 UUIDs功能重新安装 Auto Scaling 挂钩。
**注意**
如果您将 Auto Scaling 组与 CodeDeploy 部署组分离，则任何正在进行的对 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)命令，指定与中的部署组关联的 Amazon EC2 Auto Scaling 组的名称 CodeDeploy。在输出中，在 `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)。
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)。
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 自动缩放 — set-desired-capacity auto-scaling-group-name *ASG\$1NAME* — 所需容量 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 实例，并立即启动一个新实例来扩展到所需容量。新实例应该很快就会进入 `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 修订版创建全队列部署。
例如，如果修订是名为 `my-revision-bucket` 的 Amazon S3 存储桶中的 .zip 文件，对象键为 `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. 在上打开 Amazon EC2 控制台 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)，然后从导航窗格中选择 A **uto Scaling Gro** ups。
1. 选择适当的区域。
1. 转到有问题的 Auto Scaling 组。
1. 在**组详细信息**中，选择**编辑**。
1. 将**所需容量**设置为 **1**。
1. 选择**更新**。
1. 从部署组中取消注册 Auto Scaling 组：
**警告**
以下子步骤将启动一个没有软件的新 EC2 实例。在运行命令之前，请确保不运行任何软件的 Auto Scaling `InService` 实例是可以接受的。例如，确保与实例关联的负载均衡器在没有软件的情况下不会向该主机发送流量。
1. 打开 CodeDeploy 控制台，网址为[https://console.aws.amazon.com/codedeploy/](https://console.aws.amazon.com/codedeploy/)。
1. 选择适当的区域。
1. 在导航窗格中，选择 **应用程序**。
1. 选择您的 CodeDeploy 应用程序的名称。
1. 选择您的 CodeDeploy 部署组的名称。
1. 选择**编辑**。
1. 在**环境配置**中，取消选择 **Amazon EC2 Auto Scaling 组**。
**注意**
如果未定义环境配置，则控制台不允许您保存配置。要绕过检查，请临时添加一个您知道不会解析为任何主机的标签 `EC2` 或 `On-premises`。要添加标签，请选择 **Amazon EC2 实例**或**本地实例**，然后添加标签**键** **EC2** 或 **On-premises**。您可以将标签**值**留空。
1. 选择**保存更改**。
完成这些子步骤后，将会发生以下情况：
1. CodeDeploy 从部署组中注销 Auto Scaling 组。
1. CodeDeploy 从 Auto Scaling 组中移除 Auto Scaling 生命周期挂钩。
1. 由于导致部署失败的挂钩已不复存在，Auto Scaling 会取消现有 EC2 实例，并立即启动一个新实例来扩展到所需容量。新实例应该很快就会进入 `InService` 状态。新实例不包括软件。
1. 等待 EC2 实例进入 `InService` 状态。要验证其状态，请执行以下操作：
1. 打开位于 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) 的 Amazon EC2 控制台。
1. 在导航窗格中，选择 **Auto Scaling Groups**。
1. 选择您的 Auto Scaling 组。
1. 在内容窗格中，选择**实例管理**选项卡。
1. 在 “**实例**” 下，确保**生命周期**列显示在实例**InService**旁边。
1. 使用与移除组相同的方法将 Auto Scaling 组重新注册到 CodeDeploy 部署组：
1. 打开 CodeDeploy 控制台，网址为[https://console.aws.amazon.com/codedeploy/](https://console.aws.amazon.com/codedeploy/)。
1. 选择适当的区域。
1. 在导航窗格中，选择 **应用程序**。
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 修订版创建全队列部署。
例如，如果修订是名为 `my-revision-bucket` 的 Amazon S3 存储桶中的 .zip 文件，对象键为 `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. 在上打开 Amazon EC2 控制台 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)，然后从导航窗格中选择 A **uto Scaling Gro** ups。
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_cn/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_cn/codedeploy/latest/userguide/error-codes.html) |
| `HEALTH_CONSTRAINTS` | 总体部署因以下原因而失败：过多的独立实例部署遭失败、可供部署的正常实例太少或您的部署组中的一些实例遇到问题。 了解更多： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/codedeploy/latest/userguide/error-codes.html) |
| `HEALTH_CONSTRAINTS_INVALID` | 由于部署配置所定义的最小数目的正常运行的实例不可用，因此部署无法开始。您可通过更新部署配置来减少所需的正常运行的实例数或增加此部署组中的实例数。 了解更多： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/codedeploy/latest/userguide/error-codes.html) |
| `IAM_ROLE_MISSING` | 由于不存在具有为部署组指定的服务角色名称的服务角色，因此部署失败。确保您使用的是正确的服务角色名称。 了解更多： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/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_cn/codedeploy/latest/userguide/error-codes.html) |
| `NO_INSTANCES` | 这可能是由于下列原因之一导致的。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/codedeploy/latest/userguide/error-codes.html) 了解更多： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/codedeploy/latest/userguide/error-codes.html) |
| `OVER_MAX_INSTANCES` | 由于为部署定向的实例数超出您的账户允许的数量，因此部署失败。要减少为此部署定向的实例数，请更新此部署组的标签设置或删除一些定向实例。或者，您可联系 AWS 支持 以请求提高限制。 了解更多： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/codedeploy/latest/userguide/error-codes.html) |
| `THROTTLED` | 由于 IAM 角色发出的请求的数目超出 AWS CodeDeploy 允许的数目，因此部署失败。尝试减少请求数。 了解更多： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/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_cn/codedeploy/latest/userguide/error-codes.html) |
## 相关主题
[故障排除 CodeDeploy](troubleshooting.md)