我对整个 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 是否适用于许多相互依赖的小型应用程序？
答案1
在尝试改进我们手动部署的 AWS 实例时，我除了评估其他 AWS 产品外，还评估了 Elastic Beanstalk。我选择不使用它的原因是由于迁移现有应用程序会产生复杂问题，而不是产品本身的问题。问题在于，你无法控制应用程序部署/服务器配置。如果你正在启动一个新应用程序，那么现在不处理这些事情可能会有所帮助，如果你有一个现有应用程序，那么适应 Beanstalk 模型将更具挑战性。
Beanstalk 提供的产品与 Heroku 和其他 PaaS 供应商类似，但对那些只想专注于开发应用程序的人来说，好处不大。与其他 PaaS 供应商相比，您至少可以更大程度地确定虚拟化资源。
我在应用程序中遇到的问题：
基于 Git 的部署 - 我很喜欢，但我们的仓库有 1+ GB。对于定期推送来说，这太大了。这个仓库还包含大约 40 个应用程序（确实应该拆分），但这需要一些时间。上传任何类型的包都可以，但我们的大多数应用程序需要大量工作才能打包成包。
与其他服务集成 - 据我所知，Beanstalk 假设您连接的任何东西都是单一服务。如果您的服务位于 ELB 后面，但通过在每个应用程序服务器上运行的 HAProxy 访问的节点不同，那么这种方法很有效。如果您将数据存储区和其他服务作为单一端点运行，那么应该没问题。
在我的评估中，我还包含了 OpsWorks 和 CloudFormation。OpsWorks 与现有自动化对这些应用程序的工作方式存在类似的集成问题。CloudFormation 所做的工作并不比一些 Python 脚本和 Chef 已经为我们处理的工作多。
我最终选择使用 AWS Autoscaling Groups，并使用阿斯加德。这是对现有配置/应用程序代码的最小更改，并为我们提供了所寻求的好处，即通过 AWS API 轻松管理多个服务器。
Elastic Beanstalk 对您的应用程序施加的限制非常有用。您必须确保您的应用程序基本无状态，为服务提供端点，并依赖其他服务来获取状态。如果您尝试创建可重复使用的独立服务，那么 Beanstalk 中的多个应用程序是一个很好的开始。
如果/当您想要更多配置时，OpsWorks 是下一步的好选择。预定义的角色应该使转换变得容易，并且它提供了一个围绕 Chef 的自动化框架来帮助协调多个服务器的配置。
答案2
我确实看到了失去控制的意义，但我不一定看到了强制的无状态性。eb 真正做的就是部署自动化，顺便说一句，这很棒。我确实看到了大型存储库的意义。我认为，总的来说，将逻辑应用程序功能分离到单独的 bean 应用程序中，然后在下面设置“staging”和“prod”环境，这真的很不错。我们有像 uploader 这样的模块环境，它做不了什么，理论上它会增加很多成本，但你使用的只是更小的实例。我们运行一个集中式 nginx，不得不编写大量自定义 sns 消息句柄来通知 ngnix 自动缩放策略的变化。eb 的另一个大问题是无法关闭负载平衡，因为我们使用 ngnix，为什么？elb 不支持 websocket。