1.1.1.4 CLI Command Role

The command-line interface's role within Docker is to be the primary point of human interaction with the engine: a single docker binary that translates short, memorable subcommands into REST API calls against the daemon, so that building, running, and managing containers can be done through ordinary terminal commands rather than direct API calls.

Structure of the CLI

The Docker CLI follows a consistent docker <command> [options] [arguments] structure. Most subcommands map directly onto a stage of the container lifecycle:

docker build -t myapp:1.0 .
docker run -d --name myapp -p 8080:80 myapp:1.0
docker ps
docker logs myapp
docker stop myapp
docker rm myapp

This sequence — build, run, inspect, stop, remove — covers the vast majority of everyday interaction with Docker, and the predictability of this pattern is part of what made Docker approachable to developers who had no prior experience with containers or with Linux kernel internals.

Inspecting and Managing State

Beyond starting and stopping containers, the CLI exposes commands for inspecting the state of images, containers, networks, and volumes, which is essential for debugging and operational visibility:

docker images
docker inspect myapp
docker network ls
docker volume ls
docker system df

docker inspect in particular returns a detailed JSON description of a container or image's configuration, which is often the starting point for diagnosing why a container is misbehaving.

Interactive Access

The CLI also provides a way to reach inside a running container, which is useful both for debugging and for one-off administrative tasks:

docker exec -it myapp /bin/sh

This opens an interactive shell session inside the container's own namespace, letting a developer inspect files, check running processes, or run diagnostic tools exactly as they would appear from within the container.

Composing Multiple Containers

For applications made of several services, the docker compose subcommand extends the CLI to operate on a whole stack defined in a YAML file rather than one container at a time:

docker compose up -d
docker compose ps
docker compose down

This keeps the same command-driven philosophy — short, declarative subcommands — even as the unit being managed grows from a single container to an entire multi-service application.

Why the CLI's Role Matters

The CLI's role is best understood as a deliberate simplification layer: it hides the REST API, the daemon's internal state management, and the underlying containerd/runc machinery behind a small, consistent vocabulary of commands. This is what allowed Docker to be adopted so widely without requiring every developer to understand container internals — the CLI made containerization something that could be learned through a handful of commands and built upon incrementally, rather than something that required deep systems programming knowledge from the outset.