EC2/本地部署故障排查 - AWS CodeDeploy

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

EC2/本地部署故障排查

注意

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

CodeDeploy 代理无法在 Windows 2016 上启动

运行时 CodeDeploy 代理安装程序文件 (CodeDeploy-agent.msi) 在 Windows 2016 上,.msi 文件无法启动,你会在中看到以下错误C:\Windows\TEMP\CodeDeploy-agent.msi_installer.log

Error 1920 Service 'CodeDeploy Host Agent Service' (CodeDeployagent) failed to start. Verify that you have sufficient privileges to start system services.

出现此错误的原因是 Windows Defender 防病毒软件阻止CodeDeploy-agent.msi文件无法运行。

要解决此问题,您必须在运行代理安装程序之前添加 Windows Defender 排除项。

添加 Windows Defender 排除项

  1. 使用以下 Powershell 语句添加排除项。确保以管理员身份运行它们。

    Write-Host ("Adding Windows Defender exclude for CodeDeploy...") Add-MpPreference -ExclusionPath ("C:\ProgramData\Amazon\CodeDeploy","$env:windir\Temp")
  2. 在代理安装之前添加排除项,作为自定义 AMI 的一部分或使用 Systems Manager 添加排除项。如果要将代理安装为用户数据的一部分,请在代理安装脚本之前一步添加排除项。

    有关更多信息,请参阅 。为 Windows 服务器安装 CodeDeploy 代理使用 Systems Manager Run Command 运行命令, 和启动时在 Windows 实例上运行命令.

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 的 Identity and Access Management。对于本地实例,请参阅Working with On-Premises Instances

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

此错误消息指示实例正在运行的 CodeDeploy 仅支持 SHA-1 哈希算法的代理。对 SHA-2 哈希算法的 Support 已在版本 1.0.1.854 中引入。 CodeDeploy 代理商,于 2015 年 11 月发布。自 2016 年 10 月 17 起,如果 CodeDeploy 已安装了低于 1.0.1.854 版本的代理。有关更多信息,请参阅 。AWS切换为 SSL 证书的 SHA256 哈希算法注意:停用 CodeDeploy 早于 1.0.1.85 版本的主机代理, 和更新 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 默认情况下,代理将此解释为错误并且部署失败。

注意

在 Amazon Linux、RHEL 和 Ubuntu 服务器实例上,清除文件位于/opt/CodeDeploy-agent/deployment-root/deployment-instructions/. 在 Windows 服务器实例上,位置为C:\ProgramData\Amazon\CodeDeploy\deployment-instructions\.

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

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

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

排查 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 的应用程序名称和部署组名称。(您可以将获取部署组命令来检索部署组 ID。) CodeDeploy 使用底层部署组 ID 和 AppSpec 文件来删除它在上一次成功部署中安装的所有文件。

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

对于到 Amazon Linux、Ubuntu 服务器和 RHEL 实例的部署,如果您的部署脚本启动了长时间运行的进程,则 CodeDeploy 可能会在部署生命周期事件中等待较长的时间,然后使部署失败。这是因为,在该进程运行的时间比该事件中的前台和后台进程预期的所需时间长的情况下, CodeDeploy 将停止部署并使其失败,即使该进程仍按预期运行也是如此。

例如,应用程序修订在其根目录下包含两个文件:after-install.shsleep.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.shsleep.sh启动并运行 3 分钟(180 秒),它比时间晚 2 分钟(120 秒)。 CodeDeploy 期待sleep.sh(而且,按照关系,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 &

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

Inafter-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 生命周期事件,但部署日志未指明失败的原因。

此失败通常是由于用于管理部署组流量的 Classic Load Balancer、应用程序负载均衡器或 Network Load Balancer 的弹性负载均衡器中配置了错误的运行状况检查。

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

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

有关应用程序负载均衡器,请参阅目标组的运行状况检查中的适用于应用程序负载均衡器的用户指南.

有关网络负载均衡器,请参阅目标组的运行状况检查中的Network Load Balancer 用户指南.

排查失败的 ApplicationStop、BeforeBlockTraffic 或 AfterBlockTraffic 部署周期事件

在部署过程中, CodeDeploy 代理运行指定的脚本为 ApplicationStop、BeforeBlockTraffic 和 AfterBlockTraffic 中的 AppSpec 来自上次成功部署的文件。(所有其他脚本从 AppSpec 在当前部署中存在的文件。) 如果这些脚本之一包含错误且未成功运行,则部署可能失败。

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

  • 这些区域有: CodeDeploy 代理找到deployment-group-id_last_successful_install文件位于正确位置,但是在deployment-group-id_last_successful_install文件不存在。

    在 Amazon Linux 上、Ubuntu 服务器和 RHEL 实例上,此文件必须存在于/opt/codedeploy-agent/deployment-root/deployment-instructions.

    在 Windows Server 实例上,此文件必须存储在C:\ProgramData\Amazon\CodeDeploy\deployment-instructionsfolder。

  • 在中列出的位置deployment-group-id_last_successful_install文件,要么 AppSpec 文件无效或脚本无法成功运行。

  • 这一脚本中包含无法更正的错误,所以永远无法成功运行。

使用 CodeDeploy 调查部署在这些事件中的任一事件期间失败的可能原因。在部署的详细信息页上,选择查看事件。在实例的详细信息页上,在 ApplicationStopBeforeBlockTrafficAfterBlockTraffic 行中,选择查看日志。或者使用AWS CLI调用获取部署实例命令。

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

  • 使用 CodeDeploy 以创建部署。在创建部署页上的 ApplicationStop 生命周期事件失败下,选择如果实例上的此生命周期事件失败,就不要将此部署到实例上

  • 使用 AWS CLI 调用 create-deployment 命令并包含 --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/ 本地部署)部署先决项.

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

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

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

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

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

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

有关如何查找线路日志记录文件以及启用和禁用线路日志记录的信息,请参阅: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). 这里介绍了一些可能的原因和解决方案:

  • 这些区域有: CodeDeploy 实例上可能未安装或运行代理。要确定是否将 CodeDeploy 代理正在运行:

    • 对于 Amazon Linux RHEL 或 Ubuntu 服务器,请运行以下命令:

      sudo service CodeDeploy-agent status
    • 对于 Windows,请运行以下命令:

      powershell.exe -Command Get-Service -Name CodeDeployagent

    如果 CodeDeploy 代理未安装或运行,请参阅验证 CodeDeploy 代理是否在运行.

    您的实例可能无法访问 CodeDeploy 或 Amazon S3 公有终端节点使用端口 443。请尝试以下任一操作:

    • 将公有 IP 地址分配到实例并使用其路由表来允许 Internet 访问。确保与实例关联的安全组允许端口 443 (HTTPS) 上的出站访问。有关更多信息,请参阅 CodeDeploy 代理的通信协议和端口

    • 如果是在私有子网中预配置了实例,请在路由表中使用 NAT 网关而不是 Internet 网关。有关更多信息,请参阅 NAT 网关

  • 适用于的服务角色 CodeDeploy 可能没有所需权限。要配置 CodeDeploy 服务角色,请参阅第 2 步:为 CodeDeploy.

  • 如果您使用 HTTP 代理,请在:proxy_uri:在中设置 CodeDeploy 代理配置文件。有关更多信息,请参阅 CodeDeploy 代理配置参考

  • 您部署实例的日期和时间签名可能与部署请求的日期和时间签名不匹配。查找类似于的错误Cannot reach InstanceService: Aws::CodeDeployCommand::Errors::InvalidSignatureException - Signature expired在您的 CodeDeploy 代理日志文件。如果您看到此错误,请按照排查“InvalidSignatureException – Signature expired: [time] is now earlier than [time]”部署错误中的步骤进行操作。有关更多信息,请参阅 查看 CodeDeploy EC2/本地部署部署的日志数据

  • 这些区域有: CodeDeploy 代理可能会由于实例内存或硬盘空间不足而停止运行。尝试通过更新以减少实例上的存档部署数量max_revisions在中设置 CodeDeploy 代理配置。如果您为 EC2 实例执行了此操作但问题仍然存在,请考虑使用较大的实例。例如,如果您的实例类型为 t2.small,请尝试使用 t2.medium。有关更多信息,请参阅 。CodeDeploy 代理安装的文件 CodeDeploy 代理配置参考, 和Amazon EC2 实例类型.

  • 您部署到的实例可能没有附加 IAM 实例配置文件,或者它可能附加了没有所需权限的 IAM 实例配置文件。

    • 如果您的实例没有附加 IAM 实例配置文件,请创建具有所需权限的实例,然后附加它。

    • 如果 IAM 实例配置文件已经附加到您的实例,请确保它具有所需的权限。

    在您确认附加的实例配置文件配置有所需权限之后,重新启动实例。有关更多信息,请参阅 。第 4 步:为您的 Amazon EC2 实例创建 IAM 实例配置文件适用于 Amazon EC2 的 IAM 角色中的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