【问题标题】:Deploying to several environments on Amazon Elastic Beanstalk at the same time同时部署到 Amazon Elastic Beanstalk 上的多个环境
【发布时间】:2016-12-26 23:09:05
【问题描述】:

我有一个应用程序,它有多个环境(都在 Amazon Elastic Beanstalk 中运行),即生产环境、工作环境和调试环境。每个环境都有对应的 git 分支,在某些方面与 master 不同(例如,更改了配置,删除了一些代码)。

我使用eb deploy 从其分支部署新版本的应用程序。它使用git zip 压缩当前的 git 分支并将信息发送到亚马逊。然后它会部署到正在运行的实例。

但是,问题在于部署需要一些时间(大约 5 分钟)。因此,在部署工人和生产之间,它有不同的代码。这很糟糕,因为我的更改可能会更改队列协议或类似的东西。

我想要的是能够上传信息并在所有环境中进行处理,但实际上并没有替换代码,只是准备它。在我为所有环境执行此操作后,发出“完成部署”之类的命令,以便同时在所有环境中替换代码库。

有办法吗?

【问题讨论】:

    标签: amazon-web-services deployment amazon-elastic-beanstalk web-deployment


    【解决方案1】:

    您需要执行“蓝绿”部署,而不是就地执行此操作。因为您的部署模型需要同步多个部分,所以更改这些部分使用的协议意味着必须同时部署这些部分。如果存在强烈绑定设计的频繁中断协议,则将其视为单个服务。

    “已部署”意味着系统的最外层被其他系统公开和使用。在这种情况下,听起来您有一个向其他系统公开 API 的 Web 服务器层,以及一个读取 Web 层生成的消息的工作层。

    在进行中断队列协议更改时,您应该将两个更改集(Web 服务器层和队列层)部署到全新的 beanstalk 环境,将它们配置为相互使用,然后在暴露的端点上进行 DNS 交换,从旧的网络服务器 EB 环境到新的环境。在网络服务器层交换 DNS 并验证环境按预期工作后,您可以销毁旧的网络服务器和队列层。

    在不破坏协议的更新中,您可以简单地更新一个环境或另一个环境。

    这听起来很复杂,因为它是。如果您经常破坏协议,那么您的系统就没有足够的解耦来期望对工作层和网络服务器层进行版本控制,这就是为什么您必须执行这个复杂的过程来将它们一起版本化。

    希望这会有所帮助!

    【讨论】:

      猜你喜欢
      • 2015-10-23
      • 2018-06-01
      • 2016-04-20
      • 1970-01-01
      • 2013-06-14
      • 2015-07-05
      • 2016-07-18
      • 1970-01-01
      • 2013-03-05
      相关资源
      最近更新 更多