Introduction
As part of my DevOps learning journey in DMI Cohort 2, I deployed the Spring Petclinic Microservices application locally using Docker Compose.
Spring Petclinic is a cloud-native microservices application designed to demonstrate modern software architecture patterns. Instead of a single monolithic application, the system consists of multiple independent services that communicate with one another.
The deployment includes:
Config Server
Discovery Server (Eureka)
API Gateway
Customers Service
Visits Service
Vets Service
GenAI Service
Admin Server
In addition, the application includes a complete observability stack:
Prometheus
Grafana
Zipkin
The goal of this project was to deploy, verify, monitor, and troubleshoot a production-style microservices environment using Docker Compose.
Prerequisites
Before deployment, I installed and configured the following tools:
Docker
Docker was used to build and run all application containers.
Verify installation:
docker --version
Git
Git was used to clone and manage the repository.
Verify installation:
git --version
GitHub Codespaces
I used GitHub Codespaces as my development environment because my AWS account was unavailable during this project.
Step 1: Clone the Repository
I cloned the Spring Petclinic Microservices repository:
git clone https://github.com/PETCLINIC-PROJECT-GROUP-5/spring-petclinic-microservices.git
Navigate into the project:
cd spring-petclinic-microservices
Verify the repository contents:
ls
The repository contained all required microservices, Docker Compose configuration, Kubernetes manifests, and supporting documentation.
Step 2: Start the Application
The entire application can be deployed using a single command:
docker compose up -d
This command performs several tasks:
Pulls required Docker images
Creates containers
Creates a Docker network
Starts services in the background
After execution, Docker reported that all containers started successfully.
Particularly important were:
config-server
discovery-server
Both services became healthy before the remaining services started.
Why Config Server and Discovery Server Start First
The Config Server provides centralised configuration for all microservices.
The Discovery Server (Eureka) allows services to register themselves and discover other services dynamically.
Without these services running first:
Application services cannot load the configuration
Services cannot register with Eureka
Inter-service communication may fail
Docker Compose uses startup dependencies and health checks to ensure the correct startup sequence.
Step 3: Verify Running Containers
To verify deployment status, I ran:
docker compose ps
This displayed all running containers and their health status.
Services included:
config-server
discovery-server
api-gateway
customers-service
visits-service
vets-service
genai-service
admin-server
prometheus-server
grafana-server
tracing-server
All services reported a healthy or running status.
Step 4: Application Verification
After deployment, I verified each application endpoint.
Spring Petclinic
http://localhost:8080
The main application loaded successfully.
Eureka Dashboard
http://localhost:8761
Displayed all registered services.
Spring Boot Admin
http://localhost:9090
Provided centralized monitoring of Spring Boot applications.
Zipkin
http://localhost:9411
Displayed distributed traces across services.
Prometheus
http://localhost:9091
Collected and displayed application metrics.
Grafana
http://localhost:3030
Visualised metrics through dashboards.
Observability Stack
One of the most valuable parts of this project was understanding observability.
Prometheus
Prometheus collected metrics from application services.
I executed queries such as:
http_server_requests_seconds_count
This provided visibility into application requests and performance.
Grafana
Grafana converted Prometheus metrics into visual dashboards.
I was able to monitor:
Service health
Request counts
Response times
Application activity
Zipkin
Zipkin provided distributed tracing.
This allowed me to follow a request as it travelled through multiple microservices.
It demonstrated how modern cloud-native applications handle service-to-service communication.
Biggest Challenge
The most challenging part of this project was troubleshooting Docker in GitHub Codespaces.
Initially, the Codespace entered recovery mode because of container configuration issues.
Although Docker commands were installed, Docker could not connect to the daemon.
As a result:
Docker image builds failed
Docker Compose could not start containers
After reviewing the devcontainer configuration, rebuilding the Codespace environment, and validating Docker daemon connectivity, I successfully resolved the issue.
This experience improved my troubleshooting skills and deepened my understanding of Docker architecture.
Stopping and Cleaning Up
After completing verification and testing, I stopped the environment using:
docker compose down
This command:
Stops containers
Removes containers
Removes Docker networks
Free system resources
Cleaning up environments is an important DevOps practice.
Key Lessons Learned
This project taught me several valuable DevOps concepts:
Microservices architecture
Containerization with Docker
Service discovery using Eureka
Centralized configuration management
Observability using Prometheus, Grafana, and Zipkin
Troubleshooting Docker environments
Deploying and managing multi-container applications
Most importantly, I learned that successful DevOps work involves not only deployment but also monitoring, troubleshooting, and maintaining system reliability.
DMI Cohort 2 Experience
This project was completed as part of DMI Cohort 2.
The hands-on nature of the program provided practical experience with real-world DevOps tools and deployment workflows.
If you're interested in learning DevOps through practical projects, DMI Cohort 3 registration is open:
https://docs.google.com/forms/d/e/1FAIpQLSel7ai7nyb0P1qLW4vEyfB_nEsD4lUF1XG88vmAaFGBOb6hPA/viewform
Thank you for reading, and happy learning!
Top comments (0)