[[249849]]

【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管道的維護更容易，企業會發現參數化映像和環境、好讓一條管道執行多條管道的工作來得更明智。

結束語

企業層面的CI/CD往往比許多企業預料的來得復雜。幸好有了Jenkins，有好多方法可以無縫提供自動化機制。維護常見CI/CD工件的Git倉庫也會簡化工作，因為團隊可以從維護的依賴項來獲取，而不是從頭開始自行編寫。***，參數化CI/CD管道將減少需要維護的管道的數量。

原文標題：3 best practices for continuous integration and deployment，作者：Austin Dewey

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】