Docker Fundamentals

Software that runs on one machine often breaks on another because of differing OS versions, libraries, and runtimes (the "works on my machine" problem). We need a way to package an app with everything it depends on so it runs identically everywhere.

Solution: Package an app with its dependencies into a portable image and run it as an isolated container, so it behaves the same on every machine.

Before standardized shipping containers, dockworkers loaded loose cargo by hand: barrels, sacks, and crates of every shape, each needing custom handling and breaking in transit. The steel container changed everything, one fixed box that any crane, truck, or ship can carry the same way, sealed at the factory and opened at the destination unchanged. A Docker image is that sealed box for software: your app plus every dependency, packed once and run identically on any machine. The running box is a container. This is literally why Kubernetes calls its boxes "containers."

"It works on my machine" problem. A container packages app + dependencies + runtime into one portable unit that runs the same everywhere.

VMs virtualize the hardware and run a full guest OS each; containers virtualize the OS and share the host kernel, so they are far lighter.

The Docker workflow is a pipeline: a Dockerfile builds an image, and an image runs as a container.

• Image: read-only template (layers).
• Container: a running, writable instance of an image.
• Registry: stores/serves images (Docker Hub, ECR, GHCR...).

Docker is client-server: the docker CLI sends commands over a REST API to the daemon, which does the real work.

These are the everyday commands for pulling, running, inspecting, and cleaning up containers.

docker pull nginx                 # download image
docker images                     # list local images
docker run -d --name web -p 8080:80 nginx   # run detached, map ports
docker ps                         # running containers
docker ps -a                      # all (incl. stopped)
docker exec -it web bash          # shell into container
docker logs web                   # view logs
docker stop web && docker rm web  # stop + remove
docker rmi nginx                  # remove image

Port mapping publishes a container's internal port to a port on the host so you can reach the app from outside.

Each Dockerfile instruction = a cached layer. Reused across builds = fast.

From recipe to a reachable container: build the image, run it, pulling from a registry if needed, then map the port to the host.

• Containers share the host kernel -> lightweight, fast to start.
• Image = build-time artifact; Container = run-time instance.
• -d detached, -p host:container ports, -it interactive shell.

• [ ] Ran an nginx container and hit it on localhost
• [ ] Used exec, logs, ps, stop, rm
• [ ] Understand image vs container vs registry