使用Ansible(+ Docker？)进行持续部署和AWS自动扩展

Question

我的组织的网站是在前端Web服务器上运行的Django应用程序+ AWS中的一些后台处理服务器.

我们目前正在使用Ansible:

• 系统配置(来自裸OS映像)
• 经常手动触发的代码部署.

同样的Ansible playbook能够从头开始配置本地Vagrant dev VM或生产EC2实例.

我们现在想要在EC2中实现自动缩放,这需要对"将服务器视为牛,而不是宠物"的理念进行一些更改.

第一个先决条件是从静态管理的Ansible库存转移到动态的,基于EC2 API的库存,完成.

接下来的一个重要问题是如何在这个新世界中进行部署,在这个世界中,一夜之间会出现一次性事件.我能想到的选择是:

1. 为每个部署烘焙新的完全部署的AMI,创建新的AS Launch配置并使用它更新AS组.听起来非常非常麻烦,但由于采用了清晰的平板方法,因此也非常可靠,并且将确保任何系统更改所需的代码都在这里.此外,实例启动时无需其他步骤,因此可以更快地启动和运行.
2. 使用不经常更改的基本AMI,在启动时自动从git获取最新的应用程序代码,启动webserver.一旦完成,只需按需要进行手动部署,就像之前一样.但是如果新代码依赖于系统配置的更改(新包,权限等)呢？看起来你必须开始处理代码版本和系统/ AMI版本之间的依赖关系,而"只做一个完整的ansible运行"方法更集成,更可靠.这不仅仅是实践中的潜在头痛吗？
3. 使用Docker？我有一个强烈的预感它可能有用,但我不确定它如何适合我们的图片.我们是一个相对独立的Django前端应用程序,只有RabbitMQ + memcache作为服务,我们永远不会在同一台主机上运行.那么使用包含系统包+最新代码的Ansible构建Docker镜像有什么好处,而不是让Ansible直接在EC2实例上进行？

你怎么做呢 ？任何见解/最佳实践？谢谢 !

Answer 1

这个问题非常基于意见.但是为了给你我的看法,我只想用Ansible预先安装AMI,然后使用CloudFormation通过Autoscaling,Monitoring和预先制作的AMI来部署你的堆栈.这样做的好处是,如果您将大部分应用程序堆栈预先烘焙到AMI中,则自动缩放UP将会更快.

Docker是另一种方法,但在我看来,它在您的应用程序中添加了一个额外的层,如果您已经在使用EC2,则可能不需要.如果您想在单个服务器中进行容器化,Docker可能非常有用.也许你在服务器上有一些额外的容量,而Docker将允许你在同一台服务器上运行那个额外的应用程序,而不会干扰现有的应用程序.

话虽如此,有些人发现Docker不是以某种方式优化单个服务器中的资源,而是以某种方式允许您在容器中预先烘焙应用程序.因此,当您部署新版本或新代码时,您只需要在服务器上复制/复制这些docker容器,然后停止旧容器版本并启动新容器版本.

我的两分钱.