continuous-integration - Kubernetes CI/CD 流水线

Question

我的公司已决定过渡到基于微/服务的架构。

在过去的几个月里，我们一直在做大量的研究，以了解这个东西的架构究竟会是什么样子。

到目前为止，我们已经确定:

• 用于服务开发的 Dotnet 核心(尽管与语言无关在某种程度上是最终目标)

• 用于消息代理的 Kafka

• docker

• Kubernetes

• Ansible

我们有一个非常基本的概念验证工作，这似乎与管理团队打勾了所有正确的方框，与之合作绝对是一种乐趣。

我的下一个任务是研究开发工作流程实际如何运作的选项。他们已经习惯于以 CI/CD 方式工作，他们的一些新产品使用 Jenkins/Octopus Deploy。

我的问题是:对于在部署到 Kubernetes 集群时设置 CI/CD 管道，你们有任何坚定的建议吗？

必须具备的 list 是:

• 多个环境，即集成、测试、UAT、暂存、生产。

• 一种方式，不同的业务部门可以通过这种方式独特地处理不同环境的部署(开发只能插入集成，测试人员只能插入测试，等等)。这可能是他们最大的问题 - 他们习惯于使用 Octopus，并且喜欢它的处理方式。

• 单击按钮(或尽可能少的步骤)即可回滚/部署的能力。

我们最初会部署到我们自己的服务器。

过去几天我一直在研究各种选择，其中有很多。

到目前为止，Jenkins Pipeline 似乎是一个很好的开始。 Spinnakar 似乎也是一个不错的选择。我确实读了一点 Fabric8，虽然它提供了我要问的大部分内容，但似乎有点矫枉过正。

Answer 1

如果您想使用 Jenkins，Pipelines 确实是您的不二之选。我们的设置几乎可以满足您的需求，所以让我解释一下我们是如何设置的。

我们使用安装了 docker 和 kubectl 的 Jenkins 代理。该代理首先构建 docker 容器并将其推送到我们的 docker 注册表。然后它将在各个阶段调用 kubectl 以部署到我们的测试、验收和生产集群。

不同的业务部门:在管道中您可以使用an input step询问管道是否应该继续。您可以指定谁可以按下按钮，这样您就可以解决部署到不同集群的问题。 (理想情况下，当您使用 CD 时，人们会意识到每天按几次按钮是愚蠢的，他们只会自动执行整个部署。)

回滚:我们依赖 Kubernetes 的回滚系统。

凭据:我们使用 Ansible 直接向此 Jenkins 代理提供不同的 Kubernetes 凭据。

为了减少代码重复，我们引入了一个共享的 Jenkins Pipeline library ，因此每个(微)服务都以标准化方式与所有 Kubernetes 集群通信。

请注意，我们使用普通的 Jenkins、Docker 和 Kubernetes。可能有大量软件可以进一步简化此过程，所以让我们留待其他答案。