Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

排查 EC2/本地部署问题

CodeDeploy 插件 CommandPoller缺少凭据错误

如果您收到类似于 InstanceAgent::Plugins::CodeDeployPlugin::CommandPoller: Missing credentials - please check if this instance was started with an IAM instance profile 的错误，可能是由于下列原因之一导致：

IAM 实例配置文件授予 CodeDeploy 代理与 Amazon S3 通信 CodeDeploy以及从 Amazon S3 下载您的修订版的权限。对于 EC2 实例，请参阅 适用于 Amazon CodeDeploy的身份和访问管理。对于本地实例，请参阅Working with On-Premises Instances。

部署失败，显示消息“PKCS7 签名的消息验证失败”

此错误消息表示实例运行的 CodeDeploy 代理版本仅支持 SHA-1 哈希算法。2015 年 11 月发布的 CodeDeploy 代理版本 1.0.1.854 中引入了对 SHA-2 哈希算法的支持。自 2016 年 10 月 17 日起，如果安装的 CodeDeploy 代理版本低于 1.0.1.854，则部署将失败。有关更多信息，请参阅Amazon 要切换到 SSL 证书的 SHA256 哈希算法，注意：停用早于 1.0.1.85 版本 CodeDeploy 的主机代理，以及。更新代 CodeDeploy 理

将相同的文件部署或重新部署到相同的实例位置失败，出现错误“The deployment failed because a specified file already exists at this location”

当 CodeDeploy 尝试将文件部署到实例，但指定的目标位置已存在同名文件时，部署到该实例可能会失败。您可能会收到错误消息“The deployment failed because a specified file already exists at this location: location-name.” 这是因为，在每次部署期间， CodeDeploy 首先会删除先前部署中的所有文件，这些文件列在清理日志文件中。如果目标安装文件夹中存在未在此清理文件中列出的文件，则默认情况下， CodeDeploy 代理会将其解释为错误并导致部署失败。

避免此错误的最简单方式是，指定默认行为之外的选项以使部署失败。对于每个部署，您可以选择是使部署失败、覆盖清除文件中未列出的文件，还是保留实例上已有的文件。

覆盖选项在以下情况下很有用：您在上一个部署后手动将文件放置在实例上，然后将一个同名文件添加到下一个应用程序修订。

您可以为您在要成为下一部署的一部分的实例上放置的文件选择保留选项，而无需将这些文件添加到应用程序修订包。如果您的应用程序文件已存在于生产环境中，并且您想首次使用 CodeDeploy 进行部署，则保留选项也很有用。有关更多信息，请参阅 创建 EC2/本地计算平台部署（控制台） 和 现有内容的回滚行为。

排查 The deployment failed because a specified file already exists at this location 部署错误

如果您选择不指定覆盖或保留在目标部署位置 CodeDeploy检测到的内容的选项（或者您没有在编程命令中指定任何用于处理现有内容的部署选项），则可以选择对错误进行故障排除。

以下信息仅在您选择不保留或覆盖内容的情况下适用。

如果您尝试重新部署具有相同名称和位置的文件，则如果指定应用程序名称和部署组的底层部署组 ID 与之前使用的相同，则重新部署更有可能成功。 CodeDeploy 使用底层部署组 ID 来识别要在重新部署之前删除的文件。

将新文件部署到实例上的相同位置或将相同的文件重新部署到实例上的相同位置可能会因以下原因而失败：

要处理这些情况，请执行下列操作之一：

长文件路径会导致“没有这样的文件或目录”错误

对于到 Windows 实例的部署，如果您的 appspec.yml 文件的“files”部分的文件路径大于 260 个字符，则您可能会看到部署失败并显示类似以下内容的错误：

No such file or directory @ dir_s_mkdir - C:\your-long-file-path

之所以出现此错误，是因为默认情况下，Windows 不允许文件路径超过 260 个字符，详见 Microsoft 文档。

对于 CodeDeploy 代理版本 1.4.0 或更高版本，您可以通过两种方式启用长文件路径，具体取决于代理安装过程：

如果尚未安装 CodeDeploy 代理：

如果已经安装了 CodeDeploy 代理：

长时间运行的进程可能会导致部署失败

对于部署到 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 生命周期事件进行故障排除

在某些情况下，蓝/绿部署在 AllowTraffic 生命周期事件期间会失败，但部署日志并未指出失败的原因。

这种故障通常是由于在 Elastic Load Balancing 中，用于管理部署组流量的经典负载均衡器、应用程序负载均衡器或网络负载均衡器的运行状况检查配置不正确造成的。

要解决这一问题，请检查并更正负载均衡器的运行状况检查配置中的错误。

有关传统负载均衡器，请参阅经典负载均衡器用户指南和 Elastic Load Balancing API 参考版本 2012-06-01 ConfigureHealthCheck中的配置运行状况检查。

对于应用程序负载均衡器，请参阅《应用程序负载均衡器用户指南》中的目标组的运行状况检查。

对于网络负载均衡器，请参阅《网络负载均衡器用户指南》中的目标组的运行状况检查。

对失败 ApplicationStop BeforeBlockTraffic、或 AfterBlockTraffic 部署生命周期事件进行故障排除

在部署期间， CodeDeploy 代理会运行上一次成功部署 AppSpec 的文件 AfterBlockTraffic 中为 ApplicationStop BeforeBlockTraffic、和指定的脚本。（所有其他脚本都从当前部署中的 AppSpec 文件运行。） 如果这些脚本之一包含错误且未成功运行，则部署可能失败。

这些失败的可能原因包括：

使用 CodeDeploy 控制台调查在上述任何事件期间部署可能失败的原因。在部署的详细信息页上，选择查看事件。在实例的详细信息页面上，在ApplicationStopBeforeBlockTraffic、或AfterBlockTraffic行中，选择查看日志。或者使用 Amazon CLI 调用get-deployment-instance命令。

如果失败的原因是上次成功部署的脚本从未成功运行，请创建一个部署并指定应忽略 ApplicationStop BeforeBlockTraffic、和 AfterBlockTraffic 失败。有两种方式可执行此操作：

当您重新部署应用程序修订时，部署将继续，即使这三个生命周期事件中的任一事件失败也是如此。如果新的修订已包含针对这些生命周期事件的修复脚本，未来的部署无需应用此修复就能成功。

使用以下命令对失败的 DownloadBundle 部署生命周期事件进行故障排除 UnknownError：未打开供读取

如果您尝试从 Amazon S3 部署应用程序修订，但在部署生命周期事件期间 DownloadBundle 部署失败并UnknownError: not opened for reading显示错误：

在部署的事件详细信息页的下载服务包行中，选择查看日志。或者使用 Amazon CLI 调用get-deployment-instance命令。如果出现此错误，则输出中应有一个错误代码为 UnknownError 且错误消息为 not opened for reading 的错误。

要确定此错误的原因，请执行以下步骤：

有关如何查找线路日志文件以及如何启用和禁用线路日志记录的信息，请参阅:log_aws_wire:CodeDeploy 代理配置参考中的。

排查所有生命周期事件跳过错误

如果跳过了 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) 的错误。这里介绍了一些可能的原因和解决方案：

默认情况下，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