This project started with a simple goal: deploy an e-commerce application the way real systems are deployed — not locally, not manually, and not magically.
I wanted to understand the entire flow: code → version control → containerization → registry → cloud server → running services → observability. So I built the system end to end and deployed it on AWS EC2 using Docker and Docker Compose.
Repository: https://github.com/BayoJohn/Project-2.git
🚀 The Problem I Wanted to Solve
A lot of projects stop at “it works on my machine.” I wanted to go further and deal with the questions that appear the moment you leave localhost:
- How does the application get packaged?
- How does the server get the application?
- How are services started reliably?
- How do you observe what’s running?
This project forced me to answer those questions directly.
📦 Version Control as the Starting Point
Setting up the GitHub repository to track infrastructure and application code.
Everything begins with a Git repository. I created a GitHub repo to serve as the single source of truth for the application code and infrastructure configuration. This wasn’t just about backup — it was about traceability. Every change to the system has a history, and that history matters once deployment is involved.
🐳 Containerizing the Application
I containerized the application using Docker because consistency is non-negotiable in deployment. Containers ensure the same environment runs locally and on the server, eliminating the “works here, breaks there” problem.
Docker Compose was used to define how multiple services run together. Instead of starting services manually, Compose allowed me to declare the system: the application, its dependencies, and how they communicate.
⚙️ Automating Builds with GitHub Actions
After containerizing the application, I introduced GitHub Actions to automate the build process. The goal wasn’t complexity — it was consistency.
Defining the CI/CD pipeline in YAML to automate testing and building.
This step mirrors how production teams treat builds: servers don’t compile code, and deployments don’t depend on local machines.
A successful GitHub Actions run: verified, built, and ready to deploy.
📤 Using Docker Hub as an Image Registry
Pushing the final Docker image to Docker Hub for centralized access.
After building the Docker images, I pushed them to Docker Hub. The registry acts as the bridge between development and production. Instead of copying files or rebuilding images on the server, the EC2 instance simply pulls the exact image it needs.
☁️ Provisioning the Server on AWS EC2
For the infrastructure, I used an AWS EC2 instance. EC2 was a deliberate choice because it exposes you to the fundamentals of cloud computing without abstracting too much away.
The AWS EC2 Console: Provisioning the virtual server that hosts the application.
Once the instance was created, I installed Docker and Docker Compose directly on the server.
A quick docker ps on the EC2 instance confirms that all 6 services—from the DB to the monitoring tools—are Up and healthy.
🚀 Deploying the Application on EC2
With Docker installed, the deployment flow was straightforward but intentional. I cloned the repository onto the EC2 instance, pulled the images, and started the services.
The terminal view: Using Docker Compose to spin up the entire multi-container stack.
📊 Monitoring and Observability with Grafana
Deployment isn’t complete if you can’t see what’s happening.
Real-time observability: Monitoring the EC2 instance health via Grafana.
I included Grafana in the stack to introduce observability early. Grafana provides visibility into system metrics like CPU, RAM, and network health.
Configuring the security groups and instance details to allow public access.
🧠 What This Project Changed for Me
This project shifted my mindset from “writing code” to “operating systems.” You stop thinking only about features and start thinking about reliability and repeatability. Breaking things on a real server teaches lessons no tutorial ever will.
💡 Final Thoughts
If you’re learning DevOps or cloud engineering, my advice is simple: deploy something real. Deal with registries, ports, servers, and failures. That’s where the abstractions disappear and understanding begins.
Top comments (0)