3.1. Implementing GitOps on AWS: Deploying to EKS using CodePipeline and ArgoCD

GitOps on AWS: Deploying to EKS with CodePipeline and ArgoCD (Simple Guide)

So, you've heard about GitOps and Kubernetes, and now you want to put them together on AWS using EKS (Elastic Kubernetes Service). Awesome! This post will guide you through a simple implementation using CodePipeline and ArgoCD. We'll break down the complex stuff and make it easy to understand.

What is GitOps, and why should you care?

Imagine your Kubernetes cluster as a meticulously crafted garden. Traditionally, you might manually tweak things: adding fertilizer, pulling weeds, watering plants – all by hand.

GitOps, on the other hand, is like having a gardener robot whose only job is to look at a blueprint (your Git repository) and automatically adjust the garden to match. Any changes you want to make, you update the blueprint, and the robot takes care of the rest.

In other words, GitOps lets you manage your Kubernetes deployments through Git. Your Git repository becomes the single source of truth for your desired state. This offers numerous benefits:

Version Control: Track every change to your infrastructure and applications.
Automation: Automate deployments and rollbacks.
Auditing: Easily see who changed what and when.
Improved Security: Centralized and controlled access through Git.

Our Players: EKS, CodePipeline, and ArgoCD

EKS (Elastic Kubernetes Service): Your Kubernetes cluster running on AWS. Think of it as the ground where your garden (applications) grows.
CodePipeline: AWS's continuous integration and continuous delivery (CI/CD) service. This is like the construction crew building the blueprint for our robot gardener. It automates the process of building, testing, and packaging your application.
ArgoCD: A declarative GitOps continuous delivery tool for Kubernetes. This is our robot gardener! It continuously monitors your Git repository and ensures your Kubernetes cluster matches the desired state defined in Git.

Architectural Overview:

Simplified Workflow:

Code Changes: You make changes to your application code and Kubernetes manifests (YAML files defining your deployments, services, etc.) and push them to your Git repository.
CodePipeline Trigger: The Git push triggers a CodePipeline.
Build and Package: CodePipeline builds your application (e.g., builds a Docker image), runs tests, and packages everything (including your Kubernetes manifests) into an artifact (e.g., a zip file) stored in an S3 bucket.
ArgoCD Sync: ArgoCD is constantly watching your Git repository (or, in this case, the S3 bucket where CodePipeline places the artifacts). When it detects a change (a new artifact), it pulls the latest version.
Deployment: ArgoCD compares the current state of your EKS cluster with the desired state defined in the artifact and applies the necessary changes to synchronize the cluster with the Git repository.

Practical Example: Deploying a Simple "Hello World" App

Let's imagine a basic "Hello World" web application that we want to deploy to EKS using this GitOps flow.

Git Repository: You'll need a Git repository with the following structure:

 hello-world-app/
 ├── Dockerfile          # Defines how to build your application's Docker image
 ├── k8s/
 │   ├── deployment.yaml   # Kubernetes Deployment definition
 │   └── service.yaml      # Kubernetes Service definition
 └── app.py             # Your Python "Hello World" app

The deployment.yaml might look something like this:

 apiVersion: apps/v1
 kind: Deployment
 metadata:
   name: hello-world
 spec:
   replicas: 2
   selector:
     matchLabels:
       app: hello-world
   template:
     metadata:
       labels:
         app: hello-world
     spec:
       containers:
       - name: hello-world
         image: your-docker-registry/hello-world:latest  # Replace with your image
         ports:
         - containerPort: 8000

CodePipeline Setup: Create a CodePipeline that:
- Retrieves the code from your Git repository.
- Builds a Docker image from the Dockerfile and pushes it to a Docker registry (e.g., ECR).
- Updates the image field in your deployment.yaml with the new image tag. (You might use sed or a similar tool for this).
- Creates an artifact (e.g., zips the k8s directory) and stores it in an S3 bucket.
ArgoCD Configuration: Install ArgoCD into your EKS cluster. Then, create an ArgoCD application that:
- Points to the S3 bucket where CodePipeline is storing the artifacts.
- Specifies the path within the S3 bucket where your Kubernetes manifests are located (e.g., k8s).
- Defines the target namespace in your EKS cluster where the application should be deployed.
The Magic: Now, whenever you update your application code and push it to Git, CodePipeline will automatically rebuild and repackage your application. ArgoCD will detect the changes and deploy the updated version to your EKS cluster.

A Challenge: Configuration Drift

One challenge you might encounter is configuration drift. Let's say someone (accidentally!) modifies a deployment directly in the Kubernetes cluster using kubectl edit deployment hello-world. This would make the cluster's actual state different from the desired state in your Git repository.

Solution: ArgoCD automatically detects and corrects configuration drift! It will revert the manual changes made in the cluster back to the desired state defined in Git. This helps ensure your cluster remains consistent and predictable. You can configure ArgoCD to automatically sync changes or require manual approval, depending on your needs.

Conclusion

Implementing GitOps with CodePipeline and ArgoCD on AWS might seem daunting at first. However, by breaking it down into smaller, manageable steps and understanding the roles of each component, you can automate your Kubernetes deployments and reap the benefits of increased efficiency, improved security, and better collaboration. Start small, experiment, and adapt this setup to fit your specific requirements. Happy deploying!