我将 salt-cloud 和 terraform 作为管理GCE基础架构的工具进行比较。我们使用 salt stack 来管理VM配置，因此我自然希望使用 salt-cloud 作为堆栈的一个组成部分，并逐步淘汰terraform作为遗留物。
然而，我的用例对于VM部署时间至关重要，因为我们提供PaaS解决方案，并根据客户请求部署VM，因此需要在几秒钟内通过单击按钮提供准备好的VM。
令我困惑的是为什么 salt-cloud 需要很长时间来部署基本机器。
我使用 terraform 和 salt-cloud （均为并行模式），基于默认的CentOS7图像部署了三个VM，创建了一对一的简单测试。时差非常惊人 - terraform 需要大约30秒来部署请求的机器（类似于通过GCE GUI部署所需的时间）， salt-cloud 需要在同一区域中在同一帐户下部署完全相同的计算机220秒。特别奇怪的是，前130秒 salt-cloud 没有开始部署，看起来什么都没有，只有在大约130秒后才通过它显示消息deploying VMs，这些虚拟机出现在GUI中in deployment。
是否有一些显而易见的事情让我错过 salt-cloud 让它变得如此之慢？能以某种方式加速吗？ 我更愿意使用完整的盐栈，但是考虑到目前的速度问题，我无法承受这一点。
答案 0 :(得分：3)
请注意，这个答案是根据我对terraform和salt-cloud的理解推测的，我还没有通过实验验证过！
我认为原因是Terraform保持上次运行的状态（本地或远程），而salt-cloud不保持状态，因此在实际配置任何内容之前查询云。< / p>
这两种方法（在做某事之前保持状态或查询）是必需的，因为这两种工具都是幂等的（你可以安全地多次运行它们）。
例如，我认为如果您删除Terraform的状态文件并重新运行它，它将假设云中没有任何内容并且实际上会实例化重复。这并不意味着terraform做错了，它表明状态是重要的，Terraform文档清楚地说明，当在团队中运行时，应该远程保存状态，以避免这种问题。
按照我的说法，这也应该意味着如果您在详细调试模式下运行salt-cloud或查看由它生成的网络流量，那么在前130秒内你会提到（在它说“部署虚拟机”之前） ），您应该看到从salt-cloud到云提供商的查询，以动态构建状态。
最后一点，salt-cloud不存储先前运行状态的事实并不意味着它在团队环境中自动安全使用。只要没有两个团队成员同时运行它，就可以安全使用。另一方面，Consul上具有远程状态的terraform允许例如锁定，因此团队并发使用将始终是安全的。