本篇文章是一個入門文章,主要探討 GitOps 相關的起源與概念,同時介紹不少關於 GitOps 的工具
起源: Weaveworks 於 2017 年針對 Kubernetes 的工作環境產生了不同的部署方式,而 GitOps 這個詞也就那時開始萌芽發展
概念: 透過 Git PR 的方式來驗證與自動的部署所有與系統有關的修改。今天有任何部署的需求時,團隊要做的事情就是 1) 產生 Git PR 2)進行 Review 3) 合併 接者就是等任何修改被自動部署
Git 於整個環節中扮演者 Single Source of Truth 的角色,所有的修改都必須發生於 Git 本身,也因為是基於 Git 來使用,所以不論是 GitHub, Gitlab, Bitbucket, Gerrit 等系統都可以使用。
註: Bitbucket 還針對 GitOps 這種形式取了一個名為 BDDA 的名稱,意義為 Build-Diff-Deploy-Apply
好處:
1. 稽核性: 透過 Git 可以針對所有的修改去查閱,知道誰於什麼時間點進行什麼修改
2. 由於不需要將 Kubeconfig 等資源放到外部叢集,資安方面會比傳統外部直接Push/Apply 來得更好
3. 開發人員可以更容易地去部署應用,不需要仰賴Ops幫忙
4. ...etc
註: GitOps 並不是只能適用於 Kubernetes 本身,事實上整個系統架構都可以套用這種方式,譬如搭配 Terraform 等相關的 IaC 工具時,就可以透過 GitOps 來搭建整個系統,包含底層架構,k8s叢集以及最重要的應用程式
相關工具(文章列出滿多工具):
1. ArgoCD
2. Atlantis: Terraform PR 的自動化工具
3. Autoapply
4. CloudBees Rollout
5. FlexCD
6. Helm Operator
7. Flagger
8. Ignite
9. Faros
10. Gitkube
11. Jenkins X
12. KubeStack
13. Weave Cloud
14. Werf
15. PipeCD
https://medium.com/searce/gitops-the-next-big-thing-for-devops-and-automation-2a9597e51559
deploy程式 在 矽谷牛的耕田筆記 Facebook 八卦
今天這篇文章要來跟大家分享幾個好用的小工具,能夠增加開發人員與維運人員日常工作的效率
Lens 這套工具提供一個基於 GUI 介面的 Kubernetes 管理工具,如果你需要同時管理多套 Kubernetes 叢集,那使用這類型的工具可以幫助你更快速的進行日常工作。類似的專案還有知名的 k9s 等。
我認為這類型專案提供最大的好處就是當 Pod 內有多個 containers 時,這時候不論是log或是exec都需要用 -c 去指定特定的 container。使用原生的 kubectl 很大的問題是有時候根本不記得這些 container 的名稱,都需要用額外的指令去掃出相關的名稱。使用這類型的工具可以很快速地檢視有哪些 container 並且進行後續處理,甚至連 init-container 都可以方便觀看
CLI 工具系列包含大家常見的 kubectx, kubens 及 krew 打造的 plugin 管理系統外,還有 kubectl-neat, kube-no-trouble 等
其中 kubectl-neat 也可以整合到 kubectl 指令中,其目的是透過 kubectl get 可以得到當初真正部署的資源樣貌,幫你移除那些由 controller 動態加入的欄位,譬如 creationTimestamp 等
kube-no-trouble 則是幫你掃描是否有使用到任何被標示為 deprecated API,升級 Cluster 運行此工具進行檢查可以避免升級後有些資源不能使用而造成應用程式損毀。
Kube Forwarder 是一個GUI工具,如果你平常工作非常仰賴 kubectl port-forward 的話,推薦使用看看這個工具,可以幫助你管理多個 kubectl port-forward 的設定,特別是當你要針對多套 k8s cluster 不停切換時,使用這個工具會幫你減省不少時間。
文章中還有探討一些安全性相關的工具,譬如 Polaris, Kube-hunter, Kube-bench, Trivy, Goldlocks 等。有興趣的人閱讀全文並且根據需求去嘗試看看囉
https://yitaek.medium.com/useful-tools-for-better-kubernetes-development-87820c2b9435
deploy程式 在 矽谷牛的耕田筆記 Facebook 八卦
本篇文章著重於 Terraform 的實戰使用,將 Terraform 這種 IaC 的工具給整合到 Pipeline 系統中,透過 CI/CD 的概念讓 Terraform 來幫基礎建設達到自動更新。
作者使用 Azure 雲端環境作為範例,搭配 Azure DevOps 與 Terraform 來搭建出基於 Infrastructure 的 CI/CD 實作範例。
以下節錄自文章結論
1. 除了 Terraform 之外,其他的 IaC 工具譬如 Ansible, Pulumi 等也都可以搭建出這種 IaC x CI/CD 的模式,當然大部分的雲端服務商也都沒有問題。作者列出了這種模式下帶來的好處
2. 針對 Infrastructure 的改變,可以更輕鬆的再測試環境測試,而且整個架構也相對於彈性,可以加入更多的測試來確保架構改變後,整體服務不受影響
3. 透過測試的步驟,可以確保任何失敗的修改都只會停留在 Testing 的環境,而不會直接更新正式生產環境。
4. 透過 pipeline 的架構,更容易實現 Singe source of truth 的精神,所有 Infrastructure 的修改都要從程式碼著手,並且經由 Review 來確保品質,同時當正式生產環境有出現問題時,也更容易地去發覺到底是什麼修改造成問題。
5. 程式化的執行減少的人員操作的失誤,同時也提供了運行結果的一致性,未來有問題發生時都可以重複執行pipeline來除錯與驗證。
https://blog.ardanis.com/ci-cd-for-infrastructure-7d9553b32be0
deploy程式 在 如何託管及部署你的前後端應用程式(React、Node.js Express 的八卦
如何託管及部署你的前後端應用 程式 (React、Node.js Express、GraphQL) ... Deploy to Production - Node, Postgres, Redis, React - with Render. ... <看更多>
相關內容