For about one month, from 2023 to 2024, I worked with the GitOps process and learned something new about DevOps. Even though it's not entirely new, I would like to share my progress while working on the project.
ArgoCD: The magical wand to deploy K8s Cluster
Currently, I am working on tasks related to Continuous Delivery (CD) using ArgoCD. ArgoCD is an open-source software (OSS) created by the community and now adopted by the Linux Foundation under the Cloud Native Computing Foundation (CNCF).
For my task, I am researching the GitOps workflow used at my office.
The process can be described as follows:
The Apps it self will fetched by ArgoCD then deploy to the Kubernetes Cluster on the same namespace that will managed by ArgoCD.
Why the apps was blocked in one single folder to deploy all? because I’m using the patterns from ArgoCD which is the process to specify the ArgoCD apps consists with only the other apps. In the term of the Apps-of-Apps patterns which you can also check in this link below how the process and what requirements of this apps:
Specifically, you only use 1 file to declare the apps, then ArgoCD will scan all from the specified path that used for check the apps.
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: application-root
# You'll usually want to add your resources to the argocd namespace.
namespace: argocd
# Add this finalizer ONLY if you want these to cascade delete.
finalizers:
- resources-finalizer.argocd.argoproj.io
# Add labels to your application object.
labels:
name: application-root
spec:
# The project the application belongs to.
project: default
# Source of the application manifests
source:
repoURL: git@github.com:rizkyfaza20/api-laravel-test-sre.git # Can point to either a Helm chart repo or a git repo.
targetRevision: master # For Helm, this refers to the chart version.
path: argocd/apps # This has no meaning for Helm charts pulled directly from a Helm repo instead of git.
# Destination cluster and namespace to deploy the application
destination:
server: https://kubernetes.default.svc
# The namespace will only be set for namespace-scoped resources that have not set a value for .metadata.namespace
namespace: argocd
# Sync policy
syncPolicy:
automated:
prune: true
syncOptions: # Sync options which modifies sync behavior
- Validate=false # disables resource validation (equivalent to 'kubectl apply --validate=false') ( true by default ).
- CreateNamespace=false # Namespace Auto-Creation ensures that namespace specified as the application destination exists in the destination cluster.
- PrunePropagationPolicy=foreground # Supported policies are background, foreground and orphan.
- PruneLast=true # Allow the ability for resource pruning to happen as a final, implicit wave of a sync operation
# The retry feature is available since v1.7
retry:
limit: 5 # number of failed sync attempt retries; unlimited number of attempts if less than 0
backoff:
duration: 5s # the amount to back off. Default unit is seconds, but could also be a duration (e.g. "2m", "1h")
factor: 2 # a factor to multiply the base duration after each failed retry
maxDuration: 3m # the maximum amount of time allowed for the backoff strategy
revisionHistoryLimit: 10
What makes this tools useful its capability to pull every changes from Git repository which the base on the ArgoCD itself GitOps process that makes declarative for Kubernetes Deployment.
How do I approach the process of GitOps using ArgoCD?
After researching how to use ArgoCD for app deployment, I created some samples. For readers who want to manage this process, you can check out my GitHub repository:
The repository is named API Laravel SRE Test. It serves as my playground to manage applications deployed to Kubernetes using automation, without needing to be too involved from the start.
Except from the other of my script which that is :
.
├── application-argocd.yaml
├── apps
│ ├── application-laravel.yaml
│ └── application-nginx.yaml
These three files I shared with my colleague show how to synchronize all services without managing them manually. It all starts with one simple command.
Step 1: Install the ArgoCD Server
You can install it on your local machine or in your cloud environment (EKS, GKE, AKS, etc.). You can skip this step if you already have a Kubernetes Cluster. To install ArgoCD:
kubectl apply -f <https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml>
After that, you will have a list of Policies, Deployments, Services, ReplicaSets, etc.
Once you are done with that, since I deployed it locally, try accessing the UI:
kubectl port-forward svc/argocd-server <port you want to expose>:443
This will give you the login page of ArgoCD. Retrieve the initial password for your ArgoCD Dashboard.
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; ec
And now you're logged into the account. The username is admin.
Step 2: Deploy the root application
So, from my point of view, the Application Root is where all applications deployed to ArgoCD are managed. This setup allows for the automation of deploying all services without manually applying or adding them via the dashboard.
In my case, I executed the application-argocd.yaml file.
kubectl apply -f argocd/application-argocd.yaml
The logs will display messages such as “applications.argoproj.io/application-root unchanged” or indicate changes or deployments that haven't been done before. This execution will show the services we created earlier using Helm Charts.
This method was shared with me by a senior DevOps engineer who manages around 50-100 pods with ArgoCD. From what I've seen, the complexity of deploying to Kubernetes can be simplified by automating the process itself.
I haven't prepared a list of cons yet, but in future posts, I will try to research the downsides of managing with the CRD Manifest of ArgoCD. If you have any questions or inquiries about the project, please don't hesitate to comment or reach out to me through one of my social badges.
See you in the next blog! :3