6.1 KiB
Vigimétéo – Kubernetes Deployment (z2)
1. Application description
Vigimétéo is a weather monitoring web application.
Users can log in, browse weather stations, consult meteorological data (wind, temperature, pressure…) and manage objects depending on their role.
The stack is made of three services:
- A React frontend served by Nginx
- A Java / Vert.x REST backend that exposes the API
- A PostgreSQL database that stores all data
2. Containers used
| Container | Image | Role |
|---|---|---|
vigimeteo-frontend |
vigimeteo-frontend:latest (built from Front-end/Dockerfile) |
React SPA built with Vite, served by Nginx on port 80 |
vigimeteo-backend |
vigimeteo-backend:latest (built from Back-end/Dockerfile) |
Java 17 / Vert.x REST API on port 8888. Connects to PostgreSQL using environment variables |
postgres |
postgres:17-alpine |
PostgreSQL database. Automatically runs init.sql on first start to create tables and insert seed data |
busybox (init) |
busybox:1.36 |
Temporary init container inside the backend pod. Waits until PostgreSQL port 5432 is open before letting the backend start |
3. Kubernetes objects
| Kind | Name | Description |
|---|---|---|
Namespace |
vigimeteo |
Isolates all objects of this application from the rest of the cluster |
PersistentVolume |
vigimeteo-db-pv |
1 Gi storage volume mapped to ~/vigimeteo-db-data on the host node |
PersistentVolumeClaim |
vigimeteo-db-pvc |
Request for storage, bound to the PV above. Used by the StatefulSet |
ConfigMap |
vigimeteo-db-init |
Holds the SQL init script (init.sql). Mounted into the PostgreSQL container |
StatefulSet |
vigimeteo-db |
Manages the PostgreSQL pod. Provides a stable name and stable storage |
Deployment |
vigimeteo-backend |
Manages 2 replicas of the Vert.x backend |
Deployment |
vigimeteo-frontend |
Manages 2 replicas of the Nginx/React frontend |
Service (Headless) |
vigimeteo-db |
Gives the PostgreSQL pod a stable DNS name: vigimeteo-db.vigimeteo.svc.cluster.local |
Service (NodePort) |
vigimeteo-backend-service |
Exposes the backend API on port 30888 (accessible from the host) |
Service (NodePort) |
vigimeteo-frontend-service |
Exposes the frontend on port 30500 (accessible from the host) |
4. Networks and volumes
Network
Kubernetes creates a virtual internal network for the vigimeteo namespace automatically.
- Pods communicate internally using DNS service names (e.g.
vigimeteo-db.vigimeteo.svc.cluster.local). - The frontend and backend are exposed externally via NodePort services.
| Access | Address |
|---|---|
| Frontend (browser) | http://localhost:30500 |
| Backend API | http://localhost:30888 |
| Database (internal only) | vigimeteo-db.vigimeteo.svc.cluster.local:5432 |
Volume
| Name | Type | Host path | Used by |
|---|---|---|---|
vigimeteo-db-pv |
PersistentVolume (hostPath) | ~/vigimeteo-db-data |
PostgreSQL StatefulSet |
The volume is created by prepare-app.sh with mkdir -p ~/vigimeteo-db-data.
It persists data even after the application is stopped.
5. Container configuration
Backend – environment variables
The backend connects to the database using these environment variables set in deployment.yaml:
| Variable | Value |
|---|---|
DB_HOST |
vigimeteo-db.vigimeteo.svc.cluster.local |
DB_PORT |
5432 |
DB_NAME |
postgres |
DB_USER |
postgres |
DB_PASSWORD |
admin |
Backend – init container
To avoid connection errors on startup, a busybox init container runs first and waits until PostgreSQL accepts connections on port 5432:
until nc -z vigimeteo-db.vigimeteo.svc.cluster.local 5432; do sleep 3; done
Database – init script
The ConfigMap vigimeteo-db-init contains init.sql and is mounted into /docker-entrypoint-initdb.d/ inside the PostgreSQL container. PostgreSQL automatically runs all .sql files in that folder on first startup.
Images
Both images are built locally with imagePullPolicy: IfNotPresent so Kubernetes never tries to pull them from a registry.
6. How to run the application
Prerequisites
dockerinstalled and runningkubectlconfigured and connected to a cluster- For Minikube: run
eval $(minikube docker-env)first so images are built inside Minikube's daemon
Step 1 – Prepare (first time only)
bash prepare-app.sh
This creates the PV host directory and builds the two Docker images.
Step 2 – Start
bash start-app.sh
Applies all Kubernetes objects in the correct order and waits for PostgreSQL to be ready before deploying the backend.
Step 3 – Pause / restart
There is no "pause" in Kubernetes. To stop traffic you can scale down replicas:
kubectl scale deployment vigimeteo-backend vigimeteo-frontend --replicas=0 -n vigimeteo
To restart:
kubectl scale deployment vigimeteo-backend vigimeteo-frontend --replicas=2 -n vigimeteo
Step 4 – Delete
bash stop-app.sh
This deletes the namespace (which removes all objects inside it) and the PersistentVolume.
The data folder ~/vigimeteo-db-data is not deleted. To fully clean up:
rm -rf ~/vigimeteo-db-data
7. How to access the application
Once the app is started, open your browser at:
Test credentials
| Role | Password | |
|---|---|---|
| Admin | admin@a.com |
azertyuiop |
| Complexe user | complexe@gmail.com |
azertyuiop |
| Regular user | user@gmail.com |
azertyuiop |
Verify everything is running
kubectl get all -n vigimeteo
All pods should show 1/1 Running.
Troubleshooting
Pod stays Pending → The PVC is not bound. Run kubectl describe pod -n vigimeteo <pod-name> and check the events. Make sure ~/vigimeteo-db-data exists.
Backend CrashLoopBackOff → Check logs with kubectl logs -n vigimeteo deployment/vigimeteo-backend. Usually a DB connection issue.
Images not found → For Minikube, run eval $(minikube docker-env) before prepare-app.sh.