DEV Community: BAKRE JAMIU

Building a CI/CD and GitOps Platform with Jenkins, Docker, Kubernetes and ArgoCD

BAKRE JAMIU — Mon, 19 Oct 2026 08:39:35 +0000

From Jenkins credential errors to a working pipeline, Kubernetes deployment, and automated GitOps reconciliation

Author: Jamiu Olatunji Bakre

Role: Cloud, DevOps and Platform Engineer

Tags: DevOps, Platform Engineering, Jenkins, CI/CD, Docker, Kubernetes, GitOps, ArgoCD, Maven, Kustomize, Minikube

Project Overview

This project was an important step in my journey towards becoming a stronger Cloud, DevOps and Platform Engineer.

My goal was to understand how application code moves from a GitHub repository through an automated build process, becomes a Docker image, and is ultimately deployed and managed in Kubernetes.

I wanted to go beyond simply installing tools and following commands from a tutorial. I wanted to understand how the components communicate, where configuration belongs, how credentials are handled, how deployment problems are investigated, and how to verify that an application is actually working.

The journey included configuring Jenkins, working with GitHub repositories, building a Spring Boot application with Maven, packaging the application with Docker, and using Kubernetes and ArgoCD to manage the deployment.

One of the most memorable challenges was a Jenkins credential error that took considerable troubleshooting. The pipeline reported that it could not find a credential with the ID github-credentials. After working through the integration issues, I achieved a successful pipeline build on my 20th CI/CD pipeline build.

That experience taught me something important: building a pipeline is not just about writing a Jenkinsfile. It also requires understanding credentials, permissions, repository configuration, networking, container registries, deployment manifests, and the dependencies between each stage.

ArgoCD Output

Scaled Up ArgoCD Output

This documentation explains the architecture, the steps involved, the purpose of each component, the commands used to inspect and validate the system, and the improvements I would make when extending the project.

It also includes reference configurations for frontend and backend applications, persistent storage, monitoring, and production-oriented practices. These examples provide a foundation for future work; they should not be interpreted as proof that every optional component was deployed in the original lab.

1. Project Objectives

The project was designed around the following objectives:

Automate application build and verification using Jenkins.
Store application source code in GitHub.
Package the application into a Docker image.
Publish container images to Docker Hub.
Define Kubernetes resources declaratively.
Separate application source code from deployment configuration.
Use ArgoCD to monitor the GitOps repository.
Test automated reconciliation when the live cluster configuration differs from Git.
Verify the deployed application's availability through Kubernetes and an HTTP request.
Develop a repeatable troubleshooting and documentation process.

The wider objective was to understand how these capabilities fit together as a small platform engineering workflow.

2. Project Architecture

The architecture separates the application build process from the deployment reconciliation process.

Jenkins runs on an AWS EC2 instance. The Kubernetes application and ArgoCD run in a local Minikube environment.

This separation is important because a Jenkins server on EC2 cannot automatically reach a Kubernetes cluster running on a developer's local computer. The two environments have different network boundaries.

Architecture diagram

                    Developer
                        |
                        v
               Application Changes
                        |
                        v
                 GitHub Source Repo
                        |
                        v
                  Jenkins on EC2
                        |
             +----------+-----------+
             |          |           |
             v          v           v
           Maven     Code Checks   Docker Build
             |                      |
             v                      v
        Build/Test               Docker Hub
                                    |
                                    v
                          GitOps Repository
                                    |
                                    v
                                ArgoCD
                                    |
                                    v
                           Local Minikube
                                    |
                                    v
                            Kubernetes
                                    |
                                    v
                         Spring Boot App

The diagram describes the intended delivery flow. The exact automation depends on which stages are implemented in the Jenkinsfile. For example, updating the GitOps repository must be explicitly configured if it is to happen automatically after an image is published.

The role of each component

Component	Responsibility
GitHub	Stores application source code and deployment manifests
Jenkins	Orchestrates build, test, and image publication stages
Java and Spring Boot	Provide the application runtime and framework
Maven	Compiles, tests, and packages the application
Docker	Packages the application and its runtime dependencies
Docker Hub	Stores and distributes container images
Kubernetes	Schedules and manages application Pods
Minikube	Provides a local Kubernetes environment
ArgoCD	Reconciles Kubernetes resources with Git-defined desired state
Kustomize	Organises and renders Kubernetes configuration
SonarQube	Optional code-quality analysis when configured in the pipeline

3. Repository Structure and Separation of Responsibilities

I used two GitHub repositories to separate application development from deployment configuration.

3.1 Application source repository

Repository: platform-cicd-spring-boot-demo-source

URL - https://github.com/Jahmeeu-Cloud/platform-cicd-spring-boot-demo-source

This repository holds the Spring Boot application and its Maven build configuration.

A typical structure looks like this:

platform-cicd-spring-boot-demo-source/
├── spring-boot-app/
│   ├── pom.xml
│   ├── mvnw
│   ├── .mvn/
│   └── src/
│       ├── main/
│       │   ├── java/
│       │   └── resources/
│       └── test/
├── Dockerfile
├── Jenkinsfile
├── .gitignore
└── README.md

This is a recommended structure, not a claim that every file shown was present in the original repository.

The source repository should contain the code required to build the application. Generated output, credentials, and environment-specific secrets should not be committed.

For example, Maven's target/ directory contains generated build artifacts. It is normally excluded from Git.

A suitable .gitignore could include:

target/
*.log
.env
.env.*
!.env.example
.idea/
.vscode/
.DS_Store

The exact exclusions should match the project's development tools and build process.

3.2 GitOps configuration repository

Repository: platform-cicd-gitops-config

URL: https://github.com/Jahmeeu-Cloud/platform-cicd-gitops-config

This repository contains the desired Kubernetes configuration.

The confirmed base directory is:

platform-cicd-gitops-config/
└── apps/
    └── spring-boot-app/
        └── base/
            ├── deployment.yaml
            ├── service.yaml
            └── kustomization.yaml

The Deployment declares how the application should run. The Service provides a stable network endpoint. The Kustomize file identifies the manifests that belong to the application configuration.

The main principle is that the GitOps repository should describe the desired deployment state rather than merely store commands that someone runs manually.

Why keep the repositories separate?

This separation makes it easier to review application changes independently from deployment changes.

It also creates a clear path for future environment promotion:

Developers change application code.
Jenkins validates and packages the code.
A versioned image is published.
The deployment configuration references that image.
ArgoCD reconciles the cluster with the approved configuration.

In a larger platform, the same approach can support separate development, staging, and production configurations.

[SCREENSHOT: GITHUB SOURCE REPOSITORY HERE]

The source repository contains the application and build-related files.

[SCREENSHOT - GITHUB GITOPS REPOSITORY HERE]

The GitOps repository stores the Kubernetes manifests used to define the desired application state.

4. Understanding the Environment Before Starting

Before troubleshooting a CI/CD pipeline, it is useful to understand where each component is running.

In this project:

Jenkins ran on AWS EC2.
The Kubernetes cluster ran locally through Minikube.
ArgoCD ran inside the Minikube cluster.
The application image was stored in Docker Hub.
GitHub stored both the source code and the deployment configuration.

This topology has an important implication: Jenkins does not automatically have network access to the local Kubernetes API.

A common mistake is to install kubectl on a remote Jenkins server and assume that this gives it access to a local cluster. It does not. The CLI needs a valid cluster endpoint, credentials, and network connectivity.

In a GitOps architecture, Jenkins can publish the image and update the deployment configuration in Git, while ArgoCD performs the cluster-side reconciliation.

This avoids requiring the Jenkins server to connect directly to the local cluster.

4.1 Check Jenkins

On the EC2 instance:

sudo systemctl status jenkins

If the service is not running:

sudo journalctl -u jenkins -n 100 --no-pager

Check the Java runtime if the Jenkins service reports startup or compatibility problems:

java -version

The Java version must be compatible with the installed Jenkins release. Check the official Jenkins documentation for the requirements of the specific version being used.

4.2 Check Docker

docker --version
docker info

These commands confirm that the Docker client is installed and can communicate with the daemon under the current user's permissions.

When Jenkins builds Docker images, test access using the actual Jenkins service account where appropriate:

sudo -u jenkins docker info

This command assumes a Linux installation with a service account named jenkins.

Do not automatically grant broad privileges to fix an access problem. Membership in the Docker group can effectively provide root-level access to the host. Investigate the specific error and choose a build architecture appropriate to the security requirements.

4.3 Check Minikube and Kubernetes

Run these commands on the machine where Minikube is installed:

minikube status
kubectl cluster-info
kubectl get nodes -o wide
kubectl get pods -A

Expected results include a running Minikube cluster, a reachable Kubernetes API, and a node reporting Ready.

[SCREENSHOT - MINIKUBE AND KUBERNETES STATUS HERE]

The exact output varies by Kubernetes and Minikube version.

5. How the CI/CD and GitOps Process Works

The complete delivery process has several logical stages.

Stage 1: Source checkout

Jenkins retrieves the application source code from GitHub.

A checkout stage might look like this:

stage('Checkout') {
    steps {
        git branch: 'main',
            url: 'https://github.com/OWNER/REPOSITORY.git'
    }
}

Replace OWNER/REPOSITORY with the actual repository path.

For a private repository, Jenkins needs a suitable credential. For a public repository, a read-only checkout may not require authentication.

The purpose of checkout is to ensure that the build uses a known source revision rather than files copied manually to the Jenkins server.

Stage 2: Build and test

For a Maven-based Spring Boot application:

mvn clean verify

The clean goal removes previous build output. The verify lifecycle phase runs the configured checks leading up to verification.

A successful result means the build and configured verification steps passed. It does not prove that the application has no defects.

If the project uses the Maven Wrapper, prefer:

./mvnw clean verify

The wrapper helps the project use the intended Maven version, subject to the availability of a compatible Java runtime.

Stage 3: Optional code analysis

SonarQube can be included to assess code quality and identify potential issues.

An illustrative command is:

mvn clean verify sonar:sonar \
  -Dsonar.host.url="$SONAR_HOST_URL" \
  -Dsonar.token="$SONAR_TOKEN"

This requires a correctly configured SonarQube server, compatible scanner configuration, and a valid token.

Do not add this stage to a pipeline until the scanner, server URL, and credentials are configured. A code-quality stage is optional in the reference implementation and should only be described as completed if it was actually executed.

Stage 4: Build the Docker image

A Docker image packages the application into a standard format that can be stored and run in compatible container environments.

A simple example:

docker build \
  -t horlacloud/spring-boot-demo:BUILD_TAG \
  .

Replace BUILD_TAG with a valid version identifier.

For repeatable releases, use a unique build number, release version, or commit-based tag rather than depending only on latest.

For example:

docker build \
  -t horlacloud/spring-boot-demo:1.0.0 \
  .

This example assumes the Dockerfile is in the current build context. Adjust the path if it is stored elsewhere.

Stage 5: Publish the image

After building the image, Jenkins authenticates to Docker Hub and pushes it.

A typical manual command sequence is:

docker login
docker push horlacloud/spring-boot-demo:1.0.0

For an automated pipeline, credentials should be supplied securely through Jenkins Credentials rather than typed into a pipeline or stored in the source repository.

A successful push means the registry accepted the image. It does not prove that Kubernetes can pull it or that the application will start correctly.

Stage 6: Update deployment configuration

The GitOps configuration must reference the intended image.

For example:

containers:
  - name: spring-boot-app
    image: horlacloud/spring-boot-demo:1.0.0

If Jenkins is expected to update this value automatically, the Jenkinsfile needs an explicit step to modify the GitOps repository and push the change using an appropriately restricted GitHub credential.

Publishing an image does not automatically update Kubernetes unless the delivery design includes an image-update mechanism or a corresponding configuration change.

Stage 7: ArgoCD reconciliation

ArgoCD monitors the configured Git repository and path.

When a new desired configuration is committed, ArgoCD can detect the difference and synchronise the managed Kubernetes resources according to its application configuration.

This is the GitOps part of the workflow.

[SCREENSHOT - JENKINS PIPELINE STAGES HERE]

[SCREENSHOT - SUCCESSFUL DOCKER HUB IMAGE PUBLICATION HERE]

The build process packages the application into a container image that can be referenced by Kubernetes deployment configuration.

6. The Jenkins Credential Error That Took Hours to Resolve

One of the most valuable lessons from this project came from a Jenkins credential lookup failure.

The error was:

ERROR: Could not find credentials entry with ID 'github-credentials'

The important detail is the wording: Jenkins could not find the credential entry with the requested ID.

This is different from a rejected token or an access-denied response.

6.1 What is a credential ID?

Jenkins stores credentials separately from the pipeline source code. Each saved credential has an identifier.

For example:

credentialsId: 'github-credentials'

Here, github-credentials is the credential ID. It is not the token itself.

If the saved credential is named github-token, referencing github-credentials will not work unless a credential with that exact ID exists in the relevant credential store and scope.

6.2 Troubleshooting the problem

I approached the error by focusing on the stage that failed instead of repeatedly rebuilding the application.

The checks to perform are:

Identify the exact failed stage in the Jenkins console.
Inspect the credential ID referenced by the Jenkinsfile.
Open Jenkins Credentials and locate the corresponding entry.
Confirm the credential's type.
Check the credential's scope and availability to the job.
Verify that the credential has the permissions required for the GitHub operation.
Confirm that the repository URL and branch are correct.

The exact credential ID must match the identifier used in the Jenkinsfile.

The credential type must also match the pipeline binding. A Secret text credential is not the same as a username/password credential or an SSH private key.

6.3 Example: username and token

If the credential is stored as a username/password pair, an illustrative Jenkins binding is:

withCredentials([
    usernamePassword(
        credentialsId: 'github-credentials',
        usernameVariable: 'GIT_USERNAME',
        passwordVariable: 'GIT_TOKEN'
    )
]) {
    sh '''
        set +x
        # Perform the authenticated operation here.
    '''
}

The ID and credential type must match the saved Jenkins configuration.

For a Secret text credential, the binding would instead look like this:

withCredentials([
    string(
        credentialsId: 'github-token',
        variable: 'GIT_TOKEN'
    )
]) {
    sh '''
        set +x
        # Use the token without printing it.
    '''
}

These are reference patterns, not the exact final code from my environment.

6.4 Why secrets should not be stored in the Jenkinsfile

A Jenkinsfile is normally stored in version control. Hardcoding a token into it creates a risk of exposing that token through Git history, logs, pull requests, or copied source code.

The safer approach is to store secrets in Jenkins Credentials and reference them by ID.

Use narrowly scoped credentials, protect pipeline changes, and rotate exposed secrets promptly.

6.5 Three similar errors that require different fixes

Error	Likely meaning	First check
Credential not found	Jenkins cannot resolve the referenced ID	Credential ID and scope
Authentication failed	The authentication method or secret was rejected	Token validity, username, credential type
Permission denied	The identity lacks access to the requested resource	Repository permissions and token scope

This distinction saves time because each error points to a different part of the configuration.

[SCREENSHOT - THE SUCCESSFUL PIPELINE BUILD HERE]

By the 20th CI/CD pipeline build, I had worked through the integration problems and achieved a successful pipeline build.

7. Building a Spring Boot Application Container

A container image needs a Dockerfile that explains how the application is built or how its packaged artifact is executed.

There are two common approaches.

Option A: Build the JAR before creating the image

If Maven has already generated the JAR, a simple Dockerfile can copy that artifact into a Java runtime image.

FROM eclipse-temurin:21-jre

WORKDIR /app

COPY target/*.jar app.jar

EXPOSE 8080

USER 10001

ENTRYPOINT ["java", "-jar", "/app/app.jar"]

This is an illustrative example. The Java runtime version must match the application's requirements, and the build process must ensure that exactly the intended JAR is copied.

The EXPOSE instruction documents the expected container port; it does not publish the port by itself.

The non-root user improves the default security posture, provided the application can run with the required filesystem permissions.

Option B: Use a multi-stage Docker build

A multi-stage Dockerfile can compile the application in a build image and copy only the packaged artifact into the runtime image.

FROM maven:3.9-eclipse-temurin-21 AS build

WORKDIR /workspace

COPY pom.xml .
COPY src ./src

RUN mvn -B clean package -DskipTests

FROM eclipse-temurin:21-jre

WORKDIR /app

COPY --from=build /workspace/target/*.jar app.jar

EXPOSE 8080

USER 10001

ENTRYPOINT ["java", "-jar", "/app/app.jar"]

This example assumes the Maven project is at the Docker build context root and produces one intended executable JAR.

Notice that this sample skips tests during packaging. In a complete CI/CD workflow, tests should run in a dedicated stage before image publication, and the pipeline should stop if they fail. Avoid using -DskipTests as a replacement for automated testing.

The runtime image does not need the entire Maven build environment, which can reduce the amount of tooling included in the final container.

Build and test locally

mvn clean verify
docker build -t spring-boot-app:local .
docker run --rm -p 8080:8080 spring-boot-app:local

Then, in another terminal:

curl -i http://localhost:8080

Use an actual application route if the root path is not defined.

8. Deploying the Application with Kubernetes

Kubernetes manages the desired state of containerised workloads. It schedules Pods, monitors workload state, and attempts to maintain the replica count specified in the Deployment.

The project used a Deployment and a Service for the Spring Boot application.

8.1 Deployment manifest

The confirmed GitOps configuration declares three replicas and the image horlacloud/spring-boot-demo:20.

An illustrative Deployment is:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-boot-app
  labels:
    app: spring-boot-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: spring-boot-app
  template:
    metadata:
      labels:
        app: spring-boot-app
    spec:
      containers:
        - name: spring-boot-app
          image: horlacloud/spring-boot-demo:20
          ports:
            - name: http
              containerPort: 8080

This shows the core configuration. A production-oriented Deployment should normally also define appropriate probes, resource requests and limits, and a security context.

The replicas field is the desired number of Pods. Kubernetes attempts to maintain that number, but scheduling constraints, image pull failures, application crashes, and insufficient capacity can prevent all replicas from becoming ready.

The selector must match the labels on the Pod template. If the selector and template labels do not match, the Deployment will be invalid or fail to manage the intended Pods.

8.2 Service manifest

A Service provides a stable endpoint for matching Pods.

The project's Service is named spring-boot-app-service. A representative configuration is:

apiVersion: v1
kind: Service
metadata:
  name: spring-boot-app-service
spec:
  type: NodePort
  selector:
    app: spring-boot-app
  ports:
    - name: http
      port: 80
      targetPort: 8080
      protocol: TCP

Here:

port: 80 is the Service port.
targetPort: 8080 is the port on the application container.
type: NodePort exposes the Service through a port on the Kubernetes node.

The selector identifies the Pods that should receive traffic.

A Service can exist even when it has no ready endpoints. That is why it is important to inspect both the Service and the Pods behind it.

8.3 Validate the resources

kubectl get deployments
kubectl get pods -o wide
kubectl get services
kubectl get endpoints spring-boot-app-service

To inspect the Deployment in more detail:

kubectl describe deployment spring-boot-app

To inspect an individual Pod:

kubectl describe pod POD_NAME
kubectl logs POD_NAME

Replace POD_NAME with the name returned by kubectl get pods.

[SCREENSHOT - KUBERNETES DEPLOYMENT AND POD STATUS HERE]

[SCREENSHOT - KUBERNETES SERVICE AND ENDPOINTS HERE]

Kubernetes was managing the application replicas and exposing them through a stable Service.

9. ConfigMaps, Secrets, and Application Configuration

Applications often need configuration that should not be embedded directly into the container image.

Examples include:

Application mode or environment name.
Log level.
API endpoint URLs.
Database connection settings.
Authentication credentials.

Kubernetes provides ConfigMaps for non-sensitive configuration and Secrets for sensitive values.

9.1 ConfigMap example

apiVersion: v1
kind: ConfigMap
metadata:
  name: spring-boot-config
data:
  APP_ENV: "development"
  LOG_LEVEL: "INFO"

A Deployment can expose these values to the container:

envFrom:
  - configMapRef:
      name: spring-boot-config

This belongs under the container specification.

9.2 Secret example

A Secret can hold sensitive configuration such as a database password.

apiVersion: v1
kind: Secret
metadata:
  name: database-credentials
type: Opaque
stringData:
  username: app_user
  password: REPLACE_WITH_A_SECRET

This is a template only. Replace the placeholder using an appropriate secret-management process.

Do not commit real passwords, access tokens, or private keys to Git. Kubernetes Secret values are not automatically safe simply because they are stored in a Secret object; access controls and encryption-at-rest configuration also matter.

For production environments, consider a suitable external secret-management integration.

9.3 Why configuration should be separate

Separating configuration from application code makes it easier to promote the same image across environments without rebuilding it for every setting change.

It also reduces the risk of accidentally baking environment-specific values into a reusable image.

10. Persistent Volumes and Persistent Volume Claims

Persistent storage deserves special attention because container storage and application data have different lifecycles.

A container's writable filesystem is generally not intended to be the durable home for important data. If a container is replaced, its writable layer may be lost.

Kubernetes persistent storage provides a way to manage data independently of an individual container's lifecycle.

10.1 Understanding the storage components

PersistentVolume (PV): Represents a piece of storage available to a Kubernetes cluster.

PersistentVolumeClaim (PVC): A request for storage made by an application or workload.

StorageClass: Defines how storage can be provisioned. Depending on the cluster, it may support dynamic provisioning so that a PVC can trigger creation of a volume.

Pod volume mount: Connects the claimed storage to a path inside a container.

The relationship is:

Application Pod
      |
      v
  Volume Mount
      |
      v
 PersistentVolumeClaim
      |
      v
 PersistentVolume
      |
      v
Underlying Storage

When dynamic provisioning is enabled, a PVC may trigger the creation of a PV through its StorageClass.

10.2 When should persistent storage be used?

Persistent storage may be appropriate for:

Database data directories.
Application files that must survive Pod replacement.
Durable uploads or other persistent application data.
Workloads that explicitly require filesystem persistence.

It is generally not necessary for every application container.

For example, a stateless Spring Boot web application may not need a PVC if it stores no durable files locally and uses an external database or object storage.

The right storage design depends on the application's data requirements.

10.3 Inspect available StorageClasses

Before creating a PVC, check the cluster:

kubectl get storageclass
kubectl describe storageclass

The available StorageClasses depend on the Kubernetes environment and installed storage provisioners.

A Minikube installation may provide a default StorageClass, but this should be checked rather than assumed.

10.4 PVC example

This example requests 1 GiB of persistent storage:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

This example leaves storageClassName unspecified so that the cluster's default StorageClass can be used when one is configured.

The claim may remain Pending if no suitable StorageClass or matching volume is available.

The access mode ReadWriteOnce generally allows a volume to be mounted read-write by a single node at a time; it does not necessarily mean only one Pod can use it. Actual access behaviour depends on the storage implementation.

10.5 Mount the PVC into a Pod

The claim can be mounted into a container through a Pod or Deployment specification.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: storage-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: storage-demo
  template:
    metadata:
      labels:
        app: storage-demo
    spec:
      containers:
        - name: storage-demo
          image: busybox:1.36
          command:
            - sh
            - -c
            - "while true; do date >> /data/timestamps.txt; sleep 30; done"
          volumeMounts:
            - name: app-data
              mountPath: /data
      volumes:
        - name: app-data
          persistentVolumeClaim:
            claimName: app-data

This is a storage demonstration, not part of the confirmed Spring Boot deployment. It writes timestamps to a file so that persistence can be tested.

Apply the example only in a suitable test namespace:

kubectl apply -f pvc.yaml
kubectl apply -f storage-demo.yaml

Check the claim and Pod:

kubectl get pvc
kubectl get pv
kubectl get pods

Once the Pod is running, inspect the file:

kubectl exec deploy/storage-demo -- cat /data/timestamps.txt

Delete the Pod without deleting the PVC, wait for the replacement Pod, and check the file again. If the same claim is successfully remounted, the file should still contain the previously written data.

The exact behaviour depends on the provisioner and storage configuration.

10.6 What happens when a PVC is deleted?

Deleting a PVC can affect the underlying storage depending on the PV reclaim policy and provisioner.

Common reclaim policies include:

Retain: The volume is retained for manual recovery or reuse.
Delete: The underlying storage may be deleted when the claim is released.

Never assume that deleting a PVC is harmless.

Before testing cleanup, inspect the PV and its reclaim policy:

kubectl get pv
kubectl describe pv PV_NAME

Replace PV_NAME with the actual volume name.

Persistent storage is not a substitute for backups. A durable volume may survive Pod replacement while still being vulnerable to accidental deletion, corruption, or infrastructure failure.

11. Extending the Project to a Frontend and Backend

The original confirmed deployment is a Spring Boot application. If I extend the capstone to a frontend and backend, I would treat them as separate workloads with clearly defined network paths.

For example:

Browser
   |
   v
Frontend Service
   |
   v
Frontend Pods
   |
   v
Backend Service
   |
   v
Backend Pods
   |
   v
Database Service
   |
   v
Database Pods or External Database

This is a reference architecture for a future extension.

The frontend could be a React application served through Nginx, while the backend could be a Spring Boot API or a Node.js service. The backend technology depends on the actual application.

11.1 Frontend Dockerfile example

For a React application built with Vite:

FROM node:22-alpine AS build

WORKDIR /app

COPY package*.json ./
RUN npm ci

COPY . .
RUN npm run build

FROM nginx:alpine

COPY --from=build /app/dist /usr/share/nginx/html

EXPOSE 80

This example assumes the project uses npm, has a valid lockfile, and generates its production build in dist/.

For a single-page application, Nginx may also need a custom configuration to route client-side paths back to index.html.

11.2 Frontend Kubernetes Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  replicas: 2
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
        - name: frontend
          image: example/frontend:1.0.0
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: frontend
spec:
  selector:
    app: frontend
  ports:
    - port: 80
      targetPort: 80
  type: ClusterIP

Replace the example image with an image that actually exists in your registry.

The ClusterIP Service is reachable inside the cluster. External access can be provided through an Ingress, Gateway, LoadBalancer, or a local development mechanism appropriate to the environment.

11.3 Backend Deployment and Service

A generic backend might look like this:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend
spec:
  replicas: 2
  selector:
    matchLabels:
      app: backend
  template:
    metadata:
      labels:
        app: backend
    spec:
      containers:
        - name: backend
          image: example/backend:1.0.0
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 15
            periodSeconds: 20
---
apiVersion: v1
kind: Service
metadata:
  name: backend
spec:
  selector:
    app: backend
  ports:
    - port: 8080
      targetPort: 8080
  type: ClusterIP

This is a generic example. The backend must actually expose /health and return an appropriate successful response. Spring Boot applications may use a different health endpoint depending on their configuration.

The readiness probe determines whether a Pod should receive Service traffic. The liveness probe helps Kubernetes detect certain application states that require a container restart. They serve different purposes, so they should not automatically use the same endpoint in every application.

11.4 How should the frontend reach the backend?

Inside Kubernetes, the frontend can call a backend Service using its DNS name, such as:

http://backend:8080

However, a browser-based React application executes on the user's device, not inside the frontend container. A URL such as http://backend:8080 will not normally resolve in the user's browser.

For browser-based applications, the frontend usually needs a publicly reachable API URL or an Ingress/reverse-proxy arrangement that routes requests to the backend.

The correct approach depends on whether the request originates from browser JavaScript or from a server-side process.

11.5 How would I connect this to GitOps?

The frontend and backend manifests could be organised under one application directory:

apps/
└── web-platform/
    ├── base/
    │   ├── frontend.yaml
    │   ├── backend.yaml
    │   └── kustomization.yaml
    └── overlays/
        ├── staging/
        └── production/

The base would contain shared configuration. Overlays could define environment-specific image tags, replica counts, resources, and other differences.

This layout should be introduced only when the additional workloads have actually been created and tested.

12. Databases and Stateful Workloads

Databases require additional planning because application availability and data durability are different concerns.

A Kubernetes Deployment is commonly used for stateless services. A StatefulSet may be appropriate for a workload that needs stable Pod identities and persistent storage.

A StatefulSet does not automatically make a database highly available, provide safe backups, or configure replication. Those behaviours depend on the database and its operational design.

For a learning environment, a database could use a PVC for its data directory. In a production system, I would evaluate whether a managed database service is more appropriate.

Important database considerations

Persistent storage must be provisioned and mounted correctly.
Database credentials should not be committed to Git.
The database should have appropriate readiness and health checks.
Application connections should use the correct Service name and port.
Backups should be scheduled and restore procedures tested.
Database schema migrations should be managed deliberately.
Storage capacity and performance should be monitored.
A storage snapshot alone should not be assumed to be a consistent database backup.

The application should also handle database startup and temporary connectivity failures without entering an uncontrolled restart loop.

13. GitOps with ArgoCD

GitOps is the practice of using a version-controlled repository to declare the desired state of an environment and a controller to reconcile the actual environment with that desired state.

In this project, ArgoCD monitored:

Repository:
https://github.com/Jahmeeu-Cloud/platform-cicd-gitops-config.git

Path:
apps/spring-boot-app/base

Branch:
main

The application was configured to deploy into the Kubernetes default namespace.

13.1 Inspect the ArgoCD application

kubectl get applications -n argocd
kubectl get application spring-boot-app -n argocd

The expected successful state was Synced and Healthy.

Synced indicates that the managed resources match the desired configuration according to ArgoCD's comparison.

Healthy indicates that ArgoCD considers the resources healthy under its health assessment rules.

Neither status guarantees that every business function works correctly. An HTTP request and application-specific tests provide additional evidence.

13.2 Example ArgoCD Application manifest

The following is an illustrative manifest for the repository and path used in this project:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: spring-boot-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/Jahmeeu-Cloud/platform-cicd-gitops-config.git
    targetRevision: main
    path: apps/spring-boot-app/base
  destination:
    server: https://kubernetes.default.svc
    namespace: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

This is a reference configuration. Use the existing application manifest rather than replacing it blindly.

Automatic pruning can delete resources that are removed from the desired Git configuration. Review its implications before enabling it for important workloads.

13.3 Validate the manifests before committing

From the GitOps repository:

kubectl kustomize apps/spring-boot-app/base

This renders the Kustomize configuration. It is a useful early check that the directory can be processed.

After a change, inspect the rendered output and review the diff:

git status
git diff

Then commit and push the intended files:

git add apps/spring-boot-app/base
git commit -m "Update application deployment configuration"
git push origin main

Run these commands from the GitOps repository and confirm that the correct remote and branch are configured before pushing.

13.4 Verify reconciliation

kubectl get application spring-boot-app -n argocd
kubectl get deployment spring-boot-app
kubectl get pods

The aim is to confirm that the Git-defined desired state has been applied and the expected Pods are running.

[SCREENSHOT - ARGOCD APPLICATION STATUS HERE]

Suggested caption: ArgoCD was tracking the GitOps repository and reporting the synchronisation and health of the application.

14. Testing GitOps Self-Healing

The most useful test in this project was deliberately changing the live Deployment and observing how ArgoCD responded.

The GitOps configuration declared three replicas.

I manually changed the live Deployment to one replica:

kubectl scale deployment spring-boot-app --replicas=1

Then I watched the Deployment:

kubectl get deployment spring-boot-app --watch

Because the ArgoCD application was configured for automated synchronisation and self-healing, ArgoCD detected the difference between the live configuration and the desired state in Git.

The replica count returned to three.

What did this prove?

The test demonstrated that the GitOps controller could correct this particular kind of configuration drift.

The process was:

Git declared three replicas.
The live Deployment was manually scaled down to one.
The live state no longer matched the desired state.
ArgoCD detected the difference.
Automated reconciliation restored the declared replica count.
Kubernetes worked towards the desired three-replica state.

This is a practical example of declarative operations.

It also shows why manual changes to GitOps-managed resources may be temporary. If the desired state remains unchanged in Git, the controller may restore it.

Does self-healing fix every problem?

No.

ArgoCD can reconcile managed resources with the desired configuration, but it cannot automatically solve every application bug, exhausted storage volume, invalid image, external database outage, or cluster networking problem.

Self-healing is a reconciliation capability, not a replacement for monitoring, testing, and operational troubleshooting.

[SCREENSHOT - THE DEPLOYMENT AT ONE REPLICA HERE AND THE DEPLOYMENT RESTORED TO THREE REPLICAS HERE]

Suggested caption: I deliberately changed the live replica count and observed ArgoCD restore the desired state defined in Git.

15. Verifying the Application End to End

A successful Jenkins build is not the same as a successful application deployment.

I validated the Kubernetes resources and tested the application endpoint independently.

15.1 Check the Deployment

kubectl get deployment spring-boot-app

Inspect the replica counts and confirm that the expected Pods become ready.

15.2 Check the Pods

kubectl get pods -o wide

If a Pod is not ready, investigate it:

kubectl describe pod POD_NAME
kubectl logs POD_NAME

Replace POD_NAME with the actual Pod name.

15.3 Check the Service

kubectl get service spring-boot-app-service
kubectl get endpoints spring-boot-app-service

The endpoints help show whether the Service has selected and is routing to suitable Pods.

15.4 Find the current Minikube access address

For a NodePort Service:

minikube ip
kubectl get service spring-boot-app-service

Use the returned IP and NodePort to construct the URL, provided the Minikube networking setup supports direct access that way.

Alternatively:

minikube service spring-boot-app-service --url

The command may open a tunnel or return a URL depending on the driver and operating environment. Follow any instructions printed by Minikube.

15.5 Send an HTTP request

For example:

curl -i http://MINIKUBE_IP:NODE_PORT

Replace the placeholders with the actual address and port.

In the test performed for this project, the application endpoint returned HTTP 200.

That result confirmed that the tested route responded successfully. It did not, by itself, prove that every application function was correct.

What did the end-to-end test validate?

The Deployment existed.
Kubernetes created application Pods.
The Service selected the intended workload.
The endpoint was reachable through the tested access path.
The application returned a successful HTTP response.

Together, these checks provided stronger evidence than a successful build result alone.

16. Probes, Resource Requests, and Limits

For a more robust deployment, I would extend the Deployment with resource settings and appropriate health probes.

An illustrative container section is:

containers:
  - name: spring-boot-app
    image: horlacloud/spring-boot-demo:20
    ports:
      - name: http
        containerPort: 8080
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"
      limits:
        cpu: "500m"
        memory: "512Mi"
    readinessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 10
    livenessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 20
      periodSeconds: 20

These values are examples, not measurements from the capstone.

The application must actually expose the configured health endpoint. A Spring Boot application may require an appropriate health endpoint configuration, and the route may differ from /health.

Resource requests influence scheduling. Resource limits constrain how much CPU or memory the container may consume under the configured runtime rules.

A readiness probe helps determine when a container should receive Service traffic. A liveness probe helps Kubernetes decide whether to restart a container that appears unable to recover.

Probe configuration must reflect the application's real startup and recovery behaviour. Aggressive probes can make a slow-starting application less reliable rather than more reliable.

17. Availability, Scaling, and Reliability

These concepts are related, but they are not interchangeable.

Availability

Three replicas provide multiple application instances, but three replicas on a single-node local cluster do not provide node-level high availability.

If the only node fails, all Pods on that node may become unavailable.

A production design would consider multiple nodes, appropriate failure-domain placement, load balancing, cluster capacity, persistent storage, and recovery procedures.

Scalability

A Deployment's replica count can be changed manually:

kubectl scale deployment spring-boot-app --replicas=3

A Horizontal Pod Autoscaler can be introduced to adjust the number of replicas based on metrics.

For example:

kubectl autoscale deployment spring-boot-app \
  --cpu-percent=70 \
  --min=2 \
  --max=10

This is an optional extension. It requires a working metrics source and suitable resource requests. It should not be described as implemented unless the HPA was actually created and verified.

Scaling Pods also does not guarantee greater throughput if the application depends on a saturated database or another bottleneck.

Reliability

Reliability depends on more than the number of replicas. It also depends on application health checks, dependency availability, resource planning, configuration management, observability, and tested recovery procedures.

GitOps adds a useful form of configuration consistency by making the desired state explicit and version-controlled.

18. Troubleshooting Guide

A repeatable troubleshooting approach starts by identifying which layer is failing.

Jenkins pipeline fails

Inspect the failed stage and the console output.

Question: Did checkout, build, test, image build, or push fail?

If checkout fails, check the repository URL, branch, network connectivity, and credential requirements.

If Maven fails, inspect the compilation or test output before changing Docker configuration.

If Docker fails, inspect the Dockerfile, build context, daemon access, and image tag.

If the GitOps update fails, inspect the GitHub credential ID, credential type, token permissions, branch rules, and remote URL.

ImagePullBackOff

Check the Pod events:

kubectl describe pod POD_NAME

Common causes include:

Incorrect image name or tag.
Image not present in the registry.
Private registry authentication not configured.
Registry connectivity issues.
Architecture incompatibility.

Do not assume that an image was successfully published merely because the local Docker build passed.

CrashLoopBackOff

Inspect the container logs and events:

kubectl logs POD_NAME
kubectl describe pod POD_NAME

Possible causes include a bad startup command, application configuration problems, missing environment variables, dependency failures, or memory constraints.

Service has no endpoints

Inspect the Service selector and Pod labels:

kubectl describe service spring-boot-app-service
kubectl get pods --show-labels
kubectl get endpoints spring-boot-app-service

The Service selector must match the intended Pods. Pods that are not ready may not be included as normal Service endpoints.

PVC remains Pending

Check the claim and StorageClass:

kubectl describe pvc app-data
kubectl get storageclass
kubectl get pv

Possible causes include an unavailable provisioner, no matching volume, an unsupported access mode, or insufficient capacity.

ArgoCD reports OutOfSync

Inspect the application status and compare the live state with Git.

Check whether:

The correct repository is configured.
The expected branch and path are selected.
The commit was pushed successfully.
The manifests render correctly.
Automatic synchronisation is configured.
The controller can access the repository.

If manual changes keep being reverted, check whether self-healing is enabled and whether the resource is managed by the ArgoCD application.

HTTP request fails

Work from the inside out:

Check Pod readiness.
Inspect application logs.
Check the Service selector.
Check Service endpoints.
Confirm the application listens on the expected container port.
Confirm the correct NodePort, tunnel, or ingress route.
Test the correct application path.

This process avoids changing several layers at once without knowing which one is responsible.

19. Security Practices

The project interacts with several systems that require controlled access.

Jenkins

Restrict administrative access.
Maintain Jenkins and its plugins.
Store secrets in Jenkins Credentials.
Review Jenkinsfile changes.
Avoid exposing secrets in console output.
Restrict the privileges available to build agents.

GitHub

Use narrowly scoped credentials.
Protect important branches.
Require reviews where appropriate.
Never commit tokens or passwords.
Review repository permissions before allowing automated writes.

Docker

Prefer maintained base images.
Scan images for vulnerabilities where tooling is available.
Use non-root containers when practical.
Avoid embedding secrets in images.
Use traceable image versions.

Kubernetes

Apply appropriate resource requests and limits.
Use security contexts.
Restrict network access where practical.
Use readiness and liveness probes thoughtfully.
Protect Secrets through access control and appropriate encryption configuration.
Limit service-account permissions.

GitOps

Review changes before promoting them to important environments.
Understand the effect of automated pruning.
Protect the branch used by ArgoCD.
Keep sensitive values out of ordinary deployment manifests.
Make rollback procedures explicit and testable.

These controls are part of the delivery architecture, not optional additions that can be ignored until a security incident occurs.

20. Reusability and Future Platform Improvements

One of the main benefits of declarative configuration is the ability to reuse it.

Kustomize allows a project to maintain a common base and apply environment-specific overlays.

A possible future layout is:

apps/
└── spring-boot-app/
    ├── base/
    │   ├── deployment.yaml
    │   ├── service.yaml
    │   └── kustomization.yaml
    └── overlays/
        ├── staging/
        │   └── kustomization.yaml
        └── production/
            └── kustomization.yaml

The base defines shared resources. Overlays can customise image tags, replica counts, and other settings for different environments.

This is a suggested extension rather than a description of already completed overlays.

Before committing configuration changes, render the manifests:

kubectl kustomize apps/spring-boot-app/base

Then review the result and the Git diff:

git diff
git status

A reusable deployment pattern should reduce repetitive work while keeping the resulting configuration understandable to the engineers responsible for operating it.

21. Version Control, Backups, and Cleanup

Version control records configuration changes, but it is not a complete backup strategy for every kind of project data.

The source and GitOps repositories provide a record of the files committed at specific revisions.

The GitOps repository's last confirmed commit during this work was:

dc9e323 Fix deployment YAML and set replicas to three

That commit recorded a change to the deployment configuration.

For future maintenance, I would ensure that:

The intended files are committed.
Generated build output is excluded when appropriate.
The remote URL points to the correct repository.
The default branch contains the intended configuration.
Deployment manifests render successfully.
The deployed image tag corresponds to a published image.
Credentials remain outside Git.
Persistent data is backed up separately when required.

Before cleaning up a cloud environment, identify which resources belong to the project and whether any contain data that must be retained.

Before deleting a PVC, inspect its reclaim policy and confirm that important data is backed up.

Before deleting an AWS resource, verify that it is not shared with another workload or still required by a running service.

Cleanup should be deliberate, documented, and reversible where practical.

22. What I Would Improve Before Calling This Production-Ready

The project was a hands-on learning environment, not a claim of a production-grade platform.

The next improvements I would prioritise are:

Immutable image references: Use unique release tags or image digests.
Automated testing: Ensure the pipeline stops when tests fail.
Pull-request validation: Run build and manifest checks before changes reach the deployment branch.
Controlled promotion: Promote a tested image through staging and production with appropriate approvals.
Supply-chain security: Scan dependencies and container images.
Observability: Add application metrics, dashboards, logs, and actionable alerts.
Production networking: Use a suitable ingress or gateway and secure TLS configuration.
High availability: Design for node failures and relevant failure domains.
Data protection: Implement and test database backup and restore procedures where persistent data is involved.
Recovery testing: Practise rolling back to a known-good configuration and image.
Least privilege: Reduce the permissions available to Jenkins, ArgoCD, and application workloads.
Environment isolation: Separate staging and production access and configuration.

A platform becomes more mature when it can not only deploy software but also explain its state, recover from expected failures, and make unsafe changes more difficult.

23. Final Results and Validation Checklist

The following table separates the demonstrated project outcomes from optional extensions.

Area	Result or validation
Jenkins	A successful pipeline build was achieved by the 20th CI/CD pipeline build
Credential troubleshooting	Identified the `github-credentials` lookup error as a credential reference issue
Source control	Application source stored in its GitHub repository
GitOps configuration	Deployment configuration stored in a separate repository
Container image	Docker image publication was part of the workflow
Kubernetes	Spring Boot application managed through a Deployment and Service
Replicas	GitOps configuration declared three replicas
ArgoCD	Application managed through the GitOps repository
Self-healing	A manual scale-down was corrected back to the Git-defined replica count
Application testing	The tested endpoint returned HTTP 200
Persistent storage	Documented as a reusable extension; verify separately if it was implemented
Frontend and backend	Documented as a reference extension, not part of the confirmed Spring Boot-only deployment
Production monitoring and HA	Recommended future improvements, not assumed to be implemented

Final validation commands

Run these commands against the relevant environment:

# Kubernetes cluster
kubectl get nodes -o wide

# Deployment and Pods
kubectl get deployment spring-boot-app
kubectl get pods -o wide

# Service and endpoints
kubectl get service spring-boot-app-service
kubectl get endpoints spring-boot-app-service

# ArgoCD application
kubectl get application spring-boot-app -n argocd

# Render the GitOps manifests
kubectl kustomize apps/spring-boot-app/base

# Review Git changes from the GitOps repository
git status
git log -5 --oneline

The last two Git commands should be run from the GitOps repository. The Kubernetes commands should be run against the cluster and namespace where the application is deployed.

[SCREENSHOT - FINAL KUBERNETES STATUS HERE]

[SCREENSHOT - FINAL ARGOCD SYNCHRONISATION STATUS HERE]

[SCREENSHOT - THE FINAL SUCCESSFUL APPLICATION TEST HERE]

24. What I Learned From This Capstone

This project strengthened my understanding of how application delivery works across several connected systems.

I learned that:

A pipeline is a sequence of dependent operations, and each stage must be debugged at the correct layer.
Credential IDs, credential types, authentication, and permissions are separate concerns.
Docker image publication does not prove that an application has deployed successfully.
Kubernetes Deployments manage desired replica counts, while Services provide stable access to selected Pods.
Persistent storage requires deliberate planning around claims, volumes, lifecycle, and recovery.
GitOps makes the desired state visible and version-controlled.
ArgoCD self-healing can correct configuration drift when the desired state and synchronisation policy support it.
Application health must be verified independently of build and deployment status.
Three replicas on a local Minikube cluster do not constitute production high availability.
Security, observability, backups, and rollback procedures are part of operating a platform.

The most memorable part was the troubleshooting. The Jenkins credential error was frustrating, but it taught me to stop guessing and investigate the exact failure.

When an earlier pipeline stage succeeds and a later stage fails, the answer is not necessarily to rebuild everything. The better approach is to identify the failing operation, inspect its dependencies, and verify the relevant configuration.

Conclusion

This capstone gave me practical experience connecting Jenkins, GitHub, Maven, Docker, Kubernetes, and ArgoCD into a repeatable delivery workflow.

It also helped me understand why CI/CD and GitOps are complementary. CI/CD automates the process of validating and packaging application changes. GitOps provides a declarative way to manage the desired deployment state and reconcile the running environment with it.

The project is a foundation I can continue improving with stronger automated testing, a more complete frontend/backend architecture, persistent data services where needed, better monitoring, and more production-oriented security and availability controls.

My biggest takeaway is that the tools are only part of the work. Understanding the connections between them, investigating failures systematically, and being able to explain the result are just as important.

For anyone learning DevOps or platform engineering, I would encourage you to document not only what worked but also the errors you encountered, how you investigated them, and what the final tests proved.

That is what turns a practical exercise into knowledge you can reuse in your next project.

Project References

GitHub profile:

https://github.com/Jahmeeu-Cloud

Application source repository:

https://github.com/Jahmeeu-Cloud/platform-cicd-spring-boot-demo-source

GitOps configuration repository:

https://github.com/Jahmeeu-Cloud/platform-cicd-gitops-config

Author: Jamiu Olatunji Bakre
Cloud, DevOps and Platform Engineer

This article documents a hands-on learning project and includes additional reference configurations for future extensions. Optional components are identified separately from the functionality verified in the original environment.

Capstone Project: Building an End-to-End AWS Kubernetes Platform with Terraform, Docker, Amazon EKS, and PostgreSQL

BAKRE JAMIU — Sun, 18 Oct 2026 16:25:51 +0000

A practical Platform Engineering capstone: from infrastructure provisioning to application deployment, persistent storage, autoscaling, validation, and cleanup

Author: Jamiu Bakre

Project: AWS Kubernetes Platform Engineering Capstone

Cloud Provider: Amazon Web Services (AWS)

Infrastructure as Code: Terraform

Containerization: Docker

Container Orchestration: Kubernetes on Amazon EKS

Container Registry: Amazon Elastic Container Registry (ECR)

Application Load Balancing: AWS Application Load Balancer (ALB)

Database: PostgreSQL

Primary AWS Region: eu-west-1

Kubernetes Cluster: platform-capstone-prod

1. Introduction

One of the things I wanted to achieve with this capstone was to go beyond deploying an application to a cloud server. I wanted to build a platform that demonstrated how cloud infrastructure, containers, Kubernetes, persistent storage, networking, security, monitoring, and automation work together in a production-oriented environment.

The project started with a familiar application architecture: a frontend, a backend API, and a PostgreSQL database. Rather than deploying these components manually to individual servers, I used Terraform to define the cloud infrastructure and Kubernetes to manage the application workloads.

The goal was to create an environment that could be provisioned consistently, support application deployment, recover from ordinary workload failures, scale when demand increased, and provide a clear path for future improvements.

This was also an opportunity to bring together several areas of cloud and platform engineering:

Infrastructure as Code with Terraform.
AWS networking and private application infrastructure.
Container image creation with Docker.
Image storage and distribution through Amazon ECR.
Kubernetes workload orchestration with Amazon EKS.
Persistent application data using PostgreSQL, PersistentVolumes, and PersistentVolumeClaims.
External application access through an AWS Application Load Balancer.
Health monitoring, resource requests and limits, and Horizontal Pod Autoscaling.
Infrastructure validation, application testing, documentation, and cleanup.

Frontend

Backend

Backend health Status

Live status

The important part of this project was not simply getting the application to run. It was understanding how each component depends on the others and how to validate the system as a whole.

Project objectives

The main objectives were to:

Provision the AWS infrastructure using Terraform.
Create a VPC with public and private subnets.
Deploy an Amazon EKS cluster with managed worker nodes.
Build and publish the frontend and backend container images to Amazon ECR.
Deploy the frontend, backend API, and PostgreSQL database to Kubernetes.
Expose the frontend through an AWS Application Load Balancer.
Configure persistent database storage.
Implement application health probes and resource management.
Configure and validate Horizontal Pod Autoscaling.
Test database recovery after a PostgreSQL Pod restart.
Validate the Terraform configuration and maintain the project in GitHub.
Clean up the deployed infrastructure while preserving the Terraform state in Amazon S3.

[Screenshot: Capstone assignment and objectives.]

[Screenshot: The GitHub repository homepage showing the project files.]

2. Understanding the architecture

Before writing Terraform or Kubernetes manifests, it is useful to understand how the application and infrastructure fit together.

The platform has three application components:

Frontend: serves the user-facing web application.
Backend: provides application logic and API endpoints.
PostgreSQL: stores application data and provides persistent database storage.

The frontend and backend run as Kubernetes Deployments. PostgreSQL runs as a StatefulSet with persistent storage. Kubernetes Services provide stable internal networking, while an Ingress resource instructs the AWS Load Balancer Controller to create an Application Load Balancer for external access.

High-level architecture

                         Internet
                            |
                            v
                 AWS Application Load Balancer
                            |
                            v
                  Kubernetes Ingress
                            |
                            v
                    Frontend Service
                            |
                            v
                    Frontend Pods
                            |
                       API requests
                            |
                            v
                    Backend Service
                            |
                            v
                    Backend Pods
                            |
                            v
                    PostgreSQL Service
                            |
                            v
                   PostgreSQL StatefulSet
                            |
                            v
                  PersistentVolumeClaim
                            |
                            v
                 Encrypted EBS gp3 Volume


       AWS Infrastructure managed with Terraform
       -------------------------------------------
       VPC
       ├── Public subnets
       ├── Private subnets
       ├── Internet Gateway
       ├── NAT Gateways
       ├── Route tables
       ├── Security groups
       ├── Amazon EKS cluster
       ├── Managed worker node group
       └── Amazon ECR repositories

       Container delivery
       ------------------
       Application source code
                |
                v
             Docker
                |
                v
          Amazon ECR
                |
                v
          Amazon EKS

Important networking distinction: the deployed Ingress configuration routed public traffic to the frontend on HTTP port 80. The backend and PostgreSQL were intended to remain internal services. The diagram illustrates the application's logical communication path; actual browser-to-backend communication depends on the frontend configuration, such as an Nginx API proxy or additional Ingress rules.

[Screenshot: Architecture diagram.]

How the components work together

When a user visits the application, the request reaches the Application Load Balancer. The ALB routes traffic according to the Kubernetes Ingress configuration. In this implementation, the root path / routes to the frontend service.

The frontend runs in one or more Pods. When it needs backend functionality, it communicates with the backend through the configured API endpoint. The backend communicates with PostgreSQL through an internal Kubernetes Service.

Kubernetes continuously monitors the declared workloads. If a frontend or backend Pod fails, the corresponding Deployment can create a replacement. PostgreSQL uses a StatefulSet and a PersistentVolumeClaim so that database storage can outlive an individual Pod.

Terraform manages the AWS infrastructure, while Kubernetes manages the application workloads. Keeping these responsibilities separate makes the platform easier to maintain.

3. Technology stack

Technology	Purpose
AWS VPC	Isolated cloud networking
Public and private subnets	Network separation and workload placement
Internet Gateway	Internet connectivity for public resources
NAT Gateways	Outbound connectivity from private subnets
Terraform	Reproducible infrastructure provisioning
Amazon EKS	Managed Kubernetes control plane
EKS managed node group	Worker compute capacity
Amazon ECR	Container image registry
Docker	Application containerization
Kubernetes Deployment	Frontend and backend workload management
Kubernetes Service	Stable internal networking
StatefulSet	Stable identity and storage association for PostgreSQL
PersistentVolumeClaim	Request for persistent storage
Amazon EBS CSI driver	Provisioning and attachment of EBS storage
AWS Load Balancer Controller	AWS load balancer integration with Kubernetes
Application Load Balancer	Public HTTP entry point
Metrics Server	Kubernetes resource usage metrics
Horizontal Pod Autoscaler	Automatic replica scaling
Amazon S3	Remote Terraform state storage
Git and GitHub	Version control and project delivery

[Screenshot: Terraform, Docker, Kubernetes and AWS tools used in the project.]

Phase 1: Preparing the development environment

4. Tools and prerequisites

Before provisioning infrastructure, the local environment needs the tools required to create cloud resources, build containers, and interact with Kubernetes.

The main tools used in this project were:

AWS CLI.
Terraform.
Docker.
kubectl.
Git.
Helm.
Graphviz, for generating a Terraform dependency graph.

The development environment was Ubuntu under Windows Subsystem for Linux (WSL).

4.1 Verify the installed tools

Run the following commands in your terminal:

aws --version
terraform version
docker --version
kubectl version --client
helm version
git --version

If you intend to generate an infrastructure dependency graph, verify Graphviz as well:

dot -V

If Graphviz is not installed in Ubuntu:

sudo apt update
sudo apt install graphviz

4.2 Configure AWS access

Configure the AWS CLI using your approved AWS credentials:

aws configure

The CLI prompts for an access key, secret key, default region, and output format. Use an IAM identity with the permissions needed for the project. Never commit AWS credentials to Git.

Verify which account is active:

aws sts get-caller-identity

The output identifies the AWS account and the IAM identity used for subsequent operations.

Confirm the intended region:

aws configure get region

For this project, the primary region was:

eu-west-1

If necessary, set a shell variable for the current session:

export AWS_REGION="eu-west-1"
export AWS_DEFAULT_REGION="$AWS_REGION"

Why this matters: AWS commands can create or destroy real resources. Confirming the account and region before running Terraform prevents accidental changes to another environment.

Phase 2: Organizing the project

5. Repository structure

A well-organized repository separates infrastructure configuration, reusable Terraform modules, Kubernetes manifests, and application source code.

The following is a representative structure for this project. Adjust the file names to match the actual repository before publishing it.

platform-capstone/
├── terraform/
│   ├── bootstrap/
│   │   └── main.tf
│   ├── environments/
│   │   └── prod/
│   │       ├── main.tf
│   │       ├── variables.tf
│   │       ├── outputs.tf
│   │       ├── providers.tf
│   │       ├── versions.tf
│   │       └── backend.tf
│   └── modules/
│       ├── vpc/
│       ├── ecr/
│       └── eks/
├── app/
│   ├── frontend/
│   │   ├── Dockerfile
│   │   └── nginx.conf
│   └── backend/
│       ├── Dockerfile
│       ├── package.json
│       └── server.js
├── k8s/
│   ├── namespace.yaml
│   ├── postgres-secret.example.yaml
│   ├── postgres-service.yaml
│   ├── postgres-statefulset.yaml
│   ├── frontend-deployment.yaml
│   ├── frontend-service.yaml
│   ├── backend-deployment.yaml
│   ├── backend-service.yaml
│   ├── hpa.yaml
│   └── ingress.yaml
├── docs/
│   └── screenshots/
├── .gitignore
└── README.md

The exact repository may use a different layout. The key principle is to keep reusable infrastructure modules separate from the environment-specific configuration.

5.1 Why separate Terraform modules?

Modules allow infrastructure components to be defined once and reused.

For example, the VPC module can own the VPC, subnets, routes, and networking resources. The ECR module can create repositories. The EKS module can manage the Kubernetes cluster and worker nodes.

The production environment then connects these modules by passing outputs from one module into another.

This reduces duplication and makes the infrastructure easier to review and extend.

Phase 3: Provisioning infrastructure with Terraform

6. Terraform design

Terraform was used to define the AWS resources declaratively. Instead of creating resources individually through the AWS Console, the configuration describes the desired infrastructure and allows Terraform to determine the required changes.

The core infrastructure consisted of:

A VPC.
Public and private subnets across two Availability Zones.
Internet and NAT connectivity.
Route tables and security controls.
Amazon EKS.
Managed worker nodes.
Amazon ECR repositories.

The deployed worker nodes were two t3.medium instances. The EKS cluster was named platform-capstone-prod and used Kubernetes version 1.35.

6.1 Configure the Terraform provider

A representative provider configuration is:

terraform {
  required_version = ">= 1.5.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

provider "aws" {
  region = var.aws_region

  default_tags {
    tags = {
      Project     = "platform-capstone"
      Environment = "prod"
      ManagedBy   = "Terraform"
    }
  }
}

variable "aws_region" {
  description = "AWS region for the platform"
  type        = string
  default     = "eu-west-1"
}

The AWS provider version constraint should match the version selected and tested in the repository's lock file. Do not upgrade a working provider configuration without reviewing the plan.

Default tags make resources easier to identify for operations, auditing, and cost analysis.

6.2 Define the infrastructure modules

A simplified root configuration could look like this:

module "vpc" {
  source = "../../modules/vpc"

  name               = "platform-capstone-prod"
  vpc_cidr           = "10.0.0.0/16"
  availability_zones = ["eu-west-1a", "eu-west-1b"]

  public_subnet_cidrs = [
    "10.0.1.0/24",
    "10.0.2.0/24"
  ]

  private_subnet_cidrs = [
    "10.0.11.0/24",
    "10.0.12.0/24"
  ]
}

module "ecr" {
  source = "../../modules/ecr"

  repositories = [
    "platform-capstone-prod/frontend",
    "platform-capstone-prod/backend"
  ]
}

module "eks" {
  source = "../../modules/eks"

  cluster_name       = "platform-capstone-prod"
  kubernetes_version = "1.35"

  vpc_id             = module.vpc.vpc_id
  private_subnet_ids = module.vpc.private_subnet_ids
}

This is an illustrative module interface, not a complete drop-in configuration. The variables and outputs must correspond to those defined in the actual modules.

The EKS module also needs to define the cluster IAM permissions, managed node group, networking configuration, and any required access entries or authentication configuration.

6.3 Build the VPC

The VPC provides the network boundary for the platform.

The project used two public subnets and two private subnets across two Availability Zones.

Public subnets support resources that require a route to the Internet Gateway, such as an internet-facing ALB. Private subnets are appropriate for worker nodes and other internal workloads.

The public route table typically includes a default route to the Internet Gateway:

resource "aws_route" "public_internet" {
  route_table_id         = aws_route_table.public.id
  destination_cidr_block = "0.0.0.0/0"
  gateway_id             = aws_internet_gateway.this.id
}

Private subnets can use NAT Gateways for outbound connectivity where required. A NAT Gateway is not a substitute for security groups or application authentication; it provides network address translation for outbound connections.

This design improves network separation, but it has a cost implication. NAT Gateways incur hourly and data-processing charges. The capstone used two NAT Gateways, one for each Availability Zone.

[Screenshot: The Terraform plan showing the VPC, subnet, route, and gateway resources.]

[Screenshot: The AWS VPC console showing the public and private subnets across two Availability Zones.]

6.4 Create Amazon ECR repositories

Amazon ECR stores the Docker images that Kubernetes pulls when starting application Pods.

The two repositories were:

platform-capstone-prod/frontend
platform-capstone-prod/backend

A Terraform module can create them using aws_ecr_repository. The following is a representative resource:

resource "aws_ecr_repository" "frontend" {
  name                 = "platform-capstone-prod/frontend"
  image_tag_mutability = "IMMUTABLE"

  image_scanning_configuration {
    scan_on_push = true
  }

  encryption_configuration {
    encryption_type = "AES256"
  }

  tags = {
    Project = "platform-capstone"
  }
}

Repeat the configuration for the backend or use a reusable module.

Immutable tags help prevent a tag from being silently reassigned to another image. If you use immutable tags, publish new version tags for each build instead of repeatedly pushing to the same tag.

6.5 Create the EKS cluster and worker nodes

Amazon EKS manages the Kubernetes control plane. The worker nodes provide compute capacity for application Pods.

The platform used:

Cluster name: platform-capstone-prod.
Kubernetes version: 1.35.
Managed worker nodes: two t3.medium instances.
Worker placement: private subnets.
VPC networking: the VPC created by Terraform.

The EKS module must define a cluster IAM role, node IAM role, networking, cluster access, and the managed node group. It should also establish appropriate security group rules.

The control plane and worker nodes have different responsibilities. The control plane manages the Kubernetes API, scheduling, and cluster state. The worker nodes run the actual application containers.

[Screenshot: The EKS console showing platform-capstone-prod and the active node group.]

6.6 Initialize, validate, plan, and apply

Run Terraform commands from the correct root directory:

cd ~/platform-capstone/terraform/environments/prod

terraform fmt -recursive
terraform init
terraform validate
terraform plan

Review the plan carefully before applying it:

terraform apply

Terraform displays the proposed actions and requests confirmation. Review resource creation, replacement, and destruction before approving.

After deployment, verify the state:

terraform state list
terraform output

The exact outputs depend on the repository configuration.

Why this sequence matters:

terraform fmt standardizes formatting.
terraform init initializes providers, modules, and the backend.
terraform validate checks the configuration for structural errors.
terraform plan previews the intended changes.
terraform apply executes the approved plan.
terraform state list helps verify which resources Terraform is tracking.

A successful terraform validate does not prove that AWS resources can be created or that the application works. Those require deployment and runtime testing.

7. Remote Terraform state with Amazon S3

Terraform state records the mapping between Terraform resource definitions and the infrastructure Terraform manages.

For this project, the remote state bucket was:

platform-capstone-terraform-state-911xxxx03075

The state key was:

platform-capstone/prod/terraform.tfstate

The backend was configured for eu-west-1, with S3 versioning and public access blocking. The configuration used server-side encryption and S3-native state locking through use_lockfile.

A representative backend block is:

terraform {
  backend "s3" {
    bucket       = "platform-capstone-terraform-state-9111xxxx3075"
    key          = "platform-capstone/prod/terraform.tfstate"
    region       = "eu-west-1"
    encrypt      = true
    use_lockfile = true
  }
}

The bucket must exist before Terraform can initialize this backend. For a fresh deployment, the bootstrap process should create and secure the bucket first.

Why remote state matters

Remote state provides a central location for Terraform's resource mapping. It is particularly useful when working across different sessions or collaborating with other engineers.

State files may contain sensitive values. Restrict access through IAM, prevent public access, enable versioning, and never commit state files to a public Git repository.

After the capstone teardown, the state file remained in S3. This preserves the deployment record, but it does not mean the AWS infrastructure is still running.

Phase 4: Building and publishing container images

8. Why Docker was used

Docker packages an application and its runtime dependencies into a container image. The image can be built once, stored in a registry, and deployed consistently across environments.

The platform used separate images for the frontend and backend:

frontend:v2
backend:v1

The images were stored in Amazon ECR.

Using separate images also allows each component to be deployed and updated independently.

9. Building the backend API image

The backend used Node.js and Express and listened on port 5000. It exposed liveness and readiness endpoints:

/health/live
/health/ready

The liveness endpoint indicates whether the process is alive. The readiness endpoint checks whether the application is ready to receive traffic and, in this implementation, includes a database connectivity check.

9.1 Representative backend application

The following is a simplified example of the pattern. Adapt it to the actual backend source and database library.

const express = require("express");

const app = express();
const port = process.env.PORT || 5000;

app.use(express.json());

app.get("/health/live", (_req, res) => {
  res.status(200).json({ status: "alive" });
});

app.get("/health/ready", async (_req, res) => {
  try {
    // Replace this with a real PostgreSQL connectivity check.
    res.status(200).json({ status: "ready" });
  } catch (_error) {
    res.status(503).json({ status: "not-ready" });
  }
});

app.get("/api", (_req, res) => {
  res.json({ message: "Backend API is running" });
});

app.listen(port, "0.0.0.0", () => {
  console.log(`Backend listening on port ${port}`);
});

Important: the example readiness handler does not actually connect to PostgreSQL. In the deployed application, readiness must query the database or use the real connection pool to verify connectivity. A successful HTTP response alone is not proof that the database is healthy.

9.2 Representative backend Dockerfile

FROM node:22-alpine

WORKDIR /app

COPY package*.json ./
RUN npm ci --omit=dev

COPY . .

ENV NODE_ENV=production
ENV PORT=5000

USER node

EXPOSE 5000

CMD ["node", "server.js"]

This example uses a non-root runtime user. The Node.js version must match the application's supported runtime and the version actually tested in the repository.

For a production image, also consider a .dockerignore file, dependency pinning, vulnerability scanning, and reducing unnecessary files in the image.

Example .dockerignore:

node_modules
.git
.env
npm-debug.log
coverage

Caveat: Do not copy production credentials into the image!

10. Building the frontend image

The frontend was served using Nginx on port 8080, running as a non-root user.

For a static frontend, a multi-stage Docker build can compile the application and then copy only the production assets into the Nginx image.

10.1 Representative frontend Dockerfile

FROM node:22-alpine AS build

WORKDIR /app

COPY package*.json ./
RUN npm ci

COPY . .
RUN npm run build

FROM nginxinc/nginx-unprivileged:stable-alpine

COPY --from=build /app/dist/ /usr/share/nginx/html/

EXPOSE 8080

This example assumes the frontend build output is dist/. Change the source path if the application uses a different build directory.

If the frontend needs a custom Nginx configuration, provide one compatible with the unprivileged Nginx image. Do not assume the default configuration listens on port 8080; verify it.

10.2 Build and test the images locally

Example commands:

docker build -t platform-frontend:v2 ./app/frontend
docker build -t platform-backend:v1 ./app/backend

Check the image sizes:

docker image ls

The capstone assessment included a target of keeping both images below 150 MB. Check the actual image sizes rather than assuming the target was met.

Run the containers locally before publishing:

docker run --rm -p 8080:8080 platform-frontend:v2

In another terminal, test the frontend:

curl -I http://localhost:8080/

For the backend:

docker run --rm -p 5000:5000 platform-backend:v1

Then test the health endpoint:

curl -i http://localhost:5000/health/live

Use the application's actual database configuration when testing readiness. If the database is unavailable, a correctly implemented readiness check should not claim the application is ready.

11. Push images to Amazon ECR

Before pushing, obtain the AWS account ID:

AWS_ACCOUNT_ID=$(aws sts get-caller-identity \
  --query Account --output text)

AWS_REGION="eu-west-1"

Log Docker into ECR:

aws ecr get-login-password --region "$AWS_REGION" |
  docker login \
    --username AWS \
    --password-stdin \
    "${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com"

Define the image URIs:

FRONTEND_URI="${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/platform-capstone-prod/frontend"
BACKEND_URI="${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/platform-capstone-prod/backend"

Tag the images:

docker tag platform-frontend:v2 "${FRONTEND_URI}:v2"
docker tag platform-backend:v1 "${BACKEND_URI}:v1"

Push them:

docker push "${FRONTEND_URI}:v2"
docker push "${BACKEND_URI}:v1"

Verify the repository images:

aws ecr describe-images \
  --repository-name platform-capstone-prod/frontend \
  --region "$AWS_REGION"

aws ecr describe-images \
  --repository-name platform-capstone-prod/backend \
  --region "$AWS_REGION"

The EKS worker nodes must have permission to pull these images. This normally involves the appropriate ECR permissions on the node IAM role or another configured image-pull identity.

Why use ECR? It provides a private registry integrated with AWS IAM. It separates the process of building an image from the process of deploying that image.

[Screenshot: The ECR frontend and backend repository with its image tag.]

Phase 5: Configuring access to Amazon EKS

12. Connect kubectl to the cluster

After Terraform creates the EKS cluster, configure kubectl to use it:

aws eks update-kubeconfig \
  --region eu-west-1 \
  --name platform-capstone-prod

Verify the active context:

kubectl config current-context
kubectl cluster-info

Check the worker nodes:

kubectl get nodes -o wide

The expected result was two worker nodes in the Ready state.

The Ready status means Kubernetes considers the nodes healthy enough to participate in scheduling. It does not prove that every application or dependency is working.

[Screenshot: Insert kubectl get nodes -o wide showing both Ready nodes.]

13. Verify cluster add-ons

The cluster included the following add-ons and supporting components:

VPC CNI.
CoreDNS.
kube-proxy.
Amazon EBS CSI driver.
EKS Pod Identity Agent.
Metrics Server.
AWS Load Balancer Controller.

Verify EKS-managed add-ons:

aws eks list-addons \
  --cluster-name platform-capstone-prod \
  --region eu-west-1

Check Kubernetes system Pods:

kubectl get pods -n kube-system

Check Metrics Server:

kubectl top nodes

If metrics are not yet available, investigate the Metrics Server deployment and its connectivity to the kubelets. Installing an HPA resource alone does not guarantee that resource metrics are available.

Phase 6: Deploying the application to Kubernetes

14. Create a dedicated namespace

A namespace groups the application's Kubernetes resources and makes them easier to inspect and remove.

Create namespace.yaml:

apiVersion: v1
kind: Namespace
metadata:
  name: platform

Apply it:

kubectl apply -f namespace.yaml

Verify:

kubectl get namespaces

The application resources were deployed into the platform namespace.

15. Configure application secrets

The backend and PostgreSQL need database connection settings. Credentials should not be placed directly in a Docker image or committed to a public repository.

A Kubernetes Secret is one possible mechanism for supplying sensitive values. For a production system, consider a managed secret store such as AWS Secrets Manager and an appropriate integration.

A sample Secret template is shown below for illustration only:

apiVersion: v1
kind: Secret
metadata:
  name: postgres-secret
  namespace: platform
type: Opaque
stringData:
  POSTGRES_DB: appdb
  POSTGRES_USER: appuser
  POSTGRES_PASSWORD: REPLACE_WITH_A_SECRET

Do not apply this example with a real production password stored in source control. Populate sensitive values through a secure process, and ensure the Secret is not committed to Git.

A .gitignore can exclude local secret files:

.env
.env.*
!*.env.example
*secret*.yaml
terraform.tfstate
terraform.tfstate.*
.terraform/

Review the ignore rules carefully. The last rule can exclude filenames containing secret; adapt it if your repository intentionally tracks safe example templates. .gitignore does not remove files already committed to Git.

Phase 7: Deploying PostgreSQL with persistent storage

16. Why PostgreSQL uses a StatefulSet

A database has different operational needs from a stateless frontend.

A frontend Pod can generally be replaced without preserving local filesystem state. A database must preserve its data when a Pod is recreated or moved.

The capstone used a PostgreSQL StatefulSet with a 20 GiB encrypted gp3 EBS-backed PersistentVolumeClaim.

The important Kubernetes storage concepts are:

PersistentVolume (PV): represents storage available to a workload.
PersistentVolumeClaim (PVC): requests storage with specified capacity and access requirements.
StorageClass: defines how storage is dynamically provisioned.
StatefulSet: manages Pods with stable identities and storage associations.
EBS CSI driver: allows Kubernetes to provision and manage Amazon EBS volumes.

A PVC is a request for storage, not the data itself. When dynamically provisioned, Kubernetes and the CSI driver arrange for an appropriate volume to be created and bound to the claim.

17. Understand the storage lifecycle

The storage flow is:

PostgreSQL StatefulSet
          |
          v
 volumeClaimTemplates
          |
          v
 PersistentVolumeClaim
          |
          v
 StorageClass (gp3)
          |
          v
 Amazon EBS CSI Driver
          |
          v
 Encrypted EBS Volume

The volumeClaimTemplates section of a StatefulSet allows Kubernetes to create a PVC for each StatefulSet replica.

For a single PostgreSQL replica, the claim is typically named using the StatefulSet name and ordinal, for example:

data-postgres-0

The actual name depends on the StatefulSet and claim-template names.

17.1 Example StorageClass

A representative StorageClass for encrypted gp3 storage is:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: postgres-gp3
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
  type: gp3
  encrypted: "true"
reclaimPolicy: Retain

This is a reference example. If the cluster already has an appropriate StorageClass, use the actual one rather than creating a duplicate.

The WaitForFirstConsumer binding mode allows volume provisioning to account for the scheduling requirements of the consuming Pod.

The reclaim policy deserves attention:

Delete can remove the underlying dynamically provisioned volume when the claim is released, depending on the lifecycle and provisioner.
Retain preserves the underlying volume for manual recovery and cleanup.

Retaining storage can reduce the chance of accidental data loss, but it can also leave billable volumes behind. Choose the policy deliberately.

17.2 Example PostgreSQL StatefulSet

The following example illustrates the key configuration. Use the exact image version, credentials, probes, and initialization settings that your application requires.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
  namespace: platform
spec:
  serviceName: postgres
  replicas: 1

  selector:
    matchLabels:
      app: postgres

  template:
    metadata:
      labels:
        app: postgres

    spec:
      containers:
        - name: postgres
          image: postgres:16
          ports:
            - containerPort: 5432

          env:
            - name: POSTGRES_DB
              valueFrom:
                secretKeyRef:
                  name: postgres-secret
                  key: POSTGRES_DB

            - name: POSTGRES_USER
              valueFrom:
                secretKeyRef:
                  name: postgres-secret
                  key: POSTGRES_USER

            - name: POSTGRES_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: postgres-secret
                  key: POSTGRES_PASSWORD

          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "1000m"
              memory: "1Gi"

          readinessProbe:
            exec:
              command:
                - sh
                - -c
                - pg_isready -U "$POSTGRES_USER" -d "$POSTGRES_DB"
            initialDelaySeconds: 10
            periodSeconds: 10

          livenessProbe:
            exec:
              command:
                - sh
                - -c
                - pg_isready -U "$POSTGRES_USER" -d "$POSTGRES_DB"
            initialDelaySeconds: 30
            periodSeconds: 20

          volumeMounts:
            - name: data
              mountPath: /var/lib/postgresql/data

  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes:
          - ReadWriteOnce
        storageClassName: gp3
        resources:
          requests:
            storage: 20Gi

This sample uses the existing gp3 StorageClass name from the environment. If you create the alternative postgres-gp3 class above, change storageClassName accordingly.

Check the PostgreSQL image version and data directory before using this manifest. PostgreSQL image upgrades need a planned database migration strategy; changing an image tag is not always a safe database upgrade.

For a real production deployment, also consider backup and restore, database upgrades, availability, monitoring, credentials rotation, and disaster recovery. A single database replica on one EBS volume is useful for demonstrating persistence, but it is not a highly available database architecture.

17.3 Create an internal PostgreSQL Service

The backend needs a stable hostname through which it can reach PostgreSQL.

apiVersion: v1
kind: Service
metadata:
  name: postgres
  namespace: platform
spec:
  type: ClusterIP

  selector:
    app: postgres

  ports:
    - name: postgres
      port: 5432
      targetPort: 5432

Apply the database resources:

kubectl apply -f postgres-service.yaml
kubectl apply -f postgres-statefulset.yaml

Verify the StatefulSet and PVC:

kubectl get statefulsets -n platform
kubectl get pods -n platform
kubectl get pvc -n platform
kubectl get pv
kubectl get storageclass

The PVC should eventually reach Bound, and the PostgreSQL Pod should become ready.

If the PVC remains Pending, inspect its events:

kubectl describe pvc -n platform <claim-name>

Also inspect the EBS CSI driver and the StorageClass. Storage failures may be caused by missing IAM permissions, unsupported topology, invalid StorageClass parameters, or an unhealthy CSI controller.

Phase 8: Deploying the backend API

18. Backend Deployment

A Deployment manages replicas of the backend application and replaces Pods when they fail.

The backend image used by the capstone was:

platform-capstone-prod/backend:v1

The backend listened on port 5000.

A representative Deployment is:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend
  namespace: platform
spec:
  replicas: 2

  selector:
    matchLabels:
      app: backend

  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

  template:
    metadata:
      labels:
        app: backend

    spec:
      containers:
        - name: backend
          image: ACCOUNT_ID.dkr.ecr.eu-west-1.amazonaws.com/platform-capstone-prod/backend:v1

          ports:
            - containerPort: 5000

          env:
            - name: DB_HOST
              value: postgres

            - name: DB_PORT
              value: "5432"

            - name: DB_NAME
              valueFrom:
                secretKeyRef:
                  name: postgres-secret
                  key: POSTGRES_DB

            - name: DB_USER
              valueFrom:
                secretKeyRef:
                  name: postgres-secret
                  key: POSTGRES_USER

            - name: DB_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: postgres-secret
                  key: POSTGRES_PASSWORD

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

          startupProbe:
            httpGet:
              path: /health/live
              port: 5000
            failureThreshold: 30
            periodSeconds: 5

          livenessProbe:
            httpGet:
              path: /health/live
              port: 5000
            periodSeconds: 10

          readinessProbe:
            httpGet:
              path: /health/ready
              port: 5000
            periodSeconds: 5

          securityContext:
            allowPrivilegeEscalation: false
            runAsNonRoot: true
            capabilities:
              drop:
                - ALL

Replace ACCOUNT_ID with the actual account ID when creating the manifest. A deployment pipeline can generate the image reference automatically.

The security context assumes the image supports non-root execution. The image must be tested with the required UID, filesystem permissions, and any directories the application needs to write to.

18.1 Why probes matter

The three probes serve different purposes:

Startup probe: gives the application time to initialize before liveness checks take effect.
Liveness probe: detects an application process that is no longer functioning correctly.
Readiness probe: determines whether the Pod should receive traffic.

Readiness is particularly important when the backend depends on PostgreSQL. If the backend cannot access the database, it should not report itself as ready to handle database-dependent requests.

18.2 Create the backend Service

apiVersion: v1
kind: Service
metadata:
  name: backend
  namespace: platform
spec:
  type: ClusterIP

  selector:
    app: backend

  ports:
    - name: http
      port: 80
      targetPort: 5000

The Service exposes port 80 inside the cluster and forwards traffic to port 5000 on the backend Pods.

Apply the manifests:

kubectl apply -f backend-deployment.yaml
kubectl apply -f backend-service.yaml

Verify:

kubectl get deployment backend -n platform
kubectl get pods -n platform -l app=backend
kubectl get service backend -n platform
kubectl rollout status deployment/backend -n platform

Test the API from inside the cluster:

kubectl run backend-test \
  --namespace platform \
  --rm -it \
  --restart=Never \
  --image=curlimages/curl \
  -- curl -i http://backend/health/live

The temporary Pod requires the ability to pull its image. If your cluster cannot reach the image registry, use an approved diagnostic image available in your environment.

[Screenshot: The backend Deployment with two ready replicas, backend Service and port mapping and the successful backend health-check response.]

Phase 9: Deploying the frontend

19. Frontend Deployment

The frontend was served through Nginx on port 8080. Its image was:

platform-capstone-prod/frontend:v2

The frontend Deployment used two replicas.

A representative manifest is:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
  namespace: platform
spec:
  replicas: 2

  selector:
    matchLabels:
      app: frontend

  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

  template:
    metadata:
      labels:
        app: frontend

    spec:
      containers:
        - name: frontend
          image: ACCOUNT_ID.dkr.ecr.eu-west-1.amazonaws.com/platform-capstone-prod/frontend:v2

          ports:
            - containerPort: 8080

          resources:
            requests:
              cpu: "100m"
              memory: "64Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"

          readinessProbe:
            httpGet:
              path: /
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10

          livenessProbe:
            httpGet:
              path: /
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 20

          securityContext:
            allowPrivilegeEscalation: false
            runAsNonRoot: true
            capabilities:
              drop:
                - ALL

This sample assumes Nginx can serve the application using the selected non-root configuration. Validate the actual container image and configuration before applying it.

20. Create the frontend Service

apiVersion: v1
kind: Service
metadata:
  name: frontend
  namespace: platform
spec:
  type: ClusterIP

  selector:
    app: frontend

  ports:
    - name: http
      port: 80
      targetPort: 8080

The frontend Service provides a stable endpoint for the Pods. The Load Balancer Controller can then use this Service as the target for traffic configured through Ingress.

Apply and validate:

kubectl apply -f frontend-deployment.yaml
kubectl apply -f frontend-service.yaml

kubectl get deployment frontend -n platform
kubectl get pods -n platform -l app=frontend
kubectl get service frontend -n platform
kubectl rollout status deployment/frontend -n platform

Test the frontend from inside the cluster:

kubectl run frontend-test \
  --namespace platform \
  --rm -it \
  --restart=Never \
  --image=curlimages/curl \
  -- curl -I http://frontend/

[Screenshot: The frontend Deployment showing two ready replicas and the frontend Service with port 80 targeting container port 8080.]

Phase 10: Installing the AWS Load Balancer Controller

21. Why the controller is required

Kubernetes Ingress defines how HTTP traffic should be routed, but an Ingress resource does not create an AWS Application Load Balancer by itself.

The AWS Load Balancer Controller watches Kubernetes resources and provisions or manages AWS load balancers based on their configuration.

For this project, the controller was installed using Helm. The chart version was 1.14.0, with controller version v2.14.0.

The controller also needs permission to manage the relevant AWS resources. The capstone used EKS Pod Identity for the controller's AWS identity configuration.

The exact IAM policy, association, and Helm values must match the deployed cluster and controller version.

21.1 Verify Pod Identity support

Check that the EKS Pod Identity Agent add-on is installed:

aws eks list-addons \
  --cluster-name platform-capstone-prod \
  --region eu-west-1

Check the controller's service account and workload:

kubectl get serviceaccounts -n kube-system
kubectl get pods -n kube-system

21.2 Install the controller with Helm

For a new environment, first follow the AWS Load Balancer Controller documentation for creating the IAM policy, role, and Pod Identity association. The policy should be appropriate for the exact controller release.

A representative Helm installation is:

helm repo add eks https://aws.github.io/eks-charts
helm repo update

Then install the chart with the correct cluster name, region, VPC ID, service account, and controller image settings:

helm upgrade --install aws-load-balancer-controller \
  eks/aws-load-balancer-controller \
  --namespace kube-system \
  --version 1.14.0 \
  --set clusterName=platform-capstone-prod \
  --set region=eu-west-1 \
  --set vpcId=YOUR_VPC_ID

This command is illustrative. Before using it, ensure the service account is associated with the correct Pod Identity role and that the Helm values match your IAM setup. A controller without sufficient AWS permissions may run but fail to create or reconcile load balancers.

Verify the deployment:

kubectl rollout status deployment/aws-load-balancer-controller \
  -n kube-system

kubectl logs deployment/aws-load-balancer-controller \
  -n kube-system --tail=100

Phase 11: Exposing the frontend with Ingress

22. Create the Ingress resource

The capstone's public ALB routed the root path / to the frontend Service over HTTP port 80.

A representative Ingress manifest is:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: platform-ingress
  namespace: platform
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP":80}]'

spec:
  ingressClassName: alb

  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: frontend
                port:
                  number: 80

This example creates an internet-facing HTTP listener. It does not configure HTTPS or a TLS certificate. For production, use HTTPS, a suitable certificate in AWS Certificate Manager, and a planned HTTP-to-HTTPS redirect.

The target type ip allows the load balancer to target Pod IPs directly through the controller's target group configuration.

Apply the manifest:

kubectl apply -f ingress.yaml

Check its status:

kubectl get ingress -n platform
kubectl describe ingress platform-ingress -n platform

The ALB DNS name should appear in the Ingress address after the controller successfully reconciles the resource.

22.1 Test the public frontend

Obtain the hostname:

ALB_DNS=$(kubectl get ingress platform-ingress \
  -n platform \
  -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')

echo "$ALB_DNS"

Test the HTTP endpoint:

curl -I "http://${ALB_DNS}/"

Use http:// when the Ingress only defines an HTTP listener. Attempting HTTPS without an HTTPS listener and certificate will not test the configuration correctly.

22.2 Troubleshooting a public ALB

If the application does not load, check the problem layer by layer.

First, inspect Ingress events:

kubectl describe ingress platform-ingress -n platform

Then inspect the controller logs:

kubectl logs deployment/aws-load-balancer-controller \
  -n kube-system --tail=200

Check the frontend Pods and Service:

kubectl get pods -n platform -l app=frontend
kubectl get service frontend -n platform
kubectl get endpoints frontend -n platform

Finally, inspect the ALB target groups and health status in the AWS Console or through the ELBv2 API.

A healthy ALB DNS record does not guarantee that the target group is healthy. Common causes include security group restrictions, incorrect health-check paths, a Service targeting the wrong port, or Pods that are not ready.

Phase 12: Resource management and autoscaling

23. Why resource requests and limits matter

Kubernetes uses resource requests and limits to help schedule workloads and control their resource consumption.

Requests tell the scheduler the amount of CPU and memory the container needs for scheduling purposes.
Limits cap resource consumption. CPU limits can throttle a process, while exceeding a memory limit can cause the container to be terminated.

Requests and limits should reflect observed application behavior, not arbitrary values. The examples in this document are starting points, not universal production recommendations.

Check resource configuration in the live manifests:

kubectl get deployments -n platform -o yaml
kubectl describe pods -n platform

The capstone assessment required workloads to have resource controls and health probes. Review every workload, including database workloads, to verify that the final manifests satisfy the requirement.

24. Configure Horizontal Pod Autoscaling

The Horizontal Pod Autoscaler (HPA) adjusts the number of replicas in response to observed resource utilization.

The capstone configured CPU-based scaling with a target of 70%, a minimum of two replicas, and a maximum of five replicas.

A representative HPA manifest for the backend is:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: backend-hpa
  namespace: platform

spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: backend

  minReplicas: 2
  maxReplicas: 5

  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

For CPU utilization-based scaling, resource requests must be configured. If requests are missing, the HPA may be unable to calculate the intended utilization percentage.

The Metrics Server must also be healthy.

Verify metrics:

kubectl top nodes
kubectl top pods -n platform

Check the HPA:

kubectl get hpa -n platform
kubectl describe hpa backend-hpa -n platform

The HPA output includes current and target utilization, minimum and maximum replicas, and the current replica count.

24.1 Test autoscaling

A load test can help demonstrate whether the HPA reacts to demand. Use a controlled test environment and stop the test after collecting the evidence.

For example, a temporary load generator can send repeated requests to the backend Service. The exact command depends on the tools available in the cluster and the application's endpoints.

While the test is running, observe:

kubectl get hpa -n platform --watch

In another terminal:

kubectl get pods -n platform -l app=backend --watch

After the test, confirm that the replica count stabilizes and eventually scales down when utilization falls. Scaling is not necessarily immediate because Kubernetes uses sampling intervals, stabilization behavior, and scheduling time.

[Screenshot: Insert kubectl top pods -n platform showing resource metrics.]

[Screenshot: Insert kubectl get hpa -n platform showing the target CPU utilization.]

[Screenshot: The scaling test showing replicas increasing.]

[Screenshot: The final HPA status after the test.]

Phase 13: Validating PostgreSQL persistence and recovery

25. Why Pod recovery is not the same as data recovery

Kubernetes can recreate a Pod, but whether its data survives depends on where the data is stored.

Data written only to a container's writable layer is not a reliable persistence mechanism. When a container or Pod is replaced, that local state can disappear.

In this capstone, PostgreSQL stored its data on an EBS-backed persistent volume. The PVC provided the durable storage request, and the StatefulSet associated that claim with the PostgreSQL workload.

The validation goal was to demonstrate that the database data remained available after the PostgreSQL Pod was deleted and recreated.

25.1 Insert a test record

Connect to PostgreSQL using the database credentials and tooling configured for the environment. One approach is to use kubectl exec with psql:

kubectl exec -it postgres-0 -n platform -- \
  psql -U "$POSTGRES_USER" -d "$POSTGRES_DB"

The environment variables in your local shell will not automatically be available inside the Pod. For this reason, substitute the correct database name and user from the configured Secret, or use a secure method to pass them. Do not put the database password in a public screenshot.

Create a test table and insert a row:

CREATE TABLE IF NOT EXISTS persistence_test (
    id SERIAL PRIMARY KEY,
    message TEXT NOT NULL,
    created_at TIMESTAMPTZ DEFAULT NOW()
);

INSERT INTO persistence_test (message)
VALUES ('Capstone persistence validation');

SELECT * FROM persistence_test;

Record the returned row for comparison.

25.2 Delete the PostgreSQL Pod

Delete the Pod without deleting the StatefulSet or PVC:

kubectl delete pod postgres-0 -n platform

Wait for Kubernetes to recreate it:

kubectl get pods -n platform --watch

Once it is ready, query the test record again:

kubectl exec -it postgres-0 -n platform -- \
  psql -U YOUR_DB_USER -d YOUR_DB_NAME \
  -c "SELECT * FROM persistence_test;"

Replace the example database values with the actual values from the configured Secret.

The test succeeds when the Pod has been recreated and the previously inserted row is still present.

25.3 Verify the PVC remains bound

kubectl get pvc -n platform
kubectl get pv

The PVC should remain bound to the volume associated with PostgreSQL.

This test demonstrates persistence across Pod recreation. It does not, by itself, prove that backups can be restored, that a volume survives every infrastructure failure, or that the database is highly available. Those require separate tests.

Phase 14: Application and platform validation

26. Validate the cluster and workloads

Validation should cover both the underlying infrastructure and the application behavior.

Start by checking the nodes:

kubectl get nodes -o wide

Then inspect all resources in the application namespace:

kubectl get all -n platform

Check the database storage:

kubectl get pvc -n platform
kubectl get pv

Check autoscaling and metrics:

kubectl get hpa -n platform
kubectl top pods -n platform

Inspect recent events if something is not healthy:

kubectl get events -n platform \
  --sort-by=.metadata.creationTimestamp

The desired state was two frontend replicas, two backend replicas under normal conditions, and one PostgreSQL replica with a bound PVC. HPA could adjust the backend replica count between two and five in response to CPU utilization.

The actual replica count at any particular time depends on scaling activity and workload conditions.

27. Validate the frontend and backend

For the public frontend:

curl -I "http://${ALB_DNS}/"

For the backend, test its health endpoints through the internal Service or an approved diagnostic Pod:

kubectl run backend-test \
  --namespace platform \
  --rm -it \
  --restart=Never \
  --image=curlimages/curl \
  -- curl -i http://backend/health/live

Then test readiness:

kubectl run backend-ready-test \
  --namespace platform \
  --rm -it \
  --restart=Never \
  --image=curlimages/curl \
  -- curl -i http://backend/health/ready

A 200 response is useful evidence, but readiness is meaningful only if the endpoint checks the dependencies required by the application.

28. Validate a rolling update

A Deployment can replace application Pods gradually when its image or Pod template changes.

For a controlled test, publish a new immutable image tag and update the Deployment to use it. Avoid changing a production tag to point to a different image without a controlled release process.

For example:

kubectl set image deployment/backend \
  backend=YOUR_BACKEND_ECR_URI:v2 \
  -n platform

Monitor the rollout:

kubectl rollout status deployment/backend -n platform
kubectl rollout history deployment/backend -n platform

If the update fails, inspect the rollout and Pod events before considering a rollback:

kubectl describe deployment backend -n platform
kubectl get pods -n platform -l app=backend
kubectl rollout undo deployment/backend -n platform

The example uses v2 as a placeholder. The tag must exist in ECR before applying it.

A rolling-update strategy with maxUnavailable: 0 and maxSurge: 1 aims to keep the desired number of available replicas during a rollout, provided there is sufficient capacity and the readiness probes accurately identify healthy Pods. It does not guarantee zero downtime under every failure condition.

Phase 15: Terraform validation and infrastructure documentation

29. Validate Terraform before final delivery

Infrastructure validation is an important part of the delivery process.

From the production Terraform directory:

cd ~/platform-capstone/terraform/environments/prod

terraform fmt -check -recursive
terraform validate
terraform plan

After a successful deployment, a plan that reports no changes is useful evidence that the configuration matches the infrastructure Terraform is tracking at that moment.

However, a clean plan does not prove the application is healthy. Runtime checks remain necessary.

If you have already destroyed the infrastructure, do not run terraform apply simply to make the plan return to zero changes. A destroy plan or a plan proposing resource creation is expected when the infrastructure no longer exists. Review the state and the intended lifecycle before proceeding.

30. Generate a Terraform dependency graph

Terraform can generate a graph showing relationships between resources.

Run this from the directory containing the environment's Terraform root configuration:

cd ~/platform-capstone/terraform/environments/prod

terraform init
terraform graph | dot -Tsvg \
  > ~/platform-capstone/infrastructure.svg

Open the SVG in Windows from WSL:

explorer.exe "$(wslpath -w ~/platform-capstone/infrastructure.svg)"

The graph is a dependency graph, not a complete application architecture diagram. For the blog post, a separate diagram showing users, ALB, Kubernetes Services, Pods, PostgreSQL, and EBS storage is more useful for readers who are new to the project.

If the infrastructure has been destroyed, Terraform graph generation can still be useful when the configuration and provider setup remain available locally, but it does not prove that AWS resources are currently running.

[Screenshot: The Terraform validation output.]

Phase 16: GitHub and project delivery

31. Version control and repository hygiene

Git provides a history of infrastructure and application changes. GitHub makes the project available for review and future reuse.

The capstone reached a final commit:

76c49b1 feat: deploy AWS Kubernetes platform capstone

Before publishing, confirm that the hash still matches your repository and that the latest changes are committed.

Useful commands include:

git status
git log --oneline -5
git diff --stat

To check whether the current branch is ahead of or behind its upstream:

git status -sb

Do not publish Terraform state files, cloud credentials, production database passwords, or other sensitive configuration. A secret file being ignored today does not prove that it was never committed in an earlier commit.

If a secret was committed, remove it from the repository history as appropriate and rotate the exposed credential. Removing the file from the latest commit alone does not make an exposed secret safe.

[Screenshot: The GitHub repository overview.]

[Screenshot: The final commit and clean Git status.]

Phase 17: Infrastructure cleanup

32. Why teardown matters

AWS resources can continue to incur charges even after an application is no longer being tested. For example, NAT Gateways, worker nodes, load balancers, EBS volumes, and container images can all contribute to cost.

The capstone was therefore torn down after the validation evidence had been collected.

The cleanup process also needed to preserve the remote Terraform state in S3 so that the deployment record remained available.

32.1 Remove the Ingress first

Deleting the Ingress gives the AWS Load Balancer Controller an opportunity to remove the ALB and its associated resources.

kubectl delete ingress --all -n platform

Wait for the ALB to disappear from AWS before proceeding, allowing time for the controller to reconcile the deletion.

32.2 Delete the application namespace

kubectl delete namespace platform

This removes namespaced application resources, including Deployments, Services, StatefulSets, and PVCs, subject to Kubernetes finalizers and storage lifecycle policies.

Check the namespace:

kubectl get namespaces

Warning: deleting a namespace can remove the PVC that holds database data. Ensure that the data is no longer needed and that any required backup or evidence has been preserved before doing this.

32.3 Review Terraform's destroy plan

From the production Terraform root:

cd ~/platform-capstone/terraform/environments/prod

terraform plan -destroy

Inspect the planned actions. Ensure that the plan does not include deleting the remote S3 state bucket. The S3 backend bucket was managed separately from the production application infrastructure.

If the plan is correct, proceed with the destroy operation:

terraform destroy

Review the confirmation prompt carefully before approving.

Do not destroy the bootstrap configuration if it manages the S3 bucket that stores the remote state.

32.4 Verify the cleanup

The audit used AWS CLI commands to check for remaining EKS clusters, EC2 instances, load balancers, NAT Gateways, Elastic IPs, EBS volumes, snapshots, ECR repositories, and other related resources.

For example:

aws eks list-clusters --region eu-west-1

aws ec2 describe-instances \
  --region eu-west-1 \
  --filters Name=instance-state-name,Values=pending,running,stopping,stopped

aws elbv2 describe-load-balancers --region eu-west-1

aws ec2 describe-nat-gateways \
  --region eu-west-1 \
  --filter Name=state,Values=pending,available,deleting,failed

aws ec2 describe-addresses --region eu-west-1

aws ec2 describe-volumes --region eu-west-1

aws ecr describe-repositories --region eu-west-1

Empty results in these commands indicate that the corresponding queries found no matching resources.

In the capstone cleanup audit, the main infrastructure was absent from the checked regions. The two EC2 worker instances appeared as terminated, while the checks found no EKS clusters, load balancers, NAT Gateways, Elastic IPs, EBS volumes, snapshots, or ECR repositories in the primary region.

The audit also found no matching capstone IAM roles and no remaining non-default security groups or network interfaces in the primary region.

The Terraform state remained in the S3 bucket:

s3://platform-capstone-terraform-state-911xxxx3075/platform-capstone/prod/terraform.tfstate

The bucket was intentionally preserved. S3 is not automatically free, so review storage, requests, versioned objects, and billing periodically.

These checks provide strong evidence that the core capstone infrastructure was removed, but they do not prove that every AWS service in every region is empty. Review any remaining resources before assuming there are no further charges.

33. Results and outcomes

The capstone brought the infrastructure, application deployment, and validation stages together into one practical platform engineering exercise.

The main outcomes were:

Infrastructure as Code: AWS infrastructure was defined and provisioned through Terraform modules and a production environment configuration.
Network separation: the VPC included public and private subnets across two Availability Zones.
Managed Kubernetes: the Amazon EKS cluster ran two managed t3.medium worker nodes.
Container delivery: separate frontend and backend images were built and published to Amazon ECR.
Application orchestration: Kubernetes Deployments and Services managed the frontend and backend workloads.
Persistent storage: PostgreSQL used a StatefulSet and a bound PVC backed by encrypted gp3 EBS storage.
External access: an AWS Load Balancer Controller reconciled the Ingress configuration into an internet-facing ALB.
Health validation: frontend and backend health checks were used to validate application readiness.
Autoscaling: CPU-based HPA configuration used a 70% target and a replica range of two to five.
Recovery testing: a PostgreSQL Pod was deleted and recreated, and the test record remained available on persistent storage.
Delivery documentation: the project was committed to GitHub and documented for future reference.
Resource cleanup: the primary AWS infrastructure was removed after testing, while the S3 state bucket was preserved.

These outcomes demonstrate how infrastructure provisioning, containerization, Kubernetes orchestration, persistence, networking, and validation combine into a single cloud platform.

They also highlight an important engineering lesson: a resource being present is not the same as it being healthy. A running Pod does not prove the application can reach its database. A created Ingress does not prove the ALB targets are healthy. A bound PVC does not prove that a recovery process works. Each layer needs its own test.

34. Lessons learned

Infrastructure should be reproducible

Terraform makes infrastructure easier to review and recreate, but only when the configuration, variables, provider versions, and remote state are maintained carefully.

Application health must include dependencies

A backend can return a successful liveness response while its database is unavailable. Liveness and readiness should represent different conditions, and readiness should verify the dependencies required to serve requests.

Persistent storage requires lifecycle awareness

Stateful workloads need more than a PVC declaration. Storage classes, volume binding, access modes, encryption, reclaim policies, backup, and restoration all influence the safety and lifecycle of database data.

Autoscaling depends on observability and resource requests

An HPA manifest is only one part of autoscaling. The Metrics Server must be working, CPU requests must be set, and the cluster needs sufficient capacity to schedule additional replicas.

Networking should be tested layer by layer

When an application is not reachable, check the listener protocol, Ingress events, controller logs, Service endpoints, target health, and security group rules. This is more effective than repeatedly changing configuration without identifying the failing layer.

Cleanup is part of engineering

A project is not complete merely because it works. Reviewing the resources created, preserving the necessary state, removing billable infrastructure, and documenting the final status are part of responsible cloud operations.

35. Future improvements

There are several areas in which this capstone could be extended.

Security

Add HTTPS using AWS Certificate Manager.
Redirect HTTP to HTTPS.
Store production secrets in AWS Secrets Manager or another managed secret system.
Review least-privilege IAM permissions and security group rules.
Add image vulnerability scanning and container policy checks.
Consider Kubernetes NetworkPolicies where the networking implementation supports them.

Reliability

Add automated PostgreSQL backups and restore testing.
Document database upgrade and recovery procedures.
Evaluate a managed database such as Amazon RDS for a production architecture.
Add disruption budgets and scheduling constraints where appropriate.
Test rolling updates under realistic traffic conditions.

Observability

Centralize application and controller logs.
Add application-level metrics and dashboards.
Define service-level indicators for availability and latency.
Alert on unhealthy Pods, failed rollouts, and storage issues.

Delivery automation

Add a GitHub Actions pipeline to run Terraform formatting and validation.
Build and scan Docker images on pull requests.
Push versioned images to ECR after approved builds.
Deploy through a controlled release workflow.
Keep credentials out of CI logs and repository files.

Cost management

Review NAT Gateway architecture and data transfer.
Evaluate the worker node size against observed workload requirements.
Set AWS Budgets and billing alerts.
Define a documented cleanup procedure for non-production environments.
Periodically review ECR images, S3 versions, and retained EBS volumes.

These improvements would move the project closer to a more complete platform engineering implementation.

36. Final checklist

Use this checklist when reviewing the project or preparing the next version.

AWS infrastructure

[x] EKS cluster provisioned
[x] VPC and networking configured
[x] Worker nodes provisioned
[x] ECR repositories created
[x] EBS volume provisioned
[x] Application Load Balancer created

Kubernetes

[x] Worker nodes reached Ready
[x] Workloads and Services deployed
[x] Resource metrics checked
[x] HPA configured and tested
[x] PostgreSQL PVC bound
[x] Ingress configured

Validation

[x] Public frontend tested
[x] Backend readiness tested
[x] Database persistence and recovery tested
[x] HPA scaling test completed

Delivery

[x] Terraform validation performed
[x] GitHub repository maintained
[x] Final commit recorded
[x] Clean Git status checked

Cleanup

[x] Main capstone infrastructure removed
[x] Primary-region resource audit performed
[x] Additional regional checks performed
[x] Terraform state preserved in S3

The checked boxes above record the project milestones reported during the capstone. They should be retained as evidence of completed work, while future improvements should be tracked separately.

Conclusion

This capstone was an opportunity to work through the lifecycle of a cloud-native application platform: defining infrastructure, building images, provisioning Kubernetes, deploying services, persisting data, exposing the application, testing scaling and recovery, and cleaning up resources responsibly.

Repository: [https://github.com/Jahmeeu-Cloud/platform-capstone]

The biggest takeaway was the importance of understanding the boundaries between the different layers. Terraform manages infrastructure; Docker packages the application; ECR stores the images; Kubernetes manages workloads; the AWS Load Balancer Controller connects Kubernetes networking resources to AWS load balancers; and persistent storage allows the database to retain data beyond the lifetime of a Pod.

Each component serves a different purpose, and the platform only works as expected when those components are configured and validated together.

This is a foundation that can be extended into more advanced work involving CI/CD, GitOps, managed secrets, observability, policy enforcement, and platform self-service.

The aim is not simply to deploy an application once. It is to build an environment that another engineer can understand, reproduce, test, and improve.

Project status: The core capstone deployment and validation milestones were completed, and the main AWS infrastructure was subsequently removed to avoid unnecessary ongoing resource charges. The Terraform state was retained in Amazon S3 for future reference.

Resilient Kubernetes Application

BAKRE JAMIU — Wed, 07 Oct 2026 16:17:33 +0000

A production-style Kubernetes resilience and platform engineering project deployed on Amazon EKS, using Helm, Kubernetes StatefulSets, persistent EBS storage, HPA, ALB Ingress, Redis, PostgreSQL, and containerized application workloads.

The project focuses on more than simply deploying an application. It demonstrates how to identify, troubleshoot, recover from, and harden common Kubernetes failure scenarios, particularly around persistent storage, application health checks, autoscaling, and Helm-based deployment.

Project Overview

This project implements a resilient multi-component application on Amazon EKS with:

Frontend application
Backend application
PostgreSQL database
Redis cache
Persistent EBS-backed PostgreSQL storage
Kubernetes Services
AWS Application Load Balancer (ALB) Ingress
Horizontal Pod Autoscaler (HPA)
Helm-based application packaging
Environment-specific Helm values
Kubernetes health probes
PersistentVolume (PV) and PersistentVolumeClaim (PVC) management
PostgreSQL storage recovery
Storage retention testing
AWS EBS volume optimization

The project also includes hands-on troubleshooting of several realistic Kubernetes issues encountered during deployment.

Architecture

                         Internet
                            │
                            ▼
                 AWS Application Load Balancer
                            │
                            ▼
                  Kubernetes Ingress
                 resilient-app-ingress
                     ┌──────┴──────┐
                     │             │
                    /              /api
                     │             │
                     ▼             ▼
              Frontend Service   Backend Service
                     │             │
                     ▼             ▼
               Frontend Pods    Backend Pods
                  2 replicas     2+ replicas
                                    │
                                    │
                               HPA: 2–5
                                    │
                                    ▼
                              Application API


                 ┌─────────────────────────┐
                 │     resilient-app       │
                 │       namespace         │
                 └────────────┬────────────┘
                              │
                 ┌────────────┴────────────┐
                 │                         │
                 ▼                         ▼
          PostgreSQL StatefulSet       Redis Deployment
                 │                         │
                 ▼                         ▼
              PostgreSQL               Redis Service
                 │
                 ▼
                PVC
                 │
                 ▼
                PV
                 │
                 ▼
           AWS EBS Volume

Technology Stack

Technology	Purpose
Amazon EKS	Managed Kubernetes cluster
Kubernetes	Container orchestration
Helm	Application packaging and configuration
AWS ALB	External application ingress
PostgreSQL 15	Persistent relational database
Redis	Application cache
AWS EBS	Persistent block storage
HPA	Backend autoscaling
Docker/container images	Application workloads
YAML	Kubernetes and Helm configuration
kubectl	Cluster administration
AWS CLI	EBS and AWS resource management

Repository Structure

.
├── charts/
├── docs/
│   └── screenshots/
└── manifests/
    ├── backend-hpa.yaml
    ├── backend.yaml
    ├── cache.yaml
    ├── configmap-secret.yaml
    ├── database.yml
    ├── frontend.yaml
    ├── helm/
    │   ├── resilient-app/
    │   │   ├── Chart.yaml
    │   │   ├── postgres-recovery-pvc.yaml
    │   │   ├── templates/
    │   │   │   ├── backend-hpa.yaml
    │   │   │   ├── backend.yaml
    │   │   │   ├── cache.yaml
    │   │   │   ├── configmap-secret.yaml
    │   │   │   ├── database.yaml
    │   │   │   ├── frontend.yaml
    │   │   │   └── ingress.yaml
    │   │   ├── values-dev.yaml
    │   │   ├── values-staging.yaml
    │   │   ├── values-prod.yaml
    │   │   └── values.yaml
    │   └── values-prod.yaml
    ├── ingress.yaml
    ├── namespace.yml
    └── storageclass.yaml

The repository contains both the original Kubernetes manifests and the Helm-based implementation used to package the application.

Kubernetes Components

Frontend

The frontend is deployed as a Kubernetes Deployment and exposed internally through:

frontend-service:80

The production configuration supports multiple replicas to improve availability.

The application was validated through Kubernetes port forwarding and returned:

Kubernetes Resilience Demo - Frontend Active

Backend

The backend is deployed as a Kubernetes Deployment and exposed through:

backend-service:8080

The backend health endpoint returns:

{
  "status": "healthy",
  "database": "connected",
  "redis": "connected"
}

The backend is configured with an HPA allowing it to scale between:

Minimum replicas: 2
Maximum replicas: 5
CPU target:       50%

PostgreSQL

PostgreSQL runs as a Kubernetes StatefulSet:

statefulset/postgres

The database uses persistent storage through:

StatefulSet
    ↓
PersistentVolumeClaim
    ↓
PersistentVolume
    ↓
AWS EBS

The final state was:

postgres-0    1/1 Running

PostgreSQL connectivity was verified using:

kubectl exec -n resilient-app postgres-0 -- \
  pg_isready -U dbadmin -d resilient_db

Result:

/var/run/postgresql:5432 - accepting connections

Redis

Redis is deployed as a Kubernetes Deployment and exposed internally through:

redis-service:6379

The final cluster state showed Redis healthy with no container restarts.

Helm

The application is packaged as a Helm chart:

manifests/helm/resilient-app/

The chart contains:

Chart.yaml
values.yaml
values-dev.yaml
values-staging.yaml
values-prod.yaml
templates/

Environment-specific values allow the application configuration to be adapted for different environments without changing the Kubernetes templates.

Example:

helm template resilient-app . -f values-prod.yaml

The production configuration was rendered successfully.

Helm Validation

The Helm chart was validated before applying changes to the cluster.

Render the chart

helm template resilient-app . -f values-prod.yaml

Render to a file

helm template resilient-app . -f values-prod.yaml > rendered-prod.yaml

Server-side Kubernetes validation

kubectl apply --dry-run=server -f rendered-prod.yaml

This validates the generated resources against the Kubernetes API server without actually applying them.

This was used throughout the project to catch configuration problems before deployment.

Resilience Problems Identified and Resolved

One of the main goals of this project was to troubleshoot real deployment failures rather than simply deploy a predefined manifest.

Several issues were identified.

1. Conflicting Kubernetes StorageClass

The Helm chart initially attempted to manage a gp2 StorageClass that already existed in the EKS cluster.

The cluster already contained:

gp2 (default)
provisioner: kubernetes.io/aws-ebs
type: gp2
fsType: ext4

The Helm-generated StorageClass attempted to define conflicting parameters.

Kubernetes rejected the update because StorageClass parameters are immutable.

The error was:

The StorageClass "gp2" is invalid:
parameters: Forbidden: updates to parameters are forbidden.

Resolution

The application chart was changed so that it does not attempt to recreate or modify the cluster-level StorageClass.

The application should consume the existing StorageClass rather than treating it as an application-owned resource.

This follows a cleaner separation of responsibilities:

Cluster infrastructure
        │
        └── StorageClass
                │
                ▼
Application Helm chart
        │
        └──    PVC
                │
                ▼
               EBS

2. PostgreSQL Persistent Volume Recovery

The most significant resilience exercise involved PostgreSQL persistent storage.

Initially, Kubernetes reported no PVC/PV resources even though the PostgreSQL pod was still running with an attached EBS-backed filesystem.

Investigation showed that PostgreSQL was using an EBS volume containing valid PostgreSQL data.

The underlying volume was identified using the Kubernetes CSI volume information.

The EBS volume contained the PostgreSQL data directory, including:

PG_VERSION
base/
global/
pg_wal/
pg_xact/
pg_multixact/
pg_logical/
postgresql.conf
pg_hba.conf

This confirmed that the database data itself had survived.

3. Manual PV Recovery

The original EBS volume was associated with:

vol-0ed6eca1c06ba8527

A PersistentVolume was recreated to reference the existing EBS volume through the AWS EBS CSI driver.

The recovery PV was configured with:

persistentVolumeReclaimPolicy: Retain
storageClassName: gp2
volumeMode: Filesystem

The existing EBS volume was referenced through:

csi:
  driver: ebs.csi.aws.com

The recovery PVC was then explicitly bound to the recovered PV.

After recovery:

PVC → Bound
PV  → Bound
PostgreSQL → Running

The PostgreSQL data directory was verified after the volume was reattached.

4. Persistent Storage Lifecycle Test

A deliberate storage lifecycle test was performed to verify the behavior of the Retain policy.

The PostgreSQL StatefulSet was scaled down:

kubectl scale statefulset postgres --replicas=0 -n resilient-app

The PVC was deleted.

The retained PV entered the Released state rather than immediately destroying the underlying volume.

The original EBS volume remained available.

A new dynamically provisioned volume was observed during the lifecycle test, demonstrating the distinction between:

Kubernetes PVC lifecycle
PV lifecycle
dynamic provisioning
retained storage
underlying AWS EBS lifecycle

The original retained PV was then recovered by removing its stale claim reference and binding a recovery PVC to it.

PostgreSQL was started again and the original database files were confirmed to be present.

This demonstrated that the data could be recovered independently of the original PVC object.

5. PostgreSQL Storage Optimization

After confirming the database data was recovered and PostgreSQL was healthy, the underlying AWS EBS volume was upgraded from:

gp2

to:

gp3

The EBS modification was performed using the AWS CLI:

aws ec2 modify-volume \
  --volume-id <VOLUME_ID> \
  --volume-type gp3 \
  --region us-east-2

The volume modification reached:

Progress: 100
State: completed
Target type: gp3
Target IOPS: 3000
Target throughput: 125

PostgreSQL remained operational throughout the storage optimization.

Important Kubernetes detail

The underlying AWS EBS volume is now gp3, while the Kubernetes PV retains its existing:

storageClassName: gp2

This is intentional in the recovery context.

The Kubernetes StorageClass reference is metadata on the PV and is separate from the actual EBS volume type.

A future production implementation could introduce a dedicated CSI-based gp3 StorageClass and perform a controlled storage migration rather than changing the bound PV metadata directly.

6. Backend Container Failure

The backend initially entered:

CrashLoopBackOff

The container runtime reported:

exec: "-listen=:8080": executable file not found in $PATH

Investigation showed that the Helm chart was using:

httpd

while passing arguments intended for:

hashicorp/http-echo

The application manifest expected:

image: hashicorp/http-echo:latest

The Helm values were corrected accordingly.

After the change, the backend pods became healthy:

1/1 Running

and the Deployment successfully reached its desired replica count.

7. PostgreSQL Health Probe Failure

PostgreSQL initially generated:

FATAL: database "dbadmin" does not exist

The investigation revealed an important distinction:

dbadmin

was the PostgreSQL role/user, while:

resilient_db

was the actual application database.

The original probes used:

pg_isready -U dbadmin

PostgreSQL interpreted the connection target as the database named after the user:

dbadmin

which did not exist.

The probes were corrected to:

command:
  - pg_isready
  - -U
  - dbadmin
  - -d
  - resilient_db

Both liveness and readiness probes were updated.

After deployment, PostgreSQL logs showed:

database system is ready to accept connections

and:

pg_isready -U dbadmin -d resilient_db

returned:

/var/run/postgresql:5432 - accepting connections

Horizontal Pod Autoscaling

The backend uses a Horizontal Pod Autoscaler.

Configuration:

Minimum replicas: 2
Maximum replicas: 5
CPU target:       50%

The HPA was verified in the cluster:

kubectl get hpa -n resilient-app

Final observed state:

TARGETS      MINPODS   MAXPODS   REPLICAS
cpu: 2%/50%  2         5         2

The HPA behavior was also observed through Kubernetes events.

During testing, the backend scaled:

2 → 3 replicas

and later automatically scaled back:

3 → 2 replicas

with Kubernetes reporting:

reason: All metrics below target

This confirms that the HPA was actively managing the backend workload rather than merely existing as an unused resource.

Application Networking

The application uses Kubernetes Services for internal communication.

backend-service
    ClusterIP
    port 8080

frontend-service
    ClusterIP
    port 80

postgres-service
    Headless Service
    port 5432

redis-service
    Headless Service
    port 6379

The PostgreSQL and Redis services use headless service configurations to support stateful/internal service discovery.

AWS Application Load Balancer

The application is exposed through a Kubernetes Ingress using the AWS Load Balancer Controller.

Ingress:

resilient-app-ingress

Class:

alb

The EKS cluster successfully provisioned an AWS Application Load Balancer.

The final cluster state showed an ALB DNS address associated with the Ingress.

Validation and Testing

The final cluster was validated using several Kubernetes commands.

Pod health

kubectl get pods -n resilient-app

Final observed state:

backend      Running
frontend     Running
postgres     Running
redis        Running

All observed pods had:

RESTARTS: 0

Deployment health

kubectl get statefulset,deployment -n resilient-app

Final state:

postgres    1/1
backend     2/2
frontend    2/2
redis       1/1

Persistent storage

kubectl get pvc,pv -n resilient-app

Final PostgreSQL storage:

PVC:           Bound
PV:            Bound
Access Mode:   RWO
Capacity:      1Gi
Reclaim Policy: Retain

Services and Ingress

kubectl get svc,ingress -n resilient-app

Verified:

backend-service
frontend-service
postgres-service
redis-service
resilient-app-ingress

HPA

kubectl get hpa -n resilient-app

Verified:

MINPODS: 2
MAXPODS: 5
CPU TARGET: 50%

PostgreSQL health

kubectl exec -n resilient-app postgres-0 -- \
  pg_isready -U dbadmin -d resilient_db

Result:

/var/run/postgresql:5432 - accepting connections

Frontend application test

The frontend service was tested using:

kubectl port-forward svc/frontend-service 8091:80 -n resilient-app

The application returned:

Kubernetes Resilience Demo - Frontend Active

Backend application test

The backend service was tested using:

kubectl port-forward svc/backend-service 8092:8080 -n resilient-app

The service successfully accepted connections through the port-forward.

Final Cluster State

The final observed application state was:

Namespace: resilient-app

Backend:
  2/2 Running

Frontend:
  2/2 Running

PostgreSQL:
  1/1 Running

Redis:
  1/1 Running

PostgreSQL PVC:
  Bound

PostgreSQL PV:
  Bound

PV Reclaim Policy:
  Retain

Backend HPA:
  2–5 replicas
  50% CPU target

Ingress:
  AWS ALB

Pod Restarts:
  0

Key Resilience Principles Demonstrated

This project demonstrates several important Kubernetes and platform engineering principles.

1. Stateful workloads require deliberate storage management

A PostgreSQL pod can be recreated, but database data must live independently from the pod lifecycle.

Pod lifecycle ≠ Data lifecycle

2. PVCs, PVs, StorageClasses, and cloud volumes are different layers

The project demonstrates the relationship between:

Application
    ↓
StatefulSet
    ↓
PVC
    ↓
PV
    ↓
CSI Driver
    ↓
AWS EBS

Understanding these layers was essential to recovering the database.

3. Retain policies provide an additional recovery boundary

Using:

persistentVolumeReclaimPolicy: Retain

helps prevent automatic destruction of the underlying persistent volume when a claim is removed.

4. Health checks must test the real application dependency

A syntactically valid probe can still be logically wrong.

The PostgreSQL probe initially checked the wrong database.

Changing:

pg_isready -U dbadmin

to:

pg_isready -U dbadmin -d resilient_db

aligned the health check with the actual application database.

5. Autoscaling should be tested, not assumed

The HPA was observed scaling:

2 → 3 → 2

based on CPU utilization.

This provided evidence that the autoscaling configuration was functioning.

6. Helm should consume infrastructure rather than unnecessarily own it

Cluster-level resources such as StorageClasses should be managed deliberately.

The application chart should consume an appropriate existing StorageClass instead of attempting to redefine a cluster-wide resource with the same name.

Security Considerations

Sensitive configuration should not be committed to source control.

The repository should use:

Kubernetes Secrets
External Secrets where appropriate
AWS Secrets Manager or Parameter Store for production environments
Environment-specific configuration
.gitignore for local secrets
Secret scanning before pushing to GitHub

Example production architecture:

Application
     │
     ▼
Kubernetes Secret
     │
     ▲
External secret management
     │
     ▼
AWS Secrets Manager

Never commit real passwords, AWS credentials, tokens, kubeconfig files, or private keys to this repository.

Operational Lessons

This project provided hands-on experience with:

Kubernetes troubleshooting
EKS operations
StatefulSets
PersistentVolumes
PersistentVolumeClaims
StorageClasses
AWS EBS
AWS EBS CSI
Kubernetes scheduling
Kubernetes events
Health probes
Container entrypoints
Helm templating
Environment-specific values
Kubernetes Services
AWS ALB Ingress
HPA
Storage recovery
Data persistence
Failure investigation
Production-style validation

Future Improvements

This project is intentionally structured as a foundation for a larger Platform Engineering capstone.

Planned improvements include:

Infrastructure as Code

Terraform for EKS
VPC
IAM
Security Groups
EBS CSI
AWS Load Balancer Controller
Supporting AWS infrastructure

CI/CD

GitHub Actions
Helm linting
YAML validation
Security scanning
Container image scanning
Automated deployment

GitOps

Argo CD
Declarative application delivery
Environment promotion
Automated drift detection

Observability

Prometheus
Grafana
Alertmanager
Application metrics
Kubernetes metrics
SLO/SLI monitoring

Security

NetworkPolicies
Pod Security Standards
Non-root containers
Read-only root filesystems where applicable
RBAC hardening
Image scanning
Secrets management
AWS IAM least privilege

Reliability

PodDisruptionBudgets
Pod anti-affinity
Multi-AZ scheduling
Automated backup and restore
PostgreSQL backup strategy
Disaster recovery testing
Recovery Time Objective (RTO)
Recovery Point Objective (RPO)

Platform Engineering

The long-term goal is to evolve this project into a reusable internal platform that allows application teams to deploy workloads through standardized:

Infrastructure
    ↓
Kubernetes
    ↓
Helm
    ↓
CI/CD
    ↓
GitOps
    ↓
Observability
    ↓
Security
    ↓
Reliability

Useful Commands

Helm

helm lint .

helm template resilient-app . -f values-prod.yaml

helm template resilient-app . -f values-prod.yaml > rendered-prod.yaml

Kubernetes validation

kubectl apply --dry-run=server -f rendered-prod.yaml

kubectl get pods -n resilient-app

kubectl get svc -n resilient-app

kubectl get pvc,pv -n resilient-app

kubectl get statefulset,deployment -n resilient-app

kubectl get hpa -n resilient-app

kubectl get ingress -n resilient-app

kubectl get events -n resilient-app --sort-by='.lastTimestamp'

PostgreSQL

kubectl exec -n resilient-app postgres-0 -- \
  pg_isready -U dbadmin -d resilient_db

Service testing

Frontend:

kubectl port-forward svc/frontend-service 8091:80 -n resilient-app

Backend:

kubectl port-forward svc/backend-service 8092:8080 -n resilient-app

Project Outcome

The project successfully demonstrated a resilient Kubernetes application running on Amazon EKS.

The final implementation successfully achieved:

Helm-based application packaging
Multi-component Kubernetes deployment
Persistent PostgreSQL storage
PostgreSQL PV/PVC recovery
Persistent volume retention testing
AWS EBS volume recovery
AWS EBS gp2 → gp3 optimization
Correct PostgreSQL health probes
Backend container failure resolution
Kubernetes Service validation
AWS ALB Ingress provisioning
Horizontal Pod Autoscaling
Application health validation
Zero pod restarts in the final observed state

Most importantly, the project demonstrated the ability to troubleshoot and recover a stateful Kubernetes workload instead of simply redeploying it and losing the underlying data.

Author

Jamiu Bakre
Cloud & DevOps Engineer | Kubernetes | AWS | Terraform | CI/CD

Focus areas:

Cloud Engineering
DevOps
Kubernetes
Platform Engineering
Infrastructure as Code
AWS
CI/CD
Reliability Engineering

Status

Assignment status: Completed — Design & Deploy a Resilient Kubernetes Application

This repository represents the first stage of a broader Platform Engineering journey and is intended to evolve into a more complete production-style platform with Infrastructure as Code, GitOps, observability, security automation, and automated reliability testing.

Multi-Environment Terraform Infrastructure on AWS

BAKRE JAMIU — Wed, 16 Sep 2026 17:40:39 +0000

📌 Project Overview

This project demonstrates the design and deployment of AWS infrastructure across three independent environments:

Development
Staging
Production

The infrastructure is built using reusable Terraform modules rather than duplicating infrastructure code for every environment.

Each environment consumes the same core modules while using environment-specific configuration for infrastructure sizing, scaling, networking, and database requirements.

Key Objectives

Build reusable Terraform modules
Separate development, staging, and production environments
Implement AWS networking infrastructure
Deploy scalable compute infrastructure
Deploy private RDS PostgreSQL databases
Configure Terraform remote state
Implement state locking
Apply Infrastructure as Code best practices
Maintain a clean and reproducible Git workflow

🏗️ Architecture

📁 Repository Structure

Terraform-Project/
│
├── .gitignore
├── .terraform.lock.hcl
│
├── modules/
│   ├── vpc/
│   │   ├── main.tf
│   │   ├── nacl.tf
│   │   ├── outputs.tf
│   │   └── variables.tf
│   │
│   ├── compute/
│   │   ├── main.tf
│   │   ├── outputs.tf
│   │   └── variables.tf
│   │
│   └── database/
│       ├── main.tf
│       ├── outputs.tf
│       └── variables.tf
│
├── dev/
│   ├── .terraform.lock.hcl
│   ├── main.tf
│   ├── outputs.tf
│   ├── provider.tf
│   ├── variables.tf
│   └── versions.tf
│
├── stage/
│   ├── .terraform.lock.hcl
│   ├── main.tf
│   ├── outputs.tf
│   ├── provider.tf
│   ├── variables.tf
│   └── versions.tf
│
└── prod/
    ├── .terraform.lock.hcl
    ├── main.tf
    ├── outputs.tf
    ├── provider.tf
    ├── variables.tf
    └── versions.tf

🔐 Files intentionally excluded from Git

Environment-specific files such as:

terraform.tfvars
backend.hcl
terraform.tfstate
tfplan
.terraform/

are excluded from the repository through .gitignore.

This prevents environment-specific configuration, state files, generated plans, and potentially sensitive values from being committed.

🧩 Terraform Modules

🌐 VPC Module

The networking module provisions the foundational AWS network infrastructure.

Components

VPC
Public subnets
Private subnets
Internet Gateway
NAT Gateways
Route tables
Route table associations
Network ACL configuration

🖥️ Compute Module

The compute module provides scalable application infrastructure.

Components

EC2 Launch Template
Auto Scaling Group
Application Security Group
Environment-specific scaling configuration

🗄️ Database Module

The database module provisions PostgreSQL infrastructure using Amazon RDS.

Components

RDS PostgreSQL
DB subnet group
Database Security Group
Private database networking
Encryption configuration
Backup configuration
Production Multi-AZ configuration

🌎 Environment Design

Each environment uses the same reusable modules while allowing infrastructure capacity to vary according to its purpose.

Environment	VPC CIDR	EC2 Type	ASG Min	ASG Desired	ASG Max	RDS	Multi-AZ
Development	`10.0.0.0/16`	`t3.micro`	1	1	2	PostgreSQL	No
Staging	`10.1.0.0/16`	`t3.small`	1	2	3	PostgreSQL	No
Production	`10.2.0.0/16`	`t3.medium`	2	3	5	PostgreSQL	Yes

Production is intentionally configured with higher capacity and resilience than development and staging.

☁️ AWS Services

This project uses several AWS services:

AWS Service	Purpose
Amazon VPC	Network isolation
Subnets	Public/private network segmentation
Internet Gateway	Internet connectivity
NAT Gateway	Outbound private subnet connectivity
Route Tables	Network traffic routing
Network ACLs	Subnet-level traffic control
EC2	Application compute
Auto Scaling	Application scalability
Launch Template	EC2 configuration
Security Groups	Instance-level network security
Amazon RDS	Managed PostgreSQL database
Amazon S3	Terraform remote state
DynamoDB	Terraform state locking

🔐 Terraform Remote State

Terraform state is stored remotely using Amazon S3.

State locking is implemented using DynamoDB.

Example backend configuration:

bucket         = "multi-environment-terraform-150926"
key            = "dev/terraform.tfstate"
region         = "eu-west-1"
dynamodb_table = "terraform-locks"
encrypt        = true

Each environment uses its own state key to maintain environment isolation.

The actual backend configuration files are intentionally excluded from this repository.

🚀 Getting Started

Prerequisites

Install and configure:

Terraform
AWS CLI
AWS credentials
Git

Your AWS identity must have appropriate permissions to provision the required infrastructure.

Clone the Repository

Using SSH:

git clone git@github.com:Jahmeeu-Cloud/terraform-aws-multi-environment-infrastructure.git

Then:

cd terraform-aws-multi-environment-infrastructure

🔧 Deploy Development

cd dev

Initialize Terraform:

terraform init -backend-config=backend.hcl -reconfigure

Format:

terraform fmt -recursive

Validate:

terraform validate

Create a plan:

terraform plan -var-file=terraform.tfvars -out=tfplan

Apply:

terraform apply tfplan

View outputs:

terraform output

🔧 Deploy Staging

cd ../stage

Initialize:

terraform init -backend-config=backend.hcl -reconfigure

Validate:

terraform validate

Plan:

terraform plan -var-file=terraform.tfvars -out=tfplan

Apply:

terraform apply tfplan

🔧 Deploy Production

cd ../prod

Initialize:

terraform init -backend-config=backend.hcl -reconfigure

Validate:

terraform validate

Plan:

terraform plan -var-file=terraform.tfvars -out=tfplan

Apply:

terraform apply tfplan

🔄 Standard Terraform Workflow

terraform fmt
terraform validate
terraform plan
terraform apply

For a controlled deployment using a saved plan:

terraform plan -out=tfplan
terraform apply tfplan

To inspect deployed outputs:

terraform output

🛡️ Security Considerations

This project is designed as a practical cloud engineering and Infrastructure-as-Code portfolio project.

Several production hardening improvements should be considered before using the configuration for a real production workload.

Current Security Design

RDS is deployed in private subnets.
Database access is controlled through security groups.
Production RDS is encrypted.
Production RDS uses Multi-AZ.
Production RDS has deletion protection enabled.
Terraform state is stored remotely.
Environment-specific configuration files are excluded from Git.

Recommended Improvements

Replace direct SSH access with AWS Systems Manager Session Manager.
Restrict SSH source IPs where SSH is required.
Store database credentials in AWS Secrets Manager or Systems Manager Parameter Store.
Place application instances in private subnets.
Introduce an Application Load Balancer.
Add CloudWatch monitoring and alarms.
Implement least-privilege IAM policies.

💰 Cost Considerations

The infrastructure contains AWS resources that can generate ongoing costs, including:

NAT Gateways
EC2 instances
Auto Scaling Groups
RDS
Elastic IPs

For development and testing, unused environments should be destroyed when no longer required.

terraform destroy -var-file=terraform.tfvars

Always verify the Terraform plan before destroying infrastructure.

🧠 Skills Demonstrated

Infrastructure as Code

Terraform
Terraform Modules
Remote State
State Locking
Environment Isolation
Infrastructure Automation

AWS

VPC
EC2
Auto Scaling
RDS
S3
DynamoDB
IAM
Security Groups
Network ACLs
NAT Gateway
Internet Gateway
Route Tables

DevOps

Git
GitHub
Linux
Infrastructure automation
Environment management

Architecture

Modular infrastructure
Public/private network segmentation
High availability concepts
Scalable compute
Managed database architecture

📈 Future Improvements

Planned improvements include:

[ ] Application Load Balancer
[ ] Private application subnets
[ ] AWS Systems Manager integration
[ ] CloudWatch dashboards and alarms
[ ] GitHub Actions CI/CD
[ ] Terraform plan checks on pull requests
[ ] Infracost integration
[ ] Secrets Manager integration
[ ] Additional security hardening
[ ] Cost optimization for NAT Gateways
[ ] Automated infrastructure testing

🎯 Project Purpose

This project was built to demonstrate practical experience designing and deploying cloud infrastructure using Terraform and AWS.

Rather than maintaining separate duplicated Terraform configurations, reusable modules are used across multiple environments.

The project demonstrates how infrastructure can be:

Reusable
Scalable
Environment-aware
Version controlled
Automated
Easier to maintain

It forms part of my ongoing Cloud, DevOps, and Platform Engineering learning journey.

👨🏾‍💻 Author

Jamiu Olatunji Bakre

Cloud / DevOps Engineer | AWS | Terraform | Kubernetes | Platform Engineering

I build and automate cloud infrastructure with a focus on AWS, Infrastructure as Code, DevOps practices, and scalable platform engineering.

Connect With Me

GitHub: Jahmeeu-Cloud
LinkedIn: Jamiu Bakre
Portfolio: CloudWithHorla Portfolio

⭐ If you find this project useful

Feel free to explore the repository, review the Terraform modules, and follow the project as it evolves.

Built with Terraform + AWS ☁️

Multi-Environment Terraform Infrastructure on AWS

BAKRE JAMIU — Tue, 15 Sep 2026 16:34:38 +0000

📌 Project Overview

This project demonstrates the design and deployment of AWS infrastructure across three independent environments:

Development
Staging
Production

The infrastructure is built using reusable Terraform modules rather than duplicating infrastructure code for every environment.

Each environment consumes the same core modules while using environment-specific configuration for infrastructure sizing, scaling, networking, and database requirements.

Key Objectives

Build reusable Terraform modules
Separate development, staging, and production environments
Implement AWS networking infrastructure
Deploy scalable compute infrastructure
Deploy private RDS PostgreSQL databases
Configure Terraform remote state
Implement state locking
Apply Infrastructure as Code best practices
Maintain a clean and reproducible Git workflow

🏗️ Architecture

📁 Repository Structure

Terraform-Project/
│
├── .gitignore
├── .terraform.lock.hcl
│
├── modules/
│   ├── vpc/
│   │   ├── main.tf
│   │   ├── nacl.tf
│   │   ├── outputs.tf
│   │   └── variables.tf
│   │
│   ├── compute/
│   │   ├── main.tf
│   │   ├── outputs.tf
│   │   └── variables.tf
│   │
│   └── database/
│       ├── main.tf
│       ├── outputs.tf
│       └── variables.tf
│
├── dev/
│   ├── .terraform.lock.hcl
│   ├── main.tf
│   ├── outputs.tf
│   ├── provider.tf
│   ├── variables.tf
│   └── versions.tf
│
├── stage/
│   ├── .terraform.lock.hcl
│   ├── main.tf
│   ├── outputs.tf
│   ├── provider.tf
│   ├── variables.tf
│   └── versions.tf
│
└── prod/
    ├── .terraform.lock.hcl
    ├── main.tf
    ├── outputs.tf
    ├── provider.tf
    ├── variables.tf
    └── versions.tf

🔐 Files intentionally excluded from Git

Environment-specific files such as:

terraform.tfvars
backend.hcl
terraform.tfstate
tfplan
.terraform/

are excluded from the repository through .gitignore.

This prevents environment-specific configuration, state files, generated plans, and potentially sensitive values from being committed.

🧩 Terraform Modules

🌐 VPC Module

The networking module provisions the foundational AWS network infrastructure.

Components

VPC
Public subnets
Private subnets
Internet Gateway
NAT Gateways
Route tables
Route table associations
Network ACL configuration

🖥️ Compute Module

The compute module provides scalable application infrastructure.

Components

EC2 Launch Template
Auto Scaling Group
Application Security Group
Environment-specific scaling configuration

🗄️ Database Module

The database module provisions PostgreSQL infrastructure using Amazon RDS.

Components

RDS PostgreSQL
DB subnet group
Database Security Group
Private database networking
Encryption configuration
Backup configuration
Production Multi-AZ configuration

🌎 Environment Design

Each environment uses the same reusable modules while allowing infrastructure capacity to vary according to its purpose.

Environment	VPC CIDR	EC2 Type	ASG Min	ASG Desired	ASG Max	RDS	Multi-AZ
Development	`10.0.0.0/16`	`t3.micro`	1	1	2	PostgreSQL	No
Staging	`10.1.0.0/16`	`t3.small`	1	2	3	PostgreSQL	No
Production	`10.2.0.0/16`	`t3.medium`	2	3	5	PostgreSQL	Yes

Production is intentionally configured with higher capacity and resilience than development and staging.

☁️ AWS Services

This project uses several AWS services:

AWS Service	Purpose
Amazon VPC	Network isolation
Subnets	Public/private network segmentation
Internet Gateway	Internet connectivity
NAT Gateway	Outbound private subnet connectivity
Route Tables	Network traffic routing
Network ACLs	Subnet-level traffic control
EC2	Application compute
Auto Scaling	Application scalability
Launch Template	EC2 configuration
Security Groups	Instance-level network security
Amazon RDS	Managed PostgreSQL database
Amazon S3	Terraform remote state
DynamoDB	Terraform state locking

🔐 Terraform Remote State

Terraform state is stored remotely using Amazon S3.

State locking is implemented using DynamoDB.

Example backend configuration:

bucket         = "multi-environment-terraform-150926"
key            = "dev/terraform.tfstate"
region         = "eu-west-1"
dynamodb_table = "terraform-locks"
encrypt        = true

Each environment uses its own state key to maintain environment isolation.

The actual backend configuration files are intentionally excluded from this repository.

🚀 Getting Started

Prerequisites

Install and configure:

Terraform
AWS CLI
AWS credentials
Git

Your AWS identity must have appropriate permissions to provision the required infrastructure.

Clone the Repository

Using SSH:

git clone git@github.com:Jahmeeu-Cloud/terraform-aws-multi-environment-infrastructure.git

Then:

cd terraform-aws-multi-environment-infrastructure

🔧 Deploy Development

cd dev

Initialize Terraform:

terraform init -backend-config=backend.hcl -reconfigure

Format:

terraform fmt -recursive

Validate:

terraform validate

Create a plan:

terraform plan -var-file=terraform.tfvars -out=tfplan

Apply:

terraform apply tfplan

View outputs:

terraform output

🔧 Deploy Staging

cd ../stage

Initialize:

terraform init -backend-config=backend.hcl -reconfigure

Validate:

terraform validate

Plan:

terraform plan -var-file=terraform.tfvars -out=tfplan

Apply:

terraform apply tfplan

🔧 Deploy Production

cd ../prod

Initialize:

terraform init -backend-config=backend.hcl -reconfigure

Validate:

terraform validate

Plan:

terraform plan -var-file=terraform.tfvars -out=tfplan

Apply:

terraform apply tfplan

🔄 Standard Terraform Workflow

terraform fmt
terraform validate
terraform plan
terraform apply

For a controlled deployment using a saved plan:

terraform plan -out=tfplan
terraform apply tfplan

To inspect deployed outputs:

terraform output

🛡️ Security Considerations

This project is designed as a practical cloud engineering and Infrastructure-as-Code portfolio project.

Several production hardening improvements should be considered before using the configuration for a real production workload.

Current Security Design

RDS is deployed in private subnets.
Database access is controlled through security groups.
Production RDS is encrypted.
Production RDS uses Multi-AZ.
Production RDS has deletion protection enabled.
Terraform state is stored remotely.
Environment-specific configuration files are excluded from Git.

Recommended Improvements

Replace direct SSH access with AWS Systems Manager Session Manager.
Restrict SSH source IPs where SSH is required.
Store database credentials in AWS Secrets Manager or Systems Manager Parameter Store.
Place application instances in private subnets.
Introduce an Application Load Balancer.
Add CloudWatch monitoring and alarms.
Implement least-privilege IAM policies.

💰 Cost Considerations

The infrastructure contains AWS resources that can generate ongoing costs, including:

NAT Gateways
EC2 instances
Auto Scaling Groups
RDS
Elastic IPs

For development and testing, unused environments should be destroyed when no longer required.

terraform destroy -var-file=terraform.tfvars

Always verify the Terraform plan before destroying infrastructure.

🧠 Skills Demonstrated

Infrastructure as Code

Terraform
Terraform Modules
Remote State
State Locking
Environment Isolation
Infrastructure Automation

AWS

VPC
EC2
Auto Scaling
RDS
S3
DynamoDB
IAM
Security Groups
Network ACLs
NAT Gateway
Internet Gateway
Route Tables

DevOps

Git
GitHub
Linux
Infrastructure automation
Environment management

Architecture

Modular infrastructure
Public/private network segmentation
High availability concepts
Scalable compute
Managed database architecture

📈 Future Improvements

Planned improvements include:

[ ] Application Load Balancer
[ ] Private application subnets
[ ] AWS Systems Manager integration
[ ] CloudWatch dashboards and alarms
[ ] GitHub Actions CI/CD
[ ] Terraform plan checks on pull requests
[ ] Infracost integration
[ ] Secrets Manager integration
[ ] Additional security hardening
[ ] Cost optimization for NAT Gateways
[ ] Automated infrastructure testing

🎯 Project Purpose

This project was built to demonstrate practical experience designing and deploying cloud infrastructure using Terraform and AWS.

Rather than maintaining separate duplicated Terraform configurations, reusable modules are used across multiple environments.

The project demonstrates how infrastructure can be:

Reusable
Scalable
Environment-aware
Version controlled
Automated
Easier to maintain

It forms part of my ongoing Cloud, DevOps, and Platform Engineering learning journey.

👨🏾‍💻 Author

Jamiu Olatunji Bakre

Cloud / DevOps Engineer | AWS | Terraform | Kubernetes | Platform Engineering

I build and automate cloud infrastructure with a focus on AWS, Infrastructure as Code, DevOps practices, and scalable platform engineering.

Connect With Me

GitHub: Jahmeeu-Cloud
LinkedIn: Jamiu Bakre
Portfolio: CloudWithHorla Portfolio

⭐ If you find this project useful

Feel free to explore the repository, review the Terraform modules, and follow the project as it evolves.

Built with Terraform + AWS ☁️

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

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

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

Introduction

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

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

1. My starting point

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

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

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

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

A few of my early wrong assumptions:

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

3. Setup: Minikube, Docker, and permissions

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

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

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

4. My first Pod and the patience it taught me

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

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

5. Deployments, ReplicaSets, and reconciliation

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

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

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

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

I learned this when I ran:

minikube service nginx -n development

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

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

7. Scaling

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

8. Troubleshooting 🛠️

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

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

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

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

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

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

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

11. Commands that actually helped me

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

12. Lessons for other beginners

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

What I now understand

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

What I still need to learn

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

Next stop: Kubernetes Ingress 🚦

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

Conclusion

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

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

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

📘 Ansible Learning Journey - From Manual SSH to Automation Thinking

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

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

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

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

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

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

🏗️ Project Overview

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

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

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

🔧 What I Implemented (Step-by-Step)

Provisioned EC2 instances

1 controller
3 managed nodes

Installed core dependencies

Python3
Pip
Ansible on the controller

Created Ansible configuration

Custom ansible.cfg
Inventory file defining all target nodes

SSH Key-Based Authentication

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

Learned the difference between:

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

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

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

Caveat: Best practise

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

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

Caveat: Not a best practise

Sample

Privilege Escalation

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

Ansible Ad-Hoc Commands

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

Ansible Playbook Execution

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

📄 Sample Playbook used in my project:

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

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

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

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

⚠️ Challenges I Faced (and What I Learned)

1️⃣ “Permission denied (publickey)”

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

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

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

2️⃣ PasswordAuthentication Confusion

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

That was a big lesson:

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

Correct order matters:

Establish SSH key access
Test connectivity
Then disable password authentication

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

One node failed while others succeeded.

Cause:

Ubuntu auto-updates were running in the background

Lesson:

Infrastructure is not deterministic — nodes behave independently.

Solution:

Wait and retry
Or design playbooks with retries and checks

Screenshot Output

This is when I ping of the node

This is when I ping all the node

This is the first page output of my Playbook

This is the second page output of my Playbook

Node 01

Node 02

Node 03

4️⃣ Wrong Package Names

I attempted to install apache instead of apache2.

Lesson:

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

Small naming errors can break entire workflows.

🧠 Key Takeaways I Want Others to Learn

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

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

🌱 Growth Mindset

This project reinforced my core belief:

Never stop learning.

Every error I faced forced me to:

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

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

📌 Final Thought

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

CloudWithHorla ☁️
Cloud & DevOps Engineer | Always Learning

My Ongoing Cloud Migration Journey 🚀

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

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

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

What We’re Doing

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

Our scope includes:

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

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

My Role

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

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

What I’ve Achieved So Far

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

Where We Are Now

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

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

What Makes This Experience Stand Out

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

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

My Reflection

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

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

Building a Scalable AWS E-Learning Platform for Government Use

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

🌍 Project Overview

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

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

🧱 Architecture Goal

Design a 3-tier AWS architecture that ensures:

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

⚙️ Core AWS Services Used

1️⃣ User Authentication & Access Management

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

2️⃣ Video Delivery and Streaming

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

3️⃣ Multilingual AI Chatbot

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

4️⃣ Monitoring & Compliance

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

5️⃣ Quizzes & Progress Tracking

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

6️⃣ Data Storage & Analytics

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

Here is the Native Design below:

🏗️ 3-Tier Architecture Design

Tier 1: Web Layer

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

Tier 2: Application Layer

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

Tier 3: Database Layer

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

Additional Infrastructure:

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

💰 Cost Optimization Highlights

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

🧠 Key Outcomes

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

🧾 Deliverables

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

🚀 Conclusion

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

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

📬 Connect With Me

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

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

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

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

Introduction

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

🛠 Project Objective

Task: Downgrade AWS Lightsail instance to a smaller plan.

Goal: Achieve cost savings while keeping the application online.

📌 Project Context

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

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

🎯 Objectives

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

📍 End-to-End Execution

Day 1: Assessment & Planning

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

1. Resource Utilization Analysis

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

2. Downgrade Strategy Design

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

3. Backup Creation

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

🎯 What I achieved on Day 1:

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

Created a rollback plan in case of failure.

Backed up the existing instance snapshot for disaster recovery.

Day 2: Environment Setup & Migration

1. Provisioning the New Lightsail Instance

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

2. Application Environment Configuration

Installed required packages:

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

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

3. Database Migration

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

  mysql -u username -p database_name < backup.sql

4. Nginx & SSL Setup

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

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

Validated with nginx -t and reloaded.

5. Application Process Management

Started application with PM2:

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

Ensured auto-start on reboot.

🎯 What I achieved on Day 2 – Environment Preparation:

Provisioned a new Lightsail instance with the downgraded size.

Configured security groups, firewall rules, and SSH access.

Migrated application files and environment variables from the old server.

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

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

Day 3: DNS Cutover & Validation

1. DNS Redirection

Updated Lightsail static IP for the new instance.

2. Testing & Monitoring

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

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

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

3. Final Optimization

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

🎯 What I achieved on Day 3 – Cutover & Optimization

Redirected DNS records to the new Lightsail instance.

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

Verified user sessions and ensured HTTPS redirection was functioning properly.

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

Documented the final architecture and cost reduction achieved.

✅ Deliverables

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

📊 Results & Impact

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

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

💡 Lessons Learned

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

🏆 Conclusion

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

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

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

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

🏗️ Project Setup

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

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

My app.py had two routes:

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

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

🐳 Dockerfile Setup

I created a simple Dockerfile:

FROM python:3.11-slim

WORKDIR /app

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

COPY . .

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

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

💥 The First Crash: Dependency Drama

When I ran:

docker compose -f compose.yml up --build

Boom 💣

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

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

🔧 Fix:

I upgraded the base image in my Dockerfile to:

FROM python:3.11-slim

Problem solved. ✅

🧊 The Second Freeze: Compose Conundrum

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

KeyError: 'ContainerConfig'

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

🕵️‍♂️ Root Cause:

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

🔧 Fix:

I upgraded to Docker Compose v2 using:

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

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

🟢 Final Compose File

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

version: '3.8'

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

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

volumes:
  db-data:

🎯 The Sweet Success

After all the bumps, running the final command:

docker compose up --build

…worked flawlessly. I visited:

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

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

💡 Key Takeaways

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

🏁 Final Words

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

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

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

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

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

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

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

📌 Step 1: Create a Docker Network

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

docker network create jamiu-network

🧱 Step 2: Deploy the MongoDB Container

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

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

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

🌐 Step 3: Deploy Mongo Express

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

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

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

The view for Mongo-express

⚔️ Real Talk: Troubleshooting Was My Superpower

Was it smooth sailing? Absolutely not.

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

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

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

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

🧪 Step 4: Test Volume Persistence Like a Pro

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

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

Inside Mongo shell:

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

Then came the real test.

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

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

Connected again...
And guess what? 🎉

db.testcollection.find()

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

🚀 Final Thoughts: This Is Cloud Engineering

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

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

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

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

Let’s connect.