Planning What Goes in a Container
Before installing anything, decide what you are going to containerise. quicknotes is a Python web app that will soon store its notes in PostgreSQL. Do you put both in one container? Where does the database password go? Where do the notes themselves live? A few minutes of planning here saves hours later.
The rule
One container, one concern: the app here, the database there.
A container is built around one main process. When it exits, the container stops. So each part of your system that runs, restarts, updates or scales on its own gets its own container:
- quicknotes web app → one container, from an image you build.
- PostgreSQL → a second container, from the official
postgresimage.
What goes inside an image depends on the language:
- Interpreted languages (Python, JavaScript, Ruby) need their runtime in the image:
python:3.12-slimsupplies the interpreter, then your libraries and code go on top. - Compiled languages (Go, Rust) can ship just the finished program, so their final images can be tiny.
What stays outside the image:
- Configuration and secrets, such as the database password or which host to connect to. Pass them in when the container starts, commonly as environment variables, so one image works in every environment.
- Data, such as the notes. Containers are meant to be replaced; data must live in storage that outlives them.
docker run -d --name notes -e DATABASE_HOST=notes-db quicknotes:1.0The same quicknotes:1.0 image can point at a test database or a production one, just by changing -e.
The shortcut
Split where things restart separately. For each part, ask: "Would I ever want to restart, upgrade or run more copies of this without touching the other?" If yes, it gets its own container.
List the running parts
A Python web server and a PostgreSQL database.
The classic mistake is building one big image with the app, the database and a process supervisor inside. Now one upgrade restarts everything, scaling the app duplicates the database, and logs are tangled.
Drills
Answer fast — trust the rule.
How many containers should the basic quicknotes system (web app plus PostgreSQL) use?
Why does the quicknotes image include a Python interpreter?
Where should the production database password go?
You want to run three copies of the quicknotes app against one shared database. Which design allows it?
Remember
- One container, one concern: the app here, the database there.
- Shortcut: split wherever parts restart, upgrade or scale separately.
- Trap: baking configuration, secrets or data into the image.