Elastic Beanstalk：环境创建持续时间与不可变部署

Posted 2023-03-04

【中文标题】Elastic Beanstalk：环境创建持续时间与不可变部署

【英文标题】：Elastic Beanstalk: duration of environment creation vs immutable deployment

【发布时间】：2019-03-22 03:15:05

【问题描述】：

在使用 AWS Elastic Beanstalk (EB) 上的环境时，我注意到 创建 一个新的单实例环境比 不可变部署 到同一环境（使用完全相同的应用程序版本）。

我说的是 3 分钟 和 14 分钟，分别是在环境健康状况“正常”之前。

谁能解释一下？

可能我对环境与实例的概念是错误的，但我希望差异（如果有的话）是相反的。

这是工作流程的一个最小示例：

使用 EB（Web）管理控制台，使用默认 Python/Amazon-Linux 和默认示例应用程序创建新的单实例环境。默认配置仅更改为在开始创建环境之前将部署策略设置为“不可变”而不是“一次性”。这大约需要。 3 分钟：

2018-10-17 12:14:17 UTC+0200    INFO    Environment health has transitioned from Pending to Ok. Initialization completed 33 seconds ago and took 3 minutes.
2018-10-17 12:13:39 UTC+0200    INFO    Successfully launched environment: create-vs-deploy

从“应用程序版本”页面选择示例应用程序（即与步骤 1 中使用的完全相同的应用程序版本），并将其部署（不可变）到步骤 1 中创建的环境。这大约需要 10 分钟。 14 分钟：

2018-10-17 12:36:16 UTC+0200    INFO    Environment health has transitioned from Info to Ok. Application update completed 67 seconds ago and took 14 minutes.

后续部署也是如此，自定义应用版本的结果也类似。

两个实例的eb-activity.log 文件具有相同的命令和输出，并且从开始到Application deployment - Command CMD-Startup succeeded 的持续时间也几乎相同：都超过1 分钟。

不可变部署的日志会在 6 分钟后开始显示一些额外的行：

[2018-10-17T10:22:10.227Z] INFO  [2269]  - [Initialization] : Starting activity...
...
[2018-10-17T10:23:21.610Z] INFO  [2620]  - [Application deployment Sample Application@2/AddonsAfter] : Completed activity.
[2018-10-17T10:23:21.610Z] INFO  [2620]  - [Application deployment Sample Application@2] : Completed activity. Result:
  Application deployment - Command CMD-Startup succeeded
[2018-10-17T10:29:58.110Z] INFO  [3055]  - [Re-associating instance] : Starting activity...
...
[2018-10-17T10:29:58.115Z] INFO  [3055]  - [Re-associating instance] : Completed activity. Result:
  Re-associating instance - Command CMD-ImmutableDeploymentFlip succeeded

知道在 6 分钟的暂停期间发生了什么吗？ EB每次都要等待6分钟的健康检查吗？

此外，大约之间存在很大差异。 eb-activity.log 中从开始到结束的持续时间为 8 分钟，事件页面报告的持续时间为 14 分钟。

不确定它是否有帮助，但这是来自 healthd/daemon.log 的不可变部署：

# Logfile created on 2018-10-17 10:22:04 +0000 by logger.rb/47272
A, [2018-10-17T10:22:05.218449 #2186]   ANY -- : healthd daemon 1.0.3 initialized
W, [2018-10-17T10:22:05.369315 #2186]  WARN -- : log file "/var/log/httpd/healthd/application.log.2018-10-17-10" does not exist
...
W, [2018-10-17T10:23:16.646199 #2186]  WARN -- : log file "/var/log/httpd/healthd/application.log.2018-10-17-10" does not exist
W, [2018-10-17T10:36:55.231184 #2186]  WARN -- : discarding statistic item after validation error (Invalid timestamp): :id=>"0", :namespace=>"application", :timestamp=>1539771800, :data=>"\"duration\":10,\"latency_histogram\":[[0.213,1]],\"http_counters\":\"status_200\":1,\"request_count\":1"

新创建的 env 的日志除了最后一行之外看起来完全一样。

附加信息：

从下面的事件（在不同时间部署的同一应用程序）我假设新实例在应用程序更新开始后大约 12 分钟接管，之后旧实例被终止等。

2018-10-17 14:29:07 UTC+0200    INFO    Environment health has transitioned from Info to Ok. Application update completed 37 seconds ago and took 13 minutes.
2018-10-17 14:28:38 UTC+0200    INFO    Environment update completed successfully.
2018-10-17 14:28:38 UTC+0200    INFO    New application version was deployed to running EC2 instances.
2018-10-17 14:28:07 UTC+0200    INFO    Removed instance [i-0*******] from your environment.
2018-10-17 14:26:25 UTC+0200    INFO    Deployment succeeded. Terminating old instances and temporary Auto Scaling group.
2018-10-17 14:24:36 UTC+0200    INFO    Waiting for post-deployment configuration to complete.
2018-10-17 14:24:31 UTC+0200    INFO    Starting post-deployment configuration on new instances.
2018-10-17 14:23:31 UTC+0200    INFO    Attached new instance(s) to the permanent auto scaling group awseb-e-******-stack-AWSEBAutoScalingGroup*****.
2018-10-17 14:23:29 UTC+0200    INFO    Detached new instance(s) from temporary auto scaling group awseb-e-******-immutable-stack-AWSEBAutoScalingGroup*****.
2018-10-17 14:19:32 UTC+0200    INFO    Waiting for instance(s) (i-0******) to pass health checks.
2018-10-17 14:17:08 UTC+0200    INFO    Added instance [i-0******] to your environment.
2018-10-17 14:17:08 UTC+0200    INFO    Environment health has transitioned from Ok to Info. Application update in progress on 1 instance. 0 out of 1 instance completed (running for 2 minutes).
2018-10-17 14:15:19 UTC+0200    INFO    Created temporary auto scaling group awseb-e-*****-immutable-stack-AWSEBAutoScalingGroup-*******.
2018-10-17 14:14:33 UTC+0200    INFO    Immutable deployment policy enabled. Launching one instance with the new settings to verify health.
2018-10-17 14:14:24 UTC+0200    INFO    Environment update is starting.

【问题讨论】：

遇到类似问题，以前需要 20 秒的部署在设置为不可变时需要 12 分钟。

@BookOfGreg：不确定它是否会对您有所帮助，但您可以在下面找到我从 AWS 支持收到的答案。

【参考方案1】：

事实证明，与环境创建相比，不可变部署涉及的内容要多得多。以下是我从 AWS 支持 收到的部分回复，比以往任何时候都更清楚地解释了这些差异：

环境创建会发生什么

1) 发出新的环境创建命令

2) 创建 CloudFormation 堆栈以启动资源 与环境相关

3) 将作为 配置了 AutoScaling 组：这意味着要执行，因为 特殊情况，CMD-StartUp 也会执行所有的钩子 联系。此时环境已配置完毕。

不可变部署会发生什么

1) 创建了一个新的 CloudFormation 堆栈，因此当前堆栈不是 正在修改

2) 一个实例正在临时 AutoScaling 组中启动

3) 实例的配置方式与现有实例相同 在使用 CMD-StartUp 创建环境时

4) 实例一旦准备就绪，就会添加到环境的负载中 平衡器

5) 实例必须通过所有健康检查。如果环境是 “Web服务器”类型的，需要连续通过12次健康检查； 如果环境是“工人”类型，则需要通过 18 健康 检查。由于增强型健康检查每 10 次报告一次状态 秒，这意味着在最好的情况下，这将 花费 2 分钟 (10 x 12 = 120)。 （有关此 [1] 的更多信息）

6) “CMD-ImmutableDeploymentFlip”命令需要在 新的实例/实例，然后将调用 “infra-reregister-cfn-hup.rb”脚本并执行不同的操作

7) 部署后配置开始

8) 部署成功后，旧实例需要 终止

9) 部署完成。