All capabilities · Cloud, deployment & production

Containerize an application with Docker

Write Dockerfiles, compose services, manage env/secrets, publish images.

~9 focused hoursbeginner
Explore 2 tools for this project
Market relevance

Which roles ask for this — and how often

Share of job postings in India, per role, that name this capability.

What employers mean

You should be able to…

  1. Write a Dockerfile for a Python API with a small final image (multi-stage build)
  2. Manage secrets/env vars for a container without baking them into the image
  3. Use docker compose to run an API plus its database/cache locally
  4. Debug a container that starts but the app inside crashes or can't reach a dependency
  5. Publish an image to a registry (Docker Hub/GHCR) with a versioned tag
  6. Reduce image size and build time with layer caching and .dockerignore
  7. Run a container as a non-root user for security

Needs first: Build and consume REST APIs

Learn — free, link-checked

The few resources that matter

Tools for practice

Choose a tool for the job

Start with one tool for each part of your project. You don’t need to learn them all.

Go to the practice brief

2 tools to explore

Docker

Deploy · Build

Package a service with its dependencies and run a repeatable local environment.

GitHub Actions

Test · Deploy

Run checks and deployment steps automatically when project code changes.

Practices & references

  • Dockerfiles
  • Compose
  • .dockerignore
Practice

Multi-stage container and Compose stack for the ticket API

Containerize the FastAPI ticket service with a multi-stage Dockerfile: build deps in one stage, ship a slim runtime image in the next, and run the process as a non-root user. Then write a docker-compose.yml that brings the API up alongside Postgres and Redis with all config coming from env vars. Finish by tagging the image, pushing it to GitHub Container Registry, and pulling it back on a clean machine to prove it runs anywhere.

Start from

The FastAPI ticket API you built in build-apis — any small web service with a database dependency works

Milestones
  1. Write a working single-stage Dockerfile and record the image size · ~0.5h
  2. Split it multi-stage on a slim base and switch to a non-root user · ~2h
  3. Add docker-compose with Postgres and Redis, wired entirely by env vars · ~1h
  4. Tag and push to GHCR, then pull it fresh and prove it starts · ~1h
Done when
  • Multi-stage Dockerfile produces a final image under 300MB and runs as a non-root user
  • `docker compose up` starts API + Postgres + Redis and the API can reach both
  • Secrets (DB password, API keys) are passed via env vars/`.env`, never hardcoded in the image
  • Image is pushed to a public registry with a semver tag and pullable by anyone
Prove it

Evidence a recruiter can check

  • The image-size drop before and after multi-stage, straight from `docker images` output in the README
  • A `docker compose up` log showing the API connecting to both Postgres and Redis from a clean start
  • The GHCR package page with semver tags anyone can `docker pull` without credentials
  • `whoami` from inside the running container, next to the Dockerfile line that made it non-root
Signal it

Containerized a FastAPI service with a multi-stage build — cut the image to under 300MB, ran it as a non-root user, and published semver-tagged images to GHCR alongside a Compose stack with Postgres and Redis.

Interview

Questions you'll get asked

  1. Walk me through a multi-stage Dockerfile for a Python FastAPI app.
  2. How do you pass secrets to a container without committing them to the image?
  3. Your container works locally but crashes in prod — how do you debug it?
  4. What's the difference between `CMD` and `ENTRYPOINT`?
  5. How would you use docker compose to run an API with a Postgres and Redis dependency?
  6. Why would you run a container as a non-root user, and how do you set that up?
  7. How do you keep a Python image small without breaking pip installs that need build tools?