Docker Compose#

Docker Compose is a central tool throughout this DevOps/Docker course, used both to drive the course build pipeline itself and as the subject of exercises (TP12, TP12-BIS). The primary teaching material is in content/chapitres/compose.adoc.

The repository contains six Compose files across different contexts:

The version: Key — Deprecated#

The top-level version: field in Compose files is obsolete as of the Compose Specification. Modern Docker Compose (v2, the docker compose plugin) ignores it with a warning; it exists only for backward compatibility with the old docker-compose v1 standalone binary.

In this repo: Five of the six Compose files omit version: entirely, following current best practice. The single exception is the bonus Dependabot example, which declares version: "3.8" — inherited from the upstream Dependabot-GitLab project and flagged here as a legacy pattern.

What to do when you see version::

• If you control the file, remove the line. No other change is needed.
• Modern docker compose will emit a warning like:
  the attribute 'version' is obsolete, it will be ignored, please remove it to avoid potential confusion
• Do not use version: in new files written for this course or any exercises.

The course slides illustrate the correct, version-less format: every docker-compose.yml snippet in compose.adoc that is authored from scratch begins directly with services: 1.

BuildKit Integration and COMPOSE_DOCKER_CLI_BUILD#

COMPOSE_DOCKER_CLI_BUILD — Also Deprecated#

COMPOSE_DOCKER_CLI_BUILD=1 was historically needed to make Docker Compose v1 delegate build to the Docker CLI (and therefore to BuildKit) instead of its own legacy builder. With Docker Compose v2 (docker compose plugin), BuildKit is the default backend; the variable is no longer needed and is silently ignored.

Both Makefiles in this repo still set it for backward compatibility:

• Root Makefile: DOCKER_BUILDKIT ?= 1 and COMPOSE_DOCKER_CLI_BUILD ?= 1, both exported.
• content/code-samples/compose/cours/Makefile: identical pattern.

The Makefile comment explains the intent: "Docker Buildkit is enabled for faster build and caching of images" 2.

BUILDKIT_INLINE_CACHE#

The two pipeline-related Compose files pass BUILDKIT_INLINE_CACHE: 1 as a build argument 3. This tells BuildKit to embed cache metadata directly in the produced image layers, enabling layer reuse when the image is pulled elsewhere (e.g., in CI). This argument remains valid and useful with Compose v2 + BuildKit.

Current recommendation#

Key Compose Patterns Used in the Course#

The following patterns appear in the course Compose files and exercises — refer to the primary sources for full examples:

• YAML anchors (& / * / <<:) — The course build Compose file defines a x-slides-base anchor to share build config (context, BUILDKIT_INLINE_CACHE, environment, user, volumes) across the serve, build, and qrcode services. The slides explain this in detail 4.

• depends_on with conditions — The course covers three conditions 4:

  • service_started — container has started (no readiness guarantee)
  • service_healthy — container passed its healthcheck
  • service_completed_successfully — one-shot init container finished; used between qrcode → build → pdf in the pipeline

• healthcheck — Defined inline in Compose or inherited from the Dockerfile HEALTHCHECK instruction. The Dependabot example shows curl-based health checks with interval, timeout, retries, and start_period.

• Missing tools in healthchecks — The course dedicates a full section to diagnosing ExitCode: 127 (command not found) when the health-check binary is absent from slim/alpine images 4. Solutions: install the tool in the Dockerfile, use a native alternative (wget --spider, /dev/tcp), or use a runtime built-in (python -c, node -e).

• Profiles — profiles: groups services so only a named subset starts with docker compose up --profile <name> 4.

Primary Sources#