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

標題: 「透過 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 的方式來部署 有興趣的可以閱讀全問

標題: 「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 有點無妄之災

連結: 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 的一種工具 這篇文章從頭開始介紹如何整合上述工具，並且完成一個簡易的範例，透過這些範例也讓你理解每個元件對應的功能，如何使用，共重要的是從一個大範圍的視角來看，這些元件的地位，更可以幫助你瞭解整體架構 有興趣的可以閱讀全文