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

Question

总的来说，我对整个 Netflix OSS 堆栈和部署还很​​陌生。作为我目前的运维知识水平的背景，我的主要角色是前端应用工程师。但是，我喜欢事物的运营方面，因此我正在尝试为新项目设置新的部署策略和工具。

我们的目标

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

我们可以多花一点初始设置时间，如果这样做会在将来为我们省去一些麻烦。

因此，沿着这些思路，我一直在听播客、观看 Ops 演讲并阅读大量博客文章，并根据我们的目标以及我所采取的一些最佳实践，我们已经开始制定计划，使用Asgard，将我们的包滚动到 jar 中，然后将其滚动到 AMI 中。

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

我已经研究过它并使用 WAR 文件和附加的 RDS 数据库启动了一个测试环境。事情似乎奏效了，我相信我们可以通过 AWS API 使用 Jenkins 自动部署到测试环境。看起来很简单……也许太简单了。

我想知道的是，有什么收获？如果 Elastic Beanstalk 如此简单有效，为什么没有更多地谈论它？我很难找到关于两种不同部署策略的足够客观的意见和事实，所以我想我会四处打听。

您使用 Elastic Beanstalk 吗？如果是这样，为什么以及哪些因素会导致该决定？你喜欢和不喜欢什么？

如果您不使用 Elastic Beanstalk 但考虑过它，您使用什么，为什么不使用 Elastic Beanstalk？

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

Answer 1

除了其他 AWS 产品外，我还评估了 Elastic Beanstalk，同时尝试改进我们的手动 AWS 实例。我选择不使用它的原因是由于迁移我现有的应用程序而不是产品本身会出现并发症。问题是您对服务器的应用程序部署/配置没有太多控制权。如果您正在启动一个新的应用程序，那么现在不处理这些事情可能会有所帮助，如果您有一个现有的应用程序，那么适应 Beanstalk 模型是一个更大的挑战。

Beanstalk 为 Heroku 和其他 PaaS 供应商提供了类似的产品，但对那些只想专注于制作应用程序的人来说并没有太大的好处。与其他 PaaS 供应商相比，您至少可以在更大程度上确定虚拟化资源。

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

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

• 与其他服务的集成——据我所知，Beanstalk 假设您连接的任何东西都是一个单一的服务。如果您的服务落后于 ELB 但我们是单独的节点，我们通过在每个应用程序服务器上运行的 HAProxy 命中这些节点，那么这很有效。如果您将数据存储和其他服务作为单个端点运行，则应该没问题。

在我的评估中，我还包括 OpsWorks 和 CloudFormation。OpsWorks 在现有自动化如何为这些应用程序工作方面存在类似的集成问题。CloudFormation 所做的只是一些 Python 脚本和 Chef 已经为我们处理的事情。

我最终选择使用 AWS Autoscaling Groups 而不是Asgard提供的一些自动化。这是对现有配置/应用程序代码的最小更改，并为我们提供了我们正在寻找的好处，通过 AWS API 对多个可用服务器进行简单管理。

Elastic Beanstalk 对您的应用程序设置的限制非常有用。您必须确保您的应用程序大部分是无状态的，为服务提供端点，并依赖其他服务来获取状态。如果您正在尝试制作可重用的独立服务，那么 Beanstalk 中的多个应用程序是一个很好的开始。

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