Argo-CD for Beginners

This blog is simply a piece of me documenting my own learning as I embark on my journey into DevOps as a very basic beginner in this new adventure. However, if anyone finds this helpful, I would be overwhelmed with gratitude. This blog is specifically for those learners who just got into DevOps and who have just grasped the fundamentals of deploying a cluster in a local, cloud, or playground environment like Killercoda Kubernetes. Having gained a basic understanding of Kubernetes, this blog can serve as your next step to set out to explore the world of continuous delivery (CD) and its practical applications.

As a beginner taking my first steps into the world of DevOps, I've created this blog to document my learnings about continuous delivery (CD) and its practical applications. While it is not a comprehensive guide from a professional perspective, it aims to provide a foundation of as i understood CD so lets begin.

If you've explored DevOps, you've probably seen the infinity symbol like above with 'CI/CD' on it. This symbol represents the core of DevOps: continuous integration (CI) and continuous delivery (CD). CI/CD automates software development and deployment, making it faster and more reliable.

CI/CD breaks down the walls between development and operations teams, ensuring that quality is built into software from the start. It allows developers to focus on innovation while operations teams focus on infrastructure. CI/CD makes software development a continuous process, not a series of isolated events. It ensures that code changes are smoothly integrated, tested, and deployed without disrupting the software delivery cycle.

Let me explain what it really means using an example

Picture a widely used application that undergoes continuous improvements. Traditionally, developers would manually test each improvement by loading it onto servers, building it, and monitoring its performance. This process, often managed by a maintainer, could be tedious and time-consuming, delaying the deployment of new features to users.

CI/CD streamlines this process by automating the build, test, and deployment phases:

Continuous Integration (CI) focuses on the development stage, where code changes are automatically integrated and tested whether they are working or not or are breaking the application. Tools like GitHub Actions facilitate this automation, ensuring that code changes don't break the application without even manually watching for it and also avoiding possible human error.

Continuous Delivery (CD) handles the deployment stage, seamlessly releasing new versions of the application to production environments. For example, tools like Argo CD monitor Git repositories for changes and trigger automated deployments, ensuring that users always have access to the latest features. So as soon as the new feature is added it is deployed into the environment.

In simple terms, CI/CD is the driving force behind DevOps, making it more agile, and reliable, and continuously improving software development and delivery.

While continuous integration (CI) and continuous delivery (CD) are often integrated and implemented together, we'll be focusing on the CD aspect in this discussion. However, to maintain contextual consistency, we'll assume that GitHub Actions is being used for CI. This approach effectively automates the build, test, and deployment processes, paving the way for seamless continuous delivery using Argo CD. While a multitude of continuous delivery (CD) tools exist in the market, such as Jenkins, which encompasses both CI and CD capabilities or newer offerings like Flux, we'll be focusing on Argo CD for this discussion.

Why Argo CD?

While each platform it's own ups and downs, using Argo CD is a good choice due to its advantages like

Kubernetes Integration: Argo CD seamlessly integrates with the Kubernetes ecosystem, eliminating the need for additional infrastructure like Jenkins.
Real-time GitOps Synchronization: Argo CD embraces GitOps principles, ensuring that the desired state of your application, defined in Git, is continuously synchronized with the actual state of your Kubernetes cluster. This real-time synchronization guarantees that your cluster always reflects the latest changes from your Git repository. This topic will be covered extensively in the next part
Automated Rollbacks: Argo CD automates the rollback process, effortlessly reverting to a previous state if a deployment fails. This automation contrasts with Jenkins, which requires manual or complex procedures for rollbacks, making error recovery more streamlined and efficient.
User Interface: Argo CD boasts a user-friendly interface that simplifies application management.
Multi-tenancy Support: Argo CD supports multi-tenancy, enabling the management of multiple applications within a single cluster
Active Community: Argo CD benefits from an active and growing community that continuously contributes to its development, support, and feature enhancements.

1. Creating a Kubernetes Environment and Installing Argo CD

I will be covering two different deployment options

Minikube - local cluster
KIllercoda - Playgrounds

Lets cover one by one:

Minikube: To setup a cluster locally we can use Minikube and many new learners are familiar with it or even using it now while leaning Kubernetes basics. Here is the setup link if you have not setup a local cluster or if you try it out setup is very easy you need docker to be installed and you can follow up their docs its just amazing https://minikube.sigs.k8s.io/docs/start/.

Installing Argo-CD on Minikube:
1. Get your Minikube ready with
  
  minikube start
2. Create a namespace named argocd kubectl create namespace argocd
3. Now to install argo cd run the command kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
  
  This is a direct download from the GitHub repo of Argo-CD to the Kubernetes environment. As a point mentioned earlier Kubernetes Native we can see deploying Argo-CD is also similar to deploy a pods in a cluster.
  
  These instructions are from the official docs of Argo-CD you can explore it too.
4. Make sure all the pods are running it may take few minutes to get all pods ready
KillerCoda Environment: Elevating the experience, KillerCoda presents an exceptional alternative. No need to fuss about installing Argo CD separately; KillerCoda offers a pre-configured Argo CD ready for immediate use. This convenience makes it an excellent choice, especially for learners like us. A heartfelt shoutout to KillerCoda for making our learning journey smoother! You can just find Argo CD environment and select playground and Argo CD will be ready for you ,it may take some time to get all pods ready.

2.Accessing Argo-CD UI

Killer coda playground provides you the link directly on the left panel to access the Argo-CD UI if you click the link it will direct you directly to the UI page

In Minikube, it's necessary to port forward the Argo CD service to localhost on port 8080 for accessing the Argo CD UI. First, let's inspect the services within the Argo CD namespace: kubectl get services -n argocd

Upon executing this command, we observe the presence of an Argo CD server.We can see that it is currently operational and bound to TCP port 443. To establish a connection with the Argo CD UI, we initiate port forwarding from the server 443 to our localhost 8080 and we can access using a browser:

You can copy the following address, 127.0.0.1:8080, and paste it into any browser. The browser may display a warning indicating that the website is not secure because it lacks HTTPS. However, it is safe to proceed since this is a local service. Simply proceed to the website by ignoring the warning. Upon entering the address 127.0.0.1:8080 in your browser, you should encounter a page resembling the following:

Do use another instance or window of terminal for further process as current terminal will be port forwarding

3.Getting User id and Password

This step is common for both Minikube and Kubectl. By default, the username will be "admin." However, it's important to note that the password is unique each time a new argo-cd environment is introduced it manages and is stored in a secret

To retrieve the password, execute the following command on macOS or Linux:

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 --decode && echo

Note: there will be a $ or # symbol as last character so do remember to exclude that character in mac or linux

However, if you're using Windows PowerShell, the base64 decoding might not work as expected. As an alternative, you can use the following command to obtain the encoded password:

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}"

After running this command, you can copy the encoded password and decode it using any online Base64 decoder.

Once you have retrieved the decoded password, you can use the following credentials to log in to the Argo CD UI:

Username: admin
Password: [Use the decoded password]

Enter these credentials when prompted, and you should gain access to the Argo CD UI.

4.Creating `application.yaml` to Configure Argo CD Application:

Although our Argo CD application is currently operational, we need to configure it to monitor changes in a Git repository. Argo CD embraces the principle of Git as the single source of truth. This means that any attempts to modify deployments or clusters directly will be overwritten by Argo CD to adhere to the Git specifications. This approach serves as a safeguard, ensuring that changes can only be made by updating the Git repository. Moreover, it facilitates tracking of changes by identifying the contributor.

Enforcing this methodology not only restricts direct access to the cluster but also establishes a unified source of truth. If immediate changes are necessary, they can be made directly but require special access privileges. This Git-centric approach not only enhances security but also promotes transparency and accountability in managing the cluster configuration

Lets create a application.yaml to figure our Argo-cd application

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-argo-application
  namespace: argocd
spec:
  project: default

  source:
    repoURL: https://github.com/gowdaganesh005/Argo-cd.git
    targetRevision: HEAD
    path: dev

  destination:
    server: https://kubernetes.default.svc
    namespace: my-server

  syncPolicy:
    automated:
      prune: true
      selfHeal: true

    syncOptions:
      - CreateNamespace=true

apiVersion: This is a Argo project so argoproj.io/v1alpha but before using it we must always check for the current available version in the docs.
kind:Argo CD is an application
metadata:

name :name for the Argo CD is given

namespace : application is created in argocd namespace
1. spec:
  1. project: set to default
  2. source:

This section specifies the repository that argocd needs to monitor

repoURL: it should contain the repository address.

I have a GitHub repository that contains a copy of this application YAML and a 'dev' folder with a sample YAML file for the deployment of the Nginx image

If you want to use this repository, you can simply fork it and leverage it for learning purposes.

The targetRevision is set to 'HEAD,' indicating that Argo CD will monitor changes made at the head of the repository. In simpler terms, this corresponds to the latest changes or the main, top revisions

We've specified the path as 'dev' since our deployment.yaml resides in the 'dev' folder. This ensures that Argo CD accurately locates and deploys our configurations from this designated directory.

destination field plays a crucial role in pinpointing where these changes should take effect. The server parameter serves as the address, much like the IP of the cluster. Since Argo CD is native to the cluster, it cleverly utilizes an internal service, specifically, https://kubernetes.default.svc. This service provides the internal IP address, ensuring seamless communication within the cluster. Additionally, the namespace parameter ensures that these changes are executed within the specified namespace, orchestrating a tailored impact

Note: Argo CD boasts the capability to manage multiple clusters, even while residing within a single cluster. In such scenarios, you can specify the IP addresses of these clusters to ensure seamless coordination and control. This flexibility allows Argo CD to efficiently orchestrate changes across diverse environments, providing a versatile solution for cluster management
syncPolicy field in Argo CD helps configure how synchronization operates in our application. It offers two options: 'manual' for hands-on control and 'automated' for Argo CD to take care of things.

To strike a balance, we need to set some ground rules. Firstly, there's 'prune,' set to 'true.' This makes sure Argo CD automatically removes things not found in the Git repository, keeping it clean.

Additionally, there's 'selfHeal,' also set to 'true,' allowing Argo CD to automatically adjust configurations in the cluster based on the Git specs.

These configurations help keep the synchronization process smooth, letting Argo CD manage changes efficiently while ensuring Git and the cluster are on the same page.

One might wonder why we need to specify these settings every time. Well, consider this – if 'prune' or 'selfHeal' were always set to 'true' by default, it could unintentionally delete crucial files, leading to potential disasters. By explicitly defining these configurations, we ensure a deliberate and cautious approach, preventing any inadvertent mishaps in our Argo CD operations.

In the earlier discussion about the destination field, we highlighted the importance of specifying the namespace for our deployment. But what if that namespace doesn't exist yet? To address this, we can enable Argo CD to automatically create the namespace for us. This can be achieved by setting the syncOptions - CreateNamespace to 'true'. With this configuration, Argo CD takes the initiative to create the necessary namespace if it doesn't already exist, ensuring a seamless and automated setup process.

Well this ends the application.yaml

This is the copy of the deployment.yaml which is an easy and simple example deployment manifest file

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: my-server
  name: my-server
spec:
  replicas: 5
  selector:
    matchLabels:
      app: my-server
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: my-server
    spec:
      containers:
      - image: nginx

        name: my-server
        resources: {}
status: {}

This is just a basic demonstration example deployment

5.Applying application.yaml

We are ready to apply your Argo CD application YAML file once that is we just need one kubectl apply more that is all set to Argo-CD application. Once applied, Argo CD will take care of the ongoing synchronization and deployment tasks.

kubectl apply -f application.yaml

Once applied you can see your deployment to be created in the UI

The Argo CD UI offers additional features, providing in-depth information and functionalities that truly showcase its seamless integration with Kubernetes.It also allows you to check information about each individual pod.

6.Making changes to the deployment using the Git repository to demonstrate continuous delivery.

Let's consider a scenario where a developer makes changes to the deployment.yaml file, such as updating the pod images or adjusting the number of replicas. These modifications are performed using continuous integration (CI), where the changes undergo automated CI operations and successfully pass all tests. The updated deployment.yaml is then pushed to Git. Now, we aim to demonstrate how Argo CD applies these changes to the cluster, showcasing the seamless integration between CI and continuous delivery with Argo CD.

Note: As demonstration purpose I directly made changes in my repository but in real life changes are pushed using CI

I have changed the number of replicas to 10 in deployment.yaml and committed the changes to the repository.

Despite making changes, immediate results may not be apparent, as observed in the current state where the number of pods remains 5 and does not gets scaled to 10. This delay is attributed to Argo CD's behavior—it doesn't check for changes instantaneously upon every push. Instead, it operates on a periodic schedule, checking for modifications every 3 minutes. However, in practice, response times may vary, and it's not uncommon to experience a delay of 5 to 8 minutes or more.Unfortunately, I don't know the reason.

After syncing and new pods are created as per the changes in Git

In this manner, Argo CD automatically applies all changes from the Git repository to the cluster, ensuring seamless integration and effortless synchronization.

In conclusion, our hands-on demonstration of Argo CD has provided a profound insight into the world of continuous delivery (CD) within Kubernetes. By orchestrating a simple deployment, we've experienced firsthand the dynamic capabilities of Argo CD and gained a tangible understanding of what continuous delivery truly entails. The journey began with the configuration of an Argo CD application, where we meticulously defined sources, destinations, and synchronization policies to establish a streamlined connection between our Git repository and the Kubernetes cluster.

Throughout this exploration, the feeling of empowerment and excitement became palpable. Argo CD emerged not just as a tool but as a powerful ally, streamlining and automating the continuous delivery process. The ability to witness these mechanisms in action, from configuration to deployment, has offered a deeper appreciation for the robust capabilities that Argo CD brings to the Kubernetes ecosystem. This hands-on journey was not just an educational experience; it was a thrilling and empowering dive into the heart of modern continuous delivery practices.

As we wrap up this blog, a big shout-out to each and every one of you awesome readers! Thanks a bunch for spending your valuable time diving into the world of Argo CD with me. It's been a blast going through the ins and outs of this cool tool—from setting things up to watching it in action.

If you liked the blog, give it a thumbs up! Follow on Twitter

Thanks a lot and catch you in the next one

#ArgoCD #WeMakeDevs #Kubernetes #ArgoCD

Introduction to CD using ArgoCD : Basic Guide to understand what CD really means for Beginners