Docker Fundamentals

Docker is a platform for building, shipping, and running applications in containers. It packages software with its dependencies into images, distributes them through registries, and executes them in isolated environments that behave consistently from a developer's laptop to production servers.

itVirtualization, containers, and orchestration

Don't Panic — Docker Fundamentals

Docker is a way to carry an application with the files and defaults it expects, then run that package as an isolated process. Before this arrangement, moving software often meant reconstructing an environment by hand and hoping the right library had not wandered off while nobody was looking. Docker makes the package explicit. The hope is still optional, but far less central.

The useful pair is image and container. An image is the read-only package: application files, runtime dependencies, and a default command. A container is one running instance with a writable layer and its own run-time settings. The image stays put while containers start, stop, and disappear. This is why a container is meant to be replaced instead of carefully nursed back to health like a houseplant with a pager.

The recipe is a Dockerfile, a text file that says how to build the image. Its instructions create layers, which Docker can reuse when their inputs did not change. Put stable dependency work before frequently changing application files when the build permits it. Otherwise each source edit sends the builder back to the beginning, where it will wait politely and consume your afternoon.

What changes between environments does not belong in that recipe. A container receives environment variables, arguments, mounts, network connections, published ports, and resource limits when it is created. That split is the whole trick: stable dependencies in the image; environment-specific state at run time. Credentials do not belong in image layers, even briefly. Images travel, and their history has a surprisingly good memory.

Data has the same inconvenient habit of outliving its container. A volume is Docker-managed persistent storage; use it when data must survive replacement. A bind mount connects a chosen host path to the container, which is useful for local source-code work but couples the result to that particular host. A writable container layer is for disposable state. If important data lives there, its disappearance is not a mystery. It is a scheduled feature.

Networking offers its own small trap. A process can listen inside its container without being reachable from outside the Docker host. Publishing a port creates the host-to-container forwarding rule; EXPOSE only records an intention. Keep published ports narrow, because the default host binding may reach farther than the laptop in front of you.

Read the Intro for the full architecture and the line between Docker and an orchestrator. Use the Cheatsheet when you need the object map, lifecycle, storage choices, and failure boundaries. The Practice Reference turns the sequence into commands, and the Exercise lets you build, run, inspect, replace, and remove one harmless local container. After that, Compose is the place to group several related services, networks, and volumes without pretending that one host became a fleet.

Don't Panic — Docker Fundamentals

Relevant careers