Docker

01 Introduction

Lesson 13.3 presented the containers' concept and their mechanisms: the namespaces (the isolated's views), the cgroups (the limited's usage), the union file systems (the packaged's file system), the capabilities, the seccomp, the LSM, and the user's namespace, and the OCI standards (the Runtime's Specification, the Image's Specification, the Distribution's Specification) and the runtimes (the runc, the crun, the containerd, the CRI-O). This lesson presents Docker: the platform that made the containers the accessible to the developers, and that created the ecosystem that the modern's applications' development and deployment depend on.

Docker is the open-source's platform (the Docker Inc.'s, the 2013's release) for the containers' building, the sharing, and the running. The Docker's design's central's observation: the containers' kernel's mechanisms (the namespaces, the cgroups, the union file systems) existed for the years before the Docker, and the Docker's contribution was the user experience:

• The images. The Docker's image is the packaged's file system: the application and its dependencies in the single's artifact. The image's design: the layers (the base's image, the dependencies, the application), the metadata (the configuration, the environment's variables, the entrypoint, the command), and the digest (the content-addressable's identifier). The image's purpose: the application's dependencies' packaging (the "it works on my machine" problem's solution).
• The Dockerfile. The Dockerfile is the declarative's format for the image's construction: the sequence of the instructions (the FROM, the RUN, the COPY, the CMD, the ENTRYPOINT, the ENV, the EXPOSE, the USER, the WORKDIR, the VOLUME, the LABEL, the ARG, the HEALTHCHECK, the SHELL, the STOPSIGNAL, the ONBUILD), and the Docker's builder executes the instructions to produce the image. The Dockerfile's purpose: the image's reproducible's construction (the same's Dockerfile produces the same's image).
• The registries. The Docker's registries are the images' repositories: the Docker Hub (the public's), the private's registries (the Harbor, the Nexus, the Artifactory), the cloud's providers' registries (the AWS's ECR, the Azure's ACR, the Google's Artifact Registry, the GitHub's Container Registry, the GitLab's Container Registry). The registries' purpose: the images' distribution (the docker pull's and the docker push's commands), the images' versioning (the tags and the digests), and the images' sharing (the docker.io/library/ubuntu's and the enterprises' private's images).
• The Docker's CLI and the API. The Docker's CLI (the docker's command) and the API (the REST's API: the /containers's, the /images's, the /networks's, the /volumes's, the /exec's endpoints) are the user's and the tools' interfaces. The Docker's CLI's design: the verbs (the build, the run, the pull, the push, the ps, the exec, the logs, the inspect, the stop, the rm, the rmi) and the options (the resource's limits, the network's configuration, the volumes, the environment's variables, the ports, the security's options).
• The Docker's ecosystem. The Docker's ecosystem: the Docker Compose (the multi-container's applications), the Docker Swarm (the native's orchestration), the Docker Desktop (the developer's environments), the Docker Hub (the public's registry), the BuildKit (the modern's builder), and the plugins (the storage's, the network's, the logging's, the security's).

The Docker's role in the containers' adoption: the Docker's release (the 2013's) was the containers' explosion's driver. The containers' kernel's mechanisms (the namespaces, the cgroups, the union file systems) existed for the years (the LXC's release was the 2008's), but the Docker's user experience — the simple's CLI, the images' concept, the Dockerfile's format, the Docker Hub's registry, the single's process's container's model — made the containers the accessible to the ordinary's developers. The observation is the reason the Docker's name is the container's synonym, and the observation is the reason the lesson's focus is the Docker's user experience (the images, the Dockerfile, the CLI) more than the kernel's mechanisms (the Lesson 13.3's focus).

This lesson presents Docker. It defines the Docker's platform and its components. It presents the Docker's objects (the images, the containers, the networks, the volumes, the plugins). It presents the Dockerfile's directives, the layers, the build cache, and the multi-stage's builds. It presents the Docker's images (the tags, the digests, the registries), the Docker's containers (the lifecycle, the networking, the storage, the configuration), the Docker Compose (the multi-container's applications), the Docker's security (the considerations, the best practices), and the Docker's ecosystem (the BuildKit, the Buildx, the Swarm, the plugins). It closes with the Docker's design's trade-offs and the lesson's synthesis.

02 Learning objectives

This lesson contributes to U13.4 and U13.5, and to course learning outcomes CLO1, CLO7, and CLO8.

03 Required reading

• Operating System Concepts — Chapter 18, Virtual Machines, the sections on the containers and the operating-system-level virtualization. The standard treatment of the containers' concept, the container's and the VM's comparison, and the containers' mechanisms that Docker builds on.
• OSTEP — the Virtualization chapters, particularly the discussion of the containers and the namespaces. OSTEP's treatment of the containers' mechanisms is the clearest available account of the layers that Docker builds on, and it is the basis for the worked example in this lesson.
• Tanenbaum & Bos — Modern Operating Systems, Chapter 7, Virtualization and the Cloud. A complementary treatment of the containers' mechanisms and the operating-system-level virtualization.
• Merkel, D. — Docker: Lightweight Linux Containers for Consistent Development and Deployment. Linux Journal, 2014. The paper that popularized the Docker's approach, and it is the source for the Docker's design's rationale.
• Bernstein, D. — Containers and Cloud: From LXC to Docker to Kubernetes. IEEE Cloud Computing, 2014. The survey of the containers' evolution and the Docker's role.
• Turnbull, J. — The Docker Book: Containerize your applications with Docker. The comprehensive's practical's reference for the Docker's usage, and it is the source for the Dockerfile's directives' and the Docker Compose's treatment.
• Nickoloff, J., & Kuenzli, S. — Docker in Action, 2nd ed. Manning, 2019. The comprehensive's reference for the Docker's design and the containers' management, and it is the source for the Docker's architecture's and the networking's treatment.
• Mouat, A. — Using Docker: Developing and Deploying Software with Containers. O'Reilly, 2016. The practical's reference for the Docker's workflows, and it is the source for the Docker's images' and the Dockerfile's treatment.
• The Docker's documentation — The Docker's official's documentation (the docs.docker.com's site): the Dockerfile's reference, the Compose's reference, the Docker's CLI's reference, and the Docker's security's guides. The authoritative references for the Docker's usage.
• The Open Container Initiative (OCI)'s specifications: the Runtime's Specification, the Image's Specification, and the Distribution's Specification. The authoritative references for the containers' standards that the Docker's implements.
• Rice, L. — Container Security. O'Reilly, 2020. The comprehensive's treatment of the container's security's mechanisms and the escapes' attacks, and it is the source for the Docker's security's treatment.
• NIST SP 800-190. — Application Container Security Guide. National Institute of Standards and Technology. The security's reference for the containers.
• The Linux man pages: man 1 docker, man 1 docker-run, man 1 docker-build, man 1 docker-exec, man 1 docker-ps, man 1 docker-inspect, man 1 docker-logs, man 1 docker-network, man 1 docker-volume, man 1 docker-compose (or the docker compose's subcommand), man 5 Dockerfile (or the Dockerfile's reference), man 5 docker-compose.yml (or the Compose's reference), man 7 namespaces, man 7 cgroups, man 5 overlay, man 1 podman (the daemonless's alternative), man 1 buildah, man 1 skopeo, man 1 nerdctl, man 1 dive (if available).

04 Core content

4.1 What Docker is

Docker is the open-source's platform for the containers' building, the sharing, and the running. The Docker's purpose: the applications' packaging and the deployment's consistency (the "it works on my machine" problem's solution: the application and its dependencies in the single's artifact, the image). The Docker's design's central's observation: the containers' kernel's mechanisms (the namespaces, the cgroups, the union file systems) existed for the years before the Docker, and the Docker's contribution was the user experience and the ecosystem.

The Docker's platform's components:

• The Docker's client (the docker's CLI). The user's interface: the docker's command sends the requests to the daemon (the REST's API over the Unix's socket or the TCP's connection), and the daemon performs the operations. The client's design: the CLI's verbs (the build, the run, the pull, the push, the ps, the exec, the logs, the inspect, the stop, the rm, the rmi, the network, the volume, the compose), and the options (the resource's limits, the security's options, the network's configuration, the volumes, the environment's variables).
• The Docker's daemon (dockerd). The server: the daemon receives the client's requests (the REST's API), and it manages the Docker's objects (the images, the containers, the networks, the volumes, the plugins). The daemon's design: the dockerd's process, the containerd's child's process (the container's lifecycle's management), and the runc's children (the container's creation's and the execution's processes).
• The containerd. The high-level's runtime (the Docker's contribution, the containerd's project): the component that manages the container's lifecycle (the image's pulling, the container's creation, the container's start, the container's stop, the image's snapshots, the network's management) and that delegates the container's creation to the low-level's runtime (the runc). The containerd's design: the containerd's daemon, the gRPC's API, the CRI's implementation, and the content's store (the images' layers' storage).
• The runc. The low-level's runtime (the OCI's Runtime's Specification's implementation): the component that creates the container (the namespaces, the cgroups, the root's file system, the capabilities, the seccomp's filters) from the OCI's configuration and the image's layers. The runc's design: the Go's implementation (the Docker's and the containerd's default), the short-lived's process (it creates the container and exits), and the OCI's standard's compliance.
• The BuildKit. The modern's builder (the Docker's, the 2018's): the component that builds the images from the Dockerfiles with the performance's and the security's improvements (the parallel's builds, the cache's improvements, the rootless's builds, the secrets' mounts, the SSH's mounts, the multi-platform's builds). The BuildKit's design: the LLB's intermediate's representation (the Low-Level's Build's the graph's), the content-addressable's cache, and the Dockerfile's frontend (the # syntax=docker/dockerfile's directive).
• The Docker's storage's drivers. The components that manage the containers' file systems: the overlay2 (the default's on the modern's Linux: the overlayfs's implementation), the btrfs, the zfs, the devicemapper (the deprecated), the vfs (the development's: the copies, not the layers). The drivers' design: the images' layers' storage, the containers' writable's layers, and the layers' sharing (the same's base's image is the stored the once).
• The Docker's networking's drivers. The components that manage the containers' networks: the bridge (the default's: the private's network on the host's bridge), the host (the container shares the host's network's namespace), the overlay (the multi-host's networks: the Docker Swarm's), the macvlan (the containers get the MAC's addresses on the physical's network), the none (the container has no network), and the ipvlan.

4.2 The Docker's objects

The Docker's objects (the components that the Docker's platform manages):

The image (the read-only's template)

The Docker's image is the read-only's template that contains the application and its dependencies: the layered's file system (the base's image, the dependencies, the application), the metadata (the configuration: the environment's variables, the entrypoint, the command, the exposed's ports, the volumes, the user, the working's directory), and the digest (the content-addressable's identifier). The image's commands: the docker build (the Dockerfile's construction), the docker pull (the registry's download), the docker push (the registry's upload), the docker tag (the image's naming), the docker images (the listing), the docker inspect (the inspection), the docker history (the layers' history), the docker rmi (the removal).

The container (the running's instance)

The Docker's container is the running's instance of the image: the image's layers plus the writable's layer (the container's changes), the processes (the entrypoint's command), the namespaces (the isolated's views), the cgroups (the resource's limits), the network's interfaces, and the volumes (the persistent's storage). The container's commands: the docker run (the creation and the start), the docker create (the creation), the docker start (the start), the docker stop (the stop), the docker restart (the restart), the docker pause (the pause), the docker unpause (the resume), the docker ps (the listing), the docker exec (the command's execution inside the container), the docker logs (the logs), the docker inspect (the inspection), the docker stats (the statistics), the docker top (the processes), the docker diff (the file system's changes), the docker commit (the new image from the container), the docker rm (the removal).

The network (the isolated's network)

The Docker's network is the isolated's network that the containers use: the bridge's networks (the default's: the private's network on the host's bridge), the overlay's networks (the multi-host's: the Docker Swarm's), the macvlan's networks (the containers get the MAC's addresses on the physical's network), the host's networks (the container shares the host's network), and the none's networks (the container has no network). The network's commands: the docker network create, the docker network ls, the docker network inspect, the docker network connect, the docker network disconnect, the docker network rm.

The volume (the persistent's storage)

The Docker's volume is the persistent's storage that the containers use: the volumes (the Docker's managed's storage: the /var/lib/docker/volumes/'s directory), the bind mounts (the host's directories or the files mounted into the container: the -v /host/path:/container/path's option), and the tmpfs's mounts (the memory's file systems). The volume's purpose: the containers' data's persistence (the container's writable's layer is the ephemeral), and the observation: the volumes are the containers' state's management's mechanism. The volume's commands: the docker volume create, the docker volume ls, the docker volume inspect, the docker volume rm, the docker volume prune.

The plugin (the extensibility)

The Docker's plugin is the extension's mechanism: the storage's plugins (the volumes' drivers: the cloud's storage's integrations), the network's plugins (the CNI's, the overlay's), the logging's plugins (the logs' drivers: the syslog's, the fluentd's, the journald's, the splunk's), the authorization's plugins, and the metrics's plugins. The plugin's purpose: the Docker's integration with the external's systems (the storage, the network, the logging, the monitoring). The plugin's commands: the docker plugin install, the docker plugin ls, the docker plugin inspect, the docker plugin rm.

4.3 The Dockerfile

The Dockerfile is the declarative's format for the image's construction: the text's file with the instructions, and the Docker's builder (the BuildKit) executes the instructions to produce the image. The Dockerfile's directives:

FROM

The base's image: the FROM ubuntu:22.04's directive starts the image's construction from the ubuntu:22.04's image. The FROM's directive is the mandatory's first's instruction (except the ARG's directive before it), and the multi-stage's builds use the multiple's FROM's directives.

RUN

The command's execution during the build: the RUN apt-get update's directive executes the command in the container's build-time's environment, and the command's results are the new's layer. The RUN's directives are the image's construction's workhorses (the packages' installation, the build's commands, the configuration's commands), and the observation: the RUN's directive's layer's caching is the build's performance's mechanism.

COPY

The files' and the directories' copying from the build's context into the image: the COPY app.py /app/'s directive copies the app.py's file from the build's context (the directory's where the Dockerfile is, or the specified's context) into the image's /app/'s directory.

ADD

The COPY's superset: the ADD's directive supports the remote's URLs and the local's archives' extraction (the tar's files), and the observation: the Docker's best's practice recommends the COPY's directive (the explicit's behavior) over the ADD's (the implicit's behavior) unless the archive's extraction or the remote's URL is the intended's behavior.

CMD

The default's command: the CMD ["python", "app.py"]'s directive specifies the command that the container runs by default, and the docker run's arguments override the CMD's directive. The Dockerfile's design: the CMD's directive has the three's forms (the exec's form CMD ["executable", "param1"], the shell's form CMD command param1, and the parameters' form CMD ["param1"] with the ENTRYPOINT), and the observation: the exec's form is the recommended (the no shell's interpretation).

ENTRYPOINT

The container's executable: the ENTRYPOINT ["python"]'s directive specifies the executable that the container runs, and the CMD's directive supplies the default's arguments. The ENTRYPOINT's directive is the container's "the application" (the container's design: the single's process's model), and the observation: the ENTRYPOINT's and the CMD's combination's design is the container's interface's convention.

ENV

The environment's variables: the ENV NODE_ENV production's directive sets the environment's variables that persist in the image, and the container's processes see them. The ENV's directive is the configuration's mechanism, and the observation: the ARG's directive (the build-time's variables) and the ENV's directive (the runtime's variables) are the different's scopes.

ARG

The build-time's variables: the ARG VERSION=latest's directive declares the build-time's variable that the docker build --build-arg VERSION=1.0's option can override. The ARG's directive is the build's parameterization's mechanism, and the observation: the ARG's values are not the persisted in the image (the build's history's exclusion: the secrets' leakage's prevention), and the observation is the reason the ARG's directive is the secrets' mechanism's candidate (the with the BuildKit's secrets' mounts, the RUN --mount=type=secret's directive).

WORKDIR

The working's directory: the WORKDIR /app's directive sets the working's directory for the RUN, the CMD, the ENTRYPOINT, the COPY, and the ADD's directives, and the container's processes' working's directory. The WORKDIR's directive is the path's management's mechanism, and the observation: the WORKDIR's directive creates the directory if it does not exist (the mkdir -p's behavior).

EXPOSE

The port's documentation: the EXPOSE 8080's directive documents the port that the container's application listens on, and the docker run -p 8080:8080's option publishes the port to the host. The EXPOSE's directive is the documentation's mechanism (the metadata), not the publishing's mechanism (the -p's option), and the observation: the EXPOSE's directive is the image's metadata's documentation.

USER

The user's specification: the USER appuser's directive sets the user that the container's processes run as, and the observation: the USER's directive is the security's best's practice (the non-root's user: the Lesson 12.6's and the Lesson 13.3's discussions).

VOLUME

The volume's declaration: the VOLUME /data's directive declares the directory as the volume's mount's point, and the observation: the VOLUME's directive declares the volume's intent (the data's persistence's boundary), and the observation: the docker run -v's option is the volume's actual's configuration.

HEALTHCHECK

The health's check: the HEALTHCHECK --interval=30s CMD curl -f http://localhost:8080/ || exit 1's directive specifies the command that the Docker runs to check the container's health, and the observation: the HEALTHCHECK's directive is the container's health's monitoring's mechanism, and the observation: the orchestrators (the Docker Swarm, the Kubernetes) use the health's checks for the container's lifecycle's management.

LABEL

The metadata's labels: the LABEL maintainer="alice@example.com"'s directive adds the metadata's labels to the image, and the observation: the labels are the image's metadata's documentation (the author, the version, the license, the description).

SHELL

The shell's specification: the SHELL ["/bin/bash", "-c"]'s directive sets the shell that the RUN's, the CMD's, and the ENTRYPOINT's shell's forms use. The SHELL's directive is the shell's customization's mechanism (the Windows's PowerShell, the Linux's bash).

STOPSIGNAL

The signal's specification: the STOPSIGNAL SIGTERM's directive specifies the signal that the docker stop's command sends to the container's process, and the observation: the STOPSIGNAL's directive is the graceful's shutdown's mechanism.

ONBUILD

The deferred's instruction: the ONBUILD COPY . /app's directive specifies the instruction that the Docker executes when the image is used as the base's image in a subsequent's build. The ONBUILD's directive is the base's image's customization's mechanism, and the observation: the ONBUILD's directive is the deprecated's in the modern's practices (the explicit's COPY's directive in the child's Dockerfile is the recommended's practice).

The Dockerfile's layers and the build's cache: each Dockerfile's instruction produces a layer (the RUN, the COPY, the ADD, the ENV, the WORKDIR, the USER, the LABEL), and the Docker's builder caches the layers: when the builder re-executes the Dockerfile, it reuses the cached's layers for the instructions whose inputs are unchanged (the same's base's image, the same's commands, the same's copied files), and it re-executes the instructions whose inputs changed (the layer and the subsequent's layers). The observation is the reason the Dockerfile's instructions' order matters: the instructions that change frequently (the application's code's COPY) should be the last (the cache's reuse of the dependencies' layers), and the instructions that change rarely (the packages' installation's RUN) should be the first (the cache's reuse across the builds). The Dockerfile's best's practice: the layer's ordering (the dependencies' installation first, the application's code last), the combined's RUN's directives (the fewer's layers: the RUN apt-get update && apt-get install -y ... && rm -rf /var/lib/apt/lists/*'s pattern), the .dockerignore's file (the build's context's exclusion: the unnecessary's files' exclusion), and the multi-stage's builds (the separation's of the build's and the runtime's dependencies).

The multi-stage's builds: the Dockerfile with the multiple's FROM's directives, where the earlier's stages are the build's stages (the compilers, the build's tools) and the later's stages are the runtime's stages (the minimal's image with the compiled's artifacts copied from the build's stages). The multi-stage's builds' advantages: the smaller's images (the runtime's stage's image excludes the build's tools and the source's code), the smaller's attack surface (the fewer's packages), and the faster's pulls (the smaller's layers). The multi-stage's builds' design's example:

# The build's stage
FROM golang:1.21 AS builder
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o /app/server ./cmd/server

# The runtime's stage
FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=builder /app/server /server
USER nonroot:nonroot
EXPOSE 8080
ENTRYPOINT ["/server"]

The multi-stage's builds' observation: the build's stage (the golang:1.21's image: the ~800 MB) contains the compiler and the source's code, and the runtime's stage (the distroless's image: the ~2 MB) contains only the compiled's binary. The observation: the multi-stage's builds are the modern's images' best's practice (the smaller's images, the smaller's attack surface, the faster's pulls), and the observation is the reason the modern's Dockerfiles use the multi-stage's builds for the compiled's languages (the Go, the Rust, the C, the Java) and for the interpreted's languages' dependency's vendoring.

4.4 The Docker's images

The Docker's image is the read-only's template that contains the application and its dependencies. The image's structure and management:

• The layers. The image is the stack of the read-only's layers: each layer is the file system's changes (the added, the modified, the deleted files) relative to the previous's layer, and the image's metadata (the config's JSON's file) is the separate's artifact. The layers' design's advantages: the storage's efficiency (the layers are the shared between the images: the same's base's layer is the stored the once), the distribution's efficiency (the layers are the cached and the transferred the incrementally: only the changed's layers are the downloaded), and the reproducibility (the image's digest identifies the exact's contents).
• The tags. The image's reference: the registry/namespace/name:tag's format (the docker.io/library/ubuntu:22.04's, the ghcr.io/myorg/myapp:v1.0.0's), and the tag's design: the mutable's reference (the same's tag can point to the different's digests: the latest's tag is the conventional's "the most recent's" tag), and the observation: the tags are the convenient's references (the human's readable), and the observation is the reason the production's deployments should use the digests, not the tags.
• The digests. The image's content-addressable's identifier (the sha256:...'s: the hash of the image's manifest), and the digest's design: the immutable's reference (the digest identifies the exact's contents: the same's digest is always the same's image), and the observation: the digests are the production's deployments' references (the immutable's guarantee), and the observation is the reason the supply chain's security (the images' signing, the attestation) uses the digests.
• The registries. The images' repositories: the Docker Hub (the public's: the docker.io's registry), the private's registries (the Harbor, the Nexus, the Artifactory, the GitLab's Container Registry), and the cloud's providers' registries (the AWS's ECR, the Azure's ACR, the Google's Artifact Registry, the GitHub's Container Registry). The registries' commands: the docker login (the authentication), the docker pull (the download), the docker push (the upload), the docker search (the search), the docker manifest (the multi-platform's manifests).
• The image's commands. The docker build (the Dockerfile's construction), the docker images (the listing), the docker inspect (the inspection: the configuration, the layers, the metadata), the docker history (the layers' history: the instructions and the sizes), the docker tag (the image's naming), the docker rmi (the removal), the docker save (the image's export to a tar's file), the docker load (the image's import from a tar's file), the docker export (the container's file system's export), the docker import (the file system's import as an image).
• The image's analysis's tools. The dive's tool (the image's layers' inspection: the each layer's contents, the wasted's space, the efficiency's score), the docker history (the layers' history), the docker inspect (the image's metadata), the skopeo inspect (the remote's image's inspection), and the buildah inspect (the image's inspection with the buildah's tool). The observation: the image's analysis's tools are the image's optimization's and the security's auditing's mechanisms.

4.5 The Docker's containers

The Docker's container is the running's instance of the image: the image's layers plus the writable's layer (the container's changes), the processes (the entrypoint's command), the namespaces (the isolated's views), the cgroups (the resource's limits), the network's interfaces, and the volumes (the persistent's storage). The container's management:

• The container's lifecycle. The docker create (the creation: the container's state is the created), the docker start (the start: the container's state is the running), the docker pause (the pause: the container's state is the paused: the cgroup's freezer's controller suspends the processes), the docker unpause (the resume), the docker stop (the stop: the SIGTERM's signal, the grace's period, the SIGKILL's signal; the container's state is the exited), the docker restart (the restart), the docker kill (the forced's stop: the SIGKILL's signal), the docker rm (the removal: the container's state is the removed: the writable's layer is the deleted and the resources are the released).
• The container's inspection. The docker ps (the running's containers's listing: the -a's option shows the stopped's containers), the docker inspect (the container's configuration and the state: the JSON's output), the docker logs (the container's logs: the stdout's and the stderr's streams), the docker stats (the container's resource's usage: the CPU's, the memory's, the network's, the I/O's), the docker top (the container's processes), the docker diff (the container's file system's changes: the added, the modified, the deleted files), the docker port (the container's port's mappings), the docker events (the Docker's events's stream).
• The container's interaction. The docker exec (the command's execution inside the running's container: the -it's options for the interactive's session), the docker attach (the container's stdin's and stdout's attachment: the container's main's process), the docker cp (the files' copying between the container and the host), the docker commit (the new image from the container's changes: the writable's layer as the new's layer).
• The container's networking. The network's drivers (the bridge's, the host's, the overlay's, the macvlan's, the none's), the port's mapping (the -p host_port:container_port's option: the host's port forwarding to the container's port), the network's inspection (the docker network inspect's output: the network's details, the containers' IP's addresses, the DNS's configuration), the container's DNS's resolution (the container's name's resolution within the user-defined's networks: the embedded's DNS's server), and the container's network's namespaces (the isolated's view).
• The container's storage. The writable's layer (the container's file system's changes: the overlayfs's upper's directory), the volumes (the -v volume_name:/path's option: the Docker's managed's volume), the bind mounts (the -v /host/path:/container/path's option: the host's directory), the tmpfs's mounts (the --tmpfs /path's option: the memory's file system), and the container's file system's inspection (the docker diff's output).
• The container's resource's limits. The CPU's limits (the --cpus 0.5's option: the 50% of the one CPU; the --cpu-shares 512's option: the relative's weight), the memory's limits (the --memory 128m's option: the hard's limit; the --memory-reservation 64m's option: the soft's limit), the I/O's limits (the --device-read-bps's and the --device-write-bps's options), the processes' count's limit (the --pids-limit 100's option), and the observation: the resource's limits are the cgroups' controllers' configuration (the Lesson 12.6's and the Lesson 13.3's discussions).
• The container's configuration. The environment's variables (the -e KEY=value's option, the --env-file .env's option), the container's name (the --name myapp's option), the restart's policy (the --restart always's, unless-stopped's, and on-failure's policies), the labels (the --label key=value's option), and the health's check (the --health-cmd's and the --health-interval's options).

4.6 The Docker Compose

The Docker Compose is the Docker's tool for the multi-container applications: the compose.yaml's (or the docker-compose.yml's) file declares the application's services, and the docker compose up's command creates and starts the services (the containers, the networks, the volumes). The Compose's components:

The services

The application's components: the each's service is the container (or the containers' set: the deploy.replicas's option), and the service's configuration (the image, the build's context, the ports, the volumes, the environment's variables, the dependencies, the networks, the resource's limits, the health's checks, the restart's policy).

The networks

The application's networks: the Compose's networks (the default's: the single's network that the services share; the custom's: the multiple's networks with the services' isolation), and the observation: the Compose's networks are the Docker's networks (the bridge's, the overlay's).

The volumes

The application's persistent's storage: the Compose's volumes (the named's volumes, the bind mounts, the tmpfs), and the observation: the Compose's volumes are the Docker's volumes (the named's volumes are the Docker's managed's storage).

The compose.yaml's structure

The file's sections: the services's section (the application's services), the networks's section (the application's networks), the volumes's section (the application's volumes), the configs's section (the configuration's files), the secrets's section (the secrets' management), and the x-'s extension's fields (the custom's fields).

The Compose's example:

# The compose.yaml's file
services:
  web:
    build: .
    ports:
      - "8080:8080"
    environment:
      - DATABASE_URL=postgres://user:pass@db:5432/mydb
    depends_on:
      db:
        condition: service_healthy
    networks:
      - app-network
    deploy:
      resources:
        limits:
          cpus: '0.5'
          memory: 512M
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
      interval: 30s
      timeout: 5s
      retries: 3

  db:
    image: postgres:16-alpine
    environment:
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=pass
      - POSTGRES_DB=mydb
    volumes:
      - db-data:/var/lib/postgresql/data
    networks:
      - app-network
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U user -d mydb"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  db-data:

networks:
  app-network:
    driver: bridge

The Compose's commands: the docker compose up (the services' creation and the start: the -d's option for the detached's mode), the docker compose down (the services' stop and the resources' removal: the -v's option removes the volumes), the docker compose ps (the services' listing), the docker compose logs (the services' logs: the -f's option for the follow's mode), the docker compose exec (the command's execution inside the service's container), the docker compose build (the services' images' building), the docker compose pull (the services' images' pulling), the docker compose config (the configuration's validation), the docker compose scale (the services' scaling: the deprecated in the modern's Compose: the deploy.replicas's option is the modern's mechanism). The observation: the Compose's design is the development's and the testing's multi-container's applications' tool (the compose.yaml's file is the application's definition), and the observation: the Compose's design is the Kubernetes's manifests' ancestor (the Compose's services and the Kubernetes's Deployments and Services are the analogous's concepts).

4.7 The Docker's security

The Docker's security is the layered's design (the Lesson 12.6's and the Lesson 13.3's discussions applied to the Docker's configuration), and its considerations:

• The Docker's daemon's security. The dockerd's daemon runs as the root (the default's configuration), and its attack surface is the significant (the REST's API, the images' management, the containers' management). The observation: the daemon's compromise is the host's compromise (the daemon has the root's privileges), and the observation is the reason the modern's practices include the daemon's protection (the Unix's socket's permissions, the TLS's certificates for the TCP's connections, the authorization's plugins, the docker's group's membership's caution: the docker's group is the root's equivalent), and the rootless's Docker (the daemon runs as the unprivileged's user).
• The container's security. The containers' security's configurations (the Lesson 13.3's discussions): the non-root's user (the USER's directive in the Dockerfile, the --user's option), the read-only's root's file system (the --read-only's option with the tmpfs's mounts for the writable's paths), the dropped's capabilities (the --cap-drop=ALL and the --cap-add='s specific's capabilities), the seccomp's profiles (the default's or the custom's: the --security-opt seccomp='s option), the LSM's profiles (the --security-opt label='s option), the --security-opt no-new-privileges's setting, the resource's limits (the --memory's, the --cpus's, the --pids-limit's options), the --privileged's flag's avoidance (the full's host's privileges: the dangerous's option), the host's namespaces' sharing's avoidance (the --pid=host's, the --net=host's, the --ipc=host's, the --uts=host's options), the sensitive's mounts' avoidance (the /var/run/docker.sock's mount, the host's root's mount), and the observation: the container's security is the configuration's discipline.
• The image's security. The images' security (the Lesson 13.3's discussions): the minimal's images (the alpine's, the distroless's, the scratch's: the smaller's attack surface), the images' scanning (the Trivy's, the Clair's, the Grype's, the Docker's docker scan), the images' signing (the Notary's, the Cosign's, the Docker Content Trust), the images' attestation (the SLSA's, the in-toto's), the SBOM's generation (the Syft's, the Trivy's), and the observation: the image's security is the containers' security's foundation (the image's vulnerabilities are the container's vulnerabilities).
• The registry's security. The registries' security: the authentication (the Docker Hub's, the cloud's providers' registries' IAM), the authorization (the repositories' access's control), the images' signing and the verification (the content's trust: the Notary's, the Cosign's), the images' scanning (the registries' integrated's scanning: the Harbor's, the ECR's, the ACR's), and the observation: the registry's security is the images' supply chain's security's foundation.
• The secrets' management. The secrets' mechanisms: the --env-file's option (the environment's variables: the limited's security: the variables are the visible in the docker inspect's output), the Docker's secrets (the docker secret's commands: the Swarm's secrets), the build's secrets (the BuildKit's RUN --mount=type=secret's directive: the secrets are the mounted during the build, not the persisted in the layer), and the external's secret's stores (the HashiCorp's Vault, the Kubernetes's secrets, the cloud's providers' secret's managers), and the observation: the secrets' management is the containers' security's central's concern (the secrets' leakage is the common's vulnerability).
• The runtime's security's tools. The runtime's security's monitoring: the Falco's (the runtime's security: the system calls' monitoring, the rules, the alerts), the Sysdig's (the system's inspection), the Tetragon's (the eBPF's security's observability: the Kubernetes's, the Cilium's), the Docker Bench's (the CIS's benchmark's checks for the Docker's configuration), and the observation: the runtime's security's tools are the containers' security's operations's mechanisms (the detection, the response).
• The Docker Bench for Security. The docker-bench-security's tool: the CIS's Docker's benchmark's automated's checks (the host's configuration, the daemon's configuration, the container's configuration, the images, the runtime), and the observation: the Docker Bench's tool is the Docker's security's assessment's mechanism.

4.8 The Docker's ecosystem

The Docker's ecosystem's components:

• The BuildKit. The modern's builder (the Docker's, the 2018's): the performance's and the security's improvements (the parallel's builds, the cache's improvements, the rootless's builds, the secrets' mounts, the SSH's mounts, the multi-platform's builds, the RUN --mount's directives). The BuildKit's activation: the DOCKER_BUILDKIT=1's environment's variable (the older's versions) or the default (the modern's Docker's versions).
• The Buildx. The Docker's CLI's plugin (the BuildKit's frontend): the docker buildx's commands (the buildx build, the buildx create, the buildx inspect, the buildx ls, the buildx rm), and the multi-platform's builds (the --platform linux/amd64,linux/arm64's option: the single's command builds the images for the multiple's architectures), and the observation: the Buildx's tool is the modern's Docker's builders' interface.
• The Docker Swarm. The Docker's native's orchestration (the Docker's, the 2014's): the swarm (the cluster's of the Docker's nodes), the services (the multi-container's applications: the replicated's tasks), the nodes (the managers and the workers), the overlay's networks (the multi-host's networks), the secrets and the configs (the sensitive's data's management), and the stacks (the Compose's files' deployment), and the observation: the Swarm's design is the Docker's native's orchestration, and the observation: the Swarm's adoption is the limited (the Kubernetes's dominance), but the Swarm's simplicity is the attractive for the small's deployments.
• The Docker Desktop. The developer's environment (the Docker's, the macOS's, the Windows's, the Linux's): the Docker's daemon, the CLI, the Compose, the Kubernetes's single-node's cluster, the Buildx, and the GUI (the Docker Dashboard), and the observation: the Docker Desktop's tool is the developers' local's environments' standard.
• The Docker Hub. The public's registry (the Docker's): the official's images (the ubuntu's, the python's, the node's, the alpine's, the nginx's, the postgres's, the redis's, the mongo's), the verified's publishers (the vendors' images), the community's images, the automated's builds (the linked's GitHub's and Bitbucket's repositories), the webhooks, and the organizations and the teams, and the observation: the Docker Hub's registry is the images' distribution's foundation.
• The Docker's plugins. The Docker's plugins' ecosystem: the storage's plugins (the volumes' drivers: the cloud's storage's integrations: the AWS's EBS, the Azure's Disk, the GCP's Persistent Disk, the NetApp's, the Pure's), the network's plugins (the CNI's, the overlay's: the Calico's, the Cilium's, the Weave's), the logging's plugins (the logs' drivers: the syslog's, the fluentd's, the journald's, the splunk's, the gcplogs's), the authorization's plugins (the access's control), and the metrics's plugins (the monitoring's integrations).
• The Docker's alternatives. The Docker's alternatives: the Podman (the daemonless's containers: the rootless's default, the systemd's integration, the pods), the containerd (the standalone's runtime: the Kubernetes's), the CRI-O (the Kubernetes's runtime), the nerdctl (the containerd's CLI: the Docker's compatible's interface), the Buildah (the images' building without the daemon), the Kaniko (the images' building in the Kubernetes's clusters), the img (the rootless's images' builder), and the observation: the Docker's alternatives are the containers' ecosystem's diversity, and the observation is the reason the OCI's standards are the containers' interoperability's foundation.

4.9 The Docker's role in the containers' adoption

The Docker's role in the containers' adoption:

• The Docker's contribution: the user experience. The containers' kernel's mechanisms (the namespaces, the cgroups, the union file systems) existed for the years before the Docker, and the Docker's contribution was the user experience: the images (the application and its dependencies in the single's artifact: the "it works on my machine" problem's solution), the Dockerfile (the declarative's build's format: the reproducible's image's construction), the registries (the images' distribution: the Docker Hub's and the private's registries), the CLI (the simple's commands: the docker run, the docker build, the docker pull, the docker push), and the ecosystem (the Compose, the Swarm, the Desktop, the Hub, the plugins).
• The Docker's impact: the containers' mainstream. The Docker's release (the 2013's) made the containers the mainstream: the developers' adoption (the images and the Dockerfile for the applications' packaging), the operations' adoption (the containers' deployment), the cloud's providers' adoption (the container's services: the AWS's ECS, the GKE, the AKS), and the ecosystem's explosion (the Compose, the Kubernetes, the Helm, the Istio, the Prometheus, the many's tools), and the observation: the Docker's impact was the containers' mainstream's driver.
• The Docker's evolution: the OCI's standards. The Docker's contribution (the 2015's): the Docker donated the libcontainer's library to the OCI (the runc's project), and the Docker's design (the image's format, the runtime's interface) became the OCI's specifications (the Runtime's Specification, the Image's Specification, the Distribution's Specification), and the observation: the Docker's evolution was the standards' contribution (the containers' interoperability: the OCI's standards are the containers' ecosystem's foundation).
• The Docker's challenges: the ecosystem's competition. The Docker's challenges (the 2018's and the after): the Kubernetes's dominance (the orchestration's standard: the Docker's Swarm's decline), the containerd's and the CRI-O's adoption (the runtimes' independence: the Kubernetes's dockershim's removal in the 1.24's), the Podman's and the Buildah's adoption (the daemonless's alternatives: the Red Hat's), and the observation: the Docker's challenges were the ecosystem's competition (the containers' ecosystem's diversity), and the observation: the Docker's response was the focus on the developers' experience (the Docker Desktop, the Docker Hub, the Compose) and the standards' compliance (the OCI's).

4.10 Common misconceptions

05 Worked example

The following example builds a container's image with the Dockerfile's and the multi-stage's builds, runs and inspects the container, and demonstrates the Docker Compose's multi-container's application.

# Create the application's directory
mkdir -p /tmp/goapp
cd /tmp/goapp

# Create the Go's application
cat > main.go << 'EOF'
package main

import (
    "fmt"
    "net/http"
)

func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "Hello from the Go's container!\n")
    })
    http.ListenAndServe(":8080", nil)
}
EOF

# Create the go.mod's file
cat > go.mod << 'EOF'
module example.com/goapp

go 1.21
EOF

# Create the multi-stage's Dockerfile
cat > Dockerfile << 'EOF'
# The build's stage
FROM golang:1.21-alpine AS builder
WORKDIR /src
COPY go.mod ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o /app/server .

# The runtime's stage
FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=builder /app/server /server
USER nonroot:nonroot
EXPOSE 8080
ENTRYPOINT ["/server"]
EOF

# Create the .dockerignore's file
cat > .dockerignore << 'EOF'
.git
*.md
Dockerfile
.dockerignore
EOF

# Build the image
docker build -t goapp:v1.0 . 2>/dev/null

# Inspect the image's layers and size
docker images goapp:v1.0
docker history goapp:v1.0
docker inspect goapp:v1.0 2>/dev/null | head -40

# Run the container
docker run -d --name goapp-container \
    -p 8080:8080 \
    --memory 64m --cpus 0.5 \
    --read-only --tmpfs /tmp \
    --cap-drop=ALL \
    --security-opt no-new-privileges \
    goapp:v1.0 2>/dev/null

# Test the application
sleep 2
curl http://localhost:8080/ 2>/dev/null

# Inspect the container
docker ps 2>/dev/null
docker stats --no-stream goapp-container 2>/dev/null
docker inspect goapp-container 2>/dev/null | head -60

# The container's security's configuration
docker inspect goapp-container 2>/dev/null | \
    python3 -c "
import sys, json
data = json.load(sys.stdin)
c = data[0]
print('The user:', c['Config']['User'])
print('The capabilities:', c['HostConfig']['CapDrop'])
print('The read-only:', c['HostConfig']['ReadonlyRootfs'])
print('The security options:', c['HostConfig']['SecurityOpt'])
print('The memory limit:', c['HostConfig']['Memory'])
print('The CPU quota:', c['HostConfig']['NanoCpus'])
"

# The cleanup
docker rm -f goapp-container 2>/dev/null
docker rmi goapp:v1.0 2>/dev/null
rm -rf /tmp/goapp

# The image's history (the layers and the instructions)
docker history goapp:v1.0

# The image's layers' sizes
docker inspect goapp:v1.0 2>/dev/null | \
    python3 -c "
import sys, json
data = json.load(sys.stdin)
c = data[0]
print('The layers:', len(c['RootFS']['Layers']))
for i, layer in enumerate(c['RootFS']['Layers']):
    print(f'  The layer {i}: {layer[:30]}...')
print('The image size:', c['Size'])
"

# The dive's tool (if available)
dive goapp:v1.0 --ci 2>/dev/null | head -40

# The image's config
docker inspect goapp:v1.0 2>/dev/null | \
    python3 -c "
import sys, json
data = json.load(sys.stdin)
c = data[0]
print('The entrypoint:', c['Config']['Entrypoint'])
print('The exposed ports:', c['Config']['ExposedPorts'])
print('The user:', c['Config']['User'])
print('The env:', c['Config']['Env'])
"

# Create the application's directory
mkdir -p /tmp/compose-app
cd /tmp/compose-app

# Create the compose.yaml's file
cat > compose.yaml << 'EOF'
services:
  web:
    image: nginx:alpine
    ports:
      - "8080:80"
    volumes:
      - ./html:/usr/share/nginx/html:ro
    networks:
      - app-net
    depends_on:
      - api
    healthcheck:
      test: ["CMD", "wget", "-q", "-O", "-", "http://localhost/"]
      interval: 30s
      timeout: 5s
      retries: 3

  api:
    image: python:3.11-alpine
    command: python -m http.server 8000
    working_dir: /data
    volumes:
      - ./data:/data:ro
    networks:
      - app-net
    healthcheck:
      test: ["CMD", "wget", "-q", "-O", "-", "http://localhost:8000/"]
      interval: 30s
      timeout: 5s
      retries: 3

  db:
    image: postgres:16-alpine
    environment:
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=pass
      - POSTGRES_DB=mydb
    volumes:
      - db-data:/var/lib/postgresql/data
    networks:
      - app-net
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U user -d mydb"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  db-data:

networks:
  app-net:
    driver: bridge
EOF

# Create the content's directories
mkdir -p html data
echo "<h1>Hello from the Nginx's container!</h1>" > html/index.html
echo "Hello from the API's container!" > data/index.html

# Validate the configuration
docker compose config 2>/dev/null | head -40

# Start the application
docker compose up -d 2>/dev/null

# The application's state
docker compose ps 2>/dev/null
docker compose logs 2>/dev/null | head -20

# Test the application
sleep 3
curl http://localhost:8080/ 2>/dev/null

# The services' inspection
docker compose exec api ls -la /data 2>/dev/null
docker compose exec db psql -U user -d mydb -c '\l' 2>/dev/null

# The services' scaling (the demonstration)
docker compose up -d --scale api=2 2>/dev/null
docker compose ps 2>/dev/null

# The cleanup
docker compose down -v 2>/dev/null
rm -rf /tmp/compose-app

# The Docker's daemon's configuration
cat /etc/docker/daemon.json 2>/dev/null
ps -ef | grep dockerd | head -1

# The Docker's daemon's socket's permissions
ls -la /var/run/docker.sock

# The Docker's info
docker info 2>/dev/null | head -40

# The container's security's configuration
docker inspect goapp-container 2>/dev/null | \
    python3 -c "
import sys, json
data = json.load(sys.stdin)
c = data[0]
print('=== The security ===')
print('The user:', c['Config']['User'])
print('The capabilities:', c['HostConfig']['CapDrop'])
print('The read-only:', c['HostConfig']['ReadonlyRootfs'])
print('The privileged:', c['HostConfig']['Privileged'])
print('The security options:', c['HostConfig']['SecurityOpt'])
print('The pid mode:', c['HostConfig']['PidMode'])
print('The network mode:', c['HostConfig']['NetworkMode'])
print('The ipc mode:', c['HostConfig']['IpcMode'])
"

# The Docker Bench for Security (if available)
which docker-bench-security 2>/dev/null
git clone https://github.com/docker/docker-bench-security.git /tmp/dbs 2>/dev/null
cd /tmp/dbs && sudo ./docker-bench-security.sh 2>/dev/null | head -60
rm -rf /tmp/dbs

# The image's scanning (if the trivy's tool is available)
trivy image goapp:v1.0 2>/dev/null | head -30

06 Interactive activity

07 Knowledge check

08 Unit discussion

09 Practice exercise

10 Summary

• Docker is the open-source's platform for the containers' building, the sharing, and the running. Its purpose: the applications' packaging and the deployment's consistency (the "it works on my machine" problem's solution). Its contribution was the user experience and the ecosystem (the images, the Dockerfile, the registries, the CLI, the Compose, the Swarm, the Desktop, the Hub).
• The Docker's architecture: the client (the docker's CLI), the daemon (the dockerd: the objects' management), the containerd (the high-level's runtime: the container's lifecycle), the runc (the low-level's runtime: the OCI's runtime), and the BuildKit (the modern's builder: the images' construction).
• The Docker's objects: the images (the read-only's templates: the layers, the metadata, the digests), the containers (the running's instances: the image plus the writable's layer, the processes, the namespaces, the cgroups, the network, the volumes), the networks (the isolated's networks: the bridge's, the overlay's, the macvlan's, the host's, the none's), the volumes (the persistent's storage: the volumes, the bind mounts, the tmpfs), and the plugins (the extensibility: the storage's, the network's, the logging's).
• The Dockerfile is the declarative's format for the image's construction: the directives (the FROM, the RUN, the COPY, the CMD, the ENTRYPOINT, the ENV, the ARG, the WORKDIR, the EXPOSE, the USER, the VOLUME, the HEALTHCHECK, the LABEL, the SHELL, the STOPSIGNAL, the ONBUILD). The layers' and the build's cache's mechanisms: each instruction produces a layer, and the builder reuses the cached's layers. The best's practices: the instructions' order, the combined's RUN's directives, the .dockerignore's file, and the multi-stage's builds.
• The Docker's images: the layers (the shared between the images), the tags (the mutable's references), the digests (the immutable's references), and the registries (the Docker Hub, the private's, the cloud's providers'). The Docker's containers: the lifecycle (the create, the start, the pause, the stop, the remove), the networking (the bridge's, the host's, the overlay's, the macvlan's drivers), the storage (the writable's layer, the volumes, the bind mounts), and the configuration (the environment's variables, the resource's limits, the health's checks, the restart's policies).
• The Docker Compose is the Docker's tool for the multi-container's applications: the compose.yaml's file (the services, the networks, the volumes), the commands (the docker compose up, the down, the ps, the logs, the exec, the build, the config).
• The Docker's security: the daemon's security (the root's privileges, the socket's permissions, the rootless's Docker), the container's security (the non-root's user, the read-only's file system, the dropped's capabilities, the seccomp's profiles, the LSM's profiles, the no-new-privileges's setting, the resource's limits), the image's security (the minimal's images, the scanning, the signing, the SBOM), the registry's security, the secrets' management, and the runtime's security's tools (the Falco's, the Sysdig's, the Tetragon's, the Docker Bench's).
• The Docker's ecosystem: the BuildKit (the modern's builder), the Buildx (the CLI's plugin: the multi-platform's builds), the Docker Swarm (the native's orchestration), the Docker Desktop (the developer's environment), the Docker Hub (the public's registry), the plugins, and the alternatives (the Podman, the containerd, the CRI-O, the nerdctl, the Buildah, the Kaniko).
• The Docker's role in the containers' adoption: the Docker's contribution was the user experience (the images, the Dockerfile, the registries, the CLI, the ecosystem); the Docker's release made the containers the mainstream; the Docker's evolution was the standards' contribution (the OCI's specifications); and the Docker's challenges were the ecosystem's competition (the Kubernetes's dominance, the containerd's and the CRI-O's adoption, the Podman's and the Buildah's adoption).

11 References

• Silberschatz, A., Galvin, P. B., & Gagne, G. Operating System Concepts, 10th ed., Chapter 18.
• Arpaci-Dusseau, R. H., & Arpaci-Dusseau, A. C. Operating Systems: Three Easy Pieces, the Virtualization chapters. Available online at ostep.org.
• Tanenbaum, A. S., & Bos, H. Modern Operating Systems, 4th ed., Chapter 7.
• Merkel, D. Docker: Lightweight Linux Containers for Consistent Development and Deployment. Linux Journal, 2014.
• Bernstein, D. Containers and Cloud: From LXC to Docker to Kubernetes. IEEE Cloud Computing, 2014.
• Turnbull, J. The Docker Book: Containerize your applications with Docker. The comprehensive's practical's reference.
• Nickoloff, J., & Kuenzli, S. Docker in Action, 2nd ed. Manning, 2019.
• Mouat, A. Using Docker: Developing and Deploying Software with Containers. O'Reilly, 2016.
• The Docker's documentation (docs.docker.com): the Dockerfile's reference, the Compose's reference, the Docker's CLI's reference, and the Docker's security's guides.
• The Open Container Initiative (OCI)'s specifications: the Runtime's Specification, the Image's Specification, and the Distribution's Specification.
• Rice, L. Container Security. O'Reilly, 2020.
• NIST SP 800-190. Application Container Security Guide. National Institute of Standards and Technology.
• Linux man-pages: man 1 docker, man 1 docker-run, man 1 docker-build, man 1 docker-exec, man 1 docker-ps, man 1 docker-inspect, man 1 docker-logs, man 1 docker-network, man 1 docker-volume, man 1 docker-compose, man 5 Dockerfile, man 5 docker-compose.yml, man 1 podman, man 1 buildah, man 1 skopeo, man 1 nerdctl.