DEV Community: BAKRE JAMIU

I’m Learning Kubernetes—Here Are the Mistakes I Made So You Don’t Have To

BAKRE JAMIU — Sun, 30 Aug 2026 01:26:51 +0000

If you have ever stared at a Pod stuck in ContainerCreating and wondered what you did wrong, this one is for you. These are the mistakes I made while learning Kubernetes — and the lessons that finally clicked.

Introduction

There is a version of Kubernetes that exists in beginner tutorials, and there is the version you meet when you actually start using it. In the tutorial version, everything looks clean: create a Pod, expose a Service, scale replicas, move on. In real life, there are drivers that are missing, Docker permissions that block you, images that take time to pull, Services that do not exist yet, namespaces that quietly change what you are looking at, and Pods that disappear only to come back because Kubernetes is doing exactly what it was designed to do.

This is not a story about becoming a Kubernetes expert overnight. It is a story about getting my hands dirty, making honest mistakes, troubleshooting them one by one, and gradually understanding why organizations trust Kubernetes to run production workloads.

1. My starting point

I started by learning the foundations: what Kubernetes is, why companies use it, what a cluster is, the difference between the control plane and worker nodes, what nodes and Pods are, how containers differ from Pods, and how Docker and Kubernetes relate to each other. I also worked with kubectl, Minikube, namespaces, Deployments, ReplicaSets, Services, scaling, Helm, and later Kubeshark.

On paper, that list looked manageable. In practice, every concept became clearer only when it broke in front of me.

2. What I thought Kubernetes was (and what I misunderstood)

At the beginning, I thought Kubernetes was basically Docker at a bigger scale. That assumption did not survive long. The more I used it, the more I saw that Kubernetes is not mostly about starting containers. It is about describing a desired state and letting the cluster keep moving toward that state.

A few of my early wrong assumptions:

Minikube would just start, without needing a supported driver or runtime such as Docker.
A Pod in ContainerCreating meant something was definitely broken.
Deleting a Pod meant I had removed the application.
I could use minikube service before creating any Service.
Every failure during Helm or Kubeshark setup had to be a Kubernetes problem.

3. Setup: Minikube, Docker, and permissions

One of my first real lessons came from setup. I tried minikube start before having a supported driver installed. That reminded me: Kubernetes on a laptop still depends on what is underneath it. Minikube is not magic. It needs a runtime/driver to create and run the local cluster.

Then came Docker permission issues, which led me to learn about the Docker group and why a user gets blocked from Docker commands until the right permissions are in place.

Early Cloud/DevOps lesson: when something “Kubernetes-related” fails, it is sometimes the environment around Kubernetes that needs attention first.

4. My first Pod and the patience it taught me

I created an NGINX Pod and saw it sit in ContainerCreating. My first instinct was that something was wrong. Eventually it became Running. That moment sounded small, but it mattered. Container images may need to be downloaded, Internet access matters, and a Pod not being ready immediately does not automatically mean failure.

The lesson: instead of treating every delay as an error, I started asking, “What is Kubernetes doing right now?”

5. Deployments, ReplicaSets, and reconciliation

The biggest “click” moment came when I deleted a Pod and watched Kubernetes recreate it. I had deleted a Pod that was managed by a Deployment. The Deployment still wanted the desired number of replicas, so the cluster created another Pod to bring the state back in line.

That single experience taught me more than several pages of explanation could. It made Deployments, ReplicaSets, and reconciliation feel real.

6. Services — and how I learned what `SVC_NOT_FOUND` really means

Services answered a question I kept running into: how do I reliably reach an application when Pods are temporary? A Pod can be recreated and get a different IP. A Service gives that changing set of Pods a stable endpoint.

I learned this when I ran:

minikube service nginx -n development

before I had created any Service. The response was SVC_NOT_FOUND. My assumption was the bug, not Minikube. The fix was to create the Service explicitly:

kubectl expose pod nginx --type=NodePort --port=80

7. Scaling

Scaling replicas sounds simple when you read it, but it becomes more meaningful when you watch it happen. Increasing replica count means the Deployment updates the ReplicaSet, and the ReplicaSet creates more Pods until the cluster reaches the new desired count. That is when Kubernetes starts feeling less like manual container management and more like orchestration.

8. Troubleshooting 🛠️

The most valuable part of this journey has been troubleshooting. Good troubleshooting is not random trial and error. It is a sequence:

Read the error.
Question the assumption behind the step.
Inspect the cluster state.
Compare expected behavior with actual behavior.
Isolate the real cause.

9. Helm & Kubeshark — and the layer-aware lesson

Helm clicked for me as a package manager for Kubernetes. Then came Kubeshark. I ran into repository connectivity problems and almost blamed Kubernetes immediately. The more useful question was: is this a cluster problem, or is the repository itself unreachable from my environment?

curl -I https://helm.kubeshark.com/index.yaml
curl -I https://google.com
curl -I https://github.com
curl -I https://raw.githubusercontent.com
That comparison mattered. It helped me distinguish between “my Kubernetes or Helm setup is broken” and “this particular external repository cannot be reached.” Systems fail in layers. Good troubleshooting means identifying which layer is actually failing.

10. Mistakes I made — and what each one taught me

MISTAKE	LESSON
Starting Minikube without a supported driver	Kubernetes tools still depend on the host environment. Drivers, runtimes, and permissions matter.
Treating `ContainerCreating` as immediate failure	Sometimes the image is still downloading. Read the state in context and inspect events before panicking.
Trying `minikube service` before creating a Service	A Pod is not automatically a Service. Reachability needs to be defined explicitly.
Deleting a Pod and expecting the app to be gone	Deployments preserve the desired replica count. Delete the Deployment if you want the managed Pods to stop returning.
Working in the wrong namespace	Always confirm the namespace context. Resources can be healthy while you are looking in the wrong place.
Assuming every Helm/Kubeshark issue was a Kubernetes issue	Sometimes the real problem is repository/network access outside the cluster. Verify the failing layer.

11. Commands that actually helped me

minikube start
kubectl get pods -A
kubectl get deployments -A
kubectl get services -A
kubectl describe pod <pod-name>
kubectl logs <pod-name>
kubectl get deployment nginx-deployment -o yaml
kubectl expose pod nginx --type=NodePort --port=80
minikube service <service-name> --url
curl -I https://helm.kubeshark.com/index.yaml

12. Lessons for other beginners

Do not rush past the basic architecture. Knowing the relationship between Deployments, ReplicaSets, Pods, and Services saves time later.
Read the exact error message before trying random commands.
Check namespaces early. It is one of the easiest ways to eliminate confusion.
If a Pod is managed by a Deployment, deleting the Pod is not the same as deleting the application.
When troubleshooting, identify the failing layer: local machine, Docker runtime, Minikube, Kubernetes resource, network access, or external repository.

What I now understand

Kubernetes is not about micromanaging containers. It is about declaring state, letting the cluster maintain it, and using higher-level abstractions to make applications resilient and reachable.

What I still need to learn

There is still a lot ahead: Ingress, ConfigMaps, Secrets, persistent storage, observability, production-grade networking, security, and more advanced debugging patterns. The basics are no longer abstract terms — they now connect to things I have actually seen fail and recover.

Next stop: Kubernetes Ingress 🚦

Ingress is the natural next topic because it ties everything together. Pods run the application, Services give a stable way to reach those Pods inside the cluster, and Ingress sits above that to route external HTTP/HTTPS traffic to the right Service. If Services help internal reachability, Ingress helps organize external access more cleanly.

Conclusion

Every time Minikube refused to start, every time a Pod sat in ContainerCreating, every time a Service did not exist yet, every time a namespace caused confusion, every time a Pod came back after I deleted it — Kubernetes was teaching me something useful.

I thought learning Kubernetes would mostly be about commands. I was wrong. It has been more about systems thinking, careful troubleshooting, and learning how to ask better questions.

Next stop: Kubernetes Ingress — understanding how external traffic reaches Services, and through them, the Pods behind the application.

📘 Ansible Learning Journey - From Manual SSH to Automation Thinking

BAKRE JAMIU — Wed, 14 Jan 2026 15:07:46 +0000

CloudWithHorla | Cloud & DevOps Engineer (Learning in Progress 🚀)

Automation looks simple from the outside — until you try to build it yourself.

Recently, I worked on an Ansible hands-on project as part of my continuous learning in Cloud and DevOps engineering. The goal was simple on paper:

set up a controller node and manage multiple target nodes using Ansible.

In reality, the journey taught me far more than just commands.

🏗️ Project Overview

I built a small but realistic infrastructure on AWS consisting of:

* 1 EC2 Controller (Ansible Master)
* 3 EC2 Target Nodes
* Ubuntu-based servers
* SSH key-based authentication
* Ansible ad-hoc commands and playbooks

This setup mirrors what actually happens in real-world environments — not just labs.

🔧 What I Implemented (Step-by-Step)

Provisioned EC2 instances

1 controller
3 managed nodes

Installed core dependencies

Python3
Pip
Ansible on the controller

Created Ansible configuration

Custom ansible.cfg
Inventory file defining all target nodes

SSH Key-Based Authentication

Generated SSH key pair on the controller
Injected the controller’s public key into each node’s authorized_keys

Learned the difference between:

 >>  # append (safe)
 >   # overwrite (dangerous)

You are adding a new line of Public Key which is safe.

echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCppACFB47TRDuT8YXSSxL+T9jxirz0yC04avxRB8nAOnVcz5xXpyT0mhYbhcLCbI2D4pcWkSb1NqGyUwF3OeHGtur+0MkDq7/9jhPG0amrFbk+RBQM+WZ7UaEzopiK7ZB8MUKwtMGVhR9wgtIiSK6+fgmzNaCpfj13B9aH7iiMRn4sHCwr81zCAskb79DnhCmB8Y7NU2VAqlMnW5NIFEujv3aixmPSZbIKomNotGT2ljtOV5EoMuFFqq3DqA/kZVM1WJjBMEAlWtdQTn2UM5dTAi5BNvPMYJcdzEfc4fXvkp11rFYLiEc9ZUFkYi6APg1Ju5bPgh0Yp+9YOhlCMEuEPlAdxUIHE4Ih3HoNhLOB622c+a6lNK5SF7Y76gB5cdK8Rar/tRQqF6kxqy852SLfZbLnXkfIOuktF4XGemMMt13F7yw1k980vwcwCgfAK4zOZ2hmaDypmG0Rd/lhsIpC+4i6s4T8a+AB3BSKt9KH/Dn9cxUM0BVgxgM1hWyk7Hs= ubuntu@ip-10-0-8-231" >> .ssh/authorized_keys

Caveat: Best practise

You are removing an existing "Public Key" which is not safe.

echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCppACFB47TRDuT8YXSSxL+T9jxirz0yC04avxRB8nAOnVcz5xXpyT0mhYbhcLCbI2D4pcWkSb1NqGyUwF3OeHGtur+0MkDq7/9jhPG0amrFbk+RBQM+WZ7UaEzopiK7ZB8MUKwtMGVhR9wgtIiSK6+fgmzNaCpfj13B9aH7iiMRn4sHCwr81zCAskb79DnhCmB8Y7NU2VAqlMnW5NIFEujv3aixmPSZbIKomNotGT2ljtOV5EoMuFFqq3DqA/kZVM1WJjBMEAlWtdQTn2UM5dTAi5BNvPMYJcdzEfc4fXvkp11rFYLiEc9ZUFkYi6APg1Ju5bPgh0Yp+9YOhlCMEuEPlAdxUIHE4Ih3HoNhLOB622c+a6lNK5SF7Y76gB5cdK8Rar/tRQqF6kxqy852SLfZbLnXkfIOuktF4XGemMMt13F7yw1k980vwcwCgfAK4zOZ2hmaDypmG0Rd/lhsIpC+4i6s4T8a+AB3BSKt9KH/Dn9cxUM0BVgxgM1hWyk7Hs= ubuntu@ip-10-0-8-231" > .ssh/authorized_keys

Caveat: Not a best practise

Sample

Privilege Escalation

Used become: true for system-level tasks
Ensured sudo access without breaking security

Ansible Ad-Hoc Commands

   ansible -m apt -a "name=git state=present" all -b

Ansible Playbook Execution

Installed and removed packages
Copied files to remote nodes
Managed services across multiple machines in parallel

📄 Sample Playbook used in my project:

---
- name: Installing nginx playbook
  hosts: all
  become: true
  tasks:
    - name: First Task
      apt:
        name: nginx
        state: absent

    - name: Second Task
      apt:
        name: nginx
        state: present

    - name: Copy file with owner and permissions
      ansible.builtin.copy:
        src: ./index.html
        dest: /var/www/html/index.html
        owner: root
        group: root
        mode: '0777'

    - name: Third Task
      apt:
        name: apache2
        state: present

⚠️ Challenges I Faced (and What I Learned)

1️⃣ “Permission denied (publickey)”

I initially thought Ansible could manage nodes without SSH access.
Through research and troubleshooting, I learned a critical truth:

Ansible always uses SSH. There is no automation without an initial trust path.

Key-based authentication must be established at least once — either at instance creation or manually.

2️⃣ PasswordAuthentication Confusion

I tried disabling password authentication before confirming key-based access.

That was a big lesson:

❌ Disabling PasswordAuthentication does NOT give access
✅ It only removes password login after SSH keys already work

Correct order matters:

Establish SSH key access
Test connectivity
Then disable password authentication

3️⃣ APT Lock Errors (`unattended-upgrades`)

One node failed while others succeeded.

Cause:

Ubuntu auto-updates were running in the background

Lesson:

Infrastructure is not deterministic — nodes behave independently.

Solution:

Wait and retry
Or design playbooks with retries and checks

Screenshot Output

This is when I ping of the node

This is when I ping all the node

This is the first page output of my Playbook

This is the second page output of my Playbook

Node 01

Node 02

Node 03

4️⃣ Wrong Package Names

I attempted to install apache instead of apache2.

Lesson:

Automation does exactly what you tell it — not what you mean.

Small naming errors can break entire workflows.

🧠 Key Takeaways I Want Others to Learn

🔑 SSH is foundational — Ansible cannot bypass it
🔁 Automation is about idempotency and retries
🧪 Always test with --syntax-check and ping yourself (localhost) for test.

🔐 Never overwrite authorized_keys
🛠️ Real learning happens when things break

🌱 Growth Mindset

This project reinforced my core belief:

Never stop learning.

Every error I faced forced me to:

Research deeper
Read documentation
Understand why things work — not just how

I’m still learning.
I’m still breaking things.
And I’m still getting better — one tool at a time.

📌 Final Thought

Automation isn’t about avoiding work —
it’s about doing the work once, correctly and at scale.

CloudWithHorla ☁️
Cloud & DevOps Engineer | Always Learning

My Ongoing Cloud Migration Journey 🚀

BAKRE JAMIU — Mon, 10 Nov 2025 16:22:16 +0000

Over the past few months, I’ve been working on one of the most exciting and challenging cloud migration projects of my career, a large-scale transformation initiative between xyz (a global technology consulting firm) and abc (a major telecommunications company).

The goal of this project is simple but powerful: to move dozens of critical enterprise applications from on-premises data centers into a secure, scalable, and automated AWS environment without disrupting existing business operations. This is part of a broader modernization program that will allow abc to run its workloads faster, more securely, and more efficiently in the cloud.

What We’re Doing

The migration involves a mix of rehosting, redeploying, and refactoring applications using AWS native tools, Terraform for Infrastructure as Code (IaC), and automated CI/CD pipelines.

Our scope includes:

Designing and deploying AWS environments for multiple business units.
Setting up VPCs, subnets, IAM roles, security groups, load balancers, and monitoring tools.
Implementing cross-account role assumption for secure access and governance.
Coordinating closely with both the cloud engineering and application teams to ensure smooth transitions.

As of now, we’re working through a pipeline of over 30 applications scheduled for migration to AWS. Several have already been successfully redeployed and tested in non-production and production environments.

My Role

As a Cloud Engineer on this project, my role cuts across technical execution, documentation, and coordination. I’ve been directly involved in:

Designing AWS architectures for multiple applications; defining network layout, IAM roles, and access controls.
Collaborating on Terraform automation, including maintaining GitHub repositories and building modular scripts for consistent infrastructure deployment.
Managing environment readiness, which includes server provisioning, IAM access configuration, and validating connectivity between on-prem databases and cloud servers.
Supporting MGN setup, ensuring source servers are correctly configured for migration replication.
Contributing to migration design documents, including the logical architecture, deployment models, dependencies, and database connections.
Coordinating with the application and security teams to manage firewall requests, DNS cutovers, and access provisioning.

What I’ve Achieved So Far

Successfully supported the AWS environment setup for multiple application migrations.
Created and refined design documentation that clearly outlines migration strategy, deployment processes, and technical architecture.
Validated IAM roles and cross-account access, ensuring secure provisioning in multi-account AWS setups.
Helped establish a Terraform-based deployment workflow, integrating version control and infrastructure automation.
Worked closely with the project leads to align AWS provisioning with organizational compliance standards.
Gained practical experience in AWS MGN (Migration Hub), Terraform automation, and enterprise migration governance.

Where We Are Now

Our team has completed the foundation setup AWS accounts, networking, IAM, and automation frameworks are now in place. We’re currently focused on:

Accelerating AWS application deployments through Terraform automation.
Coordinating with database and app owners for production cutovers.
Streamlining server provisioning and post-deployment checks.
Ensuring security compliance and monitoring with AWS CloudWatch and Config.

What Makes This Experience Stand Out

This project is more than just moving workloads to AWS; it’s a complete cloud enablement initiative. I’ve learned the value of collaboration between cloud engineers, app owners, database administrators, and project managers, all working toward a shared goal of modernization.

Every day comes with new learning: understanding enterprise migration frameworks, managing IAM at scale, troubleshooting deployment issues, and optimizing Terraform code for real-world production environments.

My Reflection

This experience has strengthened my skills not only as a Cloud Engineer but as a problem solver and collaborator. From designing secure AWS architectures to supporting production rollouts, I’ve seen firsthand how cloud migration works at scale the challenges, the coordination, and the satisfaction that comes when an application successfully goes live in the cloud.

We’re still moving forward, with many more applications to migrate in the coming weeks. And as we continue to build, automate, and refine, I’m proud to be part of a team that’s shaping the future of cloud transformation for one of the biggest enterprises in the industry.

Building a Scalable AWS E-Learning Platform for Government Use

BAKRE JAMIU — Sat, 18 Oct 2025 13:37:45 +0000

🌍 Project Overview

As part of a Architect Engineer assessment for XYZ Company, I was tasked with designing a secure, scalable, and reliable AWS-based architecture for a government-backed e-learning platform.

The goal was to create a system capable of serving up to 200 million users across multiple regions — supporting video streaming, quizzes, progress tracking, and a multilingual AI chatbot.

🧱 Architecture Goal

Design a 3-tier AWS architecture that ensures:

Scalability for millions of users
Security and compliance with government data standards
High availability across multiple Availability Zones
Cost efficiency using serverless and auto-scaling resources

⚙️ Core AWS Services Used

1️⃣ User Authentication & Access Management

Amazon Cognito for secure user authentication
Integrated with government identity providers via SAML/OAuth
Multi-Factor Authentication (MFA) enabled for all users
Role-based access for students, instructors, and administrators

2️⃣ Video Delivery and Streaming

Amazon S3 stores all course materials and videos
AWS Elemental MediaConvert handles video transcoding
Amazon CloudFront (CDN) delivers content with adaptive bitrate streaming for smooth playback across all regions
Content is secured using signed URLs and S3 encryption

3️⃣ Multilingual AI Chatbot

Amazon Lex powers the conversational interface
Amazon Translate automatically detects and translates languages
Chatbot supports English, Yoruba, Hausa, Igbo, and Pidgin
Personalized responses based on user progress data stored in Aurora

4️⃣ Monitoring & Compliance

AWS CloudTrail logs all API activities for audit purposes
Amazon CloudWatch monitors performance metrics and triggers alarms
AWS Config ensures resource compliance with security policies

5️⃣ Quizzes & Progress Tracking

Real-time quiz scoring and feedback using AWS Lambda + API Gateway
Data stored in Amazon Aurora (PostgreSQL) for structured consistency
DynamoDB used for low-latency user progress tracking

6️⃣ Data Storage & Analytics

Data Type	AWS Service
Videos & Materials	Amazon S3
User & Quiz Data	Amazon Aurora
Progress Tracking	Amazon DynamoDB
Analytics & Reporting	AWS Glue + Redshift (future phase)

Here is the Native Design below:

🏗️ 3-Tier Architecture Design

Tier 1: Web Layer

Deployed on Auto-Scaled EC2 instances behind an Application Load Balancer (ALB) in public subnets

Tier 2: Application Layer

Stateless compute services (EC2 or AWS Lambda) in private subnets

Tier 3: Database Layer

Aurora Cluster in private subnets, Multi-AZ enabled with read replicas

Additional Infrastructure:

VPC with 6 subnets (3 public, 3 private across 3 AZs)
NAT Gateway for private subnet outbound access
Security Groups + Network ACLs for layered protection
CloudFront CDN for global performance acceleration

💰 Cost Optimization Highlights

Aurora Serverless v2 for automatic scaling of database capacity
S3 Intelligent-Tiering for optimizing storage costs
Spot Instances for EC2 auto-scaling groups
AWS Budgets + Cost Explorer for continuous cost monitoring

🧠 Key Outcomes

Highly available, fault-tolerant, and secure architecture
Optimized for millions of concurrent users
Ready for NDPR/ISO compliance via CloudTrail and IAM governance
Inclusive learning through multilingual AI support

🧾 Deliverables

AWS Architecture Diagram
Statement of Work (SOW)
Presentation Slide Deck

🚀 Conclusion

This project demonstrates the power of cloud-native architecture on AWS in enabling education at scale — bringing inclusive, accessible, and secure learning to millions of users across regions.

It also highlights my practical experience as a Cloud Engineer in building enterprise-grade solutions that combine scalability, security, and innovation.

📬 Connect With Me

👤 Bakre Jamiu (CloudWithHorla)
AWS Cloud & DevOps Engineer
✉️ bakrejamiu@gmail.com

🚀 Optimizing Costs Without Downtime: My Hands-On Experience Downgrading AWS Lightsail; A Step-by-Step Journey

BAKRE JAMIU — Wed, 06 Aug 2025 15:46:27 +0000

Over 3 days, I planned, executed, and documented the entire process. Here’s how I successfully completed the downgrade while maintaining service availability.

Introduction

In cloud engineering, cost optimization without compromising performance is a skill every professional must master. Recently, I faced a real-world challenge: one of my projects running on AWS Lightsail required a downgrade to a smaller instance to reduce monthly costs. The catch? I had to ensure zero downtime and data integrity.

🛠 Project Objective

Task: Downgrade AWS Lightsail instance to a smaller plan.

Goal: Achieve cost savings while keeping the application online.

📌 Project Context

A client’s web application was running on an oversized AWS Lightsail instance. The workload was consistently under-utilizing CPU, memory, and storage resources, which meant unnecessary monthly costs. The client requested a downgrade to a smaller Lightsail instance without affecting uptime, performance, or security.

As a Cloud & DevOps Engineer, I took ownership of the entire migration and cost-optimization project, delivering results in 3 days.

🎯 Objectives

Downgrade AWS Lightsail to a smaller instance.
Ensure zero downtime during migration.
Maintain SSL, Nginx, and PM2 configurations for seamless performance.
Implement rollback and backup strategies to avoid risk.
Document the entire process for transparency and client knowledge.

📍 End-to-End Execution

Day 1: Assessment & Planning

Assessment & Planning
Reviewed resource utilization metrics (CPU, RAM, Disk) via Lightsail Monitoring and CloudWatch.

1. Resource Utilization Analysis

Logged into AWS Lightsail Dashboard.
Checked CPU, RAM, and Network metrics via built-in monitoring.
Cross-verified with CloudWatch metrics for accurate trend analysis.
Identified that the current instance size was over-provisioned (using ~30% capacity).

2. Downgrade Strategy Design

Determined the target instance size that could handle peak loads.
Outlined a rollback plan using snapshots.
Created a migration checklist covering:
- Application files
- Database
- Nginx configuration
- SSL certificates
- Environment variables

3. Backup Creation

Took a snapshot of the existing Lightsail instance for disaster recovery.
Exported database dump for redundancy using mysqldump.

🎯 What I achieved on Day 1:

Identified the current instance type and determined a smaller instance plan suitable for the workload.

Created a rollback plan in case of failure.

Backed up the existing instance snapshot for disaster recovery.

Day 2: Environment Setup & Migration

1. Provisioning the New Lightsail Instance

Launched a new Lightsail instance with the downgraded size.
Configured SSH keys for secure access.
Set up networking (firewall rules, static IP).

2. Application Environment Configuration

Installed required packages:

  sudo apt update && sudo apt upgrade -y
  sudo apt install nginx mysql-client nodejs npm -y
  sudo npm install -g pm2

Pulled application files from transferred via SCP.
Restored environment variables from .env file.

3. Database Migration

Created a new MySQL instance inside Lightsail (or reused existing).
Imported the database:

  mysql -u username -p database_name < backup.sql

4. Nginx & SSL Setup

Configured Nginx virtual host with HTTPS redirect.
Installed Let’s Encrypt SSL certificate with Certbot:

  sudo apt install certbot python3-certbot-nginx -y
  sudo certbot --nginx -d example.com -d www.example.com

Validated with nginx -t and reloaded.

5. Application Process Management

Started application with PM2:

  pm2 start app.js --name myapp
  pm2 save
  pm2 startup

Ensured auto-start on reboot.

🎯 What I achieved on Day 2 – Environment Preparation:

Provisioned a new Lightsail instance with the downgraded size.

Configured security groups, firewall rules, and SSH access.

Migrated application files and environment variables from the old server.

Installed and configured necessary dependencies (Nginx, Node.js, PM2, etc.).

Validated that all services ran as expected on the smaller instance.

Day 3: DNS Cutover & Validation

1. DNS Redirection

Updated Lightsail static IP for the new instance.

2. Testing & Monitoring

Verified that HTTPS was redirecting correctly.
Tested login/admin pages to ensure proper routing.
Confirmed API endpoints (devapi.flexdelivery24.com) were functional.
Monitored logs with:

  tail -f /var/log/nginx/access.log
  tail -f /var/log/nginx/error.log

Monitored CPU & RAM usage under live traffic for 24 hours.

3. Final Optimization

Cleaned up unused packages and logs.
Documented final server architecture and cost savings.
Shared final access and rollback documentation with the client.

🎯 What I achieved on Day 3 – Cutover & Optimization

Redirected DNS records to the new Lightsail instance.

Tested application endpoints, admin login pages, and SSL configuration.

Verified user sessions and ensured HTTPS redirection was functioning properly.

Monitored server health (CPU/RAM) under production traffic for stability.

Documented the final architecture and cost reduction achieved.

✅ Deliverables

New Lightsail downgraded instance in production.
Full rollback snapshot in case of failure.
SSL-secured environment with automated renewals.
Updated DNS configuration with zero downtime.
Detailed post-migration documentation.

📊 Results & Impact

Cost Reduction: ~40% lower monthly Lightsail bill.
Zero Downtime: Application stayed online throughout the migration.
Performance Stability: New instance running at ~65% capacity under peak load.
Client Satisfaction: A leaner, secure, and efficient environment.

🏆 Impact
This project reinforced my ability to balance cost optimization and reliability. With a careful step-by-step approach, I delivered results that aligned with business goals while maintaining system uptime.

💡 Lessons Learned

Always benchmark workloads before downsizing to prevent under-provisioning.
Snapshots and database dumps are critical for safe rollbacks.
DNS cutover timing is crucial—setting a low TTL can make transitions smoother.
Post-migration monitoring ensures the environment remains stable under real traffic.

🏆 Conclusion

This project demonstrates my ability to manage cloud cost optimization while balancing availability, security, and scalability. Over 3 days, I delivered a solution that not only reduced costs but also improved infrastructure efficiency.

🚀 How I Deployed a Python Flask App with Docker and Troubleshot My Way to Victory 🛠️🐍🐳

BAKRE JAMIU — Tue, 13 May 2025 18:52:59 +0000

Deploying a Python Flask app with Docker sounds straightforward… until it isn’t. 😅 Recently, I rolled up my sleeves to containerize and deploy a simple Flask app connected to PostgreSQL. While it seemed like a walk in the cloud, I ran into several walls—but breaking through them made the win even sweeter. Here’s how it all went down 👇

🏗️ Project Setup

I started with a basic Flask app that connects to a PostgreSQL database. My directory looked like this:

📁 python-docker-project/
├── Dockerfile
├── compose.yml
├── app.py
├── requirements.txt
└── README.md

My app.py had two routes:

/: returns a simple greeting
/db: connects to PostgreSQL and returns the DB version

The goal? Run this app in a Docker container and use Docker Compose to spin up both the app and a PostgreSQL service in one command.

🐳 Dockerfile Setup

I created a simple Dockerfile:

FROM python:3.11-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install -r requirements.txt

COPY . .

CMD ["python", "app.py"]

Looks good, right? 🤓 But here’s where the trouble started…

💥 The First Crash: Dependency Drama

When I ran:

docker compose -f compose.yml up --build

Boom 💣

ERROR: Could not find a version that satisfies the requirement click==8.2.0

Hmm. Turns out the click==8.2.0 version in requirements.txt requires Python >= 3.10, but I was using python:3.9-slim-buster as my base image.

🔧 Fix:

I upgraded the base image in my Dockerfile to:

FROM python:3.11-slim

Problem solved. ✅

🧊 The Second Freeze: Compose Conundrum

Feeling confident, I re-ran the build and... 💥 another error:

KeyError: 'ContainerConfig'

At this point, I’m like, “What even is ContainerConfig?” 😤

🕵️‍♂️ Root Cause:

I was using Docker Compose v1.29.2 (legacy), which doesn't play nice with newer images or Docker Engine versions.

🔧 Fix:

I upgraded to Docker Compose v2 using:

mkdir -p ~/.docker/cli-plugins/
curl -SL https://github.com/docker/compose/releases/latest/download/docker-compose-linux-x86_64 \
  -o ~/.docker/cli-plugins/docker-compose
chmod +x ~/.docker/cli-plugins/docker-compose

And voilà! docker compose up started working without the dreaded ContainerConfig error. 🎉

🟢 Final Compose File

Here’s a sneak peek at my compose.yml:

version: '3.8'

services:
  app:
    build: .
    ports:
      - "5000:5000"
    environment:
      - DATABASE_URL=postgresql://postgres:mysecretpassword@db:5432/mydatabase
    depends_on:
      - db

  db:
    image: postgres:13
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: mysecretpassword
      POSTGRES_DB: mydatabase
    volumes:
      - db-data:/var/lib/postgresql/data

volumes:
  db-data:

🎯 The Sweet Success

After all the bumps, running the final command:

docker compose up --build

…worked flawlessly. I visited:

http://localhost:5000/ → Hello from Flask ✅

http://localhost:5000/db → PostgreSQL version info ✅

💡 Key Takeaways

🐍 Match your Python version with compatible libraries (watch those requirements.txt entries)
🐳 Use Docker Compose v2 for smoother experience with modern images
🧠 Don’t panic when you hit errors—each one teaches you something
🔧 Always check if errors are due to version mismatches, especially with Docker

🏁 Final Words

This small project taught me that deployment isn't always plug-and-play—but that's what makes it rewarding. If you're running into Docker or Python-related issues, you're not alone. Just breathe, dig deep, and Google like a ninja. 💻

Want more stories like this or need help with your own cloud projects? Follow me at CloudWithHorla ☁️💪

🛠️ From Concept to Container: My Journey Deploying MongoDB & Mongo-Express with Docker (No Docker Compose!)

BAKRE JAMIU — Mon, 05 May 2025 19:50:58 +0000

🔥 Real-World Skills, Real Results — A Cloud Engineer’s Perspective

In cloud engineering, we often celebrate smooth deployments—but the real growth lies in the challenges we troubleshoot along the way. This project is a perfect example of that. I set out to containerize and connect a backend database (MongoDB) and a frontend admin interface (Mongo Express) using Docker. The twist? I chose not to use Docker Compose. I wanted to master every part of the networking, environment configuration, and volume persistence manually—because that’s how pros sharpen their edge.

Let’s dive into the steps I followed, the problems I solved, and how I ensured my data persisted—even after destroying and recreating my containers.

📌 Step 1: Create a Docker Network

First, I created a custom bridge network to allow seamless communication between my containers.

docker network create jamiu-network

🧱 Step 2: Deploy the MongoDB Container

Here, I launched MongoDB with a mounted volume to persist data. This step ensures that even if the container is deleted, the data will remain intact.

docker run -d \
  --name mongo-database \
  --network jamiu-network \
  -p 27017:27017 \
  -v mongo-data:/data/db \
  -e MONGO_INITDB_ROOT_USERNAME=mongoadmin \
  -e MONGO_INITDB_ROOT_PASSWORD=secret \
  mongo

Key Takeaway:
Notice the -v mongo-data:/data/db line—that’s the magic of Docker volumes doing the heavy lifting for persistence.

🌐 Step 3: Deploy Mongo Express

Now, I deployed Mongo Express and connected it to my MongoDB container through the custom network. This acts as a simple frontend for interacting with my database.

docker run -it -d \
  --network jamiu-network \
  --name mongo-express \
  -p 8085:8081 \
  -e ME_CONFIG_OPTIONS_EDITORTHEME="ambiance" \
  -e ME_CONFIG_MONGODB_SERVER="mongo-database" \
  -e ME_CONFIG_MONGODB_ADMINUSERNAME="mongoadmin" \
  -e ME_CONFIG_MONGODB_ADMINPASSWORD="secret" \
  -e ME_CONFIG_BASICAUTH_USERNAME="user" \
  -e ME_CONFIG_BASICAUTH_PASSWORD="fairly long password" \
  mongo-express

Access Mongo Express at:
🌍 http://localhost:8085

The view for Mongo-express

⚔️ Real Talk: Troubleshooting Was My Superpower

Was it smooth sailing? Absolutely not.

Mongo Express initially failed to connect. The logs screamed:
Name does not resolve and mongo:27017 Invalid argument.

The issue? I had incorrectly set the MongoDB hostname. Instead of using "mongo-database"—which is the container name and acts as the hostname inside the Docker network—I had used "mongo".

Once I corrected the ME_CONFIG_MONGODB_SERVER value to match the actual MongoDB container name, everything clicked.

🧠 Lesson: Troubleshooting isn't a skill—it's a superpower. It’s what separates a "deployer" from a real Cloud Engineer.

🧪 Step 4: Test Volume Persistence Like a Pro

After confirming the Mongo Express interface was working, I connected to the Mongo shell inside the container and added some test data:

docker exec -it mongo-database mongosh -u mongoadmin -p secret

Inside Mongo shell:

use testdb
db.testcollection.insertOne({ name: "Bakre", skill: "Cloud Engineering" })
db.testcollection.find()

Then came the real test.

# Delete the running container
docker rm -f mongo-database

# Recreate it with the same volume
docker run -d \
  --name mongo-database \
  --network jamiu-network \
  -p 27017:27017 \
  -v mongo-data:/data/db \
  -e MONGO_INITDB_ROOT_USERNAME=mongoadmin \
  -e MONGO_INITDB_ROOT_PASSWORD=secret \
  mongo

Connected again...
And guess what? 🎉

db.testcollection.find()

The data was still there. My volume was working perfectly. Data persisted!

🚀 Final Thoughts: This Is Cloud Engineering

This project was more than deploying containers. It was about thinking like a professional Cloud Engineer:

Building infrastructure with intention
Debugging under pressure
Validating persistence
Embracing the long road for deeper mastery

Every Founder, CTO, and DevOps team needs people who don’t just know tools, but understand systems. If you're looking for someone who’s not afraid of broken logs, bad connections, or late-night debugging—I’m your guy.

🔧 Cloud isn’t just my skillset. It’s my mindset.

Let’s connect.

🚀How I Achieved My Project: Deploying Docker Images to Amazon Elastic Container Registry (ECR)🐳 Part 2

BAKRE JAMIU — Wed, 30 Apr 2025 16:11:09 +0000

🚀 How I Achieved My Project: Deploying Docker Images to Amazon Elastic Container Registry (ECR)🐳

In this post, I’ll walk you through how I successfully pushed my Docker image to Amazon Elastic Container Registry (ECR) and how Docker made the whole process incredibly seamless. This project involved leveraging Docker's simplicity to move an image from Docker Hub to AWS ECR and then deploying it onto an EC2 instance. Here’s how I did it.

How Docker Streamlined the Project
Docker revolutionizes application deployment by allowing developers to package their applications and all dependencies into containers, ensuring portability and consistency across environments. One of the key benefits of Docker is its ability to create reproducible environments, which makes deploying applications easier and more reliable.

For this project, I used Docker to build my image and initially pushed it to Docker Hub. When it was time to transfer the image to AWS ECR, Docker’s straightforward commands allowed me to easily pull and push the image to ECR, making the process seamless.

Steps to Achieve the Project

1. Docker Installation and Setup

Before starting, I made sure that Docker and AWS CLI were installed on my system. Here are the basic commands to get Docker running on an Ubuntu system:

Install Docker on Ubuntu:

sudo apt update
sudo apt install docker.io

Check my previous post i.e Part 1

Install AWS CLI:

sudo apt install awscli

Follow this official document code

Once installed, I configured the AWS CLI using the following command:

aws configure

This allows you to set your AWS access key, secret access key, and default region.

2. Authenticate Docker to AWS ECR

Since my goal was to move the Docker image to AWS ECR, the next step was to authenticate Docker to AWS using the AWS CLI. The get-login-password command simplifies this process by securely logging Docker into ECR.

Authenticate Docker to ECR:

aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 9111****75.dkr.ecr.us-east-1.amazonaws.com

This command retrieves the authentication token from AWS and logs Docker into the specified ECR repository.

3. Docker Image Build and Push to Docker Hub

For this project, I started by pulling my image from Docker Hub. Once the image was pulled, I ran the container using the following command:

Pull the Docker Image:

docker pull horlacloud/webapp

This command pulls the Docker image from Docker Hub.

After pulling the image, I proceeded to push the container to AWS ECR so that it could be pulled from there later.

4. Tag the Docker Image for ECR

With Docker authenticated to ECR, I tagged my image to point to the correct repository in AWS ECR. The following command tags the image with the appropriate ECR repository URI:

Tag Docker Image:

docker tag webapp:latest 9111****75.dkr.ecr.us-east-1.amazonaws.com/webapp:latest

This step prepares the image for pushing to ECR.

5. Push the Image to ECR

After tagging the image, I pushed it to the AWS ECR repository using the command below:

Push Image to ECR:

docker push 9111****75.dkr.ecr.us-east-1.amazonaws.com/webapp:latest

This command uploads the image to the Amazon ECR repository, making it available for further deployment.

6. Running Docker Image on EC2

To run the image on an EC2 instance, I executed the following commands. This involved pulling the image from ECR and running it on the instance.

Run the Docker Container:

docker run -d -p 8080:80 9111***75.dkr.ecr.us-east-1.amazonaws.com/webapp:latest
4f04c29bffc5929f40306b0edd282464a9e23bdf5c24f42c1abdb4c84ea84043

After executing the above command, my application was running on port 8080 on the EC2 instance. To access the application, I simply visited:

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

Useful Docker Commands for the Project

Here are a few helpful Docker commands I used throughout the process:

Making the `ubuntu` user a root user

If you want to add the ubuntu user to the Docker group (so it can run Docker commands without sudo), use:

sudo usermod -aG docker ubuntu

Then, log out and log back in for the changes to take effect.

Check Docker Images

To see the list of images on your system, run:

docker image ls

Removing Docker Images

If you need to remove an image, use:

docker rmi <image-id>

If a container is using the image, stop and remove the container first with:

docker stop <container-id>
docker rm <container-id>

View Running Containers

To list all running containers:

docker ps

Conclusion

Docker has significantly streamlined the process of moving containerized applications between environments. By pushing my Docker image to Docker Hub and pulling it into AWS ECR, I was able to quickly deploy my application on an EC2 instance with minimal configuration. Docker’s portability and ease of use make it an invaluable tool for cloud-native application deployments.

With AWS ECR and Docker, I now have a robust and scalable containerization pipeline ready for future projects. Docker's simplicity makes managing and deploying applications easier and more efficient than ever.

🚀 Getting Started with Docker: From Installation to Pushing Images to Docker Hub Part 1

BAKRE JAMIU — Tue, 29 Apr 2025 19:42:36 +0000

If you're new to Docker or looking for a simple guide to go from setup to publishing your containerized app, this post is for you. In this tutorial, you'll learn how to:

Install Docker on Ubuntu
Build your first Docker image
Create and run a container
Tag and push your image to Docker Hub

Let’s get started.

🐳 Step 1: Install Docker on Ubuntu

Open your terminal and run the following commands:

sudo apt update
sudo apt install -y docker.io

🔗 Alternative method:

For the latest version and installation options, check the official Docker install script:

get.docker.com

To verify Docker is installed correctly:

docker --version

docker -v

📂 Useful Docker Commands

List Docker images:

docker image ls

List Docker containers:

docker container ls

🛠 Step 2: Build Your Docker Image

Let’s use a static website as an example, such as one downloaded from startbootstrap.com.

Create a Dockerfile in your project directory:

nano Dockerfile

Add the following content:

FROM nginx:alpine
COPY . /usr/share/nginx/html

Build the Docker image:

docker build -t webapp:v1 .

To confirm the image was created:

docker image ls

🚀 Step 3: Run the Container

Now let’s run your image in a Docker container:

docker run -d -p 80:80 --name websiteapp webapp:v1

Visit http://localhost:80 (or your server’s public IP) to see your site live.

To list running containers:

docker container ps

🔐 Step 4: Log in to Docker Hub

If you don’t have a Docker Hub account, sign up here.

Then log in from your terminal:

docker login -u your_dockerhub_username

You’ll be asked to enter your password or a Personal Access Token (PAT).

📦 Step 5: Tag & Push Your Image to Docker Hub

Tag the image:

docker tag webapp:v1 your_dockerhub_username/webapp:v1

Push the image:

docker push your_dockerhub_username/webapp:v1

You can now visit your Docker Hub profile and view your pushed image:

👉 https://hub.docker.com/repositories

After Successful Push

✅ Summary

In this guide, you learned how to:

Install Docker on Ubuntu
Build and run a Docker image
Host a simple static site using NGINX
Push your Docker image to Docker Hub

This workflow forms the backbone of containerized development. You can now use these skills to automate deployments, integrate with CI/CD pipelines, or scale with orchestration tools like Kubernetes.

💬 Have questions or want to learn how to automate deployment using GitHub Actions or AWS ECS? Leave a comment or reach out — I’d love to help!

🚀 How I Deployed My Static Website Using GitHub Actions

BAKRE JAMIU — Thu, 24 Apr 2025 18:40:41 +0000

Deploying a static website manually can be tedious, especially when you’re updating it frequently. That’s why I decided to automate my deployment process using GitHub Actions—a powerful CI/CD tool built right into GitHub.

In this post, I’ll walk you through how I deployed my static website automatically to an NGINX server using GitHub Actions.

🛠️ Tools I Used

GitHub – to store my website’s source code
GitHub Actions – to automate the deployment
Ubuntu Server with NGINX – to host the static site
Self-Hosted GitHub Runner – on the Ubuntu server

📁 Project Structure

My website files are stored in this directory:

_work/ci-static-simple-website/ci-static-simple-website/
│
├── index.html
└── README.md

⚙️ Setting Up the GitHub Action

I created a .github/workflows/deploy.yml file in my repo to define the deployment pipeline.

Here’s a simple version of my GitHub Actions workflow:

name: Deploy Static Website

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: self-hosted

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

    - name: Copy index.html to NGINX Web Directory
      run: |
        cp _work/ci-static-simple-website/ci-static-simple-website/index.html /var/www/html/index.html
        sudo systemctl reload nginx

After successfully testing my code.

Deploying my code to the Linux self-hosted server in process.

🔗 How It Works

Every time I push to the main branch, the GitHub Action is triggered.
The self-hosted runner on my Ubuntu server picks it up.
It copies the index.html file into /var/www/html/.
It reloads NGINX to apply changes immediately.

Successful deployed and it running fine.

My Code is running Live.

🎉 Final Result

Once the action runs, my static website is instantly live at my server’s public IP!

💡 Why This Is Awesome

I never have to manually copy files again
It works perfectly for personal portfolios, landing pages, or project demos
Super fast and reliable!

Let me know in the comments if you'd like a step-by-step guide to setting up your own self-hosted runner or customizing your deployment pipeline!

PM2 Integration with Jenkins on Windows — Observations and Alternative Recommendations

BAKRE JAMIU — Thu, 17 Apr 2025 16:36:46 +0000

Hit a wall trying to run PM2 within Jenkins on a Windows machine 😅 After testing PM2, Forever, NSSM, and Task Scheduler, it’s clear that Windows isn’t PM2’s playground. Sharing this to help anyone facing the same CI/CD challenge 💡

Hello Developers,

During my recent CI/CD pipeline implementation using Jenkins on a Windows environment, I attempted to integrate PM2 as a background process manager for a Node.js application. Despite successfully installing PM2 and validating it via CLI, I encountered issues running it persistently within the Jenkins pipeline.

The process did not behave as expected — PM2 failed to run in the background through Jenkins, and the functionality was no different than invoking node app.js directly. Extensive troubleshooting, including using npx, global installs, and different execution flags (--no-daemon, etc.), did not resolve the issue.

I also explored potential Jenkins plugins for PM2 integration but confirmed that no native or community-supported plugins are currently available.

As a result, I evaluated alternative Node.js process managers that support Windows environments:

Forever – lightweight but lacks advanced features like monitoring and clustering.
NSSM (Non-Sucking Service Manager) – effective for converting scripts to Windows services, though limited in logs and ecosystem integration.
Windows Task Scheduler – native but lacks real-time monitoring and isn't CI/CD friendly.

Unfortunately, none of the alternatives offer the robustness and features of PM2, particularly in CI/CD pipelines running on Windows.

I’m sharing this update for awareness and future reference. If there’s a more effective service/process manager that supports background execution for Node.js apps within Jenkins on Windows, I’m open to exploring it and sharing further findings.

Here is a snapshot of it

Thanks,

Horla (Jahmeeu-Cloud)

Cloud & DevOps Engineer

DevOps #CloudEngineering #CICD #Jenkins #NodeJS #Automation #ProcessManager #PM2 #WindowsDevOps #BuildInPublic #TechCommunity

Infrastructure as a Code (IaC); AWS CloudFormation: Automating Infrastructure Setup

BAKRE JAMIU — Tue, 08 Apr 2025 15:01:56 +0000

AWS CloudFormation is a powerful tool that allows you to define and provision AWS infrastructure as code. In this blog post, I’ll walk you through setting up a complete infrastructure using CloudFormation, including a VPC, Subnet, Route Table, Security Group, and EC2 Instance. I’ll also demonstrate how CloudFormation detects drift when resources are modified outside of the stack.

What I’ll Build

Using CloudFormation, we’ll create:

A VPC with DNS support enabled.
A Subnet within the VPC.
An Internet Gateway and a Route Table for public access.
A Security Group to allow SSH and HTTP traffic.
An EC2 Instance running Amazon Linux 2.
Drift detection to monitor changes made outside of CloudFormation.

CloudFormation Template

Here’s the YAML template used to define the infrastructure:

AWSTemplateFormatVersion: "2010-09-09"
Description: This is my first AWS CloudFormation template

Resources:
  myVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 38.0.0.0/16
      EnableDnsSupport: 'true'
      EnableDnsHostnames: 'true'
      Tags:
        - Key: stack
          Value: production

  mySubnet:
    Type: AWS::EC2::Subnet
    Properties: 
      CidrBlock: 38.0.0.0/16
      VpcId: !Ref myVPC
      AvailabilityZone: us-east-1a
      MapPublicIpOnLaunch: 'true'
      Tags:
        - Key: stack
          Value: production

  myInternetGateway:
    Type: AWS::EC2::InternetGateway
    Properties:
      Tags:
        - Key: stack
          Value: production

  myInternetGatewayAttachment:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      VpcId: !Ref myVPC
      InternetGatewayId: !Ref myInternetGateway

  myRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref myVPC
      Tags:
        - Key: stack
          Value: production

  myRoute:
    Type: AWS::EC2::Route
    Properties:
      RouteTableId: !Ref myRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref myInternetGateway

  mySubnetRouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref mySubnet
      RouteTableId: !Ref myRouteTable

  mySecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Allow SSH and HTTP access
      VpcId: !Ref myVPC
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 22
          ToPort: 22
          CidrIp: 0.0.0.0/0
        - IpProtocol: tcp
          FromPort: 80
          ToPort: 80
          CidrIp: 0.0.0.0/0
      SecurityGroupEgress:
        - IpProtocol: -1
          FromPort: -1
          ToPort: -1
          CidrIp: 0.0.0.0/0
      Tags:
        - Key: stack
          Value: production

  myEC2Instance:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: t2.micro
      ImageId: ami-00a929b66ed6e0de6 
      SubnetId: !Ref mySubnet
      SecurityGroupIds:
        - !Ref mySecurityGroup
      Tags:
        - Key: Name
          Value: MyEC2Instance

This snapshot shows; Deployment is completely created.

Deploying the Stack

Save the template as cloudformation-template.yml.
Use the AWS Management Console or CLI to deploy the stack:

   aws cloudformation create-stack --stack-name MyStack --template-body file://cloudformation-template.yml

Once deployed, you’ll see the resources in the Stack Resources tab of the CloudFormation console.

Snapshots of the Setup

Table View: The CloudFormation console provides a detailed table view of all resources created by the stack, including their status and logical IDs.

EC2 Instance Running: After deployment, the EC2 instance will be running and accessible via SSH or HTTP, depending on the security group rules.

Canva View: The CloudFormation Designer offers a visual representation of the stack, showing the relationships between resources.

Drift Detection

CloudFormation Drift Detection is a feature that identifies changes made to stack resources outside of CloudFormation. For example, When I manually deleted the EC2 instance, CloudFormation will detect the drift.

This is when I purposely terminated to know if it will be drifted as you can see the snapshot.

Trigger Drift Detection:
- Go to the CloudFormation console.
- Select the stack and click Drift Detection.
Drifted Signal:
- The EC2 instance is deleted, the stack will show a Drifted status.
- The drift report will highlight the missing EC2 instance.

This is when it drifted as you can see the snapshot.

Conclusion

AWS CloudFormation simplifies infrastructure management by allowing you to define resources as code. With features like drift detection, you can ensure your infrastructure remains consistent with your template. This setup is a great starting point for automating your AWS environment.

Feel free to share your thoughts or ask questions in the comments below! 😊

AWS #CloudFormation #InfrastructureAsCode #DevOps #Automation #CloudComputing

DEV Community: BAKRE JAMIU

I’m Learning Kubernetes—Here Are the Mistakes I Made So You Don’t Have To

Introduction

1. My starting point

2. What I thought Kubernetes was (and what I misunderstood)

3. Setup: Minikube, Docker, and permissions

4. My first Pod and the patience it taught me

5. Deployments, ReplicaSets, and reconciliation

6. Services — and how I learned what SVC_NOT_FOUND really means

7. Scaling

8. Troubleshooting 🛠️

9. Helm & Kubeshark — and the layer-aware lesson

10. Mistakes I made — and what each one taught me

11. Commands that actually helped me

12. Lessons for other beginners

What I now understand

What I still need to learn

Next stop: Kubernetes Ingress 🚦

Conclusion

📘 Ansible Learning Journey - From Manual SSH to Automation Thinking

🏗️ Project Overview

🔧 What I Implemented (Step-by-Step)

📄 Sample Playbook used in my project:

⚠️ Challenges I Faced (and What I Learned)

1️⃣ “Permission denied (publickey)”

2️⃣ PasswordAuthentication Confusion

3️⃣ APT Lock Errors (unattended-upgrades)

4️⃣ Wrong Package Names

🧠 Key Takeaways I Want Others to Learn

🌱 Growth Mindset

📌 Final Thought

My Ongoing Cloud Migration Journey 🚀

What We’re Doing

My Role

What I’ve Achieved So Far

Where We Are Now

What Makes This Experience Stand Out

My Reflection

Building a Scalable AWS E-Learning Platform for Government Use

🌍 Project Overview

🧱 Architecture Goal

⚙️ Core AWS Services Used

1️⃣ User Authentication & Access Management

2️⃣ Video Delivery and Streaming

3️⃣ Multilingual AI Chatbot

4️⃣ Monitoring & Compliance

5️⃣ Quizzes & Progress Tracking

6️⃣ Data Storage & Analytics

🏗️ 3-Tier Architecture Design

💰 Cost Optimization Highlights

🧠 Key Outcomes

🧾 Deliverables

🚀 Conclusion

📬 Connect With Me

🚀 Optimizing Costs Without Downtime: My Hands-On Experience Downgrading AWS Lightsail; A Step-by-Step Journey

Introduction

🛠 Project Objective

📌 Project Context

🎯 Objectives

📍 End-to-End Execution

Day 1: Assessment & Planning

🎯 What I achieved on Day 1:

Day 2: Environment Setup & Migration

🎯 What I achieved on Day 2 – Environment Preparation:

Day 3: DNS Cutover & Validation

🎯 What I achieved on Day 3 – Cutover & Optimization

✅ Deliverables

📊 Results & Impact

💡 Lessons Learned

🏆 Conclusion

🚀 How I Deployed a Python Flask App with Docker and Troubleshot My Way to Victory 🛠️🐍🐳

🏗️ Project Setup

🐳 Dockerfile Setup

💥 The First Crash: Dependency Drama

🔧 Fix:

🧊 The Second Freeze: Compose Conundrum

🕵️‍♂️ Root Cause:

🔧 Fix:

🟢 Final Compose File

🎯 The Sweet Success

6. Services — and how I learned what `SVC_NOT_FOUND` really means

3️⃣ APT Lock Errors (`unattended-upgrades`)

Making the `ubuntu` user a root user