我的公司已决定过渡到基于微/服务的架构。
在过去的几个月里，我们一直在研究这件事的架构究竟是什么样子。
到目前为止，我们已经确定了：
用于服务开发的Dotnet核心（尽管与语言无关是一个最终目标）
Kafka的消息代理
泊坞
Kubernetes
Ansible
我们有一个非常基本的概念证明工作，似乎已经与管理团队勾选了所有正确的方框，并且是一个非常高兴的工作。
我的下一个任务是研究开发工作流程实际工作方式的选项。他们已经习惯于以CI / CD方式工作，他们的一些新产品使用Jenkins / Octopus Deploy。
我的问题是：在部署到Kubernetes集群时，您是否有任何关于设置CI / CD管道的明确建议？
必备品清单是：
多种环境，即集成，测试，UAT，分期，生产。
不同业务部门可以通过这种方式唯一地处理不同环境的部署（开发只能推动集成，测试人员进入测试等）。这可能是他们最大的问题 - 他们习惯于与八达通合作，他们喜欢它处理这个问题的方式。
单击按钮（或尽可能少的步骤）回滚/部署的能力。
我们最初会部署到我们自己的服务器上。
过去几天我一直在寻找各种选择，其中有很多选择。
到目前为止，Jenkins Pipeline看起来似乎是一个很好的开始。 Spinnakar似乎也是一个不错的选择。我确实读了一下Fabric8，虽然它提供了我所要求的大部分内容，但它看起来有点像矫枉过正。
答案 0 :(得分：2)
如果你想使用Jenkins，管道确实是要走的路。我们的设置完全符合您的要求，所以让我解释一下我们如何设置它。
我们使用安装了docker和kubectl的Jenkins代理。此代理首先构建docker容器并将其推送到docker注册表。然后，它将在不同阶段调用kubectl以部署到我们的测试，验收和生产集群。
不同业务单位：您可以使用an input step询问管道是否应该继续。您可以指定谁可以按下按钮，这样就可以解决部署到不同群集的问题。 （理想情况下，当您使用CD时，人们会意识到每天多次按下按钮是愚蠢的，他们只会自动完成整个部署。）
回滚：我们依靠Kubernetes的回滚系统。
凭据：我们使用Ansible直接向此Jenkins代理提供不同的Kubernetes凭据。
为了减少代码重复，我们引入了共享Jenkins Pipeline library，因此每个（微）服务都以标准化方式与所有Kubernetes集群进行通信。
请注意，我们使用普通的Jenkins，Docker和Kubernetes。可能有大量的软件可以进一步简化这一过程，所以让我们开放其他答案。
答案 1 :(得分：1)
我们正在开发一个名为Jenkins X的开源项目，该项目是Jenkins基金会的一个拟议子项目，旨在使用Jenkins管道和GitOps在Kubernetes上自动化CI / CD以促进跨环境的推广。
如果您想了解如何使用GitOps在Kubernetes上使用多个环境自动执行CI / CD以在环境和Pull请求上的预览环境之间进行促销，您可能需要查看my recent talk on Jenkins X at DevOxx UK我在哪里进行现场演示GKE。