TD4 — Operate the complete application with Compose

Step 1 — Turn the TD3 runtime into one Compose model · 45 minutes

Why: Compose records the three-service application in one versioned model. Inspect the architecture target and create your own compose.yaml and nginx/nginx.conf. The proxy alone publishes 127.0.0.1:8080; the API and PostgreSQL use private service communication, and the TD3 data and secret volumes remain attached. Keep the password value out of YAML and Git.

Before removing TD3 containers, inspect their course labels and confirm the named volumes belong to this project. Stop and remove only the old API and PostgreSQL containers, then the old TD3 network. Do not delete volumes. If a name or label differs, stop and ask for help rather than attaching unknown data.

mkdir -p evidence/TD04
docker volume ls
docker inspect delivery-api postgres --format '{{.Name}} {{json .Config.Labels}}'
docker network inspect td03-private --format '{{json .Labels}}'
docker compose -p docker-delivery config --quiet
docker compose -p docker-delivery config > evidence/TD04/resolved-compose.yaml

Check the resolved model: three services, one loopback host publication, and the two preserved named volumes. Use the setup page if you need to check which terminal runs Docker.

Step 2 — Validate, start and record known-good behavior · 35 minutes

Start the model using the API digest already recorded in your non-secret release.env. Save a versioned known-good definition before introducing the fault.

docker compose -p docker-delivery config --quiet
git add compose.yaml nginx/nginx.conf
git diff --cached --check
git commit -m 'td4: define Compose stack'
git rev-parse HEAD | tee evidence/TD04/known-good-sha.txt
docker compose -p docker-delivery up --detach --no-build --wait --wait-timeout 120
docker compose -p docker-delivery ps | tee evidence/TD04/ps-healthy.txt
curl --fail --silent --show-error http://127.0.0.1:8080/healthz
curl --fail --silent --show-error http://127.0.0.1:8080/readyz
curl --fail --silent --show-error http://127.0.0.1:8080/version

Check the API image identity with docker inspect, confirm the TD3 database marker is still present, and save bounded proxy/API logs. If baseline requests fail, diagnose them before the incident exercise. A running container alone does not prove readiness.

Step 3 — Reproduce and diagnose the supplied proxy incident · 45 minutes

Why: A 502 at the browser is a symptom. The first evidence should distinguish a proxy-to-API problem from an API or database failure. Ask your partner or Badr to introduce one reversible proxy-to-API connection error in your own working nginx/nginx.conf, without changing ports exposed on the host, credentials or data. They keep the cause private until your debrief. Save the known-good Git revision first. When working alone, use a genuine observed proxy failure; if none is available, mark the incident exercise pending rather than invent evidence. Keep the failed configuration and compare it with your known-good version during diagnosis.

docker compose -p docker-delivery up --detach --no-build --no-deps --force-recreate proxy
date -u +%FT%TZ | tee evidence/TD04/incident-start.txt
curl --silent --max-time 5 --output evidence/TD04/incident-body.txt --write-out '%{http_code}
' http://127.0.0.1:8080/healthz | tee evidence/TD04/incident-status.txt
docker compose -p docker-delivery ps --all | tee evidence/TD04/incident-ps.txt
docker compose -p docker-delivery logs --no-color --tail 80 proxy > evidence/TD04/incident-proxy-logs.txt 2>&1
docker compose -p docker-delivery logs --no-color --tail 40 delivery-api > evidence/TD04/incident-api-logs.txt 2>&1
git diff -- nginx/nginx.conf | tee evidence/TD04/proxy-diff.txt

Before any repair, check the API internally and check PostgreSQL readiness. Compare their results with the proxy request and log. Write down your hypothesis, evidence for it, and one alternative you ruled out. Keep the original failure outputs even after recovery.

Step 4 — Repair the smallest justified part and replay · 35 minutes

Use the saved proxy log, internal checks and config difference to decide which definition must change. Edit that file yourself, explain the line you changed, and recreate only the affected service. Keep API, database and named volumes in place.

docker compose -p docker-delivery config --quiet
docker compose -p docker-delivery up --detach --no-build --no-deps --force-recreate --wait --wait-timeout 120 proxy
curl --silent --show-error --max-time 5 --output evidence/TD04/repaired-body.json --write-out '%{http_code}
' http://127.0.0.1:8080/healthz | tee evidence/TD04/repaired-status.txt
curl --fail --silent --show-error http://127.0.0.1:8080/readyz | tee evidence/TD04/repaired-ready.json
curl --fail --silent --show-error http://127.0.0.1:8080/version | tee evidence/TD04/repaired-version.json
docker compose -p docker-delivery port proxy 8080 | tee evidence/TD04/proxy-port.txt

Run the supplied smoke check and your own persistence regression check. Implement the marked regression.sh task using TD3's saved item and replacement observations before claiming it passes. Confirm the same API digest, TD3 marker and loopback-only publication remain after repair. If replay fails, retain both before/after logs and inspect the proxy definition and network membership.

Step 5 — Explain the incident and finish the checkpoint · 20 minutes

Write evidence/TD04/OBSERVATIONS.md yourself. Include the first UTC observation, known-good definition SHA, API digest, failed request, internal API and database observations, competing hypotheses, the one cause supported by evidence, your smallest repair, the same request after repair, and what this exercise did not test. Reference your saved evidence filenames. Do not fill in an expected conclusion if your observed outputs disagree.

docker compose -p docker-delivery ps | tee evidence/TD04/ps-final.txt
git diff --check
test -s evidence/TD04/OBSERVATIONS.md

Next, keep this same application and its data for TD5.