deployment - 与 Terraform 相比，为什么 salt 云这么慢？

Question

我将 salt-cloud 和 terraform 作为管理 GCE 基础设施的工具进行比较。我们使用 salt stack 来管理 VM 配置，所以我自然更愿意使用 salt-cloud 作为堆栈的一个组成部分，并逐步淘汰 terraform 作为遗留物。

但是，我的用例对 VM 部署时间至关重要，因为我们提供 PaaS 解决方案，并根据客户要求部署 VM，因此需要在几秒钟内通过单击按钮交付就绪的 VM。

令我困惑的是为什么salt-cloud需要这么长时间来部署基 native 器。

我使用 terraform 和 salt-cloud(均以并行模式)基于默认 CentOS7 镜像部署了三个虚拟机，从而创建了并驾齐驱的简单测试。而且时间差异惊人 - terraform 需要大约 30 秒来部署请求的机器(这类似于通过 GCE GUI 部署所需的时间)，salt-cloud 需要大约220 秒在同一区域的同一帐户下部署完全相同的机器。特别奇怪的是，前 130 秒 salt-cloud 没有开始部署并且似乎什么也没做，只有在大约 130 秒后它才显示消息 deploying VMs 和那些 VMs在 GUI 中显示为 in deployment。

salt-cloud 是否有明显的遗漏导致它变得如此缓慢？它能以某种方式加速吗？我更愿意使用完整的salt stack，但由于目前的速度问题，我真的负担不起。

Answer 1

请注意，这个答案是基于我对地形和 salt 云的理解的推测，我还没有通过实验验证!

我认为原因是 Terraform 保留了之前运行的状态(本地或远程)，而 salt-cloud 不保留状态，因此在实际配置任何内容之前查询云。

这两种方法(在做某事之前保持状态或查询)是必需的，因为这两种工具都是幂等的(您可以安全地多次运行它们)。

例如，我认为如果您删除 Terraform 的状态文件并重新运行它，它会假定云中没有任何内容，并且实际上会实例化一个副本。这并不是说 Terraform 做错了，而是为了表明状态很重要，Terraform 文档明确表示在团队中运行时应该远程保存状态，正是为了避免此类问题。

按照我的说法，这也意味着如果您在详细 Debug模式下运行 salt-cloud 或查看它生成的网络流量，在您提到的前 130 秒内(在它说“部署虚拟机”之前) )，您应该看到从 salt-cloud 到云提供商的查询以动态构建状态。

最后一点，salt-cloud 不存储先前运行的状态这一事实并不意味着在团队环境中使用它是自动安全的。只要没有两个团队成员同时运行它，就可以安全使用。另一方面，Consul 上具有远程状态的 Terraform 允许例如锁定，因此团队并发使用将始终是安全的。