DEV Community: Zakariyau Mukhtar

Leveling Up CI/CD: Automated Versioning and the Leap to AWS

Zakariyau Mukhtar — Sat, 15 Aug 2026 21:28:05 +0000

This week has been all about refining the continuous integration and continuous deployment (CI/CD) pipeline. After successfully containerizing a Node.js application and pushing it to Docker Hub, it was time to tackle a crucial DevOps practice: Automated Versioning.

Here is a breakdown of what I implemented this week, the hurdles I overcame, and what is next on the roadmap.

Demystifying Semantic Versioning (SemVer)

Before automating anything, it is essential to understand how application versions are structured. A standard version number is broken down into three parts:

Major Version: Contains big changes that are not backward-compatible.
Minor Version: Introduces new API features but remains backward-compatible.
Patch: Dedicated strictly to minor changes and bug fixes without altering the API.

Build tools come equipped with commands to increase these versions dynamically during the build process, which is exactly what I integrated into the Jenkins pipeline.

The Automated Versioning Pipeline

The goal for this module was straightforward: Increment Version $\rightarrow$ Build App $\rightarrow$ Build Image $\rightarrow$ Push to Docker Repo.

To achieve this, I updated the Jenkinsfile to run npm version patch --no-git-tag-version. This command dynamically extracts the new version (e.g., bumping 1.0.1 to 1.0.2), which I then stored as an environment variable (env.IMAGE_NAME) to tag the newly packaged Docker image automatically.

The "Local vs. Remote" Challenge

During implementation, I ran into a classic CI/CD hurdle. When the Jenkins pipeline ran the npm version command, the new version was only updated locally within the Jenkins workspace. It did not update the actual source code repository on GitHub. This meant every subsequent build would pull the old version number from the repo, causing an endless overwrite loop.

The Solution:
The fix required adding a dedicated Git stage to the end of the pipeline. By securely injecting GitHub credentials into the workspace, Jenkins now automatically stages the modified package.json and package-lock.json files and pushes the updated version directly back to the main branch.

Here is the stage that handles this synchronization:

stage('Updating to Github'){
    steps{
        script{
            echo 'Updating the Github repo with the latest version....'
            withCredentials([usernamePassword(credentialsId: 'github.credentials', passwordVariable: 'PASS', usernameVariable: 'USER')]) {
                sh 'git config user.email "jenkins@example.com"'
                sh 'git config user.name "jenkins"' 
                sh 'git remote set-url origin https://${USER}:${PASS}@github.com/AlAfiz/Devops-app.git'
                sh 'git add package.json package-lock.json'
                sh 'git commit -m "feat: update the github repo with the latest version"'
                sh 'git push origin HEAD:main'
            }
        }
    }
}

Note: I also made sure to implement a Clean Workspace step (rm -f *.tgz) at the very beginning of the pipeline to prevent old artifact tarballs from getting swallowed up in the new builds!

What's Next: Infrastructure as a Service (AWS)

With a robust, self-versioning pipeline now fully operational, I am officially shifting gears into a brand new module: AWS Services.

Understanding Infrastructure as a Service (IaaS) is the next major milestone. Over the coming weeks, the focus will be on:

Managing users and permissions with AWS IAM.
Understanding Regions and Availability Zones.
Configuring private networks using VPCs.
Creating virtual servers via EC2.
Connecting the Jenkins pipeline to continuously deploy directly to an EC2 instance!

The journey from a local environment to the cloud is underway. Stay tuned!

Automating the Workflow: My Journey from Jenkins Freestyle Jobs to Declarative Pipelines

Zakariyau Mukhtar — Sun, 09 Aug 2026 21:16:05 +0000

The Infrastructure: Setting Up Jenkins on AWS

The foundation of this project began by provisioning an Ubuntu EC2 instance on AWS. Setting up the environment meant defining strict networking rules (opening Port 22 for SSH and Port 8080 for the Jenkins UI) and structuring the Jenkins environment with clear access controls.

In Jenkins, maintaining a secure and organized environment generally falls into two roles:

Administrators: Responsible for managing the Jenkins cluster, installing necessary plugins, and handling data backups.
Users: Focused purely on creating jobs to run their respective workflows.

The Magic of Docker-out-of-Docker (DooD)

One of the most critical architectural choices was deciding how to let Jenkins build Docker images without installing a heavy, nested Docker engine inside the Jenkins container itself. The solution was a Docker-out-of-Docker configuration.

By running the following command, I spun up the Jenkins container while binding it directly to the host machine's Docker socket:

docker run -p 8080:8080 -p 50000:50000 -d \
-v jenkins_home:/var/jenkins_home \
-v /var/run/docker.sock:/var/run/docker.sock \
-v $(which docker):/usr/bin/docker jenkins/jenkins:lts

This single command did a lot of heavy lifting. It mapped port 8080 for the UI and 50000 for Jenkins agent communication. More importantly, mapping /var/run/docker.sock gave the Jenkins container the ability to pass docker build and docker push commands directly to the EC2 host’s Docker engine. (Just remember to ensure your jenkins user has the right permissions to access that socket!).

Hitting the Wall: The Limitations of Freestyle Jobs

Initially, I set up the application lifecycle running npm install, npm test, and npm pack using a standard Jenkins Freestyle job.

Freestyle jobs are great for quick, isolated tasks. However, their limitations become glaringly obvious when you try to build a project with multiple automation steps. Orchestrating a complex workflow by chaining multiple Freestyle jobs together is inefficient and quickly leads to overloaded jobs that are impossible to maintain or debug.

The Solution: Embracing Declarative Pipelines

To solve this, I migrated the entire workflow to a Pipeline job. Pipelines are written in Groovy (a language similar to Java) and are designed specifically to orchestrate long-running, complex activities that can span multiple build agents.

The repository for this project contains all the necessary configuration files, including the Dockerfile, Jenkinsfile, package.json, and the main application code in server.js.

By placing a Jenkinsfile directly in the repository, the pipeline became part of the application's source code (Infrastructure as Code). The declarative syntax allowed me to clearly define distinct stages:

Checkout: Pulling the latest code from GitHub.
Install & Test: Running standard Node.js NPM commands.
Package & Build: Compiling the .tgz artifact and building the Docker image.
Push: Authenticating and pushing the final image to a private DockerHub repository.

Pro-Tip: When pushing to a private registry in a pipeline, you need to use Jenkins' "Secret text or file" plugin to securely pass your credentials into the docker login command via a withCredentials block, preventing sensitive data from leaking into your build logs!

What's Next?

Moving forward, I plan to implement Multibranch Pipelines, which will allow Jenkins to automatically scan my repository, detect any branch containing a Jenkinsfile, and dynamically build a pipeline for it using when condition statements. I am also exploring Jenkins Parameters to inject external configurations, making it incredibly easy to select specific application versions for deployment dynamically.

The transition from clicking through the Jenkins UI to writing robust, version-controlled pipelines has completely transformed how I approach CI/CD.

From Localhost to AWS ECR: Architecting a 3-Tier Node.js App with Docker.

Zakariyau Mukhtar — Wed, 08 Jul 2026 20:16:42 +0000

As a Cloud and DevOps Engineer, one of the most satisfying milestones is taking an application that "works on my machine" and transforming it into a robust, portable, and scalable architecture.

Recently, I decided to containerize an Infrastructure Asset Tracker application I’ve been developing. The goal wasn't just to wrap the Node.js backend in a Docker container, but to orchestrate a complete 3-tier architecture (Backend, Database, and Admin Visualizer) using Docker Compose, and securely host the final image in AWS Elastic Container Registry (ECR).

Here is a deep dive into the architecture, the optimizations I made, and the real-world debugging it took to get everything running seamlessly.

The Architecture Setup

The stack consists of three independent microservices communicating over an internal Docker network:

The Backend (devops-app:v1): A custom Node.js REST API.
The Database (mongodb): The official MongoDB image.
The Visualizer (mongo-express): A web-based admin interface for MongoDB.

Instead of building a "Frankenstein" container (shoving the database and the app into one massive image), I strictly adhered to the one-concern-per-container rule. This ensures each layer can scale independently and fail gracefully.

Phase 1: Crafting an Optimized Dockerfile

Writing a Dockerfile is easy. Writing an optimized one takes deliberate engineering.

1. The Base Image & Shell Gotchas
I opted for FROM node:18-alpine. Alpine Linux is incredibly lightweight and highly secure, keeping the final image size down to just ~51MB. However, this comes with a classic DevOps gotcha: Alpine strips out heavier utilities like bash. When I needed to shell into the running container to verify my file structures, docker exec -it <container> /bin/bash failed. I had to pivot to using the native /bin/sh.

2. Leveraging Layer Caching
To make my builds lightning fast, I separated the dependency installation from the source code copy:

WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .

Because Docker caches layers sequentially, copying only the package.json first protects the heavy npm install step. Now, if I change a single line of JavaScript or HTML, Docker uses the cached node modules and updates the code layer in less than a second.

3. The .dockerignore File
Crucially, I added a .dockerignore file containing node_modules and .env. This prevents host-OS compiled C++ bindings from breaking the Alpine container and ensures my local database passwords never accidentally get baked into the production image.

Phase 2: Orchestration & Persistence with Docker Compose

To wire the three containers together, I built a docker-compose.yml (named mongo.yaml) master blueprint. Two specific configurations were critical here:

Solving the Startup Race Condition
If the Node.js backend or Mongo Express boots up faster than the MongoDB database, they will throw connection timeouts and crash. To prevent this, I utilized depends_on:

depends_on:
  - mongodb

This acts as a traffic cop, explicitly forcing the backend and visualizer to wait until the database container is fully initialized before attempting to connect.

Ensuring Data Persistence
Docker containers are ephemeral if you spin them down, the data inside dies with them. To ensure the infrastructure assets logged in my app survived a restart, I implemented a named Docker Volume:

volumes:
  - mongodb_data:/data/db

This maps a secure, permanent directory on the host machine directly into MongoDB’s internal storage path.

Phase 3: Real-World Debugging

No deployment goes perfectly on the first try. Here are two specific hurdles I had to debug during the orchestration phase:

Port Collisions (ERR_CONNECTION_REFUSED): During deployment, my Node.js container failed to bind to port 3000. Running docker ps revealed the container was isolated (3000/tcp) instead of mapped (0.0.0.0:3000->3000/tcp). The culprit? A ghost Node.js process still running on my local host. A quick pkill node cleared the parking space, and a fresh docker compose up -d successfully mapped the port.
The Disconnected Daemon: I encountered a massive red error: failed to connect to the docker API at unix:///home/.../docker.sock. This was a context mismatch between my terminal and the Docker engine. Ensuring the Docker background service was awake and resetting the terminal context resolved the socket connection.

Phase 4: Pushing to AWS ECR

With the architecture running flawlessly locally, I tagged my custom image and pushed it to a private AWS ECR repository.

A fascinating detail about modern Docker (using the BuildKit engine) is how it handles the push. In the AWS console, I didn't just see one file; I saw three:

The Image Index (Manifest List): The master pointer for the v1 tag.
The Application Image: The actual 51MB Node.js container.
The Attestation: A cryptographic receipt proving exactly how the image was built and what dependencies were used a massive win for modern supply-chain security.

The Takeaway

Containerizing this architecture solidified my mental model of how host machines, isolated networks, and storage layers interact. We've officially moved past "it works on my machine" to "it works exactly as designed, anywhere."

Next on the roadmap: Automating this deployment flow with a complete CI/CD pipeline!

How I Escaped "Tutorial Hell" (And Put My First Real App on the Internet)

Zakariyau Mukhtar — Mon, 18 May 2026 18:41:10 +0000

Have you ever watched hours of coding tutorials, felt like you learned a lot, but still couldn't build a real project from scratch?

That is called "tutorial hell." As someone diving into Cloud and DevOps engineering, I was stuck there. To break out, I realized I needed to stop watching videos and start building. Instead of creating a fake practice project, I took a real website my brother built and challenged myself to put it live on the internet using professional tools.

Here is exactly how I did it, without the heavy tech jargon:

1. Packing It Up in a "Magic Box":
Usually, a website that works perfectly on one computer might completely break on another. To fix this, I used a tool called Docker. Think of Docker as a magic shipping container. I packed my brother's website, along with everything it needs to run, inside this invisible box. Now, no matter whose computer or cloud server opens that box, the website works perfectly every single time.

2. Fixing the "Refresh" Bug:
When I first tested the box on my laptop, the site loaded beautifully. But I noticed a bug: if I clicked on a different page and hit "refresh," the whole site crashed and gave me a 404 Not Found error.

The web server was getting confused and looking for files that didn't exist. I had to write a custom rule basically giving the server a map so it knew how to route lost visitors back to the right place. Bug squashed!

3. Automating the Boring Stuff:
I didn't want to manually repackage and upload the website every single time my brother wanted to change a button color. So, I wrote an automation script using GitHub Actions.

Now, I have a "robot" working for me in the cloud. The second my brother saves new code, this robot wakes up, tests the code to make sure it isn't broken, packages it into a new Docker box, and securely gets it ready for the internet.

4. The Trap of Over-Engineering:
This is where I almost made a huge mistake. When it was time to put the app on the internet, the idea of using Kubernetes came up. Kubernetes is a massive, highly complex system used by giant tech companies to keep thousands of servers running.

I took a step back and asked: "Isn't this total overkill for a simple web app?" It absolutely was. Using Kubernetes for this would be like buying a commercial airplane just to go to the grocery store. We scrapped that idea and went with a simple, free cloud hosting platform called Render instead.

The Big Takeaway
This project taught me one of the most important lessons in tech: a good engineer doesn't just use the fanciest, most complex buzzwords. They use the right, simple tool for the exact job in front of them.

If you are just starting your tech career, stop watching videos. Grab a project, break it, figure out how to fix it and put it on the internet. There is no substitute for building!

DevOps #TechJourney #LearnInPublic #CloudComputing

From Installation Freezes to PowerShell Automation: My Windows Server 2019 Journey.

Zakariyau Mukhtar — Thu, 15 Jan 2026 17:35:25 +0000

Introduction: The Challenge

I recently tackled a comprehensive lab project: deploying a functional Windows Server 2019 environment from scratch. The goal wasn't just to install the OS, but to configure it like a real-world sysadmin using automation to handle users, groups, and secure file sharing.

While I started this project feeling a bit like a beginner (or as we say, an "olodo"), by the end, I was writing multi-line PowerShell scripts to manage the infrastructure.

Here is a breakdown of how I built my lab using Oracle VirtualBox and how I overcame some tricky hurdles along the way.

Phase 1: The Setup and "The Freeze"

My lab environment ran on Oracle VirtualBox. The installation process taught me my first major lesson in virtualization troubleshooting.

Initially, my Windows Server installation kept freezing at the "spinning dots" boot screen. After some deep diving into settings, I realized that running a modern server OS requires specific virtualization hardware settings.

The Fix:
It turned out my VM configuration was missing a critical processor feature. I had to ensure PAE/NX was enabled in the VirtualBox processor settings and increase my video memory. Once those were tweaked, the installation sailed through to the desktop experience.

Phase 2: Base Configuration (The Manual Stuff)

Once logged in as the Administrator, the first step was giving the server an identity.

In a real network, servers need static addresses so they can always be found. I configured the network adapter with a static IPv4 address suitable for my lab environment (10.0.2.15).

I also renamed the computer from its generic Windows name to something meaningful: WIN-SERVER-01. While I could have used the GUI, I used PowerShell for a quick rename and restart:

Rename-Computer -NewName "WIN-SERVER-01" -Restart

Phase 3: The Power of Automation (The Cool Stuff)

This is where the project got interesting. The requirement was to create multiple users (Alice, Bob, Charlie), assign them to departments (HR, IT), and ensure they changed their passwords on first login.

Doing this manually involves dozens of clicks. Instead, I wrote a PowerShell script to handle it in seconds.

The Scripting Approach:
I used ISE to write a script that utilized loops and conditionals. It checked if a user or group existed before trying to create it, making the script "idempotent" (safe to run multiple times).

Here is a snippet of the user creation loop:

# Snippet: Automating User Creation
$users = @("Alice", "Bob", "Charlie")
foreach ($user in $users) {
    # Create the user
    New-LocalUser -Name $user -Password $securePassword -Description "Staff"

    # Force password change at next login
    $userObj = [ADSI]"WinNT://$env:COMPUTERNAME/$user,user"
    $userObj.PasswordExpired = 1
    $userObj.SetInfo()
}

Phase 4: Permissions and Hardening

The final step was securing the environment.

File Sharing:
I created restricted folders HRDocs and ITDocs. I used PowerShell to ensure only the HR group could access their documents, and ditto for IT. This enforced the principle of least privilege.

Security Hardening:
As a basic security measure, I disabled the built-in Guest account to prevent anonymous access. Again, PowerShell made this easy to verify:

Conclusion and Lessons Learned

This project was a great crash course in Windows Server administration. The biggest takeaway wasn't just knowing what to configure, but knowing how to do it efficiently.

While GUIs are helpful for learning, PowerShell is essential for scalable, repeatable system administration. Moving past the initial installation hurdles and seeing my scripts successfully deploy the environment felt like a massive win.

From Vibe-Coding to Engineering: My 48-Hour Battle with Docker & Windows

Zakariyau Mukhtar — Mon, 12 Jan 2026 18:08:30 +0000

I started this weekend with a simple goal: set up a local development environment. I wanted a vanilla HTML/JS frontend, a Node.js backend, and a MongoDB database running in a Docker container (plus Mongo Express to visualize the data).

Prior to this, I had zero knowledge of JavaScript. I was just following a video tutorial, copying code I didn't fully understand, and hoping for the best.

I thought it would take an hour. Instead, it took a frustrated bike ride home, a Sunday spent journaling, and a deep dive into how Docker actually works to get it running. Here is the full story.

The Setup (Copying blindly)

I started by copying the frontend code. It was a simple User Profile page where you could toggle between "View" and "Edit" modes.

My index.html:

<script>
    function saveProfile() {
        document.querySelector('#name').textContent = document.querySelector('#input-name').value
        // ... more DOM manipulation
    }
</script>

My server.js:

var express = require('express');
var app = express();
app.use(express.static(__dirname)); 
app.listen(3000, function () {
    console.log("app listening on port 3000!");
});

So far, so good. The frontend worked. Then came Docker.

Phase 1 The "Name Does Not Resolve" Loop:

I pulled the mongo and mongo-express images and tried to run them using long CLI commands I found online. I checked docker ps, and everything looked fine.

But when I checked the logs for Mongo Express, I saw this error over and over:

/docker-entrypoint.sh: line 15: mongo: Name does not resolve

I spent 30 minutes spinning up containers, deleting them, and spinning them up again. I eventually turned to AI for help. It suggested I stop everything, wipe the containers, and create a dedicated network.

I ran:

docker network create mongo-network

Then I restarted the containers attached to that network. The error persisted. I was stuck in a loop of trying random commands without understanding why they failed.

Phase 2: The Mystery of "Pass" vs "Password"-

Once I finally got the containers talking, I couldn't log in to Mongo Express.

I had explicitly set my environment variables to:

ME_CONFIG_BASICAUTH_USERNAME=admin
ME_CONFIG_BASICAUTH_PASSWORD=password

But every time I tried to log in with admin / password, it failed.

After a lot of trial and error, I tried logging in with pass. It worked.

I realized that because of how I was passing arguments in PowerShell, Docker wasn't picking up my password variable. It was defaulting to the container's built-in security settings (admin:pass). I had to completely restructure my docker run command to ensure the variables were actually being read.

Phase 3: The Saturday Night "Vibecoding" Crash-

By 9 PM on Saturday, I hit a wall.

I ran my Node.js server and tried to edit a profile. The terminal said:

Connecting to the db....

And then... silence. It just froze.

I tried everything the AI suggested, but nothing worked. I didn't even understand half the commands I was typing. I realized I was just "vibecoding" typing random things hoping for a miracle. I was frustrated. I packed up, left the office, and took a bike ride home to clear my head.

Phase 4: The Monday Morning Fix

On Sunday, I didn't touch the code. I just journaled. I wrote down a plan: Understand the problem, then fix it.

On Monday, I came back fresh. I wiped every container and image (docker system prune) and started from scratch.

The "Windows Hang" (IPv4 vs IPv6)

I realized why the app was freezing. On Windows, localhost often resolves to the IPv6 address ::1. However, Docker Desktop for Windows listens on the IPv4 address 127.0.0.1.

My Node app was knocking on the IPv6 door, but Docker was at the IPv4 house.

I changed my connection string in server.js:

Bad: mongodb://admin:password@localhost:27017
Good: mongodb://admin:password@127.0.0.1:27017

The Version Mismatch

Even with the connection fixed, I got errors. I looked at my package.json.
I had installed the latest mongodb version (v6.0+), which uses Promises. But the tutorial code I copied was written for version 3.8, which used Callbacks.

I uninstalled the new version and forced a downgrade:

npm install mongodb@3.7.3

I restarted the server. I clicked "Save Profile." It worked.

Conclusion

This project was supposed to be a quick setup, but it turned into a crash course in DevOps. I learned:

Don't trust localhost on Windows. Always use 127.0.0.1.
Check your dependencies. Copy-pasting old code requires old packages.
Stop "Vibecoding." If you don't understand the command, don't run it. Step back, journal, and come back fresh.

From "Permission Denied" to Production: My AWS & Terraform Journey

Zakariyau Mukhtar — Tue, 30 Dec 2025 14:58:59 +0000

Provisioning infrastructure and deploying applications manually is a recipe for inconsistency. Today, I took on the challenge of automating a server setup using Terraform to host a Spring Boot Java application. It wasn't a straight path. I ran into regional payment blocks, architecture mismatches and SSH "ghosts" but here is exactly how I solved them.

The Pivot From DigitalOcean to AWS:

I was following a course where the instructor used DigitalOcean to deploy the Java app. I tried to follow along, but I hit a brick wall, DigitalOcean kept rejecting my cards because I am in Nigeria.
I felt bad for a few days, but then I remembered my #30ofAWSTerraform challenge. AWS is known for its complexity, but it’s also the industry leader. I decided to stop feeling bad and start building. If the course used a DigitalOcean "Firewall," I knew I could translate that into an AWS Security Group. I decided to test my knowledge and gain real experience.

1. Provisioning Infrastructure with Terraform:

My goal was to use Infrastructure as Code (IaC) to create an EC2 instance. I used the aws_instance and aws_key_pair resources to define my server.

The Challenge: SSH Key Management
Initially, passing the public key as a raw string variable led to formatting errors.

The Solution:
I used the Terraform file() function to read my public key directly from my local disk. This ensured that the exact bytes on my Windows machine matched what AWS received.

resource "aws_key_pair" "my_ssh_key" {
  key_name   = "zacks-key"
  public_key = file("C:/Users/Public/id_aws.pub")
}

2. The Battle of AMI IDs and Usernames:

Even after the server was "running," I couldn't get in. I kept seeing InvalidAMIID.NotFound or Permission denied (publickey).

The Lessons Learned:

Region Specificity: AMI IDs are not universal. An Ubuntu ID in London won't work in North Virginia (us-east-1).
Architecture Matters: I discovered that a t2.micro instance requires an x86 image. Trying to use an ARM-based AMI will result in a "Not Found" error.
The Default User: Every OS has a different "front door." For Amazon Linux, it’s ec2-user. For Ubuntu, it’s ubuntu.

3. Deploying the Application (The JAR File):

Once the server was accessible, I needed to move my Java artifact from my local build/libs folder to the cloud.

The Tool: SCP (Secure Copy)
I used the following command to securely upload the JAR:
scp -i C:\Users\Public\id_aws "C:\Users\...\java-app-1.0-SNAPSHOT.jar" ubuntu@<IP>:/home/ubuntu/

Translating Firewall to Security Group:
When my instructor added a firewall on DigitalOcean, I knew exactly what to do in AWS. I updated my Security Group in Terraform to open Port 8080, allowing traffic to reach my Spring Boot application.

4. Linux User Management & Security

For security best practices, I created a personal user: zacks.

The Steps taken:

Creation: sudo adduser zacks.
Permissions: I gave the user administrative power using sudo usermod -aG sudo zacks.
The Final SSH Boss: I mistakenly named my key file Authentication_keys. Linux ignores this, It must be named authorized_keys. Furthermore, I had to use chown to ensure the user zacks actually owned the file and chmod 600 to make it private.

sudo mv /home/zacks/.ssh/Authentication_keys /home/zacks/.ssh/authorized_keys
sudo chown -R zacks:zacks /home/zacks/.ssh
sudo chmod 600 /home/zacks/.ssh/authorized_keys

Conclusion

Today was a masterclass in troubleshooting. I learned that DevOps isn't just about writing code; it's about being adaptable. When one cloud door closed, I used Terraform to open a better one on AWS.

Infrastructure is live, the JAR is running, and the "Whitelabel Error Page" never looked so beautiful!

Day 17 of #30DaysofAWSTerraform: Blue-Green Deployment with Elastic Beanstalk (The Hard Way)

Zakariyau Mukhtar — Thu, 25 Dec 2025 14:38:27 +0000

Day 17 was one of those days that really tested my patience but also deepened my understanding of real-world deployment strategies. Today, I learned about Blue-Green deployment, how Elastic Beanstalk fits into that strategy, and how to actually swap environments safely without downtime. It wasn’t smooth at all; IAM policies almost broke my spirit but the lesson stuck.

What Blue-Green Deployment Really Is:

Blue-Green deployment is a strategy where you maintain two identical environments:

Blue → current production (stable).
Green → new version (staging). Instead of deploying directly to production, you deploy the new version to the green environment, test it thoroughly, and then swap traffic instantly. If something goes wrong, rollback is just another swap away. This drastically reduces downtime and deployment risk something every serious production system needs.

Why Elastic Beanstalk?

Elastic Beanstalk abstracts a lot of infrastructure complexity while still giving control when needed. It manages:

EC2 instances.
Load balancers.
Auto Scaling.
Health checks.
Application versions.

For this demo, Elastic Beanstalk made Blue-Green deployment practical, especially when paired with Terraform for infrastructure consistency.

Terraform Setup: Providers and IAM (Where the Pain Started)

I started with provider configuration and IAM roles and this is where things got tough. Elastic Beanstalk requires multiple IAM roles, and incorrect attachments will break everything.

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

provider "aws" {
  region = var.aws_region
}

The EC2 role for Elastic Beanstalk instances:

resource "aws_iam_role" "eb_ec2_role" {
  name = "${var.app_name}-eb-ec2-role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = { Service = "ec2.amazonaws.com" }
    }]
  })
}

Attaching the correct managed policies was critical and yes, I hit multiple errors here due to wrong role attachments.

Creating the Elastic Beanstalk Application:

Once IAM stopped fighting me, I defined the Elastic Beanstalk application itself:

resource "aws_elastic_beanstalk_application" "app" {
  name        = var.app_name
  description = "Blue-Green Deployment Demo Application"
}

I also created an S3 bucket to store application versions each version mapped to either blue or green.

Blue Environment (Production):

The blue environment represents production running version 1.0:

resource "aws_elastic_beanstalk_environment" "blue" {
  name                = "${var.app_name}-blue"
  application         = aws_elastic_beanstalk_application.app.name
  solution_stack_name = var.solution_stack_name
  version_label       = aws_elastic_beanstalk_application_version.v1.name

  setting {
    namespace = "aws:elasticbeanstalk:application:environment"
    name      = "Environment"
    value     = "blue"
  }
}

This environment served stable traffic and stayed untouched while testing the new version.

Green Environment (Staging):

The green environment hosted version 2.0 with new features:

resource "aws_elastic_beanstalk_environment" "green" {
  name                = "${var.app_name}-green"
  application         = aws_elastic_beanstalk_application.app.name
  solution_stack_name = var.solution_stack_name
  version_label       = aws_elastic_beanstalk_application_version.v2.name

  setting {
    namespace = "aws:elasticbeanstalk:application:environment"
    name      = "Environment"
    value     = "green"
  }
}

Both environments were load-balanced, scalable, and completely independent.

Swapping Blue and Green (The Cool Part):

After testing the green environment, I used a swap script to redirect traffic instantly:

aws elasticbeanstalk swap-environment-cnames \
  --source-environment-name "$BLUE_ENV" \
  --destination-environment-name "$GREEN_ENV" \
  --region "$REGION"

This swap takes 1–2 minutes, with near-zero downtime. Production traffic moves to green, and blue becomes the fallback.

Commands Used:

Throughout this setup, I relied on the basics:

terraform init.
terraform plan.
terraform apply --auto-approve.
terraform destroy --auto-approve.

Simple commands complex consequences.

Final Thoughts

Today was tough. IAM policies and attachments caused multiple failures, and Elastic Beanstalk doesn’t forgive mistakes. But that’s exactly why this day mattered. I didn’t just learn Blue-Green deployment in theory I felt it.

Day 17 reminded me that real DevOps is messy, but the payoff is systems that deploy safely, scale reliably, and recover fast.

On to Day 18 🚀

Day 16 : Managing IAM Users, Groups, and MFA at Scale with Terraform

Zakariyau Mukhtar — Fri, 19 Dec 2025 16:55:33 +0000

Day 16 of my #30DaysOfAWSTerraform challenge focused on one of the most sensitive parts of cloud infrastructure: identity and access management (IAM).Unlike EC2 or networking, IAM mistakes don’t usually “fail loudly” they create security risks. Today’s goal was to learn how to create, manage, and secure multiple IAM users at scale using Terraform.
This day was relatively straightforward conceptually, but the implementation forced me to think like a real administrator rather than a hobbyist.

What I Built

Using Terraform, I automated the creation of:

Multiple IAM users from a CSV file.
IAM login profiles with forced password reset.
Department-based IAM groups.
Conditional group memberships.
Custom IAM policies per department.
Mandatory MFA enforcement for all users.
Account-wide password policy.

All of this was done declaratively and reproducibly.

Creating Multiple IAM Users from CSV:

Instead of hardcoding users, I used a CSV file as the source of truth. Terraform’s csvdecode() function made this clean and scalable.

locals {
  users = csvdecode(file("users.csv"))
}

Each user was created dynamically using for_each:

resource "aws_iam_user" "users" {
  for_each = { for user in local.users : user.first_name => user }
  name = lower("${substr(each.value.first_name, 0, 1)}${each.value.last_name}")
  path = "/users/"

  tags = {
    DisplayName = "${each.value.first_name} ${each.value.last_name}"
    Department  = each.value.department
    JobTitle    = each.value.job_title
    Email       = each.value.email
    Phone       = each.value.phone
  }
}

This approach allowed me to scale user creation without touching Terraform code again adding a user only requires editing the CSV.

Enabling Console Access and Password Policies:

Each user received a login profile with a forced password reset on first login:

resource "aws_iam_user_login_profile" "users" {
  for_each = aws_iam_user.users

  user                    = each.value.name
  password_reset_required = true
}

I also enforced a strong account-wide password policy:

resource "aws_iam_account_password_policy" "strong" {
  minimum_password_length        = 10
  require_lowercase_characters   = true
  require_uppercase_characters   = true
  allow_users_to_change_password = true
  max_password_age               = 90
}

This ensures consistency and security across all users.

IAM Groups and Automatic Membership:

I created four IAM groups:

Management.
Sales.
Accounting.
HR. Membership was determined dynamically using tags instead of manual assignments.

Example Management group membership based on job title:

resource "aws_iam_group_membership" "management_members" {
  name  = "management-group-membership"
  group = aws_iam_group.management.name
  users = [
    for user in aws_iam_user.users :
    user.name
    if contains(keys(user.tags), "JobTitle") &&
       can(regex("Manager|CEO", user.tags.JobTitle))
  ]
}

This pattern removes human error and keeps access aligned with organizational roles.

Enforcing MFA for Every User:

One of the most important parts of today was forcing MFA. I created a custom IAM policy that:

Allows users to set up their own MFA devices.
Denies all AWS actions if MFA is not enabled.

resource "aws_iam_policy" "force_mfa" {
  name = "Force-MFA-Policy"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "DenyAllExceptMFASetupIfNoMFA"
        Effect = "Deny"
        NotAction = [
          "iam:CreateVirtualMFADevice",
          "iam:EnableMFADevice",
          "iam:GetUser",
          "sts:GetSessionToken",
          "iam:ChangePassword"
        ]
        Resource = "*"
        Condition = {
          BoolIfExists = {
            "aws:MultifactorAuthPresent" = "false"
          }
        }
      }
    ]
  })
}

This policy was attached to every user automatically:

resource "aws_iam_user_policy_attachment" "enforce_mfa" {
  for_each   = aws_iam_user.users
  user       = each.value.name
  policy_arn = aws_iam_policy.force_mfa.arn
}

Department-Specific Policies:

Each department received tailored permissions:

Management: Broad access, restricted IAM management.
Sales: Read-only access.
Accounting: Billing and cost management.
HR: IAM user and credential management only.

These policies were attached at the group level, not the user level a best practice.

Outputs and Visibility:

I exposed useful outputs for visibility and auditing:

output "group_members" {
  value = {
    Management = length(aws_iam_group_membership.management_members.users)
    Sales      = length(aws_iam_group_membership.sales_members.users)
    Accounting = length(aws_iam_group_membership.accounting_members.users)
    HR         = length(aws_iam_group_membership.hr_members.users)
  }
}

Final Thoughts

Day 16 showed me that IAM is not about permissions it’s about structure. Terraform forces discipline, consistency, and repeatability in access control, which is exactly what real organizations need.

No chaos today just clean, deliberate infrastructure.

On to Day 17.

Day 15:Building Multi-Region VPC Peering with Terraform

Zakariyau Mukhtar — Thu, 18 Dec 2025 14:50:29 +0000

Day 15 of my #30DaysOfAWSTerraform challenge was one of the most demanding so farnot because the concepts were impossible, but because this was the first time everything felt real-world messy. Today I worked extensively with VPC peering, multi-region infrastructure, routing, security groups, and Git conflicts the full DevOps experience.

What I Learned:

The core focus of today was understanding how VPC peering works beyond theory. I didn’t just connect two VPCs, I created three VPCs across three different AWS regions and connected all of them together:

Production VPC in us-east-1.
Testing VPC in us-west-2.
Development VPC in eu-west-2.

This immediately forced me to think about provider aliases, region isolation, and how AWS networking behaves when traffic crosses VPC and regional boundaries.
I also deepened my understanding of:

Route tables and why peering alone is not enough.
Internet Gateways and their role in outbound traffic.
Subnets and availability zones.
Security group ingress rules for controlled cross-VPC access.

Creating the VPCs (Terraform Code):

Each VPC was defined with its own provider alias and CIDR block. For example, the Production VPC:

resource "aws_vpc" "prod_vpc" {
  provider = aws.prod
  cidr_block = var.prod_vpc_cidr
  enable_dns_hostnames = true
  enable_dns_support = true

  tags = {
    Name = "Production-VPC-${var.prod_A}"
    Environment = var.Environment
    Purpose = "VPC-Peering-Demo"
  }
}

I repeated this pattern for Testing and Development VPCs, each tied to its own AWS region.

Subnets, Internet Gateways and Route Tables:

Each VPC had:

A public subnet.
An Internet Gateway.
A route table with 0.0.0.0/0 pointing to the IGW.

Example Production Route Table:

resource "aws_route_table" "prod_rt" {
  provider = aws.prod
  vpc_id = aws_vpc.prod_vpc.id

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

Without properly associating route tables with subnets, nothing works and Terraform won’t warn you. This was a critical lesson.

VPC Peering Connections (The Core of the Day):

I created three peering connections:

Production ↔ Testing.
Production ↔ Development.
Testing ↔ Development.

Each peering required:

A requester connection.
An accepter connection.
Explicit routes in both VPC route tables.

Example Production to Testing peering:

resource "aws_vpc_peering_connection" "production_to_testing" {
  provider = aws.prod
  peer_vpc_id = aws_vpc.test_vpc.id
  vpc_id      = aws_vpc.prod_vpc.id
  peer_region = var.test_B
  auto_accept = false
}

And the accepter:

resource "aws_vpc_peering_connection_accepter" "testing_to_production" {
  provider = aws.test
  vpc_peering_connection_id = aws_vpc_peering_connection.production_to_testing.id
  auto_accept = true
}

Then the route entries the most commonly missed step:

resource "aws_route" "prod_to_test" {
  provider = aws.prod
  route_table_id = aws_route_table.prod_rt.id
  destination_cidr_block = var.test_vpc_cidr
  vpc_peering_connection_id = aws_vpc_peering_connection.production_to_testing.id
}

Without this, peering exists but traffic dies silently.

Security Groups and EC2 Validation:

To validate connectivity, I deployed EC2 instances in each VPC with security groups that allowed:

SSH (port 22)
ICMP (ping)
Cross-VPC CIDR access

Example Production Security Group ingress:

ingress {
  description = "SSH from Test and Dev VPC"
  from_port = 22
  to_port = 22
  protocol = "tcp"
  cidr_blocks = [
    var.test_vpc_cidr,
    var.dev_vpc_cidr
  ]
}

Each EC2 instance used Ubuntu 24.04 LTS, pulled via data sources, and included user-data scripts to install Apache and display region-specific info.

The Real Struggle: Git Merge Conflicts

This day was chaotic.

While pushing changes to Git, I ran into merge conflicts repeatedly. I ended up rewriting parts of the infrastructure three different times before I finally understood why the conflicts were happening.

It wasn’t Terraform’s fault.
It wasn’t AWS.
It was version control discipline.

That pain was worth it. I now understand merge conflicts at a deeper level not as errors, but as signals.

Final Thoughts

Day 15 taught me something important:
DevOps is not clean. It’s structured chaos.

VPC peering works beautifully when every dependency is correct. One missing route, one wrong CIDR, or one overlooked provider alias, and everything breaks silently.
Today, I didn’t just learn Terraform.
I learned how real infrastructure behaves under pressure.

On to Day 16.

Day 14 of #30DaysOfAWSTerraform: Hosting a Static Website with S3 and CloudFront

Zakariyau Mukhtar — Mon, 15 Dec 2025 19:11:31 +0000

Day 14 was all about static websites and how AWS handles them at scale. Before this lesson, I had a surface-level idea of what a static website was, but today made everything click from how files are stored, to how they are securely served globally using AWS services.

The core focus of today’s lesson was S3, CloudFront, and how Terraform ties everything together as Infrastructure as Code.

Understanding Static Websites

A static website is exactly what it sounds like a site that serves fixed content such as HTML, CSS, JavaScript, images, and assets. There’s no backend logic, no database queries, and no server-side rendering. What you upload is what users see.

This makes static websites:

Fast
Cheap to host
Highly scalable
Secure when configured correctly

AWS excels at this through Amazon S3 and Amazon CloudFront.

Deep Dive into Amazon S3

S3 (Simple Storage Service) is not just a storage bucket it’s a highly durable object storage service designed to store and retrieve any amount of data.

Key things I deeply understood today:

S3 stores objects, not filesystems
Every object is accessed via a unique key
S3 is globally durable but regionally hosted
Public access must be explicitly controlled

In my setup, I created an S3 bucket using Terraform:

resource "aws_s3_bucket" "firstbucket" {
  bucket = var.bucket_name
}

To prevent accidental public exposure, I added a public access block, which is critical for security:

resource "aws_s3_bucket_public_access_block" "block" {
  bucket = aws_s3_bucket.firstbucket.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

This ensures that the bucket cannot be accessed publicly unless explicitly allowed through CloudFront.

Uploading Website Files to S3

Instead of uploading files manually, Terraform can manage website content using aws_s3_object. This is powerful because your infrastructure and content stay in sync.

resource "aws_s3_object" "object" {
  for_each = fileset("${path.module}/www", "**/*")
  bucket   = aws_s3_bucket.firstbucket.id
  key      = each.value
  source   = "${path.module}/www/${each.value}"
  etag     = filemd5("${path.module}/www/${each.value}")

  content_type = lookup({
    "html" = "text/html",
    "css"  = "text/css",
    "js"   = "application/javascript",
    "json" = "application/json",
    "png"  = "image/png",
    "jpg"  = "image/jpeg",
    "svg"  = "image/svg+xml"
  }, split(".", each.value)[length(split(".", each.value)) - 1], "application/octet-stream")
}

This automatically uploads HTML, CSS, and JavaScript from the www/ directory into S3 with correct content types.

Introducing CloudFront (The Game Changer)

CloudFront is AWS’s Content Delivery Network (CDN). Instead of serving content directly from S3, CloudFront caches content at edge locations close to users, dramatically improving performance and security.

I created an Origin Access Control (OAC) so CloudFront can securely access the S3 bucket:

resource "aws_cloudfront_origin_access_control" "origin_access_control" {
  name                              = "demo-oac"
  origin_access_control_origin_type = "s3"
  signing_behavior                  = "always"
  signing_protocol                  = "sigv4"
}

Then I defined the CloudFront distribution:

resource "aws_cloudfront_distribution" "s3_distribution" {
  origin {
    domain_name              = aws_s3_bucket.firstbucket.bucket_regional_domain_name
    origin_access_control_id = aws_cloudfront_origin_access_control.origin_access_control.id
    origin_id                = local.origin_id
  }

  enabled             = true
  default_root_object = "index.html"

  default_cache_behavior {
    allowed_methods        = ["GET", "HEAD"]
    cached_methods         = ["GET", "HEAD"]
    target_origin_id       = local.origin_id
    viewer_protocol_policy = "redirect-to-https"
  }

  viewer_certificate {
    cloudfront_default_certificate = true
  }
}

This configuration ensures:

HTTPS is enforced
Content is cached globally
S3 is never directly exposed to users

Locking Down S3 with Bucket Policy

To complete the security setup, I added a bucket policy allowing only CloudFront to access the S3 objects:

resource "aws_s3_bucket_policy" "allow_cf" {
  bucket = aws_s3_bucket.firstbucket.id

  policy = jsonencode({
    Statement = [{
      Effect    = "Allow"
      Principal = { Service = "cloudfront.amazonaws.com" }
      Action    = "s3:GetObject"
      Resource  = "${aws_s3_bucket.firstbucket.arn}/*"
    }]
  })
}

This is a best practice for production-grade static websites.

Challenge Faced

I couldn’t fully complete the deployment because my AWS account wasn’t approved to create CloudFront distributions. That was frustrating, but also a real-world lesson: permissions and account limits matter.

Even so, the Terraform configuration is solid and production-ready.

Final Thoughts

Day 14 was a big milestone. I now understand:

How static websites work on AWS
Why S3 is ideal for hosting static content
How CloudFront improves performance and security
How Terraform ties everything together cleanly

This wasn’t just theory, it was real infrastructure thinking.

On to Day 15

Day 13 : Understanding Terraform Data Sources Like a Human, Not a Robot

Zakariyau Mukhtar — Tue, 09 Dec 2025 18:25:17 +0000

Today’s session was one of those “lightbulb days” in Terraform the point where things finally click. Day 13 was all about Terraform Data Sources and honestly, this is one of the core concepts that separates beginners from engineers who actually understand infrastructure workflows.

Data Sources: The Missing Puzzle Piece:

I’ve been creating resources in Terraform for days EC2 instances, S3 buckets, IAM, and more but today I finally understood why Data Sources matter so much. While resources are things Terraform creates, data sources are things Terraform reads from AWS. This difference is massive. Data sources allow you to use existing AWS components instead of hardcoding IDs or manually copying values from your console. That means:

No more manually typing VPC IDs.
No more guessing subnets.
No more hunting for AMI IDs.
No more breaking infrastructure because an ID changed. Terraform stays synced with AWS, and your code becomes smarter, reusable and more consistent.

What I Built Today:

1. Fetch the Default VPC:

data "aws_vpc" "vpc_name" {
  filter {
    name   = "tag:Name"
    values = ["default"]
  }
}

Instead of hardcoding a VPC ID, this fetches the one tagged “default.”

Small change and big improvement in reliability.

2. Fetch a Subnet Inside that VPC:

data "aws_subnet" "shared" {
  filter {
    name   = "tag:Name"
    values = ["subneta"]
  }
  vpc_id = data.aws_vpc.vpc_name.id
}

This pulls the subnet tagged “subneta,” within the VPC I retrieved earlier.

Now Terraform can dynamically locate a subnet without me touching the AWS console.

3. Fetch the Latest Amazon Linux 2 AMI:

data "aws_ami" "linux2" {
  owners      = ["amazon"]
  most_recent = true

  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-gp2"]
  }
  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
}

This is the cleanest way to ensure your instance always uses the latest stable Amazon Linux 2 image.

4. Deploy an EC2 Instance Using ONLY Dynamic Values:

resource "aws_instance" "example" {
  ami           = data.aws_ami.linux2.id
  instance_type = "t2.micro"
  subnet_id     = data.aws_subnet.shared.id
  tags          = var.tags
}

No hardcoded IDs.
No guesswork.
No outdated AMIs.
Everything is tied to real AWS values at the time of deployment.

Backend Configuration (S3 Remote State)

I also configured my backend for state storage:

backend "s3" {
  bucket       = "devopswithzacks-terraform-state"
  key          = "dev/terraform.tfstate"
  region       = "us-east-1"
  encrypt      = true
  use_lockfile = true
}

This moved my Terraform state from local to AWS S3, enabling:

Team collaboration.
State locking.
Zero risk of losing state locally.
Better security and versioning. This is how real-world environments are structured.

Commands I Used:

Same workflow:

terraform init
terraform plan
terraform apply --auto-approve
terraform destroy --auto-approve Smooth, clean and predictable especially now that everything is dynamic.

My Experience Today

Day 13 was surprisingly straightforward compared to the last few days.

No major blockers.
No syntax confusion.
No AWS permission issues.

Just clean logic and a clearer understanding of how Terraform interacts with existing AWS infrastructure.

Data sources are the bridge between what you already have and what you're trying to build. Today made that crystal clear.

Final Thoughts

Data sources are easily one of the most powerful features in Terraform. They eliminate hardcoding, reduce errors, and make infrastructure code scalable and environment-aware.
Today felt like a big step forward, my Terraform code finally behaves like it belongs in production.