How do you build a Docker image?
To build a Docker image, you use the docker build command with a Dockerfile, specifying the build context and optionally a tag for the resulting image.
Building a Docker image is the process of creating a portable, runnable snapshot of your application and its environment using instructions defined in a Dockerfile. The primary command is docker build, which reads the Dockerfile and executes its instructions sequentially, committing each step as a new layer in the final image. The build process requires a build context—the set of files available to the Docker daemon during the build, typically specified as the current directory ..
The -t or --tag flag assigns a name and optionally a tag to the image. Without this flag, the image receives only a unique ID, making it harder to reference later. Tags follow the format name:tag, where name can include a registry hostname and repository, and tag defaults to latest if omitted. Common tagging conventions include semantic versions (v1.2.3), Git commit SHAs (a47b2c9), or environment indicators (production).
The build context is critical—everything in the specified path (including subdirectories) is sent to the Docker daemon. For efficiency and security, include a .dockerignore file to exclude unnecessary files like node_modules, .git, or temporary files. Each instruction in the Dockerfile (FROM, RUN, COPY, etc.) creates a new layer that can be cached. Docker intelligently reuses cached layers when the instruction and its context haven't changed, dramatically speeding up subsequent builds.
- 1
--no-cache: Disables layer caching, forcing a complete rebuild of all layers. Useful when you suspect cache issues or need to ensure fresh dependencies. - 2
--build-arg: Passes build-time variables to the Dockerfile using ARG instructions, enabling dynamic configuration like version numbers or environment settings. - 3
--target: In multi-stage builds, stops at the specified stage instead of building all stages. This is useful for creating development vs production images. - 4
--pull: Always attempts to pull a newer version of the base image, ensuring you're building against the latest security patches. - 5
--platform: For multi-architecture builds, specifies the target platform (e.g., linux/amd64, linux/arm64).
Scenario Questions
- 1
We need to containerize a simple Python script. Walk me through the Dockerfile you'd write and the command you'd run to build the image.
- 2
If you accidentally include a large data directory in the build context, what will happen to the image size and build time, and how would you prevent it?
- 1
Your team added a new environment variable to the app, but after rebuilding the image the container still uses the old value. What could cause this and how would you debug it?
- 2
We want to reduce the size of our Node.js image for production. Which Dockerfile optimizations would you consider, and what trade‑offs do they involve?
- 1
Our CI pipeline builds Docker images for multiple services in parallel, but we see frequent cache misses causing long build times. How would you redesign the Dockerfile or build process to improve cache utilization?
- 2
We need to support both ARM and x86 architectures for the same image. Explain how you'd set up the build and what challenges you might face.
- 1
The organization is moving from a monolithic Docker image to a set of microservice images with shared base layers. How would you design a base image strategy to maximize layer reuse across teams while maintaining security compliance?
- 2
We have legacy images built with outdated base OS versions. Describe a migration plan to update the base images across hundreds of services without breaking deployments, including testing and rollout considerations.
Follow-up Questions
- ❓What would you include in a .dockerignore file and why?
- ❓How does Docker's layer caching affect rebuild times when you modify a later line in the Dockerfile?
- ❓Can you walk me through how you would verify that the final image contains only the intended artifacts?