Question

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

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

有人可以解释吗？

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

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

使用EB（网络）管理控制台，使用默认的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中创建的环境中。 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}}"}

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

其他信息：

在下面的事件中（同一应用在不同的时间部署），我假设新实例在应用更新开始后大约需要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服务器”，它需要通过12个连续的健康检查；   如果环境属于“工人”类型，则需要通过18点健康   检查。由于增强型健康检查每10个报告一次状态   秒，这意味着在最佳情况下，这将   需要2分钟（10 x 12 = 120）。（有关此[1]的更多信息）

6）需要在以下位置执行“ CMD-ImmutableDeploymentFlip”命令   新的实例/实例，然后将其称为   “ infra-reregister-cfn-hup.rb”脚本并执行不同的操作

7）部署后配置开始

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

9）部署完成。

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

1 个答案:

创建环境时会发生什么

不可变部署将发生什么