AWS CodeDeploy
User Guide (API Version 2014-10-06)
AWS 服务或AWS文档中描述的功能,可能因地区/位置而异。点 击 Getting Started with Amazon AWS to see specific differences applicable to the China (Beijing) Region.

解决部署问题

注意

通过查看部署过程中创建的日志文件可以确定很多部署失败的原因。为简单起见,我们建议您使用 Amazon CloudWatch Logs 集中监控日志文件,而不是逐个实例查看这些文件。有关信息,请参阅在 CloudWatch Logs 控制台中查看 AWS CodeDeploy 日志

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

此错误消息指示实例正在运行仅支持 SHA-1 哈希算法的 AWS CodeDeploy 代理版本。对 SHA-2 哈希算法的支持是在 AWS CodeDeploy 代理的 1.0.1.854 版(在 2015 年 11 月发布)中引入的。自 2016 年 10 月 17 起,如果安装了低于 1.0.1.854 版本的 AWS CodeDeploy 代理,部署将会失败。有关更多信息,请参阅 AWS 切换到 SSL 证书的 SHA256 哈希算法通知:停用低于 1.0.1.85 版本的 AWS CodeDeploy 主机代理更新 AWS CodeDeploy 代理

排查 ApplicationStop 部署生命周期事件失败的问题

ApplicationStop 部署生命周期事件期间,部署可能会由于下列原因之一而导致失败:

  • AWS 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 文件无效或脚本无法成功运行。

使用 AWS CodeDeploy 控制台调查部署在此事件期间失败的可能原因。在部署的事件详细信息页的 ApplicationStop 行中,选择 View logs。或者,使用 AWS CLI 调用 get-deployment-instance 命令。

注意

通过查看部署过程中创建的日志文件可以确定很多部署失败的原因。为简单起见,我们建议您使用 Amazon CloudWatch Logs 集中监控日志文件,而不是逐个实例查看这些文件。有关信息,请参阅在 CloudWatch Logs 控制台中查看 AWS CodeDeploy 日志

您必须使用 AWS CLI(而不是 AWS CodeDeploy 控制台)从 ApplicationStop 部署生命周期事件期间失败的部署中恢复。调用 create-deployment 命令、设置 --ignore-application-stop-failures 选项,然后重新部署应用程序修订。部署将继续,即使 ApplicationStop 部署生命周期事件再次失败也是如此。

排查失败的 DownloadBundle 部署生命周期事件的问题,错误为“UnknownError: not opened for reading”

如果您正在尝试从 Amazon S3 部署应用程序修订,并且部署在 DownloadBundle 部署生命周期事件期间失败,错误为“UnknownError: not opened for reading”:

  • 发生内部 Amazon S3 服务错误。请重新部署应用程序修订。

  • Amazon EC2 实例上的 IAM 实例配置文件无权访问 Amazon S3 中的应用程序修订。有关 Amazon S3 存储桶策略的信息,请参阅推送修订部署先决条件

  • 您将部署到的实例与一个区域(例如,美国西部(俄勒冈))关联,而包含应用程序修订的 Amazon S3 存储桶与另一个区域(例如,美国东部(弗吉尼亚北部))关联。请确保 Amazon S3 存储桶中的应用程序修订与实例所在的区域关联。

在部署的事件详细信息页的 Download bundle 行中,选择 View logs。或者,使用 AWS CLI 调用 get-deployment-instance 命令。如果出现此错误,则输出中应有一个错误代码为“UnknownError”且错误消息为“not opened for reading”的错误。

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

  1. 对至少一个实例启用线路日志记录,然后重新部署应用程序修订。

  2. 查看线路日志记录文件以找到错误。此问题的常见错误消息包括短语“access denied”。

  3. 在查看日志文件后,建议您禁用线路日志记录以减小日志文件的大小并减少将来可能会在实例上的输出中以纯文本格式出现的敏感信息量。

要了解如何查找线路日志记录文件以及启用和禁用线路日志记录,请参阅 使用 AWS CodeDeploy 代理中的 :log_aws_wire:

默认情况下,Windows PowerShell 脚本无法使用 64 位版本的 Windows PowerShell

如果作为部署的一部分运行的某个 Windows PowerShell 脚本依赖 64 位功能(例如,因为它占用的内存多于 32 位应用程序允许的内存,或调用的库仅在 64 位版本中提供),则该脚本可能会崩溃或无法按预期运行。这是因为,默认情况下,AWS CodeDeploy 使用 32 位版本的 Windows PowerShell 运行作为应用程序修订的一部分的 Windows PowerShell 脚本。

将类似于以下内容的代码添加到任何必须使用 64 位版本的 Windows PowerShell 运行的脚本的开头:

Copy
# 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 Linux、Ubuntu Server 和 RHEL 实例的部署,如果您的部署脚本启动了长时间运行的进程,则 AWS CodeDeploy 可能会在部署生命周期事件中等待较长的时间,然后使部署失败。这是因为,在该进程运行的时间比该事件中的前台和后台进程预期的所需时间长的情况下,AWS CodeDeploy 将停止部署并使其失败,即使该进程仍按预期运行也是如此。

例如,应用程序修订在其根目录下包含两个文件:after-install.shsleep.sh。其 AppSpec 文件包含以下说明:

Copy
version: 0.0 os: linux files: - source: ./sleep.sh destination: /tmp hooks: AfterInstall: - location: after-install.sh timeout: 60

after-install.sh 文件在 AfterInstall 应用程序生命周期事件期间运行。以下是其内容:

Copy
#!/bin/bash /tmp/sleep.sh

sleep.sh 文件包含以下内容,它会使程序执行暂停 3 分钟(180 秒),并模拟某个长时间运行的进程:

Copy
#!/bin/bash sleep 180

after-install.sh 调用 sleep.sh 时,sleep.sh 将启动并保持运行状态 3 分钟(180 秒),它比 AWS CodeDeploy 预期 sleep.sh(以及相关联的 after-install.sh)停止运行的时间晚 2 分钟(120 秒)。在超时 1 分钟(60 秒)后,AWS CodeDeploy 将在 AfterInstall 应用程序生命周期事件处停止部署并使其失败,即使 sleep.sh 继续按预期运行也是如此。将显示以下错误:

Script at specified location: after-install.sh failed to complete in 60 seconds

仅在 after-install.sh 中添加 & 符号无法在后台运行 sleep.sh

Copy
#!/bin/bash # Do not do this. /tmp/sleep.sh &

这样做可能使部署在长达 1 小时(默认值)的部署生命周期事件超时时段内保持挂起状态,随后 AWS CodeDeploy 将像之前一样在 AfterInstall 应用程序生命周期事件处停止部署并使其失败。

after-install.sh 中,调用 sleep.sh(如下所示),后者支持 AWS CodeDeploy 在进程开始运行后继续:

Copy
#!/bin/bash /tmp/sleep.sh > /dev/null 2> /dev/null < /dev/null &

在之前的调用中,sleep.sh 是要在后台开始运行的进程的名称,该进程将 stdout、stderr 和 stdin 重定向到 /dev/null