3

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

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

让我感到困惑的是为什么salt-cloud需要这么长时间来部署基本机器。

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

关于盐云，我是否缺少一些明显的东西让它变得如此缓慢？它可以以某种方式加速吗？我更喜欢使用 full salt stack，但由于目前的速度问题，我真的负担不起。

4

1 回答 1

3

请注意，这个答案是基于我对 terraform 和 salt-cloud 的理解的推测，我还没有通过实验验证！

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

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

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

按照我的思路，这也应该意味着，如果你在详细调试模式下运行 salt-cloud 或查看它生成的网络流量，在你提到的前 130 秒内（在它说“部署 VM”之前），你应该看到从 salt-cloud 到云提供商的查询以动态构建状态。

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

于 2017-07-02T12:57:26.867 回答