转载

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

【51CTO.com快译】本文介绍了三大主题：自动化持续集成/持续部署(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- 就行了，你有了一台运行中的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 Container Catalog 中的Jenkins映像随附安装了OpenShift-Sync插件(https://github.com/openshift/jenkins-sync-plugin)。

想创建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标注的值命名。

ImageStreams非常适合简单的Jenkins从节点配置，但是一些团队发现有必要配置一些基本细节，比如资源限制、就绪和活性探针以及实例上限。这时ConfigMaps可以派上用场：

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

注意仍需要role: jenkins-slave标签将ConfigMap转换成Jenkins从节点。Kubernetes pod模块包括一段很长的XML，可根据贵企业的喜好来配置每个细节。想查看该XML以及将ImageStreams和ConfigMaps转换成Jenkins从节点方面的更多信息，请参阅说明文档。

从上面三个例子中可以看出，没有一项操作要求管理员手动更改Jenkins控制台。通过使用OpenShift资源，Jenkins能以一种轻松自动化的方式来配置。

2. 共享就是关爱

第二个最佳实践是维护常见CI/CD工件的Git仓库。主要想法是，防止团队重新发明轮子。设想你的团队需要执行蓝/绿部署到OpenShift环境的工作，作为管道的CD阶段的一部分。团队中负责编写管道的成员可能不是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管道的维护更容易，企业会发现参数化映像和环境、好让一条管道执行多条管道的工作来得更明智。