In this post, we’ll look into how to build a GitOps pipeline to deploy applications on Amazon EKS (Elastic Kubernetes Service). We’ll use ArgoCD and various AWS services like CodeCommit, CodePipeline, CodeBuild, and Amazon Elastic Container Registry (ECR).

Sometime back, I had written a post on GitOps and some of the challenges that we typically encounter, and a few key points to consider before adopting GitOps. Feel free to take a look if you are looking for a quick refresher.Or, if you are new to GitOps, take a few minutes to go through the post as well before we look into more implementation specific details in this post.And, if you want to dive deeper, refer Weaveworks blogs as well.

---

Picking The Tools

Although GitOps for Kubernetes can be achieved with FluxCD or ArgoCD, I have chosen ArgoCD for this post primarily because ArgoCD has an intuitive GUI that can help to interact and understand the GitOps pattern in a better way. This is not an issue for someone who likes the CLIs more than the GUIs.Both ArgoCD and FluxCD have their strengths and weaknesses. Both the teams may close the gaps quickly. We never know. I am not an expert in either of them, so, I’ll refrain from going further into any deep feature comparison._Segue: _It’s worth mentioning that gitops-engine was born to converge the efforts and provide the best possible value for the GitOps community. It’s under active development and evolving rapidly. Let’s wait and watch until it is available for use.And, regarding the AWS services, we would use AWS CodeCommit for the code repository; AWS CodePipeline to provide the structure for the DevSecOps continuous integration pipeline; AWS CloudWatch Events (part of Amazon EventBridge now) to trigger the builds; AWS CodeBuild to run the builds; Amazon ECR to store the Docker images.

---

How The Pipeline Works

The pipeline architecture would look like the one below.

So, why the CloudWatch Events? We can have CodeBuild poll for code changes in the CodeCommit repository and trigger the build as well. Yes, but let’s keep it event-based. We’ll look at the Event configuration details in a later section._Why two CodeCommit repositories? _We’ll see that as well in a later section.The critical component, ArgoCD operator, is responsible to sync up the declared desired state configuration from the Git repository (CodeCommit) to the EKS cluster. The desired state can mean anything like an updated image version, Kubernetes deployment object spec, the number of replicas, port configurations, and so on.

---

Setting up the Amazon EKS Cluster

To keep things simple, I would not cover a lot of details around provisioning a hardened Amazon EKS cluster. For this post, let’s consider a publicly accessible cluster created using eksctl command like eksctl create cluster -f ../eks-cluster-config.yml with a simple configuration like the one below. Or, you can use an existing EKS cluster.

---
	apiVersion: eksctl.io/v1alpha5
	kind: ClusterConfig

	metadata:
	  name: gitops-demo
	  region: us-east-1

	availabilityZones: ["us-east-1a", "us-east-1b"]
	managedNodeGroups:
	- name: gitops-workers
	  desiredCapacity: 1
	  iam:
	    withAddonPolicies:
	      albIngress: true
	  ssh:
	    publicKeyName: "123-key"

	cloudWatch:
	    clusterLogging:
	        enableTypes: ["audit", "authenticator", "controllerManager"]

	secretsEncryption:
	  keyARN: "arn:aws:kms:<REGION>:<ACCOUNT ID>:key/<KEY ID>"

Refer the eksctl schema for details on all the supported configuration properties.Note that, eksctl will create all the required AWS services and components necessary for the EKS cluster — A dedicated VPC, subnets, security groups, IAM policies, etc.Behind the scenes, eksctl creates CloudFormation stacks. You can refer all the details and the resources of the stack like the one below —

Note: DO NOT USE such a cluster that might not meet your specific security and compliance requirements.

#software-development #git #aws #programming #kubernetes