持續整合和部署方面的3個最佳實踐

摘要： 【51CTO.com快譯】 本文介紹了三大主題：自動化持續整合/持續部署(CI/CD)配置、使用Git程式碼倉庫用於常見的CI/CD工件以及引數化Jenkins管道。 術語介紹 先不妨定義幾個術語。CI/CD是一種讓團隊可以快速自動測試、打包和部署應用程式的實踐。它常常通過利...

【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配置的幾種方法。來自 ofollow,noindex" target="_blank">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】