Containers, images, networking, and storage
Pull an image, then run a container.
Follow commands through the Docker client, host, and registry.
The daemon handles client requests and retrieves images from a registry.
An image provides read-only filesystem content and configuration. Multiple containers can be created from the same image.
Use it to distinguish pull, build, and run and locate image storage and command execution.
A Docker image consists of read-only layers created by filesystem-changing build instructions.
Explore image layers, build caching, and multi-stage builds.
Reuse unchanged build steps and include only runtime files in the final image.
Copy dependency manifests before source for cache reuse. Separate build tools from runtime files. Displayed sizes and times are examples.
Use it to understand Dockerfile ordering, cache invalidation, and image-size reduction.
A virtual machine runs a guest operating system and applications on a hypervisor.
Containers share the host kernel and package the application with its required libraries.
Compare how virtual machines and containers use operating systems and kernels.
VMs run separate guest operating systems; containers share the host kernel.
Containers avoid guest-OS boot overhead but share the kernel. Namespaces and cgroups isolate and control resources. Containers can also run within VMs.
Use it to compare isolation, startup costs, resource use, and OS compatibility.
Follow how Docker commands create, start, pause, stop, and remove a container.
Follow creation, startup, pausing, stopping, and removal of a container.
Stopping ends the process; removal also deletes the writable layer.
Run combines creation and startup. Stop signals termination and can force it after a timeout. Restarting the same stopped container preserves its writable layer.
Use it to interpret states, distinguish stopping from removal, and choose persistent storage.
Without a volume, database files are stored in the container writable layer.
Volumes and bind mounts connect external storage to a directory inside the container.
Compare data lifetimes in writable layers, volumes, and bind mounts.
Store files outside the container when they must survive its replacement.
Docker manages named-volume locations; bind mounts use specified host paths. External storage can be managed separately from containers.
Use it for database persistence, uploads, and development source sharing.
Three containers join the user-defined app-net network, each with its own IP address.
Explore name-based Docker networking and published ports.
Containers on a user-defined network connect by name; external access uses published host ports.
Port mappings forward host traffic to a container port. Separate bridge networks isolate traffic by default and require explicit communication settings.
Use it to design container connections and distinguish internal ports from externally reachable endpoints.
A registry stores image manifests and layers. Each manifest identifies its layers by digest.
Follow image upload to a registry and download to a deployment server.
Read a manifest and transfer only missing layers.
Content digests identify layers. Tags can change their target, while a digest identifies specific content.
Use it to understand image distribution, tags versus digests, and transfer reuse.
Running containers with separate commands also requires managing their networks and volumes individually.
Define and run services, networks, and volumes together in a Compose file.
Save repeatable configurations and connect containers by service name.
Startup ordering differs from readiness. Health checks and readiness conditions can delay dependent startup until a service accepts connections.
Use it to manage multi-container application environments.