DEV Community: AzeematRaji

Create Your Own Helm Charts: Reusable, Scalable, and Production-Ready

AzeematRaji — Fri, 19 Sep 2025 19:58:16 +0000

If you’ve ever deployed microservices on Kubernetes, you know the pain: endless YAML files, copy-pasting configs, and maintaining slightly different manifests for every service. It works… until you need to scale. That’s where Helm comes in. By creating your own charts, you can transform messy manifests into reusable building blocks that scale seamlessly as your app grows.

In this post, I’ll walk you through how I built a shopping application with multiple microservices, deployed on AWS EKS with Terraform, but more importantly, how I made the whole setup modular with custom Helm charts.

As a DevOps engineer, here’s what you should know before deploying a microservices app:

Which microservices you need to deploy
Which services talk to each other
How they communicate
Which database(s) they use
Which ports each service runs on

Why Write Your Own Helm Charts?

Reusability - no duplicate YAML
Scalability - add new services easily
Flexibility - use values.yaml for environment-specific configs
Consistency - Redis, ingress, microservices share structure

Instead of a one-off deployment, this approach gave me a framework to grow the application without headaches.

Prerequisites

Before diving in, you should have:

Basic Kubernetes knowledge – deployments, services, and ingress
Basic Terraform knowledge – how to provision infrastructure (init, apply, destroy)

Infrastructure First: Terraform + EKS

I used Terraform to provision the foundation:

A VPC with subnets
An EKS cluster
IAM roles and networking With this, spinning up or tearing down the cluster is just:

cd infra
terraform init
terraform apply --auto-approve
terraform destroy --auto-approve

Building Helm Charts for Each Component

Instead of dumping all microservices into one manifest, I built a chart per component:

manifests/
├── charts/
│   ├── ingress/       
│   ├── redis/         
│   └── shopping-ms/   
├── values/
├── helmfile.yaml
└── issuer.yaml

I created chart for redis database, ingress and the microservice.

helm create <chart-name>

For example, i created a chart for my shopping microservice:

helm create shopping-ms

This will generate a directory structure like:

shopping-ms/
├── charts/
├── templates/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── _helpers.tpl
├── values.yaml
├── Chart.yaml
└── .helmignore

From here, templates can be edited with placeholders to fit the microservice and the values.yaml will carry the default values for the chart.

Now going two level above the shopping-ms/, in the manifests/, inside the values/ we can then have seperate values.yaml for each microservice, the values in these yaml will override the default values in the values.yaml in the chart directory.

Securing Ingress with TLS

Install Nginx Ingress Controller in the cluster, which is responsible for creating loadbalancer and actually handling the traffic. Deployment and service in the Ingress chart is basically rules that the controller follows to know how to handle the traffic.

I used the helm repo for nginx-ingress controller and cert-manager directly from helm to minimize lot of overhead, i would get to the cert-manager in a bit, hang on!

# Add Helm repo for ingress-nginx
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

# Install ingress-nginx into its own namespace
kubectl create namespace ingress-nginx
helm install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --set controller.publishService.enabled=true

# Verify Ingress Controller
kubectl get pods -n ingress-nginx

# Check the LoadBalancer service

kubectl get svc -n ingress-nginx

You should have an existing domain name or create one, point your domain to the LoadBalancer IP with a CNAME record.
Install cert-manager in the cluster. This handle the automatic creation of certificates and renewal before it expires. However, a clusterissuer or issuer is needed to tell cert-manager what CA (certificate authority) to use. Also annotation of cert-manager.io/cluster-issuer: letsencrypt-prod must be defined in the ingress.yaml so ingress can request for the certificate successfully.

kubectl create namespace cert-manager

helm repo add jetstack https://charts.jetstack.io
helm repo update

helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --set installCRDs=true

# This installs cert-manager and the CRDs (otherwise issuers won’t work, which is needed for TLS).
# Verify Installation
kubectl get pods -n cert-manager

We need to apply the issuer.yaml, so the cert-manager is already to serve certificate when requested for.

kubectl apply -f issuer.yaml

Key notes

Ingress controller is cluster-wide, not namespace-specific
cert-manager is also a cluster-wide resource
Use ClusterIssuer instead of Issuer for certificates that apply across namespaces

Deploying with Helmfile

Managing each chart individually quickly becomes painful. That’s why I used Helmfile, a single command to apply or destroy all charts at once.

helmfile apply
helmfile destroy

Access the application

Once deployed, the shopping app was live at:

https://<your-domain>

Troubleshooting Tips

HTTPS not working? Ensure cert-manager is installed before applying your issuer
Hit Let’s Encrypt rate limits? Use the staging issuer first
Services not exposed? Double-check ingress annotations in your Helm chart
Beginner level with kubernetes? I suggest you start with a single deployment file then turn it into helm charts.

Lessons Learned

Start with charts early, don’t wait until you have YAML sprawl.
Helmfile is a lifesaver, one command to apply/destroy everything.
Charts are portable, I can now drop Redis or ingress into any new cluster.

Wrap up

This project showed me how writing reusable Helm charts makes Kubernetes deployments scalable, consistent, and future-proof. Instead of juggling manifests, I now have modular building blocks I can apply anywhere.

Next, I’m planning to extend these charts for monitoring (Prometheus + Grafana) so the setup can evolve into a full production-ready stack.

Full codebase here: Github repo

Deploying MongoDB on Amazon EKS with Terraform, Helm & Ingress: A Story of Stateful Apps on Kubernetes

AzeematRaji — Sat, 16 Aug 2025 22:49:52 +0000

Have you ever wondered how stateful applications like databases fit into the world of Kubernetes? Or maybe you’ve been curious about what happens when a database pod is replicated, where does the data actually live?

I had these same questions. Stateless apps were easy for me to understand, spin up a pod, scale it up and down, and if one dies, Kubernetes simply replaces it. But with a database? Things get trickier. Data can’t just disappear when a pod restarts.

That curiosity led me into this project: deploying MongoDB on Amazon EKS. Not only MongoDB, but also Mongo Express, a web-based admin interface to interact with the database. And I wanted to automate it end-to-end using Terraform, Helm, and Kubernetes manifests.

Here’s how the journey unfolded:

The Challenge: Stateful vs Stateless Apps

Stateless apps (like an API or frontend) don’t care if pods are destroyed and recreated — the state is stored elsewhere (e.g., S3, DynamoDB).
Stateful apps (like MongoDB, PostgreSQL, MySQL) are different. They need persistent storage that survives pod restarts.

This means when you run a database in Kubernetes, you need to think about:

How data is stored (Persistent Volumes)
How pods are managed (StatefulSets)
How storage integrates with your cloud provider (AWS EBS in my case)

My Approach

Here’s the stack I used to make this work:

Terraform – Provisioned the VPC, subnets, and Amazon EKS cluster.
AWS EBS CSI Driver – Enabled dynamic provisioning of EBS volumes for persistent storage.
Helm – Deployed MongoDB as a StatefulSet with customized values.
Mongo Express – A simple web-based UI to interact with MongoDB.
NGINX Ingress Controller – Exposed Mongo Express via an AWS Load Balancer.

Architecture Diagram

Here’s what the setup looks like:

Step 1: Provision Infrastructure with Terraform

Terraform took care of the networking and cluster setup. At a high level:

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.1.2"
  # Public & private subnets defined here...
}

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "20.24.2"
  cluster_name    = "mongo-eks-cluster"
  cluster_version = "1.30"
  # Managed node groups defined here...
}

Once applied, I had a working VPC + EKS cluster.

Step 2: Install AWS EBS CSI Driver

kubectl apply -k "github.com/kubernetes-sigs/aws-ebs-csi-driver/deploy/kubernetes/overlays/stable/ecr/?ref=release-1.22"
kubectl get pods -n kube-system -l app=ebs-csi-controller

This command pulls the stable release manifest and applies all necessary resources (controller, daemonset, RBAC, etc.) and verify installation.

Without installing this, its just like trying to claim a persistent volume that doesnt exist, the cluster can not spin up a volume without a provisioner installed which is the EBS CSI driver

Step 3: Attach policy to the Node IAM role

aws iam attach-role-policy \
  --role-name <NodeInstanceRoleName> \
  --policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy

This command gives EKS worker nodes permission to create and manage EBS volumes so MongoDB (or any pod) can use persistent storage.

Step 4: Install MongoDB via Helm

Before installing mongodb, set the mongodb-values.yaml for the required replicaset and persistent volume. Incase you are wondering what values.yaml file is, its the configuration file that overrides the default configuration when using helm to install any app.

helm install my-mongodb oci://registry-1.docker.io/bitnamicharts/mongodb \
  -f mongodb-values.yaml

Step 5: Create a service for Mongodb deployment

After installing mongodb on the cluster, it creates a headless service (with clusterIP: None), which is useful for internal communication between MongoDB pods, for example when they need to discover each other in a replica set. However, this is not suitable for external applications like Mongo Express, which need a stable endpoint to connect to MongoDB.

In statefulset, one of the replicaset has the read and write which is the primary pod, while secondary pods have just read to reduce the load on primary pod. If a headless service of a secondary pod is used in the configmap for example, the UI might be accessible but one might be unable to write to it therefore limiting the functions of the app. Its quite important to connect to the database as a whole than connecting to the individual pod.

To make MongoDB accessible to other applications inside the cluster, we need a ClusterIP service. This service provides a single stable DNS name and load balances connections across the MongoDB pods.

kubectl apply -f mongodb-svc.yaml

Check all the pods and services to comfirm they are running;

kubectl get pod
kubectl get svc
kubectl get all

Step 6: Deploy Secret and Configmap Volume

This is needed for the Mongoexpress to connect with the mongodb, these are some of the values we defined in the values.yaml

kubectl apply -f secret.yaml
kubectl apply -f configmap.yaml

Step 7: Deploy Mongo Express

Mongoexpress in the UI for the database, this will be deployed using kubernetes deployment.

kubectl apply -f mongoexpress.yaml

Step 8: Install Nginx ingress controller via helm

Nginx ingress controller automatically spin up cloud loadbalancer in my case, aws loadbalancer and route traffic from the ingress to the loadbalancer behind the hood.

helm install ingress-nginx oci://ghcr.io/nginxinc/charts/ingress-nginx \
  --namespace ingress-nginx \
  --create-namespace

Step 9: Deploy Ingress rule

This file contains the rule that ingress controller apply, basically how the traffic needs to be routed. Also this was exposed to all instead of a domain name because this is a testing environment.

kubectl apply -f ingress.yaml

Step 9: Accessing via mongoexpress UI

kubectl get all

The IP address on the ingress service would be accessible on the browser, you can access and store data on the database Mongo Express credentials (default): admin / pass.

Bonus: you can try to scale down the replicaset after saving data in the database, confirm there is no pod running, then scale up the replicaset and you will find your database would be attached back to it, thats the power of persistent volume in the cloud, pod or node restarting doesnt mean storage is lost.

Limitations of Self-Hosted

While self-hosting gives control and flexibility, it also introduces challenges such as:

Backup and restore processes.
Security patching and updates.
Monitoring and scaling for production workloads.
High availability and failover management.

Key Lessons Learned

Linode vs AWS Storage Provisioning – Linode’s Kubernetes engine comes with a default storage provisioner, but AWS EKS requires installing and configuring the EBS CSI Driver with proper IAM permissions.
StatefulSet Basics – Understanding PVC binding, PV lifecycle, and how pods reconnect to the same volumes after restarts.
Ingress Integration – AWS LB + NGINX Ingress can seamlessly route traffic to internal services and external services

Improvements

mongodb-values.yaml, terraform lock files and statefiles, .tfvars should all be in the .gitignore file
EBS CSI drive can be installed, IAM policy attached, mongodb deployed via helm all usinf terraform, this helps maintain versions
Secret.yaml can be done using third party tool like aws secret manager and referencing it in the secret.yaml instead of exposing it
Lastly, our application can be accessed via domain name, it can be configured in the ingress rule.
TLS for a secured connection using certmanager

Next Steps

To take this setup closer to production readiness, the following can be implemented:

Automated Backups – configure scheduled snapshots or use tools like Velero.
Monitoring & Alerting – integrate with Prometheus + Grafana for insights.
Maintenance – apply updates and patches regularly.
Scaling – configure replica sets for fault tolerance.
Migration to Managed Services – consider AWS DocumentDB for reduced operational overhead.

You can find all codes snippet in my github repo

From Scripts to Cloud: My Hands-On Guide to ML + DevOps

AzeematRaji — Mon, 21 Apr 2025 17:09:12 +0000

As a DevOps engineer, I'm used to automating backend systems, deploying apps, and scaling infrastructure. But when I trained my first machine learning model, I found myself asking:
How do I bring the same level of automation and structure here?

I also started wondering, as AI continues to evolve, what’s the fate of a Cloud/DevOps engineer? Or better still, what role will we play in this new landscape?

This blog post is my attempt to explore and answer those questions by integrating AI and DevOps. Think of it as a beginner-friendly hands-on project guide to building a bridge between the two worlds.

What I Built

To put these questions into practice, I built a simple yet meaningful project:
A machine learning model that predicts epitope regions in a protein sequence.
An epitope is the part of an antigen that an antibody binds to, helping the immune system recognize and fight infections. This makes epitope prediction really important in vaccine and drug development.

To bring DevOps into the mix, I wrapped the model in a FastAPI backend, containerized it with Docker, and set up automated deployment to an EC2 instance using GitHub Actions.

Why This Matters

This ML model helps researchers, especially in the low resource environments by accelerating their work, cutting costs, and reducing the time spent running multiple experiments to identify which part of a protein is epitopic.

By integrating DevOps practices, this model is accessible even to researchers without a strong data science or technical background. All they need to do is input their protein sequences into the cloud-hosted web UI and the prediction is returned instantly.

This doesn’t just speed up research, it also widens access and promotes inclusion in the global scientific space.

Tools Used & Installed

Python 3.8 and above
FastAPI
Conda
Git
GitHub Actions
Docker
AWS EC2

Prerequisite Knowledge

To get the most out of this blog, it helps to be familiar with:

Linux command-line basics
Python programming
Basic machine learning concepts
Version control with Git
Fundamentals of Docker
Understanding of APIs (e.g FastAPI)
Basic CI/CD workflows
Conda (for managing Python environments)

Project Overview

The project is structured to separate concerns clearly:

Data Scripts: For retrieving, preprocessing, and training the model
Notebook: Used for exploratory data analysis and visualization
Model Artifacts: Trained model saved for inference
API Backend: A FastAPI app that serves predictions
Dockerfile: Containerizes the app for deployment
CI/CD Workflow: GitHub Actions automates the build and deployment
Cloud Infrastructure: The app is deployed to an EC2 instance on AWS

The full codebase and directory structure can be found in my github repository

Build With Me

Let’s walk through how I brought everything together, from training the ML model to deploying it in the cloud.

Setting up the environment

I created a Conda environment and installed all necessary dependencies:

conda create -n epitope python=3.10
conda activate epitope
pip install -r requirements.txt

To build with me, clone the repository

git clone https://github.com/AzeematRaji/epitope-ml-model.git
cd epitope-ml-model

Training the Machine Learning Model

I retrieved and preprocessed the data:

python scripts/retrieve.py
python scripts/preprocess.py

Then I trained and saved the model:

python scripts/train.py
joblib.dump(model, "../models/epitope_model.joblib")

Creating the FastAPI Backend I built a simple API using FastAPI to serve the trained model. To test it locally:

uvicorn app.main:app --host 0.0.0.0 --port 8000 --reload

Test access via API from the Browser:

localhost:8000

Writing a Dockerfile

I containerized the app using Docker:

docker build -t epitope-api .
docker run -p 8000:8000 epitope-api

This made it easy to run in any environment.

Test access via API from the Browser:

localhost:8000

Now, we have confirmed the app is working locally. Lets move it to the cloud.

Setting Up the EC2 Instance
- Launch an EC2 Instance on AWS
- Choose an appropriate instance type (e.g., t3.medium because of data size).
- Configure the security group to allow inbound traffic on port 8000 from 0.0.0.0 for testing.
Creating the GitHub Actions workflow

To automate deployment, I created a GitHub Actions workflow .github/workflows/deploy.yml that is triggered whenever there is a push to the main branch, it:
- Containerizes the application,
- Pushes it to DockerHub,
- Deploys it on your EC2 instance.

GitHub Secrets Configuration

In the GitHub repository, the following secrets need to be configured to ensure the pipeline works:

DOCKER_USERNAME
DOCKER_PASSWORD
EC2_SSH_KEY: The private SSH key or .pem file used to connect to the EC2 instance
EC2_PUBLIC_IP

This process eliminates the need to manually deploy the application every time there is a code change, streamlining the workflow.

Final testing and accessibility

Access the FastAPI via the browser:

http://<ec2-public-ip>:8000

This would display a UI prompt to input protein sequence and predict whether it epitope or non-epitope

Lessons Learnt

After evaluating the model, I observed that it tends to favor the prediction of non-epitope sequences over epitope sequences. This bias is largely due to the highly imbalanced dataset used during training.

This highlighted two important takeaways:

Data quality matters: An imbalanced dataset can significantly affect a model's performance, especially in critical applications like drug discovery.
There's room for improvement: Future iterations could involve experimenting with different featurizers, applying sampling techniques (e.g. SMOTE), and trying out more balanced or larger datasets to improve accuracy and fairness in predictions

Raw Reflections & What’s Ahead

This project was just the beginning of my exploration into the intersection of AI and DevOps. While I kept things simple here, there’s so much more to integrate, from using Kubernetes to manage and scale more complex ML workloads, to Terraform for automating infrastructure provisioning in a more structured and repeatable way.

These tools and ideas will be explored in future projects and blog posts, where I’ll continue building and documenting how DevOps can enhance the accessibility and reliability of AI applications.

If you found this insightful, feel free to follow my journey on GitHub where I share more projects like this.

Very detailed! Thank you

AzeematRaji — Mon, 03 Mar 2025 10:57:49 +0000

Docker to the Rescue: Deploying React And FastAPI App With Monitoring

Utibe ・ Nov 26 '24

#devops #docker #prometheus #loki

Building Smarter CI/CD: Automating Kubernetes Deployments with GitHub Actions

AzeematRaji — Thu, 02 Jan 2025 08:54:02 +0000

Overview

This project focuses on implementing automated Continuous Integration (CI) and Continuous Deployment (CD) workflows for both the frontend and backend applications of a web platform using GitHub Actions. The goal is to enhance development efficiency, enforce code quality standards, and streamline deployment to a Kubernetes cluster.

Deliverables

Frontend CI/CD Pipelines:

Automate testing, linting, building, and deployment of the frontend application.
Ensure only code changes in the frontend application trigger workflows.
Implement conditional job execution to build and deploy only if linting and tests pass.
Tag Docker images with the Git SHA for traceability.

Backend CI/CD Pipelines:

Establish a similar automated workflow for backend application development.
Enforce code quality checks and test validation before building the application.
Ensure Kubernetes deployments use the latest tagged Docker image based on the commit SHA.

Prerequisites

AWS account and CLI configured.
Terraform installed
Frontend application code
Backend application code
Basic knowledge of kubernetes

Steps to achieving this;

Deploying a cluster on EKS service in AWS using terraform
- create a terraform/
- containing main.tf which will create;

VPC

resource "aws_vpc" "vpc" {
  tags = {
    "Name" = "udacity"
  }
  cidr_block           = "10.0.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true
}

# Create an internet gateway
resource "aws_internet_gateway" "igw" {
  vpc_id = aws_vpc.vpc.id
}

# Create a public subnet
resource "aws_subnet" "public_subnet" {
  vpc_id                  = aws_vpc.vpc.id
  cidr_block              = "10.0.1.0/24"
  availability_zone       = "us-east-1${var.public_az}"
  map_public_ip_on_launch = true
  tags = {
    Name = "udacity-public"
  }
}

# Create public route table
resource "aws_route_table" "public" {
  vpc_id = aws_vpc.vpc.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.igw.id
  }

  tags = {
    Name = "public"
  }
}

# Associate the route table
resource "aws_route_table_association" "public" {
  subnet_id      = aws_subnet.public_subnet.id
  route_table_id = aws_route_table.public.id
}

# Create a private subnet
resource "aws_subnet" "private_subnet" {
  vpc_id            = aws_vpc.vpc.id
  availability_zone = "us-east-1${var.private_az}"
  cidr_block        = "10.0.2.0/24"
  tags = {
    Name = "udacity-private"
  }
}

# Create private route table
resource "aws_route_table" "private" {
  vpc_id = aws_vpc.vpc.id

  tags = {
    Name = "private"
  }
}

# Associate private route table
resource "aws_route_table_association" "private" {
  subnet_id      = aws_subnet.private_subnet.id
  route_table_id = aws_route_table.private.id
}

# Create EKS endpoint for private access
resource "aws_vpc_endpoint" "eks" {
  count               = var.enable_private == true ? 1 : 0 # only enable when private
  vpc_id              = aws_vpc.vpc.id
  service_name        = "com.amazonaws.us-east-1.eks"
  vpc_endpoint_type   = "Interface"
  security_group_ids  = [aws_eks_cluster.main.vpc_config.0.cluster_security_group_id]
  subnet_ids          = [aws_subnet.private_subnet.id]
  private_dns_enabled = true
}

# Create EC2 endpoint for private access
resource "aws_vpc_endpoint" "ec2" {
  count               = var.enable_private == true ? 1 : 0
  vpc_id              = aws_vpc.vpc.id
  service_name        = "com.amazonaws.us-east-1.ec2"
  vpc_endpoint_type   = "Interface"
  security_group_ids  = [aws_eks_cluster.main.vpc_config.0.cluster_security_group_id]
  private_dns_enabled = true
}

resource "aws_vpc_endpoint" "ecr-dkr-endpoint" {
  count               = var.enable_private == true ? 1 : 0
  vpc_id              = aws_vpc.vpc.id
  service_name        = "com.amazonaws.us-east-1.ecr.dkr"
  vpc_endpoint_type   = "Interface"
  security_group_ids  = [aws_eks_cluster.main.vpc_config.0.cluster_security_group_id]
  subnet_ids          = [aws_subnet.private_subnet.id]
  private_dns_enabled = true
}

resource "aws_vpc_endpoint" "ecr-api-endpoint" {
  count               = var.enable_private == true ? 1 : 0
  vpc_id              = aws_vpc.vpc.id
  service_name        = "com.amazonaws.us-east-1.ecr.api"
  vpc_endpoint_type   = "Interface"
  security_group_ids  = [aws_eks_cluster.main.vpc_config.0.cluster_security_group_id]
  subnet_ids          = [aws_subnet.private_subnet.id]
  private_dns_enabled = true
}

EKS resources

# Create an EKS cluster
resource "aws_eks_cluster" "main" {
  name     = "cluster"
  version  = var.k8s_version
  role_arn = aws_iam_role.eks_cluster.arn
  vpc_config {
    subnet_ids              = [aws_subnet.private_subnet.id, aws_subnet.public_subnet.id]
    endpoint_public_access  = var.enable_private == true ? false : true
    endpoint_private_access = true
  }
  depends_on = [aws_iam_role_policy_attachment.eks_cluster, aws_iam_role_policy_attachment.eks_service]
}


# Create an IAM role for the EKS cluster
resource "aws_iam_role" "eks_cluster" {
  name = "eks_cluster_role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "eks.amazonaws.com"
        }
      }
    ]
  })
}

# Attach policies to the EKS cluster IAM role
resource "aws_iam_role_policy_attachment" "eks_cluster" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKSClusterPolicy"
  role       = aws_iam_role.eks_cluster.name
}

resource "aws_iam_role_policy_attachment" "eks_service" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKSServicePolicy"
  role       = aws_iam_role.eks_cluster.name
}



# EKS Node Group

# Track latest release for the given k8s version
data "aws_ssm_parameter" "eks_ami_release_version" {
  name = "/aws/service/eks/optimized-ami/${aws_eks_cluster.main.version}/amazon-linux-2/recommended/release_version"
}

resource "aws_eks_node_group" "main" {
  node_group_name = "udacity"
  cluster_name    = aws_eks_cluster.main.name
  version         = aws_eks_cluster.main.version
  node_role_arn   = aws_iam_role.node_group.arn
  subnet_ids      = [var.enable_private == true ? aws_subnet.private_subnet.id : aws_subnet.public_subnet.id]
  release_version = nonsensitive(data.aws_ssm_parameter.eks_ami_release_version.value)
  instance_types  = ["t3.small"]

  scaling_config {
    desired_size = 1
    max_size     = 1
    min_size     = 1
  }


  # Ensure that IAM Role permissions are created before and deleted after EKS Node Group handling.
  # Otherwise, EKS will not be able to properly delete EC2 Instances and Elastic Network Interfaces.
  depends_on = [
    aws_iam_role_policy_attachment.node_group_policy,
    aws_iam_role_policy_attachment.cni_policy,
    aws_iam_role_policy_attachment.ecr_policy,
  ]

  lifecycle {
    ignore_changes = [scaling_config.0.desired_size]
  }
}

// IAM Configuration
resource "aws_iam_role" "node_group" {
  name               = "udacity-node-group"
  assume_role_policy = data.aws_iam_policy_document.assume_role_policy.json
}

resource "aws_iam_role_policy_attachment" "node_group_policy" {
  role       = aws_iam_role.node_group.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy"
}

resource "aws_iam_role_policy_attachment" "cni_policy" {
  role       = aws_iam_role.node_group.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy"
}

resource "aws_iam_role_policy_attachment" "ecr_policy" {
  role       = aws_iam_role.node_group.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly"
}

data "aws_iam_policy_document" "assume_role_policy" {
  statement {
    effect  = "Allow"
    actions = ["sts:AssumeRole"]
    principals {
      type        = "Service"
      identifiers = ["ec2.amazonaws.com"]
    }
  }
}

ECR repositories

# ECR Repositories

resource "aws_ecr_repository" "frontend" {
  name                 = "frontend"
  image_tag_mutability = "MUTABLE"
  force_delete         = true

  image_scanning_configuration {
    scan_on_push = true
  }
}

resource "aws_ecr_repository" "backend" {
  name                 = "backend"
  image_tag_mutability = "MUTABLE"
  force_delete         = true

  image_scanning_configuration {
    scan_on_push = true
  }
}

github action user for interacting in pipeline.

# Github Action role

resource "aws_iam_user" "github_action_user" {
  name = "github-action-user"
}

resource "aws_iam_user_policy" "github_action_user_permission" {
  user   = aws_iam_user.github_action_user.name
  policy = data.aws_iam_policy_document.github_policy.json
}

data "aws_iam_policy_document" "github_policy" {
  statement {
    effect    = "Allow"
    actions   = ["ecr:*", "eks:*", "ec2:*", "iam:GetUser"]
    resources = ["*"]
  }
}

outputs.tf

output "frontend_ecr" {
  value = aws_ecr_repository.frontend.repository_url
}
output "backend_ecr" {
  value = aws_ecr_repository.backend.repository_url
}

output "cluster_name" {
  value = aws_eks_cluster.main.name
}

output "cluster_version" {
  value = aws_eks_cluster.main.version
}

output "github_action_user_arn" {
  value = aws_iam_user.github_action_user.arn
}

variables.tf

variable "k8s_version" {
  default = "1.25"
}

variable "enable_private" {
  default = false
}

variable "public_az" {
  type        = string
  description = "Change this to a letter a-f only if you encounter an error during setup"
  default     = "a"
}

variable "private_az" {
  type        = string
  description = "Change this to a letter a-f only if you encounter an error during setup"
  default     = "b"
}

providers.tf

provider "aws" {
  region = "us-east-1"
}

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "4.55.0"
    }
  }
}

run terraform init to initialize the repository
terraform plan to validate before applying
terraform apply --auto-approve to apply without prompt

This will provision our infra

Run init.sh which adds the github-action-user IAM user ARN to the Kubernetes configuration that will allow that user to execute kubectl commands against the cluster.

#!/bin/bash
set -e -o pipefail

echo "Fetching IAM github-action-user ARN"
userarn=$(aws iam get-user --user-name github-action-user | jq -r .User.Arn)

# Download tool for manipulating aws-auth
echo "Downloading tool..."
curl -X GET -L https://github.com/kubernetes-sigs/aws-iam-authenticator/releases/download/v0.6.2/aws-iam-authenticator_0.6.2_linux_amd64 -o aws-iam-authenticator
chmod +x aws-iam-authenticator

echo "Updating permissions"
./aws-iam-authenticator add user --userarn="${userarn}" --username=github-action-role --groups=system:masters --kubeconfig="$HOME"/.kube/config --prompt=false

echo "Cleaning up"
rm aws-iam-authenticator
echo "Done!"

This script will download a tool, add the IAM user ARN to the authentication configuration, indicate a Done status, then it'll remove the tool.

Generate AWS access keys for Github Action user
- Go to AWS console, navigate to the IAM service
- Under users, the github-action-user user account should be there
- Click the account and go to Security Credentials
- Under Access keys select Create access key
- Select Application running outside AWS and click Next, then Create access key to finish creating the keys
- Finally, make sure to copy these keys for storing in Github Secrets
- In the github repository settings, click secrets tab, then actions, past these keys in the repo secrets
Backend CI/CD pipeline

name: Backend CD

on:
  push:
    branches:
      - main
    paths:
      - 'starter/backend/**'
  workflow_dispatch:

jobs:
  lint:
    name: Lint
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.10'

      - name: Cache pipenv dependencies
        uses: actions/cache@v3
        with:
          path: ~/.cache/pipenv
          key: ${{ runner.os }}-pipenv-${{ hashFiles('starter/backend/Pipfile.lock') }}
          restore-keys: |
            ${{ runner.os }}-pipenv-

      - name: Install dependencies
        run: pip install pipenv && pipenv install --dev
        working-directory: starter/backend

      - name: Run lint
        run: pipenv run lint
        working-directory: starter/backend

  test:
    name: Test
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.10'
          cache: 'pipenv'

      - name: Install pipenv
        run: curl https://raw.githubusercontent.com/pypa/pipenv/master/get-pipenv.py | python
      - run: pipenv install
        working-directory: starter/backend

      - name: Run tests
        run: pipenv run test
        working-directory: starter/backend

  build-and-push:
    name: Build Docker Image
    runs-on: ubuntu-latest
    needs: 
      - lint
      - test
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.10'
          cache: 'pipenv'

      - name: Install pipenv
        run: curl https://raw.githubusercontent.com/pypa/pipenv/master/get-pipenv.py | python
      - run: pipenv install
        working-directory: starter/backend

      - name: Build Docker image
        run: |
          docker build \
            --tag mp-backend:latest \
            .
        working-directory: starter/backend

      - name: Set up AWS CLI
        uses: aws-actions/configure-aws-credentials@v2
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1

      - name: Amazon ECR Login
        uses: aws-actions/amazon-ecr-login@v1

      - name: Tag and Push Docker Image
        run: |
          docker tag mp-backend:latest ${{ secrets.AWS_ACCOUNT_ID }}.dkr.ecr.us-east-1.amazonaws.com/backend:${{ github.sha }}
          docker push ${{ secrets.AWS_ACCOUNT_ID }}.dkr.ecr.us-east-1.amazonaws.com/backend:${{ github.sha }}

  deploy:
    name: Deploy to EKS
    runs-on: ubuntu-latest
    needs: build-and-push
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up AWS CLI
        uses: aws-actions/configure-aws-credentials@v2
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1

      - name: Amazon ECR Login
        uses: aws-actions/amazon-ecr-login@v1

      - name: Set up kubectl
        uses: azure/setup-kubectl@v3
        with:
          version: 'v1.25.0'

      - name: Update kubeconfig
        run: |
          aws eks --region us-east-1 update-kubeconfig --name cluster

      - name: Set image in Kubernetes manifests using Kustomize
        run: |
          kustomize edit set image backend=${{ secrets.AWS_ACCOUNT_ID }}.dkr.ecr.us-east-1.amazonaws.com/backend:${{ github.sha }}
        working-directory: starter/backend/k8s

      - name: Deploy to EKS using Kustomize
        run: |
          kustomize build | kubectl apply -f -
        working-directory: starter/backend/k8s

This runs lint and test jobs in parallel.
lint checks out the code, sets up Python, installs dependencies using pipenv, and then runs a linting tool to ensure the code adheres to style guidelines
test runs the test suite to ensure the application functions correctly
Proceeds to build docker image and push to the backend repo created in ECR.
Deploy the app code to the cluster using the manifest files present in the backend/.
Kustomize manages and overlays YAML files, enabling reusable and environment-specific configurations.

Before pushing this code to the github repository;

add AWS_ACCOUNT_ID to the github secrets

After pushing the code, the workflow should be triggered and run successfully;

run kubectl get svc to get the URL of the backend service
add the Backend_URL to the github repo secrets, frontend app needs it to connect to the backend_api
Frontend CI/CD pipeline

name: Frontend CD

on:
  push:
    branches:
      - main
    paths:
      - 'starter/frontend/**'
  workflow_dispatch:

jobs:
  lint:
    name: Lint
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 'lts/*'

      - name: Cache npm dependencies
        uses: actions/cache@v3
        with:
          path: ~/.npm
          key: ${{ runner.os }}-node-${{ hashFiles('starter/frontend/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-node-

      - name: Install dependencies
        run: npm ci
        working-directory: starter/frontend

      - name: Run lint
        run: npm run lint
        working-directory: starter/frontend

  test:
    name: Test
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 'lts/*'

      - name: Cache npm dependencies
        uses: actions/cache@v3
        with:
          path: ~/.npm
          key: ${{ runner.os }}-node-${{ hashFiles('starter/frontend/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-node-

      - name: Install dependencies
        run: npm ci
        working-directory: starter/frontend

      - name: Run tests
        run: CI=true npm test
        working-directory: starter/frontend

  build-and-push:
    name: Build Docker Image
    runs-on: ubuntu-latest
    needs: 
      - lint
      - test
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 'lts/*'

      - name: Cache npm dependencies
        uses: actions/cache@v3
        with:
          path: ~/.npm
          key: ${{ runner.os }}-node-${{ hashFiles('starter/frontend/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-node-

      - name: Install dependencies
        run: npm ci
        working-directory: starter/frontend

      - name: Build Docker image
        run: |
          docker build \
            --build-arg REACT_APP_MOVIE_API_URL=${{ secrets.BACKEND_URL }} \
            --tag mp-frontend:latest \
            .
        working-directory: starter/frontend

      - name: Set up AWS CLI
        uses: aws-actions/configure-aws-credentials@v2
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1

      - name: Amazon ECR Login
        uses: aws-actions/amazon-ecr-login@v1

      - name: Tag and Push Docker Image
        run: |
          docker tag mp-frontend:latest ${{ secrets.AWS_ACCOUNT_ID }}.dkr.ecr.us-east-1.amazonaws.com/frontend:${{ github.sha }}
          docker push ${{ secrets.AWS_ACCOUNT_ID }}.dkr.ecr.us-east-1.amazonaws.com/frontend:${{ github.sha }}

  deploy:
    name: Deploy to EKS
    runs-on: ubuntu-latest
    needs: build-and-push
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up AWS CLI
        uses: aws-actions/configure-aws-credentials@v2
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1

      - name: Amazon ECR Login
        uses: aws-actions/amazon-ecr-login@v1

      - name: Set up kubectl
        uses: azure/setup-kubectl@v3
        with:
          version: 'v1.25.0'

      - name: Update kubeconfig
        run: |
          aws eks --region us-east-1 update-kubeconfig --name cluster

      - name: Set image in Kubernetes manifests using Kustomize
        run: |
          kustomize edit set image frontend=${{ secrets.AWS_ACCOUNT_ID }}.dkr.ecr.us-east-1.amazonaws.com/frontend:${{ github.sha }}
        working-directory: starter/frontend/k8s

      - name: Deploy to EKS using Kustomize
        run: |
          kustomize build | kubectl apply -f -
        working-directory: starter/frontend/k8s

This does similar to what the backend CI/CD pipeline is doing.

It referenced the $Backend_URL to access the backend_api endpoint.
This workflow should be triggered on push
Run kubectl get svc and open the URL for the frontend service in a browser and the application should be live and displaying the data correctly

Best practices

Created a github-action-user for enhanced security:
This user is granted only the minimal permissions required to execute the workflow, reducing potential risks.
Utilized terraform plan for validation:
Ensures configurations are error-free before applying changes, allowing for easy rollback in case of failures.

Conclusion

This project demonstrates a modern DevOps approach to managing web application development, emphasizing automation, efficiency, and scalability.

Faster release cycles with automated workflows.
Enhanced code quality through linting and test validation.
Improved traceability and reliability with SHA-tagged Docker images.
Simplified deployment process to Kubernetes, reducing manual errors.

Checkout my Github

Deploying APIs as Microservice with Kubernetes, Docker, and AWS

AzeematRaji — Wed, 01 Jan 2025 01:14:07 +0000

Overview

This project demonstrates how to deploy a set of APIs as a microservice using Kubernetes, Docker, and AWS. The service is designed to manage application operations, leveraging PostgreSQL for efficient data storage and Flask to create the web API. Here’s a breakdown of each key component:

Kubernetes: Used for orchestrating containerized microservices. This allows us to deploy, scale, and manage the APIs in production.
Docker: Containers are used to package the microservices (Flask app and PostgreSQL) along with their dependencies, making the deployment process seamless.
AWS CodeBuild: Automates the build process of Docker images, pushing them to Elastic Container Registry (ECR).
PostgreSQL: Acts as the database for storing all user data, including usage statistics for the application.
CloudWatch: Monitors application performance and logs, ensuring that any issues can be diagnosed quickly.

Prerequisites:

Step by step instructions

Ensure AWS CLI is configured

aws sts get-caller-identity

Necessary IAM permissions is needed to create a cluster.

Install eksctl and use it to create an EKS cluster.

eksctl create cluster --name my-cluster --region us-east-1 --nodegroup-name my-nodes --node-type t3.small --nodes 1 --nodes-min 1 --nodes-max 2

--name my-cluster: Cluster name.
--region us-east-1: Region for the cluster.
--node-type t3.small: EC2 instance type for worker nodes.
--nodes 1, --nodes-min 1, --nodes-max 2: Auto-scaling configuration for the number of worker nodes (1 to 2).

Update the kubeconfig

aws eks --region us-east-1 update-kubeconfig --name my-cluster

This allows access to the cluster locally using kubectl

Verify connection

kubectl config current-context

Now we need to configure database for our application

Create a file pv.yaml to define the Persistent Volume (PV), which will be used to store data.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-manual-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: gp2
  hostPath:
    path: "/mnt/data"

storageClassName: gp2: Tells Kubernetes to use an AWS EBS (Elastic Block Store) for storage.

Create pvc.yaml to define the Persistent Volume Claim (PVC), which is used to bind the persistent volume to the application.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgresql-pvc
spec:
  storageClassName: gp2
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

It can be referenced in the database's deployment to mount the storage.

Create a file postgresql-deployment.yaml for Postgres Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgresql
spec:
  selector:
    matchLabels:
      app: postgresql
  template:
    metadata:
      labels:
        app: postgresql
    spec:
      containers:
      - name: postgresql
        image: postgres:latest
        env:
        - name: POSTGRES_DB
          value: mydatabase
        - name: POSTGRES_USER
          value: myuser
        - name: POSTGRES_PASSWORD
          value: mypassword
        ports:
        - containerPort: 5432
        volumeMounts:
        - mountPath: /var/lib/postgresql/data
          name: postgresql-storage
      volumes:
      - name: postgresql-storage
        persistentVolumeClaim:     #PVC referenced
          claimName: postgresql-pvc

Apply YAML configurations in the following order

kubectl apply -f pv.yaml
kubectl apply -f pvc.yaml
kubectl apply -f postgresql-deployment.yaml

Verify Database deployment

kubectl get pods

To open bash into the pod

kubectl exec -it <postgresql-name> -- bash

Once inside the pod, you can run psql -U myuser -d mydatabase to have access to the mydatabase database.

Create a YAML file, postgresql-service.yaml

Service needs to be created for the deployment to be exposed to other pods in the cluster

apiVersion: v1
kind: Service
metadata:
  name: postgresql-service
spec:
  ports:
  - port: 5432
    targetPort: 5432
  selector:
    app: postgresql

This targets pods on port 5432, which is the default port for PostgreSQL deployment pod.

Run kubectl apply -f postgresql-service.yaml
Verify the service kubectl get svc
psql is a lightweight client application for postgresql that enables connection to your postgres server and it must be installed

apt update
apt install postgresql postgresql-contrib

Run the seed files in db/ in order to create the tables and populate them with data in the database

export DB_PASSWORD=mypassword
PGPASSWORD="$DB_PASSWORD" psql --host 127.0.0.1 -U myuser -d mydatabase -p 5433 < <FILE_NAME.sql>

Verify the database is populated

PGPASSWORD="$DB_PASSWORD" psql --host 127.0.0.1 -U myuser -d mydatabase -p 5433 to open psql terminal

Run query select *from users; to ensure they are not empty.

Setting up Continous Integration with codebuild

Create an Amazon ECR repository on AWS console by navigating to ECR service
Create buildspec.yml file the root directory of the repository

version: 0.2

phases:
  pre_build:
    commands:
      - echo Logging into ECR
      - aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com
  build:
    commands:
      - echo Starting build at `date`
      - echo Building the Docker image...          
      - docker build -t $IMAGE_REPO_NAME:$CODEBUILD_BUILD_NUMBER -f analytics/Dockerfile .
      - docker tag $IMAGE_REPO_NAME:$CODEBUILD_BUILD_NUMBER $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$IMAGE_REPO_NAME:$CODEBUILD_BUILD_NUMBER     
  post_build:
    commands:
      - echo Completed build at `date`
      - echo Pushing the Docker image...
      - docker push $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$IMAGE_REPO_NAME:$CODEBUILD_BUILD_NUMBER

This template is what the CodeBuild will use to build docker image and push to the ECR repository. The placehoders in this file would need to be set in the CodeBuild project.

Create an Amazon CodeBuild project;
- navigate to the Codebuild service, click create a new project
- enter the project name
- select github as the source code provider
- authorize AWS to access project's GitHub repository and to run on push to the repository
- configure the environment
- check the priviledge box to enable docker build in the codebuild
- select new service role in the absence of existing service role but note: ECR permission must be added to it
- set variables based on the placeholders in the buildspec.yml like $AWS_DEFAULT_REGION $AWS_ACCOUNT_ID $IMAGE_REPO_NAME
- specify the buildspec file, (buildspec.yml ensure it is in the root of your source repository)
Modify the IAM role of the newly created service role by the codebuild, add inline policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ecr:*"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

Push the buildSpec.yml to the github repository and the codebuild should be triggered and the build should be successful

Verify the image in ECR

Deploy the Application

Create a Configmap.yaml for the external configuration of the app, in this case our database values and Secret store all the sensitive environment variables such as (DB_PASSWORD)

apiVersion: v1
kind: ConfigMap
metadata:
  name: postgresql-service
data:
  DB_NAME: "mydatabase"
  DB_USER: "myuser"
  DB_HOST: "10.100.30.162"
  DB_PORT: "5432"
---
apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  password: "bXlwYXNzd29yZA=="

Run kubectl apply -f configmap.yaml

Create coworking.yaml for the service and deployment of the application, the docker image is the URI of the image we pushed to ECR, configmap and secret is referenced too.

apiVersion: v1
kind: Service
metadata:
  name: coworking
spec:
  type: LoadBalancer
  selector:
    service: coworking
  ports:
  - name: "5153"
    protocol: TCP
    port: 5153
    targetPort: 5153
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: coworking
  labels:
    name: coworking
spec:
  replicas: 1
  selector:
    matchLabels:
      service: coworking
  template:
    metadata:
      labels:
        service: coworking
    spec:
      containers:
      - name: coworking
        image: 739244444072.dkr.ecr.us-east-1.amazonaws.com/api-service-img-redo:16
        imagePullPolicy: IfNotPresent
        livenessProbe:
          httpGet:
            path: /health_check
            port: 5153
          initialDelaySeconds: 5
          timeoutSeconds: 2
        readinessProbe:
          httpGet:
            path: "/readiness_check"
            port: 5153
          initialDelaySeconds: 5
          timeoutSeconds: 5
        envFrom:
        - configMapRef:
            name: postgresql-service
        env:
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysecret
              key: password
      restartPolicy: Always

Run kubectl apply -f coworking.yaml

Verify the deployment

kubectl get pods

kubectl get svc

kubectl describe svc <DATABASE_SERVICE_NAME>

kubectl describe deployment <SERVICE_NAME>

The application is running successfully.

Monitoring container Insight logs for the applications with Cloudwatch
- navigate to the Cloudwatch service on the console
- go to the logs menu, log groups, the cluster is present there
- now go to the terminal to change the eks node group IAM role

aws iam attach-role-policy \
--role-name my-worker-node-role \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy

To get the name of the node group IAM role, go to your cluster, then compute, click on the active node group to get the name of IAM role, replace my-worker-node-role

run another command to install addons for the eks cluster

aws eks create-addon --addon-name amazon-cloudwatch-observability --cluster-name my-cluster

check the log groups on the console again, aws/containerinsights/my-cluster-name/application should be there, Click on one of the log streams to see the logs.

The logs that show the health of the application

Conclusion

Kubernetes, Docker, and AWS enable scalable and reliable microservice deployments.
AWS CodeBuild automates building, pushing, and deploying application updates.
PostgreSQL ensures effective data storage, while CloudWatch provides effective monitoring.
This setup creates a maintainable system ready for production.

Deploying an Application Using CloudFormation with CDN Integration

AzeematRaji — Mon, 30 Dec 2024 16:44:27 +0000

Introduction:

This project automates the deployment of the application on AWS using Infrastructure as Code (IaC) with AWS CloudFormation. The infrastructure is divided into separate stacks: one for the network setup and one for the application deployment. The goal is to provision, configure, and tear down the necessary infrastructure with ease. It also integrates a Content Delivery Network (CDN) to enhance application performance and ensure global availability.

Infrastructure diagram

Project Overview

This project uses CloudFormation to provision the following resources:

VPC with public and private subnets
Load Balancer to handle HTTP/HTTPS traffic
EC2 instances running the application
S3 for static content storage
CloudFront for content delivery
IAM roles and policies for security

The deployment is divided into two independent stacks:

Network Stack: Managed by the network team, this stack provisions VPCs, subnets, and security groups.
Application Stack: Responsible for provisioning the application components, including EC2 instances, load balancers, S3, and CloudFront.

Prerequisites:

AWS account with appropriate permissions
AWSCLI Install awscli and configured
Basic knowledge of CloudFormation and its template structure.
CloudFormation templates for both the Network and Application stacks.
Scripts to create, update, deploy and delete the stacks.

Spin up instructions

To spin up your infrastructure using the provided scripts, follow the steps below:

script to create stack:

#!/bin/bash

# Usage: ./create.sh <stack-name> <template-file> <parameters-file>

aws cloudformation create-stack --stack-name $1 \
    --template-body file://$2   \
    --parameters file://$3  \
    --capabilities "CAPABILITY_NAMED_IAM"  \
    --region=us-east-1

You can edit the scripts to either delete, deploy or update stack, the purpose of the scripts is to avoid running the multiple line commands everytime.

make the scripts executable

chmod +x <scripts.sh>

Use the create.sh script to create a new CloudFormation stack, create the network stack first since the application stack depends on it resources (like vpc, subnets)
The script requires three parameters (such as StackName, ParameterFile, and TemplateFile. You will need to pass these parameters as per the instructions in the script.

./create.sh StackName ParameterFile TemplateFile

In this case

./create.sh networkStack network-parameters.json network.yml

This script creates a new stack with the provided parameters.

Update an existing stack:

./update.sh StackName ParameterFile TemplateFile

This script will update the stack with new configurations based on the changes in the parameter or template file.

Deploy a stack:

./deploy.sh StackName ParameterFile TemplateFile

The deploy.sh script checks if the stack already exists. If it does, the script will update the stack; if it doesn't, it will create a new stack. It very useful for automation like CI/CD pipeline

create stack for the application as well ParameterFile, TemplateFile.

./create.sh networkStack udagram-parameters.json udagram.yml

Confirm your application is live

CloudFrontURL: https://d1gjuuten5htu8.cloudfront.net

WebAppLBDNS: http://udagra-WebAp-mMkpfHQBWeXO-1923467063.us-east-1.elb.amazonaws.com

Tear down the deployed resources, follow these instructions:

./delete.sh StackName

Use the delete.sh script to delete a stack. The script only requires one parameter: the name of the stack you wish to delete.

Conclusion

Cloudformation streamlines resource creation and reduces manual errors.
Improves scalability, easy to replicate the setup in different environments.
CDN Integration improves performance and ensures low latency worldwide.

How to Host a Static Website on AWS S3 with CloudFront CDN

AzeematRaji — Mon, 30 Dec 2024 14:30:22 +0000

Objective:

To host a static website on AWS S3 and optimize its performance and security using CloudFront as a Content Delivery Network (CDN), ensuring fast and secure global content delivery.

Prerequisite:

Active AWS account for setting up services.
Pre-built static website content (e.g., HTML, CSS, JavaScript files).

Step 1: Create an S3 Bucket

Log in to the AWS Management Console and navigate to the S3 Service.
Create a bucket with a globally unique name.
Enable public access to allow your website to be publicly accessible.

Step 2: Upload files and folder to the bucket

Click upload on the newly created bucket
Upload .html file as a file, then upload others as folder

Step 3: Configure the bucket to allow static web hosting

Click on properties tab in the bucket, Enable Static Website Hosting and edit
Choose "Host a static website" as the hosting option.
Specify Index and Error Documents
Enter the name of your main file (e.g index.html) in the Index Document field.
Specify an error file (e.g., 404.html) for handling invalid URLs. (Optional)
After saving, copy the Website Endpoint, the URL will be address for your website.

Step 4: create IAM bucket policy that makes the bucket contents publicly accessible.

Click on permission in the bucket
Edit the bucket policy with this

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AddPerm",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::your-bucket-name/*"
        }
    ]
}

Save and open the website endpoint URL from Step 3 in a browser to ensure the website is accessible.

Step 5: Set Up a CloudFront Distribution

Navigate to cloudfront service, create a distribution
Configure the settings; add origin domain, enter index.html into default root object

Step 6: Copy the domain URL and check it on the browser to confirm access to your website

Conclusion

Benefits of Using CloudFront:

Speeds up content delivery with edge locations.
Provides an SSL certificate for secure connections.
Offers caching to reduce latency and S3 bucket costs.

Streamlining CI/CD with GitHub Actions: Provision and Deploy Infrastructure Seamlessly Using Terraform

AzeematRaji — Thu, 17 Oct 2024 10:56:13 +0000

Terraform:
Terraform is an open-source Infrastructure as Code (IaC) tool used to automate and manage cloud infrastructure. It allows you to define infrastructure resources (like servers, databases, and networks) in declarative configuration files and then provision them consistently across different environments.

Kubernetes:
Kubernetes is an open-source container orchestration platform designed to automate the deployment, scaling, and management of containerized applications. It helps ensure high availability, scalability, and efficient resource utilization across clusters of machines.

GitHub Actions:
GitHub Actions is a CI/CD platform that allows you to automate workflows directly within your GitHub repository. It enables tasks like building, testing, and deploying code whenever specific events occur (e.g., push or pull requests). You can define workflows using YAML files to handle continuous integration and deployment pipelines.

These tools work well together to streamline infrastructure management and application deployment.

Objectives

Improve deployment scalability and reliability: Use Kubernetes to ensure that applications can scale automatically.
Streamline CI/CD pipeline: Create a seamless CI/CD pipeline using GitHub Actions to automate infrastructure and application deployments efficiently, reducing manual intervention.
Using terraform:

Ensure a fully automated, consistent, reproducible, and reliable infrastructure deployment across various environments.
Leveraging its unified workflow and lifecycle management features to ensure easy updates and scaling.

Prerequisites

AWS account
IAM user with administrator or neccessary role enabled
Terraform Install terraform
AWSCLI Install awscli

Step by step guide
lets run our code manually before we attempt using CI/CD workflow.

Configure your AWS credentials so that the AWS CLI can authenticate and interact with your AWS account

aws configure

Create a terraform diretory and cd into it

mkdir terraform
cd terraform

Create terraform configuration files

providers.tf contains all the providers needed for this project

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }

    kubernetes = {
      source = "hashicorp/kubernetes"
      version = "2.30.0"
    }
  }
}

# Configure the AWS Provider
provider "aws" {
  region = var.region
}

variables.tf defines input variables

variable region {}
variable cluster_name {}
variable vpc_name {}
variable vpc_cidr_block {}
variable private_subnet_cidr_blocks {}
variable public_subnet_cidr_blocks {}

main.tf contains;

Modules for VPC and EKS Cluster: creates a Virtual Private Cloud (VPC) and an Amazon EKS cluster, allowing for simpler and more concise code.
Kubernetes Provider: defines the Kubernetes provider for Terraform to deploy Kubernetes resources on the created cluster, all within a single .tf file, this ensures unified workflow and full life cycle management
Configure the Kubernetes Provider: Using cloud specific plugins, the exec plugin is utilized in the Kubernetes provider block to handle authentication, as the AWS token expires every 15 minutes.

# Filter out local zones, which are not currently supported 
# with managed node groups

data "aws_availability_zones" "available" {
  filter {
    name   = "opt-in-status"
    values = ["opt-in-not-required"]
  }
}


module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.13.0"

  name = var.vpc_name

  cidr = var.vpc_cidr_block
  azs  = slice(data.aws_availability_zones.available.names, 0, 3)

  private_subnets = var.private_subnet_cidr_blocks
  public_subnets  = var.public_subnet_cidr_blocks

  enable_nat_gateway   = true
  single_nat_gateway   = true
  enable_dns_hostnames = true

  # This enables automatic public IP assignment for instances in public subnets
  map_public_ip_on_launch = true

  public_subnet_tags = {
    "kubernetes.io/role/elb" = 1
  }

  private_subnet_tags = {
    "kubernetes.io/role/internal-elb" = 1
  }
}

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "20.24.2"

  cluster_name    = var.cluster_name
  cluster_version = "1.29"

  cluster_endpoint_public_access           = true
  enable_cluster_creator_admin_permissions = true


  vpc_id     = module.vpc.vpc_id
  subnet_ids = module.vpc.public_subnets

  # Additional security group rules
  node_security_group_additional_rules = {
    allow_all_traffic = {
      description                  = "Allow traffic from the internet"
      protocol                     = "-1"  # Allow all protocols
      from_port                    = 0
      to_port                      = 65535  # Allow all ports
      cidr_blocks                  = ["0.0.0.0/0"]  # Allow from anywhere
      type                         = "ingress"
    }
  }  


  eks_managed_node_group_defaults = {
    ami_type = "AL2_x86_64"

  }

  eks_managed_node_groups = {
    one = {
      name = "node-group-1"

      instance_types = ["t2.micro"]

      min_size     = 1
      max_size     = 2
      desired_size = 1
    }

    two = {
      name = "node-group-2"

      instance_types = ["t2.micro"]

      min_size     = 1
      max_size     = 2
      desired_size = 1
    }
  }
}



# Retrieve EKS cluster information and ensure data source waits for cluster to be created

data "aws_eks_cluster" "myApp-cluster" {
  name = module.eks.cluster_name
  depends_on = [module.eks]
}

data "aws_eks_cluster_auth" "myApp-cluster" {
  name = module.eks.cluster_name
}

#Kubernetes provider for Terraform to connect with AWS EKS Cluster

provider "kubernetes" {

  host                   = data.aws_eks_cluster.myApp-cluster.endpoint
  cluster_ca_certificate = base64decode(data.aws_eks_cluster.myApp-cluster.certificate_authority[0].data)
  exec {
    api_version = "client.authentication.k8s.io/v1beta1"
    args        = ["eks", "get-token", "--cluster-name", var.cluster_name]
    command     = "aws"
  }
}

#Kubernetes resources in Terraform

resource "kubernetes_namespace" "terraform-k8s" {

  metadata {
    name = "terraform-k8s"
  }
}

resource "kubernetes_deployment" "nginx" {

  metadata {
    name      = "nginx"
    namespace = kubernetes_namespace.terraform-k8s.metadata[0].name

  }

  spec {
    replicas = 2
    selector {
      match_labels = {
        app = "nginx"
      }
    }

    template {
      metadata {
        labels = {
          app = "nginx"
        }
      }

      spec {
        container {
          name  = "nginx"
          image = "nginx:1.21.6"

          port {
            container_port = 80
          }

          resources {
            limits = {
              cpu    = "0.5"
              memory = "512Mi"
            }
            requests = {
              cpu    = "250m"
              memory = "50Mi"
            }
          }
        }
      }
    }
  }
}



resource "kubernetes_service" "nginx" {

  metadata {
    name      = "nginx"
    namespace = kubernetes_namespace.terraform-k8s.metadata[0].name
  }

  spec {
    selector = {
      app = kubernetes_deployment.nginx.spec[0].template[0].metadata[0].labels.app
    }

    port {
      port        = 80
      target_port = 80
    }

    type = "LoadBalancer"
  }
}

outputs.tf define output values that are displayed after the deployment completes

output "cluster_endpoint" {
  description = "Endpoint for EKS control plane"
  value       = module.eks.cluster_endpoint
}

output "cluster_security_group_id" {
  description = "Security group ids attached to the cluster control plane"
  value       = module.eks.cluster_security_group_id
}

output "region" {
  description = "AWS region"
  value       = var.region
}

output "cluster_name" {
  description = "Kubernetes Cluster Name"
  value       = module.eks.cluster_name
}

output "nginx_load_balancer_ip" {
  description = "output Load Balancer IP to access from browser"
  value = kubernetes_service.nginx.status[0].load_balancer[0].ingress[0].ip
}

terraform.tfvars file assigns values to the input variables defined in variables.tf. This file contains sensitive information, such as AWS credentials or other configuration settings, and should not be exposed publicly, such as by pushing it to GitHub. Instead, it's best practice to store it as a secret variable in your repository's settings to ensure that sensitive information is kept secure.

Run the terraform command

terraform init initializes the repository, adding all the dependencies required.

terraform plan plan the changes to be added or removed, essentially a preview of what terraform apply will do, allowing you to review and confirm

terraofrm apply --auto-approve apply without prompt

Confirm cluster is created and application is properly deployed on it, this can be done in two ways:

aws console - check if cluster is running, nodes are healthy, check the loadbalancer for ip or dns name, open via browser, nginx app is successfully displayed

using kubectl - install kubectl, configure the kubectl to interact with the cluster aws eks --region us-east-1 update-kubeconfig --name <cluster_name>. can run kubectl commands to get deployment, service, pods and others kubectl get all -n <namespace>

Run terraform destroy --auto-approve we can safely destroy after confirm the configuration files are good.
CI/CD workflow - to run this fully automated, create .github/workflows directory and two yaml files in it, one is execute our terraform apply and the other to destroy when done.

terraform.yaml _ save your access key, secret key and region in your repository secret variable_

# This is a basic workflow to help you deploy nginx on EKS using terraform

name: Terraform EKS Deployment

# Controls when the workflow will run
on:
  # Triggers the workflow on push events but only for the "main" branch
  push:
    branches: [ "main" ]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains multiple jobs terraform,
  terraform:
    name: Deploy EKS Cluster
    # The type of runner that the job will run on
    runs-on: ubuntu-latest

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Step 1: Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - name: Checkout Code
        uses: actions/checkout@v4

      # Step 2: Setup AWS Credentials
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_REGION }}

      # Step 3: Setup Terraform
      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v2
        with:
          terraform_version: 1.9.6

      # Step 4: Terraform Init
      - name: Terraform Init
        run: terraform init

      # Step 5: Terraform Plan
      - name: Terraform Plan
        run: terraform plan

      # Step 6: Terraform Apply
      - name: Terraform Apply
        id: apply
        run: terraform apply -auto-approve

terraform-destroy.yml it's essential to have access to the .tfstate file to ensure that you can properly delete the resources you created, such as the cluster. Instead of pushing your .tfstate to a repository (which is not secure), you should store it remotely. One recommended option is using an S3 bucket as the remote backend for your Terraform state.

To do this, you can create a backend.tf file that specifies the S3 bucket as the remote backend for storing the .tfstate file.

terraform {
  backend "s3" {
    bucket = "terraform-statefile-backup-storage"
    key    = "eks-cluster/terraform.tfstate"
    region = "us-east-1"
  }
}

terraform-destroy.yml set to run manually instead of running on push

name: Terraform Destroy EKS Cluster

on:
  workflow_dispatch: # Manually triggered workflow

jobs:
  terraform:
    name: Destroy EKS Cluster
    runs-on: ubuntu-latest

    steps:
      - name: Checkout Code
        uses: actions/checkout@v4

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_REGION }}

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v2
        with:
          terraform_version: 1.9.6

      - name: Terraform Init
        run: terraform init

      - name: Terraform Plan Destroy
        run: terraform plan -destroy

      - name: Terraform Destroy
        run: terraform destroy -auto-approve

Push to Github, and the terraform.yml will run on push

Confirm by accessing your loadbalancer IP or dns name via browser

Manually run the workflow of terraform-destroy.yml

Conclusion

Time-Saving: Automating the deployment process saves time and effort, making it easier to manage infrastructure.
Consistency: Automation leads to more reliable deployments, reducing mistakes and ensuring everything works as expected.
Scalability: Automated workflows can easily grow with your project, allowing for faster updates without losing quality.
Better Teamwork: Integrating tools like Terraform and Kubernetes with GitHub Actions helps team members collaborate more effectively.
Flexibility: A well-defined CI/CD pipeline allows teams to quickly adjust to changes, improving overall project speed and adaptability.

Check out my Github