持續集成與部署的 3 個最佳實踐

本文涵蓋了三個關鍵主題：自動化 CI/CD 配置、使用 Git 存儲庫處理常見的 CI/CD 工件、參數化 Jenkins 管道。

術語

首先，我們定義一些術語。CI/CD 是允許團隊快速自動化測試、打包、部署其應用程序的實踐。它通常通過利用名為 Jenkins 的伺服器來實現，該伺服器充當 CI/CD 協調器。Jenkins 偵聽特定輸入（通常是代碼簽入後的 Git 掛鉤），並在觸發時啟動一個管道。

管道 pipeline 由開發和/或運營團隊編寫的代碼組成，這些代碼指導 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 劇本、一個 Bash 腳本，或者任何您希望自動化 CI/CD 基礎設施部署的其它方式。我已經使用 Ansible 和 OpenShift-Applier 角色來自動化我的實現。您可能會發現這些工具很有價值，或者您可能會發現其他一些對您和組織更有效的工具。無論哪種方式，您都將發現自動化顯著地減少了重新創建 CI/CD 組件所需的工作量。

配置 Jenkins 主伺服器

除了一般的「自動化」之外，我想單獨介紹一下 Jenkins 主伺服器，並討論管理員如何利用 OpenShift 來自動化配置 Jenkins。來自 Red Hat Container Catalog 的 Jenkins 鏡像已經安裝了 OpenShift-Sync plugin。在 該視頻 中，我們將討論如何使用這個插件來創建 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 注釋中的值命名。

ImageStreams 對於簡單的 Jenkins 從屬配置工作得很好，但是一些團隊會發現有必要配置一些細節詳情，比如資源限制、準備就緒和活動性探測，以及實例上限。這就是 ConfigMap 發揮作用的地方：

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

注意，仍然需要角色：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 管道的參數化將減少必須維護的管道的數量。

如果您找到了其他不可或缺的做法，請在評論中分享。

via: https://opensource.com/article/18/11/best-practices-cicd

作者：Austin Dewey 選題：lujun9972 譯者：ChiZelin 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive