Docker: Compose & Networking
Wire several containers together
One container is a program in a box. Several containers are a system, and a system has questions with exact answers: which files win at a mountpoint, which port a sibling dials, which of five places a variable is set actually reaches the process. This is those answers, drilled.
- Modules
- 5
- Drills
- 0
- Build steps
- 9
- Time
- ~4h
Walk out able to
Read any Compose file and say what it will do before you run it — then write one to a specification and prove every constraint held.
What you work on
Services and teardown
What `up` creates, and what `down` leaves behind.
Volumes against bind mounts
Which set of files wins at one mountpoint, and why.
Names, networks and walls
Reach a service by name; keep one unreachable.
Ports and configuration
Publish on purpose; know which value the process reads.
The pitch
What you practise, and what you leave with
A four-service stack built from a specification: one local-only door, a database nothing outside reaches, and data that survives a teardown.
You will practise
- What a project creates, and what a teardown keeps
- Which files win when a mount lands on a path
- Service names, networks and what they wall off
- Published ports, and which value a process reads
Afterwards you can
- Predict a mountpoint before you run it
- Read a port mapping in both directions
- Reach a service by name, on the right port
- Find which of five sources set a value
Modules
5 modules, 24 items
Lessons explain one idea. Drills repeat it until it sticks. Build steps make something that exists afterwards.
- 1
One file, one running stack
~48 minBring several services up from one file, and know what a teardown leaves on the disk.
- LessonWhy several containers need a file4 min
- LessonWhat `docker compose up` creates7 min
- LessonWhat a teardown keeps9 min
- LessonStarted is not the same as ready7 min
- LessonWait for the right thing8 min
- Build stepBring a two-service stack up8 min
- Build stepWatch the data vanish5 min
- 2
Volumes against bind mounts
~38 minPredict which files are visible at a mountpoint before anything runs.
- LessonWho owns the bytes at a mountpoint8 min
- LessonThe three rules at a mountpoint9 min
- Build stepGive the store somewhere to live8 min
- Build stepHide the data without deleting it6 min
- Build stepWatch a copy-up happen7 min
- 3
The network you did not configure
~42 minReach a service by name, and put a service where nothing outside can reach it.
- LessonReach a service by its name8 min
- LessonA network is a wall, not a label8 min
- Build stepDial one service from inside another12 min
- Build stepPut a wall between two services14 min
- 4
Publish a port on purpose
~31 minRead and write a port mapping in both directions, and know exactly what it binds.
- LessonWhich side of the colon is the host8 min
- LessonWhat a published port binds9 min
- Build stepPublish a port and prove which is which14 min
- 5
Configuration the process reads
~55 minFind which of five sources a value came from, then build the whole stack.
- LessonFive places one variable can be set8 min
- LessonWhat actually reaches the process9 min
- Build stepFind out which value actually won12 min
- LessonCompose a stack to a specification16 min
- LessonProve every constraint held10 min
A taste of the code
services:
web:
image: nginx:alpine
ports:
- "8080:80" # a door on your machine -> the port inside$ docker compose port web 80
0.0.0.0:8080
More in DevOps & cloud
Keep going
Nginx & Proxies
The config is right. The request went somewhere else.
Advanced~4h6 modules
Linux & Shell
The prompt stops being a place you guess.
Foundational~4h5 modules
Linux: Processes & Systems
Stop guessing why it did not come back.
Intermediate~4h6 modules
Bash Scripting
The line you keep is a different thing from the line you type.
Intermediate~5h5 modules
Know where every byte and every connection goes, before you run it.
The first item is free. ~4h of focused work, at your own pace.
Intermediate~4h5 modules