0

我在 AWS 上运行 CoreOS 集群。在 AWS 中的每个实例上，我运行一个 docker 容器。例如，我有 2 个名为 API 的实例，它们使用我们最新的软件版本运行 docker 映像。

我还有 6 个处理器实例，它们运行另一个最新版本的 docker 映像。

我想更新集群中的每个容器，所以今天我使用带有管道的GoCD来激活一个可以完成所有工作的 ansible-playbook。管道监听 github 项目，一旦我将更改推送到该分支，它就会激活管道。

它构建 API 和处理器新的 docker 镜像，将新更新的镜像上传到 dockerhub，然后连接到 AWS 实例并为刚刚上传的镜像发出 docker pull，最终使用新拉取的镜像启动容器。

这是我目前控制我的版本部署的方式。

问题是：

  1. 需要很长时间
  2. 它有时会因各种原因而失败
  3. 它不灵活（我需要硬编码特定分支以在 github 上收听并从中提取文件）

你有任何其他建议\工具来完成这项工作吗？有时我需要更新 3 台机器，有时需要更新 7 台机器，我需要一些可以扩展的东西。

4

2 回答 2

1

我没有在我的环境中使用 git，但使用了启动 Jenkins 部署工作流程的提交后 SVN 挂钩。添加 Jenkins Build Pipeline 插件，这样您就可以从失败中恢复，而不是从头开始。也就是说，检查 GoCD 是否支持这种东西，如果不需要，切换工具是没有意义的。

我建议进行以下更改：

  1. 在部署工具中将 ansible playbook 分解为离散的步骤。这将允许您在更接近故障时重新启动，从而减少浪费的时间。

  2. 在您的管道中设置通知以通知您失败，并在最后通知您成功。没有必要照看进度条......这很快就会变得令人沮丧

  3. 开始量化流程中的瓶颈所在。你一步一步地修复一个缓慢的过程，首先确定最容易修复的事情。

于 2016-02-04T19:23:09.717 回答
0

从问题 #3 开始，您可能需要考虑是否要从各个分支发布代码。GoCD 作为一种持续交付工具，最适合基于主干的开发，即始终从 master 发布。

不过，您不想在每次推送到主干时直接部署到生产环境。您可以在 Go 中进行手动批准步骤，或者使用其他组件作为生产中运行的版本运行一组自动化测试，或者同时进行测试和手动批准。

关于问题 #2，您可能希望在 GoCD 中有更多步骤，以便您可以按照 Go Web UI 中的流程，获取有关失败的电子邮件通知，并从失败的点恢复等。

关于#1，你必须告诉我们什么是慢，以及你对时间有什么样的期望。GoCD 在入门方面并不快。我认为它每分钟轮询一次 GIT 存储库，空闲的代理会每隔一段时间检查服务器，看看是否有工作要做。不过，这基本上是一个固定的延迟。它不会因为您有 100 台主机要升级而变慢，除非您为每个实例制作一个 GoCD 作业（这可能不是一个好主意）。

听起来 docker compose 和 docker swarm 可能是您使用 Ansible 工作的更好工具。

于 2016-02-17T13:51:40.217 回答