✦ For everyone, free.

Practical knowledge for real and everyday life

Home

19.2.1.1 Run Container Creation

A focused guide to Run Container Creation, connecting core concepts with practical Docker and container operations.

Container creation is the internal process that docker run executes before starting a container. It transforms an image — a static, read-only collection of layered filesystems — into a running instance with its own writable filesystem, isolated process space, network interface, and resource boundaries. Understanding what happens during creation clarifies why containers start in microseconds and why each container is independent despite sharing the same underlying image.

What Gets Created

When Docker creates a container, it allocates and configures several components:

Writable Container Layer

Every container gets its own thin, writable layer added on top of the image's read-only layers. This is called the container layer or the copy-on-write layer. Any file modifications, new files, or deletions made inside the container are stored in this layer. The underlying image layers remain unchanged, which means:

  • Multiple containers running the same image do not duplicate the image data.
  • Stopping and removing a container discards only its writable layer.
  • The image can be reused to create new containers instantly.
Container Layer (R/W) App Layer (R/O) Runtime Layer (R/O) Base OS Layer (R/O) Container Image Layers
Network Namespace

Docker creates a dedicated network namespace for the container. This namespace gets its own virtual network interface (typically eth0), an IP address assigned from the container network's subnet, and its own routing table. The container cannot see the host's network interfaces directly (unless --network host is specified).

PID Namespace

The container gets an isolated process ID namespace. The container's first process always has PID 1 inside the namespace, regardless of its actual PID on the host. This isolation prevents containers from seeing each other's processes and prevents a process inside the container from signaling host processes.

Mount Namespace

Filesystems are isolated through a separate mount namespace. The container sees its own root filesystem assembled from the image layers, plus any bind mounts or volumes specified at run time.

Control Groups (cgroups)

Docker assigns the container to a cgroup hierarchy, which enforces resource limits (CPU, memory, I/O). If --memory or --cpus was specified in the docker run command, these limits are applied at the cgroup level during creation.

Creation Steps in Order

When docker run is executed, the Docker daemon performs these steps in sequence:

  1. Image resolution: Check if the image is available locally. Pull it from the registry if not.
  2. Container metadata creation: Allocate a unique container ID (a 64-character hex string). Create metadata in the Docker state directory.
  3. Filesystem setup: Create a union filesystem that stacks the image layers with a new empty writable layer on top.
  4. Namespace allocation: Create the network, PID, IPC, UTS, and mount namespaces.
  5. Network configuration: Assign an IP address, set up virtual Ethernet pairs, and connect to the requested network.
  6. Volume mounting: Mount any specified bind mounts or named volumes into the appropriate paths inside the container filesystem.
  7. cgroup setup: Create cgroup entries and apply resource limits.
  8. Environment and configuration: Set the working directory, user, hostname, environment variables, and labels as specified.
  9. Process start: Fork and exec the specified command (or the image's default CMD/ENTRYPOINT) inside the new namespaces.

Verifying Container Creation

After docker run, the container appears in the container list:

docker ps

CONTAINER ID   IMAGE          COMMAND             CREATED         STATUS         PORTS     NAMES
3a4b5c6d7e8f   nginx:latest   "/docker-entrypo…"   5 seconds ago   Up 4 seconds   80/tcp    web-server

For a stopped container created with docker create:

docker ps -a

CONTAINER ID   IMAGE          COMMAND     CREATED        STATUS    PORTS   NAMES
8f7e6d5c4b3a   ubuntu:22.04   "bash"      10 seconds ago   Created           staging-box

Inspecting the Created Container

The full configuration of a container can be examined immediately after creation:

docker inspect web-server

Key fields in the output:

  • Id: Full 64-character container ID
  • Created: ISO 8601 timestamp of creation
  • Path and Args: The command being executed
  • State: Current lifecycle state
  • Image: The image ID the container was created from
  • Mounts: All volume and bind mount configurations
  • NetworkSettings: IP address, gateway, MAC address
  • HostConfig: Resource limits and restart policy

Isolation at Creation Time

The isolation guarantees established during creation persist for the container's entire lifetime. A container cannot escalate its own privileges beyond what was set during docker run. Memory limits cannot be exceeded without being killed by the OOM killer. The network namespace boundary does not change unless the container is explicitly connected to another network.

This means that everything relevant to security and resource management is determined when docker run executes — not later, when the container is already running. Understanding creation as the moment of configuration makes it easier to reason about what a container can and cannot do once it is running.

Container ID vs. Container Name

Every created container has both a randomly generated 64-character ID and a human-readable name. Both can be used interchangeably in all subsequent commands:

docker stop web-server          # by name
docker stop 3a4b5c6d7e8f        # by full ID
docker stop 3a4b5c6d            # by short ID (unambiguous prefix)

If no --name was provided to docker run, Docker generates a name by combining a random adjective with a random scientist's name (e.g., tender_lovelace, happy_curie).

Related content