DEV Community: Soram Varma

"Argo CD: A GitOps Tool for Kubernetes Continuous Deployment"

Soram Varma — Sat, 22 Mar 2025 14:56:56 +0000

Introduction

In modern DevOps practices, ensuring seamless and automated deployments for Kubernetes applications is crucial. Traditional CI/CD tools like Jenkins often require extensive scripting and lack real-time synchronization with Kubernetes clusters. This is where Argo CD comes in—a GitOps-based continuous deployment tool designed specifically for Kubernetes. In this blog, we will explore what Argo CD is, its architecture, installation process, and why it stands out as a better choice for Kubernetes deployments.

What is GitOps?

It is necessary to understand what GitOps is first:
GitOps is an operational framework that uses Git repositories as the single source of truth for managing infrastructure and application deployment. This approach enables version control, easy rollbacks, and automated synchronization of the actual state with the desired state.

Note: Here, a single source of truth means that any change required for application deployment or infrastructure management must originate from Git. Direct modifications in Kubernetes, Terraform, or other platforms are not allowed, and this ultimately makes it secure and consistent.

What is Argo CD?

Argo CD is a continuous deployment tool for Kubernetes that follows the GitOps approach. It works on a pull-based mechanism, ensuring that the actual state of applications matches the desired state defined in a Git repository. If any discrepancies occur—whether due to manual changes in Kubernetes or updates in Git—Argo CD detects them. However, manual modifications in Kubernetes are not permitted, as they result in an OutOfSync state. Argo CD continuously monitors the Git repository and only applies changes when new updates are detected, ensuring automated synchronization.

Key Features of Argo CD:

Declarative, GitOps-based deployment
Versioned and Immutable
Automated synchronization of desired and actual state
UI and CLI for better accessibility
Role-Based Access Control (RBAC)
Self-healing capabilities
Continuous Observation/Monitoring

Argo CD Architecture

API server: It is gRPC server(a high performance Remote Procedure Call framework which uses HTTP/2 for efficient communication) and is the interface which allows users to interact with Argo cd by UI/CLI.

Its responsibilities are:

Application management and status report
Operations like rollback, sync, etc
Credential management of repositories and clusters
Allows RBAC

Repo server: This service keeps the local cache of the git repositories that have manifest files and this gets generated and sent to K8s when provided inputs in Argo cd like repo URL, its path(filename), and values if using helm.

Application controller: This service controls Kubernetes which continuously monitors the running application and compares the current state against the desired state. If it's different in state or changes made from the K8s side manually it results in OutOfSync and it reverts back to the desired state on its own which was originally defined in the git repo. This step concludes that ArgoCD has the self-healing ability.

Responsibilities:

Detects any configuration drift between the actual and desired state
Automatically synchronizes changes when discrepancies occur
Ensures self-healing by reverting unauthorized manual changes in Kubernetes

Installing Argo CD

Argo CD is installed directly in a Kubernetes cluster and can be accessed via both UI and CLI.

1. Install Argo CD on Kubernetes

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

This creates an argocd namespace and installs Argo CD components from the official GitHub repository.

2. Expose the Argo CD Service
By default, Argo CD runs with a ClusterIP service. To access it externally, change it to NodePort:

kubectl edit service/argocd-server -n argocd

Modify the type field from ClusterIP to NodePort and save the changes.

3. Retrieve Argo CD Admin Password
Argo CD’s default username is admin, and the password is stored in a Kubernetes secret:

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

Use this password to log in via the web UI.

4. To Install and Access Argo CD via CLI

curl -sSL -o argocd-linux-amd64 https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
sudo install -m 555 argocd-linux-amd64 /usr/local/bin/argocd
rm argocd-linux-amd64

To log in via CLI:

argocd login <server-host>

Retrieve the initial admin password using:

argocd admin initial-password -n argocd

Why Use Argo CD Over Jenkins?

Jenkins is widely used for CI/CD, but when it comes to Kubernetes deployments, it has limitations:

Jenkins requires scripts for automation, whereas Argo CD follows a declarative approach.
Jenkins does not monitor Kubernetes clusters for state changes, whereas Argo CD continuously syncs the actual and desired states.
Argo CD provides a UI and CLI specifically designed for Kubernetes deployment workflows.
Argo CD supports Helm, and native YAML, making it flexible for various deployment strategies.

Alternatives to Argo CD

Another popular GitOps tool is Flux CD, which also follows a pull-based deployment model. The choice between Argo CD and Flux CD depends on specific use cases:
Argo CD is better for teams requiring a UI, RBAC, and advanced deployment strategies.
Flux CD is lightweight and integrates well with Kubernetes-native tooling like Helm Operator.

Conclusion

Argo CD simplifies Kubernetes application deployment by automating synchronization with Git repositories. Its pull-based mechanism ensures self-healing capabilities, reducing the chances of manual errors. Compared to traditional CI/CD tools like Jenkins, Argo CD provides a more Kubernetes-native approach to continuous deployment.

If you are managing Kubernetes applications and want a robust, automated GitOps workflow, Argo CD is a powerful tool worth integrating into your DevOps pipeline.
Happy CD! 🚀

Understanding Multi-Stage Dockerfile: A Guide for Efficient Containerization

Soram Varma — Mon, 10 Mar 2025 08:21:25 +0000

Introduction

Docker has revolutionized the way applications are deployed by providing a containerized environment that ensures consistency across development, testing, and production. A key aspect of Docker is the Dockerfile, which is used to define and build custom container images based on specific requirements.
However, when dealing with large applications, traditional Dockerfiles can result in unnecessarily large images, consuming excessive storage and making deployments less efficient. This is where Multi-Stage Dockerfiles
come into play, helping to optimize the image size and improve security by only including what is necessary for the final deployment.

In this blog, we will explore Multi-Stage Dockerfiles, their benefits, and how they enhance the deployment process. We’ll also walk through an example using Maven and TomEE to build and deploy a Java-based web application.

What is a Multi-Stage Dockerfile?
A Multi-Stage Dockerfile is an advanced feature of Docker that allows multiple stages within a single Dockerfile. Each stage can use a different base image, and only the necessary artifacts from the previous stages are copied to the final image. This significantly reduces the final image size and enhances security by eliminating unnecessary dependencies.

Key Benefits of a Multi-Stage Dockerfile:

Optimized Image Size: Reduces storage usage by only including essential artifacts.
Improved Security: The final image is free from unnecessary build tools, reducing potential attack vectors.
Simplified Workflow: Eliminates the need for separate Dockerfiles for building and running applications.
Better Maintainability: Keeps Dockerfiles clean and easier to manage.

Multi-Stage Dockerfile Example: Java-Based Application
Below is the overview of the Multi-stage Dockerfile
Let's break down this Multi-Stage Dockerfile for a Java-based application that uses Maven for building and TomEE for deployment as a base image.

# Build Stage
FROM maven: latest AS build
WORKDIR /app
COPY . .
RUN mvn clean package

# Deployment Stage
FROM tomee:latest  # Includes Java and Tomcat (TomEE)
WORKDIR /app
COPY --from=build /app/target/*.war /usr/local/tomee/webapps/ROOT.war
EXPOSE 8080
CMD ["catalina.sh", "run"]

Stage 1: Build Stage

Base Image: maven:latest – Includes Maven to compile the Java project.
Working Directory: /app
COPY Instruction: Copies all source code and the pom.xml file from the local machine to the container.
RUN Instruction: Executes mvn clean package, which compiles the application and creates a .war file in the target directory.

Stage 2: Deployment Stage

Base Image: tomee:latest – Includes Java and TomEE.
Working Directory: /app
COPY --from=build: Extracts only the .war file from the previous stage and moves it to TomEE's deployment directory (/usr/local/tomee/webapps/ROOT.war).
EXPOSE 8080: Opens port 8080 to allow access to the application.
CMD Instruction: Starts the TomEE server.

Why Use ROOT.war?
By default, a .war file deployed inside webapps/ is accessible via:

http://localhost:8080/<context_path>

However, when named ROOT.war, the application is deployed as the root, making it accessible directly at:

http://localhost:8080/

This eliminates the need to specify the context path in the URL.

Why Use a Multi-Stage Dockerfile?

A traditional approach would involve creating separate images for the build and deployment, but this can lead to large image sizes and unnecessary complexity. Here’s why using a Multi-Stage Dockerfile is beneficial:

Reduces Image Size: A standard image containing Maven and build dependencies can be several gigabytes in size. With a Multi-Stage Dockerfile, only the essential .war file is included in the final image, significantly reducing its size.
Enhances Security: By removing unnecessary build tools from the final image, we minimize the attack surface, making the containerized application more secure.
Improves Deployment Efficiency: Since the final image only contains runtime dependencies, it results in faster deployment times and efficient resource utilization.
Encourages Best Practices: Keeping build and runtime environments separate aligns with industry best practices, ensuring better maintainability and scalability.

Conclusion

Multi-Stage Dockerfiles are an essential feature for optimizing Docker images, reducing storage requirements, and improving security. By carefully structuring build and deployment stages, you can streamline the development workflow and deploy lightweight, efficient containers.

In this guide, we explored a practical Java-based example using Maven and TomEE, highlighting the benefits of this approach. Whether you're developing microservices, monolithic applications, or frontend-heavy web apps, adopting Multi-Stage Dockerfiles will greatly enhance your containerization strategy.

Happy Containerizing!

How can I ping the main machine on which I just launched my private instance?

Soram Varma — Sun, 16 Feb 2025 08:09:29 +0000

When working with cloud infrastructure, it's common to have private instances that don't have direct internet access. These instances often rely on a NAT (Network Address Translation) gateway to access the internet for updates or external communications. However, this setup can make it challenging to ping the main machine (or bastion host) from the private instance, or vice versa, due to the lack of a direct route.

In this blog, we'll explore how you can ping the main machine from a private instance that has no internet connection and uses a NAT gateway for outbound traffic. We'll also discuss why this setup behaves the way it does and provide a step-by-step guide to achieve the desired connectivity.

Why Can't You Ping the Main Machine?
In a typical cloud setup:

Private Instances: These instances are placed in a private subnet and do not have public IP addresses. They rely on a NAT gateway to access the internet for outbound traffic.
NAT Gateway: The NAT gateway allows private instances to initiate outbound connections to the internet but does not allow inbound connections from the internet or other instances.
Main Machine (Bastion Host): This is usually a public-facing instance that acts as a gateway to access private instances.

The inability to ping the main machine from the private instance (or vice versa) is due to the following reasons:

Private instances lack public IP addresses, so they cannot be directly accessed from the internet.
The NAT gateway only facilitates outbound traffic and does not route inbound traffic to private instances.
Security groups and network ACLs (Access Control Lists) may block ICMP (ping) traffic between the instances.

Step-by-Step Guide to Ping the Main Machine
To enable pinging between the main machine and the private instance, follow these steps:

1. Set Up a Bastion Host
Ensure you have a bastion host (main machine) in a public subnet with a public IP address.
Configure the security group of the bastion host to allow SSH access (port 22) from your IP address.

2. Configure Security Groups
For the private instance:
Allow inbound ICMP (ping) traffic from the bastion host's private IP address.
Allow inbound SSH traffic from the bastion host's private IP address.
For the bastion host:
Allow outbound ICMP traffic to the private instance's private IP address.

3. Use SSH Tunneling
Since the private instance cannot be directly accessed, you can use the bastion host as a jump server to establish a connection.

SSH into the bastion host:

ssh -i <your-key.pem> user@<bastion-public-ip>

From the bastion host, SSH into the private instance using its private IP address:

ssh -i <your-key.pem> user@<private-instance-ip>

4. Ping the Main Machine
Once you're inside the private instance, you can ping the bastion host's private IP address:

ping <bastion-private-ip>

If the security groups and network ACLs are configured correctly, the ping should succeed.

5. Ping the Private Instance from the Main Machine
To ping the private instance from the bastion host, use the private IP address of the private instance:

ping <private-instance-ip>

Troubleshooting Tips

Check Security Groups: Ensure that the security groups for both the bastion host and the private instance allow ICMP traffic.
Verify Network ACLs: Ensure that the network ACLs for the subnets allow inbound and outbound ICMP traffic.
Private IP Addresses: Always use private IP addresses for communication within the VPC (Virtual Private Cloud).
NAT Gateway Configuration: Remember that the NAT gateway only facilitates outbound traffic and does not help with inbound connectivity.

Conclusion
Pinging the main machine from a private instance (or vice versa) in a cloud environment with a NAT gateway requires careful configuration of security groups, network ACLs, and SSH tunneling. By following the steps outlined in this blog, you can establish the necessary connectivity and troubleshoot any issues that arise.

This setup is particularly useful for managing private instances in a secure and controlled manner, ensuring that your infrastructure remains protected while still allowing necessary communications.

Note: Whether you're working with Linux or Windows-based servers, the process remains the same. For Windows servers, additional attention to the Windows Firewall is required, but the core steps are identical.

Happy networking! 🚀

Installing Kubernetes using kubeadm without installing docker in Ubuntu

Soram Varma — Thu, 06 Feb 2025 14:07:31 +0000

First of all, what is Kubernetes?
Kubernetes (K8s) is an orchestration tool that automates the deployment, scaling, and management of containerized applications. It provides key features like:

Scaling: Automatically scales applications up or down based on demand.
Updating: Manages rolling updates and rollbacks to ensure seamless application updates.
High Availability: Ensures applications run without downtime by distributing containers across multiple nodes.
Load Balancing: Distributes traffic efficiently to maintain performance.
Self-Healing: Detects and replaces failed containers automatically.

But to happen this thing initial step is to install it
Below are the steps to achieve it.

#Installing Kubernetes using kubeadm in Ubuntu:
sudo apt-get update sudo apt-get install -y apt-transport-https ca-certificates curl gpg

#Enable IPv4 packet forwarding
#sysctl params required by setup, params persist across reboots
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf net.ipv4.ip_forward = 1 EOF
# Apply sysctl params without reboot
sudo sysctl --system
*#verify it by command as the output should be 1: *
sudo sysctl net.ipv4.ip_forward

#(Althoug it present but if not available) make directory with permission if not present you can check by going to this directory /etc/apt/keyrings
_#sudo mkdir -p -m 755 /etc/apt/keyrings_

#Add the Kubernetes repository

curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.31/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
# This overwrites any existing configuration in /etc/apt/sources.list.d/kubernetes.list
#Execute the below command after creating kubernetes repo
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.31/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list

#As installing k8s version v1.31 no need to install Docker as in k8s instead installing container runtime environment(cri-o, containerd, Docker Engine) it provides the required docker usage stuff

#Add the CRI-O repository:

curl -fsSL https://pkgs.k8s.io/addons:/cri-o:/stable:/v1.31/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/cri-o-apt-keyring.gpg
#Then run the created repo:
echo "deb [signed-by=/etc/apt/keyrings/cri-o-apt-keyring.gpg] https://pkgs.k8s.io/addons:/cri-o:/stable:/v1.31/deb/ /" | sudo tee /etc/apt/sources.list.d/cri-o.list

#Execute the following command
sudo apt-get update
sudo apt-get install -y cri-o kubelet kubeadm kubectl #Install the packages
sudo systemctl start crio.service #This will start the cri-o service
sudo swapoff -a #as this makes the kubelet not to start
sudo modprobe br_netfilter #Bootstrap a cluster

sudo kubeadm init

#Below command gets provided by running kubeadm init which need to be performed
mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config

#Create cni network
curl https://raw.githubusercontent.com/projectcalico/calico/v3.28.2/manifests/calico.yaml -O

kubectl apply -f calico.yaml

#last will copy and paste the kubeadm join command into the desired node which will be like given below **
**#example:
sudo sudo kubeadm join 192.168.46.157:6443 --token7xlnp0.9uv4z0qr4wvzhtqn \ --discovery-token-ca-cert-hash sha256:4a1a412d2e682556df0bf10dc380c744a98eb99e8c927fa58eb025d5ff7dc694