Elastic Beanstalk是否适合企业级持续交付？

76次阅读

问题描述

正在使用Jenkins构建和部署微服务到Elastic Beanstalk。他们将集成分支部署到测试环境，发布分支部署到预发布环境，然后将最终的主分支构建部署到生产环境。用户对当前的部署方式有一些担忧：首先，这意味着每个项目每个环境都需要构建一次，造成了工作的重复；其次，这意味着我们在生产环境中部署的构建产物与在预发布环境中验证的构建产物不一致。

用户倾向于放弃使用Beanstalk，转而使用纯粹的ASG（Auto Scaling Group），并使用类似Chef的工具进行部署。这样我们就只需要为每个项目构建一次，生成一个构建产物，并且可以在生产环境中部署与在预发布环境中验证的相同构建产物。然而，转换过程需要一定的前期成本。是否有一种更好的使用Beanstalk的方式，可以实现更可靠、更易管理的持续集成/持续交付（CI/CD）？

注意：我确实想要实现的是使用相同的构建产物进行部署，但从文档中我没有看到明确的方法来实现这一点；文档解释了如何从应用程序源代码部署到EB，但没有解释如何将现有版本推广到另一个环境，除非我刚好漏掉了。如果EB本身支持这个功能，那么Jenkins的EB部署插件可能存在限制，阻止了在Jenkins中执行此操作的方法，但我还没有找到任何方法来实现这一点。

解决方案

请注意以下操作注意版本差异及修改前做好备份。

方案1

在这种情况下，问题并不在于Elastic Beanstalk，而是在于Jenkins，或者至少是你使用Jenkins的方式。你应该专注于只构建“一个东西”，而不管那个东西是什么。

以下是一个解决方案的示例，使用GoCD作为持续交付工具，但其他工具也可以类似实现：

在你的流水线的早期阶段，构建“构建产物”。这可以是表示应用程序的全部或部分的二进制文件，也可以是来自测试工具等任何工具的输出。这些构建产物应该由系统进行存储，并且不应再次构建。系统在需要时应该从正确的版本中获取构建产物。
下一个流水线可以是部署到更复杂的测试环境。它应该从构建产物的确切版本中获取构建产物，并使用Elastic Beanstalk将该构建产物部署到正确的环境。
下一个流水线是预发布部署。它会回溯到第一个流水线，并从构建产物的确切版本中获取构建产物。然后使用Elastic Beanstalk将该构建产物部署到正确的环境。

这些是独立的流水线，因为这样可以并行运行更多的流水线或按需运行，而不会阻塞。

你可以使用Elastic Beanstalk、Chef、Puppet、Ansible、uDeploy或其他任何工具来执行实际的部署。这不是导致问题的地方。持续集成服务器最初并不是为此而构建的。当然，如果你喜欢，也可以使用许多插件来达到相同的目的。

持续交付服务器如GoCD、Chef Automate和ConcourseCI专门为解决这类问题而构建。

方案2

另一种方法是编写脚本或使用工具来控制容器的运行顺序。你可以使用docker run命令来手动控制容器的启动顺序，或者使用一些第三方工具来管理容器的依赖关系。

以下是一个简单的bash脚本示例，可以在容器A启动后启动容器B：

#!/bin/bash
# 启动容器A
docker run -d --name container_a your_image_a
# 等待容器A完全启动
while ! docker exec container_a echo "Container A is ready"; do
  sleep 1
done
# 启动容器B
docker run -d --name container_b your_image_b

在这个示例中，我们首先使用docker run命令启动容器A，并将其命名为container_a。然后，使用一个循环来等待容器A完全启动（这里是通过在容器内运行echo命令来测试）。一旦容器A就绪，我们再使用docker run命令启动容器B，并将其命名为container_b。

请注意，这种方法需要手动编写脚本，并确保容器A和容器B之间的依赖关系正确设置。