DEV Community: David Oyewole

Deploying a 3-tier Micro-services Platform on AWS EKS

David Oyewole — Wed, 15 Oct 2025 20:00:51 +0000

by David Oyewole, Cloud & DevOps Engineer

Introduction

Every DevOps engineer eventually faces that “big one”, the project that brings together all the skills we’ve learned across infrastructure, automation, cloud, and observability.

For me, that project was deploying the Sock Shop microservices application on Amazon EKS using Terraform, Helm, AWS Load Balancer Controller, Route53, ACM, ExternalDNS, Prometheus, and Grafana.

What started as an academic capstone evolved into a fully automated, production-ready microservices deployment — complete with HTTPS, DNS automation, and end-to-end monitoring.

This article walks through my design, implementation, challenges, and lessons learned from building this platform from scratch.

The Vision

I wanted to prove I could:

Provision and manage AWS infrastructure as code using Terraform
Deploy Kubernetes workloads with Helm charts
Configure secure ingress with HTTPS and DNS automation
Add observability through Prometheus and Grafana
Do it all without manual steps, in a reproducible, production-grade setup

In other words, to go beyond “it works” and build something that would scale, self-document, and represent how DevOps is done in the real world.

Architecture Overview

At the heart of my setup is AWS EKS, orchestrating dozens of containers across two main namespaces:

sock-shop — the microservices application (frontend + internal services)
monitoring — the observability stack (Prometheus + Grafana)

The Cloud Stack

Layer	Technology	Role
Infrastructure	Terraform	Provisions VPC, EKS, subnets, IAM roles, ACM, Route53
Ingress	AWS ALB Ingress Controller	Manages ingress traffic via ALB
DNS & SSL	Route53 + ACM + ExternalDNS	Automated DNS record creation and TLS certificates
Deployment	Helm	Deploys Sock Shop microservices and monitoring stack
Monitoring	Prometheus + Grafana	Cluster and app observability
Security	IRSA	Fine-grained IAM for ALB and DNS controllers

Traffic flows like this:
User → Route53 (DNS) → ALB (HTTPS termination) → Ingress → Frontend Service → Internal ClusterIP Services

Step 1: Infrastructure as Code with Terraform

I started by writing Terraform modules to create the networking and compute foundation.

Terraform handled:

A VPC with public and private subnets
EKS cluster and managed node groups
IAM roles for both controllers (external-dns and aws-load-balancer-controller) using IRSA
A Route53 hosted zone for my subdomain (sock.blessedc.org)
An ACM wildcard certificate for HTTPS termination

Once the code was ready, I ran

terraform init
terraform apply -auto-approve

In minutes, AWS spun up a fully functional Kubernetes environment with all IAM and networking policies correctly set.

Step 2: Deploying Microservices with Helm

With infrastructure live, I used Helm to deploy the Sock Shop micro-services.

helm repo add sock-shop https://microservices-demo.github.io/helm
helm install sockshop sock-shop/sock-shop -n sock-shop --create-namespace

Helm made it easy to templatize everything and redeploy consistently after every test or rebuild.

I configured only the frontend service to be public (via Ingress), while keeping all other services (catalogue, user, orders, shipping, etc.) internal-only with ClusterIP.

This separation ensured the architecture was both secure and realistic, mimicking real-world micro-service deployments.

Step 3: HTTPS & DNS Automation

Manual certificate management and DNS updates are the enemies of scalability.

So I automated both using:

AWS Certificate Manager (ACM) — provisioned via Terraform with a wildcard certificate (*.blessedc.org)
ExternalDNS — dynamically updates Route53 A-records based on Ingress resources
AWS ALB Ingress Controller — automatically creates the load balancer and attaches the certificate

A single Ingress.yaml file for the frontend handled all of this:

annotations:
  kubernetes.io/ingress.class: alb
  alb.ingress.kubernetes.io/scheme: internet-facing
  alb.ingress.kubernetes.io/target-type: ip
  alb.ingress.kubernetes.io/certificate-arn: <acm-arn>

In less than five minutes, a fully functional HTTPS endpoint appeared:

https://sock.blessedc.org

And yes ExternalDNS took care of the Route53 record automatically using helm by running this command

helm repo add external-dns https://kubernetes-sigs.github.io/external-dns/
helm repo update

helm install external-dns external-dns/external-dns \
--namespace external-dns \
--create-namespace \
--set provider=aws \
--set registry=txt \
--set txtOwnerId=sockshop \
--set domainFilters={sock.blessedc.org} \
--set aws.zoneType=public \
--set serviceAccount.create=true \
--set serviceAccount.name=external-dns \
--set serviceAccount.annotations."eks\.amazonaws\.com/role-arn"=arn:aws:iam::<IAM-ID>:role/eks-externaldns-role

Step 4: Monitoring with Prometheus and Grafana

No production cluster is complete without observability.

I deployed a complete monitoring stack using the kube-prometheus-stack Helm chart.

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install monitoring prometheus-community/kube-prometheus-stack -n monitoring --create-namespace
kubectl apply -f grafana-ingress.yaml -n monitoring
kubectl apply -f prometheus-ingress.yaml -n monitoring

This deployed:

Prometheus — scraping cluster and application metrics
Grafana — for dashboard visualization
Alertmanager — ready for future integrations

I created the grafana-ingress.yaml and prometheus-ingress.yaml file before executing that command, this created the grafana and prometheus sub domains like this:

grafana.sock.blessedc.org
prometheus.sock.blessedc.org

and exposed them via Ingress, secured by the same ACM certificate.

Custom Grafana Dashboard

I built a custom “Sock Shop Microservices Overview” dashboard showing:

Pod CPU & Memory usage per microservice
Pod restart count
Node resource utilization
Cluster-wide health
Request and error rates

It was a beautiful moment seeing real-time metrics flow across a system I built entirely from scratch.

Step 5: Troubleshooting and Challenges

No project is complete without a few scars.

Here are some of the issues I hit — and how I fixed them:

Issue	Root Cause	Fix
AccessDenied for Route53	Missing IAM permissions for ExternalDNS	Attached `route53:*` policy to `eks-externaldns-role`
ALB not creating	Missing `ingressClassName` and IAM for ALB controller	Updated Ingress annotations and IRSA role
Ingress stuck without address	ACM ARN mismatch	Ensured the certificate region matched the cluster region (`us-east-1`)
Hosted Zone not deleting	Route53 still had A/TXT records	Cleaned up manually before running `terraform destroy`
Grafana unreachable	Ingress hostname typo	Fixed host rule to `grafana.sock.blessedc.org`

Each issue taught me something about how AWS and Kubernetes actually communicate under the hood and that’s where true learning happens.

Security Highlights

Used IRSA (IAM Roles for Service Accounts) for both aws-load-balancer-controller and external-dns
Ensured all backend services stayed internal (ClusterIP)
Enabled HTTPS-only ingress (redirecting all HTTP to HTTPS)
Isolated monitoring stack in a separate namespace

This aligns with cloud-native security best practices for production workloads.

Results

After deployment, I had:

A fully automated and reproducible AWS EKS cluster
Publicly available frontend accessible via HTTPS
DNS records auto-managed by Kubernetes (no manual updates)
Centralized monitoring for all microservices
A clean teardown/rebuild process via Terraform in minutes

Lessons Learned

Networking is everything. Understanding subnets, routes, and public vs private traffic is key before touching EKS.
ALB Ingress Controller is incredibly powerful but requires precise IAM permissions.
Automation = Reliability. The fewer manual steps, the fewer production mistakes.
Monitoring early helps debug faster and ensures confidence in the platform.
IRSA changed the way I think about security in Kubernetes no more over-permissioned nodes.

Final Thoughts

This project made me appreciate the power of Infrastructure as Code and declarative configuration.
It taught me to think like a systems designer, not just an implementer building platforms that can scale, heal, and redeploy themselves.

Today, my sock.blessedc.org setup stands as more than a capstone,
it’s my personal proof that DevOps is about automation, resilience, and continuous learning.

Summary

This project demonstrates how to design and deploy a secure, scalable, observable microservices architecture on AWS, using Terraform for infrastructure, Helm for Kubernetes deployments, and modern DevOps best practices for automation, monitoring, and reliability.

👨‍💻 Author

David Oyewole
Cloud & DevOps Engineer
LinkedIn
Github

🚀 Building a Fully Automated Cloud Monitoring & Logging Infrastructure on AWS

David Oyewole — Fri, 25 Jul 2025 09:15:21 +0000

In today’s cloud-native world, observability is more than just a luxury, it's a necessity. Whether you’re a startup deploying fast or an enterprise managing hundreds of services, monitoring and logging infrastructure forms the backbone of system reliability and performance.

This article documents how I designed and automated a real-world cloud monitoring and logging infrastructure using Terraform, Ansible, Prometheus, Grafana, Loki, Fluent Bit, and Alertmanager, all deployed on AWS EC2 with logs stored remotely in S3.

🎯 Why I Built This Project

I’ve worked on cloud deployments before, but I wanted something beyond the usual hello-world stack. I wanted a setup that would:

Mirror what’s used in real production environments
Be modular and repeatable (IAC-first mindset)
Handle metrics, logs, and alerts in a centralized and automated way
Include secure public access to dashboards and endpoints via HTTPS

This project was not only an exercise in learning and problem-solving, but also a step toward building production-ready DevOps workflows.

🌍 Real-World Use Case

Imagine you're managing infrastructure for a SaaS product with multiple microservices. Here’s how this stack supports you:

Concern	Solution Provided
Detect server failure	Prometheus + Alertmanager alerts to Slack
Monitor system metrics	Node Exporter + Grafana dashboards
Track app errors in logs	Fluent Bit → Loki → Grafana
Long-term log retention	Loki stores chunks in S3
Secure access to tools	Nginx reverse proxy + SSL
Infrastructure scalability	Terraform + modular Ansible roles

⚙️ Architecture Overview

The project provisions:

Two EC2 instances:
- Monitoring Server (Prometheus, Grafana, Loki, Alertmanager, Nginx)
- Web Server (Fluent Bit, Node Exporter, and static web content)
S3 Bucket for storing Loki logs
Slack Integration via Alertmanager
All services are containerless and run as systemd services for simplicity and transparency.

    [Web Server]                      [Monitoring Server]
    ┌──────────────┐                   ┌────────────────────────────────┐
    │ Node Exporter│→───────────────→│  Prometheus               │
    │ Fluent Bit  │━━━━━━━━━━━┐          │                           │
    └───────────────└────────────→ │  Loki                     │
                                    │   ↳ S3 storage backend     │
                                    │  Grafana + Alertmanager    │
                                    └────────────────────────────┘
                                             ↓
                                       Slack Notifications

🧠 Automation Strategy

From the beginning, the goal was to automate everything. I used:

Terraform: To provision EC2, security groups, IAM roles, and the S3 bucket
Ansible: To install, configure, and start all services
A shell script: To orchestrate the full deployment and handle DNS updates via Namecheap's dynamic DNS API

Everything from spinning up servers to pushing logs into Grafana — happens with a single command:

./deploy.sh

This deploys Terraform infra, fetches the EC2 IP, updates DNS, waits for propagation, generates Ansible variables, and runs the full Ansible playbook.

💥 Challenges Faced

1. DNS & SSL Certbot Errors

Let’s Encrypt (via Certbot) expects Nginx to be running before it can verify domain ownership, but Nginx can’t start unless the SSL certs exist. Classic chicken-and-egg.

Solution:
I implemented a temporary HTTP-only Nginx config just to obtain the certs, then replaced it with the full reverse proxy config.

2. Terraform IP Sync with Ansible

After terraform apply, the private/public IPs of EC2 instances change, but Ansible needs those IPs to connect and configure properly.

Solution:
I wrote a Python script to auto-generate a YAML file (terraform_outputs.yml) from terraform output -json, which Ansible uses directly.

3. Loki Failing to Flush Logs to S3

I saw this error:

PutObjectInput.Bucket: minimum field size of 1

Turns out, even though the AWS credentials were set, the bucket name was missing in the config due to a YAML templating issue.

Lesson: Always double-check templated variables and file paths in production systems.

4. Slack Webhook Not Working

Alertmanager showed the alert as firing, but no message came to Slack.

Cause: The webhook URL wasn’t rendering correctly in the Alertmanager config due to a misconfigured variable.

Fix: Injected the correct URL into Ansible vars and validated it using cat /etc/alertmanager/alertmanager.yml | grep api_url.

📊 Dashboards in Action

Once everything was set up, Grafana became the single-pane-of-glass for:

CPU, memory, disk metrics from Prometheus + Node Exporter
Log streams from Fluent Bit + Loki, searchable by label
Alert status overview with firing/resolved alerts
S3 bucket verification for long-term log persistence

Access it securely at:

https://monitoring.yourdomain.com/grafana/

📣 Slack Alerts in Action

Prometheus + Alertmanager monitor system health, and notify me on Slack when:

A server goes down (NodeDown)
Fluent Bit or Loki stop sending logs
Memory or CPU usage exceeds thresholds

💡 Key Lessons Learned

Observability must be baked in from the start, not retrofitted.
SSL and reverse proxy automation can be tricky — understand the Certbot flow.
Always validate your YAML configs on target machines.
The power of infrastructure-as-code is not just provisioning — but repeatability.

✅ What’s Next

[ ] Add autoscaling for web nodes and dynamic target discovery in Prometheus
[ ] Automate dashboard import in Grafana via JSON API
[ ] Add multi-user RBAC auth for Grafana
[ ] Store Prometheus TSDB snapshots in S3

📁 GitHub Repository

Full codebase is available here:
🔗 GitHub - Cloud Monitoring & Logging Infrastructure

🙌 Final Thoughts

This project solidified my understanding of real-world observability. It goes beyond tutorials and walks into what a DevOps engineer would actually implement in a production environment.

Everything provisioning, configuration, metrics, logs, dashboards, alerts, HTTPS, log storage is done automatically with one script.

If you're building or learning DevOps, I strongly recommend doing a project like this. It forces you to troubleshoot across multiple layers: infrastructure, OS, services, and automation.

Let me know what you think, or if you’d like a walkthrough video or workshop based on this project!

[Boost]

David Oyewole — Fri, 25 Jul 2025 08:06:05 +0000

David Oyewole

Jun 12 '25

From Scratch to Kubernetes: My Full-Stack DevOps Project on a Local Machine

#devops #kubernetes #docker #monitoring

Comments 2

3 min read

From Scratch to Kubernetes: My Full-Stack DevOps Project on a Local Machine

David Oyewole — Thu, 12 Jun 2025 13:12:54 +0000

🚀 Description

A hands-on DevOps showcase: containerization, Kubernetes with Helm, CI/CD using GitHub Actions, and observability with Prometheus, all running locally.

In this article, I walk through a DevOps project I recently completed, a fully containerized full-stack web application deployed on a local Kubernetes cluster. This project was designed not just to build a functional app, but to demonstrate my DevOps skills end-to-end: containerization, orchestration, CI/CD, and observability.

🛠️ Project Overview

🔧 Project Goal:
The goal was to create a simple yet realistic web app and apply modern DevOps practices around it. Here's what the application does:

A React frontend collects user information.
The data is sent to a Flask backend, which checks if the user already exists.
If not, it adds the user to a PostgreSQL database.
Redis is used to cache the user data for faster reads.
Nginx acts as a reverse proxy to route traffic efficiently.

Simple in logic, but powerful as a DevOps exercise.

📦 Containerization with Docker

🐳 Consistent builds everywhere.

Each component of the stack React front-end, Flask back-end, PostgreSQL, Redis, and Nginx was packaged into its own Docker container. I created Dockerfiles for the front-end, back-end,PostgrSQL and Nginx while the using redis official images

I pushed all my custom images to Docker Hub, making them easy to deploy anywhere.

☸️ Kubernetes Orchestration with Helm

🧭 Template-driven deployments.
I chose Minikube as my local Kubernetes distribution because it’s lightweight and easy to set up.

To manage deployments efficiently, I used Helm charts. Helm made it easier to define and template Kubernetes manifests for each component. It allowed me to quickly spin up or update the application by adjusting just a few values.

Key Kubernetes resources used:

Deployments for the front-end, back-end, and Nginx
StatefulSet for PostgreSQL
Persistent Volumes for database storage
ConfigMaps and Secrets for environment variables
Ingress configured with Nginx for routing

🌐 Reverse Proxy with NGINX

🛣️ Traffic routing made simple.

NGINX was configured as a reverse proxy to route external traffic efficiently to the back-end services and enforce separation of concerns.

⚡ Caching with Redis

🚀 Faster response times.

Redis was integrated as an in-memory store to cache user data, helping reduce database load and improve response times.

🐘 PostgreSQL for Persistent Storage

🗄️ Reliable relational storage.

PostgreSQL was used as the main relational database, storing all user information reliably with persistent volumes on Kubernetes.

📈 Observability with Prometheus, Grafana & Alertmanager

📊 Visualizing performance.

Monitoring is essential for any production-grade system. I deployed the Prometheus stack, including Grafana and Alertmanager inside the cluster.

Prometheus scraped metrics from pods and the Kubernetes API.
Grafana provided dashboards to visualize system performance (CPU, memory, request latency).
I configured Alertmanager to send alerts to a Slack channel when thresholds were breached (e.g., high memory usage or pod crashes).

🔁 CI/CD with GitHub Actions and Self-Hosted Runner

🤖 Automated delivery pipeline.
To complete the DevOps lifecycle, I set up a full CI/CD pipeline using GitHub Actions.

CI/CD Workflow:

Lint and test the code (for front-end/back-end).
Build Docker images.
Push to Docker Hub.
Trigger a deployment to my MicroK8s cluster.

Since the cluster was running locally, I used a self-hosted GitHub Actions runner installed on my laptop. This allowed the pipeline to build and deploy directly to my local Kubernetes environment no cloud required.

⚠️ Challenges & Lessons Learned

🧩 Solving real-world problems.

Ingress and Service Networking: Getting Nginx ingress to work with service routing locally took some tweaking.
Secrets Management: Managing database credentials and API keys securely in Kubernetes taught me the importance of Secrets and RBAC.
Resource Limits: Without setting proper resource requests/limits, some pods would get evicted under memory pressure.
CI/CD Integration: Setting up a self-hosted GitHub runner took some trial and error but was a great learning experience.

✅ Final Thoughts

This project helped me strengthen my understanding of the entire DevOps lifecycle:

From writing Dockerfiles to managing deployments with Helm
From local Kubernetes orchestration to building CI/CD pipelines
From setting up observability tools to configuring real-time alerts

It was a rewarding experience that sharpened my technical skills and gave me a deeper appreciation for system reliability and automation.

📎 Want to See the Code?

Feel free to check out the project repository on GitHub:

👉 Github Repo

If you have any questions or feedback, I’d love to hear from you in the comments!

How I Built a Bulk Email Sender with Python and Brevo API

David Oyewole — Thu, 12 Jun 2025 12:12:18 +0000

Sending personalized bulk emails programmatically is something I’ve always wanted to do, especially for community engagement and event updates. Recently, I built a simple but powerful bulk email sender in Python using the Brevo SMTP service. In this post, I’ll walk you through everything from setting up Brevo, to reading recipients from a CSV file, sending beautiful HTML emails with personalized content, and tracking email delivery status.

🧰 Tools & Technologies Used

Python 3

Pandas – for reading and updating the CSV

smtplib – to send emails via SMTP

email.mime – for formatting the emails in HTML

Brevo SMTP – the email delivery service (free plan supported!)

📝 Step 1: Preparing the Email List

I had already collected user responses via Google Forms. From the Google Sheet, I manually downloaded a CSV that included columns like Full Name, Email address, and sent_status. The sent_status column helps prevent resending to the same recipients.

Here’s a sample structure of the CSV:

Full Name	Email address	sent_status
Jane Doe	jane@example.com
John Smith	johnsmith@domain.com

✉️ Step 2: Setting Up Brevo SMTP

I signed up at Brevo.

From the dashboard, I went to SMTP & API section.

Copied my SMTP credentials and took note of the login username (something like abc123@smtp-brevo.com).

I also authenticated my sending domain (e.g., kingdavid.me) so my messages wouldn’t get marked as spam.

If you don’t have a domain, Brevo still lets you test with limited functionality—but domain authentication is recommended for proper deliverability.

🧑‍💻 Step 3: Writing the Python Script

Here’s what the script does:

Loads the CSV using Pandas.

Loops through each row and checks if the email was already sent.

Creates a personalized HTML email for each recipient.

Sends the email via Brevo SMTP.

Updates the sent_status in the CSV after each email is sent.

Sleeps between sends to avoid being rate-limited.

import sib_api_v3_sdk
import pandas as pd
from email.mime.multipart import MIMEMultipart
from email.mime.text import MIMEText
import time
from sib_api_v3_sdk.rest import ApiException  # Import ApiException

# Initialize Brevo API client
configuration = sib_api_v3_sdk.Configuration()
configuration.api_key['api-key'] = ''  # Replace with your actual Brevo API key

api_instance = sib_api_v3_sdk.TransactionalEmailsApi(sib_api_v3_sdk.ApiClient(configuration))

# Define sender email as a dictionary (Ensure it's a verified sender email)
sender = {
    "name": "John Doe",  # Replace with your name
    "email": "Johndoe@email.com"  # Replace with a valid sender email that is verified
}

# CSV file containing email addresses and names
CSV_FILE = "Cleaned Data.csv"
DELAY = 1  # seconds between emails

SUBJECT = "WEB3 LITERACY WITH BLESSED"
HTML_BODY = """
<html>
  <head>
    <style>
      body {{
        font-family: Arial, sans-serif;
        background-color: #f4f4f4;
        margin: 0;
        padding: 0;
      }}
      .container {{
        background-color: #ffffff;
        max-width: 600px;
        margin: 30px auto;
        padding: 20px;
        border-radius: 10px;
        box-shadow: 0 2px 5px rgba(0,0,0,0.1);
      }}
      .header {{
        text-align: center;
        padding-bottom: 20px;
      }}
      .logo {{
        width: 120px;
      }}
      .body-content {{
        font-size: 20px;
        color: #333333;
        line-height: 1.6;
      }}
      .footer {{
        text-align: center;
        font-size: 12px;
        color: #999999;
        padding-top: 20px;
      }}
    </style>
  </head>
  <body>
    <div class="container">
      <div class="header">
        <img src="https://drive.google.com/uc?export=view&id=1cdWkRN1S8JvGye-f55a3aWfkE2pr9d1w" alt="Logo" class="logo" />
      </div>
      <div class="body-content">
        <p>Hi <strong> {name} </strong>,</p>
        <p>Thank you for taking the bold step to begin your journey into the world of Web3 and blockchain technology. I’m 
        truly excited to have you onboard, and I look forward to walking this path with you over the next few weeks. 
        We’ll kick things off tomorrow with a pre-class session, where you’ll get an overview of what to expect and how to 
        prepare. The full course officially begins on the 22nd of this month and will run for 10 days, taking place every 
        Wednesday, Thursday, Friday, and Saturday. To ensure a smooth and interactive learning experience, we’ve created four
          private Telegram groups, with each group holding between 200 to 400 participants to avoid overcrowding and make 
          sure everyone gets the attention they need. You can join your assigned group using the unique link in this email. 
          Please note that this is a personalized link created just for you. It must not be shared or forwarded. 
          Each link is tied to a specific participant, and sharing it may lead to identification and removal from the class. 
          The full curriculum will be shared with you soon. I’m looking forward to a powerful three weeks of Web3 literacy, 
          growth, and connection. I wish you great success as you step into the future of technology and digital opportunity! 
          Let’s do this! </p>
          <a href="https:******"><strong>Join The Group Here</strong></a>
        <p>Warm regards,<br><strong>Blessed</strong> <br><strong>Host, Web3 Literacy Season1</strong></p>
      </div>
      <div class="footer">
        <p>This is an automated message — please don’t reply directly.</p>
      </div>
    </div>
  </body>
</html>
"""

# Load the CSV file with email recipients
df = pd.read_csv(CSV_FILE)

# Add a column for email sending status
if "sent_status" not in df.columns:
    df["sent_status"] = ""

df["sent_status"] = df["sent_status"].astype(str)

# Loop through each email
for i, row in df.iterrows():
    if str(row["sent_status"]).strip().lower() == "sent":
        continue

    recipient_email = row["Email address"]
    name = row.get("Full Name", "there")
    html = HTML_BODY.format(name=name)

    # Prepare the email
    try:
        send_smtp_email = sib_api_v3_sdk.SendSmtpEmail(
            to=[{"email": recipient_email}],
            subject=SUBJECT,
            html_content=html,
            sender=sender  # Corrected sender format
        )

        # Send the email using Brevo's API
        api_instance.send_transac_email(send_smtp_email)

        print(f"✅ Sent to {recipient_email}")
        df.at[i, "sent_status"] = "sent"

    except ApiException as e:
        print(f"❌ Failed to send to {recipient_email}: {e}")
        df.at[i, "sent_status"] = f"failed: {e}"

    time.sleep(DELAY)

# Save updated status to the CSV file
df.to_csv(CSV_FILE, index=False)

📸 Adding an Image to Your Email

To include an image in your HTML email, use a public image URL (e.g., uploaded to Imgur or your domain). Embedding local images isn't reliable for HTML email clients.

<img src="https://yourdomain.com/logo.png" alt="Web3 Logo" />

📊 Tracking Status

The sent_status column is updated automatically in your CSV file, making the script idempotent. You can rerun the script, and it will skip those already marked as sent.
🧠 Lessons Learned

Validating your sending domain helps prevent email delivery issues.

Use try/except to catch failed deliveries and record them.

Avoid embedding base64 images—host your assets publicly.

Always add delays to avoid getting rate-limited or blacklisted.

💡 Final Thoughts

This project taught me a lot about email infrastructure and how easy it is to build something practical with just a few lines of Python. If you’re looking to build a newsletter or outreach tool without a full-blown ESP, this is a solid starting point.

Feel free to fork it and tweak to your needs. Happy hacking!

Why I Switched from WSL to Ubuntu for DevOps: A Personal Journey

David Oyewole — Thu, 12 Jun 2025 12:10:40 +0000

👋 Introduction

For a long time, I ran my development and DevOps tooling inside Windows Subsystem for Linux (WSL). It felt like the best of both worlds: I could run Linux commands and tools while still using my Windows desktop apps. I even configured Docker, Minikube, Microk8s and a bunch of other tools to work inside WSL. But as my DevOps workflow grew more complex especially around Kubernetes, CI/CD, and observability I kept running into annoying limitations.

So I made a decision: I wiped the whole windows OS and WSL then installed Ubuntu as my main OS. The result? Everything just works better. Faster. Cleaner. More reliable.

This post walks you through why I switched, what changed, and why I’m never looking back.

🧠 WSL vs Native Ubuntu: A DevOps-Focused Comparison

Let’s get straight to the core differences I noticed after making the switch:

Feature	Ubuntu (Native)	WSL (Windows)
Networking	Full, native networking	Isolated VM networking
Systemd Support	✅ Full `systemctl` and timers	❌ WSL1 lacks it, WSL2 partial
Docker Support	Native Docker daemon	Needs Docker Desktop
Kubernetes	Runs smoothly (MicroK8s/Minikube)	Requires tunneling & workarounds
GUI Apps	GNOME, Postman, VS Code, etc.	WSLg is decent, but glitchy
File Access	Native ext4 filesystem	Slower across `/mnt/c/`
Hardware Support	Direct access to USB, GPU, etc.	Limited or indirect

WSL is amazing for lightweight scripting and simple setups. But when you need production-grade workflows or want to simulate real infrastructure, it becomes a struggle.

🚀 The Moment That Blew My Mind

I deployed a sample app on Kubernetes with a NodePort service, and without doing any port forwarding, I opened my browser and hit http://localhost:30000. It worked.

Coming from WSL, where I had to constantly run:

kubectl port-forward svc/my-service 8080:80

to get anything into the browser, this felt like pure magic. No hacks. No tunnels. No separate IP guessing.

That was the first moment I realized just how much friction I had been tolerating under WSL.

🛠️ What I Love About Ubuntu as a DevOps Engineer

Since making the switch, here’s how my workflow has improved:

✅ Full Docker & Kubernetes Support

I now run MicroK8s natively with all the bells and whistles: Helm, Prometheus, Grafana, Ingress, and more. No need for Docker Desktop or weird socket tricks everything is integrated and lightweight.

✅ systemd for Automation

I use systemd to run background agents like Jenkins, Prometheus Node Exporter, and even test CI runners. I can enable them with:

sudo systemctl enable my-service

Something I always missed in WSL.

✅ Real Networking

I use nmap, tcpdump, iptables, and even set up firewall rules with ufw. These tools either don't work or require complex setup in WSL.

✅ Better Resource Utilization

I can control my containers using real cgroups, assign memory limits, and monitor system metrics accurately no Docker Desktop abstractions.

✅ Native File I/O Performance

Building containers and running tools like Ansible or Terraform is significantly faster. No slow-downs when writing files.

✅ GUI Just Works

I’ve installed Postman, DBeaver, VS Code, and everything runs like native apps because they are. WSLg is improving, but it still feels a bit clunky.

🧪 Real-World Use Case

I recently built a full-stack app with Flask, React, PostgreSQL, and NGINX all containerized and deployed on MicroK8s. In Ubuntu:

I deployed with Helm
Monitored with Prometheus + Grafana
Logged with the ELK stack
Used VS Code + Terminal in split screen
Browsed the app without needing a single port-forward

This would have been possible in WSL but not without hours of config, tunneling, and frustration.

🤔 Should You Switch?

If you:

Work heavily with Docker or Kubernetes
Build or test cloud-native apps
Want to use tools like Ansible, Terraform, Helm
Need fast builds, native services, or background agents

Then yes, switching to Ubuntu is absolutely worth it.

But if you're doing light scripting, occasional CLI work, or you rely heavily on Windows apps, WSL might still be the better fit for you.

🧵 Final Thoughts

WSL was a great bridge between worlds, but for serious DevOps engineering, native Ubuntu is where the real power lies. I’ve spent less time fighting the environment and more time shipping features, building infrastructure, and learning tools that behave exactly how they do in production.

If you've been feeling the same friction I was, consider making the leap.

Let me know your experience have you switched? Still thinking about it? Let's chat in the comments! 🚀

Follow me for more DevOps tips, real-world experiences, and Kubernetes content.

Automating Flask Deployment with GitHub Actions and Docker

David Oyewole — Tue, 01 Apr 2025 09:18:11 +0000

Introduction

Continuous Integration and Continuous Deployment (CI/CD) are essential for modern software development. In this tutorial, I will walk you through setting up a CI/CD pipeline for a Flask application using GitHub Actions and Docker. By the end of this guide, you will have an automated workflow that builds, tests, and pushes a Docker image to Docker Hub.

⚙️ Prerequisites

Python 3.x
pip
Docker
GitHub Repository
Docker Hub Account
AWS EC2 Instance with Docker installed
SSH Access to the EC2 instance

Step 1: Setting Up the Flask Application

Let's start by creating a simple Flask application.

Create a project directory:
```
mkdir flask-cicd && cd flask-cicd
```

Create a virtual environment and activate it:

python3 -m venv venv
source venv/bin/activate  # On macOS/Linux
venv\Scripts\activate  # On Windows

Install Flask:
```
pip install flask
```

Create an app.py file:

from flask import Flask

app = Flask(__name__)

@app.route('/')
def home():
    return "Hello, Flask CI/CD!"

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

Create a requirements.txt file:
```
flask
```

Step 2: Dockerizing the Flask Application

Create a Dockerfile in the project directory:

# Use official Python image
FROM python:3.10

WORKDIR /app

COPY requirements.txt requirements.txt
RUN pip install --no-cache-dir -r requirements.txt

COPY . .
EXPOSE 5000
CMD ["python", "app.py"]

To test the Docker container locally, build and run it:

docker build -t flask-cicd .
docker run -p 5000:5000 flask-cicd

Step 3: Setting Up GitHub Actions for CI/CD

Now, we will create a GitHub Actions workflow to automate building and pushing our Docker image to Docker Hub.

🔄 CI/CD Pipeline (GitHub Actions)
✅ CI — Continuous Integration
GitHub Actions automatically runs the following on each push to main:

Clone repository

Set up Python and install dependencies

Run unit tests

Build Docker image

Push image to Docker Hub

🚀 CD — Continuous Deployment to EC2
After a successful Docker push, a second GitHub Actions job connects to your EC2 server via SSH and:

Logs into Docker (if private image)

Pulls the latest image from Docker Hub

Stops and removes the old container

Runs the updated container

This enables automatic deployment of your latest code to a live server!

Inside your project, create .github/workflows/main.yml and add the following:

# This workflow will install Python dependencies, run tests and lint with a single version of Python
# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-python

name: Python application

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

permissions:
  contents: read

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v4
    - name: Set up Python 3.10
      uses: actions/setup-python@v3
      with:
        python-version: "3.10"
    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        pip install flake8 pytest
        if [ -f requirements.txt ]; then pip install -r requirements.txt; fi
    - name: Lint with flake8
      run: |
        # stop the build if there are Python syntax errors or undefined names
        flake8 . --count --select=E9,F63,F7,F82 --show-source --statistics
        # exit-zero treats all errors as warnings. The GitHub editor is 127 chars wide
        flake8 . --count --exit-zero --max-complexity=10 --max-line-length=127 --statistics
    - name: Log in to Docker Hub
      uses: docker/login-action@v3
      with:
        username: ${{ secrets.DOCKER_USERNAME }}
        password: ${{ secrets.DOCKER_PASSWORD }}

    - name: Set up Docker Buildx
      uses: docker/setup-buildx-action@v3

    - name: Build and Push Docker Image
      uses: docker/build-push-action@v5
      with:
        context: .
        file: Dockerfile  # Ensure this path is correct
        push: true
        tags: ${{ secrets.DOCKER_USERNAME }}/practice:latest

  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy on EC2 via SSH
        uses: appleboy/ssh-action@v1.0.0
        with:
          host: ${{ secrets.EC2_HOST }}
          username: ${{ secrets.EC2_USER }}
          key: ${{ secrets.EC2_SSH_KEY }}
          script: |
            docker login -u ${{ secrets.DOCKER_USERNAME }} -p ${{ secrets.DOCKER_PASSWORD }}
            docker pull ${{ secrets.DOCKER_USERNAME}}/practice:latest

            docker stop flask-app || true
            docker rm flask-app || true

            docker run -d \
              --name flask-app \
              -p 5000:5000 \
              ${{ secrets.DOCKER_USERNAME}}/practice:latest

Once pushed, GitHub Actions will automatically run the workflow. You can check the status under the Actions tab in your repository.

🔐 GitHub Secrets Configuration

Remember to add the appropriate secrets to your github secret, go to Actions>secrets and add the following with correct values

Secret Name	Purpose
`DOCKER_USERNAME`	Docker Hub username
`DOCKER_PASSWORD`	Docker Hub password/token
`EC2_HOST`	Public IP or DNS of your EC2
`EC2_USER`	SSH username (e.g., `ubuntu`)
`EC2_SSH_KEY`	Private SSH key for EC2 access

Conclusion

Congratulations! 🎉 You have successfully set up a CI/CD pipeline for your Flask application using GitHub Actions and Docker. Now, every time you push code, your application will be tested, built, and deployed automatically.

Feel free to share your thoughts and improvements in the comments below! 🚀

Windows Subsystem for Linux (WSL)

David Oyewole — Sat, 29 Mar 2025 19:36:17 +0000

Introduction

In my early days of learning DevOps, one of the biggest challenges I faced was setting up a Linux environment on my laptop. Since I was already comfortable with Windows, I found it difficult to make a complete switch to Linux, mainly because I still needed access to certain Windows applications.

I initially tried dual-booting, but it felt cumbersome—I wanted both operating systems to work side by side without rebooting. Then I experimented with virtual machines (VMs), which worked but drained my laptop’s battery too quickly.

During my search for a better solution, I discovered Windows Subsystem for Linux (WSL), which turned out to be the perfect answer to my problem. Since then, I haven’t looked back—WSL allows me to run a Linux environment directly within Windows, seamlessly integrating both systems.

What is WSL?

Windows Subsystem for Linux (WSL) is a powerful compatibility layer that enables users to run a full Linux environment natively on Windows. Unlike traditional virtual machines or dual-boot setups, WSL provides a lightweight and efficient way to access Linux tools and utilities directly from Windows.

WSL is particularly useful for developers, system administrators, and DevOps engineers who require Linux-based tools while maintaining a Windows workflow. This guide will cover everything you need to know about WSL, from installation to advanced usage.

Why Use WSL?

WSL offers several advantages over traditional virtualization and dual-boot setups:

Seamless Integration: Run Linux commands and applications alongside Windows programs.
Low Resource Usage: No need for additional system resources to run a separate virtual machine.
Native Performance: WSL 2 provides full system call compatibility and improved performance with a real Linux kernel.
Improved Developer Experience: Use Linux-native tools, package managers, and programming languages without leaving Windows.
Better Docker Support: WSL 2 significantly improves Docker’s performance and integration with Windows.

Installing WSL on Windows

To install WSL on your Windows machine, follow these steps:

Prerequisites

Ensure that your system is running Windows 10 version 2004 and higher (Build 19041 and higher) or Windows 11.

Step 1: Enable WSL

Open PowerShell as Administrator and execute the following command:

wsl --install

This command automatically installs WSL and the default Linux distribution (Ubuntu), which can be changed later.

If you already have WSL installed but want to update to WSL 2, run:

wsl --update

Step 2: Verify Installed Distributions

Check the available and installed distributions with:

wsl --list --verbose

This will display:

Installed Linux distributions
The default WSL version (WSL 1 or WSL 2)

Step 3: Set WSL 2 as Default

To take advantage of WSL 2’s features, set it as the default version:

wsl --set-default-version 2

Step 4: Install Additional Linux Distributions

To install another Linux distribution, run:

wsl --install -d <Distribution Name>

Replace <Distribution Name> with your preferred Linux distribution.

To see a list of available distributions, run:

wsl --list --online

If you need to upgrade a specific distribution to WSL 2, use:

wsl --set-version <DistroName> 2

Replace <DistroName> with the name of your installed Linux distribution.

Using WSL

Launching WSL

To start WSL, simply open a terminal and run:

wsl

The first time you launch a distribution, you'll need to create a user account and password.

Pro Tip: Use Windows Terminal for a Better Experience

Windows Terminal supports multiple command-line environments (PowerShell, Command Prompt, Azure CLI, Git Bash, etc.).
It allows you to open multiple tabs and split panes for improved multitasking.
You can fully customize your terminal with color schemes, fonts, background images, and custom keyboard shortcuts.

You can also launch your Linux distribution directly from the Windows Start menu by typing its name, such as "Ubuntu".

Running Linux Commands in Windows

After launching WSL, you can execute Linux commands just like in a standard Linux environment:

ls -la
cd /home
cat /etc/os-release

Installing Linux Packages

Each WSL distribution has its own package manager. For Ubuntu-based distributions, use apt:

sudo apt update && sudo apt upgrade
sudo apt install git curl vim

For Fedora-based distributions, use dnf:

sudo dnf install nano wget

Accessing Windows Files from WSL

WSL allows seamless file sharing between Windows and Linux. To access Windows files from WSL:

cd /mnt/c
ls

This maps the Windows C: drive to /mnt/c, enabling file access between the two environments.

WSL 1 vs WSL 2: Key Differences

Feature	WSL 1	WSL 2
System Call Compatibility	Partial	Full
File I/O Performance	Faster for Windows-to-Linux operations	Faster for Linux-to-Linux operations
Uses a Linux Kernel	No	Yes
Virtual Machine Integration	No	Yes
Docker Support	Limited	Fully Supported

Recommendation: Use WSL 2 for better performance and full Linux kernel support, especially if you plan to run Docker or complex Linux workloads.

Advanced WSL Features

Using WSL with Docker

WSL 2 greatly enhances Docker’s performance. To integrate Docker with WSL:

Install Docker Desktop.
Enable WSL 2 support in Docker settings.
Run the following command to verify installation:

docker run hello-world

Real-World Use Cases

Web Development: Run Node.js, Python, and other web frameworks natively in Linux.
DevOps & Cloud Engineering: Use WSL for Kubernetes, Terraform, Ansible, and CI/CD workflows.
Security & Penetration Testing: Install Kali Linux on WSL for ethical hacking and security research.
Machine Learning & Data Science: Run Jupyter notebooks and ML libraries with native Linux support.

Troubleshooting Common Issues

Issue: "WSL Not Recognized"

Solution: Ensure WSL is enabled by running:

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart

Issue: "No Internet Access in WSL"

Solution: Restart the WSL network adapter:

wsl --shutdown
netsh winsock reset

Then restart WSL and check network connectivity.

Issue: "Docker Not Working with WSL 2"

Solution: Ensure that WSL integration is enabled in Docker Desktop settings under "Resources > WSL Integration."

Conclusion

WSL is a powerful tool that bridges Windows and Linux, providing developers and IT professionals with the best of both worlds. By following this guide, you should now have a solid understanding of how to install, configure, and use WSL effectively. Happy coding!

[Boost]

David Oyewole — Mon, 24 Mar 2025 15:05:10 +0000

Mastering Kubernetes Persistent Volumes: A Simplified Beginner Guide

David Oyewole ・ Mar 21

#devops #kubernetes #cloudcomputing #docker

Mastering Kubernetes Persistent Volumes: A Simplified Beginner Guide

David Oyewole — Fri, 21 Mar 2025 12:15:17 +0000

Introduction

In a traditional containerized environment, storage is ephemeral—meaning that when a pod is restarted, all its data is lost. This happens because container file systems are temporary and tied to the pod's lifecycle. This is a major challenge for stateful applications like databases and file storage systems that hold important data and information.

Kubernetes solves this issue by providing Persistent Volumes (PV) and Persistent Volume Claims (PVC), ensuring data persistence even when pods restart or move between nodes. This ensures that data remains persistent and secure.. In this article, I will guide you through how Persistent Volumes work, how to configure them, and best practices for managing persistent storage in Kubernetes, with a complete practical guide.

Understanding Persistent Volumes in Kubernetes

Why Do We Need Persistent Volumes?

By default, Kubernetes pods use ephemeral storage, which means:

When a pod restarts or gets rescheduled to another node, its data is lost.
Stateful applications (e.g., databases like MySQL, MongoDB) require persistent storage.
Persistent Volumes provide a way to separate storage from pods, allowing data to persist beyond the lifecycle of a pod.

What is a Persistent Volume (PV) and a Persistent Volume Claim (PVC)?

Persistent Volume (PV): A physical storage resource in the cluster, provisioned by administrators or dynamically created using Storage Classes.
Persistent Volume Claim (PVC): A request from a pod to use a Persistent Volume.
StorageClass: Defines how storage should be dynamically provisioned by the cloud provider or local storage.

How Persistent Volumes Work

Administrator creates a Persistent Volume (PV) with a specified storage size and access mode.
A pod requests storage by creating a Persistent Volume Claim (PVC).
Kubernetes binds the PVC to an available PV.
The pod mounts the Persistent Volume and uses it for storage.

Persistent Volume Provisioning: Static vs Dynamic

Static Provisioning: The cluster administrator manually creates a Persistent Volume (PV) before any pod requests storage.

Dynamic Provisioning: Kubernetes automatically provisions storage when a pod creates a Persistent Volume Claim (PVC) using a StorageClass.

Creating a Persistent Volume and PVC (Hands-on Guide)

In this practical guide, I will be using MongoDB and Mongo Express (a UI for MongoDB) to demonstrate how to use Persistent Volumes. This example is tested on a Minikube cluster, so ensure your Minikube is running.

Since we will be using local storage to persist data, we need to create a storage path in Minikube. This storage path will be used to create our Persistent Volume (PV).

minikube ssh
sudo mkdir -p /data/mongodb
sudo chmod 777 /data/mongodb
exit

This will create the directory and grant the necessary permissions. Now, we can proceed to create the PV, PVC, and deployments.

Step 1: Create a Persistent Volume (PV)

apiVersion: v1
kind: PersistentVolume
metadata:
  name: mongodb-pv
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: "/data/mongodb"

Ensure that the hostPath matches the directory created in your Minikube setup.

Step 2: Create a Persistent Volume Claim (PVC)

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

Ensure the storageClassName, accessModes, and storage values match those defined in the PV

After applying these configurations, Kubernetes will bind the PVC to an available PV, allowing the pod to use persistent storage.
Run kubectl get pv and kubectl get pvc after applying the configuration to confirm the binding. The status should look like this:

Step 3: Deploy MongoDB with Persistent Volume

For a real-world use case, let’s deploy MongoDB with a Persistent Volume.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mongo-deployment
  labels:
    app: mongodb
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mongodb
  template:
    metadata:
      labels:
        app: mongodb
    spec:
      volumes:
      - name: mongodb-storage
        persistentVolumeClaim:
          claimName: mongodb-pvc
      containers:
        - name: mongo
          image: mongo
          ports:
            - containerPort: 27017
          volumeMounts:
            - name: mongodb-storage
              mountPath: /data/db
          resources:
            limits:
              cpu: "500m"
              memory: "256Mi"
            requests:
              cpu: "250m"
              memory: "128Mi"
          env:
            - name: MONGO_INITDB_ROOT_USERNAME
              valueFrom:
                secretKeyRef:
                  name: mongo-secret
                  key: username
            - name: MONGO_INITDB_ROOT_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: mongo-secret
                  key: password

Your MongoDB deployment file should look like this but take note of the following.

In the volumes section, the claimName must match the name of your PVC.
In The volumeMounts section, the mountPath is the default mountPath for MongoDB
The env which is the Environment Variables i.e the MONGO_INITDB_ROOT_USERNAME and MONGO_INITDB_ROOT_PASSWORD is stored in a secret file for security purposes, I will write about that in my next article.

Now apply the configuration

Step 4: Deploy Mongo Express as a UI for MongoDB

Now let's deploy Mongo Express

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mongoexpress-deployment
  labels:
    app: mongoexpress
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mongoexpress
  template:
    metadata:
      labels:
        app: mongoexpress
    spec:
      containers:
        - name: mongoexpress
          image: mongo-express
          ports:
            - containerPort: 8081
          resources:
            limits:
              cpu: "500m"
              memory: "256Mi"
            requests:
              cpu: "250m"
              memory: "128Mi"
          env:
            - name: ME_CONFIG_MONGODB_ADMINUSERNAME
              valueFrom:
                secretKeyRef:
                  name: mongo-secret
                  key: username
            - name: ME_CONFIG_MONGODB_ADMINPASSWORD
              valueFrom:
                secretKeyRef:
                  name: mongo-secret
                  key: password
            - name: ME_CONFIG_MONGODB_SERVER
              valueFrom:
                configMapKeyRef:
                  name: mongo-config
                  key: database_url

This is what your Mongo Express deployment should look like, the environment variables are contained in a secret and configMap file as I mentioned earlier.

Step 5: Configure services for communication

For internal and external communication, we need to configure services, MongoDB will use ClusterIP because there will be no need for external communication while Mongo Express will use a Nodeport to give external access.

apiVersion: v1
kind: Service
metadata:
  name: mongo-service
spec:
  selector:
    app: mongodb
  ports:
    - protocol: TCP
      port: 27017
      targetPort: 27017
  type: ClusterIP


---
apiVersion: v1
kind: Service
metadata:
  name: mongoexpress-service
spec:
  selector:
    app: mongoexpress
  ports:
    - protocol: TCP
      port: 8081
      targetPort: 8081
      nodePort: 30000
  type: NodePort

Run kubectl get svc to check your services, it should look like the image below.

Step 6: Minikube Service

Next, we will use Minikube to expose the Mongo Express service, making it accessible from the browser. This will enable us to interact with MongoDB through the UI. Run the command:
minikube service minikube service mongoexpress-service

You can now access Mongo Express from the given IP address. The web page should look like this:

To test this, create databases and collections from the Mongo Express UI. Restart the pods, and you will still have the data intact. This demonstrates how Persistent Volumes work.

Common Issues & Troubleshooting

PVC stuck in "Pending" state?
- Run kubectl describe pvc mongodb-pvc to check events.
- Ensure that a matching PV is available.
- Check if the storageClassName matches between the PV and PVC.
Pod cannot write to storage?
- Ensure the permissions on the host path are correct.
Pod stuck in "ContainerCreating"?
- Verify that the Persistent Volume is properly mounted.
- Run kubectl describe pod <pod-name> for detailed logs.
PV and PVC not bound?
- Check kubectl get pv and kubectl get pvc for status.
Data loss after pod restart?
- Ensure that the volume is mounted correctly.
- Check the reclaim policy (Retain, Delete, Recycle).

Best Practices for Using Persistent Volumes

Use Storage Classes for dynamic provisioning when working with cloud storage providers.
Choose the right access mode (ReadWriteOnce, ReadWriteMany) based on the application's needs.
Set the appropriate reclaim policy (Retain, Delete, Recycle) depending on data retention needs.
Monitor storage usage using Kubernetes metrics and alerts.

Conclusion

Persistent Volumes are essential for running stateful applications in Kubernetes. By using PV, PVC, and Storage Classes, you can ensure that your application data persists beyond pod restarts and rescheduling.

Now that you understand how Persistent Volumes work, try deploying them in your own Kubernetes cluster and see how they enhance data persistence! 🚀

How To Set Up An EC2 Instance on AWS

David Oyewole — Sat, 18 May 2024 15:28:48 +0000

INTRODUCTION

WHAT IS EC2
Amazon Elastic Compute Cloud (Amazon EC2) is a pivotal service within the Amazon Web Services (AWS) suite of products. It functions as a scalable and highly secure virtual server, enabling users to effortlessly host applications without the need for upfront hardware investments. Operating EC2 is convenient, as it can be easily launched and managed from the AWS dashboard. The service encompasses a wide array of computing capabilities and grants users the flexibility to customize specifications such as RAM, ROM, and more. EC2 significantly streamlines the development process by facilitating easy scalability and seamless integration with other services, making it a highly valuable tool for developers and businesses.

WHY USE EC2

Easy to scale up and down.
Remote Access to your assets from anywhere in the world.
Very Secure.
Pay-As-You use i.e. you only pay for what you use.
Easy to set up as no hardware is required.

SETTING UP AN EC2 INSTANCE

Let's take a step-by-step look at how to set up an EC2 instance

Step 1: Log in to your AWS account or create an account Here

Step 2: Click on services by the top left corner or EC2 as shown in the image below, if you click on services, you will need to click on EC2 in the next screen.

Step 3: Click on launch instance button as shown below.

Step 4: Configure the instance, examples are given below

Name the instance

Select the type of OS you want and also the AMI(Amazon Machine Image) you want, take note, and take advantage of the AMI eligible for free-tier if your account is less than a year old. Also, select the Architecture you want.

Select the instance type you want, and also take note of the free-tier eligible ones.

Create a new key pair or select an existing one if you already have one. This key pair will allow you to securely connect to the instance using SSH agents. Click on the create new key pair button.

Input a name, select the key type and key format then click on the Create Key Pair button shown below.

Configure the network settings, select an existing security group, or create a new one and specify the rules.

Configure the storage you want or leave the default one

Click on the Launch Instance button at the bottom left corner.

Step 5: The next screen will take a moment and then show you a success message, click on the instance ID shown in the message to see the state of your instance.

Step 6: Wait for some moments for the instance to initiate, click on the reload button shown below to refresh, and when the status check turns green, your instance is up and running.

Step 7: Click on the instance ID from the screen above, this will take you to the instance summary shown below. Click on the connect button to connect to your instance CLI, you can also connect to the instance using any SSH agent with the key pair we created earlier.

CONCLUSION

This comprehensive article provides a step-by-step guide to simplify the process of launching an EC2 instance. By following the detailed instructions, you will not only be able to launch the instance but also learn how to configure it according to your specific needs and requirements.

Automating LAMP Stack Deployment Using a Bash Script on an Ubuntu Server

David Oyewole — Fri, 17 May 2024 06:12:18 +0000

Introduction
Laravel is a popular free and open-source PHP-based web framework used for building high-end web applications. It is renowned for its expressive and elegant syntax.

In this article, we will deploy a Laravel app on a LAMP stack. LAMP stands for Linux, Apache, MySQL, and PHP. We will automate this deployment with a Bash script. This will not only speed up the deployment but also reduce the errors that might occur in manual deployment, while also ensuring consistency in the deployment process. Let’s go through the process step by step.

Prerequisites

Basic knowledge of Linux and terminal commands
An accessible Ubuntu server instance.
A Laravel application in a GitHub repository.
SSH Access into the Ubuntu server.

Laravel LAMP Automation Process
Step 1: Create a bash script file, I’ll name mine “lamp.sh”.
touch lamp.sh

Step 2: Give the file executable permission.
chmod +x lamp.sh
I will be using vim as my editor you can use nano or any editor of your choice to edit the bash script file.
vim lamp.sh

Step 3: Now we can start writing our bash script, we will be dividing our tasks into functions, this is good for modularity and reusability. First, we declare our shebang
#!/bin/bash

Step 4: let’s write a function to update the repository and a function to install each of the LAMP stack

update_repository() {
    sudo apt update
}

To install apache

install_apache() {
    sudo apt -y install apache2
}

To install MySQL

install_mysql() {
    sudo apt -y install mysql-server mysql-client
}

To install PHP and other PHP extensions required for the deployment, note that I installed PHP 8.2 hence all the extensions must be of the same version, I will also install zip and unzip which are not PHP extensions but will be needed later for composer.

install_php() {
    sudo apt install software-properties-common --yes
    sudo add-apt-repository -y ppa:ondrej/php
    sudo apt update
    sudo apt -y install php8.2 php8.2-curl php8.2-dom php8.2-mbstring php8.2-xml php8.2-mysql zip unzip
}

Step 5: Enable URL rewriting and Restart Apache

enable_url_rewriting() {
    sudo a2enmod rewrite
    sudo systemctl restart apache2
}

Step 6: Write a function to install and setup composer, note that we will do this in the /usr/bin directory

install_composer() {
    cd /usr/bin
    curl -sS https://getcomposer.org/installer | sudo php -q
    if [ ! -f "composer" ]; then
        sudo mv composer.phar composer
    fi
}

Step 7: Write a function to clone the Laravel app from a GitHub repo. Here is a link to the repository Laravel repo, note that this function will also change the ownership of the /var/www directory to the current user.

clone_laravel_repo() {
    sudo chown -R $USER:$USER /var/www
    cd /var/www
    if [ ! -d "laravel" ]; then
       git clone https://github.com/laravel/laravel.git
    fi
}

Step 8: Now we will install composer in the laravel directory which we just cloned.

install_composer_in_project() {
    cd /var/www/laravel
    composer update --no-interaction
}

Step 9: Write a function to configure the .env file.

build_env_file() {
    cd /var/www/laravel
    if [ ! -f ".env" ]; then
        cp .env.example .env
    fi
    sudo php artisan key:generate
    sudo chown -R www-data storage
    sudo chown -R www-data bootstrap/cache

}

Step 10: Write a function to create a new virtual host and use it as the default.

create_apache_config() {
    sudo bash -c 'cat > /etc/apache2/sites-available/laravel.conf <<EOF
<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    ServerName localhost
    ServerAlias localhost
    DocumentRoot /var/www/laravel/public

    <Directory /var/www/laravel/public>
        Options -Indexes +FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/laravel-error.log
    CustomLog ${APACHE_LOG_DIR}/laravel-access.log combined
</VirtualHost>
EOF'

  cd ~
    sudo a2dissite 000-default.conf
    sudo a2ensite laravel.conf
    sudo systemctl restart apache2
}

Step 11: Now we can write a function that will configure our MySQL i.e. create a database and user.

create_database_and_user() {
    sudo systemctl start mysql
    sudo mysql -uroot -e "CREATE DATABASE IF NOT EXISTS laravel;"
    sudo mysql -uroot -e "CREATE USER IF NOT EXISTS 'vagrant'@'localhost' IDENTIFIED BY '1805';"
    sudo mysql -uroot -e "GRANT ALL PRIVILEGES ON laravel.* TO 'vagrant'@'localhost';"

    cd /var/www/laravel
    grep -qF 'DB_CONNECTION=mysql' .env && sed -i 's/DB_CONNECTION=mysql/DB_CONNECTION=mysql/' .env || echo "DB_CONNECTION=mysql" >> .env
    grep -qF 'DB_HOST=localhost' .env && sed -i 's/DB_HOST=localhost/DB_HOST=localhost/' .env || echo "DB_HOST=localhost" >> .env
    grep -qF 'DB_PORT=3306' .env && sed -i 's/DB_PORT=3306/DB_PORT=3306/' .env || echo "DB_PORT=3306" >> .env
    grep -qF 'DB_DATABASE=laravel' .env && sed -i 's/DB_DATABASE=laravel/DB_DATABASE=laravel/' .env || echo "DB_DATABASE=laravel" >> .env
    grep -qF 'DB_USERNAME=vagrant' .env && sed -i 's/DB_USERNAME=vagrant/DB_USERNAME=vagrant/' .env || echo "DB_USERNAME=vagrant" >> .env
    grep -qF 'DB_PASSWORD=1805' .env && sed -i 's/DB_PASSWORD=1805/DB_PASSWORD=1805/' .env || echo "DB_PASSWORD=1805" >> .env

    sudo php artisan storage:link
    sudo php artisan migrate --force
    sudo php artisan db:seed --force
    sudo systemctl restart apache2

}

NOTE: My Database name is laravel, my Username is vagrant and my Password is 1805, you can use values of your choice.

Step 11: Now we can call all our functions as we know functions won’t execute until they are called.

update_repository
install_apache
install_mysql
install_php
enable_url_rewriting
install_composer
clone_laravel_repo
install_composer_in_project
build_env_file
create_apache_config
create_database_and_user

Save the script and exit
Execute the script ./lamp.sh

Load the IP of your server or your domain in your browser and you should have the output below

OUTPUT

Conclusion
By following the steps outlined in this guide, you will be able to streamline the deployment of the LAMP (Linux, Apache, MySQL, PHP) stack through the utilization of a bash script. While it is possible to carry out this process manually, automation offers the advantage of increased speed, consistency, and reduced potential for errors. Furthermore, the bash script can be reused for future deployments, saving time and effort.