持续集成和部署的 3 个最佳实践

本文涵盖三个关键主题：自动化 CI/CD 配置、使用 Git 仓库存储通用 CI/CD 工件以及参数化 Jenkins 流水线。

术语

首先，让我们定义一些术语。 CI/CD 是一种实践，它允许团队快速且自动地测试、打包和部署他们的应用程序。这通常通过利用一个名为 Jenkins 的服务器来实现，该服务器充当 CI/CD 编排器。Jenkins 监听特定的输入（通常是代码签入后的 Git 钩子），并在被触发时启动流水线。

流水线 由开发和/或运维团队编写的代码组成，这些代码指示 Jenkins 在 CI/CD 过程中应采取的操作。这个流水线通常类似于“构建我的代码，然后测试我的代码，如果这些测试通过，则将我的应用程序部署到下一个最高环境（通常是开发、测试或生产环境）。” 组织通常有更复杂的流水线，其中包含诸如工件仓库和代码分析器之类的工具，但这提供了一个高级示例。

现在我们了解了关键术语，让我们深入探讨一些最佳实践。

1. 自动化是关键

要在 PaaS 上运行 CI/CD，您需要在集群上配置适当的基础设施。在本例中，我将使用 OpenShift。

“Hello, World” 的实现非常容易实现。只需运行 oc new-app jenkins-<persistent/ephemeral>，瞧，您就拥有了一个可以使用的 Jenkins 服务器。然而，在企业中的应用要复杂得多。除了 Jenkins 服务器，管理员通常还需要部署代码分析工具（如 SonarQube）和工件仓库（如 Nexus）。然后，他们将不得不创建流水线来执行 CI/CD，并创建 Jenkins 从节点以减少主节点的负载。这些实体中的大多数都由 OpenShift 资源支持，需要创建这些资源才能部署所需的 CI/CD 基础设施。

最终，部署 CI/CD 组件所需的手动步骤可能需要重复，并且您可能不是执行这些步骤的人。为了确保快速、无错误且与之前完全相同地产生结果，应在创建基础设施的方式中加入自动化方法。这可以是 Ansible playbook、Bash 脚本或您想要自动化部署 CI/CD 基础设施的任何其他方式。我使用了 Ansible 和 OpenShift-Applier 角色来自动化我的实现。您可能会发现这些工具很有价值，或者您可能会发现其他更适合您和您组织的工具。无论哪种方式，您都会发现自动化显着减少了重新创建 CI/CD 组件所需的工作量。

配置 Jenkins 主节点

除了通用的“自动化”之外，我想单独指出 Jenkins 主节点，并讨论管理员可以利用 OpenShift 来自动化 Jenkins 配置的几种方法。来自 Red Hat 容器目录 的 Jenkins 镜像包中预装了 OpenShift-Sync 插件。在 视频 中，我们讨论了如何使用此插件来创建 Jenkins 流水线和从节点。

要创建 Jenkins 流水线，请创建一个类似于这样的 OpenShift BuildConfig

apiVersion: v1 
kind: BuildConfig 
... 
spec:   
  source: 	
    git:   
      ref: master   	
      uri: <repository-uri>   
  ...   
  strategy: 	
    jenkinsPipelineStrategy:   	
      jenkinsfilePath: Jenkinsfile 	
    type: JenkinsPipeline

OpenShift-Sync 插件将注意到已创建了策略为 jenkinsPipelineStrategy 的 BuildConfig，并将其转换为 Jenkins 流水线，从 Git 源指定的 Jenkinsfile 中拉取。也可以使用内联 Jenkinsfile 代替从 Git 仓库中拉取。有关更多信息，请参阅 文档。

要创建 Jenkins 从节点，请创建一个以以下定义开头的 OpenShift ImageStream

apiVersion: v1 
kind: ImageStream 
metadata: 
  annotations: 
    slave-label: jenkins-slave 
    labels: 
      role: jenkins-slave 
…

请注意此 ImageStream 中定义的元数据。OpenShift-Sync 插件会将任何带有标签 role: jenkins-slave 的 ImageStream 转换为 Jenkins 从节点。Jenkins 从节点将以 slave-label 注释中的值命名。

ImageStream 非常适合简单的 Jenkins 从节点配置，但有些团队会发现有必要配置细粒度的细节，例如资源限制、就绪性和活性探针以及实例上限。这就是 ConfigMap 发挥作用的地方

apiVersion: v1 
kind: ConfigMap 
metadata: 
  labels: 
  role: jenkins-slave 
... 
data: 
  template1: |- 
    <Kubernetes pod template>

请注意，仍然需要 role: jenkins-slave 标签才能将 ConfigMap 转换为 Jenkins 从节点。Kubernetes pod 模板 由冗长的 XML 片段组成，它将配置您组织所需的每个细节。要查看此 XML，以及有关将 ImageStream 和 ConfigMap 转换为 Jenkins 从节点的更多信息，请参阅 文档。

请注意上面显示的三个示例，所有操作都不需要管理员手动更改 Jenkins 控制台。通过使用 OpenShift 资源，可以以易于自动化的方式配置 Jenkins。

2. 共享是关怀

第二个最佳实践是维护通用 CI/CD 工件的 Git 仓库。主要思想是防止团队重复造轮子。想象一下，您的团队需要在流水线的 CD 阶段执行到 OpenShift 环境的蓝绿部署。负责编写流水线的团队成员可能不是 OpenShift 专家，也可能没有带宽从头开始编写此功能。幸运的是，有人已经在一个通用的 CI/CD 仓库中编写了一个包含该功能的函数，因此您的团队可以使用该函数，而不是花费时间编写一个。

为了更进一步，您的组织可能会决定维护整个流水线。您可能会发现团队正在编写具有类似功能的流水线。对于这些团队来说，使用通用仓库中的参数化流水线比从头开始编写自己的流水线更有效。

3. 少即是多

正如我在上一节中暗示的那样，第三个也是最后一个最佳实践是参数化您的 CI/CD 流水线。参数化将防止流水线过多，从而使您的 CI/CD 系统更易于维护。想象一下，我有多个区域可以部署我的应用程序。如果没有参数化，我将需要为每个区域单独的流水线。

要参数化作为 OpenShift 构建配置编写的流水线，请将 env 节添加到配置中

... 
spec: 
  ... 
  strategy: 
    jenkinsPipelineStrategy: 
      env: 
      - name: REGION 
        value: US-West   	
      jenkinsfilePath: Jenkinsfile 	
    type: JenkinsPipeline

通过此配置，我可以将 REGION 参数传递给流水线，以将我的应用程序部署到指定的区域。

视频 提供了一个更重要的案例，其中参数化是必须的。一些组织决定将他们的 CI/CD 流水线拆分为单独的 CI 和 CD 流水线，通常是因为在部署之前会发生某种审批流程。想象一下，我有四个镜像和三个不同的环境要部署。如果没有参数化，我将需要 12 个 CD 流水线来允许所有部署可能性。这很快就会失控。为了使 CD 流水线的维护更容易，组织会发现最好参数化镜像和环境，以允许一个流水线执行许多流水线的工作。

总结

企业级的 CI/CD 往往比许多组织预期的要复杂。幸运的是，借助 Jenkins，有很多方法可以无缝地提供设置自动化。维护通用 CI/CD 工件的 Git 仓库也将减轻工作量，因为团队可以从维护的依赖项中拉取，而不是从头开始编写自己的依赖项。最后，CI/CD 流水线的参数化将减少必须维护的流水线的数量。

如果您发现其他必不可少的实践，请在评论中分享。