Docker Basic Commands

When you're new to Docker, the most common confusion isn't the concepts — it's "which command do I actually type for this." This post collects the most frequently used basic commands, each with its syntax and an example, for quick reference.

Before the commands themselves, one thing worth getting straight: images and containers are two different things. An image is a read-only template containing the filesystem and configuration a program needs to run; a container is a running instance of an image, with a writable layer added on top. One image can spawn multiple containers that don't interfere with each other. Nearly every command below operates on one of these two objects — some on images (pull, images, rmi), some on containers (run, ps, rm, kill, restart, start, exec). Keep the object straight and the commands are much easier to remember.

Also, the Docker daemon runs with root privileges by default, so regular users need sudo to run docker commands (or need to be added to the docker group), which is why most examples below include sudo.

Help

docker -h

When you forget a command or a flag, check the help first. You can also get help for a specific subcommand — docker run --help, for example, lists every option that subcommand supports.

Pulling an image

# Syntax: NAME is the image name, TAG is the version tag
sudo docker pull NAME[:TAG]

# Example: pull the latest tag of centos
sudo docker pull centos:latest

pull downloads an image from a registry (Docker Hub by default) to your local machine. If you omit the TAG, latest is pulled. Images are stored in layers, so during a pull you'll see per-layer download progress, and layers already present locally are reused rather than downloaded again.

Starting a container

# Syntax
sudo docker run [OPTIONS] IMAGE [COMMAND] [ARG...]

# Example: start an interactive container from an image (the original post wrote "contos"; it should be centos)
sudo docker run -t -i contos /bin/bash

What run actually does is two steps: it creates a new container from the image, then starts it. A few common flags:

1. -i: keep stdin open so you can type into the container;

2. -t: allocate a pseudo-terminal; combined with -i you get an interactive shell;

3. the /bin/bash after the image name is the command executed when the container starts — when that command exits, the container stops.

If the image isn't present locally, run automatically performs a pull first.

Listing images

List all local images:

# Syntax
sudo docker images [OPTIONS] [NAME]

# Example: only show centos-related images
sudo docker images centos

The output shows each image's repository name, tag, image ID, creation time, and size. The name or ID shown here is what you'll use later when removing an image.

Listing containers

See every container we've created:

# Syntax
docker ps [OPTIONS]

# Example: -a lists all containers, including stopped ones
sudo docker ps -a

Note that docker ps only shows running containers by default. A container that just exited won't appear in ps, which makes it easy to think it "disappeared" — add -a to see everything. Both the CONTAINER ID and NAMES columns can be used to identify a container in later commands.

Removing an image

Delete a downloaded image from the local machine:

# Syntax: you can delete several at once
sudo docker rmi IMAGE [IMAGE...]

# Example
sudo docker rmi centos:latest

If any container (even a stopped one) was created from the image, rmi will refuse with an error — you need to rm the related containers first.

Removing container instances

Remove one or more containers:

# Syntax
sudo docker rm [OPTIONS] CONTAINER [CONTAINER...]

Remove all containers:

# The original post wrote it as below; in practice the inner command needs $() or backticks for command substitution:
# sudo docker rm $(sudo docker ps -aq)
sudo docker rm sudo docker ps -aq

Here the -q in docker ps -aq means output container IDs only; passing those IDs as arguments to docker rm gives you batch deletion. A running container cannot be rm'd directly — stop it first, or add -f to force removal.

Stopping a running container

# Syntax
sudo docker kill [OPTIONS] CONTAINER [CONTAINNER...]

# Example: the first few characters of the container ID are enough, as long as they uniquely identify it
sudo docker kill 026e

By default kill sends SIGKILL to the container's main process, killing it immediately with no chance to clean up. If you want the program to exit gracefully, docker stop is the better choice — it sends SIGTERM first and only sends SIGKILL after a grace period.

Restarting a running container

# Syntax
sudo docker restart [OPTIONS] contains[CONTAINER]

# Example
sudo docker restart 026e

restart amounts to a stop followed by a start; data in the container's writable layer is preserved.

Starting a stopped container

# Syntax
sudo docker start [OPTIONS] CONTAINER [CONTAINER..]

# Example
sudo docker start 026e

Mind the difference between start and run: run creates a new container, while start just brings an existing, stopped container back up — every change you previously made inside it is still there.

Entering a container

docker exec -it <container name or ID> /bin/bash

exec starts an additional process inside a running container — here, another bash. It's more commonly used than attach: typing exit in a shell you entered via exec only ends that extra process and doesn't affect the container itself.

Pitfalls and caveats

1. Don't mix up image IDs and container IDs. rmi removes images, rm removes containers; pass the wrong kind of ID and you'll get a "no such object" error.

2. Stopped is not removed. A stopped container still holds its name and its writable layer on disk. A new container using the same name will fail to create — rm the old one first.

3. Prefer stop over kill. Unless the process is hung and unresponsive, give the application a chance to clean up after receiving SIGTERM.

4. Data inside a container is ephemeral. Once a container is rm'd, the data in its writable layer goes with it. Anything important should be mounted to the host via volumes.

Wrapping up

This set of commands covers Docker's minimal working loop: pull to get an image, run to start a container, images / ps to check state, start / stop (kill) / restart to control the lifecycle, exec to get inside a container for debugging, and finally rm / rmi to clean up containers and images. Keep the through-line in mind — images are templates, containers are instances — and the rest is just practice.