Hi, I'm Shitanshu Jha, a BCA student and Java Backend Developer focused on building real-world applications using Java, Spring Boot, REST APIs, Spring Security, JPA/Hibernate, and MySQL.
One of the major projects I am currently developing is ShopEase, a full-stack e-commerce application.
ShopEase wasn't built in one go.
I have been developing it step by step and module by module. With every new module, I have faced new problems, debugged issues, understood why they occurred, and then implemented better solutions.
Throughout this journey, I have worked on different parts of an e-commerce system, including authentication, products, cart, wishlist, checkout, orders, validation, exception handling, security, and database integration.
After getting the core application working, I reached another important question:
How can I make ShopEase run consistently without depending entirely on the configuration of my local machine?
This question led me to Docker.
In Module 28, I successfully containerized ShopEase and tested the application with Spring Boot and MySQL running inside Docker containers.
🚀 Why I Added Docker to ShopEase
Before Docker, ShopEase depended heavily on my local development environment.
I needed the correct:
Java environment
MySQL installation
Database configuration
Application configuration
Ports
Credentials and other environment-specific values
My application might work perfectly on my computer, but that doesn't automatically mean it will behave exactly the same way on another machine.
That is the classic:
“It works on my machine.”
problem.
I wanted ShopEase to move beyond that kind of setup.
Instead of thinking only about writing backend code, I wanted to understand how an actual application can be packaged, configured, and run as multiple services.
That's why I decided to containerize it.
🧱 Step 1 — Understanding What Needed to Be Containerized
Before writing Docker configuration, I first looked at the basic ShopEase backend architecture.
It was essentially:
Frontend
│
▼
REST APIs
│
▼
Spring Boot Backend
│
▼
MySQL Database
The backend depends on MySQL.
So simply putting the Spring Boot application inside a container wasn't enough.
I needed two main services:
┌─────────────────────┐
│ Spring Boot Backend │
└──────────┬──────────┘
│
│ Database Connection
▼
┌─────────────────────┐
│ MySQL │
└─────────────────────┘
Both services needed to run independently while still being able to communicate.
That became the foundation of my Docker implementation.
🐳 Step 2 — Creating a Dockerfile for Spring Boot
The next step was creating a Dockerfile for the ShopEase backend.
A Dockerfile defines how Docker should create an image for an application.
The basic flow became:
ShopEase Backend
│
▼
Build Project
│
▼
JAR File
│
▼
Docker Image
│
▼
Docker Container
│
▼
Spring Boot Running
This was an important change in how I thought about the application.
Previously, I was mainly thinking:
Write Code → Run Spring Boot
Now I had to think:
Write Code
↓
Build Application
↓
Package Application
↓
Build Docker Image
↓
Create Container
↓
Run Application
It gave me a better understanding of how backend applications move from development toward deployment.
🗄️ Step 3 — Containerizing MySQL
ShopEase stores application data in MySQL.
So the next task was running MySQL as a separate container.
Now instead of thinking about MySQL only as a database installed on my Windows machine, I could treat it as an independent service.
The architecture started looking like this:
Docker
│
├── ShopEase Backend Container
│ │
│ │
│ ▼
│
└── MySQL Container
But this introduced one of the most important challenges.
⚠️ Challenge 1 — Connecting Spring Boot to MySQL
When both applications are running directly on the same machine, using localhost feels natural.
But containers change this concept.
Inside the Spring Boot container:
localhost
refers to the Spring Boot container itself.
It does not automatically mean the MySQL container.
That was an important concept for me to understand.
I needed the backend container to find and communicate with the database container correctly.
This led directly to the next part of the implementation.
🌐 Step 4 — Docker Networking
To allow the Spring Boot and MySQL containers to communicate, I configured them to work through Docker networking.
Conceptually, the architecture became:
Docker Network
│
┌───────────┴───────────┐
│ │
▼ ▼
┌──────────────┐ ┌──────────────┐
│ Spring Boot │ <────> │ MySQL │
│ Container │ │ Container │
└──────────────┘ └──────────────┘
Instead of treating the database as something running on the host machine, the backend can communicate with the database service inside the Docker environment.
This helped me understand an important Docker concept:
Containers are isolated, but they can communicate through properly configured networks.
⚠️ Challenge 2 — Application Configuration
Getting the containers running was only part of the work.
The Spring Boot application also needed the correct database configuration.
The application needed values such as:
Database Host
Database Port
Database Name
Database Username
Database Password
Hardcoding all of these values directly into the application would make the configuration difficult to manage across different environments.
So I worked with environment variables.
🔐 Step 5 — Using Environment Variables
Environment variables allowed me to separate configuration from application code.
For example, configuration can conceptually be represented as:
DB_HOST
DB_PORT
DB_NAME
DB_USERNAME
DB_PASSWORD
The application can then read these values from its environment.
This means the same application can work with different configurations.
For example:
Development Environment
│
├── Development DB
│
Testing Environment
│
├── Testing DB
│
Production Environment
│
└── Production DB
without requiring the actual application logic to be rewritten.
This also taught me an important backend engineering principle:
Configuration should be separated from application logic whenever possible.
Sensitive credentials should also not be committed directly to a public Git repository.
🧩 Step 6 — Bringing Everything Together with Docker Compose
At this point, ShopEase had more than one container.
I had:
Spring Boot Container
MySQL Container
Starting and managing every service separately would quickly become inconvenient.
That's where Docker Compose became useful.
With Docker Compose, I could describe the services required by ShopEase together.
Conceptually:
docker compose
│
├── Spring Boot Service
│
├── MySQL Service
│
├── Environment Variables
│
└── Networking
Then the complete environment could be managed as one multi-container application.
The startup process became much cleaner:
docker compose up
│
▼
Create / Start Services
│
├───────────────┐
▼ ▼
Spring Boot MySQL
Container Container
│ │
└──── Network ──┘
This was one of the biggest improvements Docker brought to ShopEase.
⚠️ Challenge 3 — Moving from Localhost Thinking to Container Thinking
One of my biggest learnings during this module was that containerized applications require a different way of thinking.
Previously, my environment was mostly:
My Computer
├── Java
├── Spring Boot
└── MySQL
After Docker:
My Computer
│
Docker
│
├── Spring Boot Container
│
└── MySQL Container
The application and database were no longer simply two programs running directly beside each other.
They were independent containers.
That affected:
Hostnames
Networking
Ports
Database configuration
Environment variables
Startup dependencies
Understanding these differences was one of the most valuable parts of this module.
🛠️ My Problem-Solving Approach
I have followed a similar development process throughout ShopEase.
Whenever something doesn't work, I try not to randomly change code until the error disappears.
My approach is generally:
Implement Feature
↓
Run Application
↓
Test Feature
↓
Observe Error
↓
Understand the Cause
↓
Change Configuration / Code
↓
Test Again
↓
Verify Complete Flow
I followed the same approach while implementing Docker.
Containerization introduced new problems because the environment was different from my normal local setup.
I had to understand how the Spring Boot container sees MySQL, how the services communicate, and how configuration should reach the application.
Solving those problems step by step made Docker much easier to understand than simply memorizing Docker commands.
🧪 Step 7 — Testing the Containerized Application
I didn't want to consider the module complete just because the containers started successfully.
The important question was:
Does ShopEase actually work correctly inside this environment?
So I tested the setup to verify that:
✅ Docker image builds correctly
✅ Spring Boot container starts
✅ MySQL container starts
✅ Spring Boot can communicate with MySQL
✅ Docker networking works
✅ Environment variables are passed correctly
✅ Database connectivity works
✅ Backend APIs continue functioning in the containerized environment
After testing the complete flow, I marked:
✅ Module 28 — Docker: Completed & Tested
🏗️ ShopEase Docker Architecture
The final containerized backend architecture can be visualized like this:
ShopEase
│
▼
Docker Compose
│
Docker Network
│
┌───────────┴───────────┐
│ │
▼ ▼
┌─────────────────────┐ ┌─────────────────┐
│ Spring Boot │ │ MySQL │
│ Container │◄─►│ Container │
│ │ │ │
│ ShopEase Backend │ │ ShopEase Data │
└─────────────────────┘ └─────────────────┘
│
▼
REST APIs
💡 What I Learned From Module 28
Before implementing this module, Docker was mostly another technology on my learning roadmap.
After actually integrating it into ShopEase, I understood why containerization matters.
I gained practical experience with:
Dockerfile — packaging the Spring Boot application.
Docker Images — understanding the blueprint used to create containers.
Docker Containers — running isolated application services.
Docker Compose — managing multiple services together.
Docker Networking — enabling communication between Spring Boot and MySQL.
Environment Variables — separating configuration from application code.
Containerized Databases — running MySQL as an independent service.
But the biggest learning wasn't a Docker command.
It was understanding that:
Building an application is not only about writing code. You also need to think about how that application will be configured, packaged, connected, run, tested, and eventually deployed.
👨💻 Building ShopEase Step by Step
ShopEase has been a learning-by-building project for me.
I didn't start by knowing everything required to build the complete application.
Instead, I have been developing it incrementally.
Learn
↓
Implement
↓
Face Problems
↓
Debug
↓
Understand
↓
Improve
↓
Move to Next Module
Every new feature has introduced something new for me to understand.
Some challenges have been related to backend logic, some to databases, some to security and API integration, and now some to infrastructure and containerization.
That process is exactly why I continue developing ShopEase.
The goal isn't just to add a long list of technologies to the project.
The goal is to understand why they are needed and how they work together in a real application.
🚀 What's Next for ShopEase?
Completing Docker doesn't mean ShopEase is finished.
Containerization is another step toward making the project more deployment-oriented.
My upcoming areas of focus include further improving:
Automated testing
CI/CD
Production configuration
Cloud deployment
Monitoring and logging
Backend reliability and optimization
I want to continue evolving ShopEase while learning the engineering practices used beyond local development.
🎯 Conclusion
Module 28 was more than simply adding a Dockerfile to ShopEase.
It changed how I think about running an application.
I moved from running Spring Boot and MySQL as locally configured components to understanding how they can operate as separate but connected containerized services.
During the implementation, I had to understand networking, configuration, environment variables, service communication, and multi-container management.
I faced problems, debugged them step by step, tested the complete setup, and finally got Spring Boot and MySQL running together successfully using Docker Compose.
There is still much more for me to learn and improve, but that's exactly how I am building ShopEase:
One module. One challenge. One solution at a time. 🚀
🐳 Module 28 — Docker
Status: ✅ Completed & Tested
Developed by Shitanshu Jha
Top comments (0)