DEV Community: Akingbade Omosebi

Opsfolio - From Interview Task to Production: Building a Security-First DevSecOps Platform

Akingbade Omosebi — Tue, 25 Nov 2025 13:09:48 +0000

From Interview Task to Production: Building a Security-First DevSecOps Platform

TL;DR

The Assignment: Deploy a simple app to local Kubernetes

What I Built: A production-grade DevSecOps platform with 6-layer security scanning, FinOps cost tracking, GitOps automation, and complete observability

Result: "Opsfolio" - A hands-on demonstration of how I approach real-world infrastructure challenges

🔗 View the complete repository

The Challenge
The Approach
Security Architecture
FinOps: Cost Intelligence
Automation & GitOps
Technical Implementation
Results & Metrics
Key Takeaways

The Challenge

The interview assignment was straightforward:

✅ Set up a local Kubernetes cluster (kind/minikube/k3s)
✅ Create a Dockerfile
✅ Deploy an application
✅ Bonus: IaC, GitOps, semantic versioning

Simple enough. But I asked myself a different question:

"What would this look like if I built it for production?"

That question changed everything.

The Approach

Instead of building the minimum viable solution, I treated this like a real-world production system with:

Security-first mindset: Multiple scanning layers, zero static credentials
Cost awareness: FinOps integration for visibility before deployment
Full automation: From commit to production with zero manual steps
Observability: Complete monitoring and alerting stack
Documentation: Enterprise-grade docs for every component

Security Architecture

🛡️ Multi-Layer Defense Strategy

Layer 1: CI/CD Security Pipeline (6 Scanners)

1. GitLeaks - Secret Detection

- name: GitLeaks Scan
  uses: gitleaks/gitleaks-action@v2
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Scans entire Git history for exposed secrets (API keys, passwords, tokens).

2. SonarCloud - Static Application Security Testing (SAST)

Achieved: A Security Rating
Detects code vulnerabilities, security hotspots, code smells

3. Snyk Open Source - Software Composition Analysis (SCA)

Scans dependencies for known vulnerabilities
Severity threshold: CRITICAL

4. Snyk Code - SAST

Static code analysis for security issues
Severity threshold: HIGH

5. Trivy - Container Security

- name: Run Trivy scanner
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: 'interview-app:latest'
    severity: 'CRITICAL,HIGH'
    exit-code: '1'  # Blocks pipeline on findings

Shift-left approach: Scans images BEFORE pushing to registry

6. TFSec - Infrastructure as Code Security

Scans Terraform for misconfigurations
Posts findings directly to PRs

7. MegaLinter - Code Quality & Security

Multi-language linting
Auto-fixes via pull requests

Layer 2: Container Hardening

securityContext:
  ## Pod-level security
  runAsNonRoot: true
  runAsUser: 101
  fsGroup: 101

containers:
  - name: interview-app
    securityContext:
      # Container-level security
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL  # Drop all Linux capabilities

    resources:
      # DoS prevention
      limits:
        memory: "512Mi"
        cpu: "500m"
      requests:
        memory: "128Mi"
        cpu: "100m"

Dockerfile Security :

# Minimal Alpine base
FROM nginx:1.29.3-alpine

# OS updates
RUN apk update && apk upgrade

# Non-root user
USER 101

# Non-privileged port
EXPOSE 8080

Layer 3: Network Security :

args:
  - "http"
  - "interview-app-service:8080"
  - "--authtoken"
  - "$(NGROK_AUTH_TOKEN)"
  - "--auth"
  - "myuser:mypassword"        # Basic auth
  - "--allow-cidr"
  - "192.168.0.0/16"            # IP allowlist
  - "--deny-cidr"
  - "5.142.0.0/16"              # IP denylist
  - "--rate-limit"
  - "20:60s"                     # DDoS protection

Features:

✅ TLS encryption (Ngrok)
✅ HTTP Basic Authentication
✅ IP-based access control (CIDR filtering)
✅ Rate limiting (20 requests/60 seconds)
✅ Traffic inspection UI

Layer 4: Secrets Management

Zero Static Credentials Strategy:

AWS OIDC Authentication (No long-lived keys)

- name: Configure AWS Credentials
  uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
    aws-region: us-east-1

Bitnami SealedSecrets (Encryted at rest)

apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  name: grafana-admin-secret
  namespace: monitoring
spec:
  encryptedData:
    admin-user: AgBxgB9cmAMxkypRMT5b5N7T...
    admin-password: AgB6DRmxAXK6Ot1c9Pn7XnZr...

Terraform Cloud (Encrypted State Backend)

Results: 100% encrpyted secrets, zero plaintext anywhere.

FinOps: Cost Intelligence

💰 Infracost Integration

The Problem : Teams deploy infrastructure, then get surprised by AWS bills.

The Solution : Cost visibility BEFORE deployment.

- name: Generate Infracost JSON
  run: |
    infracost breakdown \
      --path . \
      --format json \
      --out-file infracost.json

- name: Post Infracost Comment on PR
  uses: infracost/actions/comment@v1
  with:
    path: infracost.json
    behavior: update

Example PR Comment:

💰 Monthly Cost Estimate

| Resource | Monthly Cost | Change |
|----------|--------------|--------|
| aws_eks_cluster.main | $73.00 | +$73.00 |
| aws_eks_node_group (t3.small) | $15.00 | +$15.00 |
| aws_nat_gateway (x2) | $65.00 | +$65.00 |
| **Total** | **$153.00** | **+$153.00** |

💡 Cost Optimization Opportunities:
- Use spot instances for node group (save ~70%)
- Single NAT gateway for non-production (save $32.50/mo)

Business Impact : Infrastructure decisions become data-driven, not guesswork.

Automation & GitOps

🚀 Complete Release Automation

Semantic Release Configuration :

// .releaserc.js
module.exports = {
  branches: ['main'],
  plugins: [
    '@semantic-release/commit-analyzer',
    '@semantic-release/release-notes-generator',
    ['@semantic-release/changelog', { 
      changelogFile: 'CHANGELOG.md' 
    }],
    ['@semantic-release/exec', {
      prepareCmd: 'echo ${nextRelease.version} > VERSION.txt'
    }],
    ['@semantic-release/git', {
      assets: ['CHANGELOG.md', 'VERSION.txt']
    }],
    '@semantic-release/github'
  ]
};

Commit Convention:

feat: add new feature        # → Minor version bump (1.0.0 → 1.1.0)
fix: resolve bug             # → Patch version bump (1.0.0 → 1.0.1)
BREAKING CHANGE: ...         # → Major version bump (1.0.0 → 2.0.0)

Result : Automated versioning, changelog generation, and GitHub releases

ArgoCD GitOps

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: interview-app
  namespace: argocd
spec:
  syncPolicy:
    automated:
      prune: true      # Remove deleted resources
      selfHeal: true   # Auto-correct drift
  source:
    repoURL: https://github.com/AkingbadeOmosebi/Opsfolio-Interview-App
    path: k8s
    targetRevision: HEAD

Features:

✅ Continuous deployment from Git
✅ Self-healing (automatic drift correction)
✅ Image Updater with semver constraints
✅ Complete audit trail

Technical Implementation
Dual Environment Strategy

Local Environment (K3s)

# Install K3s
curl -sfL https://get.k3s.io | sh -

# Deploy application
kubectl apply -f k8s/

# Deploy monitoring
kubectl apply -f k8s/monitoring/prometheus-app.yaml

Purpose : Cost-free validation and prototyping

Cloud Environment (AWS EKS)

Terraform Infrastructure:

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "~> 20.0"

  cluster_name    = "opsfolio-cluster"
  cluster_version = "1.31"

  vpc_id     = module.vpc.vpc_id
  subnet_ids = module.vpc.private_subnets

  eks_managed_node_groups = {
    main = {
      min_size     = 1
      max_size     = 3
      desired_size = 2
      instance_types = ["t3.small"]
    }
  }
}

Security Features :

Private VPC subnets for nodes
IAM to Kubernetes RBAC mapping
TFSec scanning before deployment
OIDC authentication (no static keys)

Results & Metrics

📊 Measurable Outcomes

Metric	Result
SonarCloud Security Rating	A
Critical Vulnerabilities	0 (Snyk + Trivy)
Secrets Encrypted	100%
Static Credentials	0 (Full OIDC)
CI/CD Security Scanners	6
Automated Releases	Yes (Semantic)
Cost Visibility	Pre-deployment

Key Takeaways

What This Project Demonstrates

Defense-in-Depth Security

Not one tool, but 6 scanning layers
Container hardening at multiple levels
Network-level access controls
Zero static credentials anywhere

FinOps as Code

Cost estimation before deployment
Optimization recommendations in PRs
Data-driven infrastructure decisions
Complete Automation

Semantic versioning

Auto-generated changelogs
GitOps continuous deployment
Self-healing infrastructure

Production Thinking

Not "does it work?" but "is it production-ready?"
Observability from day one
Documented for team scalability
Cost-conscious engineering

The Difference

Junior approach: Meet the requirements
Senior approach: Understand WHY production systems need security, observability, cost controls, and automation—then implement them

This project is my answer to: "How do you build production-ready infrastructure?"

Explore the Repository

🔗 GitHub Repository

What's Inside:

Complete source code
Architecture diagrams (visual + ASCII)
Step-by-step implementation guides
Component deep-dives
CI/CD workflows
Kubernetes manifests
Terraform infrastructure code

Documentation:

Architecture Overview
Local Setup Guide
Cloud Infrastructure Setup
CI/CD Workflows

Let's Connect

Found this helpful? Questions about the implementation?

⭐ Star the repo
💬 Open an issue for questions
🔄 Share with your network

What production practices do you prioritize in your infrastructure? Drop a comment below!

devops #kubernetes #devsecops #aws #finops #terraform #security #gitops #cicd #infrastructure

🏁 From Code to Cloud: My DevOps + DevSecOps Journey (Part 4/4 - The Reflection and Possible Routes)

Akingbade Omosebi — Fri, 29 Aug 2025 11:42:37 +0000

Part 4 – Lessons Learned and Takeaways

In Part 3 I explained how I used Terraform and Terraform Cloud to provision Azure infrastructure while keeping security at the core.

Now, it’s time to wrap up this series with some real talk: what went wrong, what went right, and what I learned along the way.

⚠️ The Struggles

Let’s be honest! This wasn’t smooth sailing.

SonarCloud kept failing → My app was just HTML/CSS/JS, so SonarCloud gave me 0% test coverage. At first, that meant failed pipelines, which was frustrating.
Docker “latest” confusion → I thought every push would create a new image version in ECR. Wrong. Without unique tags, I couldn’t track versions or roll back easily.
Trivy misconfigurations → My first vulnerability scans failed because I didn’t reference the full ECR image path. Rookie mistake, but it cost me time.
Secret management headaches → Hardcoding secrets was a no-go. Finding the right balance between Terraform Cloud, GitHub Actions, and AWS credentials took trial and error.

Every failure made me slow down, rethink, and fix things the right way.

✅ The Wins

Despite the bumps, here’s what I walked away with:

A fully automated CI/CD pipeline for my portfolio app
Cross-cloud integration: AWS ECR → Azure Container Apps
Security-first approach with SonarCloud, TFSEC, and Trivy
Infrastructure fully managed as code with Terraform
Secrets handled safely using Terraform Cloud sensitive variables

The app itself? Just a simple portfolio.
But the pipeline? Enterprise-grade.

As at writing this documentation blog, the deployment was 100% functional, fired by Github actions, and deployed by Terraform Cloud.

Last screenshots.

Before destroying project.

As to everything, it has an end. While this isn't the total end, it's just a milestone with it, the beginning of a newer and more sophisticated challenge. More is coming!!

💡 Key Lessons Learned

Looking back, here are the big takeaways from this journey:

Even a static app can teach you real DevOps.
It’s not about the complexity of the code — it’s about how you build, ship, and secure it.
Always version your Docker images.
Using Git commit SHAs as tags solved so many headaches and gave me rollback safety.
Security isn’t an afterthought.
TFSEC and Trivy forced me to think like a DevSecOps engineer. Better to fix issues now than explain them later.
Secrets should never live in repos.
Terraform Cloud’s sensitive variables saved me from bad practices and kept everything professional.
Documentation is part of DevOps.
This Dev.to series itself is proof. If you can’t explain what you built, it’s almost like it doesn’t exist.

🚀 What’s Next?

This project was just the beginning. If I were to extend it, I’d:

Add monitoring & observability (Prometheus, Grafana, or Azure Monitor)
Deploy to multiple environments (staging + prod) with approval gates
Write basic tests for my JavaScript to make SonarCloud happier
Add a rollback strategy in the pipeline (in case a deploy fails)

Each of those would push this portfolio pipeline even closer to what real-world production systems look like.

🎯 Final Thoughts

I started this journey wanting “just a portfolio site.”
But I ended up building something much more:

A CI/CD pipeline
A multi-cloud deployment
A DevSecOps showcase

The biggest lesson?

👉 You don’t need a big app to prove your skills. You just need discipline, automation, and security woven into your process.

This wasn’t just about HTML, CSS, and JS.
It was about showing that I can think, build, and operate like a DevOps engineer.

And that’s the story behind my portfolio.

Feel free to check out my Repo

Thank you for reading.

Feel free to like, leave a comment and share.

🌍 From Code to Cloud: My DevOps + DevSecOps Journey. (Part 3/4 - The Execution)

Akingbade Omosebi — Fri, 29 Aug 2025 11:34:42 +0000

Part 3 – Terraform and Secure Cloud Infrastructure

In Part 2, I showed how my GitHub Actions pipeline automated builds, scans, and deployments for my portfolio app.

Now it’s time to talk about infrastructure — the piece that made everything real in the cloud.

🛠️ Why Terraform?

I could have clicked buttons in the Azure portal and spun up resources manually. I mean I have already done that in the past before and that would also defeat the whole purpose, I wanted something different, a different challenge without straying from my main goal.

The goal of this project was to showcase DevOps discipline:

Repeatable deployments (no “...but it works or worked on my machine”)
Version-controlled infrastructure (IaC mindset)
Security baked in (no leaking secrets in YAML files)

That’s why I chose Terraform.

🚀 The Infrastructure

Here’s what I needed for my app to live in the cloud:

Azure Container App → the service to run my Dockerized portfolio
Resource Group & Networking → to organize and isolate resources
Terraform Cloud → remote state storage & secure variable management

Notice something? I didn’t use Azure Container Registry (ACR).
Instead, I built my images in GitHub Actions and pushed them to AWS ECR.
Why? Because it showed I could integrate AWS + Azure in one pipeline — To showcase a multi-cloud DevSecOps project. A valuable real-world skill.

Provisioned Resource Group and Container App

Terraform Cloud Run Sequence Triggered by GITHUB Actions to provision resources. Status: Successful!

💰 Cost Estimation in Terraform Cloud

But did you also pause to notice something?

One underrated feature of Terraform Cloud is Cost Estimation. Every time a terraform plan runs in TFC, it doesn’t just show what resources will change — it also estimates the monthly cloud bill of those changes.

For example, this simple VM resource:

resource "azurerm_linux_virtual_machine" "myvm" {
  name                = "vm1"
  size                = "Standard_B2s"
  admin_username      = "adminuser"
  resource_group_name = azurerm_resource_group.rg.name
  location            = azurerm_resource_group.rg.location
  network_interface_ids = [
    azurerm_network_interface.myvm_nic.id,
  ]
}

Might give me an output like:
Cost estimate: +$24.50/month

This is huge because it helps avoid surprise cloud bills and keeps infra spending predictable. On bigger teams, you can even enforce policies (e.g., block applies if cost > $100/month).

👉 Lesson learned: Don’t just plan for resources, plan for costs. Infrastructure as Code is also Finance as Code.

🔑 Secret Management with Terraform Cloud

One of the trickiest parts was handling secrets.

Terraform needed:

My ECR authentication token (from AWS)
My Azure credentials (to deploy resources)

I refused to hardcode them anywhere.

👉 My solution: store them as sensitive variables inside Terraform Cloud.
That way:

They were encrypted
Not visible in logs
Automatically injected into Terraform runs

Terraform ENV Variables configured and set for Authentication to ECS & Deployment to Azure

This gave me a secure, enterprise-style workflow without having to build a full secret management system.

You can get the ECR Auth Token from AWS using the following command:

aws ecr get-login-password --region region

🛡️ Security Checks with TFSEC

Terraform is code — which means it can also have vulnerabilities.

For example:

Misconfigured networking rules
Exposed storage accounts
Overly permissive IAM roles

To catch these, I integrated TFSEC into my pipeline.
Every time Terraform code ran, TFSEC checked it against security best practices.

This meant my IaC wasn’t just functional — it was hardened.

📜 A Simplified Terraform Snippet

Here’s a safe example (trimmed down for clarity) of how I deployed my Azure Container App:

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "rg" {
  name     = "portfolio-rg"
  location = "West Europe"
}

resource "azurerm_container_app" "portfolio" {
  name                = "portfolio-app"
  resource_group_name = azurerm_resource_group.rg.name
  container_app_environment_id = azurerm_container_app_environment.env.id

  template {
    container {
      name   = "portfolio"
      image  = "ACCOUNT_ID.dkr.ecr.eu-west-1.amazonaws.com/portfolio:${var.image_tag}"
      cpu    = 0.5
      memory = "1.0Gi"
    }
  }
}

Notice the image is pulled from AWS ECR — not ACR.
This cross-cloud integration was a deliberate choice to highlight flexibility.

✅ The Result

When everything was wired up, here’s what I got:

A Dockerized portfolio app running on Azure Container Apps
Fully managed via Terraform IaC
Secrets stored securely in Terraform Cloud
IaC continuously scanned with TFSEC
Container image scanned with Trivy

Docker build with Trivy Image Scanner.

This setup wasn’t about having the fanciest app.
It was about** proving I could deploy apps securely, consistently, and across multiple clouds.**

Final Application up and running from the Container App Live. Fully automated to make deployment changes based upon new image build

💡 Why This Matters

Employers don’t just want someone who can write code.
They want engineers who can:

Deploy infrastructure securely
Work across multi-cloud environments
Use IaC for repeatability and control
Integrate security scanning into DevOps (aka DevSecOps)

That’s what this part of the project showed.

🚀 Next Up

In Part 4, I’ll share the biggest lessons learned along this journey: the frustrations, the wins, and how I’d improve this pipeline even further.

Stay tuned! Because that’s where it all comes together.

Click here to view the final part. Part 4 ➡️

⚙️ From Code to Cloud: My DevOps + DevSecOps Journey (Part 2/4 - The Automation Obstacles)

Akingbade Omosebi — Fri, 29 Aug 2025 11:03:10 +0000

Part 2 – Automating the Pipeline

In Part 1 of this series, I explained how I wanted my personal portfolio to be more than just a few HTML files sitting on GitHub Pages.

I wanted it to behave like a production-grade application: built, scanned, and deployed automatically with security woven into the process.

This is the part where things got interesting — the pipeline.

🏗️ The App Itself

Let’s keep it real: my app is not a full-stack system.

It’s a portfolio website — plain and simple.

HTML for structure
CSS for styling
JavaScript for a little interactivity

That’s it.

But what made it special was how I treated it:

I Dockerized it using an NGINX base image to serve static files.
I pushed that image to AWS Elastic Container Registry (ECR).
Then, I deployed it to Azure Container Apps using Terraform.

Even though the app was static, the pipeline was dynamic.

🔄 The Pipeline Workflow

Here’s how the GitHub Actions workflow was designed:

Checkout code from GitHub
Build Docker image (NGINX serving my HTML/CSS/JS)
Tag and push the image to AWS ECR
Run security scans:
- Trivy → scan Docker image for vulnerabilities
- TFSEC → scan Terraform code
- SonarCloud → check code quality
Deploy with Terraform to Azure Container Apps

⚠️ The Roadblocks

It wasn’t smooth sailing at first.
Here are some of the biggest challenges I hit:

SonarCloud Failures

Initially it was configuration issue, till i understood it clearly and passed its project key, token, and needs into Repo-Env-Secrets & Variables.
Then next; SonarCloud kept failing the Quality Gate.
Why? Because my project had no backend logic — just HTML, CSS, and JS.
That meant 0% test coverage (and SonarCloud hates that).

👉 My fix: I kept SonarCloud in the pipeline, but marked it so failures didn’t block the build.
That way, I still got visibility on quality checks, but my deployments weren’t stopped.

SonarCloud Failed due to 0% test coverage, since my app doesnt have any actual complex logic. Nonetheless, it doesnt change the fact that SonarCloud scanner was integrated and showcases my potential.

Here is a simple SonarCloud workflow you can get your hands dirty with, to get started on your next project.

name: "sonar_cloud_scan_github_actions"
on:
  workflow_dispatch:

jobs:
  DemoSonarCloudSCan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
            fetch-depth: 0
      - name: SonarCloud Scan
        uses: sonarsource/sonarcloud-github-action@master
        env:
            GITHUB_TOKEN: ${{ secrets.GIT_TOKEN }}
            SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
        with:
          args: >
              -Dsonar.organization=rekhugopal
              -Dsonar.projectKey=SonarCloudCodeAnalyisis
              -Dsonar.python.coverage.reportPaths=coverage.xml

It is a manual trigger workflow, change it to automatic by modifying it to something like this for both a push and when a PR is opened:

name: "sonar_cloud_scan_github_actions"

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

Also, ensure to pass in the appropriate keys, variables and tokens in Actions or Github Env Variables.

Docker “latest” Tag Problem

At first, I tagged my image as latest.
The issue? If nothing in the image changed, ECR wouldn’t show a new version.
It felt like my push was “skipped,” even though the workflow ran.

👉 My fix: I switched to unique tags using Git commit SHA.
Here is my code block for that from my actions.

docker build -t my-portfolio:${{ github.sha }} .
docker push my-portfolio:${{ github.sha }}

This way, every commit created a brand new image version in ECR.
No confusion, easy rollback.

Trivy Misconfiguration

My first Trivy scan failed with an invalid image reference error.
I had forgotten to include the repository name before the image hash.

👉 My fix: I updated the scan step to reference the full ECR image path.
Once fixed, Trivy scanned the image and reported vulnerabilities clearly.

It was at this point, I had to make each workflow modular, and seperate to be able to isolate without messing up each workflow or pipeline. Segmenting it made me focus like a laser! And it work like a charm!

Terraform Secrets

Terraform needed my ECR token and Azure credentials.
Storing them in plain text was not an option.

👉 My fix: I stored them securely in Terraform Cloud as sensitive variables. That way, I avoided exposing secrets in GitHub Actions or in my repo.

And the rest fix were properly passing in the right ENV values without human errors such as Spaces, Upper-cases, or Additional characters, for The Pipeline to pick up the right Secret Envs since I did not want to "Hardcode" any value or Secrets (See Screenshot below).

✅ The Working Pipeline

After fixing those issues, my pipeline looked like this:

Commit to GitHub
       ↓
 GitHub Actions kicks off
       ↓
 Build Docker image (NGINX + portfolio files)
       ↓
 Push image to AWS ECR (tagged with commit SHA)
       ↓
 Run scans (SonarCloud, TFSEC, Trivy)
       ↓
 Deploy with Terraform to Azure Container Apps

And the best part? Every push = automatic build + scan + deploy.

My ECR Repo images, with each change, commit, and push it is built, tagged, scanned, before being deployed.

💡 Why This Matters

Even though my app is just static HTML/CSS/JS, the pipeline is enterprise-grade.
It shows that:

I can build CI/CD pipelines from scratch
I can integrate security tools (DevSecOps mindset)
I can work across AWS + Azure
I can solve real-world problems like failing quality gates, versioning issues, and secret management.

This is the stuff hiring managers love to see — not just “I can write code,” but “I can run a secure DevOps workflow.”

🚀 Next Up

In Part 3, I’ll walk through the Terraform setup and how I provisioned Azure Container Apps with IaC.

Spoiler: Terraform Cloud made my life much easier, but it came with its own surprises.

Stay tuned.

Click here to view part 3 ➡️

🎬From Code to Cloud: My DevOps + DevSecOps Journey (Part 1/4 – The Vision)

Akingbade Omosebi — Fri, 29 Aug 2025 10:28:06 +0000

A few weeks ago, I decided I didn’t just want another static portfolio site.
I wanted something that tells a story of my skills in action: automation, cloud, DevOps, and security all woven together.

Instead of just pushing some HTML to GitHub Pages, I asked myself:

👉 “What if my portfolio itself became a DevOps project?”

That’s how this whole journey began.

💡The Idea

I wanted a simple app — nothing fancy. Just:

Frontend: HTML + CSS + a bit of JavaScript

Containerized: Docker with NGINX serving my files

But the real magic wouldn’t be in the code.
The magic would be in how it’s built, tested, scanned, and deployed.

🛠️The Tech Stack I Chose

Here’s what I pulled together for the project:

Version Control: GitHub
CI/CD: GitHub Actions
Image Registry: AWS Elastic Container Registry (ECR)
Infrastructure: Terraform (state managed in Terraform Cloud)
Deployment: Azure Container Apps
Security & Quality:
- SonarCloud (code quality & coverage)
- TFSEC (Terraform security scanning)
- Trivy (container vulnerability scanning)

That stack might sound like a lot for a portfolio, but that was the point.
I wanted to treat my personal project as if it were production software.

🎯 The Goal

t the end of the day, here’s what I wanted:

A fully automated pipeline where every git push would:

Build my Docker image
Push it to AWS ECR
Run security scans
Deploy the container to Azure using Terraform Cloud Run call.

All infrastructure managed as code with Terraform
Quality gates in place to enforce DevSecOps practices

Basically:

Commit → Build → Scan → Deploy → Done

⚡ The Challenges I Knew Were Coming

I wasn’t naive. I knew I’d hit roadblocks like:

Failing pipelines when SonarCloud complained about coverage
Docker images not updating in ECR when tagged latest
Terraform secrets and tokens needing secure handling
Security scanners flagging issues I’d have to fix

But that’s the beauty of it, this wasn’t just a coding exercise, it was a learning journey.

🗺️ The Big Picture

Here's the high-level architecture of what i set out to build- All automated:

   GitHub Repo
       |
       v
 GitHub Actions CI/CD
       |
       v
Docker Image Build
       |
       v
 Push to AWS ECR
       |
       v
Security Scans (SonarCloud, Trivy, TFSEC)
       |
       v
 Deploy via Terraform Cloud Run 
       |
       v
 Azure Container Apps
       |
       v
 Live App Running
       |
       v
Manage Terraform State-file Securely on Terraform Cloud.

Every single step has its own story, which i'll break down in this series.

✨ Why This Matters

For me, this wasn’t about just having a portfolio.
It was about proving to myself (and to future employers) that I can:

Build pipelines from scratch
Integrate security into DevOps (a true DevSecOps mindset)
Manage multi-cloud setups (AWS + Azure in one project)
Solve real-world CI/CD issues

This is Part 1 of the series. In Part 2, I’ll dive into the pipeline itself: the YAML, the pain, the failures, and the fixes that brought it to life.

Stay tuned. 🚀

Click here to view Part 2 ➡️

How i built My Own Cloud-Native Monitoring App, From Flask to ECR using Boto3, and EKS using Terraform, then implemented ArgoCD.

Akingbade Omosebi — Tue, 22 Jul 2025 18:45:02 +0000

Tech bros,
We meet again!

I’ve just got my hands dirty lately with something fun and lowkey production-ish: I built 🔧 a simple Python system monitoring web app, containerized it with Docker, shipped it to AWS ECR that was provisioned using Python's Boto3, spun up an EKS cluster with Terraform, deployed it with kubectl, and wired up ArgoCD for full-on GitOps DevOps Operations.

Whole thing got me feeling like a software engineer 🧑‍💻👷🏿‍♂️👷🏿‍♂️ now, sike! Because i am one now! 🙂‍↕️🙂‍↕️

Yeah, Thats right!! my local laptop is basically my mini DevOps playground right now. 🤣🤣

Let's dive into this with phases.

Here is an Architecture diagram i crafted from draw.io, use it as a flow reference.

Phase 1 : My Python Flask Monitoring App

So, let’s start at the very beginning.
I wrote a Python web app that uses psutil, it grabs CPU load, memory usage, disk usage, all that good system info, and displays it with Flask, wrapped with some plain HTML + CSS.
Lightweight, simple, but does the job. ✅✅

Phase 2: Containerize Everything

Next step: Spun up a docker desktop in my local machine,

Whgipped out a Dockerfile with the following config:

FROM python:3.9-slim-buster

WORKDIR /app

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

COPY . .

ENV FLASK_RUN_HOST=0.0.0.0

EXPOSE 5000

CMD ["flask", "run"]

Built the image, spun up the container locally aaand boom!! My app was alive on localhost:5000.

That moment had me smiling like a goat 🐐🐐 cuz I'm the goat!. (see what i did there? 😏).

Phase 3: Pushed the image to AWS ECR

Next up, I didn’t want this image sitting only on my laptop. So I had to put it somewhere, and for some random reason, i thought of google searching other ways to provision resources, i stumbled on boto3, and decided to give it a try, i used boto3 in Python to build out an ECR repository in my AWS account.

import boto3            ## i got it from here, you can also leearn  more from here https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/ecr/client/create_repository.html

ecr_client = boto3.client('ecr')

repository_name = "my-cloud-app-repo"
response = ecr_client.create_repository(repositoryName=repository_name)

repository_uri = response['repository']['repositoryUri']
print(repository_uri)

# I just attempted to do a little with it, and have an idea of how it works, i still prefer my terraform approach, as this requires a lot of API calls, which may delay or throw me off the plan.

Logged in with the CLI, tagged my image, pushed it up to ECR — now my container lives in the cloud where it belongs.

docker push and aws ecr get-login-password were my witnesses.

so far; Python ==> Docker ==> ECR. ✅✅

Stay with me now!! dont go anywhere, keep scrolling!!! 😠

Next up: Part 2! Terraform, EKS and Deployments!!.

💡 Why I’m doing this:
I’m not just playing around!! I actually want recruiters, hiring managers, or whoever’s reading to see that I know how to build something end-to-end.
I understand how code moves from my IDE ➡️ to a container ➡️ to a registry ➡️ to Kubernetes ➡️ and gets managed with GitOps.

If you’re gonna call yourself a Cloud/DevOps engineer, you can talk the talk, but you better walk the talk. So I’m walking it, one cluster at a time. (Admit it, I'm sleek with it)😏😏

Part 2: Terraform + EKS: Bringing My non-existent Cluster to Life

Alright, once my ECR image was chilling safely in AWS, it was time to spin up the big boys playground! "An EKS cluster", the big guns for container orchestration.

No point clicking around in the AWS console, that’s rookie moves.
I went full Infrastructure-as-Code with Terraform, because real engineers automate repeatable pain, not just deployments.

The big boy tools ⚔️⚔️

I wrote my main.tf with two key modules:

The VPC module → pulled from the official terraform-aws-modules/vpc

# VPC MODULE, you can get it from thee official VPC config

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.8.1"

  name = "eks-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["eu-central-1a", "eu-central-1b", "eu-central-1c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]

  enable_nat_gateway = true
  single_nat_gateway = true

  tags = {
    Name = "eks-vpc"
  }
}

The EKS module → terraform-aws-modules/eks

# EKS MODULE: likewise this one too, it pulls from its official EKS config

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

  cluster_name                   = var.cluster_name
  cluster_version                = var.cluster_version
  cluster_endpoint_public_access = true

  # Link to VPC module output
  vpc_id     = module.vpc.vpc_id
  subnet_ids = module.vpc.private_subnets

  eks_managed_node_groups = {
    default = {
      desired_capacity = var.desired_capacity
      max_capacity     = var.max_capacity
      min_capacity     = var.min_capacity

      instance_types = var.node_instance_types
    }
  }

My VPC config gave me 3 AZs, private & public subnets, NAT Gateway; you know, the usual building blocks to keep traffic flowing but tight.

Then the EKS module did the heavy lifting:
It spun up the control plane, worker nodes, IAM roles, the whole shebang.

*** RBAC Headaches 🥀 & IAM Headbutts 💔***
Here’s where the "fun" started >> RBAC.
As you can see, I’m an IAM user (Ak_DevOps), and Kubernetes does not care if your IAM user has AdminAccess in AWS. Cold and Ruthless, it didnt even care that I hadn't eaten while working on this project. 💔💔
K8s RBAC is its own beast. 🧛🧛

So there I was, cluster up, kubectl get nodes… Access Denied.
Can’t list nodes. Can’t touch aws-auth. Nothing. 😫😥

The Fix? The Right AccessEntry!
First, I tried to wire up system:masters.
AWS EKS: “Nah bro, system: prefixes are off-limits.”
Cool cool cool.

So I fixed the Terraform config: instead of shoehorning system:masters, I used an AWS-provided cluster policy AmazonEKSClusterAdminPolicyand associated it properly in access_entries.

A couple terraform apply runs later, my user got mapped, RBAC was finally happy, kubectl get nodes → works. We were good!! 🤝🤝

Sometimes it’s not about who you are, but what policy ARN you carry. 😶‍🌫️😶‍🌫️Lesson learned.

Phase 4: Deploy My App!

With the cluster breathing, it was time to launch my container in its new home.

✅ I wrote deployment.yaml → pointed it to my ECR image.
✅ I wrote service.yaml → exposed it as a LoadBalancer on AWS.
✅ Ran kubectl apply -f → watched pods spin up, nodes pull my image, service get a public IP.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: python-monitoring-app
  labels:
    app: python-monitoring-app
spec:
  replicas: 2  # Running 2 copies so it’s reliable and handles load
  selector:
    matchLabels:
      app: python-monitoring-app
  template:
    metadata:
      labels:
        app: python-monitoring-app
    spec:
      containers:
      - name: monitoring-app
        image: 194722436853.dkr.ecr.eu-central-1.amazonaws.com/my-cloud-app-repo:latest  # My ECR image URL
        ports:
        - containerPort: 5000  # The port my Flask app listens on inside the container
        env:
        - name: FLASK_RUN_HOST
          value: "0.0.0.0"  # Make flask listen on all interfaces, not just localhost
        resources:
          requests:
            memory: "128Mi"  # I added these section, as i want to define the constraint of minimum resources which should be reserve for this container
            cpu: "100m"
          limits:
            memory: "256Mi"  #  maxx resources container can use so it doesnnt hog a lot of cluster memories and slow down the system!!!
            cpu: "200m"
---
apiVersion: v1
kind: Service
metadata:
  name: python-monitoring-service
spec:
  selector:
    app: python-monitoring-app  # tHIS will liink service to pods with this label
  ports:
  - protocol: TCP
    port: 80         # External port people hit to reach the app
    targetPort: 5000 # Internal port your app listens on (fix from 8080)
  type: LoadBalancer # AWS will spin up a real load balancer for me

and my service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: python-monitoring-service
spec:
  type: LoadBalancer
  selector:
    app: python-monitoring-app
  ports:
  - protocol: TCP
    port: 80       # external port
    targetPort: 5000  # container port

Boom! my flask app, alive on the internet, powered by EKS.
One tiny Python script, now scaling in the cloud.

Upcoming: Part 3!! ArgoCD — GitOps or Go Home!

So far:

✅ Python Flask app

✅ Docker + ECR

✅ Terraform VPC + EKS

✅ Deployed via kubectl

Next up: ArgoCD.
How I turned this into a proper GitOps pipeline!! fully automated, push code ➡️ watch the cluster sync ➡️ self-healing infra.

And oh, the Dex server meltdown on t3.small?
Yeah… the late-night detective story deserves its own spotlight.

Part 3!! GitOps the Smart Way: ArgoCD + the Dex Saga

So my Python Flask app was up on EKS. Cool.
But let’s be real! kubectl apply manually? Nah.
This is 2025, not 2015😑.

I wanted proper GitOps! So i needed ArgoCD to watch my Git repo like a hawk and sync changes automatically.
Push code → Argo picks it → deploys → cluster stays true to Git🤞🤞.
Clean, declarative, bulletproof.

Talk about ArgoCD Loyalty to Git!! Not sure you can relate 🤣🤣.

Installaing ArgoCD

I spun up a new argocd namespace:

kubectl create namespace argocd
Then installed ArgoCD with the official manifests:

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

All good, riiiight?

So far so good.
Pods popped up: Application Controller, Repo Server, API Server…
But then came Dex!! ArgoCD’s SSO engine. I call it, "The Humbler" because, boy was i humbled! 😭😭

Dex: The Tiny Pod that Broke my Night🤬🤬

The argocd-dex-server kept dying. CrashLoopBackOff.
Logs? Useless. Google? Meh!!,
AWS forum? All were dead ends!!
Reddit? I found only one person who had the issue one year ago, but he was never answered not resolved, i guess he quitted half-way. Totally excusable!. I started to crash out. I've come too far to fail😭😭

I doubled my nodes: desired_capacity = 3.
No dice.
kubectl describe → oom killed.

Then I did what DevOps folks do when docs fail I took my phone and dialed up Claude (👀).

Solution? Bigger Instances.

Claude said:

“Your t3.small nodes don’t have enough RAM. Dex needs more headroom.”

Fair.

So i tweaked my Terraform:

instance_types = ["t3.medium"]
Re-applied. Watched the nodes drain and come back bigger.
Dex? Back to life instantly😮‍💨😮‍💨.

Sometimes more RAM fixes everything 😮‍💨😮‍💨.

Expose ArgoCD the smart wayy

By default, ArgoCD’s argocd-server is a ClusterIP — internal only.
So I patched it to a LoadBalancer:

kubectl edit svc argocd-server -n argocd
Changed type: ClusterIP → type: LoadBalancer.

A shiny new ELB spun up — now my ArgoCD UI was live!!!

Admin Login

Got the admin password:
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

Loggined in as admin. Changed the passsword.
Safe and sound!!

Connect to GitHub! The GitOps Cycle or Loop, or whatever you want to call it.

I didn’t want to click through the UI to add the repo, because that will reduce the little aura i had left from dex issue 🥲🥲, so I did it the proper way:

Wrote an argo-app.yaml config that points to my GithUb Repo:

# This defines my ArgoCD app: pulls manifests from my GitHub repo, syncs to my EKS cluster, you can also do it console or manual approach too.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-cloud-monitoring-app   # This is the name of my ArgoCD app
  namespace: argocd               # Must match ArgoCD namespace we created earlier
spec:
  project: default

  source:
    repoURL: 'https://github.com/AkingbadeOmosebi/my-cloud-monitoring-app'  # My GitHub repo
    targetRevision: HEAD              # Branch to track (HEAD = default branch)
    path: manifests               # Path to my k8s manifests (deployment and service.yaml) folder inside repo

  destination:
    server: 'https://kubernetes.default.svc'  # EKS cluster endpoint inside ArgoCD
    namespace: default

  syncPolicy:           # This is where it syncs every deployyment
    automated:
      prune: true       # Remove old resources if not in Git anymore
      selfHeal: true    # Revert drift automatically,

Applied it:
kubectl apply -f argo-app.yaml
Watched ArgoCD pick up my deployment.yaml & service.yaml → deploy my app → match desired state.

I could feel a different sensation, it was Aura. Aura was rising from everywhere. 😎😎

The Moment of Truth: Scaling!!

I tested it live:

-Pushed an update to replicas: 2 → Argo synced.

-Changed it to 4 → Argo synced.

-Pushed 6 → Argo synced and spun up 6 pods, just like that.

This is how CD should feel: Hands off, Git is the source of truth, Argo enforces it.
Such a beautiful relationship🥹🥹. I wish mine was like that too 🥲🥲, couldn't even wait for me to scale up 💔🥀.

Anyways, it is what it is!.

Final Thoughts

So yeah, I built and turned:

A Python Flask app
Containerized with Docker
Pushed to ECR
Deployed to EKS (Infra-as-Code with Terraform)
Managed through ArgoCD

Into a real Continuous Deployment pipeline — all my public Git.

Big lessons for recruiters, tech leads and tech ethusiasts reading this:

I don’t just build, I debug.
I don’t fear YAML, I automate with it.
I know how infra works from IAM quirks to cluster IPs.

And when things break at 2AM? I figure it out, and document it so the next version is better and sleep at 3:30AM 😃😃.

If you read this far, just pause and imagine. Imagine what I can do for your team when it’s not just me in the dark with Dex. 🔥

Outro or Perhaps What’s Next?

This wasn’t just another “Hello World on Kubernetes”.

I built, broke, fixed, tuned, automated, scaled, then wrapped it all in GitOps so it runs itself.
And I made mistakes on purpose (well… some😅) so I could really understand what’s happening under the hood 🌚.

Next up?

Templating my manifests with Helm.
Adding Ingress with cert-manager and SSL.

-Maybe wire up Prometheus & Grafana to watch my app’s real CPU + RAM usage.

And of course, more Terraform modules to make this repeatable for any project.

Why Does This Matter?

I’m not here to memorize commands, I understand why they break.

I’m not scared of IAM, K8s RBAC, or AWS networking.

I automate the boring stuff so I can focus on shipping value.

##Let’s Connect 💬
I’m open to DevOps, Platform Engineering, SRE or Cloud Native roles where:
✅ Cloud + K8s + Terraform are the daily bread
✅ GitOps, automation & CI/CD aren’t just buzzwords
✅ And people actually share what they learn

If this sounds like your kind of crew, lets talk.
Or just drop a comment to geek out about EKS, ArgoCD, or your weirdest CrashLoopBackOff story. I love hearing them all.

📌 Check the full project repo: my-cloud-monitoring-app

🔗 Connect with me on Linkedin

Deploying a Fully Functional Multi-AZ WordPress App on AWS ECS + RDS with Terraform & Spacelift.

Akingbade Omosebi — Thu, 17 Jul 2025 17:32:59 +0000

Hey everyone! I’m Akingbade Omosebi, and I like turning ideas into real, production-grade level infrastructure.

This post breaks down exactly how I deployed a WordPress app on AWS ECS, using RDS for storage, an ALB, a multi-AZ VPC, and full CI/CD via Spacelift.

It’s practical, minimal fluff, and everything here was built, tested, and verified, you’ll see my real console screenshots to prove it.

What you’ll see here

How I split my VPC into Public & Private Subnets across multiple AZs.
How ECS, ALB, and RDS fit together.
Why security groups matter, and how I designed them.
How the Terraform files are split, no monolith .tf mess.
How I ran it first locally, then automated it on Spacelift with secrets.
Architecture diagram + real deployment screenshots.

What’s my goal?

A WordPress app that:

Runs in multiple Availability Zones.
Gets traffic through an Application Load Balancer.
Stores all posts/users in a MySQL RDS database in Private Subnets.
Fully version-controlled and deployed through Spacelift.

Why multi-AZ?
If one AZ goes down, ECS and RDS keep the site alive

Overall Architecture.

Here's my high level arhitecctural diagram which i created on draw.io

Key parts:

Public Subnets hold the ALB + ECS Tasks.
Private Subnets hold the RDS DB.
IGW lets Public Subnets connect out.
Security Groups lock down who talks to who.

VPC, Subnets & Internet Gateway

VPC: 10.0.0.0/16
Public SUbnets:
- 10.0.1.0/24 in eu-central-1a
- 10.0.2.0/24- in -eu-central-1b
Private Subnets:
- 10.0.3.0/24 in eu-central-1a
- 10.0.4.0/24 in eu-central-1b

*Why seperate? *
Public Subnets have IGW for inbound HTTP. Private Subnets stay internals, RDS has no direct Internet pathwayy.

Here is my terraform resource block code for my VPC, i liken it to my whole network block or network playground:

# -------- VPC --------
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16" # This means: our entire VPC has a lot of IPs, approx 65k or slightly moore
  tags = {
    Name = "${var.project_name}-vpc"
  }
}

Here is my resource block code for one of my ssubnets, which are like little fenced yards within my vpc:

# -------- Public Subnets --------

# Subnet 2 in eu-central-1b
resource "aws_subnet" "public_2" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.2.0/24" # Next block, 256 IPs
  availability_zone       = "eu-central-1b"
  map_public_ip_on_launch = true

  tags = {
    Name = "${var.project_name}-public-2"
  }
}

Here is for my Internet Gateway, that lets traffic in and out.

# -------- Internet Gateway --------
resource "aws_internet_gateway" "igw" {
  vpc_id = aws_vpc.main.id
  tags = {
    Name = "${var.project_name}-igw"
  }
}

To view the rest of the VPC, check out my GitHub Repo Link WordPress GitHub Repo

Security Groups

ALB SG: Inbound 80 from anywhere.
ECS SG: Inbound only from ALB SG.
RDS SG: Inbound on 3306 only from ECS SG.

This means the following, just as i illustrated in the diagram:

Traffic comes in via ALB.
ALB talks to only ECS.
Only ECS talks to RDS!!.
Nothing else has direct DB access, especially as DB ought to be private always.

ECS Fargate Cluster & Service

One Cluster, multi-AZ.

One Service, desired count = 2 Tasks. (i wanto two tasks like replicas in k8s to be up)

Task Definition: is typically used within the ECS to define or run the official WordPress image, and is mapped to port 80 from its image (wrodpress image). You can get your images from ECR public imagess or from Dockerhub images!.

Here is my Task Definition code blocks from my ECS:

# -------- ECS Task Definition --------
# This is the 'recipe' for your WordPress container
resource "aws_ecs_task_definition" "wordpress" {
  family                   = "${var.project_name}-task"
  network_mode             = "awsvpc"    # Needed for Fargate
  requires_compatibilities = ["FARGATE"] # We use Fargate, no EC2 to manage
  cpu                      = 512         # 0.5 vCPU
  memory                   = 1024        # 1 GB
  execution_role_arn       = aws_iam_role.ecs_task_execution_role.arn

  container_definitions = jsonencode([
    {
      name      = "wordpress"
      image     = "wordpress:latest" # Official WordPress image from Docker Hub, you can also put ECR public WordPress image here
      essential = true

      portMappings = [
        {
          containerPort = 80
          hostPort      = 80
        }
      ]

      environment = [
        {
          name  = "WORDPRESS_DB_HOST"
          value = aws_db_instance.wordpress.address
        },
        {
          name  = "WORDPRESS_DB_USER"
          value = var.db_username
        },
        {
          name  = "WORDPRESS_DB_PASSWORD"
          value = var.db_password
        },
        {
          name  = "WORDPRESS_DB_NAME"
          value = var.db_name
        }
      ]
    }
  ])
}

And here is my ECS Service code block as well:

# -------- ECS Service --------
# Keeps tasks alive & hooks them to ALB
resource "aws_ecs_service" "wordpress" {
  name            = "${var.project_name}-service"
  cluster         = aws_ecs_cluster.main.id
  task_definition = aws_ecs_task_definition.wordpress.arn
  launch_type     = "FARGATE"
  desired_count   = 2 # 2 containers for high availability, 1 is for just one only, but for production you should have at least 2 or more

  network_configuration {
    subnets = [
      aws_subnet.public_1.id,
      aws_subnet.public_2.id
    ]
    security_groups  = [aws_security_group.ecs_sg.id]
    assign_public_ip = true # Needed since we’re in public subnets
  }

  load_balancer {
    target_group_arn = aws_lb_target_group.main.arn
    container_name   = "wordpress"
    container_port   = 80
  }

  depends_on = [aws_lb_listener.http] # Make sure ALB listener exists first
}

To view the rest of the VPC, check out my GitHub Repo Link WordPress GitHub Repo

My ALB & Target Group

My ALB covers across both Public Subnets.
My target group uses ip type (not instance needed for awsvpc mode).
Listener forwards HTTP requests to the ECS Tasks.

Mapped out Target group resources, showing its relevant connections are in place and active.

Dashboard shows everything is healthy and good, based upon the success codes, both replicas are in great shape.

Health Checks by the ALB, it sends requests every 30 seconds to get responses, its acceptable response code is 200-399 Max, else it assumes it is unhealthy and switches to the next replica which is provisioned.

Here are some code blocks taken from my ALB.tf file

# -------- ALB --------
resource "aws_lb" "main" {
  name               = "${var.project_name}-alb"
  internal           = false # false = internet-facing
  load_balancer_type = "application"

  security_groups = [aws_security_group.alb_sg.id]
  subnets = [
    aws_subnet.public_1.id,
    aws_subnet.public_2.id
  ]

  tags = {
    Name = "${var.project_name}-alb"
  }
}

My Target Group code block:

 # -------- ALB Target Group --------
# This is like the guest list — who can receive traffic from the ALB
resource "aws_lb_target_group" "main" {
  name     = "${var.project_name}-tg"
  port     = 80
  protocol = "HTTP"
  vpc_id   = aws_vpc.main.id
  target_type = "ip"


  health_check {
    path                = "/"
    protocol            = "HTTP"
    matcher             = "200-399"
    interval            = 30
    healthy_threshold   = 2
    unhealthy_threshold = 2
  }

  tags = {
    Name = "${var.project_name}-tg"
  }
}

And from my listener code block:

# -------- ALB Listener --------
# This listens on port 80 and forwards traffic to our target group (ECS tasks)
resource "aws_lb_listener" "http" {
  load_balancer_arn = aws_lb.main.arn
  port              = 80
  protocol          = "HTTP"

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.main.arn
  }
}

To view the rest of the files, check out my GitHub Repo Link WordPress GitHub Repo

My RDS: The DB Layer

-MySQL DB.
-Multi-AZ standby.
-Lives in Private Subnets only.
-ECS connects using private DNS endpoint.

Here is some code blocks from my rds.tf file:

# -------- RDS MySQL Instance --------
resource "aws_db_instance" "wordpress" {
  identifier             = "${var.project_name}-db" # Unique name for my db
  allocated_storage    = 20              # 20 GB storage for DB
  storage_type         = "gp2"           # General Purpose SSD
  engine               = "mysql"         # DB engine
  engine_version       = "8.0"           # MySQL version
  instance_class       = "db.t3.micro"   # Smallest cheap instance for demo
  db_name              = var.db_name     # DB name from variables.tf
  username             = var.db_username # Master user
  password             = var.db_password # Master password
  db_subnet_group_name = aws_db_subnet_group.main.name

  # Attach RDS SG to control who can connect (only ECS)
  vpc_security_group_ids = [aws_security_group.rds_sg.id]

  # Don't keep final snapshot when destroying, i'll only do this for dev stages
  skip_final_snapshot = true

  backup_retention_period = 7  # Keep daily backups for 7 days, you can increase or decrease as needed (similar to what you are insturcted on Console)

  # tag for clarity or just incase moments of confusion
  tags = {
    Name = "${var.project_name}-rds"
  }
}

To view the rest of the files, check out my GitHub Repo Link WordPress GitHub Repo

Variables & Secrets

DB password is sensitive = true in Terraform.
I passed it to Spacelift as an Enviironment Variable.
Make sure to never hardcode sensitibve credentials in .tf files.
Outputs don’t print sensitive values.
Always check: Always test secrets are functional before automating them.

As you can see in my repo link, there's no secret or sensitve data in my Terrafrom code there, but it works well. I'll show you later how i embeded my secrets or sensitive data to Spacelift without pushing it to repo.

Local Runs (Optional, but good practice)

Additionally, I often sometimes rerun my code locally or directly with terraform, especially if i want to test a module, so it doesnt mess up my repo.

Here are some commands i use from terraform

terraform init
terraform fmt
terraform validate
terraform plan
terraform apply /  #(-auto-approve) <---- Optional, use only if you're sure 
terraform destroy / #(-auto-approve) <---- Optional, use only if you're sure

CI/CD via Spacelift

Why Spacelift?

it automates the plan + apply with each Git commits and push successful in my repoo..
it stores secrets securely.
it keeps infra history in version control.
It lets me rollback if needed.
It builds secure pipelines for your workflow, and is collaborative

I use contexts or environment variables within stacks to store secrets.
Spacelift utilizes and maps out the TF_Var as a Terraform variable, and takes in its values.

How does the my traffic flow within my work?

Its pretty easy and simple!.

Step 1: User hits ALB DNS (could be domain name, if domain is bought and assigned to Route 53 (R53), and is routed by the ALB to a healthy ECS Task.
Step 2: Task container runs Apache + PHP based on the configuration of the wordpress image, and talks to RDS over port 3306.
Step 3: Additionally, Lets assume, one AZ fails the health check or fails for whatever reasons, my ECS Tasks still serve traffic from the other AZ. DB failover too.

As you can see my ECS Tasks is healthy, live and running.

Both replicas are spun up and running, minimum is set to two, incase one faults or fails, another is there.

And since there are up and healthy, to access it, we have to use the ALB DNS to access it in this case, for production level, they use route 53 and other DNS services, but for this project, this is fine, further developments will occur on it with time.

As you can see, my Wordpress site is on and live, waiting for me to setup.

Account creation and all

Blog up and running, left to be customized by designer.

WHat did i learn?

I learned a lot, made a couple of mistakes, and ran into some errors which naturally frustrated me at first, such as, I wondered why my RDS was not Multi-AZ, until i read through the documentation on Registry.terraform site again, and made an isolated attempt, which worked, then i compared and adopted the changes between them.

Unplanned personal error

I also encountered a situation where i did not pay attention to a small detail, it went like this. I ran across some accidents such as wrongly configuring my TF_VAR, and blindly re-inputting my database instance name as actual name in my ENV_VAR, especially as they were similar with just a slight "-" hyphen difference, then crashing out 😭😭 and getting more coffee ☕☕ as it wasn't working and making no sense, until I found out my silly mistake from an inspected .json file within my RDS and my Task Definition, which showed my ENV_VAR was not the same.

This made my ECS task to not function and my ALB to detect the replicas as unhealthy, (clearly as it couldn't authenticate with the username).

It was funny but also interesting to see how the smallest and simplest but unexpected errors can throw anyone off, while we naturally focus on the larger complex tasks.😂😂

I had to research a little bit as i worked to make sense of what i was doing.

But these are normal human errors, and I learn to pay more attention and cross check little details. 😎😎

Other things i learned were;

Why Task Definitions are just blueprints.
Why awsvpc mode needs ip Target Groups.
Why Security Groups must stay tight.
Why multi-AZ is worth the extra cost.
Why real CI/CD beats terraform apply from a laptop.

Final thoughts.

This project is 100% built from scratch, tested, deployed, and running in my own AWS account.

If you’re learning:

Break big .tf files into small ones. Embrace modularity!.
Draw your diagram or arhitecture, it helps you explain it to anyone, and also reminds you of what you're looking at.
Run local first, then automate.
Keep your secrets separate always.

Next up!

In the future, i might probably add some more features, such as route 53, Custom domain name, and other features, for future tasks. Butr who knows?
That's why you gotta stay tuned!! 😉.

If you want to see the rest of my actual infra code block or configuration files (terraform files), then check out my WordPress GitHub Repo

I tried my best to keep it simple, calm, clear and direct, trying to figure my tones. If you enjoed this read up, dont forget to drop a comment here.

Connect on LinkedIn | GitHub Repo

Stay curious, keep building!

—

AWS #Terraform #ECS #RDS #CI/CD #Spacelift

🚀 How I Built, & Deployed My Portfolio Site With Docker, AWS ECR, ECS-FARGATE, Terraform & Spacelift.

Akingbade Omosebi — Wed, 09 Jul 2025 11:54:47 +0000

Hey folks,
So as you know I've been playing with Spacelift, and honestly, I think i'm starting to find myself enjoy it, even more than the traditional approach of just handling and deploying infrastructures. That's why I want to share a fun project of mine i worked on today.

I actually decided to mess around and play both the roles of a Frontend Software Developer and a DevOps Engineer alone by myself for this project. I created and turned a portfolio site using HTML, CSS, JAVASCRIPT into a full-on AWS Cloud DevOps project. Which I containerized with Docker and and pushed to AWS Elastic Container Registry (ECR) and deployed with AWS Elastic Container Service (ECS), and all these were managed with Terraform and Spacelift.

Before you jump into it, here is the Architecture diagram to explain the logical flow of what the project is about. But if not, you can always refer to it, incase you're lost within the concept.

Why I Did This
Originally, I just wanted a simple portfolio site, you know, something to show off my projects and have a personal space online. But I didn’t want to stop at just pushing HTML, CSS, and JavaScript to a random static host. I thought: Why not make this an opportunity to show real DevOps skills too? make sense, right?

So, I took it up a notch — wrapped the site in a Docker container, pushed it to AWS ECR, deployed it on ECS, wrote my whole infra with Terraform, then wired it all up with Spacelift to handle the deployments automatically whenever I push changes to GitHub.

Pre-requisites

But before you dive into something similar, trying to accomplish this too (which i encourage you to), here are some basics I suggest you should have ready:

A basic front-end project (HTML, CSS, JavaScript) — I got a template, and build my frontend code based on the template, then added some extra more stuffs to it.
At least have docker installed locally — you’ll need it to build your image, which you you have developed, to tag it, and to test it through containers locally at first.
An AWS account — I use my AWS free tier account, you can use yours too if you are eligible, because you’ll need it for creating ECR repos, ECS clusters, IAM roles, VPCs, all the good and essential stuff.
Terraform installed — For this project I used Terraform, you can use CloudFormation or others as you desire, but you need an IaC like Terraform to define your infrastructure as code.
A Spacelift account connected to your GitHub repo (or any IaC CI/CD tool you prefer), you can register for a free trial.
Basic git knowledge — After I had finished my work, everything went well, With my brain overexcited from this project, I accidentally typed "git init", rather than "terraform init" which really messed up my nearly perfect workflow between my local machine and remote repo, and that's where my Git skills came in handy.
I promise, you’ll use git pull, rebase, and probably force push more than once.

Phase 1: Building the Portfolio Website

Building the Site

There was nothing too fancy here, but here is where my Frontend Developer skills played out, by eventually crafting a nice portfolio using Html, Css and JavaScript. I found a clean web template, stripped it down, rewrote parts, tossed in some more parts, added my own images (yes, I even took some quick professional portrait shot of myself just for this talk about dedication to the craft 😌😌). Made sure it was responsive, light, and looked modern enough.

Phase 2: Dockerizing the App

Meet our friends; Docker Desktop and Docker Engine, without it this project wont be possible

I decided to spin up my Docker Desktop, to get Docker engine running, and if you're on windows you know you will need to have WSL running, to be able to do that. If you do not have docker desktop, you can get it from its official website below:

Docker Desktop

Containerizing with Docker

Next, I wrote a simple Dockerfile. The goal was to serve the static site with NGINX inside a container. My Dockerfile was basically something like:

# I will be using the Nginx alpine image as the base image
FROM nginx:alpine

# to copy the contents of the current directory to the /usr/share/nginx/html directory in the container.
COPY . /usr/share/nginx/html

# i will expose port 80 from Nginx. This is the port that Nginx will listen on inside the container.
EXPOSE 80

If you don't know how to build docker images. Here is a guide from docker's official website.
Build and push your first image - docker.com

I also added a .dockerignore file to make sure I didn’t accidentally send unnecessary stuff to the build context (like .git folders, local configs, etc), because I initially accidentally built my image with the Nginx:latest tag, and it was bulky 960MB, so i had to stepback, use Nginx:alpine and added the things to be ignored in order to ensure dockerbuild wasn't adding unneccesary files... It came out as 82MB.

Here is the block of code from my .dockerignore file:

# Ignore Git metadata
.git

# Ignore GitHub workflows and config
.github

# Ignore Terraform infrastructure code
terraform

# Ignore documentation and config files not needed in container
README.md
Dockerfile
.dockerignore
workflows

# Optional: ignore logs and env files iif any
*.log
*.env

Then I ran docker build and docker run locally to make sure it actually worked. Seeing my site pop up locally inside a container felt satisfying.

To build use the following commands:

docker build --tag

docker build -t <filename>:<tag> .

docker build --tag name:latest . #the dot after is extremely important, and make sure you're inside your directory.

GitBash:> my_portfolio latest 5481289d0f89 8 hours ago 82.2MB

Docker host running locally:

While that was cute, it wasn't the main objective or end goal. The true goal was to make it run on something that is more reachable, such as AWS Elastic Container Service or Elastic Kubernetes Service, or something else. So I had to press on.

Before I could run any of these services on AWS, I needed some services to be up and supporting, such as VPC, Security Groups, IAM, ECR,

VPC (with Subnets & IGW)

# My VPC network
resource "aws_vpc" "my_vpc" {
  cidr_block       = "10.0.0.0/16"
  instance_tenancy = "default"

  tags = {
    Name        = "my-vpc"
    Project     = "my_portfolio"
    Environment = "dev"
  }
}

# My 3 subnets
resource "aws_subnet" "subnet-1" {
  vpc_id            = aws_vpc.my_vpc.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "eu-central-1a" # my zone a subnet

  tags = {
    Name        = "subnet-1a"
    Project     = "my_portfolio"
    Environment = "dev"
  }
}

resource "aws_subnet" "subnet-2" {
  vpc_id            = aws_vpc.my_vpc.id
  cidr_block        = "10.0.2.0/24"
  availability_zone = "eu-central-1b" # my zone b subnet

  tags = {
    Name        = "subnet-1b"
    Project     = "my_portfolio"
    Environment = "dev"
  }
}

resource "aws_subnet" "subnet-3" {
  vpc_id            = aws_vpc.my_vpc.id
  cidr_block        = "10.0.3.0/24"
  availability_zone = "eu-central-1c" # my zone c subnet

  tags = {
    Name        = "subnet-1c"
    Project     = "my_portfolio"
    Environment = "dev"
  }
}

#My route table, so that my subnets can atleast access the internet
resource "aws_route_table" "my_route_table" {
  vpc_id = aws_vpc.my_vpc.id

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

  tags = {
    Name        = "my-route-table"
    Project     = "my_portfolio"
    Environment = "dev"
  }
}

# my subnet associations to the route table, selecting the subnets i want to have access to the internet. 
resource "aws_route_table_association" "subnet_associations" {
  count          = 3
  subnet_id      = [aws_subnet.subnet-1.id, aws_subnet.subnet-2.id, aws_subnet.subnet-3.id][count.index]
  route_table_id = aws_route_table.my_route_table.id
}

# Myy internet gateway
resource "aws_internet_gateway" "my_igw" {
  vpc_id = aws_vpc.my_vpc.id

  tags = {
    Name        = "my-igw"
    Project     = "my_portfolio"
    Environment = "dev"
  }
}

Security Group

# My Security group mainly for my ECS tasks
resource "aws_security_group" "ecs_tasks_sg" {
  name        = "ecs-tasks-security-group"
  description = "Security group for ECS tasks"
  vpc_id      = aws_vpc.my_vpc.id

  # SSH access (Just incase, i need it for debugging)
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"] # Normally, restrict to your IP for security, but open for now
    description = "SSH access"
  }

  # Allow HTTP traffic (port 80)
  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
    description = "HTTP access"
  }

  # Allow HTTPS traffic (port 443)
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
    description = "HTTPS access"
  }

  # Allow My_portfolio application port
  ingress {
    from_port   = 5000
    to_port     = 5000
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
    description = "Application port"
  }

  # Allow all outbound traffic
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
    description = "All outbound traffic"
  }

  tags = {
    Name        = "ecs-tasks-sg"
    Project     = "my_portfolio"
    Environment = "dev"
  }
}

** ECR **

# My ECR repository for my_portfolio project
resource "aws_ecr_repository" "my_portfolio" {
  name                 = "my_portfolio"
  image_tag_mutability = "MUTABLE" # or "IMMUTABLE" based on your requirement
  image_scanning_configuration {
    scan_on_push = true
  }

  tags = {
    Name        = "my-portfolio-ecr"
    Project     = "my_portfolio"
    Environment = "dev"
  }
}

Phase 3: Pushing to ECR

Pushing my Local Docker Image to AWS ECR

With my image ready, I created an ECR repository in AWS using Terraform and Spacelift. Then I logged in to ECR from my terminal, tagged my image, and pushed it up.

This part went pretty smoothly — but if you’re new to ECR, make sure you don’t forget to authenticate your Docker client using the aws ecr get-login-password command. If you skip this, your push will fail and the error messages aren’t always the friendliest.

Once it was deployed, I had 3 images, which i only needed one as you can see below:

so for that I added a policy resource block with two rule blocks; one for tagged images and another for untagged images, ensuring there was only a maximum of 1 at a time, i then deployed it via terraform spacelift. Here is the code for that:

resource "aws_ecr_lifecycle_policy" "my_portfolio_ecr_policy" {
  repository = aws_ecr_repository.my_portfolio.name

  policy = <<EOF
{
    "rules": [
         {
      "rulePriority": 1,
      "description": "Expire untagged images",
      "selection": {
        "tagStatus": "untagged",
        "countType": "imageCountMoreThan",
        "countNumber": 1
      },
      "action": {
        "type": "expire"
      }
    },
        {
            "rulePriority": 2,
            "description": "Keep only 1 image max",
            "selection": {
                "tagStatus": "any",
                "countType": "imageCountMoreThan",
                "countNumber": 1
            },
            "action": {
                "type": "expire"
            }
        }
    ]
}
EOF
}

Phase 4: Deploying to ECS with Terraform**

After I was done with the whole ECR and Docker part, here’s where the fun (and a bit of chaos) started. I wrote my Terraform files to create an ECS cluster, services and task definitions.

Here is Spacelift doing the Heavy Terraform Lifting:

Here is the Cluster Created!:

I also needed to provision an IAM role and IAM Role Policy Attachment for the ECS. Here is Spacelift deploying it.

And here is its code block:

# So, i need two things, aws_iam_role and aws_iam_role_policy_attachment for my ECS task execution role.

resource "aws_iam_role" "ecs_task_execution_role" {
  name = "ecs-task-execution-role"
  assume_role_policy = jsonencode({    # Terraform's "jsonencode" function converts a Terraform expression result to valid JSON syntax. you can get moore of this templates on terraform registry docs site like i did here.
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Sid    = ""
        Principal = {
          Service = "ecs-tasks.amazonaws.com"       # You must specific the service type!!! This is the service that will assume this role, in my case, it is the ECS tasks. Read more on it.
        }
      },
    ]
  })

  tags = {
    name = "ecs-task-execution-role"
  }
}

and for policy Attachment:

# This is my Policy Attachment role, you can find this within the registry docs and read more about it then modify its attributes and apply it here as i did.

resource "aws_iam_role_policy_attachment" "ecs_task_execution_role_policy" {
  role       = aws_iam_role.ecs_task_execution_role.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
}

Then i needed to create an ECS Task Definition to for our Cluster to know what to do.

This is the code block for the Task defiition:

# now its time for taask definiinnition, you can find this basic example on terraform registry docs as i did, then read and modify it as you need it.

resource "aws_ecs_task_definition" "portfolio_task" {
  family                   = "portfolio-task"
  network_mode             = "awsvpc"
  requires_compatibilities = ["FARGATE"]
  cpu                      = "256"
  memory                   = "512"
  execution_role_arn       = aws_iam_role.ecs_task_execution_role.arn

  container_definitions = jsonencode([
    {
      name      = "portfolio-container"
      image     = "194722436853.dkr.ecr.eu-central-1.amazonaws.com/my_portfolio:latest"
      essential = true
      portMappings = [
        {
          containerPort = 80
          hostPort      = 80
        }
      ]
    }
  ])

  tags = {
    Name = "portfolio-task"
  }
}

Finally for the creation of my ECS, I needed a services resource that pulls my image from ECR and runs it within our ECS cluster, so I created it.

# Alright, so i am almost done, and here is where i add my service for my ecs and the amount i want running at all times.

resource "aws_ecs_service" "portfolio_service" {
  name            = "portfolio-service"
  cluster         = aws_ecs_cluster.portfolio_cluster.id
  task_definition = aws_ecs_task_definition.portfolio_task.arn
  launch_type     = "FARGATE"
  desired_count   = 1       # Personally id like to think of this as replicas with self heaaling in k8s or kubernetes. You can set to the miniumum about you  want to keep up and running at al times!!

  network_configuration {
    subnets         = [aws_subnet.subnet-1.id, aws_subnet.subnet-2.id]
    security_groups = [aws_security_group.ecs_tasks_sg.id]
    assign_public_ip = true
  }

  tags = {
    Name = "portfolio-service"
  }
}

So far, so good. Clean and neatly written codes carefully deployed.

Where Things Went Sideways

Everything was pretty good and working really well, so far so good. until i noticed my Cluster wasnt running, it had "0/1" task running for approx 5 minutes, and that didnt spell any good for me.

Phase 5: Troubleshooting: When Things Broke

Part of my duty as an engineer is to be able to repair broken stuffs, or things that went wrong within my project, So I did what i needed to do, like any DevOps or Technical Engineer. I went into trouble shooting mode, and looked into its log to see what the issues are. Luckily, I found the log and dug my way to it's root cause, a miswritten code, too much happy fingers. It was definitely rewarding to fix what was broken, it boosted my confidence more and gave me extra morale.

So, What was my Error Code?

Error Code:

container_definitions = jsonencode([
  {
    name      = "my_portfolio"
    image     = "my_portfolio:latest"  # <-- this is wrong!
    ...
  }
])

Caused by me carelessly re-writting the image name and tag, rather than paying attention to the docs, that specified the name here as image URL.

So what was the correct block of code?

container_definitions = jsonencode([
  {
    name      = "my_portfolio"
    image     = "194722436853.dkr.ecr.eu-central-1.amazonaws.com/my_portfolio:latest"
    ...
  }
])

You can also find it here:

Phase 6: Lessons I Learned

Always take your time, double-check your documentation and code in your Terraform ecs.tf file and every other file. Even a single mistake such as this, or a port mismatch can break the whole deployment. Thankfully, I found it > tweaked it > pushed it > Spacelift picked it up as usual and did the heavy lifting for me, and after a few seconds boom!!! My portfolio was running from my own ECS cluster.

And it was healthy as well...

But i wanted to access my app from the internet, normally, it is advised to use Application Load Balancer (ALB) Network Configuration, but for a small project such as mine, I went with the Public IP, with the rightful ports open in the security group, i had the Public Ip automatically assigned to it from the network configuration underneath the service block.

network_configuration {
    subnets         = [aws_subnet.subnet-1.id, aws_subnet.subnet-2.id]
    security_groups = [aws_security_group.ecs_tasks_sg.id]
    assign_public_ip = true
  }

and when i clicked the Public Ip address, My application was live and running. No more on local host, but on a public ip, and anyone across the globe could access it. I shared it with my friend who was far away, and he confirmed it from his mobile as well.

Automating with Spacelift CICD

Writing Terraform is nice, but I wanted it to run automatically whenever I push changes to GitHub. There came Spacelift, which i've been using for a while now, I bet you're tired of seeing me posting about it.
I connected my repo, set up a stack, wired up the permissions, and boom!! Now every commit and push runs a plan and applies the infra config if approved.

It felt good to see my commits trigger an actual pipeline that deploys my container and updates my infra with no extra manual steps.

Screenshots or It Didn’t Happen

Because I won’t keep the cluster running forever (it costs money!), I took a bunch of screenshots as proof: the live site, my ECS cluster, task definitions, ECR repo, and my Spacelift runs. I added them to my repo’s README for anyone curious.

Tip: Always do this for demo or learning projects. Trust me, you don’t want to pay AWS bills just so people can “see” your container is live forever.

A Few Things to Watch Out For

Be careful with your IAM permissions. ECS won’t run your tasks if you don’t have the right execution role.

Double-check your .dockerignore. You don’t want to push your .git or local config files to your container.

Use lifecycle policies on ECR to clean up old images automatically — your storage bill will thank you.

If you run into git messes (I did!), don’t panic. Stash, reset, pull with rebase, force push, but be careful!

Final Thoughts

I started this as a simple portfolio site but turned it into a practical showcase of cloud and DevOps skills. I learned (and re-learned) so many small but real lessons along the way.

If you’re a developer wanting to break into DevOps or cloud engineering, I highly recommend picking a small project like this and taking it through the whole pipeline. From local dev to a live container in the cloud, all automated.

I did not include everything here as it is already long.
However, If you want to see my repo, check it out here: Github
I hope this inspires someone to try the same.

Thanks for reading! 🚀✨

Enforcing Cloud Guardrails with Spacelift Policies: My Hands-On Test with Rego, Terraform, and AWS

Akingbade Omosebi — Mon, 07 Jul 2025 00:11:02 +0000

After getting comfortable using Spacelift to automate my AWS infrastructure with Terraform, I wanted to push myself a bit further, so I decided to dig into something that often gets overlooked: Policies.

In real-world organizations, you rarely have total freedom to spin up any resource you want, any way you want. Teams need guardrails, ways to make sure people stick to the right instance types, permissions, regions, or cost limits, resources, etc. That’s where Spacelift’s policy engine comes in. And honestly? I must say, i struggled with it a lot, as part of my failure journey, but it paid off in a very satisfying way. It’s pretty interesting once you get your hands dirty.

Before we dive in deep, let me drop an architectural diagram, hopefully you would get the concept ahead (like a spoiler).

Getting Started with Policies: Templates & Manual Rego

To get my head around it, I started with Spacelift’s template policies.

They provide some great examples to learn from. But I didn’t stop there. I wanted to see if I could write my own Rego policies from scratch too.

My experiment?
Allow only t2.nano EC2 instances ✅
Prohibit t3.micro instances ❌

Why should any of these matter?

You may ask why? Well this matters to businesses in my opinion, and how i can fit in it?

In a real company setup, you might have policies that say:

“Developers can only launch small test instances, not production-grade ones.”
Or:
“No one is allowed to use certain instance families because they’re too expensive.”

So I wanted to see exactly how you can enforce rules like that before someone clicks "Apply", and to make it clear why something is blocked.

How I Wrote It (and Broke It)
Writing Rego for the first time is honestly a bit of a brain twist. I made plenty of mistakes! Syntax errors, logic that didn’t match what I meant, rules that blocked the wrong thing. Such as this block of code i wrote, which seems nice and logical, but is flawed somewhere.

# secondary_only_t2_nano_instances - plan

package spacelift

deny[message] {
  rc := input.resource_changes[_]

  rc.type == "aws_instance"
  rc.change.actions[_] == "create"

  instance_type := rc.change.after.instance_type

  instance_type != "t2.nano"

  message := sprintf("Only t2.nano instances are allowed. Found disallowed type '%v' at %v", [instance_type, rc.address])
}

or this one:

# deny_t3_micro_instance - plan

package spacelift

deny[message] {
  some i
  rc := input.resource_changes[i]

  rc.type == "aws_instance"
  rc.change.actions[_] == "create"

  instance_type := rc.change.after.instance_type

  instance_type == "t3.micro"

  message := sprintf("Provisioning t3.micro instances is not allowed: %v", [rc.address])
}

or was it when i failed trying to combine both logics into one? it checked off well logically and looked good on paper, but still failed somehow.

package spacelift

# Block if creating anything not t2.nano
deny[message] {
  rc := input.resource_changes[_]
  rc.type == "aws_instance"
  rc.change.actions[_] == "create"
  instance_type := rc.change.after.instance_type
  instance_type != "t2.nano"
  message := sprintf("Only t2.nano instances are allowed (create). Found disallowed type '%v' at %v", [instance_type, rc.address])
}

# Block if updating anything not t2.nano
deny[message] {
  rc := input.resource_changes[_]
  rc.type == "aws_instance"
  rc.change.actions[_] == "update"
  instance_type := rc.change.after.instance_type
  instance_type != "t2.nano"
  message := sprintf("Only t2.nano instances are allowed (update). Found disallowed type '%v' at %v", [instance_type, rc.address])
}

These are the policies i created:

Irregardness, these were failures, I did not delete them for a deliberate reason, to return and learn from my mistakes.

That’s part of why I’m documenting this: the mistakes helped me actually learn how it works.

But guess what?! When I finally got my policy working, Spacelift did exactly what it should:

If I tried to provision a t3.micro instance, the policy failed the plan.

But instead of the usual boring “Policy was denied” message, I set a custom message:

“Selected policy denied by Admin, only t2.nano instances are permitted or allowed.”

That little touch alone makes a huge difference, especially when teams grow and you need clear feedback instead of digital or cryptic errors.

Putting It All Together

Of course, I tested my policy by actually provisioning an EC2 instance of type t2.nano through my Terraform code and Spacelift stack. It passed the policy check, applied successfully, and spun up the instance exactly as expected.

I also learned how policies are attached to stacks in Spacelift:

You can choose whether your policy runs on plan events, push events, or others.

You attach the policy to the specific stack you want to enforce it on.
And when you don’t need it, you can detach it. Super easy!!.

Lessons & Takeaways

This project and learning taught me a lot:

Rego is powerful! But you’ll probably break it a few times before you get it right. That’s normal!
Clear policy messages make a big difference for teams. Explain why something failed, don’t just throw an error.
Spacelift policies are a practical way for organizations to balance freedom and control. Terraform doesn’t care what you write, but your company and it's budget probably does.

If you’re getting into Terraform automation, don’t skip over policies. They’re not just “enterprise stuff”, they’re how you scale infrastructure safely. And like most things, you learn best by writing one, breaking it, and fixing it yourself.

👀 If you're lost, you may want to read my first Spacelift + Terraform story here if you missed it:
Provisioning AWS Resources with Terraform through Spacelift.io

GitHub Repo link for my spacelift project.

Next up for me, will be showing you some less coding, and more of chilled/laid back sweet stuffs about Spacelift, so you don't get nervous and run away from Rego.

Enforcing Cloud Guardrails with Spacelift Policies: My Hands-On Test with Rego, Terraform, and AWS"

Akingbade Omosebi — Mon, 07 Jul 2025 00:11:02 +0000

Before we dive in deep, let me drop an architectural diagram, hopefully you would get the concept ahead (like a spoiler).

Getting Started with Policies: Templates & Manual Rego

To get my head around it, I started with Spacelift’s template policies.

They provide some great examples to learn from. But I didn’t stop there. I wanted to see if I could write my own Rego policies from scratch too.

My experiment?
Allow only t2.nano EC2 instances ✅
Prohibit t3.micro instances ❌

Why should any of these matter?

You may ask why? Well this matters to businesses in my opinion, and how i can fit in it?

In a real company setup, you might have policies that say:

“Developers can only launch small test instances, not production-grade ones.”
Or:
“No one is allowed to use certain instance families because they’re too expensive.”

So I wanted to see exactly how you can enforce rules like that before someone clicks "Apply", and to make it clear why something is blocked.

# secondary_only_t2_nano_instances - plan

package spacelift

deny[message] {
  rc := input.resource_changes[_]

  rc.type == "aws_instance"
  rc.change.actions[_] == "create"

  instance_type := rc.change.after.instance_type

  instance_type != "t2.nano"

  message := sprintf("Only t2.nano instances are allowed. Found disallowed type '%v' at %v", [instance_type, rc.address])
}

or this one:

# deny_t3_micro_instance - plan

package spacelift

deny[message] {
  some i
  rc := input.resource_changes[i]

  rc.type == "aws_instance"
  rc.change.actions[_] == "create"

  instance_type := rc.change.after.instance_type

  instance_type == "t3.micro"

  message := sprintf("Provisioning t3.micro instances is not allowed: %v", [rc.address])
}

or was it when i failed trying to combine both logics into one? it checked off well logically and looked good on paper, but still failed somehow.

package spacelift

# Block if creating anything not t2.nano
deny[message] {
  rc := input.resource_changes[_]
  rc.type == "aws_instance"
  rc.change.actions[_] == "create"
  instance_type := rc.change.after.instance_type
  instance_type != "t2.nano"
  message := sprintf("Only t2.nano instances are allowed (create). Found disallowed type '%v' at %v", [instance_type, rc.address])
}

# Block if updating anything not t2.nano
deny[message] {
  rc := input.resource_changes[_]
  rc.type == "aws_instance"
  rc.change.actions[_] == "update"
  instance_type := rc.change.after.instance_type
  instance_type != "t2.nano"
  message := sprintf("Only t2.nano instances are allowed (update). Found disallowed type '%v' at %v", [instance_type, rc.address])
}

These are the policies i created:

Irregardness, these were failures, I did not delete them for a deliberate reason, to return and learn from my mistakes.

That’s part of why I’m documenting this: the mistakes helped me actually learn how it works.

But guess what?! When I finally got my policy working, Spacelift did exactly what it should:

If I tried to provision a t3.micro instance, the policy failed the plan.

But instead of the usual boring “Policy was denied” message, I set a custom message:

“Selected policy denied by Admin, only t2.nano instances are permitted or allowed.”

That little touch alone makes a huge difference, especially when teams grow and you need clear feedback instead of digital or cryptic errors.

Putting It All Together

I also learned how policies are attached to stacks in Spacelift:

You can choose whether your policy runs on plan events, push events, or others.

You attach the policy to the specific stack you want to enforce it on.
And when you don’t need it, you can detach it. Super easy!!.

Lessons & Takeaways

This project and learning taught me a lot:

Rego is powerful! But you’ll probably break it a few times before you get it right. That’s normal!
Clear policy messages make a big difference for teams. Explain why something failed, don’t just throw an error.
Spacelift policies are a practical way for organizations to balance freedom and control. Terraform doesn’t care what you write, but your company and it's budget probably does.

👀 If you're lost, you may want to read my first Spacelift + Terraform story here if you missed it:
Provisioning AWS Resources with Terraform through Spacelift.io

GitHub Repo link for my spacelift project.

Next up for me, will be showing you some less coding, and more of chilled/laid back sweet stuffs about Spacelift, so you don't get nervous and run away from Rego.

Provisioning AWS resources with Terraform through Spacelift.io

Akingbade Omosebi — Fri, 27 Jun 2025 15:18:35 +0000

When I first started working with Terraform, one of my biggest concerns was how to manage my infrastructure as code in a clean, automated, and secure way—without spending all my time running terraform apply manually or worrying about who has access to what. I researched and did some digging, I found different interesting options, but that’s when I also stumbled upon Spacelift.

Spacelift is basically a modern CI/CD platform built specifically for Infrastructure as Code. Think of it as a bridge between your version control system (like GitHub) and your cloud resources—helping you automate Terraform workflows, manage policies, and handle approvals, all in one place.

In this write-up, I want to share a quick story about how I used Spacelift to provision a VPC on AWS from a Terraform configuration sitting in my GitHub repo. I’ll walk you through what I did, why I did it this way, and some small lessons I picked up along the way. If you’re curious about how to get Terraform and Spacelift working together in the real world, I hope this helps you get started.

Before I jump into it, let me share with you my architectural diagram which i designed with Draw.io
.

Why I Picked Spacelift for This
Before this, I was managing my Terraform runs manually on my local machine. It worked, but it didn’t feel sustainable — especially when you think about team collaboration, state file security, and approvals for production changes.

Spacelift stood out to me because it plugs right into my GitHub repo, listens for changes, and takes care of running terraform plan and terraform apply in a safe, controlled way. Plus, it lets me see exactly what’s going to change before I hit “approve.” That extra visibility really helps when you’re touching cloud resources.

What I Wanted to Build
For this little experiment, I kept it simple: a custom VPC on AWS. I wanted to have my own network, subnets, internet gateway — the basics that any modern cloud setup needs. Nothing too fancy, but enough to see Spacelift and Terraform working together end to end.

How I Set It Up
Here’s the high-level flow:

Write the Terraform Code
I wrote a main.tf that defines my VPC, subnets, internet gateway, and route tables. I pushed this to a new GitHub repo.
Connect GitHub to Spacelift
I created a new Spacelift stack, pointed it at my repo, and connected it to my AWS account using IAM credentials.
Run and Approve
Spacelift detected my Terraform config, ran a plan, and showed me the changes. After reviewing, I gave it approval/confirmation and Spacelift applied the configuration to my AWS account.

That’s it — my VPC was live, provisioned automatically from my GitHub code.

Here is the Terraform Code which I Used
I kept my Terraform configuration as simple and clean as possible — just enough to spin up a VPC with a few subnets. Here’s what it looks like:

# main.tf

resource "aws_vpc" "my_vpc" { 
  cidr_block       = "10.0.0.0/16"
  instance_tenancy = "default"

  tags = {
    Name = "my-simple-vpc"
  }
}

# Subnet 1
resource "aws_subnet" "subnet1" {
  vpc_id     = aws_vpc.my_vpc.id
  cidr_block = "10.0.1.0/24"

  tags = {
    Name = "subnet-1"
  }
}

# Subnet 2
resource "aws_subnet" "subnet2" {
  vpc_id     = aws_vpc.my_vpc.id
  cidr_block = "10.0.2.0/24"

  tags = {
    Name = "subnet-2"
  }
}

# Subnet 3
resource "aws_subnet" "subnet3" {
  vpc_id     = aws_vpc.my_vpc.id
  cidr_block = "10.0.3.0/24"

  tags = {
    Name = "subnet-3"
  }
}

And here’s my provider block, so Terraform knows which cloud and region to talk to:

# provider.tf

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "6.0.0"
    }
  }
}

provider "aws" {
  region = "eu-central-1"
}

What This Code Does (Quick Breakdown)
VPC: The first block creates a VPC with a /16 CIDR block (10.0.0.0/16). This means I have plenty of private IP space to carve out subnets later.

Subnets: I added three subnets, each with a /24 CIDR block inside that VPC. Each subnet has a simple name tag so it’s easier to recognize in the AWS console.

Provider: Finally, the provider config makes sure Terraform uses the AWS provider and targets the eu-central-1 region (Frankfurt, in my case).

All terraform codes can be derived from the official terraform registry site. Here is the registry link i used. AWS Terraform Registry

Small Tips I Picked Up

Version Pinning: I pinned the AWS provider version (6.0.0). It’s a good habit — this helps avoid surprises when a new provider version has breaking changes.
Tags: Adding clear tags saves you headaches later, especially when you have multiple VPCs or subnets.
State Management: Since Spacelift handles remote state for me, I didn’t have to mess around with setting up an S3 bucket and DynamoDB table for locking — Spacelift does this behind the scenes.

What’s Next?
After pushing this code to my GitHub repo, Spacelift automatically detected the changes, ran terraform plan, and let me preview what would happen. When I hit Approve, Spacelift ran terraform apply and my VPC popped up in AWS — no manual runs from my laptop.

Here is what my Github repo i used looks like.

And here is the link to the GitHub repo i worked with incase you want to access it. My GitHub Repo

Here is my AWS VPC empty, before Spacelift provisioned its resources.

Here is Spacelift running the Apply process for the Deployment cycle, right after the Init Phase, and Plan Phase.

Here is Spacelift once it was with the "Applying phase" and had finished its process cycle.

Here is my formerly empty AWS VPC page which was empty, Now having the provisioned/deployed resource(s).

To Deploy your code to your cloud provider, for example AWS. You need to have an Account, preferrable an IAM user with least required priviledges (for security practices).

You need to "create" and "generate" a security access credentials from your IAM user, and download the CSV file, within it you will have your credentials.

Two credentials needed for Spacelift to work with AWS are "Secret Key" & "Secret Access Key"

Once Generated, they will take this form within your .csv file you downloaded.

provider "aws" {
  region     = "us-west-2"
  access_key = "sample-my-access-key" # Your Key
  secret_key = "sample-my-secret-key" # Your Key
}

You need to input them into your Spacelifts Slacks to configure it and authorize/Authenticate it.

Here is a simple direction to follow:

Additionally, here is an extra story of when I broke my configuration by later returning at an different hour, forgetting to review my code from scratch again, and accidentally pushing an unfinished config code to my repo. (and this is how Spacelift Saved Me)

Right after getting the initial setup working, I decided to tweak something in my Terraform code. I made a quick change, pushed it to the GitHub repo… and boom — Spacelift flagged an error and deliberately allow it to fail.

Turns out, I had pushed an invalid configuration by mistake. But here’s the cool part:
Spacelift picked it up immediately, ran the terraform plan, and failed the run without applying anything. That moment was a good reminder of why I’m using this tool in the first place — it acts like a guardrail.

Instead of letting broken code touch my AWS environment, Spacelift stopped the pipeline, showed me exactly where the config was wrong, and kept my infrastructure safe. Once I fixed the mistake, committed the changes, and pushed again, everything went through cleanly.

Here’s a quick snapshot from that failed run (see below ⬇️). I left it in on purpose — because real DevOps isn’t perfect, and that’s okay. What matters is catching things early.

So i resolved it, and cleared the config issue. Hence, why you can see it successfully finished.

Wrapping up

Final Thoughts: What did i learn, right?

This small project may seem basic — just a VPC and some subnets — but for many out there who are just starting or wondering on how to start or where to start, it will serve as an solid intro to combining Terraform with Spacelift in a real-world workflow.

Personally, It showed me how powerful automation can be when paired with the right tools and a good version control setup.

Here’s what stood out the most:

🛡️ Safety First: Spacelift acted like a second pair of eyes. It caught my broken code and stopped it from being applied. That alone is worth the setup.

🧠 Git-Driven Infra: Everything I did was tracked in Git. No more guessing what changed or why — just clean commits and transparent change history.

🚀 Confidence Boost: Watching Spacelift plan and apply my infrastructure automatically made me feel more confident about scaling future projects.

I’m only just getting started with IaC automation, but this experiment gave me the motivation to go deeper.

I have also used Spacelift to provision resources on Azure, and now I am looking forward to GCP.

Here is Spacelift managing Azure Resources.

And here is Spacelift Lifecycle on the Azure Resource.

Then next, on my AWS repo, I’ll be looking into adding network ACLs, route tables, maybe even EC2 instances — all managed through the same Spacelift pipeline.

If you’re exploring Terraform and want a smoother CI/CD experience for your infrastructure, I genuinely recommend giving Spacelift a shot. It’s like Terraform on autopilot — but with controls.

I hope you enjoyed reading through, feel free to practice with Spacelift.

Thank you for reading.

DEV Community: Akingbade Omosebi

Opsfolio - From Interview Task to Production: Building a Security-First DevSecOps Platform

From Interview Task to Production: Building a Security-First DevSecOps Platform

TL;DR

Table of Contents

The Challenge

The Approach

Security Architecture

🛡️ Multi-Layer Defense Strategy

Layer 1: CI/CD Security Pipeline (6 Scanners)

FinOps: Cost Intelligence

Automation & GitOps

ArgoCD GitOps

📊 Measurable Outcomes

Key Takeaways

Explore the Repository

Let's Connect

devops #kubernetes #devsecops #aws #finops #terraform #security #gitops #cicd #infrastructure

🏁 From Code to Cloud: My DevOps + DevSecOps Journey (Part 4/4 - The Reflection and Possible Routes)

⚠️ The Struggles

✅ The Wins

💡 Key Lessons Learned

🚀 What’s Next?

🎯 Final Thoughts

🌍 From Code to Cloud: My DevOps + DevSecOps Journey. (Part 3/4 - The Execution)

🛠️ Why Terraform?

🚀 The Infrastructure

💰 Cost Estimation in Terraform Cloud

🔑 Secret Management with Terraform Cloud

🛡️ Security Checks with TFSEC

📜 A Simplified Terraform Snippet

✅ The Result

💡 Why This Matters

⚙️ From Code to Cloud: My DevOps + DevSecOps Journey (Part 2/4 - The Automation Obstacles)

🏗️ The App Itself

🔄 The Pipeline Workflow

⚠️ The Roadblocks

✅ The Working Pipeline

💡 Why This Matters

🎬From Code to Cloud: My DevOps + DevSecOps Journey (Part 1/4 – The Vision)

💡The Idea

🛠️The Tech Stack I Chose

🎯 The Goal

⚡ The Challenges I Knew Were Coming

🗺️ The Big Picture

✨ Why This Matters

How i built My Own Cloud-Native Monitoring App, From Flask to ECR using Boto3, and EKS using Terraform, then implemented ArgoCD.

Phase 1 : My Python Flask Monitoring App

Phase 2: Containerize Everything

Phase 3: Pushed the image to AWS ECR

Part 2: Terraform + EKS: Bringing My non-existent Cluster to Life

Phase 4: Deploy My App!

Part 3!! GitOps the Smart Way: ArgoCD + the Dex Saga

Dex: The Tiny Pod that Broke my Night🤬🤬

Connect to GitHub! The GitOps Cycle or Loop, or whatever you want to call it.

The Moment of Truth: Scaling!!

Outro or Perhaps What’s Next?

Deploying a Fully Functional Multi-AZ WordPress App on AWS ECS + RDS with Terraform & Spacelift.

What you’ll see here

What’s my goal?

Overall Architecture.

VPC, Subnets & Internet Gateway

Security Groups

ECS Fargate Cluster & Service

My ALB & Target Group

My RDS: The DB Layer

Variables & Secrets

Local Runs (Optional, but good practice)

CI/CD via Spacelift

How does the my traffic flow within my work?

WHat did i learn?

Final thoughts.

AWS #Terraform #ECS #RDS #CI/CD #Spacelift

🚀 How I Built, & Deployed My Portfolio Site With Docker, AWS ECR, ECS-FARGATE, Terraform & Spacelift.

Phase 1: Building the Portfolio Website

Phase 2: Dockerizing the App

Phase 3: Pushing to ECR

Phase 4: Deploying to ECS with Terraform**

Phase 5: Troubleshooting: When Things Broke

Phase 6: Lessons I Learned