Deploy & Run Applications with Docker

4.1 Run a Docker container and watch it finish

A container is an isolated process that shares the host’s kernel but runs with its own filesystem and network stack, giving it the feel of a separate lightweight machine.

Start a container that prints a message and exits instantly

No Docker installed yet? Use https://labs.play-with-docker.com for a free, zero-install browser sandbox — same commands, no local setup. Otherwise this works once you've installed Docker for your OS (see the Windows / macOS / Linux chapters).

1. OPEN terminal and type docker run hello-world
2. WAIT for Docker to pull the hello‑world image if it is not already present locally
3. OBSERVE Docker CREATE a container from that image and RUN it
4. NOTE that the container prints its message and then EXITs automatically

• You'll see 'Hello from Docker!' appears in the terminal within a second or two, with no boot screen
• Takeaway Containers are isolated processes that share the host kernel, so they start as fast as any regular program
• Check If a container shares the host's kernel, what's actually different between a container and a normal program you'd just run directly?

4.2 Run two independent containers from one image and observe data loss without a volume

An image is a read‑only blueprint; a container is a running (or stopped) instance of that blueprint; a volume provides persistent storage that outlives the container’s disposable filesystem.

Do this first Run a Docker container and watch it finish

Create two separate containers from the same PostgreSQL image, delete one, and see that its file disappears because it was not stored in a volume

Three commands, three layers of the model.

1. LIST downloaded images with docker images to confirm the postgres:16 blueprint exists
2. START the first container using docker run -d --name box1 -e POSTGRES_PASSWORD=secret postgres:16
3. START the second container using docker run -d --name box2 -e POSTGRES_PASSWORD=secret postgres:16
4. SHOW both containers with docker ps -a, verifying they were created from the same image
5. CREATE a file inside box1 via docker exec box1 sh -c "echo test > /tmp/note.txt"
6. REMOVE box1 with docker rm -f box1 and note that /tmp/note.txt is no longer present
7. LIST existing volumes using docker volume ls, highlighting that no volume was used for the file

• You'll see Both box1 and box2 appear in docker ps -a, then the file you created inside box1 is gone after removing the container
• Takeaway Containers share an image but have isolated writable layers, so data persists only when placed in a Docker volume
• Check You just deleted a database container that had no volume attached. What actually happened to the data — and how would a volume have changed the outcome?

4.3 Verify a Docker stack is reproducible

A Dockerfile defines an exact base OS, runtime, dependencies and startup command; building it creates an immutable image that runs identically on any machine.

Do this first Run two independent containers from one image and observe data loss without a volume

Confirm that a docker‑compose file pins exact images and that those images guarantee identical environments across machines

Prints a content hash — proof the image is a fixed, addressable artifact, not a version number someone could silently republish differently.

1. OPEN the official docker‑compose.yml for n8n at its documentation site
2. OBSERVE that the file specifies exact tags for both the n8n and Postgres images
3. RUN docker inspect postgres:16 --format "{{.Id}}" in a terminal and note the hash displayed
4. COMPARE the printed ID with any other machine’s output to see they match exactly

• You'll see docker inspect prints a fixed image ID, proving the artefact does not change
• Takeaway Pinning images removes reliance on each developer’s local versions so the same stack runs everywhere
• Check Two people both run pip install from the same requirements.txt six months apart. Why might they get different environments — and why would the same Dockerfile always give them the same one?

4.4 Identify the role of each service in a docker‑compose file

Ollama, n8n, Open WebUI, AnythingLLM, Open Notebook — nearly every tool in this curriculum's local-and-private track ships a docker-compose.yml. That's not a coincidence: these tools bundle a specific Python or Node version, specific ML libraries, and sometimes a specific database (SurrealDB, Postgres) — exactly the kind of dependency tangle Docker exists to solve.

Do this first Verify a Docker stack is reproducible

Name the purpose of every service defined in example docker‑compose.yml files

Run inside any tool's folder that has a docker-compose.yml — prints the fully-resolved stack Docker is about to create, service by service.

1. Open Terminal and navigate to the folder containing the example docker‑compose.yml
2. Run docker compose config to display the resolved configuration for all services
3. Read each service block in the output and note its image, exposed ports and mounted volumes
4. Compare the listed services with the description of the tool (e.g., app service, database service) and state what each one provides

• You'll see docker compose config lists each service with its image, ports and volumes, showing the complete stack on one screen
• Takeaway Docker lets maintainers resolve complex dependencies once at build time so you only need a single command to run a fully configured environment
• Check Name one dependency problem Ollama's single-container setup avoids that you'd otherwise have to solve by hand.

4.5 Choose when to avoid Docker

Docker adds overhead only when there is a real dependency or reproducibility problem to solve; otherwise it is unnecessary extra complexity.

Do this first Identify the role of each service in a docker‑compose file

Decide, for a few concrete situations, whether Docker is actually worth reaching for.

Paste the command into the Terminal screen of the docker‑intro tool and press Enter. Watch the summary it prints – it will list each scenario and say YES if Docker is recommended or NO otherwise.

1. SKIP Docker for a single Python script you run yourself
2. SKIP Docker for a polished single‑purpose desktop app that already handles its own dependencies
3. USE Docker when a tool requires a specific database, runtime and configuration to work together
4. USE Docker when you need the same environment on multiple machines
5. USE Docker when you want to run several versions of the same service side by side

• You'll see A clear yes/no for each situation above, and a next step: your OS's Docker install chapter
• Takeaway Docker solves one specific problem — dependency reproducibility across environments and machines; if that problem doesn't exist yet, the overhead isn't worth it
• Check Your lab has one shared GPU server that five people SSH into to run different Python projects with conflicting dependency versions. Is this a "reach for Docker" situation? Why?