使用Ansible自动配置AWS自动缩放组实例

Question

我使用Amazon Web Services在Elastic Load Balancer后面创建一个自动缩放的应用程序实例组。我使用CloudFormation模板创建自动扩展组+负载均衡器，并且一直使用Ansible配置其他实例。

我无法解决如何设计事物的问题，以便在新的自动调节实例出现时，它们可以由Ansible自动配置（也就是说，我无需查找新实例＆＃39; s主机名并为它运行Ansible）。我已经查看了Ansible的ansible-pull功能，但我不太清楚我是否理解如何使用它。它需要一个中央git存储库，它可以处理，但你如何处理你不想提交的敏感信息？

此外，我使用Ansible与AWS的当前方式是使用CloudFormation模板创建堆栈，然后我将主机名作为堆栈的输出，然后为Ansible生成要使用的主机文件。这不是很正确 - 是否有最佳实践＆＃34;对此？

Answer 1

是的，另一种方法是在实例启动后在本地运行您的Playbook。例如，您可以在rc.local文件（Linux）调用ansible-playbook -i <inventory-only-with-localhost-file> <your-playbook>.yml中为您的部署创建EC2 AMI。 rc.local几乎是启动时运行的最后一个脚本。

您可以将这些敏感信息存储在您的EC2 AMI中，但这是一个非常广泛的主题，实际上取决于它是什么类型的敏感信息。 （您还可以使用私有git存储库来存储敏感数据）。

例如，如果您的剧本定期更新，您可以在AMI中创建一个经常运行的cron条目，并实际运行您的剧本以确保您的实例配置始终是最新的。因此避免从远程工作站“推”。

这只是一种可能有很多其他方法的方法，它取决于您运行的服务类型，使用的数据类型等。

Answer 2

我认为您不应该使用Ansible配置新的自动缩放实例。而是使用Ansible配置新映像，您将在其中创建AMI（亚马逊机器映像），并命令AWS自动缩放从此启动。

除此之外，您还应该使用Ansible在您更改Playbook时轻松更新现有的运行实例。

Answer 3

替代

有几种方法可以做到这一点。首先，我想介绍一些替代方法。

一种选择是使用Ansible Tower。这会产生依赖关系：您的Ansible Tower服务器需要在自动缩放或类似情况发生时运行。

另一个选择是使用类似packer.io的东西并构建功能完备的服务器AMI。您可以使用Ansible将所有代码安装到这些代码中。这没有任何非AWS依赖关系，并且具有服务器快速启动的优势。一般来说，构建AMI是自动缩放的推荐方法。

S3存储桶中的Ansible配置

替代路线有点复杂，但在运行大型网站（数百万用户）时效果很好。它是“无服务器”，仅依赖于AWS​​服务。它还支持多个可用区，并且不依赖于运行任何中央服务器。

我整理了一个GitHub repo，其中包含一个完整的Cloudformation示例。我还把a presentation for the London Ansible meetup放在一起。

总的来说，它的工作原理如下：

1. 创建S3存储桶，用于存储引导服务器所需的部分。
2. 将您的Ansible剧本和角色等保存在其中一个S3存储桶中。
3. 让您的Autoscaling流程运行一个小型shell脚本。此脚本从S3存储桶中提取内容并使用它来“引导”Ansible。
4. Ansible然后做其他一切。
5. 所有机密值（如数据库密码）都存储在CloudFormation参数值中。 'bootstrap'shell脚本将这些副本复制到Ansible事实文件中。

因此，您不依赖于外部服务，您还需要在S3存储桶中保存任何构建依赖项（例如：任何.deb文件，软件包安装文件或类似文件）。您希望这样，因为您不希望要求ansible.com或类似程序启动并运行您的Autoscale引导脚本才能运行。一般来说，我试图只依赖于像S3这样的亚马逊服务。

在我们的案例中，我们还使用AWS CodeDeploy实际安装Rails应用程序。

与上述相关的配置的关键位是：

1. S3 Bucket Creation
2. Script that copies things to S3
3. Script to copy Bootstrap Ansible。这是该过程的核心。这也会根据CloudFormation参数写入Ansible事实文件。
模板中的
4. Use the Facts。