与其他部署策略相比，AWS Elastic Beanstalk的优缺点是什么？

一般而言，我对整个Netflix OSS堆栈和部署还很​​陌生。作为我当前所学知识水平的背景，我的主要角色是担任前端应用工程师。但是，我很喜欢操作方面的内容，因此我试图为新项目设置新的部署策略和工具。

我们的目标

• 超级轻松的部署（我们想按一下按钮以更新生产）
• 自动化部署到测试环境（使用Jenkins）
• 易于维护（我们有一个要编写的应用程序，不想花时间摆弄生产问题）
• 能够处理面向服务的体系结构（许多小型应用，各种语言和数据存储）
• 足够的灵活性以确保我们很快就不必更改策略（我们已经在努力摆脱RightScale）

如果可以省下一些麻烦，我们可以增加一些初始设置时间。

因此，按照这些思路，我一直在听播客，观看Ops演讲，阅读大量博客文章，并根据我们的目标以及我认为是最佳实践的想法，我们开始使用Asgard，将我们的包装放入罐子，然后放入AMI。

我们已经计划了所有这一切，并且喜欢该流程与使用Chef服务器和即时聚合实例相比的优势（由于时间表有限且对Chef服务器工作流程缺乏理解，我们认为这很容易出错）。但是，一位同事自己环顾四周，觉得Elastic Beanstalk满足了我们的需求。

我研究了它，并使用WAR文件和附加的RDS数据库启动了一个测试环境。似乎一切正常，我相信我们可以通过AWS API使用Jenkins将部署自动化到测试环境。似乎很简单...也许太简单了。

我想知道的是，有什么收获？如果Elastic Beanstalk如此简单和有效，为什么不谈论更多呢？对于两种不同的部署策略，我很难找到足够的客观见解和事实，因此我想四处询问。

您是否使用Elastic Beanstalk？如果是这样，为什么和什么因素导致了这一决定？你喜欢什么和不喜欢什么？

如果您不使用而是考虑使用Elastic Beanstalk，则使用什么，为什么不使用Elastic Beanstalk？

SOA的基于Elastic Beanstalk的部署策略的优缺点是什么？也就是说，Elastic Beanstalk是否可以与许多相互依赖的小型应用程序很好地工作？

我在尝试改善手动滚动AWS实例的同时，还评估了Elastic Beanstalk和其他AWS产品。我之所以选择不使用它，是因为复杂性会导致迁移现有应用程序而不是产品本身。问题是您对服务器的应用程序部署/配置没有太多的控制权。如果您正在启动一个新应用程序，那么现在不处理这些事情可能会有所帮助，如果您有一个现有的应用程序，那么要适合Beanstalk模型将是一个更大的挑战。

Beanstalk提供了与Heroku和其他PaaS供应商类似的产品，但对于那些只想专注于自己的应用程序的用户而言，并没有太大的好处。您至少要比其他PaaS供应商更大程度地确定虚拟化资源。

我的应用程序遇到的问题：

• 基于Git的部署-我喜欢它们，但我们的存储库为1+ GB。较大，可以定期推送。此仓库还包含大约40个应用程序（应将其拆分），但这需要一些时间。上载任何类型的程序包都可以，但是我们的大多数应用程序都需要大量工作才能将其装入程序包。

• 与其他服务的集成-从我所看到的Beanstalk看来，您假设要连接的任何东西都是单一服务。如果您的服务落后于ELB，但如果我们是通过运行在每个应用程序服务器上的HAProxy访问的单独节点，则此方法很好用。如果您将数据存储和其他服务作为单个端点运行，则应该没问题。

在评估中，我还包括OpsWorks和CloudFormation。OpsWorks在现有自动化如何为这些应用程序工作方面也存在类似的集成问题。CloudFormation所做的不过是一些Python脚本和Chef已经为我们提供的服务而已。

我最终选择使用AWS Autoscaling Group来代替Asgard提供的一些自动化。这是对现有配置/应用程序代码的最小更改，并为我们提供了我们一直在寻找的好处，即可以通过AWS API轻松管理多个服务器。

Elastic Beanstalk在您的应用程序上施加的限制非常有用。您将必须确保您的应用程序大部分是无状态的，为服务提供端点，并依赖于其他服务来提供状态。如果您试图提供可重用的独立服务，那么Beanstalk中的多个应用程序就是一个很好的开始。

如果/当您到达要进行更多配置的地步时，OpsWorks是一个不错的下一步。预定义的角色应该使过渡很容易开始，并且它提供了一个围绕Chef的自动化框架，以帮助协调多个服务器的供应。

我确实看到了失去控制的要点，但是我并不一定看到强制性的无国籍状态。eb真正要做的只是部署自动化，这真是太棒了。我确实看到大型存储库的意义。我认为通常来说，将逻辑应用程序功能分离到单独的Bean应用程序中，然后在其下具有“暂存”和“产品”环境真的很好。我们有类似上载器的模块环境，它执行的不是很多，并且从理论上讲，它会增加很多成本，但是您使用的是更小的实例，而是其中的更多。我们运行集中化的nginx，并且必须编写大量自定义的sns消息句柄以将自动缩放策略的更改通知给ngnix。eb的另一个大问题是，由于我们使用ngnix，因此无法平衡负载平衡，为什么？elb不支持websocket。