10 — The Docker CLI: Containers and Networks in Day-to-Day Use

The Docker command surface felt like a wall of unrelated verbs until I noticed its grammar. The structure that surfaced: the Docker CLI is noun-verb — docker <noun> <verb> — and almost everything I do is docker container <verb> or docker network <verb>, with images and volumes following the same pattern. [1][3]

The framing worth holding onto is that the older single-word commands (docker run, docker ps, docker stop) and the newer grouped commands (docker container run, docker container ls, docker container stop) are the same operations [2]. Docker reorganized the CLI into management groups so that every object — container, image, volume, network — has a consistent verb set. Once I learned the noun-verb shape, the surface stopped feeling sprawling and started feeling small.

The grammar

That grammar is the whole shape of the surface. The same four verbs — ls, inspect, rm, and a domain-specific one (run for containers, build for images, create for volumes/networks) — appear for every object, so learning one noun teaches the pattern for the rest [1].

Container commands

Containers are the noun I touch most. The day-to-day set, in management-group form [2]:

docker container run -d --name api -p 8080:3000 my-app:1.0  # start one
docker container ls                                          # running containers
docker container ls -a                                       # include stopped
docker container logs -f api                                 # tail logs (follow)
docker container exec -it api sh                             # shell inside
docker container stop api                                    # graceful stop (SIGTERM)
docker container rm api                                      # remove stopped container
docker container inspect api                                 # full config as JSON

These all have short aliases — docker run, docker ps, docker exec — and in practice I type the short forms. But the grouped form is what makes the CLI teachable: every object behaves the same way, and docker container ls -a parallels docker volume ls and docker network ls exactly [1][2].

Two commands deserve special mention because they're where I spend most debugging time. docker logs -f <name> follows a container's stdout in real time — the single most useful debug tool, given a well-logging app. docker exec -it <name> sh drops me into a shell in the live container, where I can env, ls, curl localhost, and otherwise poke the running process without restarting it [1].

Network commands

Networks are the second noun I touch whenever more than one container is involved. By default, Docker gives every container a network — but the default bridge network isolates containers from each other's names, which is almost never what I want. The pattern I use is to create a named network and attach my services to it, so they can reach each other by container name [4][5]:

docker network create appnet
docker run -d --name db --network appnet postgres:16
docker run -d --name api --network appnet -e DATABASE_URL=postgres://db:5432/app my-app:1.0

On appnet, the api container can resolve the hostname db to the database container's IP — Docker runs an embedded DNS server for each user-defined network [4]. That's the whole magic behind the postgres://db:5432/... connection string in a Compose file: the service name resolves because they're on the same network.

Docker ships three network drivers worth knowing [4]:

• bridge — the default, a virtual network on the host. The user-defined bridge (what I create above) adds DNS resolution between containers; the default bridge does not.
• host — the container shares the host's network stack directly. No isolation, but maximum performance. Mainly useful on Linux.
• overlay — spans multiple Docker hosts (used with Swarm), so containers on different machines can talk as if on the same LAN.

The diagnostic verbs are the same as for containers: docker network ls lists them, docker network inspect appnet shows which containers are attached and what IPs they got, docker network connect appnet api attaches a running container to an additional network, and docker network rm appnet removes one [5].

The other two nouns

Images and volumes round out the surface, and they obey the same grammar. docker image ls, docker image rm, docker image pull; docker volume create, docker volume ls, docker volume rm. I won't expand on them — they're covered in the registries and persistence posts — but I mention them here because they're what completes the picture. Four nouns, same verbs, that's the CLI.

System-wide inspection

A few commands sit above the noun-verb structure and are worth knowing exist:

docker system df            # disk used by images, containers, volumes
docker system prune         # remove stopped containers, dangling images, unused networks
docker stats                # live CPU/mem/net per running container
docker info                 # daemon config, storage driver, counts

docker system prune is the one I run periodically on dev machines, where images and stopped containers accumulate into gigabytes of cruft. In production I'm more careful — prune removes anything not currently in use, which is rarely what I want a server to do to itself.

How I use this

The grammar is the habit. When I can't remember a command, I reconstruct it from docker <noun> <verb> — "list volumes? docker volume ls", "inspect this network? docker network inspect appnet" — and I'm right almost every time without looking it up. When debugging, my loop is docker container ls to find the container, docker logs -f <name> to read what it's complaining about, and docker exec -it <name> sh to poke it if the logs aren't enough. And when I'm wiring up a multi-container app, I reach for a named bridge network and service-name DNS — that single pattern replaces every fragile -p port-forward chain I used to build. The CLI's grammar is small; leaning on it is what keeps it small.

References

[1] Docker, Inc., "Use the Docker command line," Docker Docs, 2024. [Online]. Available: https://docs.docker.com/engine/reference/commandline/cli/

[2] Docker, Inc., "docker (base command) reference," Docker Docs, 2024. [Online]. Available: https://docs.docker.com/reference/cli/docker/

[3] Docker, Inc., "Docker CLI cheat sheet (PDF)," Docker Docs, 2024. [Online]. Available: https://docs.docker.com/get-started/docker_cheatsheet.pdf

[4] Docker, Inc., "Docker networking overview," Docker Docs, 2024. [Online]. Available: https://docs.docker.com/network/

[5] Docker, Inc., "docker network subcommands," Docker Docs, 2024. [Online]. Available: https://docs.docker.com/engine/reference/commandline/network/