Title: Lab 4 — FastAPI + Redis + Trainer Multi-Container Stack
Course: AIINFRA 101: Applied Infrastructure & Containerization > Section: Week 04 — Docker Compose & Multi-Container AI Applications

🛠️ Lab 4 — FastAPI + Redis + Trainer Multi-Container Stack (50 pts)

Goal: Build a working multi-container AI application with Docker Compose — a FastAPI inference service, a Redis cache, and a third training-style container — and prove that service discovery, dependency ordering, and volume/environment wiring all work correctly. Steps:

1. Install/confirm Docker Desktop (bundles Compose v5.3.0+) is running: docker compose version.
2. Create a project folder week04-lab/ with subfolders app/ and trainer/.
3. In app/, write a minimal FastAPI application (main.py) with a /health route and a route that reads/writes a key in Redis using the hostname redis (not localhost). Add a simple Dockerfile for it (reuse patterns from Week 03).
4. Reference the FastAPI + Redis tutorial in this week's Resources for the connection pattern (redis.Redis(host="redis", port=6379)).
5. In the project root, write a docker-compose.yaml with three services:
  - app — builds from app/, exposes port 8000, depends on redis
  - redis — uses the official redis:latest image, includes a healthcheck (e.g., redis-cli ping)
  - trainer — a simple container (can reuse a lightweight Python image with a placeholder training script) that writes a dummy model file to a shared volume
6. Add a named volume (e.g., model-data) and mount it into both app and trainer at the same path (e.g., /models), so the app can theoretically read what the trainer writes.
7. Add an environment variable to app and trainer for MODEL_PATH=/models/model.bin so both containers agree on the file location without hardcoding it twice.
8. Change app's depends_on entry to the long form with condition: service_healthy, pointing at the redis healthcheck you wrote in step 5.
9. Run docker compose up --build and confirm all three containers start.
10. Verify service discovery: run docker compose exec app sh (or bash) to get a shell inside the app container, then run curl http://redis:6379 or use a small Python snippet to confirm the app container can reach Redis by name.
11. Verify volume sharing: from inside the trainer container, confirm the dummy model file exists at /models/model.bin; from inside app, confirm the same file is visible at the same path.
12. Kill the redis container mid-run (docker compose stop redis) and observe what happens to app — note whether Compose's healthcheck-based dependency prevented app from starting before Redis was ready in the first place, and write up what you observed.

Deliverables: Submit your docker-compose.yaml, the app/ and trainer/ folder contents (including Dockerfiles), and a short write-up (half a page) covering: (1) the terminal output proving service discovery worked, (2) what happened when Redis was stopped, and (3) one sentence explaining why depends_on alone would not have been sufficient without the healthcheck.