Forem: Kelechi Edeh

Understanding Docker, Containers, and How to Dockerize Your Application

Kelechi Edeh — Sat, 12 Jul 2025 15:32:21 +0000

In today's software development world, the shift from monolithic to microservices architecture has revolutionized how we build and deploy applications. At the heart of this evolution is Docker a platform that enables developers to package, ship, and run applications in lightweight, portable containers.

This article provides a comprehensive overview of Docker, explains what containers are, and walks through the process of dockerizing an application with practical examples.

What Is Docker?

Docker is an open-source platform that allows developers to automate the deployment of applications inside lightweight, portable containers. These containers run consistently across any environment—whether it's a developer's laptop, a test server, or a production cloud environment.

Docker uses containerization technology to package an application with all its dependencies, configuration files, libraries, and binaries, ensuring it will run the same regardless of where it's deployed.

What Are Containers?

A container is a standard unit of software that encapsulates an application and all its dependencies so it can run quickly and reliably across different environments.

Unlike virtual machines (VMs), containers do not include a full operating system. They share the host OS kernel and isolate the application processes. This makes them more lightweight and faster to start compared to VMs.

Containers vs Virtual Machines

Here’s a quick comparison between Virtual Machines and Containers:

Feature	Virtual Machines	Containers
OS	Includes guest OS	Shares host OS kernel
Resource Usage	Heavy (more memory & CPU)	Lightweight
Boot Time	Minutes	Seconds
Portability	Less portable	Highly portable

Docker Architecture

Docker has three major components:

Docker Client – CLI tool (docker) that users interact with.
Docker Daemon – Runs in the background to manage containers.
Docker Images – Read-only templates used to create containers.
Docker Containers – Running instances of Docker images.
Docker Registry – A repository for Docker images (e.g., Docker Hub).

Why Use Docker?

Consistency across environments
Rapid deployment and scalability
Isolation of applications
Efficient CI/CD integration
Simplified dependency management
Microservices support

Setting Up Docker

Install Docker from the official website or use your system’s package manager:

Ubuntu: sudo apt install docker.io
macOS: Use Docker Desktop
Windows: Use Docker Desktop (WSL 2 backend recommended)

Check installation:

docker --version

Dockerizing an Application

To show you how to dockerize an application, I have dockerized a Prime Video clone built with React. The original frontend project can be found here: Prime Video Clone on GitHub. My Docker setup allows the app to run consistently across environments, making it production-ready and easily deployable.

Create a Dockerfile

A Dockerfile is a text file that contains a set of instructions Docker uses to build a Docker image. Think of it as a blueprint for packaging your application and its environment (OS, libraries, dependencies, etc.) into a portable container.

When you run docker build, Docker reads the Dockerfile line by line, executing each instruction to assemble the final image.

Inside your project root (prime-video-clone/), create a Dockerfile

# Use official Node.js base image for build step
FROM node:20-alpine

# Set working directory
WORKDIR /app

# Copy package files and install dependencies
COPY package*.json .
RUN npm install


# Copy the rest of the source code
COPY . .

# Expose port 3000
EXPOSE 3000

# Start app
CMD [ "npm", "start"]

Add a .dockerignore File

Exclude unnecessary files from your Docker build context:

node_modules
build
.dockerignore
Dockerfile
.git
.gitignore

Build the Docker Image

Open your terminal and run:

docker build -t kelzceana/prime-video-appe .

Run the Container

To run the app locally on port 3000

docker run -d -p 3000:3000 kelzceana/prime-video-app

code repository

Conclusion

Dockerizing your Prime Video clone not only improves the developer experience, but also prepares your app for real-world deployment scenarios. You now have a portable, production-ready version of your React frontend all in a single container.

Step-by-Step Guide: Creating an Amazon EKS Cluster Using Terraform

Kelechi Edeh — Mon, 07 Jul 2025 21:44:00 +0000

Manually provisioning cloud infrastructure can be repetitive and error-prone. Tools like Terraform allow us to define our infrastructure as code, making deployments repeatable, auditable, and scalable.

In this article, I’ll walk you through how I created a production-ready Amazon EKS cluster using Terraform, AWS, and two powerful open-source modules:

What is Terraform?

Terraform is an open-source Infrastructure as Code (IaC) tool developed by HashiCorp. It allows you to define, provision, and manage cloud infrastructure using declarative configuration files. Rather than clicking through web consoles, Terraform empowers you to codify your infrastructure and manage it just like your application code with versioning, collaboration, and automation.

Why Use Terraform for AWS EKS?

Amazon Elastic Kubernetes Service (EKS) is a managed Kubernetes service that simplifies running Kubernetes on AWS without the operational overhead of managing the control plane.

Provisioning EKS manually can be complex due to the number of components involved (VPCs, subnets, IAM roles, node groups, etc.). Terraform removes this complexity by:

Enabling repeatable and auditable deployments.
Simplifying dependency management between AWS resources.
Integrating with CI/CD pipelines for automated infrastructure changes.

Prerequisites

Before creating an EKS cluster, ensure you have:

An AWS account and credentials configured locally
Terraform installed (terraform -v)
AWS CLI installed and configured (aws configure)
Basic knowledge of Terraform syntax

Project Structure

To keep things clean and efficient, I used only three main files to deploy both the networking (VPC) and the EKS cluster, leveraging the official Terraform modules for best practices.

Here’s what my final project structure looks like:
├── eks.tf ├── provider.tf ├── terraform.tfstate ├── terraform.tfvars └── vpc.tf
By keeping networking and compute separate, I can manage, extend, or even reuse each part of the infrastructure more easily.

Networking with terraform-aws-modules/vpc/aws

In vpc.tf, I used the terraform-aws-modules/vpc/aws module to create a complete VPC setup with:

Public and private subnets across multiple AZs
A NAT Gateway
Required tags for EKS subnet auto-discovery
DNS and VPN gateway support (optional for hybrid setups)

Here’s the simplified breakdown of what this module gives me:

# Configure the AWS Provider
provider "aws" {
  region = "us-east-1"
}


variable vpc_cidr_blocks {}
variable public_subnet_cidr_blocks {}
variable private_subnet_cidr_blocks {}

data "aws_availability_zones" "azs" {}

module "my-eks-cluster-vpc" {
  source = "terraform-aws-modules/vpc/aws"
  version = "5.1.2"

  name = "my-vpc"
  cidr = var.vpc_cidr_blocks
  private_subnets = var.private_subnet_cidr_blocks
  public_subnets = var.public_subnet_cidr_blocks

  azs = data.aws_availability_zones.azs.names


  enable_nat_gateway = true
  enable_vpn_gateway = true
  enable_dns_hostnames = true

  tags = {
    "kubernetes.io/cluster/my-eks-cluster" = "shared"

  }

  public_subnet_tags = {
    "kubernetes.io/cluster/my-eks-cluster" = "shared"
    "kubernetes.io/role/elb" = 1
  }
  private_subnet_tags = {
    "kubernetes.io/cluster/my-eks-cluster" = "shared"
    "kubernetes.io/role/internal-elb" = 1
  }
}

Why tagging matters:
EKS needs to know which subnets it can use for placing worker nodes and load balancers. The tags kubernetes.io/cluster/<name> and kubernetes.io/role/internal-elb or elb signal to AWS which subnets are eligible

Deploying EKS with terraform-aws-modules/eks/aws

In eks.tf, I used the terraform-aws-modules/eks/aws module to spin up the Kubernetes control plane and a managed node group.

Here’s what it includes:

EKS control plane with the latest version
IAM roles and security groups (auto-generated)
Managed node group with autoscaling
Automatic subnet and VPC discovery from the vpc module

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

  cluster_name = "my-eks-cluster"
  cluster_version = "1.30"

  subnet_ids = module.my-eks-cluster-vpc.private_subnets
  vpc_id = module.my-eks-cluster-vpc.vpc_id

  tags = {
    env = "dev"
  }

  #node group configuration
   eks_managed_node_groups = {
    dev = {
      min_size     = 1
      max_size     = 3
      desired_size = 2

      instance_types = ["t2.small"]
    }
  }


}

Using terraform.tfvars for Inputs

To separate logic from data, I defined my VPC CIDR and subnet ranges in terraform.tfvars like this:

vpc_cidr_blocks = "10.0.0.0/16"
private_subnet_cidr_blocks = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
public_subnet_cidr_blocks = ["10.0.4.0/24", "10.0.5.0/24", "10.0.6.0/24"]

This makes the code reusable just update the .tfvars file to spin up a new environment (e.g., staging, production, dev).

S3 Native State Locking

One nice bonus I added: S3 native locking. In previous Terraform versions, you needed a DynamoDB table for state locking. But with AWS Provider v5.20.0+, you can use use_lockfile = true to enable native state locking directly in S3.

resource "aws_s3_bucket" "terraform_state" {
  bucket = "terraform-state-bucker12345"

  lifecycle {
    prevent_destroy = false
  }
}

terraform {  
  backend "s3" {  
    bucket       = "terraform-state-bucker12345"  
    key          = "dev/terraform-state-file"  
    region       = "us-east-1"  
    encrypt      = true  
    //use_lockfile = true  #S3 native locking
  }  
}

This keeps my state safe from concurrent edits without needing a separate DynamoDB table.

Wrapping up

In this article, I demonstrated how to provision a production-ready Amazon EKS cluster using just a few Terraform files and the official AWS modules for VPC and EKS.

By leveraging:

The terraform-aws-modules/vpc/aws module for a highly available and EKS-compatible VPC,
The terraform-aws-modules/eks/aws module to simplify Kubernetes cluster provisioning,
And S3 native locking to manage Terraform state securely without DynamoDB,

I was able to deploy a scalable and maintainable Kubernetes environment using clean, modular infrastructure-as-code. This setup is not only efficient and reusable but also adheres to AWS best practices.

code repo

Creating a Secured Kubernetes Cluster on Amazon EKS

Kelechi Edeh — Sat, 05 Jul 2025 03:27:48 +0000

Amazon Elastic Kubernetes Service (EKS) makes it easier to deploy, manage, and scale containerized applications using Kubernetes on AWS. But for production environments, ensuring the security of your cluster is critical especially when deploying it inside a private network.

In this article, I document how I deployed a fully secured Amazon EKS (Elastic Kubernetes Service) cluster inside private subnets using AWS best practices. My approach ensured that the Kubernetes control plane, worker nodes, and sensitive services were all protected from public exposure while still being fully manageable and scalable.

Security Considerations Before You Begin

Before diving into the technical steps, I aligned my infrastructure design with core security principles in AWS and Kubernetes. Here are the key things I considered while designing the cluster:

VPC and Subnet Design: I ensured the EKS nodes were launched in private subnets, and only necessary resources like the bastion host resided in public subnets.
IAM and Identity Management: I created distinct IAM roles for the EKS control plane, node group, and EC2 bastion host using the principle of least privilege.
Node Security: Nodes were isolated, updated, and assigned minimal permissions.
Bastion Host for Access: I deployed a bastion host as a secure jump box, with SSH restricted to my IP address.
Kubernetes Network Policies: I applied policies to control pod-to-pod communication within the cluster.
Secrets and Configuration Management: Kubernetes secrets were encrypted using AWS KMS.
Logging and Monitoring: I enabled logging to Amazon CloudWatch and audit trails via CloudTrail and GuardDuty.
Control Plane Access: I limited EKS API server access to specific IPs and used RBAC for access control.
Use of IRSA (IAM Roles for Service Accounts): This ensured fine-grained pod-level permissions without over-privileging node IAM roles.
Cluster Updates and Maintenance: I deployed the latest Kubernetes version and hardened AMIs, with plans to automate updates.

Steps I Took to Deploy the Cluster

Step 1: Created a Custom VPC with Public and Private Subnets

I began by creating a custom VPC with:

2 public subnets: to host internet-facing resources like a bastion host.
2 private subnets: dedicated to hosting the EKS worker nodes and the control plane.

Each pair of public/private subnets was spread across two Availability Zones to ensure high availability. I also ensured the private subnets had no direct route to the internet, and only communicated outward through NAT Gateways in the public subnets.

Step 2: Create IAM Role for the EKS Cluster Control Plane

You need an IAM role that allows EKS to create and manage resources on your behalf. To allow EKS to interact with other AWS services, I created an IAM role for the EKS control plane with the AmazonEKSClusterPolicy and AmazonEKSServicePolicy attached.

This IAM role will be specified during cluster creation to ensure the control plane had the necessary permissions to manage resources securely.
To create this IAM role, follow these steps:

Navigate to the IAM Roles section in the AWS Console.
Click on Create role.
Under Trusted entity type, choose AWS service.
For the use case, select EKS - Cluster
Attach the policies to the role
Review and click Create

Step 3: Create the EKS Cluster

The EKS cluster using the AWS Management Console.

Navigate to EKS > Clusters
Click Create Cluster
Under Name, enter secure-eks-cluster
Select the Kubernetes version
Under Cluster Service Role, select the IAM role you created earlier
Choose VPC and subnets created in Step 1
Enable Private access to the Kubernetes API server and disable public access in the cluster endpoint access
Enable control plane logging (audit, API, authenticator, etc.)
For Amazon EKS add-ons, i selected the CoreDNS, Amazon VPC CNI, and kube-proxy add-ons
Click Create

Creating the eks cluster may take several minutes. Wait for the cluster status to change to "Active."

Step 4: Create IAM Role for Node Group

Creating a node group requires IAM roles to be used by the nodes.

Go to IAM > Roles > Create Role
Choose EC2
Attach:
- AmazonEKSWorkerNodePolicy
- AmazonEKS_CNI_Policy
- AmazonEC2ContainerRegistryReadOnly
Name the role
Click create

Step 5: Create Security Group for Node Group

Before creating your node group, it's important to set up a security group that defines how the nodes can communicate.

How to Create the Security Group

Navigate to EC2 > Security Groups
Click Create Security Group
Name it
Select your VPC
Under Inbound rules, add:
Type: SSH, Source: My IP
This allows internal traffic within the cluster. You can further tighten this based on workloads.
Under Outbound rules, keep the default: All traffic allowed. Click Create security group

You will associate this security group with the node group in the next step.

Step 6: Create Node Group in EKS Cluster

A node group is a group of EC2 instances that supply compute capacity to your Amazon EKS cluster. Multiple node groups can be added to the cluster

In the EKS Console, go to your cluster > Compute tab
Click Add Node Group
Enter name of node group
Select the IAM role created in step 4
Choose instance type (e.g., t3.medium), desired size, min and max nodes
Select the private subnets
Configure remote access to node and select your valid key pair
Select the security group created in step 5
Review and Create

Step 7: Launch a Bastion Host

A bastion host (also called a jump box) is a special-purpose EC2 instance used to securely access resources in a private network such as your EKS worker nodes or Kubernetes control plane without exposing those resources to the public internet.

The EKS cluster created above was created with private endpoint access only. This means it cannot be reached from your local machine or the public internet. A bastion host solves this by acting as a secure intermediary.

To access your private EKS cluster, create a bastion host in a public subnet.

Go to EC2 > Launch Instance
Select AMI (I selected Amazon linux 2023 AMI)
Select Instace type (t2.micro - Free Tier)
Select key pair for SSH access
Choose your custom VPC and public subnet created in step 1
Create a security group allowing only your IP on port 22

Step 8: Configure AWS CLI in Bastion

Once the Bastion host instance is running, you can securely connect to your private EKS resources using the bastion host. By establishing an SSH session to the bastion, you'll gain command-line access within the VPC, allowing you to run kubectl and other AWS CLI tools without exposing your Kubernetes API or nodes to the internet.

SSH into the instance:

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

Next, we will configure the AWS CLI with the credentials and preferences it needs to interact with your AWS account.
It prompts you to enter four key pieces of information:

AWS Access Key ID: This is part of your credentials used to authenticate your identity with AWS services.
AWS Secret Access Key: A secret counterpart to your access key. It should be kept safe and never exposed in public code or documentation.
Default Region Name: Specifies the AWS region you want the CLI to interact with by default (e.g., us-east-1, us-west-2). This should match the region where your EKS cluster is deployed.
Default Output Format: Controls how the CLI formats the output. Common options are:
- json (default)
- table (human-readable)
- text (compact, script-friendly)

aws configure

AWS Access Key ID [None]: ****************
AWS Secret Access Key [None]: ***********************
Default region name [None]: us-east-1
Default output format [None]: json

After this, the CLI stores the credentials in:

~/.aws/credentials
~/.aws/config

These files allow AWS CLI and tools like kubectl (via aws eks update-kubeconfig) to authenticate and communicate securely with your AWS resources.

Step 9: Configure kubectl in Bastion Host

Once the AWS CLI is installed, I proceeded to install the kubectl. The kubectl command line tool is the main tool you will use to manage resources within your Kubernetes cluster.

To install kubectl on Linux for Kubernetes 1.33, i followed the following steps

curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/1.33.0/2025-05-01/bin/linux/amd64/kubectl

Check the SHA-256 checksum for your downloaded binary with one of the following commands.

sha256sum -c kubectl.sha256

Apply execute permissions to the binary.

chmod +x ./kubectl

Copy the binary to a folder in your PATH

mkdir -p $HOME/bin && cp ./kubectl $HOME/bin/kubectl && export PATH=$HOME/bin:$PATH

You can explore the full step-by-step process here

Step 10: Create a Kubeconfig File

A kubeconfig file is a configuration file used by the kubectl command-line tool to determine how to access and authenticate with a Kubernetes cluster.

I created a kubeconfig file automatically using the command below

aws eks update-kubeconfig --region region-code --name my-cluster

Replace region-code with the AWS Region that your cluster is in and replace my-cluster with the name of your cluster.

Test your configuration.

kubectl get pods -A

Output

NAMESPACE     NAME                       READY   STATUS    RESTARTS   AGE
kube-system   aws-node-9dhsx             2/2     Running   0          90m
kube-system   aws-node-r2sxb             2/2     Running   0          90m

You can read more on creating a kubeconfig file here

Important: Allow HTTPS Traffic from Bastion to EKS
Action: Update the security group associated with your EKS cluster to allow inbound HTTPS traffic (TCP port 443) from the bastion host’s security group.

Why?
The EKS API server listens on port 443 for secure communication. Since my cluster is configured with private access only, my kubectl commands (executed from the bastion host) need permission to reach the API server. By allowing traffic on port 443 from the bastion host's security group, i have enabled secure cluster management without exposing the API publicly.

Step 11: Configure IAM Roles for EC2 instances

Initially, I used long-term IAM user credentials inside Kubernetes pods to access AWS services like S3. However, this is not considered a best practice, especially in production environments, because it introduces risks such as credential leakage and over-privileged access.

To follow security best practices, I migrated to using IAM Roles. This allows specific pods to securely assume fine-grained IAM roles without storing access keys inside the container.

Create IAM role for bastion host instance
Go to EC2 > Instances > Bastion Host > Actions > Security
Click Modify IAM role
Select the role created for the bastion host instance
Click Update Iam role

Even after assigning an IAM role to your bastion host EC2 instance via the AWS Console, the AWS CLI may still use old IAM user credentials stored in ~/.aws/credentials and ~/.aws/config. This happens because the AWS CLI defaults to credentials in those files before checking for instance metadata.

To fix this issus, i renamed the existing AWS CLI Credentials

mv ~/.aws/credentials ~/.aws/credentials.bak
mv ~/.aws/config ~/.aws/config.bak

Next, i ran AWS CLI Commands without stored credentials

aws sts get-caller-identity

Output

Conclusion

Deploying a fully private and secure Amazon EKS cluster required careful planning, precision, and a solid grasp of AWS infrastructure and Kubernetes operations. From designing the VPC and locking down IAM roles, to configuring private API access and implementing IRSA, every decision was guided by security best practices

Managing access through a bastion host, fine-tuning security groups, and resolving credential conflicts reinforced the importance of automation, least privilege, and clean access boundaries.

If you're interested in automating this process with Terraform, stay tuned for my next article where I’ll share how I built a fully automated version of this architecture!

Adding CI/CD Integration to My Cloud Resume Challenge

Kelechi Edeh — Tue, 10 Jun 2025 02:14:50 +0000

As part of my Cloud Resume Challenge, I wanted to go beyond just creating a resume website on AWS by implementing a Continuous Integration and Continuous Deployment (CI/CD) pipeline. This added a new layer of automation, efficiency, and reliability to the project, ensuring that every update I make to my resume site goes live seamlessly. In this post, I’ll walk you through my process for setting up a CI/CD workflow using GitHub Actions to automate updates to my resume, hosted on AWS, and to handle CloudFront cache invalidation.

Why CI/CD for a Resume Site?

Adding CI/CD to a resume website might seem like overkill at first glance, but here’s why it’s a valuable addition:

Efficiency: I can push updates directly from GitHub, avoiding the need for manual uploads or deployments.
Reliability: Automated testing ensures that any changes don’t inadvertently break the site.
Learning Opportunity: This was a chance to practice CI/CD with AWS, a skill highly relevant to real-world DevOps and cloud-based projects.

My CI/CD Goals for the Project

Automate Deployments to S3: Whenever I push updates to my GitHub repository, the workflow should sync the changes to my S3 bucket, which hosts my static website.
Invalidate CloudFront Cache: After the files are updated, the CloudFront distribution’s cache should be invalidated to ensure that visitors see the latest content.
Integrate Testing: Though simple, my code includes some basic HTML, CSS, and JavaScript, so any critical testing should pass before deploying.

Setting Up the CI/CD Pipeline

For this project, I used GitHub Actions as my CI/CD tool due to its seamless integration with GitHub repositories and support for AWS.

I created a .yml file in .github/workflows within my repository. This file defines the entire CI/CD pipeline, divided into two main jobs: Deploy to S3 and Invalidate CloudFront Cache.

Code repository

Let’s break down what each part does:

Trigger: The workflow is triggered by a push to the master branch. Whenever I update my resume’s code in this branch, the workflow automatically runs.
Deploy to S3 Job:

Checkout: The code from the repository is checked out into the runner.

Configure AWS Credentials: GitHub Actions configures AWS credentials from the stored secrets.

Sync to S3: This command uploads all the files from the repository to my S3 bucket, ensuring that any outdated files are replaced, and deleted files are removed.
Invalidate CloudFront Cache Job:

Dependency on Deploy Job: This job depends on the successful completion of the S3 deployment. If deployment fails, cache invalidation won’t occur.

Cache Invalidation: This command clears the cache in CloudFront, ensuring that the updated content is available globally without delay.

Benefits of the CI/CD Pipeline

With this CI/CD setup, every update to my resume becomes a simple commit and push. GitHub Actions takes care of uploading to S3 and clearing the CloudFront cache. This setup has brought several benefits:

Rapid Updates: I can make updates quickly without manual intervention.
Reduced Errors: Automating deployments has reduced the chance of human error.
Real-World DevOps Practice: Setting up this CI/CD pipeline gave me valuable experience with AWS and GitHub Actions.

Conclusion

Implementing CI/CD for my Cloud Resume Challenge has been a rewarding experience, adding both professionalism and efficiency to my project. If you’re working on a similar project, I highly recommend setting up a CI/CD pipeline with GitHub Actions. It simplifies deployment and makes it easy to keep your site updated and relevant.

. Thanks for reading, and happy coding!

Building My Cloud Resume: A Step-by-Step Journey

Kelechi Edeh — Tue, 10 Jun 2025 02:13:30 +0000

As I took on the Cloud Resume Challenge, I was excited about the chance to build a fully cloud-based resume from scratch. Having developed some foundational skills through my learning at Lighthouse Labs, I knew this would be the perfect way to put my HTML skills and newfound AWS knowledge to practical use. Here’s a breakdown of the steps I’ve taken so far to make this project a reality.

Step 1: Creating the HTML Resume

Thanks to the skills I gained at Lighthouse Labs, I was able to create an HTML resume showcasing my experience and qualifications. This static HTML file is the foundation of my cloud resume, and it’s designed to be lightweight and easily accessible.

Step 2: Registering My Domain with Porkbun

With the resume designed, I needed a custom domain to make it look professional. I chose Porkbun for domain registration because of their competitive pricing and user-friendly interface. I registered kelechiedeh.info as my domain name, which aligns with my personal brand.

Step 3: Uploading Static Pages to Amazon S3

To host the HTML resume on AWS, I turned to Amazon S3. S3 is an ideal service for hosting static websites, as it provides high availability, scalability, and security. I created a new S3 bucket, configured it to host a website, and uploaded my HTML resume files to this bucket.

Step 4: Setting Up CloudFront for Content Delivery

To improve the performance of my resume website and enhance user experience, I set up Amazon CloudFront, AWS’s content delivery network. CloudFront caches my website’s static content closer to users around the world, leading to faster load times and a more responsive site.

Step 5: Managing DNS with Route 53

Next, I configured Amazon Route 53 to manage the DNS for my domain. I created a hosted zone for kelechiedeh.info and set up an alias record pointing my domain to the CloudFront distribution. Route 53 provides a reliable way to route traffic to my S3-hosted website.

Step 6: Securing the Site with AWS Certificate Manager

To ensure my website is secure, I used AWS Certificate Manager (ACM) to provision an SSL/TLS certificate for my domain. With HTTPS enabled, my visitors can be confident that their connection to my resume site is secure. ACM simplified the process of managing the certificate, and I configured CloudFront to use it, providing a secure browsing experience.

Final Thoughts

These steps have transformed my HTML resume into a fully hosted, scalable, and secure cloud resume. By leveraging AWS services like S3, CloudFront, Route 53, and Certificate Manager, I’ve gained hands-on experience with cloud infrastructure, which is incredibly rewarding. The project has been an exciting learning journey, and I’m eager to continue refining my skills as I progress through the Cloud Resume Challenge.

Congratulations, you just earned a badge: So whats next?

Kelechi Edeh — Tue, 10 Jun 2025 02:05:51 +0000

Congratulations, you've earned a badge! It's an incredible moment—the feeling of accomplishment after all the hard work, late nights, and hours of study and practice. But now that you've reached this milestone, you might be wondering: what’s next? This was exactly the question I asked myself after achieving my AWS Solutions Architect - Associate certification.

For me, the journey didn't stop there. I'm diving into the Cloud Resume Challenge, a hands-on project that puts cloud skills into real action and, ultimately, brings all the theoretical knowledge into practical application. This challenge is about building and refining a cloud-native resume website while exploring essential AWS services, infrastructure as code, and CI/CD pipelines. Join me as I navigate this next chapter, sharing my learnings, challenges, and triumphs along the way. Let's see where this journey takes us!

Setting Up a Dev Environment on Google Cloud: A Challenge Lab Walkthrough

Kelechi Edeh — Thu, 10 Apr 2025 20:38:40 +0000

Hey there, fellow cloud enthusiasts! 👋

I recently tackled a pretty interesting Challenge Lab on Google Cloud titled "Set Up an App Dev Environment on Google Cloud"—and it was the perfect mix of practical hands-on learning and real-world cloud engineering. Whether you're prepping for certification or just trying to boost your GCP skills, this one's worth diving into.

In this post, I’ll break down what the lab was about, how I approached it, and some takeaways that might help you breeze through it, too.

Scenario: Welcome to Jooli Inc

You’ve just landed a junior cloud engineer role at Jooli Inc.. Not bad, right?

Your first big task is to help the newly formed Memories team set up their environment for a photo storage and thumbnail generation app. Your responsibilities include creating storage and Pub/Sub infrastructure, deploying a Cloud Run function, and cleaning up old user access.

The kicker? There are no step-by-step instructions. Just you, your GCP know-how, and a list of tasks.

Let’s get into it.

Task 1: Create a Bucket for Photo Storage
This is the starting point, creating a Cloud Storage bucket where uploaded images would live.
Steps:

Navigate to Cloud Storage > Buckets.
Click Create bucket, give it the exact name Bucket Name.
Select the correct region (as specified).

You can also create a Cloud Storage bucket using the gsutil command (a part of gcloud CLI).

  gcloud storage buckets create gs://Bucket-Name --location=REGION

Make sure to replace Bucket-Name with your desired name and REGION with the appropriate region (e.g., us-central1).

Task 2: Create a Pub/Sub Topic
This topic will be used by the Cloud Run function to publish messages when thumbnails are created.

Steps:

Head to Pub/Sub > Topics.
Click Create Topic, name it exactly Topic Name.
No bells and whistles—just a straight-up topic setup.

To create a Pub/Sub topic, use the following gcloud command:

gcloud pubsub topics create Topic-Name

Replace Topic-Name with the desired name for the Pub/Sub topic.

Task 3: Deploy a Thumbnail Generator with Cloud Run (2nd Gen)
You’ll deploy a Cloud Run (2nd gen) function in Node.js 22 that watches for new images in the bucket, generates 64x64 thumbnails using Sharp, and sends a message to the Pub/Sub topic.

Key Notes:

Set the trigger to Cloud Storage (Object Finalized).
Use Cloud Functions Framework with Node.js 22.
Make sure the entry point matches your function name.

The main logic in index.js

const functions = require('@google-cloud/functions-framework');
const { Storage } = require('@google-cloud/storage');
const { PubSub } = require('@google-cloud/pubsub');
const sharp = require('sharp');

functions.cloudEvent('', async cloudEvent => {
  const event = cloudEvent.data;

  console.log(`Event: ${JSON.stringify(event)}`);
  console.log(`Hello ${event.bucket}`);

  const fileName = event.name;
  const bucketName = event.bucket;
  const size = "64x64";
  const bucket = new Storage().bucket(bucketName);
  const topicName = "";
  const pubsub = new PubSub();

  if (fileName.search("64x64_thumbnail") === -1) {
    // doesn't have a thumbnail, get the filename extension
    const filename_split = fileName.split('.');
    const filename_ext = filename_split[filename_split.length - 1].toLowerCase();
    const filename_without_ext = fileName.substring(0, fileName.length - filename_ext.length - 1); // fix sub string to remove the dot

    if (filename_ext === 'png' || filename_ext === 'jpg' || filename_ext === 'jpeg') {
      // only support png and jpg at this point
      console.log(`Processing Original: gs://${bucketName}/${fileName}`);
      const gcsObject = bucket.file(fileName);
      const newFilename = `${filename_without_ext}_64x64_thumbnail.${filename_ext}`;
      const gcsNewObject = bucket.file(newFilename);

      try {
        const [buffer] = await gcsObject.download();
        const resizedBuffer = await sharp(buffer)
          .resize(64, 64, {
            fit: 'inside',
            withoutEnlargement: true,
          })
          .toFormat(filename_ext)
          .toBuffer();

        await gcsNewObject.save(resizedBuffer, {
          metadata: {
            contentType: `image/${filename_ext}`,
          },
        });

        console.log(`Success: ${fileName} → ${newFilename}`);

        await pubsub
          .topic(topicName)
          .publishMessage({ data: Buffer.from(newFilename) });

        console.log(`Message published to ${topicName}`);
      } catch (err) {
        console.error(`Error: ${err}`);
      }
    } else {
      console.log(`gs://${bucketName}/${fileName} is not an image I can handle`);
    }
  } else {
    console.log(`gs://${bucketName}/${fileName} already has a thumbnail`);
  }
});

And the package.json:

{
 "name": "thumbnails",
 "version": "1.0.0",
 "description": "Create Thumbnail of uploaded image",
 "scripts": {
   "start": "node index.js"
 },
 "dependencies": {
   "@google-cloud/functions-framework": "^3.0.0",
   "@google-cloud/pubsub": "^2.0.0",
   "@google-cloud/storage": "^6.11.0",
   "sharp": "^0.32.1"
 },
 "devDependencies": {},
 "engines": {
   "node": ">=4.3.2"
 }
}

For the Cloud Run Function (2nd Generation) that handles the thumbnail creation, I used gcloud commands to deploy the function. Here’s the full flow:

Steps:

Set up the Cloud Function: Ensure that you have the necessary code files (index.js and package.json) for the function ready in a directory.
Enable necessary APIs: Before deploying the function, ensure the required APIs are enabled
Deploy the Cloud Run Function: Navigate to the directory containing your index.js and package.json files and run the following:

gcloud run deploy Cloud-Run-Function-Name \
  --image=gcr.io/cloud-builders/npm \
  --platform=managed \
  --region=REGION \
  --allow-unauthenticated \
  --trigger-bucket=gs://Bucket-Name \
  --memory=256Mi \
  --cpu=1 \

Replace:

Cloud-Run-Function-Name with your desired Cloud Run function name.
REGION with the region where the function should be deployed (e.g., us-central1).
Bucket-Name with the name of the bucket you created earlier.

Note: The --trigger-bucket flag connects the function to your bucket, so it runs when a new object is uploaded.

Task 4: Remove the Previous Cloud Engineer’s Access
To remove the previous engineer’s access, I used the gcloud IAM commands.

Steps:

List IAM members: You can check the current IAM roles with:

gcloud projects get-iam-policy PROJECT_ID

Remove the previous engineer’s role: If the previous engineer has the Viewer role, you can remove them with:

gcloud projects remove-iam-policy-binding PROJECT_ID \
  --member='user:USERNAME' \
  --role='roles/viewer'

Replace PROJECT_ID with your project ID, and USERNAME with the email address of the previous engineer.

Final Thoughts

This lab did a great job simulating a real-world task flow:

Creating infrastructure
Automating image processing
Managing permissions

It helped solidify my understanding of how Cloud Storage, Pub/Sub, and Cloud Run can work together to build scalable, event-driven systems.

If you're prepping for the Associate Cloud Engineer certs like me, labs like these are gold.

What are your thoughts?

The Unsung Heroes of SaaS: Delivering Exceptional Technical Support

Kelechi Edeh — Fri, 28 Mar 2025 19:50:59 +0000

When people think of Software as a Service (SaaS), they often picture sleek user interfaces, powerful APIs, and seamless integrations. However, behind every successful SaaS product lies a team of dedicated technical support professionals—problem solvers, troubleshooters, and customer champions who ensure users get the most out of the product. Despite their critical role, technical support teams often don’t receive the recognition they deserve. Let’s change that.

The Critical Role of Technical Support in SaaS

Technical support is not just about answering tickets; it’s about bridging the gap between customers and engineering, translating complex technical issues into actionable solutions. Their work directly impacts customer satisfaction, retention, and even product development. Here’s how:

Enhancing Customer Experience: A well-trained support team ensures that customers receive timely, accurate, and helpful responses. By resolving issues quickly and efficiently, they help users stay productive and satisfied.
Reducing Churn and Increasing Retention: Customers don’t leave just because of bugs; they leave when they feel unheard or unsupported. Proactive and empathetic support keeps users engaged, reducing churn and fostering loyalty.
Providing Valuable Product Feedback: Support teams act as a direct line between customers and developers. They identify recurring issues, feature requests, and usability pain points, driving meaningful product improvements.
Enabling Growth Through Education: Beyond troubleshooting, support teams educate users on best practices, new features, and advanced workflows, empowering customers to get the most out of the product

Challenges Faced by Technical Support Teams

Despite their importance, support teams often face significant challenges:

High Ticket Volume: Scaling support to match a growing user base can be overwhelming.
Burnout and Stress: Handling frustrated customers and complex
technical issues can take a toll on support agents.
Lack of Recognition: Unlike engineering or sales, support work
often goes unnoticed unless something goes wrong.
Keeping Up with Rapid Product Changes: SaaS products evolve quickly, requiring support teams to continuously update their knowledge base.

Best Practices for Exceptional SaaS Support

To overcome these challenges and provide world-class technical support, SaaS companies should adopt the following best practices:

Invest in Training and Knowledge Management: Provide ongoing training for support agents and maintain a robust knowledge base to ensure quick and accurate responses.
Leverage Automation and AI: Use chatbots, self-service portals, and automated ticket routing to streamline support workflows and reduce repetitive tasks.
Foster a Culture of Appreciation: Recognize and celebrate the contributions of support teams through internal awards, career growth opportunities, and public acknowledgment.
Encourage Collaboration Between Support and Engineering: Establish clear communication channels between support and development teams to ensure faster bug resolution and better product insights.
Monitor and Act on Support Metrics: Track key performance indicators (KPIs) such as response times, resolution rates, and customer satisfaction (CSAT) scores to continually improve support quality.

Conclusion

Technical support teams are the unsung heroes of SaaS. Their dedication to problem-solving, customer satisfaction, and product improvement is invaluable. It’s time to recognize and elevate the role of technical support in building successful SaaS businesses. Whether you’re a founder, developer, or user, take a moment to appreciate the people working behind the scenes to keep things running smoothly.

What are your thoughts on the role of technical support in SaaS? Share your experiences in the comments!⬇️ ⬇️ ⬇️

Linux, Azure, and NGINX: The Ultimate Trio for Web Hosting Fun!

Kelechi Edeh — Fri, 14 Feb 2025 21:03:40 +0000

Ready to get your hands dirty with some cloud magic? Today, we’re building a Linux VM on Azure and spinning up NGINX, the web server that’s faster than your morning coffee kick-in. Let’s make the cloud our playground! ☁️

Step 1: Create a Linux VM on Azure

If you’ve caught my previous post on setting up a Windows 11 VM, you're already halfway to cloud mastery! If not, don’t sweat it—you can catch up here. Instead of a Windows image, we’re embracing the power of Linux. Linux is lean, mean, and built for performance. Plus, it pairs perfectly with NGINX, making it the ultimate tag-team for web hosting.

OS: Choose your linux distribution.
Size: A small VM (like B1s) is perfect for this project.
Username: Create a username for your vm
Authentication: Use an SSH key for security points. Give your ssh key a name
Network: select SSH and HTTP in the inbound port
Review & Launch: Hit Review + Create, then Create,

Download the private key and remember its location—you'll need it to securely SSH into your VM later.

Step 2: Install NGINX on the Linux VM

Open a terminal and connect via SSH:
- Change the permission of your private key

chmode 600 <path-to-private-key>

If you're using a private key for authentication (without a password), use the -i option to specify the path to your private key file:

ssh <path-to-private-key>username@your-vm-ip

username: The username you want to use to log into the Linux server.
your-vm-ip: The domain name or IP address of the Linux server.

Step 3: Install NGINX (Your Web Server)

Once connected, let’s install NGINX:

if you aren not logged in as the root user use sudo when running your commands

sudo apt update
sudo apt install nginx -y

apt = is the package manager of nginx
install = this is a verb and the action that you want the package manager to perform
nginx = this is what you want to install on the VM
-y = This is a command that prompts the system to automatically accept anything that requires you to accept a yes or no

We can verify this installation by pasting the IP Address of the VM on a browser

Conclusion

Congrats! You’ve deployed your first Linux VM on Azure and installed NGINX! You’re officially a cloud adventurer. Want to add a custom webpage next? Let me know in the comments below!

How to Deploy a Windows Server on a Virtual Machine and Install IIS Server

Kelechi Edeh — Fri, 14 Feb 2025 18:57:12 +0000

Deploying a Windows Server on a Virtual Machine (VM) and setting up an IIS (Internet Information Services) server is a crucial skill for developers, system administrators, and IT enthusiasts. This guide walks you through the process step-by-step, from creating a VM to verifying the IIS installation.

Windows Server: A robust operating system designed for enterprise environments, offering features such as Active Directory for user and security management, Hyper-V for virtualization, and built-in security tools like Windows Defender and BitLocker. It supports scalable deployments with load balancing and integrates seamlessly with Microsoft tools like SQL Server and Exchange.

IIS (Internet Information Services): A web server platform that hosts websites and applications, providing native support for ASP.NET, SSL security, and application pools to isolate services. IIS is scalable with load balancing and web farms and offers powerful extensions such as URL Rewrite and detailed logging for performance monitoring.

This combination is ideal for hosting websites, web services, and enterprise applications with high performance and security.

Step 1: Set Up a Virtual Machine (VM)

If you’ve read my previous post on setting up a Windows 11 VM, you’re already halfway there! If not, no worries—you can catch up by checking it out here. But this time, we’re stepping up our game. Instead of Windows 11, we’re choosing a Windows Server image. Why? Because this isn’t just about a desktop experience—it’s about building a powerhouse that can host websites, applications, and more.

Select the Windows server image and leave other configuration as default
For the inbound port selection, ensure that RDP and HTTP is checked

Connect to the windows server using the native RDP

Congratulations!!! Your windows server is up!

Step 2: Install IIS (Internet Information Services)

We will be installing IIS using powershell. PowerShell is a powerful command-line shell and scripting language built on .NET, designed for system administration and automation on Windows systems. It is an essential tool for managing Windows Server, making complex tasks quicker and more efficient.

Run Windows Powershell as an administrator
Click on the Start menu.
Type PowerShell and open Windows PowerShell or Windows PowerShell ISE as an administrator (right-click and select Run as administrator)

Run the following command to install the IIS role and management tools:

Install-WindowsFeature -name Web-Server -IncludeManagementTools

Verify Installation You can verify that IIS has been installed by opening a web browser and navigating to the ip address of the VM in a browser and verifiy that you installed the webserver.

Conclusion:

Congratulations! You've successfully deployed a Windows Server on a VM and installed IIS. This server can now host websites, web apps, or services. You can further explore SSL configurations, custom domains, and advanced IIS settings to enhance your server's capabilities.

Would you like to learn more about configuring IIS for a specific website or setting up virtual directories? Let us know in the comments below!

Building a Network Monitoring Tool with Python and Linode

Kelechi Edeh — Wed, 12 Feb 2025 04:28:58 +0000

Have you ever wanted to monitor your application, get notified when it goes down, and automatically restart it—without breaking a sweat? Well, that’s exactly what we’re doing today! In this guide, we’ll set up a Linode server, deploy NGINX as a Docker container, and use a Python script to monitor the application endpoint. If something goes wrong, our script will send an email alert and attempt to restart the container or even the server!

Step 1: Setting Up a Linode Server 🖥️

We’ll start by spinning up a Linode instance with Debian 11. Here’s how:

Create a Linode Account – Head over to Linode and log in.
Create a New Linode:
- Select Debian 11 as the operating system.
- Choose a plan (a Nanode works fine for testing).
- Set a root password (you’ll need this later).
Access Your Server – Use SSH to connect:
To access the Linode server using SSH, the server needs to be configured to accept SSH request.
- Copy your public ssh key and add to the linode server

cat ~/.ssh/id_rsa.pub

Connect to your linode server

ssh root@your-linode-ip

🎉 Woohoo! Your first cloud server is live! 🚀 Time to give it some love, deploy cool stuff, and rule the cloud like a pro. The sky (or should we say, the cloud) is the limit! ☁️😎

Step 2: Installing Docker 🐳

Docker simplifies app deployment using lightweight containers. Since our server runs Debian, we'll follow the official Docker installation guide for Debian, found here

# Add Docker's official GPG key:
sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Add the repository to Apt sources:
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update

To install the latest version run

sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Check that Docker is running:

docker --version

Step 3: Deploying NGINX in a Docker Container 🌍

We’ll now set up an NGINX web server inside a Docker container.

docker run -d --name nginx-container -p 8080:80 nginx

Verify it’s running:

docker ps

Now, visiting http://your-linode-ip:8080 should display the default NGINX welcome page.

Step 4: Writing a Python Monitoring Script

Now for the fun part! Our Python script will:

Monitor the application endpoint where NGINX is running by making an HTTP request and checking the status code. This determines whether the application is up or experiencing issues—such as inaccessibility, errors, or a crashed container.
Trigger an email alert if the application is down.
Attempt to restart the Docker container to restore service.
If the issue persists, reboot the entire Linode server to bring everything back online.

Code repository

Skills Gained from This Project

By working through this project, you have developed and strengthened several key skills, including:

Cloud Server Management – Setting up and configuring a Linode server.
Docker & Containerization – Deploying applications inside Docker containers.
Python Scripting – Writing automation scripts to monitor and manage applications.
Networking & Troubleshooting – Diagnosing and resolving connectivity issues.
Linux System Administration – Installing and managing software on Debian.
Email Notifications & Alerting – Using SMTP to send alerts on application failures.
Server Automation & Recovery – Automating container and server restarts for high availability.
API & Remote Server Management – Interacting with Linode’s API for automated server management.

Final Thoughts

With this setup, you have a self-healing infrastructure that minimizes downtime. Whether you're running a personal project or a production service, this approach keeps your app online and responsive.

Have questions or ideas to improve the setup? Let’s discuss! 👇

Azure Applied Skills: Providing private storage for internal company documents

Kelechi Edeh — Sat, 08 Feb 2025 10:41:14 +0000

In today’s digital landscape, secure and highly available storage is essential for businesses that manage private data while ensuring backup solutions for critical assets. This guide walks through setting up a robust cloud storage architecture that provides high availability, restricted access, cost efficiency, and seamless backup mechanisms.

By completing this task, you will have developed essential skills in:

Creating a storage account for private company documents.
Configuring redundancy to ensure high availability.
Setting up shared access signatures (SAS) for restricted file access.
Implementing backup solutions for public website storage.
Managing storage lifecycle policies to transition content to the cool tier efficiently.

Setting Up High-Availability Storage

To begin, we create a storage account tailored for internal private company documents. This ensures secure storage with redundancy to withstand potential regional outages.

Steps to Create a Storage Account

In the portal, search for and select Storage accounts.
Select + Create.
Set the Storage account name to a unique name
Select Review, and then Create the storage account.

Configuring Redundancy for High Availability
Since business continuity is a priority, we enable Geo-Redundant Storage (GRS):

Within the Data management section, select Redundancy.
Choose Geo-redundant storage (GRS) to replicate data to a secondary region.
Refresh and verify the primary and secondary locations.

Restricting Access to Corporate Data

Access control is essential when handling private documents. We configure a private storage container with limited access.

Creating a Private Storage Container

Under Data storage, navigate to Containers.
Click + Container
Name it private.
Set Public access level to Private (no anonymous access).
Click Create.

Uploading and Testing Access Control

Open the private container.
Click Upload, select a file, and upload it.

Copy the file’s URL and attempt to access it in a browser. A restricted access error should appear.

Providing Limited Partner Access Using SAS

For external partners requiring temporary access, we generate a Shared Access Signature (SAS).

Generating a SAS Token

Open the uploaded file and navigate to Generate SAS.
Assign only Read permissions.
Set the expiration time to 24 hours.
Generate and copy the SAS URL.
Test access by opening the SAS URL in a new browser tab.

Optimizing Costs with Storage Tiers

To minimize storage costs, we move data from the hot tier to the cool tier after 30 days.

Implementing Lifecycle Management

In the Data management section, select Lifecycle management.
Click Add rule and name it movetocool.
Apply the rule to all blobs in the storage account and click next.
Set Last modified to More than 30 days ago.
Choose Move to cool storage.
Save the rule.

Backing Up Public Website Data

To protect website files, we create a backup mechanism.

Creating a Backup Storage Container

In the private storage account, create a new container named backup using default settings.

Enabling Object Replication for Automated Backup

Navigate to the publicwebsite storage account.
Select Object replication under Data management.
Click Create replication rule.
Set the Destination storage account to the private storage account.
Choose Source container as public and Destination container as backup.
Create the rule.

Final Thoughts

Implementing these storage strategies ensures a secure, highly available, cost-efficient, and automated backup system for company assets. By leveraging Azure Storage capabilities, businesses can enhance data security, streamline partner collaboration, and optimize storage costs effectively.