Engineering Toolkit, lesson 11
Containers and deploying
Package an API with Docker, keep secrets out, and read its logs.
"HTTP APIs with FastAPI" for the API being packaged, and "Pipes, variables and scripts" for environment variables.
Part 1. Why a container
The runs API works on your laptop. To run it on a server, the server needs the right Python, the right packages, the files, the start command, and none of the leftovers on your machine that you've forgotten it depends on. A container image packs all of that into one thing that runs the same everywhere Docker does.
Example 1.1
From a folder to a running container
- Dockerfile+your files
A Dockerfile is a recipe: start from a base image, copy files in, install packages, name the start command.
- docker build→image
Building runs the recipe and saves the result: a read-only filesystem plus the command to start.
- docker run→container
Running an image starts a container: a process that sees only the image's files, with its own network address.
- the same image→laptopservera teammate's machine
Push the image to a registry, and any machine with Docker runs exactly the same thing.
Your turn
The image starts FROM python:3.12-slim. Your laptop has Python 3.14. Which Python runs inside the container?
Image
A packaged, read-only filesystem (an operating system's basic files, Python, your packages and code) plus the command to start. Built from a Dockerfile, stored in a registry.
Container
A running instance of an image: a process that sees only the image's files and gets its own network. Delete it and anything it wrote is gone; the image is unchanged.
Part 2. A Dockerfile, line by line
Keep going with Pro
You've done the first part. Pro opens the rest of this lesson, and every other one.
- A Dockerfile, line by line
- Settings and secrets come from outside
- Deploying, and reading the logs
Engineering Toolkit overviewSpotted a mistake? Tell us.