使用Ansible进行持续部署和AWS自动扩展（+ Docker？）
我的组织的网站是一个运行在AWS前端Web服务器+一些后台处理服务器上的Django应用程序。
我们目前正在使用Ansible：
- 系统configuration（从裸露的OS映像）
- 频繁的手动触发代码部署。
相同的Ansible操作手册能够从头开始configuration本地Vagrant dev VM或生产EC2实例。
我们现在要在EC2中实现自动缩放，这就需要一些“把服务器当作牛，而不是宠物”的理念。
第一个先决条件是从一个静态pipe理的Ansible库存移动到一个dynamic的，基于EC2 API的库。
接下来的一个大问题是如何在这个新的世界里，在一夜暴富的情况下来回摆动。 我能想到的选项是：
- 为每个部署创build一个新的完全部署的AMI ，创build一个新的AS启动configuration并用此更新AS组。 听起来非常非常繁琐，但也是非常可靠的，因为清洁的石板方法，并将确保任何系统更改代码所需的将在这里。 而且，在实例启动时不需要额外的步骤，所以启动和运行更快。
- 使用不经常更改的基本AMI ，在启动时自动从git获取最新的应用程序代码，启动web服务器。 一旦启动，只需按照需要手动部署，就像以前一样。 但是如果新代码依赖于系统configuration（新包，权限等）的更改呢？ 看起来你必须开始考虑代码版本和系统/ AMI版本之间的依赖关系，而“只是做一个完全可靠的运行”的方法更集成，更可靠。 这不仅仅是在实践中潜在的头痛吗？
- 使用Docker？ 我有一个强大的预感，它可以是有用的，但我不知道它是如何适合我们的图片。 我们是一个相对独立的Django前端应用程序，只有RabbitMQ + memcache作为服务，我们永远不会在同一个主机上运行。 那么使用包含系统包+最新代码的Ansible构buildDocker镜像有什么好处，而不是让Ansible直接在EC2实例上执行？
你怎么做呢 ？ 任何见解/最佳实践？ 谢谢 ！
这个问题是非常意见的基础。 但是为了给我提供一些帮助，我只需要用Ansible预先打包AMI，然后使用CloudFormation通过Autoscaling，Monitoring和预先烘焙的AMI来部署堆栈。 这样做的好处是，如果您将大部分应用程序堆栈预先插入AMI，则自动调整UP会发生得更快。
Docker是另一种方法，但是在我看来，如果您已经在使用EC2，那么在您的应用程序中会增加一个额外的层，您可能不需要这个层。 如果您说要在一台服务器中进行容器化，Docker可能会非常有用。 也许你在服务器上有一些额外的容量，Docker将允许你在同一台服务器上运行这个额外的应用程序，而不会干扰现有的应用程序。
话虽如此，有些人发现Docker并不是以某种方式来优化单个服务器中的资源，而是以某种方式允许您将应用程序预先烧成容器。 因此，当您部署新版本或新代码时，您只需在服务器上复制/复制这些docker容器，然后停止旧的容器版本并启动新的容器版本。
我的两分钱
混合解决scheme可能会给你想要的结果。 在S3中存储头部docker图像，在开始时用简单的获取并运行脚本预先烘焙AMI（或者将其传递到具有用户数据的股票AMI中）。 通过将头部图像移动到最新的稳定版本进行版本控制，您可能还可以实现新版本的testing堆栈，方法是使抓取脚本足够智能，以根据可在实例启动时configuration的实例标签来识别要抓取哪个docker版本。
您还可以将AWS CodeDeploy用于AutoScaling和构build服务器。 我们使用Jenkins的CodeDeploy插件。
这个设置允许你：
- 在jenkins执行你的构build
- 上传到S3存储桶
- 部署到属于已分配的AWS Auto-Scaling组的一部分的所有EC2。
所有这一切按一个button！
以下是AWS教程： 使用AWS CodeDeploy将应用程序部署到Auto Scaling组