KCNA考試 第六章：持續傳遞

文章目錄

• ​​1. 簡介​​
• ​​2. 學習目标​​
• ​​3. 應用程式傳遞​​
• ​​4. CI / CD​​
• ​​5. GitOps​​
• ​​6. 其它資源​​

1. 簡介

這些年來，在任何平台上部署應用程式都有了很大的進步。一開始,應用程式可能會在同一台機器上執行他們寫,後經由實體媒介(軟碟、u盤、CD),現在我們在代碼中檢查伺服器,建構和應用程式,把它放在一個容器,直接将其部署到一個平台像Kubernetes。

我們傳遞應用程式的方式深受DevOps運動的影響，DevOps運動在2000年代後期取得了突破。DevOps運動是一場文化變革，帶來了許多新方法

2. 學習目标

在本章結束時，你應該能夠:

1. 讨論自動化在內建和傳遞應用程式中的重要性。
2. 了解對Git和版本控制系統的需求。
3. 解釋什麼是CI/CD管道。
4. 讨論作為代碼的基礎設施(IaS)的概念。
5. 讨論GitOps的原理以及它是如何與Kubernetes整合的。

3. 應用程式傳遞

每個應用程式的生命周期都是從編寫的代碼開始的。源代碼不僅是應用程式的基礎，而且是知識産權，是以是大多數公司或個人的資本。我們很久以前就發現，管理源代碼的最佳方式是版本控制系統。

在2005年，Linus Torvalds建立了Git，這是現在幾乎所有人都在使用的标準版本控制系統。Git是一個分散的系統，可以用來跟蹤源代碼中的更改。本質上，Git可以在您的更改合并回主分支之前，使用代碼副本(在分支或分支中調用)。

請務必檢視這個網頁以了解更多關于​​git​​​的資訊，因為它是一個強大的行業标準工具，幾乎所有的開發人員和管理者每天都在使用它。

在檢查源代碼之後，傳遞應用程式之前的下一步就是建構它，這也可能包括容器映像的建構，如容器編排一章所述。

為了確定你的應用的高品質，下一步應該是廣泛和自動測試應用程式，以確定所有功能仍然在有人作出更改後。

最後一步是将應用程式傳遞到它應該運作的平台。如果您的目标平台是Kubernetes，那麼您可以編寫一個YAML檔案來部署您的應用程式，同時您新建構的容器映像可以推送到容器注冊中心，Kubernetes會在那裡為您下載下傳它。

今天，源代碼并不是版本控制系統中管理的唯一内容。為了充分利用雲資源，基礎設施作為代碼(IaC)的原則開始流行起來。您可以在檔案中描述基礎設施，并使用雲供應商的API來設定基礎設施，而不是手動安裝基礎設施。這允許開發人員更多地參與基礎設施的設定。

4. CI / CD

随着服務越來越小，部署越來越頻繁，一個合乎邏輯且重要的步驟就是部署過程的自動化。DevOps運動強調了頻繁和快速部署的重要性。在傳統的設定中，部署将包括開發人員和管理者，許多容易出錯的手動步驟，以及對某些東西會損壞的持續擔心。

自動化是克服這些障礙的關鍵，今天我們知道并使用持續內建/持續傳遞(CI/CD)的原則，它描述了應用程式部署、配置甚至基礎設施的不同步驟。

• 持續內建是這個過程的第一部分，它描述了編寫代碼的永久建構和測試。高度自動化和版 本控制的使用允許多個開發人員和團隊在相同的代碼庫上工作。
• 持續傳遞是過程的第二部分，它将預建構軟體的部署自動化。在雲環境中，您經常會看到軟體在釋出和傳遞到生産系統之前被部署到開發或傳遞環境中。

要自動化整個工作流程，您可以使用CI/CD管道，它實際上隻不過是所有相關步驟的腳本形式，在伺服器上甚至容器中運作。管道應該與管理代碼庫更改的版本控制系統內建。每當您的代碼有新的修訂準備部署時，管道就開始執行腳本，這些腳本建構代碼、運作測試、将它們部署到伺服器，甚至執行安全性和遵從性檢查。

除了管道步驟的通用腳本之外，現代CI/CD工具還有更多的功能，比如直接互動和來自Kubernetes這樣的系統的回報。

流行的CI/CD工具包括:

• ​​Spinnaker​​
• ​​GitLab​​
• ​​Jenkins​​
• ​​Jenkins X​​
• ​​Tekton CD​​
• ​​Argo.​​

為了更深入地了解DevOps、站點可靠性工程和基礎設施作為代碼，我們強烈建議您學習DevOps和​​站點可靠性工程概論(LFS162)​​，這是edX上的一門免費課程。

5. GitOps

作為代碼的基礎設施在提高提供基礎設施的品質和速度方面是一場真正的革命，它工作得如此之好，以至于今天，配置、網絡、政策或安全都可以被描述為代碼，甚至通常與軟體位于同一個存儲庫中。

GitOps進一步将Git的概念作為真理的單一來源，并将基礎設施的配置和更改過程與版本控制操作內建在一起。

如果代碼是分支的，并且應該合并回主分支，您可以建立一個合并或拉取請求，在實際合并之前，其他開發人員可以對其進行審查。這在軟體開發中已經是一個很長時間的最佳實踐了，并且還包括為每一個應該進行的更改運作CI管道。在GitOps中，這些合并請求用于管理基礎設施更改。

CI/CD管道有兩種不同的方法來實作你想要的更改:

• Push-based

  管道啟動并運作在平台中進行更改的工具。變更可以由送出或合并請求觸發。

• Pull-based

  代理會監視git存儲庫的變化，并将存儲庫中的定義與實際運作狀态進行比較。如果檢測到更改，則代理将更改應用到基礎設施。

使用基于拉的方法的兩個流行的GitOps架構的例子是​​Flux​​​和​​ArgoCD​​​。ArgoCD是作為Kubernetes控制器實作的，而Flux是用GitOps工具包建構的，這是一組api和控制器，可以用來擴充Flux，甚至建構一個定制的傳遞平台。

ArgoCD架構很好地概述了GitOps是如何實作的。

​​ArgoCD架構，檢索自ArgoCD文檔​​​ Kubernetes特别适合GitOps，因為它提供了一個API，并且從一開始就為聲明性的資源配置和更改而設計。您可能會注意到，Kubernetes使用了類似于基于拉的方法的思想:監視資料庫的變化，如果變化不比對所需的狀态，則将其應用到運作狀态。

要了解更多關于GitOps的運作情況以及ArgoCD和Flux的使用，可以考慮報名​​免費課程《GitOps入門》(LFS169)​​。

6. 其它資源

10 Deploys Per Day - Start of the DevOps movement at Flickr

• ​​Velocity 09: John Allspaw and Paul Hammond, “10+ Deploys Per Day”​​
• ​​10+ Deploys Per Day: Dev and Ops Cooperation at Flickr​​, by John Allspaw and Paul Hammond

Learn git in a playful way

• ​​Oh My Git! An open source game about learning Git!​​
• ​​Learn Git Branching​​

• ​​Delivering Cloud Native Infrastructure as Code​​
• ​​Unlocking the Cloud Operating Model: Provisioning​​

• ​​GitLab’s guide to CI/CD for beginners​​