【问题标题】:Failed to deploy application: During an aborted deployment, some instances may have deployed the new application version无法部署应用程序:在中止部署期间,某些实例可能已经部署了新的应用程序版本
【发布时间】:2021-01-24 15:22:31
【问题描述】:

我无法在 Elastic Beanstalk 上部署新版本。

在我尝试部署一个有很多问题的新版本之前,一切都运行良好(这不是我第一次在这个环境中部署一个新版本,我已经部署了几十个)。当我设法修复所有这些错误时,我得到了这些错误:

  • Failed to deploy application.
  • During an aborted deployment, some instances may have deployed the new application version. To ensure all instances are running the same version, re-deploy the appropriate application version.
  • Unsuccessful command execution on instance id(s) 'i-...'. Aborting the operation

我重新部署了不起作用的版本。

这是 Elastic Beanstalk 控制台:

Elastic Beanstalk console

Elastic Beanstalk events

Elastic Beanstalk 的请求日志按钮不返回任何内容。 EC2 实例的系统日志显示最后的工作版本日志。

我从 Configuration 导航窗格启用 CloudWatch 日志。它向 CloudWatch 日志中添加了 4 个文件:

  • /var/log/eb-activity.log -> 目前为空
  • /var/log/httpd/access_log -> 目前为空
  • /var/log/httpd/error_log -> 目前为空
  • /environment-health.log -> Command is executing on all instances (56 minutes or more elapsed).", "Incorrect application version found on all instances. Expected version \"prod-v1.7.28-0\" (deployment 128).

它是一个 Amazon Linux,t2.medium 实例,以 Apache 作为 Web 服务器

我已经尝试过的:

  • 每次将 .zip 的名称更改为与已部署的其他 zip 不同的名称
  • 终止实例,loadBalancer 自动创建一个新实例
  • 重启实例
  • 重建 Elastic Beanstalk 环境
  • 部署最简单的代码

我尝试使用以下代码仅部署一个 zip,但我遇到了同样的错误。

<html>
  <head>
    <title>This is the title of the webpage!</title>
  </head>
  <body>
    <p>This is an example paragraph. Anything in the <strong>body</strong> tag will appear on the page, just like this <strong>p</strong> tag and its contents.</p>
  </body>
</html>

它总是回到上一个工作版本,当我尝试部署新版本时它不起作用。

在一些帖子中,我看到有人说这可能是因为实例太小,但在它正常工作之前,并且从那时起大小没有改变。

如果您有任何问题或想法,我将不胜感激。 祝你有美好的一天!

答案: 问题出在您所说的日志中。我必须通过 ssh 进入我的 EC2 实例才能联系到他们。错误在文件cfn-init-cmd.log 中。 其中一个命令正在等待输入,因此它超时且没有错误消息。

【问题讨论】:

    标签: amazon-web-services amazon-ec2 amazon-elastic-beanstalk amazon-elb


    【解决方案1】:

    您应该检查 EBS 的日志,以了解有关您的部署出了什么问题的任何提示。 AWS 控制台 可能会有所帮助。

    还有可以从EC2获取的日志:

    CloudWatch 日志是另一项检查。

    您还应该检查自动缩放组,看看那里是否有任何运行状况检查。这些是什么支票?什么是宽限期?

    下面列出了 EC2 运行状况检查可能失败的原因。 您可以启动更好的 ec2 实例进行故障排除。

    实例状态检查。

    以下是可能导致实例状态检查失败的问题示例:

    系统状态检查失败

    网络或启动配置不正确

    内存耗尽

    文件系统损坏

    内核不兼容

    重建也是一个非常激烈的步骤,因为它会破坏和重建你的所有资源。例如,您的 ELB DNS 将消失,任何关联的 EIP 都将被释放。这些东西无法回收。

    【讨论】:

    • 是的,我经历了重建环境的“坏影响”。我不会再犯这个错误了^^。日志请求在 EBS 控制台上不起作用。通过使用 ssh 直接在服务器上查看,我不知道它是来自失败的上传还是最后一个工作版本的上传。 eb-engine.log 至少在 /var/log 中不存在
    • 关于弹性伸缩组,唯一的健康检查是Health check type: EC2和宽限期Health check grace period: 0。我对此一无所知,对不起,我不是创建自动伸缩组的人。
    • 是否启用了 cloudwatch 日志? ebs 中的事件有什么线索吗? ebs的健康状况如何?灰色、红色、橙色还是绿色?
    • No cloudwatch 日志未启用。健康状况下降。这些事件是我在问题中发布的错误。感谢您的帮助!
    • 刚刚添加了 EBS 控制台的屏幕截图。请求日志按钮被禁用?什么都不返回?
    猜你喜欢
    • 1970-01-01
    • 2020-02-18
    • 1970-01-01
    • 1970-01-01
    • 2013-03-08
    • 1970-01-01
    • 2021-01-18
    • 2013-10-29
    相关资源
    最近更新 更多