是远程自动化还是本地自动化？

Question

如果运行像Ansible这样的自动化工具来在云中构建基础设施堆栈(例如AWS)，那么在云中的不同区域/VPC中拥有自动化工具和构建堆栈是否足够，或者让您的自动化工具和脚本在本地(拥有数据中心/机器)更有意义？

两者似乎都被使用了，但我只是想知道是否有一个最佳实践标准。

Answer 1

与塞拉a的很好的答案形成对比的是，我们尽可能多地从内部运行AWS。

我们从中获得的真正好处是，它允许我们使用运行詹金斯的集中式可抗服务器(在我们的例子中，Terraform用于实际的AWS配置，Ansible只用于配置EC2实例，并为管理任务运行临时剧本)。

然后，我们可以通过凭据和/或安全组/NACL控制对这些Jenkins服务器的访问。

这样做意味着我们可以控制拥有某种形式的凭据的人的数量，从而允许他们创建他们喜欢的任何东西和/或破坏他们喜欢的任何东西。

理想情况下，我们只能通过IAM EC2实例角色向Jenkins服务器提供凭据，但我们还没有完全做到这一点。

其中一个真正积极的方面是，我们的第一线/二线支持人员几乎只使用Windows，可以在半夜访问一个很好的web GUI来管理事物，并运行Jenkins作业，这些作业可以运行，可以重新启动服务器/服务，甚至重建VPC的一部分。

我们有一个独立的"dev“帐户，开发人员可以从他们自己的机器上访问它，在开发我们的Ansible (和Terraform)代码库之前，在测试和生产环境中使用该代码库之前，我们就是在这里构建代码库的。

Answer 2

我们在本地经营一切。

+

• 我们测试所有的游戏书籍(和我们的软件)在一个本地Vagrant，因此，我们需要它在本地无论如何。
• 我们不需要额外的机器。你也应该用Ansible来配置它们，所以至少有人需要安装Ansible。否则你就有鸡对蛋的问题了。
• 可能稍微快一点，因为你的网络跳数少了一个。

减

• 每个人都需要本地的Ansible安装，它只能在Linux和Mac上工作，而不是在Windows上工作(只能是目标)。

其他考虑事项

• 对于我们的Windows用户，Linux / Mac用户创建一个带有Ansible (所有设置)的VM，并将其导出为一个基本框。然后Windows用户可以在Vagrant中导入这个基本框，只需要启动它--所有的东西都已经安装好了。这包括Ansible，这样您就可以从VM中运行所有的东西。
• 最初，我们计划在NAT实例(针对私有VPC子网)上放置Ansible。但是，我们需要一个配置来设置VPC、安全组和NAT实例，另一个配置用于在NAT实例上运行并设置其余的基础设施。然而，我们没有看到任何真正的好处，所以我们现在拥有本地的一切。

PS:不确定是否有明确的答案，但这些是我们的论点。