Skip to content

Using Containers for Development

Containers create lightweight, reproducible environments for building and testing code. They are especially useful when a project depends on specific toolchain versions or services.

FROM ubuntu:24.04
RUN apt update && apt install -y build-essential cmake git
WORKDIR /src
COPY . /src
RUN mkdir -p build && cd build && cmake .. && cmake --build .

Run a container and mount the source directory for iterative development:

Terminal window
docker build -t myproj:dev .
docker run --rm -it -v "$PWD":/src -w /src myproj:dev bash

Podman is a drop-in replacement for Docker on many systems and supports rootless containers by default. Use the same Dockerfile with podman build and podman run.

  1. Use container images as repeatable CI builders.
  2. Use volume mounts for fast edit/build cycles during development.
  3. Keep container images minimal and cache-friendly to speed builds.

This topic is an important part of building a reliable Linux development workflow. Understanding it clearly will make later tasks easier, because it reduces guesswork and helps you recognize when a step is missing or misapplied.

  • Try the commands or configuration shown here in a safe test environment.
  • Compare how the concepts apply across different distributions or tools.
  • Keep a short note of what worked and what failed so you can diagnose future problems faster.
  • Revisit the related article in the series to deepen the connections between topics.
  • Skipping verification steps and assuming the system is configured correctly.
  • Copying commands without adapting paths, package names, or tool versions for your environment.
  • Treating this topic as an isolated tip rather than part of a larger workflow.

When using containers for development, keep the container definition and the build commands under version control. A Dockerfile or Containerfile that is checked in with the project makes the environment reproducible for both your own future work and for collaborators.

Avoid mounting the entire host home directory into the container. Instead, mount only the project directory, and keep persistent state such as caches or tool configuration in a well-defined location.

  • Using a container image that is too large for everyday development. Start from a small base image and add only the packages you actually need.
  • Ignoring file permission issues when mounting volumes, especially when the container runs as a different user than the host.
  • Forgetting to rebuild the container after changing the Dockerfile; instead of docker run alone, use docker build again when the environment definition changes.

Containers isolate the build environment from the host system. This is helpful when you want to test the same workflow on machines with different installed toolchains, or when a dependency version mismatch would otherwise make the project non-reproducible.