我有一个部署到Amazon Elastic Beanstalk的PHP应用程序。但是我注意到一个问题，每当我通过git aws.push将我的代码更改推送到Elastic Beanstalk时，部署的应用程序都没有获取更改。我检查了我的应用程序Beanstalk环境中的事件日志，并注意到每次Beanstalk发出时：
将新版本部署到实例
它总是紧随其后：
以下实例在允许的命令超时时间内没有响应（它们最终可能仍然自行完成）：[i-d5xxxxx]
当我尝试请求快照日志时，会发生同样的事情。 Beanstalk问题：
requestEnvironmentInfo正在启动
然后几分钟之后再次出现：
以下实例在允许的命令超时时间内没有响应（它们最终可能仍然自行完成）：[i-d5xxxxx]。
我有几次这个问题。它似乎只影响特定的实例。因此可以通过终止EC2实例来解决（通过管理控制台上的EC2页面完成）。此后，Elastic Beanstalk将检测到0个正常实例并自动启动新实例。
如果这是一个生产环境，并且您只有一个实例，并且您希望最小的停机时间
默认情况下，如果您的命令没有及时完成，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部署（以及Get Logs等其他功能）通过向实例发送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 Client，它可以再次接收命令。
修复SQS客户端的一种更简单方法是重启cfn-hup服务：
sudo service cfn-hup restart
这里有同样的问题（单个t1.micro实例）。
通过管理控制台上的EC2页面（而不是EB页面）重新启动EC2实例来解决问题。
在部署的情况下，关闭EC2实例并等待Elastic Beanstalk做出反应或使用最小和最大实例进行操作的替代方法是在目标环境中执行Rebuild环境。
如果先前的部署由于超时而失败，则新版本仍将针对环境进行注册，但由于超时，它似乎无法运行（根据我的经验，实例似乎仍在运行旧版本）。
重建环境似乎会重置使用新版本的东西。
显然，在一段时间的停机时间方面存在缺点。
我认为这是解决这个问题的正确方法。我认为处理这个问题的正确方法是通过做this answer suggests来找出超时的原因。
如果您在调查超时原因之前需要这个固定的ASAP，那么需要做chongzixin's answer。
但是，如果确实需要增加超时，请参阅以下内容：
将配置文件添加到名为.ebextensions的文件夹中的源代码中，并将其部署在应用程序源包中。
例：
option_settings:
"aws:elasticbeanstalk:command":
Timeout: 2400
*“value”表示超时前的时间长度（以秒为单位）。
从Elastic Beanstalk管理仪表板中的“Actions”菜单中“重新启动App Server”，然后eb deploy为我修复它。