一年一度的鐵人賽又開賽了,這次跟又跟幾個好朋友們組了一個奇怪的戰隊,兩個 DevOps 領域加上三個 AI/ML 領域一起努力的於這30天產出共 150 篇技術好文。
這次鐵人賽想要跟大家分享如何使用 Rancher & Rancher Fleet 來嘗試不同方式 GitOps 解決方式。
Rancher Fleet 相對於現有知名的 Flux/ArgoCD 最特別的我想莫過於其客製化應用程式的方式,其不但同時支援 Helm 與 Kustomize 這兩種格式,更可以讓兩者同時運作來達到最大客製化。
試想一下想要針對一些第三方 Helm Chart 進行客製化但是對方 values 又沒有開放時該怎麼辦,這時候就可以透過 kustomize 透過 patch 的方式來動態加入檔案或是修改欄位。
唯一遺憾的是 Rancher v2.6.0 開賽前一天才正式發布,試玩了一下不是說非常穩定,因此這30篇文章還是會基於 v2.5.9 來介紹。
歡迎舊雨新知有興趣的都可以追蹤,相關文章之後也都會發佈到自己的部落格上
https://ithelp.ithome.com.tw/users/20120317/ironman/4034
chart helm 在 矽谷牛的耕田筆記 Facebook 的最佳貼文
ref: https://itnext.io/helm-3-secrets-management-4f23041f05c3
Secret Management 的議題一直以來都是 CI/CD 流程中不可忽似的一部分,本篇文章作者不同於以往採用常見的解決方案(Hashicorp Vault, Helm Secret, SealedSecret),反而是使用 Helm 內建的 AES 加解密功能來實作 Heml Chart 資料的加解密需求。
作者認為一個良好的機密管理解決方案需要能夠為其團隊提供三個基本需求
1) 所有的機密資訊都要能夠存放到版本控制系統中(Git...etc)
2) 所有被上傳到 Chartmuseum 的 Helm Chart Package 都不能有任何 k8s secret 物件,要放的只能有加密後結果。反之使用者要使用時也必須要有能力去解密
3) 單一工具管理,以作者來說會希望能夠都使用 Helm 這個工具來處理,愈少的工具意味者依賴性愈少,同時在維護與管理上要花的心力也更少。
作者首先列舉了兩個現存的專案,分別是 Helm Secrets 以及 Hashicorp Vault 並且針對這兩者進行了簡單的介紹,並且舉出為什麼這兩個專案並不適合作者團隊的需求與使用情境。
作者最後開始認真研究 Helm 本身有什麼內建的加解密功能可以使用,最後發現 encryptAES 以及 descryptAWS 這兩個內建函式可以使用,譬如
value: encryptAES "secretkey" {{ .Values.valueToEncrypt }}
value: {{ .Values.valueToDecrypt }} | decryptAES "secretkey"
有了基本的概念與用法後,作者透過 shell script 實作一層 wrapper 來簡化整個處理流程。
最後將這些資訊也導入到 CI/CD 流程中來幫忙進行解密的相關動作,讓 CD 可以順利的將目標 Secret 給送到 Kubernetes 中。
個人心得: 採用加解密的系統個人還是喜歡採用 SealedSecret 的設計理念,將解密的時間點延後到 Kubernetes 內而並非 CI/CD 系統上,主要是 CI/CD 的 pipeline 要是沒有仔細設計其實很多人會不小心把過程命令給輸出的,這樣的話加解密的過程,使用的 Key 等都有可能會洩漏出去。
chart helm 在 矽谷牛的耕田筆記 Facebook 的最佳解答
本篇是一個新手教學文,作者分享如何撰寫一個基於 Library 概念的 Helm Chart。
Helm Chart 的使用基本上不會太困難,透過 Helm Create 也可以很輕鬆地創造出一個範例 Helm Chart,針對該 Helm Chart 簡單修改也可以變成符合使用者需求的 Helm Chart。
作者工作中遇到一個要求,該要求要將一個 mono-repo 內的所有應用程式都變成 Helm Chart 的形式,該 repo 內大概有 10 個左右的應用程式,而這些應用程式部署所需要的資源都差不多,因此最簡單的方式就是創建十個幾乎完全一樣的 Helm Chart,透過 values.yaml 來客製化每個服務即可。
不過作者認為這種做法有點痛苦,要是未來需要針對這些k8s資源加上一些定義或是一些欄位,有可能就要 Copy&Paste 十次來處理所有的 Helm Chart。
為了解決這個問題作者就嘗試創建第一個 Helm Chart Library,只要到 Charts.yaml 裏面將 type 修改為 library 即可。(一般來說是 application)
作者特別提到,Helm 在處理部署的時候,只要檔案開頭為_,則該資源就不會被嘗試部署到 Kubernetes 內,這也是為什麼預設的 helper 會叫做 _helpers.tpl。
對於開發一個供其他 Helm Chart 使用的 Library Helm Chart 有興趣的可以參考這個文來看看一個簡單的範例
https://medium.com/nontechcompany/how-i-create-my-first-library-helm-chart-4f23caf5287d