我有3个环境，每个环境在各自的虚拟网络上都有各自的配置。如果要在每个环境上进行持续部署，是否需要3个单独的Jenkins实例？重新部署在多环境体系结构上的最佳实践有哪些？

#1 楼

这是一个非常好的问题，因为它是将ci/cd工具与环境结合使用的常见反模式。

Jenkins是一个构建工厂。因此，它应该完全与环境，甚至交付的概念无关。交付软件）。

登台过程

您应该尝试为每个环境创建某种登台作业，在其中定义环境的配置并将其捆绑最终的包装。

接下来，您将为每个环境提供交货作业。

交货工具

为了创建暂存和交付作业，您可以使用非常基本的脚本工具，例如shell，但是还有更多适应性强的脚本工具，例如Ansible，puppet，chef ...在部署软件中（我将在评论部分中提及一些我所使用的软件）。

请注意，这些软件管理某种环境暂存过程。

Obv遗憾的是，将部署软件和脚本结合起来很有意义。值得一提的是另一个常见的反模式：将SCM工具和交付过程结合在一起。工具（例如svn或git ...）。但是，在上线过程中检出环境配置并上线脚本是非常不好的做法。

此结帐阶段应该是我之前提到的登台过程的一部分。 br />另一个最佳实践是您的脚本应该是idem-potent：这意味着您应该能够播放一次脚本以执行登台和交付。然后，您应该能够一次又一次地播放它们，除非配置出现问题，否则它们不会改变系统状态。

扩展

作为最后的最佳选择实践中，我将从直接经验中分享的是缩放詹金斯：不同的团队对詹金斯有不同的需求和用途。当太多团队共享同一个詹金斯兄弟时，可能会出现资源问题。最糟糕的情况是，当一个团队需要重新启动Jenkins主服务器，而另一个需要交付时。

理想的情况是每个团队或每组团队拥有一个目标和交付计划相同的Jenkins 。

#2 楼

我刚刚从拥有Jenkins自由式作业和为每个环境单独工作过渡到使用Jenkins管道（声明性语法）。

在Jenkins管道中，我们只有一个文件（Jenkinsfile）并定义了不同的文件不同环境（开发/阶段/生产）的各个阶段，在这些阶段中，我们仅为每种环境定义了不同的行为。例如，在我们的“部署”阶段，我们将根据开发环境或暂存环境将其部署到其他kubernetes命名空间/集群。在所有分支机构上。

评论

那么，如何使它部署特定的环境？还是始终将它们全部部署在一起？

–lkraider
19年11月11日在17:20
@lkraider我们执行此操作的方法是在git和脚本化的Jenkins Pipeline中使用良好的分支策略。例如，您可以将所有开发分支转到开发环境，而将所有主分支或任何其他分支转到阶段或产品。然后，在您的Jenkinsfile中，可以在管道阶段使用“ If”语句，例如“ if（env.BRANCH_NAME =='develop'）”或“ if（env.BRANCH_NAME =='master'）”。看看jenkins.io/doc/tutorials/build-a-multibranch-pipeline-project

–玩具
20 Mar 3 '20 at 16:21

#3 楼

您问题的简短答案是“否”。詹金斯（Jenkins）无需与您的生产环境进行交流，但如果需要，可以进行交流。换句话说，如果詹金斯（Jenkins）可以到达这些环境，则很可能会与它们进行交互。品牌，Ansible，地形，云形成或Kubernetes）。

管道能够处理并行目标，这意味着您可以选择同时构建并部署到所有三个环境。

您可能希望使问题更精确或更详细，以获得更多反馈。

#4 楼

我们可以将Jenkinsfile用于不同的环境。但是我们需要一些东西来区分这种环境，可以是环境变量，也可以是参数化作业中的参数，以控制我们在每种环境中需要执行的操作。也许我们想要在一个环境中进行构建，测试，执行端到端并将映像推送到存储库中。然后使用相同的映像并在下一个部署（可能是分阶段）并执行烟雾测试。然后使用相同的映像部署到生产中。