Forem: Michelle

The Lives Behind the Flowers

Michelle — Sun, 10 May 2026 01:39:37 +0000

The Quiet Cost of Motherhood

Today being mother's day, I found myself thinking about motherhood, not only in human beings, but across nature itself.

I came across flamingos, whose bright pink feathers begin to fade while nurturing their young because so much of their energy and nutrients are redirected into feeding their chicks. I read about rabbits pulling out their own fur to prepare warm nests before giving birth. Across species, motherhood seems to come with a quiet surrender. A giving away of the self so that another life may continue.

And suddenly, human motherhood did not seem so separate from the rest of nature.

We often speak about birth as though it is the finish line. As though motherhood begins and ends in a delivery room. But giving birth is only the opening chapter.

Motherhood stretches into sleepless nights, postponed dreams, changing bodies, financial burdens, emotional exhaustion, invisible fear, and the constant responsibility of shaping another human being. Some women lose their hair. Others lose parts of their identity they are still trying to recover years later. Some carry scars no one sees because society has romanticized sacrifice so deeply that pain is expected to arrive silently.

And still, mothers continue.

Not because motherhood is always beautiful, but because love often asks people to endure things that beauty alone cannot sustain.

What unsettles me is how casually society treats this sacrifice while simultaneously condemning women who choose not to become mothers at all.

There is an assumption that womanhood naturally leads to motherhood, and that rejecting one somehow rejects the other. Women who choose not to have children are often labeled selfish, immature, incomplete, or unnatural. But perhaps what society calls selfishness is sometimes honesty.

Perhaps some women understand the weight of motherhood deeply enough to admit they are not prepared for it.

And is that not more responsible than bringing life into the world simply because tradition demanded it?

Not every person is meant for parenthood. Some know they do not have the emotional, mental, financial, or personal capacity to raise a child in the way a child deserves. Others simply do not desire motherhood at all. Neither should make them villains.

Nature itself teaches us that nurturing life demands sacrifice. It demands energy, patience, and pieces of oneself that may never fully return. If we truly respected motherhood, then we would also respect the seriousness of choosing whether or not to enter it.

Because motherhood should never be treated as a compulsory milestone.

It is a commitment vast enough to alter bodies, identities, futures, and entire lives.

And perhaps the women who recognize that truth most clearly are not selfish at all.

Perhaps they are simply honest.

30-Day Cloud & DevOps Challenge: Day 12 — Terraform: Infrastructure as Code

Michelle — Mon, 04 May 2026 08:35:10 +0000

So far in this challenge, I've built containers, set up CI/CD with Jenkins, and pushed images to Docker Hub.

But there was one missing piece: how do I create the actual servers where all this runs?

Today, I started learning Terraform, a tool that lets you create infrastructure (servers, networks, databases) using code instead of clicking around in a web console.

No more "ClickOps". No more "it works on my machine". Just code that creates real infrastructure.

First: What is Infrastructure as Code (IaC)?

The Manual Way (ClickOps)

AWS Console -> Click "Launch Instance" -> Choose settings -> Click "Create"
EC2 Console -> Click "Create Security Group" -> Add rules -> Click "Create"
VPC Console -> Click "Create VPC" -> Configure -> Click "Create"

The problems:

No record of what you created
Can't reproduce exactly the same way twice
Easy to make mistakes
No version control
Only the person who clicked knows what happened

The IaC Way (Terraform)

# main.tf
resource "aws_instance" "my_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
}

The benefits:

Code is documentation (everyone can see what exists)
Version control with Git (track every change)
Repeatable everywhere (dev, staging, production)
Easy to review changes before applying
No human error from clicking wrong buttons

What is Terraform?

Terraform is an open-source tool created by HashiCorp that lets you define infrastructure as code and then creates that infrastructure for you.

The Analogy

Concept	Analogy
Terraform code	A blueprint for a house
Terraform plan	Walking through the blueprint before building
Terraform apply	Actually building the house
Terraform destroy	Demolishing the house
State file	The house's deed (records what was built)

Which Providers Does Terraform Support?

Terraform works with almost EVERY cloud provider:

Provider	What it creates
AWS	EC2 servers, VPC networks, S3 storage
Azure	Virtual machines, databases, storage
Google Cloud	Compute instances, Kubernetes clusters
Kubernetes	Pods, services, deployments
Docker	Containers, images, networks
Local	Files on your computer (what we'll use today)

Terraform Core Commands

The Workflow

Write Code → init → plan → apply → destroy
   (main.tf)  (setup) (preview) (create) (cleanup)

Command 1: `terraform init`

What it does: Prepares your working directory for Terraform.

terraform init

What happens:

Downloads required provider plugins (AWS, Azure, Local, etc.)
Sets up backend for storing state
Initializes modules

Example output:

Initializing provider plugins...
- Finding latest version of hashicorp/local...
- Installing hashicorp/local v2.8.0...
- Installed hashicorp/local v2.8.0 (signed by HashiCorp)

Terraform has been successfully initialized!

When to use: First time in a folder, or when you add new providers.

Command 2: `terraform plan`

What it does: Shows what Terraform WILL do without actually doing it.

terraform plan

What happens:

Compares your code against existing infrastructure
Shows what will be added, changed, or deleted
Does NOT make any changes (safe to run anytime)

Example output:

Terraform will perform the following actions:

  + resource "local_file" "hello" {
      + content  = "Hello from Terraform!"
      + filename = "./hello.txt"
    }

Plan: 1 to add, 0 to change, 0 to destroy.

When to use: Always run this BEFORE apply to review what will change.

Command 3: `terraform apply`

What it does: Actually creates or updates infrastructure.

terraform apply

What happens:

Shows you the plan
Asks for confirmation (yes to proceed)
Creates the resources

Example output:

Do you want to perform these actions?
  Enter a value: yes

local_file.hello: Creating...
local_file.hello: Creation complete

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

When to use: After reviewing the plan, to actually create resources.

Command 4: `terraform destroy`

What it does: Removes all infrastructure created by Terraform.

terraform destroy

What happens:

Shows what will be destroyed
Asks for confirmation
Deletes everything

Example output:

Do you want to destroy these resources? Enter a value: yes

local_file.hello: Destroying...
local_file.hello: Destruction complete

Destroy complete! Resources: 1 destroyed.

When to use: When you want to clean up and avoid ongoing charges.

Your First Terraform Project

Step 1: Install Terraform

On Ubuntu/Kali Linux:

sudo snap install terraform --classic
terraform --version

Step 2: Create a Project Folder

mkdir -p ~/Desktop/terraform-demo
cd ~/Desktop/terraform-demo

Step 3: Create main.tf

nano main.tf

Step 4: Add the Terraform Code

resource "local_file" "hello" {
  content  = "Hello from Terraform!"
  filename = "${path.module}/hello.txt"
}

Understanding the code:

Part	Meaning
`resource`	"I want to create something"
`"local_file"`	The type of resource (a file on my computer)
`"hello"`	A name I give this resource (can be anything)
`content`	What text to put inside the file
`filename`	Where to save the file (`./hello.txt` means current folder)
`${path.module}`	Terraform variable meaning "current folder"

Step 5: Initialize Terraform

terraform init

What this does: Downloads the "local" provider plugin so Terraform can create files.

Step 6: Preview the Plan

terraform plan

What this does: Shows you what Terraform WILL create without actually creating it.

You should see:

Terraform will perform the following actions:

  + resource "local_file" "hello" {
      + content  = "Hello from Terraform!"
      + filename = "./hello.txt"
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Step 7: Apply the Configuration

terraform apply

When prompted, type: yes

What this does: Actually creates the file.

Step 8: Verify the File Was Created

ls -la
cat hello.txt

You should see: Hello from Terraform!

Step 9: Check Terraform State

terraform show
terraform state list

What this does: Shows what Terraform is tracking.

Step 10: Clean Up (Optional)

terraform destroy

Type: yes

What this does: Removes the file.

Understanding Terraform Files

When you run Terraform, it creates several files:

File	Purpose	Should you edit it?
`main.tf`	Your infrastructure code	YES (this is where you write code)
`terraform.tfstate`	Current state of infrastructure	NO (Terraform manages this)
`terraform.tfstate.backup`	Backup of previous state	NO
`.terraform/`	Provider plugins	NO
`.terraform.lock.hcl`	Locks provider versions	NO

The State File is IMPORTANT

What it contains:

{
  "version": 4,
  "resources": [
    {
      "mode": "managed",
      "type": "local_file",
      "name": "hello",
      "instances": [{
        "attributes": {
          "content": "Hello from Terraform!",
          "filename": "./hello.txt"
        }
      }]
    }
  ]
}

Why it matters: Terraform uses this file to track what it created. Without it, Terraform doesn't know what exists.

Best practice: Store state files remotely (S3, Azure Storage) when working with a team.

Terraform Commands Cheat Sheet

Command	What it does	When to use
`terraform init`	Downloads plugins, sets up backend	First time in a folder
`terraform plan`	Previews what will change	Before every apply
`terraform apply`	Creates/updates resources	After reviewing plan
`terraform destroy`	Deletes all resources	When cleaning up
`terraform fmt`	Formats code consistently	Before committing
`terraform validate`	Checks if code is valid	After writing code
`terraform show`	Shows current state	To see what exists
`terraform state list`	Lists resources in state	To see tracked resources

Terraform vs Other DevOps Tools

Tool	Purpose	Where it fits
Terraform	Create infrastructure (servers, networks)	Day 0: Provision resources
Ansible	Configure existing servers (install software)	Day 1: Configure the servers
Docker	Package applications into containers	Build phase
Jenkins	Automate builds and deployments	CI/CD pipeline
Kubernetes	Run and scale containers	Run phase

They work together in this flow:

Terraform creates the server
       ↓
Ansible configures the server (installs Docker)
       ↓
Jenkins builds and pushes Docker images
       ↓
Docker runs the containers
       ↓
Kubernetes orchestrates multiple containers

Key Takeaways

Concept	Explanation
Infrastructure as Code	Define servers, networks, databases in code
Terraform	Tool that turns code into cloud resources
`init`	Sets up Terraform in a directory
`plan`	Previews what will change (safe to run anytime)
`apply`	Actually creates/changes resources
`destroy`	Removes everything (be careful!)
State file	Tracks what Terraform created (don't edit manually)

What's Next

Now that you understand basic Terraform commands, tomorrow we will:

Create real infrastructure in the cloud (AWS)
Provision a server to run your Docker containers
Combine Terraform with your existing CI/CD pipeline

From local files to actual cloud servers!

Resources

Let's Connect!

Have you used Terraform before? What infrastructure have you coded?

Drop a comment or connect on LinkedIn. Let's learn together!

30-Day Cloud & DevOps Challenge: Day 11 — Pushing Docker Images to Registry

Michelle — Mon, 04 May 2026 07:34:21 +0000

Yesterday, my Jenkins pipeline could build Docker images for backend and frontend.

But those images only existed on my local machine. They weren't accessible anywhere else, not on another developer's computer, not on a cloud server, not anywhere.

Today, I fixed that. I configured Jenkins to push Docker images to Docker Hub a public registry where anyone can pull my images.

Now my images are available everywhere.

First: What is a Docker Registry?

The Analogy

Concept	Analogy
Docker image	A shipping container with your app
Docker registry	A shipping port where containers are stored
Docker Hub	The largest public shipping port
docker pull	Bringing a container FROM the port
docker push	Sending a container TO the port

Why Push to a Registry?

Without Registry	With Registry
Images only on your laptop	Images available anywhere
Can't share with team	Anyone can pull the image
Need to rebuild on every server	Pull once, run anywhere
No versioning	Tag versions (v1.0, latest)

Step 1: Create Docker Hub Account

If you don't have one:

Go to hub.docker.com
Sign up for a free account
Remember your username

Step 2: Add Docker Hub Credentials to Jenkins

Why Credentials?

Jenkins needs to log in to Docker Hub before it can push images.

Adding Credentials

Open Jenkins: http://localhost:8081
Manage Jenkins -> Credentials
System -> Global credentials -> Add Credentials

Fill out the form:

Field	Value
Kind	`Username with password`
Username	Your Docker Hub username
Password	Your Docker Hub password
ID	`docker-hub-credentials`
Description	`Docker Hub login for pushing images`

Click "Create"

Step 3: Update Jenkinsfile with Push Stage

The Complete Jenkinsfile with Push

pipeline {
    agent any

    environment {
        DOCKER_REGISTRY = 'docker.io'
        DOCKER_USERNAME = 'your-dockerhub-username'  // Replace this!
        BACKEND_IMAGE = "${DOCKER_REGISTRY}/${DOCKER_USERNAME}/myapp-backend:latest"
        FRONTEND_IMAGE = "${DOCKER_REGISTRY}/${DOCKER_USERNAME}/myapp-frontend:latest"
    }

    stages {
        stage('Checkout') {
            steps {
                echo 'Cloning repository...'
                checkout scm
            }
        }

        stage('Backend Dependencies') {
            steps {
                dir('backend') {
                    sh 'npm install'
                }
            }
        }

        stage('Frontend Build') {
            steps {
                dir('frontend') {
                    sh 'npm install'
                    sh 'npm run build'
                }
            }
        }

        stage('Docker Build') {
            steps {
                echo 'Building Docker images...'
                sh 'docker build -t ${BACKEND_IMAGE} ./backend'
                sh 'docker build -t ${FRONTEND_IMAGE} ./frontend'
            }
        }

        stage('Docker Push') {
            steps {
                echo 'Pushing to Docker Hub...'
                withCredentials([usernamePassword(
                    credentialsId: 'docker-hub-credentials',
                    usernameVariable: 'DOCKER_USER',
                    passwordVariable: 'DOCKER_PASS'
                )]) {
                    sh 'echo $DOCKER_PASS | docker login -u $DOCKER_USER --password-stdin'
                    sh 'docker push ${BACKEND_IMAGE}'
                    sh 'docker push ${FRONTEND_IMAGE}'
                }
            }
        }

        stage('Success') {
            steps {
                echo 'Pipeline completed successfully!'
                echo "Images pushed to:"
                echo "  - ${BACKEND_IMAGE}"
                echo "  - ${FRONTEND_IMAGE}"
            }
        }
    }

    post {
        failure {
            echo 'Pipeline failed! Check the logs.'
        }
        success {
            echo 'Images published to Docker Hub!'
        }
    }
}

Understanding New Parts

Part	What it does
`environment { DOCKER_USERNAME }`	Stores your Docker Hub username
`BACKEND_IMAGE = "docker.io/username/image"`	Full image name including registry
`withCredentials()`	Safely uses credentials without exposing passwords
`docker login`	Authenticates with Docker Hub
`docker push`	Uploads the image to the registry

Step 4: Replace the Username

Important: Change your-dockerhub-username to YOUR actual Docker Hub username!

DOCKER_USERNAME = 'johndoe'  // Use your actual username

Understanding Credential Security

What NOT to do (Hardcoding passwords)

// DON'T DO THIS!
sh 'docker login -u johndoe -p MyRealPassword123'

Why not? Anyone who sees your Jenkinsfile can steal your password!

What TO do (Using Jenkins credentials)

withCredentials([usernamePassword(
    credentialsId: 'docker-hub-credentials',
    usernameVariable: 'DOCKER_USER',
    passwordVariable: 'DOCKER_PASS'
)]) {
    sh 'echo $DOCKER_PASS | docker login -u $DOCKER_USER --password-stdin'
}

Why this is safe:

Password never appears in logs
Password not stored in Jenkinsfile
Jenkins encrypts credentials
Only authorized users can access

Step 5: Commit and Push

git add Jenkinsfile
git commit -m "ci: add Docker Hub push stage

- Tag images with Docker Hub registry
- Add credentials for Docker login
- Push backend and frontend to Docker Hub"
git push origin main

Step 6: Run the Pipeline

Go to Jenkins -> microservices-ci
Click "Build Now"
Watch the console output

Console Output

[Pipeline] stage
[Pipeline] { (Docker Push)
[Pipeline] echo
Pushing to Docker Hub...
[Pipeline] withCredentials
[Pipeline] {
[Pipeline] sh
+ echo ****
+ docker login -u johndoe --password-stdin
Login Succeeded

[Pipeline] sh
+ docker push docker.io/johndoe/myapp-backend:latest
The push refers to repository [docker.io/mkangeth/myapp-backend]
latest: digest: sha256:abc123... size: 2420

[Pipeline] sh
+ docker push docker.io/johndoe/myapp-frontend:latest
The push refers to repository [docker.io/johndoe/myapp-frontend]
latest: digest: sha256:def456... size: 1024

[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Success)
[Pipeline] echo
Pipeline completed successfully!
Images pushed to:
  - docker.io/johndoe/myapp-backend:latest
  - docker.io/johndoe/myapp-frontend:latest
Finished: SUCCESS

Step 7: Verify on Docker Hub

Go to https://hub.docker.com/u/your-username
You should see:
- myapp-backend
- myapp-frontend

Check Repository Details

Click on myapp-backend:

Tags: latest
Size: ~135MB
Pull command: docker pull yourusername/myapp-backend:latest
Last pushed: Just now

Step 8: Test Pulling from Any Computer

On any machine with Docker:

# Pull your images
docker pull yourusername/myapp-backend:latest
docker pull yourusername/myapp-frontend:latest

# Run them
docker run -d -p 3001:5000 yourusername/myapp-backend:latest
docker run -d -p 8080:80 yourusername/myapp-frontend:latest

# Test
curl http://localhost:3001/health
# Open browser to http://localhost:8080

It works anywhere in the world!

Before vs After

Aspect	Before (Day 10)	After (Day 11)
Images location	Only on local machine	Docker Hub (worldwide)
Sharing	Send files manually	`docker pull`
Team access	Send images via USB/email	Anyone can pull
Deployment	Copy images to server	Pull from registry
Version tracking	Manual	Tags in registry

Complete CI/CD Pipeline Now

+-----------------------------------------------------------------------------------+
|                         YOUR COMPLETE CI/CD PIPELINE                              |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|   git push -> Jenkins -> Build -> Docker -> Push -> Available                     |
|                    |          |         |        |                               |
|                    v          v         v        v                               |
|                  Pulls     Installs   Creates  Uploads                           |
|                  code      deps       images   to Hub                            |
|                                                                                   |
+-----------------------------------------------------------------------------------+

                              |
                              v
                    +-----------------+
                    |   DOCKER HUB    |
                    |  (Your Images)  |
                    +-----------------+
                              |
                              v
              +---------------+---------------+
              v               v               v
         Your Laptop     Cloud Server    Team Member
         (docker pull)   (docker pull)   (docker pull)

Key Takeaways

Images need a home = Docker Registry (Docker Hub is the default)
Credentials protect secrets = Never hardcode passwords in Jenkinsfile
Tag images properly = Include registry and username in the tag
Push once, pull anywhere = Images become globally available
Latest is fine, versions are better = Consider using build numbers as tags

Resources

Let's Connect!

Have you pushed images to Docker Hub before? What registry do you use (Docker Hub, AWS ECR, GCR, others)?

Drop a comment or connect on LinkedIn. Let's learn together!

30-Day Cloud & DevOps Challenge: Day 10 — Docker in CI

Michelle — Mon, 04 May 2026 07:23:51 +0000

Yesterday, my Jenkins pipeline could install dependencies and build the frontend.

But there was a missing piece: Docker. Without it, I couldn't package my applications into containers — the whole point of this challenge!

Today, I fixed that. I configured Jenkins to build Docker images for both my backend and frontend, turning my CI pipeline into a complete build system.

First: Why Docker in CI?

Before Docker in CI

The pipeline could:

Pull code from GitHub
Install dependencies
Build the frontend
Could NOT create Docker images

After Docker in CI

The pipeline can:

Pull code from GitHub
Install dependencies
Build the frontend
Create Docker images for backend AND frontend

Why this matters: Docker images are what actually get deployed to production. Without them, you can't run your app anywhere else.

Step 1: Giving Jenkins Docker Access

The Problem

Jenkins runs in a container. By default, containers can't access the host's Docker daemon.

+------------------+     +------------------+
|     Jenkins      |     |   Docker Daemon  |
|    Container     |  X  |    (on host)     |
| "I need Docker"  |---->|  "Cannot reach"  |
+------------------+     +------------------+

The Solution: Docker Socket Mounting

Mount the host's Docker socket into the Jenkins container:

# jenkins/docker-compose.yml
services:
  jenkins:
    user: root                      # Run as root for permissions
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock  # Mount Docker socket
    environment:
      - DOCKER_HOST=unix:///var/run/docker.sock   # Tell Jenkins where Docker is

After Mounting

+------------------+     +------------------+
|     Jenkins      |     |   Docker Daemon  |
|    Container     |  ✓  |    (on host)     |
| "I need Docker"  |---->|  "Here you go!"  |
+------------------+     +------------------+

Step 2: Installing Docker in Jenkins Container

Even with the socket mounted, Jenkins needs the Docker CLI tool.

# Enter Jenkins container
sudo docker exec -it jenkins bash

# Install Docker CLI
apt-get update
apt-get install -y docker.io

# Verify it works
docker --version

Expected output:

Docker version 26.1.5, build a72d7cd

Step 3: Adding Docker Build to Pipeline

The Docker Build Stage

stage('Docker Build') {
    steps {
        echo 'Building Docker images...'
        sh 'docker build -t myapp-backend:latest ./backend'
        sh 'docker build -t myapp-frontend:latest ./frontend'
    }
}

What Each Command Does

Command	What it does
`docker build`	Creates a Docker image from a Dockerfile
`-t myapp-backend:latest`	Tags the image with a name and version
`./backend`	Tells Docker where to find the Dockerfile

The Complete Jenkinsfile (Docker Stage Added)

pipeline {
    agent any

    stages {
        stage('Checkout') {
            steps {
                echo 'Cloning repository...'
                checkout scm
            }
        }

        stage('Backend Dependencies') {
            steps {
                dir('backend') {
                    sh 'npm install'
                }
            }
        }

        stage('Frontend Build') {
            steps {
                dir('frontend') {
                    sh 'npm install'
                    sh 'npm run build'
                }
            }
        }

        stage('Docker Build') {
            steps {
                echo 'Building Docker images...'
                sh 'docker build -t myapp-backend:latest ./backend'
                sh 'docker build -t myapp-frontend:latest ./frontend'
            }
        }

        stage('Success') {
            steps {
                echo 'Pipeline completed successfully!'
            }
        }
    }
}

Step 4: Understanding Docker Build in CI

What Happens During Docker Build

Stage: Docker Build
    │
    ├── Backend Image
    │   ├── FROM node:18-alpine
    │   ├── WORKDIR /app
    │   ├── COPY package*.json ./
    │   ├── RUN npm install
    │   ├── COPY . .
    │   └── CMD ["npm", "start"]
    │
    └── Frontend Image
        ├── FROM nginx:alpine
        ├── COPY build /usr/share/nginx/html
        └── EXPOSE 80

Image Sizes

Image	Size	Why
myapp-backend:latest	~135MB	Node.js + dependencies
myapp-frontend:latest	~23MB	Just nginx + static files

Step 5: Testing Docker Build Locally

Before trusting Jenkins, test manually:

# Build backend image
cd backend
docker build -t test-backend .
docker run -p 3001:5000 test-backend
curl http://localhost:3001/health

# Build frontend image
cd ../frontend
npm run build
docker build -t test-frontend .
docker run -p 8080:80 test-frontend
# Open browser to http://localhost:8080

Step 6: Running the Pipeline

Trigger the Build

Go to Jenkins -> microservices-ci
Click "Build Now"
Watch the console output

Console Output

[Pipeline] stage
[Pipeline] { (Docker Build)
[Pipeline] echo
Building Docker images...
[Pipeline] sh
+ docker build -t myapp-backend:latest ./backend
#1 [internal] load build definition from dockerfile
#1 transferring dockerfile: 149B done
#1 DONE 0.2s
#2 [internal] load metadata for docker.io/library/node:18-alpine
#2 DONE 35.8s
#3 [1/5] FROM docker.io/library/node:18-alpine
#3 DONE 0.0s
...
Successfully built dd22467f3082
Successfully tagged myapp-backend:latest

[Pipeline] sh
+ docker build -t myapp-frontend:latest ./frontend
#1 [internal] load build definition from dockerfile
...
Successfully built 54515d7d59a9
Successfully tagged myapp-frontend:latest

[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Success)
[Pipeline] echo
Pipeline completed successfully!
Finished: SUCCESS

Docker in CI: Before vs After

Aspect	Before (Day 9)	After (Day 10)
Docker access	No	Yes
Backend image	Not built	Built automatically
Frontend image	Not built	Built automatically
Ready for deployment	No	Yes

Troubleshooting

Issue 1: "docker: command not found"

Error:

+ docker build
docker: command not found

Fix: Install Docker CLI in Jenkins container:

sudo docker exec jenkins bash -c "apt-get update && apt-get install -y docker.io"

Issue 2: "Permission denied"

Error:

Got permission denied while trying to connect to the Docker daemon

Fix: Run Jenkins as root user in docker-compose.yml:

services:
  jenkins:
    user: root

Issue 3: Build context issues

Error:

COPY failed: file not found in build context

Fix: Check your Dockerfile paths. The build context is the directory you specify in docker build -t name ./path.

Key Takeaways

Docker in CI = Deployable artifacts — Without Docker, you can't deploy
Mount the Docker socket — Jenkins container needs access to host's Docker
Install Docker CLI — The container needs the docker command
Tag images meaningfully — latest is fine, but version tags are better
Build once, deploy anywhere — CI builds images, they can run anywhere

Resources

Let's Connect!

Have you integrated Docker with Jenkins before? What challenges did you face with Docker in CI?

Drop a comment or connect on LinkedIn. Let's learn together!

30-Day Cloud & DevOps Challenge: Day 9 — Jenkins Pipeline + GitHub Integration

Michelle — Mon, 04 May 2026 07:09:45 +0000

Yesterday, I installed Jenkins and ran my first "Hello World" pipeline.

But that was just the beginning. Today, I connected Jenkins to my actual GitHub repository and created a REAL CI pipeline that automatically builds my entire application.

The result? A fully automated pipeline that pulls code, installs dependencies, builds the frontend, and creates Docker images — all with one click.

First: What is a CI Pipeline?

CI (Continuous Integration) means automatically building and testing your code every time it changes.

The Manual Way (Before)

# Every time you change code:
git pull
cd backend && npm install
cd ../frontend && npm install && npm run build
docker build -t myapp-backend ./backend
docker build -t myapp-frontend ./frontend
# ... repeat forever

The CI Way (After)

# Just push code:
git push

# Jenkins does EVERYTHING else automatically!

Step 1: Connecting Jenkins to GitHub

Creating the Pipeline Job

In Jenkins dashboard -> "New Item"
Name: microservices-ci
Select "Pipeline" -> OK

Configuring GitHub Connection

Scroll down to the "Pipeline" section:

Field	Value
Definition	Pipeline script from SCM
SCM	Git
Repository URL	https://github.com/Michelle8395/Production-Ready-Microservices-Platform.git
Branches to build	*/main

What this does: Jenkins will read the pipeline from a Jenkinsfile in your repository.

Step 2: Creating the Jenkinsfile

A Jenkinsfile is a text file that defines your entire pipeline as code.

Why Pipeline as Code?

Before (UI configuration)	After (Jenkinsfile)
Configuration hidden in Jenkins	Configuration in your repository
Hard to version control	Tracked with Git
Can't reproduce easily	Anyone can see the pipeline
Changes require UI clicks	Changes just need a commit

The Complete Jenkinsfile

pipeline {
    agent any

    stages {
        stage('Checkout') {
            steps {
                echo 'Cloning repository...'
                checkout scm
            }
        }

        stage('Backend Dependencies') {
            steps {
                echo 'Installing backend dependencies...'
                dir('backend') {
                    sh 'npm install'
                }
            }
        }

        stage('Frontend Build') {
            steps {
                echo 'Building frontend...'
                dir('frontend') {
                    sh 'npm install'
                    sh 'npm run build'
                }
            }
        }

        stage('Docker Build') {
            steps {
                echo 'Building Docker images...'
                sh 'docker build -t myapp-backend:latest ./backend'
                sh 'docker build -t myapp-frontend:latest ./frontend'
            }
        }

        stage('Success') {
            steps {
                echo 'Pipeline completed successfully!'
            }
        }
    }
}

Understanding Each Stage

Stage	What it does	Why it matters
Checkout	Pulls code from GitHub	Always work with latest code
Backend Dependencies	Runs npm install	Ensures all packages are available
Frontend Build	Installs and builds React	Creates production-ready static files
Docker Build	Creates container images	Packages app for deployment
Success	Reports completion	Confirms everything worked

Step 3: Running the Pipeline

Commit and Push the Jenkinsfile

git add Jenkinsfile
git commit -m "ci: add Jenkins pipeline"
git push origin main

Trigger a Build

In Jenkins, go to microservices-ci
Click "Build Now"
Watch the console output

Step 4: Reading Console Output

Success Looks Like This:

[Pipeline] stage
[Pipeline] { (Backend Dependencies)
[Pipeline] sh
+ npm install
added 94 packages in 2s
[Pipeline] }
[Pipeline] stage
[Pipeline] { (Frontend Build)
[Pipeline] sh
+ npm install
added 1314 packages in 5m
+ npm run build
Compiled successfully.
[Pipeline] }
[Pipeline] stage
[Pipeline] { (Docker Build)
[Pipeline] sh
+ docker build -t myapp-backend:latest ./backend
Successfully built xxxxx
+ docker build -t myapp-frontend:latest ./frontend
Successfully built yyyyy
[Pipeline] }
[Pipeline] stage
[Pipeline] { (Success)
[Pipeline] echo
Pipeline completed successfully!
[Pipeline] }
Finished: SUCCESS

What Each Color Means

Color	Meaning
Blue ball	Build in progress
Green check	Build succeeded
Red X	Build failed
Yellow dot	Build unstable (tests failed)

Troubleshooting Common Issues

Issue 1: "npm: not found"

Error:

+ npm install
/script.sh: 1: npm: not found

Cause: Jenkins container doesn't have Node.js installed.

Fix: Install Node.js in Jenkins container:

sudo docker exec jenkins bash -c "apt-get update && apt-get install -y nodejs npm"

Issue 2: "docker: not found"

Error:

+ docker build
docker: command not found

Cause: Jenkins can't access Docker.

Fix: Update jenkins/docker-compose.yml:

services:
  jenkins:
    user: root
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

Issue 3: Git Clone Failed

Error:

stderr: Permission denied (publickey)

Cause: Jenkins can't authenticate with GitHub.

Fix for public repos: Use HTTPS URL instead of SSH:

https://github.com/username/repo.git

Your Pipeline Architecture

┌─────────────────────────────────────────────────────────────┐
│                      JENKINS PIPELINE                       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│   Stage 1: Checkout                                         │
│   └── git clone from GitHub                                 │
│                                                             │
│   Stage 2: Backend Dependencies                             │
│   └── npm install (94 packages)                            │
│                                                             │
│   Stage 3: Frontend Build                                   │
│   ├── npm install (1314 packages)                          │
│   └── npm run build (production)                           │
│                                                             │
│   Stage 4: Docker Build                                     │
│   ├── docker build backend -> myapp-backend:latest          │
│   └── docker build frontend -> myapp-frontend:latest        │
│                                                             │
│   Stage 5: Success                                          │
│   └── Pipeline completed!                                   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Key Takeaways

Pipeline as Code = Your automation lives in Git, not hidden in Jenkins UI
Stages organize work = Each stage has one responsibility
Console output is your friend = Always check logs when something fails
Jenkins needs tools = Install Node.js, Docker inside the container
CI = Continuous Integration = Build and test every code change

Resources

Let's Connect!

Have you set up a CI pipeline before? What challenges did you face?

Drop a comment or connect on LinkedIn. Let's learn together!

30-Day Cloud & DevOps Challenge: Day 8 — Jenkins: my First CI/CD Pipeline

Michelle — Wed, 29 Apr 2026 06:43:36 +0000

Yesterday, I had all three containers running with Docker Compose; frontend, backend, and PostgreSQL.

But there was still one manual step: every time I changed code, I had to rebuild and restart containers manually.

Today, I fixed that forever.

I installed Jenkins — an automation server that watches my GitHub repository and runs tasks automatically when code changes. This is the heart of CI/CD (Continuous Integration/Continuous Deployment).

First: What is Jenkins?

In one sentence: Jenkins is a tool that automatically runs tasks when your code changes.

The Problem Jenkins Solves

Without Jenkins (where I was):

Write code
git push
Manually run docker-compose up --build
Wait
Repeat for every change

With Jenkins:

Write code
git push
Jenkins AUTOMATICALLY builds and deploys
Done!

Analogy

Without Jenkins	With Jenkins
You bake bread from scratch every morning	Bread machine bakes automatically when you add ingredients
Manual, repetitive, error-prone	Automatic, consistent, reliable

Step 1: Running Jenkins in Docker

Since my entire stack is already containerized, running Jenkins in Docker made perfect sense.

Creating the Jenkins Docker Compose File

cd ~/Desktop/Production-Ready-Microservices-Platform
mkdir jenkins
cd jenkins
nano docker-compose.yml

The docker-compose.yml for Jenkins

version: '3.8'

services:
  jenkins:
    image: jenkins/jenkins:lts
    container_name: jenkins
    restart: always
    ports:
      - "8081:8080"
      - "50000:50000"
    volumes:
      - jenkins_home:/var/jenkins_home
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - DOCKER_HOST=unix:///var/run/docker.sock

volumes:
  jenkins_home:

Understanding the Configuration

Line	What it does	Why it matters
`image: jenkins/jenkins:lts`	Uses the Long-Term Support version	Stable, reliable
`ports: - "8081:8080"`	Maps host port 8081 → container port 8080	Access Jenkins at localhost:8081
`volumes: - jenkins_home:/var/jenkins_home`	Persists Jenkins data	Jobs, settings survive container restarts
`volumes: - /var/run/docker.sock:/var/run/docker.sock`	Mounts Docker socket	Jenkins can run Docker commands!
`DOCKER_HOST=unix:///var/run/docker.sock`	Tells Jenkins where Docker is	Allows building images inside Jenkins

Starting Jenkins

sudo docker-compose up -d

What I saw:

[+] Running 2/2
 ✔ Network jenkins_default     Created
 ✔ Container jenkins           Started

Step 2: Accessing Jenkins Web Interface

Check Jenkins is Running

sudo docker ps

Output:

CONTAINER ID   IMAGE                 COMMAND   STATUS         PORTS
xxxxxx         jenkins/jenkins:lts   ...       Up ...         0.0.0.0:8081->8080/tcp

Open Jenkins

In your browser: http://localhost:8081

Step 3: Unlocking Jenkins

Jenkins requires an initial admin password.

Get the Password

sudo docker exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword

Output: A long string of letters and numbers (copy this!)

Paste the Password

On the Jenkins web page, paste the password
Click "Continue"

Step 4: Installing Plugins

Jenkins asked which plugins to install. I chose "Install suggested plugins"

What are plugins? Extensions that add features to Jenkins:

Git integration
Docker pipeline
Blue Ocean (pretty UI)
Many more

Step 5: Creating Admin User

After plugins installed, I created my admin account:

Field	What I entered
Username	`admin`
Password	(created a strong password)
Full name	My name
Email	My email

Click "Save and Continue"

Step 6: Jenkins is Ready!

After confirming the URL (default is fine), I clicked "Start using Jenkins"

I saw the Jenkins dashboard!

Step 7: My First Pipeline Job

Creating a New Job

Click "New Item" on the left menu
Enter name: my-first-pipeline
Select "Pipeline"
Click OK

Writing the Pipeline Script

In the "Pipeline" section, I selected "Pipeline script" and added:

pipeline {
    agent any

    stages {
        stage('Hello') {
            steps {
                echo 'Hello from Jenkins!'
            }
        }

        stage('Date') {
            steps {
                sh 'date'
            }
        }

        stage('Who Am I') {
            steps {
                sh 'whoami'
            }
        }

        stage('Docker Version') {
            steps {
                sh 'docker --version'
            }
        }
    }
}

What This Pipeline Does

Stage	What it does	Output example
Hello	Prints a greeting	`Hello from Jenkins!`
Date	Runs `date` command	`Tue Apr 28 14:30:00 EAT 2026`
Who Am I	Shows user Jenkins runs as	`root` (or `jenkins`)
Docker Version	Checks Docker is available	`Docker version 28.5.2`

Running the Pipeline

Click "Save"
Click "Build Now" on the left menu
Click on build #1
Click "Console Output"

What I saw:

[Pipeline] Start of Pipeline
[Pipeline] stage
[Pipeline] { (Hello)
[Pipeline] echo
Hello from Jenkins!
[Pipeline] }
[Pipeline] stage
[Pipeline] { (Date)
[Pipeline] sh
+ date
Tue Apr 29 10:30:00 EAT 2026
[Pipeline] }
[Pipeline] stage
[Pipeline] { (Docker Version)
[Pipeline] sh
+ docker --version
Docker version 28.5.2, build 9cc6dea35e
[Pipeline] }
[Pipeline] End of Pipeline
Finished: SUCCESS

It worked! Jenkins successfully ran my pipeline!

Jenkins vs Docker Compose (Understanding the Difference)

Tool	What it does	When to use
Docker Compose	Runs multiple containers together	Starting your app locally
Jenkins	Automates tasks when code changes	CI/CD, automatic builds, testing

They work TOGETHER:

You push code → Jenkins sees it → Jenkins runs Docker Compose → Your app updates

Issues I Ran Into (And Fixed)

Issue 1: Docker Pull Timeout

Error:

dial tcp: lookup registry-1.docker.io: i/o timeout

Cause: DNS configuration issue with Docker.

Fix:

# Create Docker daemon config
sudo nano /etc/docker/daemon.json

# Add DNS servers
{
  "dns": ["8.8.8.8", "1.1.1.1"]
}

# Restart Docker
sudo systemctl restart docker

Issue 2: Port Already in Use

Error:

Bind for 0.0.0.0:8080 failed: port is already allocated

Cause: Something else was using port 8080 (maybe another Jenkins or web server).

Fix: Used port 8081 instead of 8080.

Issue 3: Jenkins Container Not Starting

Fix: Check logs:

sudo docker logs jenkins

Docker Commands for Jenkins

Command	What it does
`sudo docker-compose up -d`	Start Jenkins in background
`sudo docker-compose down`	Stop Jenkins
`sudo docker logs jenkins`	View Jenkins logs
`sudo docker exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword`	Get admin password

Pipeline Syntax Basics

Groovy Element	What it does
`pipeline { }`	Wraps the entire pipeline
`agent any`	Run on any available agent
`stages { }`	Contains all stages
`stage('name') { }`	A named step in the pipeline
`steps { }`	Contains the actual commands
`echo 'text'`	Print text to console
`sh 'command'`	Run a shell command

Key Takeaways

Jenkins automates repetitive tasks — No more manual builds
CI/CD = Continuous Integration/Continuous Deployment — Automate from code push to deployment
Jenkins runs in Docker too — Consistent with our containerized stack
Plugins extend Jenkins — Git, Docker, Slack, etc.
Pipeline as Code — Your build process lives in code, not click-ops

Resources

Let's Connect!

Have you used Jenkins before? What CI/CD tool do you prefer — Jenkins, GitHub Actions, GitLab CI, or something else?

Drop a comment or connect on LinkedIn. Let's learn together!

30-Day Cloud & DevOps Challenge: Day 7 — Docker Compose: One Command to Rule Them All

Michelle — Sun, 12 Apr 2026 14:35:05 +0000

Yesterday, I had two containers: one for my backend, one for my frontend.

But running them meant two terminals, two docker run commands, and remembering which port mapped to what.

Today, I fixed that forever.

I learned Docker Compose a tool that lets me define my entire application stack in one file and start everything with a SINGLE command.

First: What Problem Does Docker Compose Solve?

Without Docker Compose (Days 5 & 6)

# Terminal 1
cd backend
sudo docker build -t backend-app .
sudo docker run -p 3001:5000 backend-app

# Terminal 2 (new terminal)
cd frontend
npm run build
sudo docker build -t frontend-app .
sudo docker run -p 8080:80 frontend-app

The pain:

Multiple terminals
Many commands to remember
Containers don't automatically know about each other
Hard to share setup with others

With Docker Compose (Today)

# One terminal. One command.
sudo docker-compose up --build

That's it. Everything runs.

What is Docker Compose?

In one sentence: Docker Compose is a tool that lets you define and run multiple Docker containers together using a single YAML file.

The Analogy

Concept	Docker Alone	Docker Compose
Individual containers	Shipping containers	Shipping containers
Managing them	Moving each by hand	A crane operator with a manifest
Documentation	Remember what goes where	Everything in one file

Docker Compose is the crane operator + manifest that organizes all your containers at once.

Step 1: Creating docker-compose.yml

First, I went to my project root:

cd ~/Desktop/Production-Ready-Microservices-Platform

Then I created the Compose file:

touch docker-compose.yml
nano docker-compose.yml

Step 2: Writing the Compose File (Line by Line)

Line 1: Version

version: '3.8'

What this means: Which version of Docker Compose syntax to use (3.8 is current).

Line 2: Services Section

services:

What this means: Everything below defines containers (called "services").

Lines 3-6: Backend Service

  backend:
    build: ./backend
    ports:
      - "3001:5000"

Line	Meaning
`backend:`	Name of the service
`build: ./backend`	Build image using Dockerfile in `./backend`
`ports:`	Define port mapping
`- "3001:5000"`	Map host 3001 → container 5000

Lines 7-10: Frontend Service

  frontend:
    build: ./frontend
    ports:
      - "8080:80"

Same pattern, but for the frontend (port 8080 → 80).

The Complete File

version: '3.8'

services:
  backend:
    build: ./backend
    ports:
      - "3001:5000"

  frontend:
    build: ./frontend
    ports:
      - "8080:80"

That's it! 12 lines to define my entire application.

Step 3: What Docker Compose Does Behind the Scenes

When I ran docker-compose up --build, Compose did ALL of this automatically:

# 1. Created a shared network
docker network create microservices-platform_default

# 2. Built backend image
docker build -t microservices-platform-backend ./backend

# 3. Built frontend image
docker build -t microservices-platform-frontend ./frontend

# 4. Started backend container
docker run -d \
  --name microservices-platform-backend-1 \
  --network microservices-platform_default \
  -p 3001:5000 \
  microservices-platform-backend

# 5. Started frontend container
docker run -d \
  --name microservices-platform-frontend-1 \
  --network microservices-platform_default \
  -p 8080:80 \
  microservices-platform-frontend

All of that from one command. That's the magic of Docker Compose.

Step 4: Running Everything

sudo docker-compose up --build

What I saw:

[+] Building 2.5s (15/15) FINISHED
[+] Running 3/3
 ✔ backend   Built
 ✔ frontend  Built
 ✔ Network microservices-platform_default  Created

Then the containers started:

frontend-1  | /docker-entrypoint.sh: Configuration complete; ready for start up
backend-1   | Server is running on http://localhost:5000
backend-1   | Try these endpoints:
backend-1   |   - http://localhost:5000/
backend-1   |   - http://localhost:5000/health
backend-1   |   - http://localhost:5000/users

Both containers running simultaneously in ONE terminal!

Step 5: Testing Everything

Testing the Backend

In a new terminal:

curl http://localhost:3001/health

Response:

{"status":"healthy","service":"backend-api","timestamp":"2026-04-12T13:10:49.057Z"}

Testing the Frontend

In my browser: http://localhost:8080

My React app appeared! Same as Day 3, but now running inside a container managed by Compose.

Step 6: Stopping Everything

To stop all containers:

# In the Compose terminal, press Ctrl+C
Ctrl+C

# Then clean up
sudo docker-compose down

One command stops EVERYTHING. No more hunting for container IDs.

Docker vs Docker Compose: The Comparison

Task	Docker Alone	Docker Compose
Run one container	`docker run ...`	Overkill
Run multiple containers	Multiple commands	`docker-compose up`
Connect containers	Manual network setup	Automatic network
Start order	Manual (wait, then start)	`depends_on`
Environment variables	`-e` flag each time	In file
Port mapping	`-p` flag each time	In file
Share setup	Send commands to friend	Send one file
Rebuild after changes	Manual rebuild	`--build` flag
View logs	`docker logs ID`	`docker-compose logs`

Why Your Project NEEDS Docker Compose

Your Architecture

User → Frontend (React) → Backend (Node.js) → (Soon: PostgreSQL)

Each component has different needs:

Need	Frontend	Backend	Database (coming)
Base image	nginx:alpine	node:18-alpine	postgres:15
Port	80	5000	5432
Storage	None	None	Persistent volume
Start order	Last	Middle	First
Scale for	User traffic	API calls	Data growth

Without Compose (Manual Nightmare)

# Start database
docker run -d --name postgres -v postgres_data:/var/lib/postgresql/data postgres:15

# Wait for database
sleep 5

# Start backend
docker run -d --name backend --link postgres -e DB_HOST=postgres backend-app

# Start frontend
docker run -d --name frontend -p 8080:80 frontend-app

# Create network
docker network create myapp
docker network connect myapp postgres backend frontend

# To stop: 4 separate commands

15+ commands! One mistake and nothing works.

With Compose (One File)

version: '3.8'

services:
  postgres:
    image: postgres:15
    volumes:
      - postgres_data:/var/lib/postgresql/data

  backend:
    build: ./backend
    depends_on:
      - postgres
    environment:
      - DB_HOST=postgres

  frontend:
    build: ./frontend

# ONE command
docker-compose up --build

3 commands total. Perfect every time.

Issues I Ran Into

Issue 1: "no configuration file provided"

Error:

no configuration file provided: not found

Cause: I was in the wrong directory.

Fix:

cd ~/Desktop/Production-Ready-Microservices-Platform
ls -la docker-compose.yml  # Verify file exists

Issue 2: Port already allocated

Error:

Bind for 0.0.0.0:8080 failed: port is already allocated

Cause: I still had my old frontend container running from Day 6.

Fix:

sudo docker ps  # Find running containers
sudo docker stop <container_id>  # Stop the old one
sudo docker-compose up  # Now it works

Issue 3: The "version is obsolete" warning

Warning:

the attribute `version` is obsolete, it will be ignored

Fix: I can remove the version: '3.8' line — newer Docker versions don't need it.

Docker Compose Commands Cheat Sheet

Command	What it does
`docker-compose up`	Start all services
`docker-compose up -d`	Start in background (detached)
`docker-compose up --build`	Rebuild images then start
`docker-compose down`	Stop and remove containers
`docker-compose down -v`	Also remove volumes (databases!)
`docker-compose ps`	Show status of services
`docker-compose logs`	View logs from all services
`docker-compose logs backend`	View logs from backend only
`docker-compose build`	Rebuild images without starting
`docker-compose restart`	Restart all services

Key Takeaways

Docker Compose = Multiple containers, one command — No more terminal juggling
Everything in one file — Share your setup with anyone
Automatic networking — Containers can find each other by name
Declarative configuration — Say WHAT you want, not HOW
Local = Production — Same Compose file works everywhere

Resources

30-Day Cloud & DevOps Challenge: Day 6 — Dockerizing My React Frontend

Michelle — Sat, 11 Apr 2026 14:55:23 +0000

Yesterday, I packaged my backend into a Docker container. Today, I did the same for my React frontend.

But there's a twist, frontend containers are DIFFERENT. No Node.js running. No npm start. Just pure, static files served by nginx.

And I learned why nginx is the king of web servers.

First: How Frontend Docker is Different

Backend Container	Frontend Container
Runs Node.js server	Runs nginx (web server)
Needs `npm start`	Just serves static files
Code changes often	Build once, serve forever
Port 5000	Port 80 (standard web port)
~135MB image	~23MB image

Analogy:

Backend = Restaurant kitchen (active cooking, handling requests)
Frontend = Dining room + menu (just shows what's ready)

Step 1: Building React for Production

Right now, I run React with npm start (development mode). For Docker, I need a production build, optimized, minified, and ready to serve.

Navigate to frontend folder

cd ~/Desktop/Production-Ready-Microservices-Platform/frontend

Build the production version

npm run build

What this command does:

Takes all my React code
Optimizes it (removes comments, shortens variable names)
Minifies files (makes them smaller)
Creates a build folder with everything needed

What I saw:

Creating an optimized production build...
Compiled successfully.

File sizes after gzip:
  40.21 kB  build/static/js/main.xxxxx.js
  1.78 kB   build/static/css/main.xxxxx.css

Verify the build folder

ls

I could see the build folder (blue or highlighted in terminal).

ls build

Output:

index.html  static  asset-manifest.json

What's inside:

index.html — The main HTML file
static/ — JavaScript and CSS files
asset-manifest.json — Map of all assets

Step 2: Creating the Dockerfile

Why nginx?

nginx (pronounced "engine-x") is the most popular web server in the world. It's:

Feature	Why It Matters
Fast	Can handle 10,000+ connections simultaneously
Lightweight	Alpine version is only 23MB
Reliable	Used by Netflix, Airbnb, Uber, Dropbox
Simple	Just point it to your files and it works

Create the Dockerfile

nano Dockerfile

The Complete Dockerfile

FROM nginx:alpine
COPY build /usr/share/nginx/html
EXPOSE 80

That's it! Three lines. Frontend containers are much simpler than backend.

Understanding Each Line

Line	What it does	Why
`FROM nginx:alpine`	Start with nginx on Alpine Linux	Tiny base image (23MB)
`COPY build /usr/share/nginx/html`	Put React files where nginx looks	nginx serves from this folder by default
`EXPOSE 80`	Document the port	Standard web port

What is `/usr/share/nginx/html`?

This is nginx's default document root — the folder where it looks for files to serve. When you put index.html there, nginx automatically serves it.

Save and verify

# Save: Ctrl+O, Enter, Ctrl+X

# Verify the file
cat Dockerfile

Output:

FROM nginx:alpine
COPY build /usr/share/nginx/html
EXPOSE 80

Step 3: Building the Frontend Image

sudo docker build -t frontend-app .

Breaking down the command:

Part	Meaning
`sudo docker build`	Build an image
`-t frontend-app`	Tag it as "frontend-app"
`.`	Use Dockerfile in current directory

What I saw:

[+] Building 0.5s (5/5) FINISHED
 => [1/2] FROM nginx:alpine
 => [2/2] COPY build /usr/share/nginx/html
 => exporting to image
 => => naming to docker.io/library/frontend-app:latest

Verify the image

sudo docker images

Output:

REPOSITORY     TAG       IMAGE ID       CREATED         SIZE
frontend-app   latest    xxxxxxx        1 minute ago    23MB
backend-app    latest    e0e0904815be   1 day ago       135MB
nginx          alpine    xxxxxxx        2 weeks ago     23MB

Notice the size difference:

Backend image: 135MB (Node.js + dependencies)
Frontend image: 23MB (just static files + nginx)

Step 4: Running the Frontend Container

sudo docker run -p 8080:80 frontend-app

Understanding the port mapping:

Part	Meaning
`-p 8080:80`	Map port 8080 (my computer) → port 80 (container)
`frontend-app`	Which image to use

Why port 80? Port 80 is the standard web port. Browsers use it by default when you visit http://example.com.

Why map to 8080? Port 80 is often already in use. 8080 is a common alternative.

What I saw: Nothing in the terminal. That's normal! nginx runs silently.

Step 5: Testing the Container

Open browser

I went to: http://localhost:8080

My React app appeared! The same one I built on Day 3.

Check running containers

In a new terminal:

sudo docker ps

Output:

CONTAINER ID   IMAGE          COMMAND                  CREATED         STATUS         PORTS
b8194975c784   frontend-app   "/docker-entrypoint.…"   3 minutes ago   Up 3 minutes   0.0.0.0:8080->80/tcp

What this shows:

Container is running
Port 8080 on my computer → port 80 inside container
Status: Up (healthy!)

Running Both Containers

Now I have TWO containers running:

Container	Image	Port	Purpose
frontend-app	nginx:alpine	8080	Serves React app
backend-app	node:18-alpine	3001	API endpoints

To see both:

sudo docker ps

Output:

CONTAINER ID   IMAGE           COMMAND                  PORTS
b8194975c784   frontend-app    "/docker-entrypoint.…"   0.0.0.0:8080->80/tcp
a1b2c3d4e5f6   backend-app     "docker-entrypoint.s…"   0.0.0.0:3001->5000/tcp

Step 6: Stopping the Container

To stop the frontend container, I went to its terminal and pressed:

Ctrl + C

The container stopped gracefully.

What I Learned

Why nginx for Frontend?

Alternative	Pros	Cons
`serve` (npm package)	Simple	Needs Node.js installed
`http-server`	Easy	Not production-ready
nginx	Fast, reliable, tiny	Slight learning curve

Production Build vs Development

Aspect	`npm start` (dev)	`npm run build` (prod)
File size	Large (unminified)	Small (minified)
Source maps	Yes (debugging)	No (smaller)
Hot reload	Yes	No
Performance	Slow	Fast
Use case	Development	Production/Docker

The Build Process Explained

React Source Code (JSX, Components)
        ↓
    npm run build
        ↓
Optimized Files (minified, bundled)
        ↓
   build/ folder
        ↓
    COPY to nginx
        ↓
     Served to users

Mistakes I Made (And Fixed)

Mistake 1: Trying to use `npm start` in Docker

What I thought: I could just do CMD ["npm", "start"] like backend

Why it's wrong: React's dev server isn't meant for production containers

Fix: Use nginx to serve static files

Mistake 2: Wrong COPY destination

What I tried: COPY build /var/www/html

Why it's wrong: nginx default folder is /usr/share/nginx/html

Fix: Use the correct nginx document root

Mistake 3: Forgetting to run `npm run build`

What happened: Docker couldn't find the build folder

Error: COPY failed: stat build: file does not exist

Fix: Always run npm run build before building the Docker image

Docker Commands Cheat Sheet (Updated)

Command	What it does
`npm run build`	Create production build of React app
`docker build -t name .`	Build image from Dockerfile
`docker images`	List all images
`docker run -p HOST:CONTAINER image`	Run container from image
`docker ps`	List running containers
`docker ps -a`	List ALL containers (including stopped)
`docker stop container_id`	Stop running container
`docker rm container_id`	Remove stopped container
`docker rmi image_id`	Remove image

Key Takeaways

Frontend containers are simpler — Just static files + web server
nginx is the industry standard — 40% of all websites use it
Production builds are essential — npm run build creates optimized files
Alpine images are tiny — My frontend image is only 23MB
Port mapping is still important — Container port 80 → host port 8080

Resources

Let's Connect!

Have you containerized a frontend app before? What web server do you prefer? nginx, Apache, or something else?

Drop a comment or connect on LinkedIn. Let's learn together!

This is Day 6 of my 30-Day Cloud & DevOps Challenge. Follow along as I build a complete microservices platform from scratch!

30-Day Cloud & DevOps Challenge: Day 5 — Dockerizing My Backend (First Steps into Containers)

Michelle — Sat, 11 Apr 2026 14:28:01 +0000

Yesterday, I had a working PostgreSQL database with real data. But there was one problem...

My backend still ran with npm run dev. It worked on MY laptop, but would it work anywhere else?

Today, I solved that forever.

I packaged my Node.js backend into a Docker container — a self-contained unit that runs IDENTICALLY on any computer. And I learned why containers are revolutionizing software deployment.

First: What Even IS Docker? (Explained Simply)

The Problem Docker Solves

Before Docker (The "It works on my machine" nightmare):

Computer	Issue
Your laptop	Node.js v18, PostgreSQL local
Your coworker's laptop	Node.js v14, different OS
Cloud server	Ubuntu, missing dependencies
Production	Completely different environment

Result: "But it worked on MY machine!"

The Docker Solution

Think of Docker like a shipping container:

Analogy	Docker
Shipping container	Docker container
Ship, train, truck	Any computer running Docker
Your stuff inside	Your app + Node.js + all dependencies

The magic: Once it's in a container, it runs IDENTICALLY everywhere.

Step 1: Checking Docker Installation

First, I needed to verify Docker was installed on my Ubuntu system:

docker --version

Output:

Docker version 29.2.1, build a5c7197

Docker was installed! But I hit a permission issue:

docker ps

Error:

permission denied while trying to connect to the docker API

Fixing Docker Permissions

The issue: My user wasn't in the docker group.

Solution:

# Add my user to docker group
sudo usermod -aG docker mkangeth

# Log out and back in (or restart)
# Then verify
docker ps

Alternative (what I used): Added sudo before each docker command:

sudo docker ps

Output:

CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

Empty list = Docker is working!

Step 2: Creating the Dockerfile

A Dockerfile is like a recipe that tells Docker how to build your container.

What is a Dockerfile?

Think of it like baking a cake:

Baking Analogy	Dockerfile Instruction
Start with base ingredients	`FROM node:18-alpine`
Set up your workspace	`WORKDIR /app`
Add your ingredients	`COPY package*.json ./`
Mix everything	`RUN npm install`
Present the final cake	`CMD ["npm", "start"]`

Creating the File

First, navigate to my backend folder:

cd ~/Desktop/Production-Ready-Microservices-Platform/backend

Create the Dockerfile:

touch Dockerfile
nano Dockerfile

The Complete Dockerfile (Line by Line)

# Use Node.js 18 on Alpine Linux (tiny Linux, only 5MB!)
FROM node:18-alpine

# Create and set working directory inside the container
WORKDIR /app

# Copy package files first (for Docker caching)
COPY package*.json ./

# Install all dependencies
RUN npm install

# Copy all source code
COPY . .

# Tell Docker the container listens on port 5000
EXPOSE 5000

# Start the application
CMD ["npm", "start"]

Why Each Line Matters

Instruction	What it does	Why it's important
`FROM node:18-alpine`	Base image with Node.js	Alpine is tiny (5MB vs 100MB+)
`WORKDIR /app`	Sets working directory	All commands run from here
`COPY package*.json ./`	Copies dependency list	Docker caches this layer
`RUN npm install`	Installs dependencies	Happens inside the container
`COPY . .`	Copies your code	Last layer (changes most often)
`EXPOSE 5000`	Documents the port	Doesn't publish, just informs
`CMD ["npm", "start"]`	Runs when container starts	Production command, not dev

Step 3: Building the Docker Image

Now the magic happens — building my image:

sudo docker build -t backend-app .

Breaking down the command:

Part	Meaning
`sudo docker build`	Build an image from a Dockerfile
`-t backend-app`	Tag (name) the image "backend-app"
`.`	Use Dockerfile in current directory

What I saw:

[+] Building 45.2s (10/10) FINISHED
 => [1/5] FROM node:18-alpine
 => [2/5] WORKDIR /app
 => [3/5] COPY package*.json ./
 => [4/5] RUN npm install
 => [5/5] COPY . .
 => exporting to image
 => => naming to docker.io/library/backend-app:latest

Verifying the Image

sudo docker images

Output:

REPOSITORY     TAG       IMAGE ID       CREATED         SIZE
backend-app    latest    e0e0904815be   2 minutes ago   135MB
node           18-alpine f0286cc18189   2 weeks ago     120MB

My image is 135MB — much smaller than a full Ubuntu image would be (thanks, Alpine!)

Step 4: Running the Container

Time to run my backend inside a container:

sudo docker run -p 3001:5000 backend-app

Understanding port mapping:

Part	Meaning
`-p 3001:5000`	Map port 3001 (my computer) → port 5000 (container)
`backend-app`	Which image to use

Why port mapping?

Inside container: app runs on port 5000
On my computer: I can access it via port 3001

Output:

> backend@1.0.0 start
> node server.js

 Server is running on http://localhost:5000
 Try these endpoints:
   - http://localhost:5000/
   - http://localhost:5000/health
   - http://localhost:5000/users

The terminal stays "stuck" here — that's GOOD! My server is running!

Step 5: Testing the Container

In a new terminal, I tested my running container:

curl http://localhost:3001/health

Response:

{"status":"healthy","service":"backend-api","timestamp":"2026-04-11T14:03:42.057Z"}

Then tested the users endpoint:

curl http://localhost:3001/users

Response:

[
  {"id":1,"name":"Alice","email":"alice@example.com"},
  {"id":2,"name":"Bob","email":"bob@example.com"},
  {"id":3,"name":"Charlie","email":"charlie@example.com"}
]

SUCCESS! My Dockerized backend was working perfectly!

Step 6: Stopping the Container

To stop the container, I went back to the first terminal and pressed:

Ctrl + C

The server shut down gracefully.

What I Learned

Docker Concepts I Mastered

Concept	What I learned
Image	A blueprint/template (like a class in programming)
Container	A running instance of an image (like an object)
Dockerfile	The recipe that defines how to build an image
Port mapping	Connecting container ports to host ports
Layer caching	Docker reuses unchanged layers for faster builds

The Docker Workflow

Dockerfile → docker build → Image → docker run → Container
   (recipe)      (build)     (blueprint)   (run)    (running app)

Why Alpine Linux?

Base Image	Size	Use case
`node:latest`	~1GB	Full OS, many tools
`node:18-slim`	~200MB	Minimal Debian
`node:18-alpine`	~120MB	Tiny, security-focused

I chose Alpine: Smaller = faster downloads, less storage, smaller attack surface.

Mistakes I Made (And Fixed)

Mistake 1: Docker Permission Denied

Error:

permission denied while trying to connect to the docker API

Fix: Added sudo before docker commands OR added user to docker group:

sudo usermod -aG docker $USER
# Then log out and back in

Mistake 2: Wrong Port Mapping

What happened: My server ran on port 5000, but I mapped to port 8000

Fix:

# Wrong
sudo docker run -p 3001:8000 backend-app

# Correct
sudo docker run -p 3001:5000 backend-app

Lesson: Always check what port your app actually uses!

Docker Commands Cheat Sheet

Command	What it does
`docker --version`	Check Docker version
`docker images`	List all images on your computer
`docker ps`	List RUNNING containers
`docker ps -a`	List ALL containers (including stopped)
`docker build -t name .`	Build an image from Dockerfile
`docker run -p HOST:CONTAINER image`	Run a container from an image
`docker stop container_id`	Stop a running container
`docker rm container_id`	Remove a stopped container
`docker rmi image_id`	Remove an image
`docker logs container_id`	See container logs

Key Takeaways

Containers are NOT virtual machines — They share the host OS kernel, making them lightweight and fast
Dockerfiles are recipes — They define exactly how to build your container
Images are blueprints — You build once, run anywhere
Containers are running instances — You can run many containers from one image
Port mapping is essential — Containers have their own network; you must expose ports
Alpine Linux is your friend — Tiny images = faster everything

Resources

Let's Connect!

Have you used Docker before? What was your first container? Any tips for someone just starting?

Drop a comment or connect on LinkedIn. Let's learn together!

This is Day 5 of my 30-Day Cloud & DevOps Challenge. Follow along as I build a complete microservices platform from scratch!

30-Day Cloud & DevOps Challenge: Day 4 — PostgreSQL Deep Dive (From Zero to Database Hero)

Michelle — Wed, 08 Apr 2026 09:13:28 +0000

Yesterday, my React frontend finally talked to my Node.js backend. But there was one problem...

The users were FAKE. Hardcoded in server.js. Every time the server restarted, any new users would disappear forever.

Today, I fixed that permanently.

I installed PostgreSQL, created a database, built a users table, and stored real data that survives server restarts. And I learned WAY more about databases than I expected.

First: What Even IS a Database?

Before writing a single command, I needed to understand what a database actually IS.

Think of it like this:

Real World	Database
A filing cabinet	The database itself
A drawer in the cabinet	A table
A folder in the drawer	A row (record)
Information on the folder	Columns (fields)

For my users:

One drawer called users
Each folder has: an ID number, a name, an email address, a creation date
I can open any folder, read it, change it, or throw it away

The magic: Even if I turn off my computer, the filing cabinet (database) still has all my folders.

Step 1: Installing PostgreSQL

I'm on Ubuntu Linux, so installation was straightforward:

# Update my package list (like refreshing the app store)
sudo apt update

# Install PostgreSQL
sudo apt install postgresql postgresql-contrib -y

# Verify it's running
sudo systemctl status postgresql

What I learned about each command:

Command	What it actually does
`sudo`	"Super user do" — gives admin permissions
`apt update`	Refreshes the list of available software
`apt install postgresql`	Downloads and installs the database
`-y`	Automatically answers "yes" to confirmation prompts

The moment I knew it worked: Seeing Active: active (running) in green text.

Step 2: Understanding PostgreSQL Users

When PostgreSQL installs, it automatically creates:

A system user called postgres (the admin/manager)
A default database also called postgres

Analogy:

Concept	Analogy
PostgreSQL	A bank vault
`postgres` user	The bank manager (has all the keys)
My job	Ask the manager to create a vault for MY project

To become the manager:

sudo -u postgres psql

My prompt changed from: mkangeth@LAP-018:~$

To: postgres=#

Note: That postgres=# means I'm INSIDE PostgreSQL now. Different commands work here.

Step 3: My First PostgreSQL Commands

Seeing what databases already exist:

\l

This showed me three databases: postgres, template0, template1. None were mine.

Creating MY database:

CREATE DATABASE microservices_platform;

Response: CREATE DATABASE — it worked!

Creating a user for my app:

CREATE USER app_user WITH PASSWORD 'mysecretpassword';

Response: CREATE ROLE

Giving my user permission:

GRANT ALL PRIVILEGES ON DATABASE microservices_platform TO app_user;

Response: GRANT

Connecting to MY database:

\c microservices_platform

Response: You are now connected to database "microservices_platform"

Notice: My prompt changed to microservices_platform=#

Step 4: Creating My First Table

Now for the exciting part — creating a table to store users.

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    email VARCHAR(100) UNIQUE NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Let me explain EVERY piece:

Part	What it means
`CREATE TABLE users`	Make a new table called "users"
`id SERIAL PRIMARY KEY`	Auto-number each user (1,2,3...) and use it as the unique identifier
`name VARCHAR(100) NOT NULL`	Name column, max 100 characters, can't be empty
`email VARCHAR(100) UNIQUE NOT NULL`	Email column, max 100 chars, no duplicates, can't be empty
`created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP`	Automatically sets the current time when a user is added

Response: CREATE TABLE — my table exists!

Step 5: Inserting Data

Time to add some users:

INSERT INTO users (name, email) VALUES 
('Alice', 'alice@example.com'),
('Bob', 'bob@example.com'),
('Charlie', 'charlie@example.com');

Response: INSERT 0 3 — three users added successfully.

Step 6: Reading My Data

The moment of truth — seeing what's actually in my database:

SELECT * FROM users;

Output:

id |  name   |        email        |         created_at
----+---------+---------------------+----------------------------
 1 | Alice   | alice@example.com   | 2026-04-08 09:57:56.360654
 2 | Bob     | bob@example.com     | 2026-04-08 09:57:56.360654
 3 | Charlie | charlie@example.com | 2026-04-08 09:57:56.360654
(3 rows)

I literally cheered. My data was stored permanently in a real database!

Step 7: Exiting PostgreSQL

\q

Back to my normal terminal prompt.

What I Learned About Databases (Deep Dive)

Why PostgreSQL Specifically?

Feature	Why It Matters
ACID compliance	Transactions are atomic — either fully complete or fully fail (no partial updates)
MVCC	Multiple users can read/write simultaneously without locking each other
Advanced data types	JSON, arrays, hstore, geometric data — not just strings and numbers
Standards compliant	Learning PostgreSQL teaches you SQL that works on Oracle, DB2, etc.

The Data Types I Used

Type	What it stores	Example
`SERIAL`	Auto-incrementing integer	1, 2, 3, 4...
`VARCHAR(100)`	Text up to 100 characters	"Alice"
`TIMESTAMP`	Date and time	"2026-04-08 09:57:56"

The Constraints I Used

Constraint	What it does
`PRIMARY KEY`	Uniquely identifies each row (no duplicates, never null)
`NOT NULL`	This field must have a value
`UNIQUE`	No two rows can have the same value in this column
`DEFAULT`	If no value is provided, use this automatic value

Mistakes I Made (And Fixed)

Mistake 1: Typing PostgreSQL commands in the normal terminal

What happened: I typed \c at mkangeth@LAP-018:~$ and got command not found

Why: \c is a PostgreSQL command, not a Linux command

Fix: Enter PostgreSQL first with sudo -u postgres psql

Mistake 2: Forgetting the semicolon

What happened: I typed CREATE DATABASE microservices_platform and nothing happened

Why: PostgreSQL waits for ; to know the command is complete

Fix: Always end SQL commands with ;

Mistake 3: Incomplete CREATE DATABASE

What happened: I typed CREATE DATABASE microservices and got stuck at a postgres-# prompt

Why: I didn't finish the command

Fix: Press Ctrl+C to cancel, then retype the full command

PostgreSQL vs Other Databases (What I Learned)

Database	Best For	Why
PostgreSQL	Complex apps, data integrity	Full SQL support, ACID compliant
MySQL	Simple web apps, WordPress	Fast reads, easier to learn
SQLite	Mobile apps, local storage	No server needed, single file
MongoDB	Flexible schema, JSON data	No fixed structure, horizontal scaling
Firebase	Real-time apps, prototyping	Built-in auth, real-time updates
Supabase	PostgreSQL + convenience	Open source, real-time, auto-API

Why I chose PostgreSQL for this project: It's the industry standard for serious applications. Apple, Netflix, and Uber all use it.

Key Takeaways

Databases are permanent storage — unlike server memory, data survives restarts
Tables have structure — columns define what data looks like (types, constraints)
PostgreSQL is powerful — ACID compliance, advanced data types, concurrency handling
SQL is the language — CREATE, INSERT, SELECT, UPDATE, DELETE
The prompt tells you where you are — $ = terminal, =# = PostgreSQL

Quick Reference: PostgreSQL Commands I Learned

Command	What it does
`sudo -u postgres psql`	Enter PostgreSQL as admin
`\l`	List all databases
`\c database_name`	Connect to a specific database
`\d`	List all tables in current database
`\d table_name`	Show table structure
`CREATE DATABASE name;`	Create a new database
`CREATE USER name WITH PASSWORD 'pass';`	Create a new user
`GRANT ALL PRIVILEGES ON DATABASE db TO user;`	Give user permissions
`CREATE TABLE ...`	Create a new table
`INSERT INTO ... VALUES ...`	Add data to a table
`SELECT * FROM ...`	Read data from a table
`\q`	Exit PostgreSQL

Resources

Let's Connect!

Have you worked with databases before? SQL or NoSQL? What's your preference and why?

Drop a comment or connect on LinkedIn. Let's learn together!

30-Day Cloud & DevOps Challenge: Day 3 — Connecting Frontend to Backend (The CORS Journey)

Michelle — Fri, 03 Apr 2026 10:42:26 +0000

After yesterday's backend success, today was about making my React frontend actually TALK to my Node.js API.

Spoiler alert: It wasn't as simple as I thought. But that's where the real learning happened.

What I Set Out to Do Today

Build a React frontend that:

✅ Connects to my backend API
✅ Fetches health status automatically
✅ Displays users from the database
✅ Shows everything in a nice UI

Simple, right? Well... let me share the journey.

Step 1: Creating the React App

I started by creating a React app in my project folder:

cd ~/Desktop/Production-Ready-Microservices-Platform
npx create-react-app frontend

This created a complete React application with all the boilerplate code.

What I learned: create-react-app is a magical command that sets up an entire React development environment in minutes. It includes:

Development server with hot reloading
Build tools (webpack, Babel)
Testing setup
Production build optimization

Step 2: Cleaning Up Unnecessary Files

React creates many example files. I removed what I didn't need:

cd frontend/src
rm App.test.js setupTests.js reportWebVitals.js logo.svg

What I learned: reportWebVitals.js tracks performance metrics (load time, responsiveness). Not needed for learning, but useful for production apps.

Oops moment: After deleting files, React crashed because index.js was still trying to import reportWebVitals. Fixed by removing those import lines from index.js.

Step 3: Writing the React Component

Here's the complete App.js I built:

import { useState, useEffect } from 'react';
import './App.css';

function App() {
  // State = memory for our component
  const [backendStatus, setBackendStatus] = useState('Checking backend...');
  const [users, setUsers] = useState([]);
  const [loading, setLoading] = useState(false);

  // useEffect = runs automatically when page loads
  useEffect(() => {
    checkBackendHealth();
  }, []);

  // Check if backend is alive
  async function checkBackendHealth() {
    try {
      const response = await fetch('http://localhost:8000/health');
      const data = await response.json();
      setBackendStatus(`✅ Backend is healthy! Service: ${data.service}`);
    } catch (error) {
      setBackendStatus('❌ Cannot reach backend. Make sure it\'s running on port 8000');
    }
  }

  // Load users from backend
  async function loadUsers() {
    setLoading(true);
    try {
      const response = await fetch('http://localhost:8000/users');
      const data = await response.json();
      setUsers(data);
    } catch (error) {
      console.error('Failed to load users:', error);
    } finally {
      setLoading(false);
    }
  }

  return (
    <div className="App">
      <h1> Microservices Platform</h1>

      <div className="status-card">
        <h2>Backend Status</h2>
        <p>{backendStatus}</p>
      </div>

      <div className="status-card">
        <h2> Users List</h2>
        <button onClick={loadUsers} disabled={loading}>
          {loading ? 'Loading...' : 'Load Users'}
        </button>

        <div className="users-list">
          {users.map(user => (
            <div key={user.id} className="user-item">
              <strong>{user.name}</strong>
              <br />
               {user.email}
            </div>
          ))}
        </div>
      </div>
    </div>
  );
}

export default App;

The Major Problem: CORS

I ran both servers:

Backend on port 8000 (npm run dev)
Frontend on port 3000 (npm start)

But my React app showed: ❌ Cannot reach backend

The browser console showed this error:

Access to fetch at 'http://localhost:8000/health' from origin 'http://localhost:3000' 
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present

What is CORS? (Simple Explanation)

Term	Meaning
CORS	Cross-Origin Resource Sharing
Origin	The domain + port where your app lives (http://localhost:3000)
The Problem	Browsers block requests from one origin to another by default (security)
The Fix	Tell the backend "It's OK to accept requests from React"

Analogy:

React = A person at door 3000
Backend = A person at door 8000
Browser = Security guard
Without CORS = Guard says "You can't talk to each other, different doors!"
With CORS = Guard says "Oh, it's allowed. Go ahead!"

Fixing CORS (Step by Step)

Step 1: Install the CORS package

cd backend
npm install cors

Step 2: Add CORS to server.js

const express = require('express');
const cors = require('cors');  // ← ADD THIS

const app = express();
app.use(cors());  // ← ADD THIS

Step 3: Restart both servers

Backend: Ctrl+C then npm run dev
Frontend: Ctrl+C then npm start

Step 4: Hard refresh browser

Ctrl + Shift + R

The Moment It Worked

After fixing CORS, my browser showed:

Backend Status: ✅ Backend is healthy! Service: backend-api

Clicking "Load Users" displayed:

SUCCESS! My frontend and backend were finally talking!

Key Learnings from Day 3

Technical Concepts

Concept	What I Learned
React State	`useState` creates memory for your component. When state changes, UI updates automatically
useEffect	Runs code automatically when component loads (great for fetching initial data)
fetch API	Browser's built-in way to make HTTP requests to APIs
CORS	Browser security that blocks cross-origin requests unless backend allows it
Ports	React uses 3000, backend uses 8000 — different ports = different origins

Problem-Solving Skills

Reading error messages: The CORS error looked scary, but it told me exactly what was wrong
Using browser Console: F12 → Console tab shows all errors
Testing with curl: curl http://localhost:8000/health proved backend was working (curl ignores CORS)
Systematic debugging: Backend works? Yes. Frontend works? Yes. Connection? CORS issue.

Mistakes I Made (And Fixed)

Mistake	Consequence	Fix
Deleted files without updating imports	React compilation error	Removed import lines from index.js
Didn't install CORS package	CORS still blocked	`npm install cors`
Forgot to restart backend	Changes didn't take effect	`Ctrl+C` then `npm run dev`
Didn't hard refresh browser	Saw old cached page	`Ctrl+Shift+R`

Tips for Anyone Building Their First React + API App

Test backend with curl first — If curl works but React doesn't, it's CORS
Always restart servers after changes — They don't auto-reload config
Use browser Console — It's your best friend for debugging
Hard refresh (Ctrl+Shift+R) — Avoid seeing cached old versions
Keep both terminals visible — One for backend, one for frontend

Resources

Let's Connect!

Have you struggled with CORS before? Building your first full-stack app? I'd love to hear about your journey!

Drop a comment or connect on LinkedIn. Let's learn together!

This is Day 3 of my 30-Day Cloud & DevOps Challenge. Follow along as I build a complete microservices platform from scratch!

30-Day Cloud & DevOps Challenge: Day 2 — Building My First Backend API

Michelle — Wed, 01 Apr 2026 13:10:35 +0000

The journey continues! After setting up my project structure on Day 1, today was all about building the heart of my microservices platform: the backend API.

If you missed Day 1, you can catch up here: [https://dev.to/michellewanjiru/day-1-of-my-30-day-cloud-devops-challenge-project-setup-2a5a?trk=public_post_comment-text]

What I Set Out to Do Today

Build a working REST API that can:

Respond to HTTP requests
Return JSON data
Serve as the foundation for my microservices platform

Simple, right? Well... let me share how it actually went.

The Tech Stack I Chose

I decided to go with Node.js + Express for my backend because:

JavaScript is everywhere (frontend, backend, even DevOps tools)
Express is lightweight and beginner-friendly
I already had Node.js installed on my Ubuntu system

Step-by-Step: What I Actually Did

1. Initial Setup

cd backend
npm init -y  # Creates package.json
npm install express  # Web framework
npm install --save-dev nodemon  # Auto-restarts server on changes

What I learned: package.json is like a shopping list for your project. Every tool you add gets listed there, making it easy to share your project with others.

2. Writing My First Server

I created server.js with three endpoints:

const express = require('express');
const app = express();
const PORT = 8000;

// Root endpoint
app.get('/', (req, res) => {
    res.json({ message: 'Welcome to the Microservices Platform API', status: 'running' });
});

// Health check endpoint
app.get('/health', (req, res) => {
    res.json({ status: 'healthy', service: 'backend-api', timestamp: new Date().toISOString() });
});

// Users endpoint (mock data for now)
app.get('/users', (req, res) => {
    res.json([
        { id: 1, name: 'Alice', email: 'alice@example.com' },
        { id: 2, name: 'Bob', email: 'bob@example.com' },
        { id: 3, name: 'Charlie', email: 'charlie@example.com' }
    ]);
});

app.listen(PORT, () => {
    console.log(` Server running on http://localhost:${PORT}`);
});

Understanding each part:

app.get() defines what happens when someone visits a URL
(req, res) => {} is a function that handles the request and sends a response
res.json() sends data back as JSON (the language of APIs)

3. The Challenge That Almost Stopped Me

I tried running my server with:

npm run dev

And got this error:

npm error Missing script: "dev"

My reaction: 😅 Wait, what? I thought I had this!

How I diagnosed it:

npm run  # Shows all available scripts

Only test was showing. I had completely forgotten to add the "dev" script to my package.json!

The fix: I opened package.json and added:

"scripts": {
    "start": "node server.js",
    "dev": "nodemon server.js"
}

Lesson learned: Never assume your configuration is correct. Always verify with simple commands.

4. The Moment It Finally Worked

After fixing the script, I ran:

npm run dev

And saw:

 Server running on http://localhost:8000

Then in another terminal:

curl http://localhost:8000/

Response:

{"message":"Welcome to the Microservices Platform API","status":"running"}

I literally cheered in my chair.🎉 My first API was alive!

Testing All Endpoints

Here's what each endpoint returned:

Endpoint	Response
`GET /`	Welcome message
`GET /health`	Service status with timestamp
`GET /users`	List of 3 mock users

All working perfectly!

Key Learnings from Day 2

Technical Concepts I Gained:

HTTP Methods: GET is how you retrieve data from a server
JSON: The universal language of APIs — both request and response
Ports: Think of them like doors — 8000 is the door my API listens on
Endpoints: Specific URLs that do specific things (/health, /users)
Package.json scripts: Custom commands to automate repetitive tasks

Problem-Solving Skills:

Diagnosing errors: npm run helped me see what was actually available
Reading error messages: "Missing script" told me exactly what was wrong
Step-by-step verification: Test each piece before assuming everything works

Mindset Shifts:

Done is better than perfect: My first API doesn't have a database yet, and that's okay
Celebrate small wins: Getting that first curl response was genuinely exciting
Embrace mistakes: The missing script error taught me more than if everything worked perfectly

Tips for Anyone Starting Their Own API

Start simple. My API only does 3 things right now — that's enough!
Test as you go. Don't write 100 lines of code before testing. Test after each endpoint.
Use curl or browser. It's satisfying to see your API respond in real-time.
Save your package.json changes. I almost forgot this one!
Keep notes. Document what you learn, especially the mistakes.

A Quick Thank You

To everyone following along and the community helping me debug, your support means everything. Special shoutout to those who reminded me to check my package.json scripts!

What's Next (Day 3)

Tomorrow, I'm building a frontend that will:

Fetch data from my API
Display the list of users
Show the health status

It's going to be the first time my frontend and backend talk to each other!

Links & Resources

GitHub Repository: Production-Ready-Microservices-Platform
Express Documentation: expressjs.com
Nodemon: nodemon.io

Let's Connect!

Are you also learning backend development? Building your first API? I'd love to hear about your journey!

Drop a comment below or connect with me on LinkedIn at https://www.linkedin.com/in/michelle-wanjiru-420877275/?lipi=urn%3Ali%3Apage%3Ad_flagship3_detail_base%3BHw%2F74ryNQ7CjXqDkL3k7eQ%3D%3D. Let's learn together!

This is Day 2 of my 30-Day Cloud & DevOps Challenge. Follow along as I build a complete microservices platform from scratch!

Forem: Michelle

The Lives Behind the Flowers

The Quiet Cost of Motherhood

30-Day Cloud & DevOps Challenge: Day 12 — Terraform: Infrastructure as Code

First: What is Infrastructure as Code (IaC)?

The Manual Way (ClickOps)

The IaC Way (Terraform)

What is Terraform?

The Analogy

Which Providers Does Terraform Support?

Terraform Core Commands

The Workflow

Command 1: terraform init

Command 2: terraform plan

Command 3: terraform apply

Command 4: terraform destroy

Your First Terraform Project

Step 1: Install Terraform

Step 2: Create a Project Folder

Step 3: Create main.tf

Step 4: Add the Terraform Code

Step 5: Initialize Terraform

Step 6: Preview the Plan

Step 7: Apply the Configuration

Step 8: Verify the File Was Created

Step 9: Check Terraform State

Step 10: Clean Up (Optional)

Understanding Terraform Files

The State File is IMPORTANT

Terraform Commands Cheat Sheet

Terraform vs Other DevOps Tools

Key Takeaways

What's Next

Resources

Let's Connect!

30-Day Cloud & DevOps Challenge: Day 11 — Pushing Docker Images to Registry

First: What is a Docker Registry?

The Analogy

Why Push to a Registry?

Step 1: Create Docker Hub Account

Step 2: Add Docker Hub Credentials to Jenkins

Why Credentials?

Adding Credentials

Step 3: Update Jenkinsfile with Push Stage

The Complete Jenkinsfile with Push

Understanding New Parts

Step 4: Replace the Username

Understanding Credential Security

What NOT to do (Hardcoding passwords)

What TO do (Using Jenkins credentials)

Step 5: Commit and Push

Step 6: Run the Pipeline

Console Output

Step 7: Verify on Docker Hub

Check Repository Details

Step 8: Test Pulling from Any Computer

Before vs After

Complete CI/CD Pipeline Now

Key Takeaways

Resources

Let's Connect!

30-Day Cloud & DevOps Challenge: Day 10 — Docker in CI

First: Why Docker in CI?

Before Docker in CI

After Docker in CI

Step 1: Giving Jenkins Docker Access

The Problem

The Solution: Docker Socket Mounting

After Mounting

Step 2: Installing Docker in Jenkins Container

Step 3: Adding Docker Build to Pipeline

The Docker Build Stage

What Each Command Does

The Complete Jenkinsfile (Docker Stage Added)

Step 4: Understanding Docker Build in CI

What Happens During Docker Build

Image Sizes

Step 5: Testing Docker Build Locally

Step 6: Running the Pipeline

Trigger the Build

Command 1: `terraform init`

Command 2: `terraform plan`

Command 3: `terraform apply`

Command 4: `terraform destroy`