Checkpoint Lab — Installing Docker Engine and Desktop, CLI Basics, Daemon Connectivity, Contexts, and Environment Setup

1. Checkpoint scenario and acceptance criteria

Establish one disposable Docker environment and prove it as if handing it to another engineer. The preferred execution path is a disposable native-Linux Engine host from Lesson 2; Docker Desktop learners may use the Desktop variant and mark host-service/data-root details that are abstracted by the VM as such.

Your evidence packet must answer: What platform is this? How was Docker obtained? Which client and server are in use? Which context/endpoint receives commands? What is the daemon data root/storage model? What privilege model lets this user administer Docker? Which immutable image content was tested? Which container object was created? What survived restart? What was cleaned up?

2. Setup and lab identity

set -eu

LAB_CONTAINER="da-ch02-checkpoint"
LAB_LABEL="devops-academy.lab=chapter02-checkpoint"
LAB_IMAGE_TAG="hello-world:latest"
EVIDENCE_DIR="$HOME/da-ch02-evidence"
mkdir -p "$EVIDENCE_DIR"

printf 'started=%s
' "$(date -u +%Y-%m-%dT%H:%M:%SZ)" | tee "$EVIDENCE_DIR/session.txt"

3. Capture platform, client, server, context, and privilege preflight

{
  echo '=== host ==='
  uname -a 2>/dev/null || true
  uname -m 2>/dev/null || true
  cat /etc/os-release 2>/dev/null || true
  echo '=== client/server ==='
  docker version
  echo '=== context ==='
  docker context show
  docker context ls
  docker context inspect "$(docker context show)"
  echo '=== environment overrides ==='
  env | grep '^DOCKER_' || true
  echo '=== plugins ==='
  docker buildx version 2>/dev/null || true
  docker compose version 2>/dev/null || true
  echo '=== identity ==='
  id 2>/dev/null || true
  ls -l /var/run/docker.sock 2>/dev/null || true
} | tee "$EVIDENCE_DIR/preflight.txt"

On Windows/Desktop, save wsl --version and the Desktop version/backend separately. Never invent Linux service/socket evidence that your Desktop host cannot expose.

4. Capture daemon state, data root, storage, and security baseline

{
  docker info
  docker info --format 'DockerRootDir={{.DockerRootDir}}'
  docker info --format 'Driver={{.Driver}} CgroupVersion={{.CgroupVersion}} CgroupDriver={{.CgroupDriver}}'
  docker info --format 'SecurityOptions={{json .SecurityOptions}}'
} | tee "$EVIDENCE_DIR/daemon-baseline.txt"

Record the data root as an identity fact. Do not browse/delete its internals for this checkpoint. If Docker Desktop abstracts this behind the managed VM, record that boundary instead.

5. Write predictions before changing runtime state

6. Resolve the image and run the checkpoint container

docker pull "$LAB_IMAGE_TAG" | tee "$EVIDENCE_DIR/pull.txt"
IMAGE_REF="$(docker image inspect "$LAB_IMAGE_TAG" --format '{{index .RepoDigests 0}}')"
IMAGE_ID="$(docker image inspect "$LAB_IMAGE_TAG" --format '{{.Id}}')"
printf 'image_ref=%s
image_id=%s
' "$IMAGE_REF" "$IMAGE_ID" | tee "$EVIDENCE_DIR/image.txt"

docker run --name "$LAB_CONTAINER" --label "$LAB_LABEL" "$IMAGE_REF"   | tee "$EVIDENCE_DIR/container-output.txt"

docker inspect "$LAB_CONTAINER" >"$EVIDENCE_DIR/container-inspect.json"
docker inspect "$LAB_CONTAINER" \
  --format   'id={{.Id}} image={{.Image}} status={{.State.Status}} exit={{.State.ExitCode}} labels={{json .Config.Labels}}'   | tee "$EVIDENCE_DIR/container-summary.txt"

A successful exit is useful evidence, but write explicitly that it does not prove port publication, application health, persistent data, or registry publication.

7. Preflight the restart

docker ps --format 'table {{.ID}}	{{.Names}}	{{.Status}}'
docker ps -a --filter "label=$LAB_LABEL"

BEFORE_CONTAINER_ID="$(docker inspect "$LAB_CONTAINER" --format '{{.Id}}')"
BEFORE_IMAGE_ID="$(docker image inspect "$IMAGE_REF" --format '{{.Id}}')"
BEFORE_ROOT="$(docker info --format '{{.DockerRootDir}}')"
printf '%s
'   "before_container=$BEFORE_CONTAINER_ID"   "before_image=$BEFORE_IMAGE_ID"   "before_root=$BEFORE_ROOT"   | tee "$EVIDENCE_DIR/before-restart.txt"

If this command reveals unrelated running containers on a native Engine host, do not restart that daemon for the course exercise.

8. Restart safely and verify persistence

Native Linux Engine path:

sudo systemctl restart docker
sudo systemctl is-active docker

Docker Desktop path: use Docker Desktop's supported restart control/CLI for your installed release. Do not kill VM processes manually. After Desktop is healthy again, continue with portable Docker CLI checks below.

docker version
docker context show

AFTER_CONTAINER_ID="$(docker inspect "$LAB_CONTAINER" --format '{{.Id}}')"
AFTER_IMAGE_ID="$(docker image inspect "$IMAGE_REF" --format '{{.Id}}')"
AFTER_ROOT="$(docker info --format '{{.DockerRootDir}}')"

printf '%s
'   "after_container=$AFTER_CONTAINER_ID"   "after_image=$AFTER_IMAGE_ID"   "after_root=$AFTER_ROOT"   | tee "$EVIDENCE_DIR/after-restart.txt"

test "$BEFORE_CONTAINER_ID" = "$AFTER_CONTAINER_ID"
test "$BEFORE_IMAGE_ID" = "$AFTER_IMAGE_ID"

The checkpoint is about evidence, not forcing every platform into identical internals. A Desktop learner can prove Docker object persistence without claiming access to the managed VM's systemd process state.

9. Document how this user is authorized to Docker

Choose the statement that matches your environment and attach evidence:

10. Required evidence packet

11. Exact cleanup and rollback

docker inspect "$LAB_CONTAINER" --format 'name={{.Name}} labels={{json .Config.Labels}}'
docker rm "$LAB_CONTAINER"
docker ps -a --filter "label=$LAB_LABEL"

printf 'finished=%s
' "$(date -u +%Y-%m-%dT%H:%M:%SZ)" | tee -a "$EVIDENCE_DIR/session.txt"

Do not uninstall Docker or delete the data root unless the entire VM itself is the disposable lab artifact and you intentionally destroy/rebuild the VM. The evidence directory is intentionally outside the Docker data root so it survives container cleanup.

12. Explain every successful state precisely

Knowledge check

13. Chapter 02 operational review

You can now install and verify Docker without collapsing software source, client, daemon, endpoint, Desktop VM, persistent data, privilege, and workload state into one checkbox. You can show where the packages or Desktop application came from, which server a client controls, how state survives restart, and why convenience access can expand privilege.

Chapter 03 moves inside the Engine boundary: dockerd, containerd, runc, BuildKit, APIs, and the container lifecycle. The version/context/data-root baseline you created here becomes the evidence foundation for understanding those components without guessing at implementation details.

Official references and version notes

Version-sensitive statements in this chapter were rechecked against primary documentation on 2026-09-20. Installation support, package names, Desktop requirements, component versions, context behavior, rootless prerequisites, and security guidance evolve. Always record the versions and platform facts actually reported by the environment you are operating.

• Install Docker Engine — supported distribution paths, release channels, package-source boundaries, and installation methods.
• Install Docker Engine on Ubuntu — current official apt-repository procedure, package names, verification, and convenience-script caveats.
• Linux post-installation steps — service startup and the warning that membership in the docker group grants root-level privileges.
• Rootless mode — current prerequisites, subordinate UID/GID requirements, user-service behavior, and limitations.
• Docker contexts — endpoint identity, switching contexts, and portable client configuration.
• Docker CLI reference — global flags and environment-variable precedence including DOCKER_CONTEXT and DOCKER_HOST.
• Docker daemon configuration overview — daemon configuration paths, preferred JSON configuration, data root, and validation.
• dockerd reference — daemon sockets, --validate, configuration conflicts, data-root, and runtime options.
• Install Docker Desktop on Windows — current WSL 2/Hyper-V/VMM installation requirements, modes, and Windows support boundaries.
• Install Docker Desktop on Mac — current supported macOS window, architecture downloads, and Desktop subscription terms.
• Install Docker Desktop on Linux — VM-backed Desktop behavior and the dedicated desktop-linux context.
• Docker Desktop release notes — Docker Desktop 4.91.0 was released 2026-09-14.
• Docker Engine 29 release notes — Docker Engine 29.8.1 was released 2026-09-15.
• Buildx releases — Buildx v0.37.1 was released 2026-09-11.
• BuildKit releases — BuildKit v0.33.0 was released 2026-09-02.
• Compose releases — Docker Compose v5.5.1 was released 2026-09-03.