Docker Fundamentals

After this lesson, you will be able to: Use docker run, ps, logs, exec, stop, rm and rmi confidently. Understand the difference between an image and a container.

Image is the blueprint; container is the running instance. Master the daily-driver commands first; the rest of the sub-track builds on them.

Prerequisites:What Containers Are

Run, list, stop, remove

The eight commands you'll type most often.

tsx

docker run hello-world                # download + run image
docker run -d nginx                   # detached (background)
docker run -d -p 8080:80 nginx        # publish host:8080 -> container:80
docker run -it ubuntu bash            # interactive (use for exploring images)
docker run --rm -it alpine sh         # --rm removes the container after it exits
docker run -d --name web nginx        # give it a name (instead of random)

docker ps                             # running containers
docker ps -a                          # ALL containers (including stopped)
docker logs web                       # show the container's stdout/stderr
docker logs -f web                    # follow
docker exec -it web bash              # shell into a running container

docker stop web                       # graceful stop (SIGTERM, then SIGKILL after 10s)
docker rm web                         # remove a stopped container
docker rm -f web                      # stop + remove in one
docker rmi nginx                      # remove an image

Image vs container (the key mental model)

Image = immutable bundle of filesystem layers + metadata (entrypoint, env, ports). Like a class. Container = running instance of an image. Like an object. You can spawn many containers from one image. Each gets its own writable layer on top of the image's read-only layers. `docker images` lists images; `docker ps` lists containers. Don't conflate the two.

Environment, ports, mounts: the run flags that matter

These let you configure a container without rebuilding the image.

tsx

# Environment variables
docker run -e DATABASE_URL='postgres://...' -e LOG_LEVEL=debug myapp
docker run --env-file .env myapp

# Port mapping (host:container)
docker run -p 3000:3000 myapp
docker run -p 127.0.0.1:3000:3000 myapp    # bind only to localhost

# Mount a host directory into the container
docker run -v $PWD:/app -w /app node:20 npm test
# -v   bind mount (host_path:container_path)
# -w   set working directory inside container

# Named volume (managed by Docker)
docker volume create pgdata
docker run -v pgdata:/var/lib/postgresql/data postgres

Inspecting containers

`docker inspect <name>` dumps full JSON about a container (IP, mounts, env, networks). `docker stats` shows live CPU/RAM/IO per container, like `top` for containers. `docker top <name>` lists processes inside a container. `docker diff <name>` shows what changed in the container's filesystem vs the image.

Common mistakes only experienced engineers avoid

Running containers without `--rm` in dev; you end up with hundreds of stopped containers polluting `docker ps -a`. Forgetting `-p`. The container is running but you can't reach its port from the host. `docker exec` to 'fix' a misconfigured container instead of rebuilding. Cattle, not pets. Filling the disk with old images. `docker system prune` is your friend (asks before deleting). Mounting host paths into containers that run as root. The container can chown/chmod your host files.

Quick Check

Your container starts and exits immediately. `docker logs` shows nothing useful. What do you check first?

Pick the highest-leverage diagnostic.

←What Containers Are and Why

Back to Docker and Containerization

Writing Dockerfiles→