歡迎光臨
每天分享高質量文章
當前位置：知識星球 > 後端 > 正文

容器環境下的持續整合最佳實踐

2019-04-08 分類：後端 閱讀(421) 評論(0)

本文結合 Drone + GitFlow + Kubernetes 介紹一些容器環境下持續整合、持續釋出方面的實踐經驗。文章將展示從 Hello World 到單人單分支手動釋出到團隊多分支 GitFlow 工作流再到團隊多分支 semantic-release 語意化釋出最後到通知 Kubernetes 全自動釋出，如何從零開始一步一步搭建 CI 將團隊開發、測試、釋出的流程全部自動化的過程，最終能讓開發人員只需要認真提交程式碼就可以完成日常的所有 DevOps 工作。
雲原生（Cloud Native）是伴隨的容器技術發展出現的的一個詞，最早出自 Pivotal 公司（即開發了 Spring 的公司）的一本技術小冊子 Migrating to Cloud-Native Application Architectures， 其中定義了雲原生應用應當具備的一些特質，如無狀態、可持續交付、微服務化等。隨後雲原生概念被廣為取用，並圍繞這一概念由數家大廠牽頭，成立了 CNCF 基金會來推進雲原生相關技術的發展，主要投資並孵化雲原生生態內的若干專案，包括瞭如 Kubernetes / etcd / CoreDNS 等耳熟能詳的重要專案。而這張大大的雲原生版圖仍然在不斷的擴充套件和完善。
從個人理解來說，傳統的應用由於年代久遠，更多會考慮單機部署、行程間通訊等典型的“單機問題”，雖然也能工作在容器下，但由於歷史包袱等原因，架構上已經很難做出大的調整。而“雲原生”的應用大都是從一開始就為容器而準備，很少考慮在單機環境下使用，有些甚至無法脫離容器環境工作；考慮的場景少，從而更輕量，迭代更快。比如 etcd 之於 ZooKeeper， Traefik 之於 Nginx 等，相信只要在容器環境下實現一次同樣的功能，就能強烈的體會到雲原生應用所特有的便捷之處。
在 CNCF 的版圖下，持續整合與持續交付（Continuous Integration & Delivery）板塊一直缺少一個欽定的主角，雖然也不乏 Travis CI、GitLab、Jenkins 這樣的知名專案，但最能給人雲原生應用感覺的，應該還是 Drone 這個專案，本文將圍繞 Drone 結合 GitFlow 及 Kubernetes 介紹一些容器環境下持續整合、持續釋出（CI/CD）方面的實踐經驗。
主流 CI/CD 應用對比

 

之前我也介紹過基於 Travis CI 的一些持續整合實踐[1]。後來經過一些比較和調研，最終選擇了 Drone 作為主力 CI 工具。截止本文，團隊已經使用 Drone 有 2 年多的時間，從 v0.6 一路用到現在即將釋出的 v1.0，雖然也踩了不少坑，但總的來說 Drone 還是可以滿足大部分需求，並以不錯的勢頭在完善和發展的。
下麵這張表總結了主流的幾個 CI/CD 應用的特點： 
Travis CI 和 CircleCI 是目前佔有率最高的兩個公有雲 CI，易用性上相差無幾，只是收費方式有差異。由於不支援私有部署，如果並行的任務量一大，按行程收費其實並不划算；而且由於伺服器位置的原因，如果推送映象到國內，速度很不理想。
GitLab CI 雖然好用，但和 GitLab 是深度系結的，我們的程式碼託管在 GitHub，整體遷移程式碼庫的成本太大，放棄。
Jenkins 作為老牌勁旅，也是目前市場佔有率最高的 CI，幾乎可以改寫所有 CI 的使用場景，由於使用 Java 編寫，配置檔案使用 Groovy 語法，非常適合 Java 為主語言的團隊。Jenkins 顯然是可以滿足我們需要的，只是團隊並非 Java 為主，又已經習慣了使用 YAML 書寫 CI 配置，抱著嘗鮮的心態，將 Jenkins 作為了保底的選擇。
綜上，最終選擇 Drone 的結論也就不難得出了，Drone 即開源，又可以私有化部署，同時作為雲原生應用，官方提供了針對 Docker、Docker Swarm、Kubernetes 等多種容器場景下的部署方案，針對不同容器場景還有特別最佳化，比如在 Docker Swarm 下 Drone 是以 Agent 方式執行 CI 任務的，而在 Kubernetes 下則透過建立 Kubernetes Job 來實現，顯然充分利用了容器的優勢所在，這也是 Drone 優於其他 CI 應用之處。個人還覺得 Drone 的語法是所有 CI 中最容易理解和掌握的，由於 Drone 每一個步驟都是執行一個 Docker 容器，本地模擬或除錯也非常容易。
一句話概況 Drone，可以將其看做是可以支援私有化部署的開源版 CircleCI，並且目前仍然沒有看到有其他主打這個定位的 CI 工具，因此個人認為 Drone 是 CI/CD 方面雲原生應用頭把交椅的有力競爭者。
容器環境下一次規範的釋出應該包含哪些內容

 

技術選型完成後，我想首先演示一下最終的成果，希望能直觀的體現出 CI 對自動化效率起到的提升，不過這就涉及到一個問題：在容器環境下，一次釋出應該包含哪些內容，其中有哪些部分是可以被 CI 自動化完成的。這個問題雖然每家公司各不相同，不過按經驗來說，容器環境下一次版本釋出通常包含這樣一個 Checklist：

  • 程式碼的下載構建及編譯

  • 執行單元測試，生成單元測試報告及改寫率報告等

  • 在測試環境對當前版本進行測試

  • 為待釋出的程式碼打上版本號

  • 編寫 ChangeLog 說明當前版本所涉及的修改

  • 構建 Docker 映象

  • 將 Docker 映象推送到映象倉庫

  • 在預釋出環境測試當前版本

  • 正式釋出到生產環境

 

看上去很繁瑣對嗎，如果每次釋出都需要人工去處理上述的所有內容，不僅容易出錯，而且也無法應對 DevOps 時代一天至少數次的釋出頻率，那麼下麵就來使用 CI 來解決所有問題吧。
CI 流程演示

 

為了對 CI 流程有最直觀的認識，我建立了一個精簡版的 GitHub 專案 AlloVince/drone-ci-demo[2] 來演示完整的流程，同時專案對應的 CI 地址是 cloud.drone.io/AlloVince/drone-ci-demo，專案自動構建的 Docker 映象會推送到 docker registry 的 allovince/drone-ci-demo。為了方便說明，假設這個專案的核心檔案只有 index.html 一個靜態頁面。
單人開發樣式
目前這個專案背後的 CI 都已經配置部署好，假設我是這個專案的唯一開發人員，如何開發一個新功能併發布新版本呢？

  • Clone 專案到本地， 修改專案程式碼， 如將 Hello World 改為 Hello World V2。

  • git add .，然後書寫符合約定的 Commit 並提交程式碼， git commit -m “feature: hello world v2”。

  • 推送程式碼到程式碼庫git push，等待數分鐘後，開發人員會看到單元測試結果，GitHub 倉庫會產生一次新版本的 Release，Release 內容為當前版本的 ChangeLog， 同時線上已經完成了新功能的釋出。

 

雖然在開發者看來，一次釋出簡單到只需 3 個指令，但背後經過瞭如下的若干次互動，這是一次釋出實際產生互動的時序圖，具體每個環節如何工作將在後文中詳細說明。 
多人開發樣式
一個專案一般不止一個開發人員，比如我是新加入這個專案的成員，在這個 Demo 中應該如何上線新功能呢？同樣非常簡單：

  1. Clone 專案到本地，建立一個分支來完成新功能的開發, git checkout -b feature/hello-world-v3。在這個分支修改一些程式碼，比如將Hello World V2修改為Hello World V3

  2. git add .，書寫符合規範的 Commit 並提交程式碼， git commit -m “feature: hello world v3”

  3. 將程式碼推送到程式碼庫的對應分支， git push origin feature/hello-world

  4. 如果功能已經開發完畢，可以向 Master 分支發起一個 Pull Request，並讓專案的負責人 Code Review

  5. Review 透過後，專案負責人將分支合併入主幹，GitHub 倉庫會產生一次新版本的 Release，同時線上已經完成了新功能的釋出。

這個流程相比單人開發來多了 2 個環節，很適用於小團隊合作，不僅強制加入了 Code Review 把控程式碼質量，同時也避免新人的不規範行為對釋出帶來影響。實際專案中，可以在 GitHub 的設定介面對 Master 分支設定寫入保護，這樣就從根本上杜絕了誤操作的可能。當然如果團隊中都是熟手，就無需如此謹慎，每個人都可以負責 PR 的合併，從而進一步提升效率。
 
GitFlow 開發樣式
在更大的專案中，參與的角色更多，一般會有開發、測試、運維幾種角色的劃分；還會劃分出開發環境、測試環境、預釋出環境、生產環境等用於程式碼的驗證和測試；同時還會有多個功能會在同一時間並行開發。可想而知 CI 的流程也會進一步複雜。
能比較好應對這種複雜性的，首選 GitFlow 工作流， 即透過並行兩個長期分支的方式規範程式碼的提交。而如果使用了 GitHub，由於有非常好用的 Pull Request 功能，可以將 GitFlow 進行一定程度的簡化，最終有這樣的工作流： 

  • 以 dev 為主開發分支，Master 為釋出分支

  • 開發人員始終從 dev 建立自己的分支，如 feature-a

  • feature-a 開發完畢後建立 PR 到 dev 分支，併進行 code review

  • review 後 feature-a 的新功能被合併入 dev，如有多個並行功能亦然

  • 待當前開發週期內所有功能都合併入 dev 後，從 dev 建立 PR 到 master

  • dev 合併入 Master，並建立一個新的 Release

上述是從 Git 分支角度看程式碼倉庫發生的變化，實際在開發人員視角里，工作流程是怎樣的呢。假設我是專案的一名開發人員，今天開始一期新功能的開發：

  1. Clone 專案到本地，git checkout dev。從 dev 建立一個分支來完成新功能的開發, git checkout -b feature/feature-a。在這個分支修改一些程式碼，比如將Hello World V3修改為Hello World Feature A

  2. git add .，書寫符合規範的 Commit 並提交程式碼， git commit -m “feature: hello world feature A”

  3. 將程式碼推送到程式碼庫的對應分支， git push origin feature/feature-a:feature/feature-a

  4. 由於分支是以 feature/ 命名的，因此 CI 會執行單元測試，並自動構建一個當前分支的映象，釋出到測試環境，並自動配置一個當前分支的域名如 test-featue-a.avnpc.com

  5. 聯絡產品及測試同學在測試環境驗證並完善新功能

  6. 功能透過驗收後發起 PR 到 dev 分支，由 Leader 進行 code review

  7. Code Review 透過後，Leader 合併當前 PR，此時 CI 會執行單元測試，構建映象，併發布到測試環境

  8. 此時 dev 分支有可能已經積累了若干個功能，可以訪問測試環境對應 dev 分支的域名，如 test.avnpc.com，進行整合測試。

  9. 整合測試完成後，由運維同學從 Dev 發起一個 PR 到 Master 分支，此時會 CI 會執行單元測試，構建映象，併發布到預釋出環境

  10. 測試人員在預釋出環境下再次驗證功能，團隊做上線前的其他準備工作

    運維同學合併 PR，CI 將為本次釋出的程式碼及映象自動打上版本號並書寫 ChangeLog，同時釋出到生產環境。

  11. 由此就完成了上文中 Checklist 所需的所有工作。雖然描述起來看似冗長，但不難發現實際作為開發人員，並沒有任何複雜的操作，流程化的部分全部由 CI 完成，開發人員只需要關註自己的核心任務：按照工作流規範，寫好程式碼，寫好 Commit，提交程式碼即可。

接下來將介紹這個以 CI 為核心的工作流，是如何一步步搭建的。
Step by Step 構建 CI 工作流

 

Step.0：基於 Kubernetes 部署 Drone v1.0.0
以 GitHub 為例，截止本文完成時間（2019 年 3 月 28 日）， Drone 剛剛釋出了第一個正式版本 v1.0.0。官方檔案已經提供了分別基於 Docker、Kubernetes 的 Drone 部署說明，不過比較簡略，因此這裡給出一個相對完整的配置檔案。
首先需要在 GitHub 建立一個 Auth App，用於 repo 的訪問授權。應用建立好之後，會得到 Client ID 和 Client Secret 。同時 Authorization callback URL 應填寫 Drone 服務對應域名下的 /login，如 https://ci.avnpc.com/login。
Drone 支援 SQLite、MySQL、Postgres、S3 等多種後端儲存，主要用於記錄 build logs 等文字資訊，這些資訊並不是特別重要，且我們的 CI 有可能做遷移，因此個人更推薦使用 SQLite。
而在 Kubernetes 環境下，SQLite 更適合用掛載 NAS 的方式供節點使用，因此首先將儲存的部分獨立為檔案 drone-pvc.yml，可以根據實際情況配置 nfs.path 和 nfs.server：
  1. kubectl apply -f drone-pvc.yaml
Drone 的配置主要涉及兩個映象：

  • drone/kubernetes-secrets 加密資料服務，用於讀取 Kubernetes 的 secrets

  • drone/drone:1.0.0-rc.6 就是 Drone 的 server 端，由於在 Kubernetes 下 Drone 利用了 Job 機制，因此不需要部署 Agent。

這部分配置較長，可以直接參考示例 drone.yaml[3]。
 
主要涉及到的配置項包括：
 

  • Drone/kubernetes-secrets 映象中

    • SECRET_KEY：資料加密傳輸所用的 key，可以使用 openssl rand -hex 16 生成一個

  • Drone/Drone映象中

    • DRONEKUBERNETESENABLED：開啟 Kubernetes 樣式

    • DRONEKUBERNETESNAMESPACE：Drone 所使用的 Namespace， 這裡使用 default

    • DRONEGITHUBSERVER：GitHub 伺服器地址，一般為 https://github.com

    • DRONEGITHUBCLIENT_ID：上文建立 GitHub Auth App 得到的 Client ID

    • DRONEGITHUBCLIENT_SECRET：上文建立 GitHub Auth App 得到的 Client Secret

    • DRONESERVERHOST：Drone 服務所使用的域名

    • DRONESERVERPROTO：http 或 https

    • DRONEDATABASEDRIVER：Drone 使用的資料庫型別，這裡為 SQLite3

    • DRONEDATABASEDATASOURCE：這裡為 SQLite 資料庫的存放路徑

    • DRONESECRETSECRET：對應上文的 SECRET_KEY

    • DRONESECRETENDPOINT：加密資料服務的地址，這裡透過 Kubernetes Service 暴露，無需修改

最後部署即可：
  1. kubectl apply -f drone.yaml
部署後首次登入 Drone 就會跳轉到 GitHub Auth App 進行授權，授權完畢後可以看到所有能讀寫的 Repo，選擇需要開啟 CI 的 Repo，點選 ACTIVATE 即可。 如果開啟成功，在 GitHub Repo 的 Settings > Webhooks 下可以看到 Drone 的回呼地址。
Step.1：Hello World for Drone
在正式開始搭建工作流之前，首先可以測試一下 Drone 是否可用。Drone 預設的配置檔案是 .drone.yml， 在需要 CI 的 repo 根目錄下建立.drone.yml， 內容如下，提交並git push到程式碼倉庫即可觸發 Drone 執行 CI。
  1. kind: pipeline
  2. name: deploy
  4. steps:
  5. - name: hello-world
  6. image: docker
  7. commands:
  8. - echo "hello world"
Drone v1 的語法主要參考的 Kubernetes 的語法，非常直觀，無需閱讀檔案也可以知道，我們首先定義了一個管道（Pipeline），管道由若干步驟（step）組成，Drone 的每個步驟是都基於容器實現的，因此 Step 的語法就回到了我們熟悉的 Docker，一個 Step 會拉取 image 定義的映象，然後執行該映象，並順序執行 commands 定義的指令。
在上例中，Drone 首先 clone git repo 程式碼到本地，然後根據 .drone.yml 所定義的，拉取 Docker 的官方映象，然後執行該進行並掛載 git repo 的程式碼到 /drone/src 目錄。
在 Drone 的介面中，也可以清楚的看到這一過程。
 
本階段對應：

  • 程式碼部分：https://github.com/AlloVince/drone-ci-demo/tree/hello-world

  • Drone 構建記錄：https://cloud.drone.io/AlloVince/drone-ci-demo/1

  • Docker 映象：無

 

Step.2：單人工作流，自動化單元測試與 Docker 映象構建
有了 Hello World 的基礎，接下來我們嘗試將這個工作流進行擴充。
為了方便說明，這裡假設專案語言為 JavaScript，專案內新增了 test/index.js 檔案用於模擬單元測試，一般在 CI 中，只要程式的傳回值為 0，即代表執行成功。這個檔案中我們僅僅輸出一行 Log Unit test passed用於模擬單元測試透過。
我們希望將程式碼打包成 Docker 映象，根目錄下增加了 Dockerfile 檔案，這裡直接使用 Nginx 的官方映象，構建過程只有 1 行 COPY index.html /usr/share/nginx/html/， 這樣映象執行後可以透過 http 請求看到 index.html 的內容。
至此我們可以將工作流改進為：

  • 當 Master 分支接收到 push 後，執行單元測試

  • 當 GitHub 釋出一次 Release， 構建 Docker 映象，並推送到映象倉庫

對應的 Drone 配置檔案如下：
  1. kind: pipeline
  2. name: deploy
  4. steps:
  5. - name: unit-test
  6. image: node:10
  7. commands:
  8. - node test/index.js
  9. when:
  10. branch: master
  11. event: push
  12. - name: build-image
  13. image: plugins/docker
  14. settings:
  15. repo: allovince/drone-ci-demo
  16. username: allovince
  17. password:
  18. from_secret: DOCKER_PASSWORD
  19. auto_tag: true
  20. when:
  21. event: tag
雖然比 Hello World 複雜了一些，但是可讀性仍然很好，配置檔案中出現了幾個新概念：
Step 執行條件， 即 when 部分，上例中展示了當程式碼分支為 Master，且收到一個 push；以及當程式碼被標記 tag 這兩種情況。Drone 還支援 repo、執行結果等很多其他條件，可以參考 Drone Conditions[4] 檔案。
Plugin 外掛，上例中用於構建和推送映象的是 plugins/docker 這個 Plugin， 一個 Plugin 本質上仍然是一個 Docker 映象，只是按照 Drone 的規範接受特定的輸入，並完成特定的操作。所以完全可以將 Plugin 看做一個無法更改 command 的 Docker 映象。
Docker 這個 Plugin 由 Drone 官方提供，用於 Docker 映象的構建和推送，具體的用法可以檢視 Docker 外掛的檔案[5]。例子中演示的是將映象推送到私有倉庫，如果不做特殊配置，映象將被推送到 Docker 的官方倉庫。
此外 Docker 外掛還有一個很方便的功能，如果設定 auto_tag: true，將根據程式碼的版本號自動規劃 Docker 映象的標簽，如程式碼版本為1.0.0，將為 Docker 映象打三個標簽 1, 1.0, 1.0.0。如果程式碼版本號不能被解析，則映象標簽為 latest。
目前 Drone 的外掛已經有很多，可以改寫主流的雲服務商和常見的工作流，並且自己製作外掛的成本也不高。
Secret 加密資料，映象倉庫的使用者名稱和密碼都屬於敏感資訊，因此可以使用 fromsecret 獲取加密資料。一條加密資料就是一個 key / value 對，如上例中的 DOCKERPASSWORD 就是我們自己定義的加密資料 key。即便加密資料在 log 中被列印，UI 也只能看到 *。加密資料的 value 需要提前儲存好，儲存的方式有 3 種：

  • 透過 Drone UI 介面中， repo -> Settings -> Secrets 新增，所新增的加密資料將儲存在 Drone 的資料庫中，僅能在當前 repo 中使用。

  • 透過 Drone cli 加密後儲存在 .drone.yml 檔案中， 使用範圍僅限 yaml 檔案內

  • 透過 Kubernetes 儲存為 Kubernetes Secret，稱為 External Secrets，所有的 repo 都可以共享。如果是團隊使用的話，這種儲存方式顯然是最方便的，但也要註意安全問題，因此 External Secrets 還支援 repo 級別的許可權管理， 可以只讓有當前 repo 寫入許可權的人才能使用對應 secret。

 

這個階段對應：

  • 程式碼倉庫：https://github.com/AlloVince/drone-ci-demo/tree/single-person

  • push 時觸發的 Drone CI：https://cloud.drone.io/AlloVince/drone-ci-demo/4

  • Release 時觸發的 Drone CI：https://cloud.drone.io/AlloVince/drone-ci-demo/5

  • Release 後 CI 構建的 Docker 映象：allovince/drone-ci-demo:latest

Step.3：GitFlow 多分支團隊工作流
上面的工作流已經基本可以應付單人的開發了，而在團隊開發時，這個工作流還需要一些擴充套件。不需要引入 Drone 的新功能，只需要在上文基礎上根據分支做一點調整即可。
首先保證單元測試位於 steps 的第一位，並且限定團隊工作的分支，在 push 和 pull_request 時，都能觸發單元測試。
  1. - name: unit-test
  2. image: node:10
  3. commands:
  4. - node test/index.js
  5. when:
  6. branch:
  7. include:
  8. - feature/*
  9. - master
  10. - dev
  11. event:
  12. include:
  13. - push
  14. - pull_request
然後根據 GitFlow 的流程對於不同的分支構建 Docker 映象並打上特定標簽，以 feature 分支為例，下麵的配置約定了當分支名滿足 feature/*，並收到 push 時，會構建 Docker 映象並打標簽，標簽名稱為當前分支名去掉 feature/。如分支 feature/readme， 對應 Docker 映象為 allovince/drone-ci-demo:readme，考慮到 feature 分支一般都出於開發階段，因此新的映象會改寫舊的。配置如下：
  1. - name: build-branch-image
  2. image: plugins/docker
  3. settings:
  4. repo: allovince/drone-ci-demo
  5. username: allovince
  6. password:
  7. from_secret: DOCKER_PASSWORD
  8. tag:
  9. - ${DRONE_BRANCH##feature/}
  10. when:
  11. branch: feature/*
  12. event: push
映象的 Tag 處不再使用自動方式，其中 DRONE_BRANCH 是 Drone 的內建環境變數（Environment），對應當前的分支名。##feature/ 是執行了一個字串的替換操作（Substitution）。更多的環境變數和字串操作都可以在檔案中找到。
以此類推，可以檢視這個階段的完整 .drone.yml ，此時我們的工作流示例如下：

  • 團隊成員從 dev 分支 checkout 自己的分支 feature/readme

  • 向feature/readme提交程式碼並 push， CI 執行單元測試，構建映象allovince/drone-ci-demo:readme

  • 功能開發完成後，團隊成員向 dev 分支 發起 pull request ， CI 執行單元測試

  • 團隊其他成員 merge pull request， CI 執行單元測試，構建映象allovince/drone-ci-demo:test

  • 運維人員從 dev 向 master 發起 pull request，CI 執行單元測試，並構建映象allovince/drone-ci-demo:latest

  • 運維人員 merge pull request， 並 Release 新版本 pre-0.0.2， CI 構建映象allovince/drone-ci-demo:pre-0.0.2

可能細心的同學會發現 dev -> Master 的 pull request 時，構建映象失敗了，這是由於 Drone 出於安全考慮限制了在 pull request 時預設無法讀取加密資料，因此無法得到 Docker Registry 密碼。如果是私有部署的話，可以在 Repo Settings 中勾選 Allow Pull Requests，此處就可以構建成功。
Step.4：語意化釋出
上面基本完成了一個支援團隊協作的半自動 CI 工作流，如果不是特別苛刻的話，完全可以用上面的工作流開始幹活了。
不過基於這個工作流工作一段時間，會發現仍然存在痛點，那就是每次釋出都要想一個版本號，寫 ChangeLog，並且人工去 Release。
標記版本號涉及到上線後的回滾，追溯等一系列問題，應該是一項嚴肅的工作，其實如何標記早已有比較好的方案，即語意化版本。在這個方案中，版本號一共有 3 位，形如 1.0.0，分別代表：

  • 主版本號：當你做了不相容的 API 修改

  • 次版本號：當你做了向下相容的功能性新增

  • 修訂號：當你做了向下相容的問題修正

 

雖然有了這個指導意見，但並沒有很方便的解決實際問題，每次釋出要搞清楚程式碼的修改到底是不是向下相容的，有哪些新的功能等，仍然要花費很多時間。
而語意化釋出（Semantic Release）就能很好的解決這些問題。
語意化釋出的原理很簡單，就是讓每一次 Commit 所附帶的 Message 格式遵守一定規範，保證每次提交格式一致且都是可以被解析的，那麼進行 Release 時，只要統計一下距離上次 Release 所有的提交，就分析出本次提交做了何種程度的改動，並可以自動生成版本號、自動生成 ChangeLog 等。
語意化釋出中，Commit 所遵守的規範稱為約定式提交（Conventional Commits）。比如 Node.js、 Angular、Electron 等知名專案都在使用這套規範。
語意化釋出首先將 Commit 進行分類，常用的分類（Type）有：

  • feat：新功能

  • fix：BUG 修複

  • docs：檔案變更

  • style：文字格式修改

  • refactor：程式碼重構

  • perf：效能改進

  • test：測試程式碼

  • chore：工具自動生成

每個 Commit 可以對應一個作用域（Scope），在一個專案中作用域一般可以指不同的模組。
當 Commit 內容較多時，可以追加正文和腳註，如果正文起始為BREAKING CHANGE，代表這是一個破壞性變更。
以下都是符合規範的 Commit：
  1. feat：增加重置密碼功能
  1. fix（郵件模組）：修複郵件傳送延遲BUG
  1. feat（API）：API重構
  3. BREAKING CHANGE：API v3上線，API v1停止支援
有了這些規範的 Commit，版本號如何變化就很容易確定了，目前語意化釋出預設的規則如下：
  1. Commit 版本號變更
  2. BREAKING CHANGE 主版本號
  3. feat 次版本號
  4. fix / perf 修訂號
因此在 CI 部署 semantic-release 之後，作為開發人員只需要按照規範書寫 Commit 即可，其他的都由 CI 完成。
具體如何將語意化釋出加入 CI 流程中呢， semantic-release 是 js 實現的，如果是 js 的專案，可以直接在 package.json 中增加配置項，而對於任意語言的專案，推薦像 Demo 中一樣，在根目錄下增加 配置檔案release.config.js。這個配置目的是為了禁用預設開啟的 npm 釋出機制，可以直接套用。
semantic-release 要執行 GitHub Release，因此我們需要在 CI 中配置自己的 Personal access tokens 讓 CI 有 GitHub Repo 的讀寫許可權， 可以透過 GitHub 點選自己頭像 -> Settings -> Developer settings -> Personal access tokens -> Generate new token 生成一個 Token。 然後在 Drone 的 repo 設定介面新增一個 Secret， key 為 GITHUB_TOKEN， value 填入剛生成的 Token。
最後在 .drone.yml 中增加這樣一段就可以了。
  1. - name: semantic-release
  2. image: gtramontina/semantic-release:15.13.3
  3. environment:
  4. GITHUB_TOKEN:
  5. from_secret: GITHUB_TOKEN
  6. entrypoint:
  7. - semantic-release
  8. when:
  9. branch: master
  10. event: push
來再次模擬一下流程，feature 分支部分與上文相同：

  • 從 dev 向 master 發起 pull request，CI 執行單元測試，並構建映象allovince/drone-ci-demo:latest

  • merge pull request，CI 會執行單元測試並執行 semantic-release ， 執行成功的話能看到 GitHub 新增 Release v1.0.0

  • GitHub Release 再次觸發CI 構建生產環境用 Docker 映象allovince/drone-ci-demo:1.0.0

 

最終我們能得到這樣一個賞心悅目的 Release。 
Step.5：Kubernetes 自動釋出
Docker 映象推送到倉庫後，我們還剩最後一步就可以完成全自動釋出的閉環，即通知 Kubernetes 將映象釋出到生產環境。這一步實現比較靈活，因為很多雲服務商在容器服務都會提供 Trigger 機制，一般是提供一個 URL，只要請求這個 URL 就可以觸發容器服務的釋出。Demo 中我們使用更為通用的方法，就是將 kubectl 打包為容器，以客戶端呼叫 Kubernetes 叢集 Master 節點 API（kube-apiserver）的形式完成釋出。
假設我們在生產環境下 drone-ci-demo 專案的 Kubernetes 釋出檔案如下：
  1. ---
  2. apiVersion: extensions/v1beta1
  3. kind: Deployment
  4. metadata:
  5. name: ci-demo-deployment
  6. namespace: default
  7. spec:
  8. replicas: 1
  9. template:
  10. spec:
  11. containers:
  12. - image: allovince/drone-ci-demo
  13. name: ci-demo
  14. restartPolicy: Always
對應 .drone.yml 中增加 step 如下。這裡使用的外掛是 honestbee/drone-kubernetes， 外掛中 kubectl 連線 API 使用的是證書 + Token 的方式鑒權，因此需要先獲得證書及 Token， 已經授權的 Token 儲存於 Kubernetes Secret，可以透過 kubectl get secret [ your default secret name ] -o yaml | egrep ‘ca.crt:|token:’ 獲得並配置到 Drone 中，註意外掛要求 Token 是明文的，需要 base64 解碼一下：echo [ your token ] | base64 -d && echo ”。
  1. - name: k8s-deploy
  2. image: quay.io/honestbee/drone-kubernetes
  3. settings:
  4. kubernetes_server:
  5. from_secret: KUBERNETES_SERVER
  6. kubernetes_cert:
  7. from_secret: KUBERNETES_CERT
  8. kubernetes_token:
  9. from_secret: KUBERNETES_TOKEN
  10. namespace: default
  11. deployment: ci-demo-deployment
  12. repo: allovince/drone-ci-demo
  13. container: ci-demo
  14. tag:
  15. - ${DRONE_TAG}
  16. when:
  17. event: tag
在示例中，可以看到在語意化釋出之後 CI 會將新版本的 Docker 映象自動釋出到 Kubernetes，這裡為了演示僅列印了指令並未實際執行。相當於執行瞭如下的指令：
  1. kubectl -n default set image deployment/ci-demo-deployment ci-demo=allovince/drone-ci-demo:v1.0.2
由於自動釋出的環節勢必要接觸到生產伺服器，需要格外註意安全問題，首推的方式當然是將 CI 和 Kubernetes 叢集放於同一內網中，同時可以使用 Kubernetes 的 RBAC 許可權控制，為自動釋出單獨建立一個使用者，並刪除不必要的許可權。
後話

 

總結一下，本文展示了從 Hello World 到單人單分支手動釋出再到團隊多分支 GitFlow 工作流再到團隊多分支 semantic-release 語意化釋出最後到 通知 Kubernetes 全自動釋出，如何從零開始一步一步搭建 CI 將團隊開發、測試、釋出的流程全部自動化的過程，最終能讓開發人員只需要認真提交程式碼就可以完成日常的所有 DevOps 工作。
最終 Step 的完成品可以適配之前的所有 Step，如果不太在意實現細節的話，可以在此基礎上稍作修改，直接使用。
然而寫好每一個 Commit 這個看似簡單的要求，其實對於大多數團隊來說並不容易做到，在實施過程中，經常會遇到團隊成員不理解為什麼要重視 Commit 規範，每個 Commit 都要深思熟慮是否過於吹毛求疵等等疑問。
以 Commit 作為 CI 的核心，個人認為主要會帶來以下幾方面的影響：

  1. 一個好的 Commit，代表著開發人員對當前改動之於整個系統的影響，有非常清楚的認識，程式碼的修改到底算 feat 還是 fix ，什麼時候用 BREAKING CHANGE 等都是要仔細斟酌的，每個 Commit 都會在 ChangeLog 裡“留底”，從而約束團隊不隨意提交未經思考的程式碼，提高程式碼質量。

  2. 一個好的 Commit 也代表開發人員有能力對所實現功能進行精細的劃分，一個分支做的事情不宜過多，一個提交也應該專註於只解決一個問題，每次提交（至少是每次 push）都應該保持系統可構建、可執行、可測試，如果能堅持做到這些，對於合併程式碼時的衝突解決，以及整合測試都有很大幫助。

  3. 由於每次釋出能清楚的看到所有關聯的 Commit 以及 Commit 的重要程度，那麼線上事故的回滾也會非常輕鬆，回滾到哪個版本，回滾後哪些功能會受到影響，只要看 CI 自動生成的 Release 記錄就一目瞭然。如果沒有這些，回滾誤傷到預期外的功能從而引發連鎖反應的慘痛教訓，可能很多運維都有過類似經歷吧。

因此 CI 自動化其實是錦上添花而非雪中送炭，如果團隊原本就無視規範，Commit 全是空白或者沒有任何意義的單詞，分支管理混亂，釋出困難，奢望引入一套自動化 CI 來能解決所有這些問題，無疑是不現實的。而只有原本就重視程式碼質量，有一定規範意識，再透過自動化 CI 來監督約束，團隊在 CI 的幫助下程式碼質量提高，從而有機會進一步改進 CI 的效率，才能形成良心迴圈。
願天下不再有難釋出的版本。
Q&A;

 

Q：Kubernetes 上主流的 CI/CD 方案是啥？
A：其實這無關 Kubernetes，從市場佔有率來看，前三名分別是：

  1. Jenkins

  2. JetBrains TeamCity

  3. CircleCI

來源：https://www.datanyze.com/market-share/ci
Q：GitLab 自帶的 CI 與 Jenkins 和 GitLab 結合的 CI，該如何選擇？想知道更深層次的理解。
A：還是要結合自己團隊的實際情況做選擇。從成熟度來說，肯定是 Jenkins 使用者最多，成熟度最高，缺點是側重 Java，配置相對繁瑣。GitLab 自帶的 CI 相對簡單，可以用 yaml，和 GitLab 結合的最好，但功能肯定沒有 Jenkins 全面。如果是小團隊新專案，GitLab CI 又已經可以滿足需求的話，並不需要上 Jenkins，如果是較大的團隊，又是偏 Java 的，個人更偏向 Jenkins。
Q：Jenkins 如果不想執行在 Kubernetes 裡面，該怎麼和 Kubernetes 整合？
A：從 CI 的流程來說，CI 應用是不是跑在 Kubernetes 的並不重要，CI 只要能訪問程式碼庫，有許可權在生產環境釋出，是不是跑在容器裡從效果來說其實沒有區別，只是用 Kubernetes 部署 Jenkins 的話，運維的一致性比較好，運維團隊不用額外花時間維護一套物理機的部署方案。
Q：Kubernetes 的回滾方案是回滾程式碼，重做映象，還是先切流量，後做修改？
A：程式碼一定是打包到映象裡的，映象的版本就是程式碼的版本，所以一定是切映象。至於回滾操作本身，Kubernetes 已經內建了很多滾動釋出（Rolling update）的策略，無論是發新版本還是回滾版本，都可以做到使用者無感知。
Q：映象大到幾 G 的話如何更新部署，有什麼好的實踐呢，以及如何回滾？
A：幾個要點：

  1. 映象倉庫部署在內網，映象推拉走內網，幾個 G 的映象傳輸起來也只是秒級別的

  2. 映象構建時將不經常變動的部分劃分到 1 層，因為 Docker 映象是分層的，這樣每次拉映象可以利用到 Docker 的快取傳輸的只有映象發生變化的部分

  3. 選擇 alpine 這樣儘量小的映象

回滾如果發生在相鄰的版本，一般物理機上是有快取的，速度都很快。
Q：Drone 開放 API 服務嗎？這樣方便其他系統整合。
A：可以調整一下思路，直接把需要的功能做成映象在 Drone 裡呼叫就好了。
Q：如果有 Drone 的 Server怎麼做高可用？
A：Drone serve r用 Kubernetes 部署的話本身只起到了一個任務排程的作用，很難會遇到效能瓶頸。真的有效能問題可以嘗試水平擴充套件 Drone server，共享同一資料庫。
相關連結：

  1. https://avnpc.com/pages/android-auto-deploy-workflow-on-travis-ci

  2. https://github.com/AlloVince/drone-ci-demo

  3. https://github.com/AlloVince/drone-ci-demo/blob/master/kubernetes/drone.yaml

  4. https://docs.drone.io/user-guide/pipeline/conditions/

  5. http://plugins.drone.io/drone-plugins/drone-docker/

作者部落格：https://avnpc.com/pages/drone-gitflow-kubernetes-for-cloud-native-ci

贊(0)
標籤：

相關推薦

熱門標籤

iOS (11238)微軟 (4955)Linux (4274)安全 (4180)Python (4161)效能 (3165)運維 (2774)最佳化 (2419).NET (2262)Google (2136)機器學習 (1795)併發 (1613)分散式 (1559)叢集 (1240)SQL (1174)Mysql (1060)區塊鏈 (1017)Docker (977)微服務 (922)面試 (919)Apache (743)NLP (725)Redis (719)Android (668)Git (640)架構師 (632)Nginx (630)Facebook (599)JVM (595)爬蟲 (476)

熱門文章

分享創造快樂