Final Project Brief - Docker Delivery Pack

Author & Course Lead — Badr Tajini · ESILV · 2026–2027

Course: DevOps Foundations with Docker: Containerization, Delivery, and Operations
Course ID: ESILV-DEVOPS-DOCKER
Academic year: 2026-2027
Working mode: Teams of at most two students
Assessment: team Delivery Pack 50%; TD01-TD05 evidence packs 40%; individual practical defense 10%

The labs become your project

TD1 establishes the runtime; TD2 builds the image; TD3 adds network and state; TD4 adds Compose operations; TD5 hardens it; TD6 adds CI, release and rollback. Integrate the same application rather than starting another one.

Defense: 30 November–4 December 2026, 8–10 minutes per student under the existing protocol. The appointment schedule and submission deadline will be announced separately.

Engineering problem

A small application currently runs as source code and an unmanaged database. Your team must turn it into a traceable, least-privilege, recoverable delivery system on your laptop or your own Ubuntu 24.04 server. A reviewer must be able to identify exactly which source revision produced the running image, replay the principal tests, inspect the operating evidence, restore persisted data, and return to the previous release after a failed deployment.

The default system is the supplied Flask/Gunicorn API, PostgreSQL database, and unprivileged Nginx proxy at the root of your private project repository. Application programming is not an assessment objective. An alternative application is allowed only with written instructor approval and only if it implements the same runtime, health, persistence, evidence, and rollback contract.

Learning outcomes assessed

• LO1: Explain the DevOps delivery flow and the image/container/registry mental model without treating Docker as synonymous with DevOps.
• LO2: Build and identify a reproducible OCI image using a versioned Dockerfile, non-root runtime user, Git SHA, and immutable digest.
• LO3: Prove runtime networking, storage, backup, restore, graceful stop, and rollback behavior.
• LO4: Operate and troubleshoot a multi-service Compose system using health, readiness, logs, inspection, and controlled failure injection.
• LO5: Apply and justify least-privilege and supply-chain controls, then report residual risk honestly.
• LO6: Implement a CI delivery path with an immutable release and produce a precise Kubernetes handoff.

Required system behavior

1. proxy is the only service published on the host. The safe default is 127.0.0.1:8080; remote access uses an SSH tunnel.
2. delivery-api listens privately on port 8000 and exposes /healthz, /readyz, and /version with their documented semantics.
3. postgres listens privately on port 5432 and stores data in a named volume.
4. The API runs as a non-zero UID, emits logs to stdout, reads secrets from a mounted secret file, and accepts graceful SIGTERM shutdown.
5. The Compose definition includes health-aware dependency ordering, bounded resources, least-privilege runtime controls, and no host Docker-socket mount.
6. A CI workflow tests, builds, scans, records an SBOM, publishes with a Git-SHA tag, captures the registry digest, and permits deployment only by digest.
7. Deployment runs smoke tests. Failure leaves or restores a known-good release. A manual rollback is independently replayable.
8. Backup and restore procedures are tested against a named, checksummed backup. docker compose down -v is not a recovery procedure.

Mandatory demonstrations

Your final demonstration must prove, rather than narrate, the following:

• clean build from the declared commit;
• image identity by registry digest and OCI labels;
• only the intended host port is reachable;
• liveness remains process-only while readiness fails when PostgreSQL is unavailable;
• a written record survives API-container recreation;
• the non-root/read-only/capability controls are active;
• vulnerability findings are triaged, not hidden;
• CI produces the immutable release;
• a deliberately unhealthy release is detected and rolled back;
• a backup can restore a record that was removed after the backup;
• every major claim points to versioned definition, test, evidence, timestamp, tool versions, and limitations.

Evidence rule

Every claim must contain:

1. a versioned definition reference;
2. a replayable positive or negative test reference;
3. runtime evidence with UTC capture time and tool versions;
4. an explicit result (PASS, FAIL, or BLOCKED);
5. limitations and residual risk;
6. rollback or recovery proof when state changes.

Screenshots without commands, timestamps, and claim references are supporting illustrations only. They are not primary evidence.

Differentiation

Guided, independent, and extension routes share the same core acceptance gates. Extension work is reviewed only after the core system is reproducible and safe. Adding more products does not compensate for a public database, missing rollback, unverifiable evidence, or an image running as root.

Suitable depth work includes a justified rootless comparison, registry build provenance, a narrower network policy, or a measured recovery improvement. Docker Swarm, Kubernetes deployment, service meshes, and unrelated monitoring stacks are outside this project.

Safety gates

The following require immediate containment and remediation before review:

• credentials, tokens, private keys, or real personal data in the repository;
• Docker API exposed without authenticated transport;
• privileged: true, host PID/network namespace, or a host-root bind mount;
• /var/run/docker.sock mounted into an application container;
• PostgreSQL published to a public interface;
• destructive cleanup with an unresolved or broad target;
• tests against any system outside the allocated course environment.

Remediation does not erase the incident. Record it in the risk register and postmortem with cause, impact, corrective action, and proof.

The teaching team applies the trusted static validator from the released instructor package before any submitted Dockerfile, Compose definition, or shell script is executed. Passing your repository's own validator or CI check does not replace that gate because those files remain under your control. Replay is performed on a disposable, credential-free course host; a static pass is permission to begin review, not evidence that the system is safe or correct.

Submission and defense

Submit one directory named final-docker-delivery-pack/ that satisfies FINAL_DOCKER_DELIVERY_PACK.md. Run the static validator before submission. The automated report determines readiness for human review; it does not assign the project grade.

The pack includes a root claims-index.md: one review row per claim linking the definition, structured test, primary evidence and checksum, result, recovery or rollback, and limitation. Its identifiers and paths must agree with the manifest and test cards.

Each team member completes an individual practical defense. The instructor may select any submitted claim and inject one bounded fault. The student must explain the definition, choose diagnostic evidence, recover safely, and state the remaining limitation without relying on a prepared script.

Scheduling dates and repository invitation details are issued through the official course channel. Do not hard-code private repository URLs or access tokens in the delivery pack.