Your First Python Dockerfile Blueprint
A Dockerfile is a recipe for building a self-contained environment for your Python app. Use it to ensure your app runs identically everywhere, from your laptop to production. The common footgun is forgetting a .dockerignore file, which bloats your image.
Why it exists
To solve the "it works on my machine" problem. Python applications depend on specific interpreter versions, system libraries, and package versions. Managing these across different environments is complex and error-prone. A Dockerfile codifies the entire environment setup, making it repeatable and portable.
The mental model
A Dockerfile is a blueprint for an assembly line. Each instruction (FROM, COPY, RUN, CMD) is a station. The raw materials are your source code and a base OS image. The finished product is a Docker image: a self-contained, runnable package of your application and its entire environment.
How it works
Docker reads the Dockerfile top-to-bottom, creating a new "layer" for each instruction. It starts with a base image using FROM (e.g., python:3.11-slim). WORKDIR sets the current directory inside the container. COPY adds files from your machine. RUN executes commands, like installing dependencies with pip. Finally, CMD specifies the default command to execute when a container starts. Docker aggressively caches these layers. If your code changes but your requirements.txt does not, Docker reuses the dependency layer, making rebuilds much faster.
When to use it
Use a Dockerfile for nearly any Python application you plan to deploy, share, or run in isolation. It's standard for web services (FastAPI, Django), data processing jobs, and machine learning models. It guarantees consistency from local development to cloud deployment on services like Kubernetes or AWS ECS.
When not to use it
For simple, single-file scripts with no external dependencies that are only run locally, a Dockerfile might be overkill. It's also less common for libraries intended to be installed via pip into other projects, as the consuming project typically manages its own environment.
One canonical example
A common pattern for a FastAPI app is to optimize for caching. First, copy only the requirements file: COPY requirements.txt .. Then, install dependencies: RUN pip install --no-cache-dir -r requirements.txt. After that, copy the rest of your application source code: COPY . .. This ensures that changing your Python code doesn't force a time-consuming re-installation of all your packages on every build. The final line, CMD, would start the web server, like: CMD ["uvicorn", "main:app", "--host", "0.0.0.0"].
Interview question
What is the primary reason for copying requirements.txt and installing dependencies before copying the full application code in a Python Dockerfile?
- a.To allow for easier debugging of dependency-related issues by separating them from application code errors.
- b.To leverage Docker's layer caching, significantly speeding up subsequent image rebuilds when only the application code changes.Correct
- c.To ensure that the application's dependencies are always installed in a separate, isolated layer.
- d.To prevent potential security vulnerabilities by isolating the dependency installation process from the main application logic.
Why? this is the answer
The card explicitly states that Docker aggressively caches layers, and copying requirements.txt first allows Docker to reuse the dependency layer if only the application code changes, making rebuilds much faster. While other options might describe general benefits of good practices, they are not the primary reason for this specific ordering strategy as detailed in the card.
Just read this? Test yourself on what you have been reading.
Read the original → docs.docker.com
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on docker — each one lists the topics its interview covers.
See open roles