Skip to main content

4 posts tagged with "GitOps"

View All Tags

· One min read

ArgoCD 安裝方式多元化,本身有簡單部署也有 HA 狀態的部署,以下示範如何用 Kustomize 來安裝 ArgoCD 並且之後還可以用 ArgoCD 控管 ArgoCD 自己本身的設定

使用 https://github.com/argoproj/argo-cd/tree/master/manifests/cluster-install 這個簡易安裝

準備一個 kustomizatiom.yaml,然後如果想要客製化就準備其他的 yaml 來調整 最後搭配一個 Application Yaml 來控管自己

$ cat kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- https://github.com/argoproj/argo-cd/manifests/cluster-install?ref=v2.7.7

patchesStrategicMerge:
- argocd-rbac-cm.yaml
- argocd-application-controller.yaml
- argocd-applicationset-controller.yaml
- argocd-cm.yaml
- argocd-cmd-params-cm.yaml
- argocd-dex-server.yaml
- argocd-redis.yaml
- argocd-repo-server.yaml
- argocd-server.yaml
- argocd-notifications-cm.yaml

· 2 min read

標題: 「透過 Crossplane 與 ArgoCD 來達成應用程式與基礎建設的 GitOps 部署方式」 類別: cicd 連結: https://medium.com/containers-101/using-gitops-for-infrastructure-and-applications-with-crossplane-and-argo-cd-944b32dfb27e

作者表示過往很多教學文章當探討到 Kubernetes 部署議題的時候,通常都不會去探討如何部署 Kubernetes 而是專注於應用程式的部署, 理由非常直觀,文章就是要專注於 Deployment 的議題,能夠讓讀者更容易地去閱讀與參考,另外一個背後的原因其實是因為 Kubernetes 部署的方式 太多種,常見的方式使用 Terraform 透過 IaC 的概念來管理,而應用程式都使用 Helm/Kustomize 完全不同的方式來管理

而作者今天想要探討的是如何透過 ArgoCD 來建設一個 GitOps 的環境,並且於上面使用 Crossplan 這個解決方案來處理各種底層基礎建設的需求,如此一來 就可以統一透過 Helm/Kustomize 的方式來描述這些基礎建設

Crossplan 很類似 Terraform 但是有者一些些微的差異

  1. Crossplan 本身是 Kubernetes 的應用程式,所以本身的描述方式就是 Kubernetes 的 YAML 方式
  2. 可以使用 kubectl, Helm/Kustomize 等方式來部署這些描述並且讓 Crossplan 來幫忙創建描述的基礎建設

由於整個 Crossplan 可以視為一個 Kubernetes 應用程式,所以直接使用 ArgoCD 的方式來部署 有興趣的可以閱讀全問

· 5 min read

標題: 「The pains of GitOps 1.0」 類別: cicd 連結: https://codefresh.io/about-gitops/pains-gitops-1-0/

作者認為很多文章都闡述 GitOps 對於部署帶來的好處,但是軟體世界沒有十全十美的東西,所以作者就探討了 12 個其認為 GitOps 的缺點

註:

  1. 本篇文章是 2020 年底的文章,所以文章探討的內容也許當年沒有很好的解決方式,但是現在已經有了比較好的處理方式。
  2. 我個人覺得文章的某些部分有點太牽強,已經假設 GitOps 是個萬能解法,什麼問題都要靠這個。就這個問題是不管有沒有 GitOps 都會存在的問題,有點為了反對而反對,與其說 GitOps 的缺點不如說沒有解決的問題。

這邊就節錄幾個文章中探討的議題,剩下有興趣的可以閱讀全文

GitOps covers only a subset of the software lifecycle

作者認為 GitOps 的精神「我想要將 Git 專案內的所描述的狀態給同步到叢集中」這點只能處理應用程式部署的問題,但是其他的流程 譬如編譯程式碼,運行單元測試,安全性檢查,靜態掃描等過程都沒有辦法被 GitOps 給處理。

作者不滿的點主要是很多 GitOps 的工具好像都會宣傳自己是個全能的解決方案,能夠處理所有事情,但是實際上卻沒有辦法。 實際上其專注的點就是應用程式部署策略為主的部分,其餘部分還是團隊要有自己的方式去處理

Splitting CI and CD with GitOps is not straightforward

過往很多團隊都會將 CI/CD 給整合到相同的 pipeline 中去處理,通常是最後一個階段就會將應用程式給部署到目標叢集,然而有外部 Controller 實作的 GitOps 解決方案會使得 CI/CD 兩者脫鉤,好處來說就是 pipeline 不需要去處理部署,只需要專心維護 Git 內的資訊,後續都讓 Controller 來處理。

然後某些團隊本來的 CI/CD 流程會於部署完畢後還會進行一些測試或是相關操作,這部分會因為 GitOps 將部署給弄走導致整個流程不太好處理,畢竟要如何讓 GitOps 部署完畢後又要可以觸發其他的工作也是額外要處理的事情

There is no standard practice for GitOps rollbacks

雖然 GitOps 的核心是透過 Git Commit 去控制當前部署的版本,那發生問題時到底該怎麼處理,如何去 rollback? 作者舉兩種範例

  1. 讓 GitOps 去指向之前的 Git Commit
  2. 針對 Git 使用 Git revert 等相關操作來更新最新的內容 作者認為沒有一個標準來告訴使用者該怎麼使用以及處理

Observability for GitOps (and Git) is immature

作者認為目前現有的 GitOps 工具都沒有辦法提供下列答案

  1. 目前生產環境是否有包含 Feature X
  2. Bug X,Y 是否只有存在於 Staging 環境? 還是生產環境也有?

註: 有什麼概念是天生就可以有這些東西的..? GitOps 有點無妄之災

· 2 min read

連結: https://adam-toy.medium.com/implementing-gitops-on-kubernetes-using-k3s-rancher-vault-and-argocd-f8e770297d3a

這邊跟大家分享一篇 GitOps 實作心路歷程,這篇文章中總共使用下列工具

  1. AWS, 所有環境都基於 AWS 此 cloud provider
  2. K3S, 一套由 Rancher 開發的輕量級 Kubernetes 發行版本
  3. Rancher, 管理 K3S 介面
  4. Cert-Manager, 與 Let's Encrypt 連動,管理相關憑證
  5. Vault, Secret 管理工具
  6. ArgoCD GitOps 使用工具,連動 Git Repo 與 K8s
  7. Terraform, IaaC 的一種工具 這篇文章從頭開始介紹如何整合上述工具,並且完成一個簡易的範例,透過這些範例也讓你理解每個元件對應的功能,如何使用,共重要的是從一個大範圍的視角來看,這些元件的地位,更可以幫助你瞭解整體架構 有興趣的可以閱讀全文