Add ArgoCD Deployment for GitOps Workflow

[vikramreddym]

What?

This PR is regarding the issue #45. In this PR, argocd application is created using app of apps pattern for self managing argocd in a declarative gitops way. There is also folder structure setup in-place so that future additions of argocd applications will be easier. README.md file is added for documentation which details the creation of argocd deployment manually for initial setup and then switching to gitops self-managed method.

Directory structure:

argocd
├── apps-children
│   └── argocd-app.yaml
├── values
|   └── values.yaml (This file is only used for manual initial setup. Any future changes to be done in argocd-app file)
├── manifests
└── root-app.yaml

Why?

This PR addresses the issue #45. Changes are done to enable gitops workflow using argocd. App of apps pattern becomes necessary because without it, the changes to argocd-app.yaml needs to be applied imperatively using kubectl command as the argocd-app.yaml uses helm chart of argocd to deploy it.

How?

This uses app of apps pattern for self managing argocd. We first set it up manually for initial setup and then switch to declarative gitops way to manage argocd.

1. Manual setup

cd argocd
helm repo add argo https://argoproj.github.io/argo-helm
helm repo update
helm install argo-cd argo/argo-cd --version 7.7.15 -n argocd --create-namespace -f values/values.yaml

2. Switch to declarative self-managed way:

k apply -f root-app.yaml -n argocd 
kubectl delete secret -n argocd -l name=argo-cd

Testing

Make sure kubectl, argocd cli, k8s cluster with atleast 3 worker nodes and helm cli are installed.

Quote from artifacthub

Warning: You need at least 3 worker nodes as the HA mode of redis enforces Pods to run on separate nodes.

0. Modify the root-app.yaml and replace repoUrl with my repo url and targetRevision by a new branch name. create a new branch off of 'feature/argocd-gitops-setup' branch. (We can delete the branch later). :

source:
  repoURL: https://github.com/vikramreddym/kubecraft.git
  targetRevision: <newbranch>
  path: "./argocd/apps-children"

Execute commands from the How? section above. Then proceed to step 1.

1. Get password for ui server
   kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

2. kubectl port-forward service/argo-cd-argocd-server -n argocd 8080:443. Access the page at http://127.0.0.1:8080

3. argocd login localhost:8080

4. argocd app list

5. helm list -n argocd will no longer show the original release it created.

6. Make a change to the targetRevision version specified in argocd-app.yaml and commit to github. Argocd will automatically synchronize the change. UI server will be down briefly. Re-run port forward command again to access the UI page.

---

Screenshot:

Something similar should be seen:

Anything else?

• Found this while researching but need to explore further: https://github.com/argoproj-labs/argocd-autopilot

• Found a two stage approach implemented here: https://github.com/axivo/k3s-cluster

Chatgpt summary:

Two stage approach:

Stage 1 (Base Layer via Flux): Use Flux to install the foundational components. For example:

• Sealed Secrets (for managing secrets in a GitOps-friendly way)
• Ingress controllers (like nginx or Cilium Gateway API)
• Load balancers (like MetalLB)
• Argo CD itself

Stage 2 (Remainder via Argo CD): Once those base components (including Argo CD) are deployed, Argo CD takes over to manage and continuously synchronize all the additional Kubernetes resources for the rest of the cluster.

In other words, the “approach” is:

Flux bootstraps the minimal infrastructure required for the cluster (including Argo CD), and then Argo CD takes charge of deploying and managing every other workload or Helm chart in the cluster.

[mischavandenburg]

Hi Vikram, this is great work!

I have a couple of points:

I was reading through this article, where they suggest a repo structure and application sets.

https://codefresh.io/blog/how-to-structure-your-argo-cd-repositories-using-application-sets/

https://github.com/kostis-codefresh/many-appsets-demo/tree/main

Would it be possible to restructure and rename it according to this?

Also, I'm thinking that we will be using a single node cluster for a while. The HA can stillb e in the documentation, but can you adjust the manifests for a normal single deployment?

Thank you