雲原生入門第六章：持續交付

stargazing發表於2022-03-17

@

目錄

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工具包括:

為了更深入地瞭解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

Learn git in a playful way

Infrastructure as Code

Beginners guide to CI/CD

✈推薦閱讀：

相關文章