amazon-web-services - Elastic Beanstalk : duration of environment creation vs immutable deployment

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 中创建的环境。这大约需要 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 文件具有相同的命令和输出，并且从启动到应用程序部署 - 命令 CMD-Startup 成功 的持续时间也接近相同:都略多于 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}}"}

新创建的环境的日志看起来相同，除了最后一行。

其他信息:

根据下面的事件(在不同时间部署同一应用程序)，我假设新实例在应用程序更新开始后大约 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 支持 收到的部分回复，比我以前更清楚地解释了这些差异:

What will happen on environment creation

1) The new environment creation command is issued

2) A CloudFormation stack is created to launch the resources associated with the environment

3) The instance or instances that will be launched as part of the AutoScaling group are provisioned: this implies to execute, in that particular case, CMD-StartUp which will execute also all the hooks associated. At this time the environment is provisioned.

What will happen on Immutable Deployments

1) A new CloudFormation stack is created to so the current one is not getting modified

2) One instance is being launched in a temporary AutoScaling group

3) The instance is provisioned the same way as the existing one was at environment creation with CMD-StartUp

4) The instance, once ready, is added to the environment's load balancer

5) The instance has to pass all health checks. If the environment is of type "Web server", it needs to pass 12 consecutive health checks; if the environment is of type "worker", it needs to pass 18 health checks. Since Enhanced health check is reporting the status every 10 seconds, it means that in the best possible scenario, this is going to take 2 minutes (10 x 12 = 120). (More information regarding this [1])

6) The "CMD-ImmutableDeploymentFlip" command needs to be executed on the new instance/instances, which will then call the "infra-reregister-cfn-hup.rb" script and performs different actions

7) Post-deployment configuration starts

8) When deployment succeeded, the old instance(s) needs to be terminated

9) The deployment is completed.