7

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

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

4

2 回答 2

4

我们在本地运行一切。

加

  • 我们在本地 Vagrant 盒子中测试所有剧本（和我们的软件），因此无论如何我们都需要它。
  • 我们不需要额外的机器。你也应该用 Ansible 配置它们，所以至少有人需要安装 Ansible。否则你有鸡与蛋的问题。
  • 可能会稍微快一点，因为你的网络跳数少了。

减

  • 每个人都需要一个本地 Ansible 安装，它只能在 Linux 和 Mac 上运行，而不能在 Windows 上运行（只能是目标）。

其他注意事项

  • 对于我们的 Windows 用户，Linux / Mac 用户使用 Ansible（一切设置）创建一个 VM，并将其导出为基本框。然后 Windows 用户可以在 Vagrant 中导入该基本框，并且只需要启动它 - 一切都已安装。这包括 Ansible，因此您可以从 VM 运行所有内容。
  • 起初，我们计划将 Ansible 放在我们的 NAT 实例上（用于私有 VPC 子网）。但是我们需要一种配置来设置 VPC、安全组和 NAT 实例，另一种配置在 NAT 实例上运行并设置其余的基础设施。但是，我们看不到任何真正的好处，所以我们现在在本地拥有一切。

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

于 2015-09-20T23:35:19.203 回答
4

与xeraa的好答案相反，我们尽可能从 AWS 内部运行。

我们从中获得的真正好处是，它允许我们使用运行Ansible的集中式Jenkins服务器（在我们的案例中，Terraform用于实际的 AWS 预置，而 Ansible 仅用于配置 EC2 实例并为管理任务运行临时剧本）。

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

这样做意味着我们可以控制拥有某种形式的凭证的人数，这些凭证允许他们建造他们喜欢的任何东西和/或摧毁他们喜欢的任何东西。

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

一个真正的积极因素是，我们几乎完全使用 Windows 的一线/二线支持人员可以在半夜访问一个不错的 Web GUI 来管理事物并运行他们专门有权运行的 Jenkins 作业，这将做一些事情，比如重新启动服务器/服务，甚至重建 VPC 的一部分。

我们有一个单独的“开发”帐户，开发人员可以从他们自己的机器上访问它，我们在这里构建我们的 Ansible（和 Terraform）代码库，然后将该代码库用于我们的测试和生产环境。

于 2015-09-23T19:03:05.860 回答