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!