今天聊一聊Beanstalk的部署策略有哪些。
不过在聊部署策略前，我们先聊一下Beanstalk本身和环境。
Beanstalk是AWS一个很强大的工具， 它覆盖了从最底层的infrastructure部署，到最上层的Appliacation的版本更新。可以说，如果你在考虑Replatform的话，使用Beanstalk是很好的一个选择。
Beanstalk本身是免费的，仅在使用的资源时候收取资源的费用。
再说环境，一般环境部署的时候，我们可以分为个人的开发或者测试环境，产品真正的production环境，以及可能是小型的单一worker的环境。
针对不同的环境，就有会不同的需求。有些要求快，有些要求服务不能中断，有些要求省钱……我常说，所有的方案都是为了需求服务的，因此我们研究一下这些需求，来看Beanstalk对应的解决方案。
第一个，什么都没有，我们从头来部署。恩……这种用什么“方案”都无所谓的，从无到有。
从下面开始，我们仅考虑已经有环境的情况，也就是所谓的再部署或者升级。
需求A：我自己的自测环境，要部署最新的软件。
在这种情况下，你关心的是“快”还是“服务不中断”？既然是我自测的环境，我更希望他部署快速。
因此，使用Beanstalk的all-in-one部署方式是最佳的选择。
Beanstalk的all-in-one部署方式是将新软件在每一个现有的资源上面一起更新。同时开始，也就表示整个过程的最长时间也就是花费最长时间的单个资源所用的时间。
需求B：Production环境，还在提供着服务，要部署最新的软件。
哎？这样的环境往往更关心“服务不中断”。但也可能会收到类似于“尽量不中断，但是必须在某某时间内完成”这样的需求。
那上边说过的all-in-one的部署方式肯定是不适合了。与其大家一起更新，那换成一个一个更新会不会好？
一个接一个更新的方法，叫做rolling。一个接一个，跟在地上“翻跟头”似的。
有些同学可能会问了，一个一个更新，那服务也会断啊，比如我提供服务的EC2升级了，没人提供服务了啊。
你这个问题，很明显是环境设计上有瓶颈。拿EC2来举例，哪个production环境没在用ASG？如果用了ASG，在你给一个EC2升级的时候，是不是另外的EC2还在提供着服务？
所以我们可以说，rolling的方法，会“最小化”中断（因为有瓶颈的情况下还是有可能），时间嘛，肯定是所有需要更新的资源升级时间的总和了。
有没有办法把这“最小化的中断可能“变成“不可能”？有哇。
你想想，之所以还是会中断，是因为你在升级的时候，是在”已经创建的资源“上面升级。这个资源若只有一台，那肯定会断。
如果我们创建一台新的呢？升级好了再替换回来，是不是就解决了升级过程中“中断”的问题了呢？
是滴。
这种方法，叫rolling with additional batch。
从这个方案起，你开始考虑加入新机器了，花费也就开始变高了。
于是我们继续想，那有没有可能，我们把这套环境整个重新创建了得了。
有！这种方法叫做immutable。原来环境留着，我们新来一套。
之后不论是用blue-green，还是测试好了直接切到新环境。逻辑上和旧环境隔离得特别彻底。
关键看你的需求。
看，又回来了！
参考文章《Deploying applications to Elastic Beanstalk environments》
