Skip to content

Latest commit

 

History

History
121 lines (58 loc) · 6.27 KB

day13.md

File metadata and controls

121 lines (58 loc) · 6.27 KB

Day13 - CD 系統的選擇議題

本文將於賽後同步刊登於筆者部落格 有興趣學習更多 Kubernetes/DevOps/Linux 相關的資源的讀者，歡迎前往閱讀 更多相關科技的技術分享，歡迎追蹤 矽谷牛的耕田筆記

前面幾篇文章我們在探討 CI 與 Kubernetes 的整合，當 CI 完成，一切準備就緒後，下一件事情就是 CD，如何將開發者修改後的結果透過 pipeline 系統給推入到 Kubernetes 叢集中

這過程中有非常多的議題可以探討，舉例來說

  1. 要使用 Pipeline 系統加上客製化腳本來部署，來是使用專門處理 CD 過程的軟體

  2. 要用什麼工具來管理 Kubernetes 應用程式，對於不同環境所需要的客製化參數，要如何準備並且部署到遠方 Kubernetes

  3. 要如何實現藍綠部署，金絲雀部署等

  4. 如果環境中有機密資訊，譬如資料庫密碼等，要如何於 CD 過程中準備與部署

上述每個問題的坑都很深，我們接下來的文章會盡量探討每個層面的細節以及有什麼樣的開源軟體可以處理。

CNCF 技術雷達

本篇文章我們先來探討第一個問題，到底系統該怎麼選擇? 我們先來看看由 CNCF End User Techonlogy Radar 所發佈的 CD 調查報告, 其中我們擷取一張重點圖片即可

想看完整報告的解析版本可以參考CNCF Continuous Delivery 使用者調查報告

這張圖片是根據 CNCF 的使用者廠商投票回報，大家在 CD 的過程中會使用哪些工具，對這些工具是否推薦大家去使用

雷達圖片由內到外，代表推薦程度，愈靠近圓心代表推薦程度愈高

應用工具包裝與部署

首先，雷達圖片中有三個工具在描述上述的問題 (2)，分別是 Helm, Kustomize,jsonnet，剛好推薦信心也是按照這個排序

最多廠商選擇使用 Helm ，再來是 Kustomize 以及 jsonnet。

我個人的經驗會根據情況使用 Helm 以及 Kustomize，比較不會使用 jsonnet，覺得帶來的效益跟並不是很大，

部署平台/策略選擇

再來上圖中剩下的技術都跟 CD 部署有關，其中 Flux 以及 ArgoCD 這兩個主要是主打 GitOps 的部署工具，本身沒有任何流水線的設計，完完全全就是針對部署去設計的，之後也會有章節再探討 GitOps 的概念與示範。

剩下的平台基本是都有提供 Pipeline 系統來處理，這部分有開源軟體，也有 SaaS 軟體，這之中包含了

  1. CircleCI
  2. GitLab
  3. Jenkins
  4. Jenkins X
  5. Github Action
  6. TeamCity
  7. TravisCI

從使用者廠商回報的結果來看， CircleCI 以及 Gitlab 比較有明確的共識，推薦大家使用，其他的內容包含

  1. Github Action 擁有完全正面的回饋，只是正式使用的數量還不夠多

  2. Jenkins 則是一面倒，擁有數量不少的推薦數量，但是也有最高票的強烈不推薦票

    眾多人的意見表示，對舊有系統來說 Jenkins 已經運行的很好了，但是對於全新的系統會願意嘗試不同的系統，而非使用 Jenkins。

所以針對 (1) 到底該怎麼選擇？ 這部分我認為目前有兩個主流，一個就是透過 Pipeline 系統直接與 Kubernetes 叢集互動，另外一個則是透過 GItOps 的概念讓 Kubernetes 叢集自己更新，不仰賴額外的 Pipeline 系統。

接下來我們這兩種概念都會去探討，並且介紹這兩種概念下可能的部署流程會長怎樣。

部署策略

這部分要探討的主要是部署過程中，你要如何將新的應用部署到生產環境，同時對系統以及使用者造成的影響最少，這部分有不少的流派在跑，譬如說

  1. Recreate 這是個最簡單的策略，將舊版本全部移除，接者部署新版本。這種策略下的 downtime 取決於舊版本移除的時間以及新版本的部署時間

  2. Ramped 透過 one by one 的替換策略，每次都會部署一個新版本的實體，透過 load-balancer 確認該新版本實體可以接受到網路流量且正常運作後，就會把舊版本的一份實體移除，反覆執行直到舊版本全部結束。

  3. Blue/Green 相對於 Ramped 部署， BG 部署則是一口氣部署全部的新版本實體，譬如 3 份副本，部署完畢且測試完成後，一口氣將所有流量導向新版本，並且移除舊版本。

  4. Canary Canary 強調的是逐步切換的概念，首先一口氣部署全部的新版本實體，接下來透過 load-balancer 的方式與權重的設定，慢慢的將流量從舊版本導向新版本，譬如 90%:10% -> 80%:20% -> 50%:50% -> 10%:90% -> 0%:100% 這樣的進展

  5. A/B testing 這種部署策略更大的應用是商業上的判斷，最常見的就是針對不同使用者給予不同的介面，譬如 Facebook 每次升級新版本的時候，都會有一部分的使用者開始使用新版本，而剩下的依然使用舊版本。其運作邏輯跟上述的 Canary 部署雷同。

  6. Shadow 這個版本的部署也是新部署版本的全部實體，接下來針對所有流向舊版本的流量都複製一份，將其送到新版本去跑，當一切都沒有問題後才會移除舊版本。

更多詳細的介紹可以參閱這篇文章 Six Strategies for Applications Deployment

實際上這些策略跟你使用的 CD 工具會有很大的關係，礙於每個工具的技術與架構，並不是上述所有策略都可以輕鬆的於任何架構中實現

機密資料控管

最後一個要探討的問題就是機密資料管理，舉例來說，今天要部署一款新的應用程式到 Kuberntes 叢集中，而該應用程式需要知道資料庫的帳號密碼，假設今天使用的是 Helm 的方式來部署。

雖然 Helm 有提供 --set, values.yaml 的方式來客製化內容，但是要如何在 CD 的過程中取得這些機密資料並且部署到 Kubernetes 內，同時又不希望有任何的地方可以看到這些機密資料的明碼。

這部分之後的章節會再來仔細探討相關議題以及一些解決方案