我們 True Engineering 已經建立了一個向客戶伺服器持續交付更新的流程，並希望分享這項經驗。
首先，我們為客戶開發了一個線上系統，並將其部署在我們自己的 Kubernetes 叢集中。 現在我們的高負載解決方案已經轉移到客戶的平台上，我們為此建立了全自動的持續部署流程。 因此，我們加快了上市時間—交付產品環境的變化。
在本文中，我們將討論持續部署 (CD) 流程或向客戶平台交付更新的所有階段：
- 這個過程是如何開始的？
- 與客戶的 Git 儲存庫同步，
- 後端和前端的組裝，
- 在測試環境中自動部署應用程序，
- 自動部署到產品。
我們將一路分享設定細節。
1. 啟動光碟
持續部署從開發人員將變更推送到 Git 儲存庫的發布分支開始。
我們的應用程式在微服務架構上運行，其所有元件都儲存在一個儲存庫中。 因此，即使其中一個微服務發生了更改，所有微服務都會被收集和安裝。
我們透過一個儲存庫組織工作有以下幾個原因：
- 易於開發 - 應用程式正在積極開發，因此您可以立即使用所有程式碼。
- 單一 CI/CD 管道，保證應用程式作為單一系統通過所有測試並交付到客戶的生產環境。
- 我們消除了版本混亂 - 我們不必儲存微服務版本映射並在 Helm 腳本中描述每個微服務的配置。
2.與客戶原始碼的Git倉庫同步
所做的變更會自動與客戶的 Git 儲存庫同步。 在那裡配置應用程式程序集，該程序集在更新分支後啟動，並部署到延續。 這兩個進程都源自於其環境中的 Git 儲存庫。
我們無法直接使用客戶的儲存庫，因為我們需要自己的開發和測試環境。 我們將 Git 儲存庫用於這些目的 - 它與他們的 Git 儲存庫同步。 一旦開發人員將變更發佈到我們儲存庫的相應分支，GitLab 就會立即將這些變更推送給客戶。
之後您需要進行組裝。 它由幾個階段組成：後端和前端組裝、測試和交付生產。
3. 組裝後端和前端
建構後端和前端是在 GitLab Runner 系統中執行的兩個平行任務。 其原始程序集配置位於同一儲存庫中。
.
GitLab Runner 從所需的儲存庫中取得程式碼，使用 Java 應用程式建置命令進行組裝，並將其傳送至 Docker 註冊表。 在這裡，我們組裝後端和前端，取得 Docker 映像，並將其放入客戶側的儲存庫中。 為了管理我們使用的 Docker 映像 .
我們將映像的版本與將在 Docker 中發布的發布版本進行同步。 為了順利運行，我們做了一些調整：
1.測試環境和生產環境之間不重建容器。 我們進行了參數化，以便同一個容器可以在測試環境和生產環境中使用所有設定、環境變數和服務，而無需重建。
2. 若要透過 Helm 更新應用程序，您必須指定其版本。 我們建立後端、前端並更新應用程式 - 這是三個不同的任務，因此在任何地方使用相同版本的應用程式非常重要。 對於此任務，我們使用 Git 歷史記錄中的數據，因為我們的 K8S 叢集配置和應用程式位於同一個 Git 儲存庫中。
我們從命令執行結果中取得應用程式版本
git describe --tags --abbrev=7.
4.自動部署所有變更到測試環境（UAT）
此建置腳本的下一步是自動更新 K8S 叢集。 如果整個應用程式已建置並且所有工件已發佈到 Docker 註冊表，則會發生這種情況。 之後，測試環境更新開始。
叢集更新開始使用 。 如果結果沒有按計劃進行，Helm 將自動且獨立地回滾所有變更。 他的工作不需要受到控制。
我們提供 K8S 叢集配置以及元件。 因此，下一步是更新它：configMaps、部署、服務、金鑰以及我們更改的任何其他 K8S 配置。
然後，Helm 在測試環境中執行應用程式本身的 RollOut 更新。 在將應用程式部署到生產環境之前。 這樣做是為了讓使用者可以手動測試我們放入測試環境的業務功能。
5.自動部署所有變更到Prod
若要將更新部署到生產環境，您只需在 GitLab 中按一下按鈕 - 容器就會立即交付到生產環境。
相同的應用程式可以在不同的環境（測試和生產）中運行，而無需重建。 我們使用相同的工件，而不更改應用程式中的任何內容，並在外部設定參數。
應用程式設定的靈活參數化取決於應用程式的執行環境。 我們已將所有環境設定移至外部：所有內容均透過 K8S 配置和 Helm 參數進行參數化。 當 Helm 將組件部署到測試環境時，測試設定將套用於該組件，而產品設定將應用於生產環境。
最困難的事情是參數化所有依賴環境的使用的服務和變量，並將它們轉換為Helm的環境變量和環境參數的描述配置。
應用程式設定使用環境變數。 它們的值是使用 K8S configmap 在容器中設定的，該配置映射使用 Go 模板進行模板化。 例如，可以將環境變數設定為域名，如下所示：
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Values.global.env – 此變數儲存環境的名稱（prod、stage、UAT）。
.Values.app.properties.app_external_domain – 在此變數中，我們在 .Values.yaml 檔案中設定所需的域
更新應用程式時，Helm 會根據範本建立 configmap.yaml 文件，並根據應用程式更新開始的環境，使用所需的值填入 APP_EXTERNAL_DOMAIN 值。 該變數已在容器中設定。 它可以從應用程式訪問，因此每個應用程式環境都會有該變數的不同值。
最近，Spring Cloud 中出現了 K8S 支持，包括使用 configMaps： 。 雖然該專案正在積極開發並發生根本性變化，但我們無法在生產中使用它。 但我們積極監控其狀況並在 DEV 配置中使用它。 一旦它穩定下來，我們就會從使用環境變數切換到它。
在總
因此，持續部署已配置並正在執行。 所有更新均透過一次按鍵完成。 對產品環境的變更的交付是自動的。 而且，重要的是，更新不會停止系統。
未來計畫：自動資料庫遷移
我們考慮了升級資料庫以及回滾這些變更的可能性。 畢竟，應用程式的兩個不同版本同時運行：舊版本正在運行，新版本正在運行。 只有當我們確定新版本可以工作時，我們才會關閉舊版本。 資料庫遷移應該允許您使用應用程式的兩個版本。
因此，我們不能簡單地更改列名或其他資料。 但是我們可以建立一個新列，將舊列中的資料複製到其中，並編寫觸發器，在更新資料時，將同時在另一列中複製和更新資料。 成功部署新版本的應用程式後，在啟動後支援期結束後，我們將能夠刪除舊列和不再需要的觸發器。
如果新版本的應用程式無法正常運作，我們可以回滾到先前的版本，包括先前版本的資料庫。 簡而言之，我們的更改將允許您同時使用該應用程式的多個版本。
我們計劃透過 K8S 作業自動化資料庫遷移，並將其整合到 CD 流程中。 我們一定會在哈布雷身上分享這段經歷。
來源： www.habr.com