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

Question

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

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

谁能解释一下？

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

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

1. 使用 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
   

2. 从“应用程序版本”页面选择示例应用程序（即在步骤 1 中使用的完全相同的应用程序版本），并将其部署（不可变）到在步骤 1 中创建的环境中。这大约需要。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 分钟？

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

Answer 1

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

环境创建会发生什么

1）下发新环境创建命令

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

3) 将作为 AutoScaling 组的一部分启动的一个或多个实例被提供：这意味着在这种特殊情况下执行 CMD-StartUp，它也将执行所有关联的钩子。这时候环境就配置好了。

不可变部署会发生什么

1) 创建一个新的 CloudFormation 堆栈，因此当前堆栈不会被修改

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

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

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

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

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

7) 部署后配置开始

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

9) 部署完成。