我应该在AWS上使用什么进行配置管理？

#1 楼

查找类似内容的比较信息的一种好方法是使用Google搜索“ X vs Y”，例如“ Chef vs AWS stacks”，“ Chef vs Puppet”之类的东西。确实可以得到主观信息，尽管它不像是动手实践，但您仍然可以在这里或那里找到一些不错的块。例如，Chef为您提供了完整的Ruby语言，而Puppet有一个基于红宝石的DSL。这对你有关系吗？只有你能说出来。

根据我对Puppet / Ansible的经验（我还不知道厨师），大部分都是因为味道。例如，我真的很喜欢Ansible只需要一个有效的ssh密钥，而不需要其他任何事实。我喜欢没有中央存储库。其他人可能喜欢Puppet有一个存储库的事实。另外，我喜欢简单的配置文件格式。但这一切都是主观的。

因此，为了追赶，我的建议是：


如果您完全致力于AWS，请使用AWS Stacks，永远不会更改为其他提供商，就像与AWS功能的更高集成一样。无论如何，它都会在内部使用Chef，并向您公开Chef文件。
如果您想学习新知识并希望与供应商保持独立，请直接使用Chef。如果您以后决定完全提交给AWS，那么您应该可以这样做。
如果您更喜欢Puppet，或者如果可以，可以使用Puppet（AWS似乎也开始提供支持）。 t站厨师。

#2 楼

一个考虑因素可能是锁定。例如，亚马逊的云很快就会变得昂贵-是因为计算最终超出了您的估计，或者总是有亚马逊决定提高其计算价格成本的可能性。这可能会导致您想要将云服务提供商更改为便宜的云服务提供商，或者您可能将其扩展到某种程度上使其具有更大的财务意义。例如，Spectre和Meltdown漏洞在管理程序上特别令人讨厌，并提供了一些可能性和前景，可以将客人跳入管理程序或从管理程序上的另一个租户那里获取敏感信息。潜在场景可能实现，也可能未实现，也可能不现实，但是尽管如此，通过选择易于导出到其他云的内容，您可以保持敏捷性并轻松部署到另一个云或内源中。这可以防止上述情况或任何其他可能发生的情况。 -not-pets哲学，因为这使您可以立即开始在新的云或群集中开始旋转新的计算实例。您无需迁移虚拟机。 （希望您没有大量数据要导出）。

这就是说：避免使用AWS堆栈也许是明智之举，这样您就不会被该特定供应商所困。