作者 | 郝樹偉(花名：流生) 阿里雲高級研發工程師
本文整理自架構師成長系列 2 月17 日直播課程。
關注“阿里巴巴雲原生”公衆號，回覆 “217”，即可獲取對應直播回放鏈接及 PPT 下載鏈接。
導讀：DevOps 是一種軟件開發人員和 IT人員之間的合作過程，目標是高效地自動執行軟件交付和基礎架構更改流程。在雲原生時代，企業又如何藉助 DevOps 實現產品快速、穩定、高效和安全地迭代，釋放業務價值呢？
什麼是雲原生
爲了解決傳統應用升級緩慢、架構臃腫、不能快速迭代、故障不能快速定位、問題無法快速解決等問題，雲原生這一概念橫空出世。
Pivotal 是雲原生應用的提出者，並推出了 Pivotal Cloud Foundry 雲原生應用平臺和 Spring 開源 Java 開發框架，成爲雲原生應用架構中先驅者和探路者。
早在 2015 年 Pivotal 公司的 Matt Stine 就寫了一本叫做遷移到雲原生應用架構的小冊子，其中探討了雲原生應用架構的幾個主要特徵：
- 符合 12 因素應用
- 面向微服務架構
- 自服務敏捷架構
- 基於 API 的協作
- 抗脆弱性
後來 Pivotal 對雲原生的定義做過幾次更新， 最新的 Pivotal 官網上對雲原生應用的最新介紹是關注以下四點：
- 集成 DevOps
- 持續交付
- 微服務
- 容器化
-
DevOps 是軟件開發人員和 IT 運營之間的合作，目標是自動執行軟件交付和基礎架構更改流程。它創造了一種文化和環境，可在其中快速、頻繁且更可靠地構建、測試和發佈軟件；
-
持續交付使得單個應用更改在準備就緒後即可發佈，而不必等待與其它更改捆綁發佈或等待維護窗口期等事件。持續交付讓發佈行爲變得平淡可靠，因此企業可以以更低的風險頻繁交付，並更快地獲得最終用戶的反饋，直到部署成爲業務流程和企業競爭力必不可少的組成部分；
-
微服務是將應用作爲小型服務集合進行開發的架構方法，其中每個服務都可實施業務功能，在自己的流程中運行並通過 HTTP API 進行通信。每個微服務都可以獨立於應用中的其他服務進行部署、升級、擴展和重新啓動，通常作爲自動化系統的一部分運行，可以在不影響最終客戶的情況下頻繁更新正在使用中的應用；
-
與標準虛擬機相比，容器能同時提供效率和速度。單個操作系統實例使用操作系統 級的虛擬化，在一個或多個隔離容器之間進行動態劃分，每個容器都具有唯一的可寫文件系統和資源配額。創建和破壞容器的開銷較低，再加上單個虛擬機中的高包裝密度，使容器成爲部署各個微服務的完美計算工具。
Google 主導成立了雲原生計算基金會（CNCF），對雲原生的定義爲：
“雲原生（Cloud Native）技技術幫助企業和機構在公有云、私有云和混合雲等新型動態環境中，構建和運行可彈性擴展的應用。雲原生的代表技術包括容器、 服務網格、微服務、不可變基礎設施和聲明式 API；這些技術能夠構建容錯性好、易於管理和便於觀察的鬆耦合系統。結合可靠的自動化手段，雲原生技術可以使開發者輕鬆地對系統進行頻 繁並可預測的重大變更 。”
目前雲原生背後最大的推手就是 CNCF，關鍵技術包括容器、微服務、服務網格、devops，聲明式的 API 等等。
雲原生應用與傳統應用的對比，雲原生應用可以充分利用雲的優勢，靈活地在各個雲廠商分發應用，釋放企業生產力，聚焦到業務創新上，而不是花費更多的時間在適配和擴展不同的基礎設施平臺上。
雲原生時代的 DevOps 新挑戰
首先我們要清楚地知道， 站在企業的角度來看，在這樣一個快捷商業的時代，企業最需要什麼？
- 唯快不破。這裏的快可以解讀出來兩層含義，一是業務應用快速上線，有利於搶佔市場先機，第二層意思就是在你的業務有爆炸式增長的時候，你如何在計算資源上給以充分的保證，這個時候其實追加鉅額的 IT 投資購買軟硬件也未必能跟得上業務的快速發展。這個其實就是企業研發效能的問題；
- 穩中求變。業務或者應用的穩定性永遠都是第一位的，如何既保證業務的“穩態”又要滿足快捷商業的“敏態”需求，比如新業務的上線、應用的變更等。這個是企業 IT 架構的問題；
- 節省資源，如何節省計算資源，根據業務是否高峯自動擴容縮容，這個是雲平臺建設的問題；
- 開拓創新，開發運維一體化、微服務架構。
DevOps 最初的出現打破了開發人員和運維人員之間歷來存在的壁壘和溝鴻，加強了開發、運營和質量保證人員之間的溝通、協作與整合。在後 DevOps 時代，我們可以藉助容器技術更快地對應用進行迭代上線。
下面是應用發佈的一般過程，開發者 push 代碼，觸發構建，構建過程是拉取源碼，應用打包，容器鏡像推送，部署。
這個模型其實已經有很多地方充分利用了雲原生的優勢，比如容器技術、Kubernetes、動態分配 slave pod 等。但還有一些挑戰。
- 如何應用在環境棧之間的安全推進發布
- 如何管理應用發佈的權限和安全審批
- 如何提高應用的平均部署時間和平均恢復時間
- 如何迅速對線上應用進行故障定位、復現和回滾
雲原生時代下的 DevOps 之道
首先我們要充分利用雲原生技術的優勢，雲原生可以改進應用開發的效率，改變企業的組織結構，甚至會在文化層面上直接影響一個公司的決策。在容器領域內，Kubernetes 已經成爲了容器編排和管理的社區標準。它通過把應用服務抽象成多種資源類型，比如 Deployment、Service 等，提供了一個雲原生應用通用的可移植模型。
在這樣的背景下，我們如何在雲原生的環境下實踐更高效的 DevOps 來達到更有生產力的表現就成爲了一個新的課題和訴求。
下面是一個企業應用平臺的建設目標：
在此 PaaS 平臺的基礎上，我們設計了 GitOps 安全發佈模型來解決前面我們提到的一些挑戰。
在設計 GitOps 發佈模型的時候是有以下這些核心訴求的：
- 版本管理。我們希望每一個發佈的應用的版本號都能跟 git commit id 關聯，這樣的好處就是每一個變更都有歷史記錄查詢、可以更快進行故障定位和修復；
- 基線管理。便於問題復現和快速回滾；
- 安全發佈。包括髮布權限管理以及安全審批的內容；
- 快速反饋。提高研發效能。
GitOps 發佈模型有以下特性：
- Git 倉庫是任何 CICD 過程的唯一輸入源
- 聲明式的應用編排、構建部署模型
- 應用在環境棧之間的無差別、自動化推進
- PR/MR 觸發的拉取式流水線過程
- 快速反饋機制
下面是使用 GitOps 管理應用發佈到不同 Kubernetes 集羣的架構圖。
首先是應用源碼與構建源碼分離，我們可以看到橙色框起來的這兩個源碼項目，一個是我們的應用源碼項目 application-java-demo， 左側的這個源碼項目是用來存放構建源碼的，比如 preview pipeline 的 Jenkinsfile， staging pipeline 的 Jenkinsfile，production pipeline 的 Jenkinsfile， 除了 Jenkinsfile 之外，可能還有一些關於動態創建測試環境、連接預發環境或者生產環境的敏感信息，這些敏感信息也可以存放在數據庫裏，然後這裏保存數據庫的連接信息。
這個普通應用 application-java-demo 在 Git 倉庫裏是有不同的分支的，每個分支跟 Kubernetes 集羣環境都有一定的對應關係，比如我們這裏的設定，master 分支對應的是生產環境，latest 分支對應的是預發環境，其他開發分支對應的是測試環境，測試環境的動態創建和銷燬、應用再測試環境的部署發佈是開發測試人員自助的服務，但應用想要部署到預發環境和生產環境中的話是需要經過管理員安全審批的。
普通開發者的權限只有創建新代碼分支和創建合併請求的權限，除此之外，剩下其他的部分都是管理員纔有權限做的，綠色區域是 Jenkins 的流水線任務，當然你也可以是使用其他 cicd 引擎來做這個流水線任務的構建。普通開發者沒有 Jenkins 環境的創建 Job 和構建 Job 的權限，也沒有更改配置的權限，他有的只是構建 Job 的日誌查看權限。
最後是一個時序圖，演示一個應用從開發測試到業務上線迭代的一個完整流程：
- 開發者提交新的功能分支 feature；
- 開發者創建請求合併代碼到 latest 分支的 Merge Request；
- 開發者創建 Merge Request 的動作自動觸發名爲 preview-pipeline 的 Jenkins 流水線任務的構建；
- preview-pipeline 流水線任務從 Git 服務器拉取 preview-pipeline 源碼項目，並按照項目中 Jenkinsfile 文件中的聲明式腳本運行源碼編譯、測試、容器鏡像構建和推送、應用部署到 Preview 的容器集羣、釘釘通知的流程；
- 管理員在 Git 服務器的 Merge Request 頁面查看應用的預覽連接並驗證應用是否可以合併到 latest 分支，如果通過驗證則接受 Merge Request 的合併，觸發步驟 6， 如果不通過則通知開發者進行代碼更新和提交，退回步驟 1；
- 管理員接受 Merge Request 合併的動作會自動觸發 Jenkins 流水線任務 staging-pipeline 的構建；
- staging-pipeline 流水線任務從 Git 服務器拉取 staging-pipeline 源碼項目，並按照項目中 Jenkinsfile 文件中的聲明式腳本運行源碼編譯、測試、容器鏡像構建和推送、應用部署到 Staging 的容器集羣、釘釘通知的流程；
- Staging 環境中的應用服務在通過測試和驗證後，管理員可以合併 latest 分支到 master 分支；
- 管理員合併 latest 分支到 master 分支後，會自動觸發 Jenkins 流水線任務 production-pipeline 的構建；
- production-pipeline 流水線任務從 Git 服務器拉取 production-pipeline 源碼項目，並按照項目中 Jenkinsfile 文件中的聲明式腳本運行源碼編譯、測試、容器鏡像構建和推送、應用部署到 Production 的容器集羣、釘釘通知的流程。
GitOps 是一套方法論，所以其實是有多種實踐的方式的，會有多種多樣的好用的工具，比如使用 draft 可以幫助完成應用編排模板的自動化生成，skaffold 用來簡化應用構建部署流程，kaniko 可以實現不依賴 docker daemon 的鏡像構建和推送，helm 用作應用的包管理工具，還有其他 cicd 引擎像 jenkins，tekton，argo 以及爲雲原生而生的 jenkinsx 等等。
後面，我們會單獨實戰演示 GitOps 安全發佈模型的工作過程。
參考文獻：https://pivotal.io/cn/cloud-native
“阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”