为什么每次 Elastic Beanstalk 向其实例发出命令时总是超时？答案

【问题标题】：Why every time Elastic Beanstalk issues a command to its instance it always timed out?为什么每次 Elastic Beanstalk 向其实例发出命令时总是超时？
【发布时间】：2014-05-14 23:24:48
【问题描述】：

我有一个 PHP 应用程序部署到 Amazon Elastic Beanstalk。但是我注意到一个问题，每次我通过 git aws.push 将代码更改推送到 Elastic Beanstalk 时，部署的应用程序都没有接收到更改。我检查了我的应用程序 Beanstalk 环境中的事件日志，并注意到每次 Beanstalk 问题：

将新版本部署到实例

后面总是跟着：

以下实例在允许的命令超时时间内没有响应（它们最终可能仍会自行完成）： [i-d5xxxxxx]

当我尝试请求快照日志时，也会发生同样的事情。魔豆问题：

requestEnvironmentInfo 正在启动

几分钟后又是：

以下实例在允许的命令超时时间内没有响应（它们最终可能仍会自行完成）：[i-d5xxxxx]。

【问题讨论】：

嗨 - 我今天突然遇到同样的问题，我的一个应用程序进行了一次小的增量更新。我认为这一定是亚马逊的一个（希望是暂时的）问题。
我在环境更新和日志方面都遇到了同样的事情（4 月 24 日）。我有一个负载平衡的环境，但我认为只有一个实例在运行。由于更新和日志都会发生这种情况，我认为这不是网络问题（即作曲家在获取存储库时超时。）ardford 和@Simon Robb - 这个问题消失了吗？
@Chris Carson 很遗憾没有——我不得不重建我的环境，从那时起事情进展顺利。
@SimonRobb 是的，我也必须这样做。我不认为这是一个暂时的问题——似乎很多人都在发生。感谢您的回复。
通过来之不易的经验以及与亚马逊支持人员的对话，我发现这与您使用的实例的大小有关。如果 t1.micro 实例正在为“实时”网站提供服务 - 即如果它们从外部世界获得任何类型的流量，它们通常不会响应 git aws.push。因此，在您向客户展示后的关键几天，您在开发时表现出色的东西却惨遭失败。到目前为止，我发现的唯一解决方案是增加环境中实例的大小并交换环境 URL。

标签： amazon-web-services amazon-elastic-beanstalk

【解决方案1】：

我遇到过几次这个问题。它似乎只影响特定的实例。因此可以通过终止 EC2 实例来解决（通过管理控制台上的 EC2 页面完成）。此后，Elastic Beanstalk 将检测到有 0 个健康实例并自动启动一个新实例。

如果这是一个生产环境，并且您只有 1 个实例并且您希望最短的停机时间

将最小实例配置为 2，Beanstalk 将为您启动另一个实例。
通过 EC2 选项卡终止有问题的实例，Beanstalk 将为您启动另一个实例，因为最小实例为 2
将最小实例配置回 1，Beanstalk 将删除您的两个实例之一。

【讨论】：

这个问题仍然发生在我身上，我不知道为什么它会偶尔发生一次。好像亚马逊还没有修复它。我在日志中找不到任何东西为什么会发生，甚至在我部署之前已经成功部署的文件时也会发生，所以我怀疑文件是错误的。有人知道为什么会这样吗？
一次简单的实例重启对我有用 :)
停止并从 EC2 为我恢复工作。它为我创建了一个新实例并将当前实例移动到新实例，并终止旧实例。
导致服务器时钟漂移，不再同步。我不知道是什么导致了这种漂移（默认的 Elastic Beanstalk 实例都设置了 NTP），但是一旦漂移超过大约一两分钟，它将不再响应来自 Elastic Beanstalk 的消息。如果您检查 /var/log/cfn-hup.log，您将看到类似于：Invocation xxx of command ElasticBeanstalkCommand-AWSEBAutoScalingGroup for stack arn:aws:cloudformation:... expired at 2016-03-07T02:19:37; skipping 的行。我发现唯一可行的解决方案是上面的答案：重新启动（或重建）。
有人对此有任何永久解决方案吗？重新启动是我现在唯一的选择。这仍然经常发生，beantalk 从来没有解释过它的原因。我几乎可以用服务器做所有事情，只是 Beanstalk 认为服务器已经死了。

【解决方案2】：

默认情况下，如果您的命令未及时完成，Elastic Beanstalk 在 8 分钟（设置中定义的 480 秒）后“引发超时异常”。您可以设置更长的时间，最长可达 30 分钟（1800 秒）。

{
    "Namespace": "aws:elasticbeanstalk:command",
    "OptionName": "Timeout",
    "Value": "1800"
}

在这里阅读：http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-options.html

【讨论】：

您好，感谢您的回答。但我认为问题不在于命令需要多长时间才能完成。因为需求发生了一些变化，我不得不重新配置 Beanstalk 应用程序。由于这些更改，Beanstalk 然后重新创建 EC2 实例。应用程序恢复运行后，我尝试了与以前相同的操作，但问题消失了，命令在一分钟内完成！我真的不知道真正的问题是什么，但我怀疑这是因为在我的旧配置中，Beanstalk 未能向其底层 EC2 实例发出命令。
你把这个放在哪里？
@Spoeken - 在 .ebextensions 目录中的 myapp.config 文件中
3600 是新的最大限制。
如果您从命令行使用eb deploy，您可以添加--timeout 参数，后跟您想要设置超时的分钟数。例如：eb deploy --timeout 30 my-prod-app 为您的 my-prod-app elasticbeanstalk 部署设置 30 分钟超时

【解决方案3】：

Beanstalk 部署（以及获取日志等其他功能）通过向实例发送 SQS 命令来工作。 SQS 客户端部署到实例并大约每 20 秒检查一次队列（请参阅 /var/log/cfn-hup.log）： 2018-05-30 10:42:38,605 [DEBUG] 接收队列https://sqs.us-east-2.amazonaws.com/124386531466/93b60687a33e19的消息...

如果 SQS 客户端崩溃或在 t1/t2 实例上出现网络问题，则它将无法接收来自 Beanstalk 的命令，并且部署将超时。重启实例会重启 SQS 客户端，它可以再次接收命令。

更简单的修复 SQS 客户端的方法是重启 cfn-hup 服务：

sudo service cfn-hup restart

【讨论】：

【解决方案4】：

这里有同样的问题（单个 t1.micro 实例）。

通过管理控制台上的 EC2 页面（而不是 EB 页面）重启 EC2 实例确实解决了问题。

【讨论】：

【解决方案5】：

在部署的情况下，关闭 EC2 实例并等待 Elastic Beanstalk 做出反应或弄乱最小和最大实例的替代方法是简单地在目标环境。

如果之前的部署由于超时而失败，那么新版本仍会在环境中注册，但由于超时，它似乎无法运行（根据我的经验，实例似乎仍在运行旧版本） .

重建环境似乎会重置正在使用的新版本。

很明显，停机一段时间也有不利的一面。

【讨论】：

应该注意的是，重建你的环境会破坏弹性 beanstalk 可能控制的任何数据库。所以请谨慎行事。

【解决方案6】：

我认为这是处理这个问题的正确方法。我认为解决这个问题的正确方法是通过执行this answer suggests 来找出超时的原因。

chongzixin's answer 是如果您需要在调查超时原因之前尽快修复此问题，则需要执行此操作。

但是，如果您确实需要增加超时，请参阅以下内容：

将配置文件添加到名为 .ebextensions 的文件夹中的源代码中，并将其部署到应用程序源包中。

例子：

option_settings:
  "aws:elasticbeanstalk:command":
    Timeout: 2400

*"value" 表示超时前的时间长度，以秒为单位。

参考：https://serverfault.com/a/747800/496353

【讨论】：

问题是即使使用 Windows 实例也会发生这种情况......重新启动不起作用。似乎是 SQS 问题。

【解决方案7】：

Elastic Beanstalk 管理仪表板中“操作”菜单中的“重新启动应用程序服务器”，然后是 eb deploy 为我修复了它。

Visual cue for the first instruction

【讨论】：

【解决方案8】：

在检查了两天的随机问题后，我一个接一个地重新启动了两个 EC2 实例，以确保没有停机。网站运行良好，但一段时间后，网站开始抛出错误 504。

当我检查 http 服务器时，nginx 已关闭并抛出“Out of HDD space”。 “增加了 HDD 大小”，弹性豆茎创建了新实例并修复了问题。

【讨论】：

【解决方案9】：

对我来说，问题在于我的 VPC 安全组规则。根据the docs,，您需要允许端口 123 上的出站流量才能使 NTP 工作。我关闭了端口，因此时钟在漂移，因此 EC2 对来自 Elastic Beanstalk 环境的命令变得无响应，需要很长时间才能部署（只是超时）无法获取日志等。

感谢@Logan Pickup 在您评论中的提示。

【讨论】：