Domain 2 of 4 · Chapter 5 of 7

Interpreting Docker Compose Files

Unlock the complete study guide + 1,040 practice questions across 16 full exams.

Bundled into the existing Designing, Deploying and Managing Network Automation Systems premium course — no separate purchase.

14-day money-back guarantee — no questions asked.

Included in this chapter:

  • The Compose file: top-level keys and no version
  • The image: image, build, and the Dockerfile
  • Runtime overrides: environment, command, entrypoint
  • Start order and readiness: depends_on
  • Reachability: ports, expose, and service DNS
  • Networks: the default network, membership, aliases
  • Volumes: named vs bind, persistence, read-only
  • Legacy keys, restart, and reading the stem

What each Compose key controls

Question the key answersKey(s)What it setsClassic trap
Source: what image?`image` / `build`Pull a prebuilt image, or (with build) build from a Dockerfile per pull_policy and tag itThinking image and build cannot both appear
Runtime: how does it run?`environment` / `command` / `entrypoint`Inject env vars and override the image's default commandAssuming a rebuild is needed to change behavior
Reachability: who can reach it?`ports` / `expose`Publish HOST:CONTAINER to the host, or expose internally onlyReading ports as CONTAINER:HOST
Discovery: how do peers find it?service name / `networks`Resolve by service name via embedded DNS on shared networksExpecting DNS to resolve across disjoint networks
Start order: when does it start?`depends_on`Order startup relative to peers, not readinessAssuming it waits until the dependency is ready
Storage: what does it mount?`volumes` (named / bind)Persist data in a named volume, or map a host path inBelieving `down` deletes named-volume data
Lifecycle: how is it kept up?`restart`Relaunch on exit or daemon restart per policyUsing `always` where `unless-stopped` is meant

Decision tree

B needs A before it starts? No depends_on; the app retries A is a one-shot job that must finish? One-shot finished: service_completed_successfully B needs A ready to accept connections? healthcheck + condition: service_healthy depends_on (default: service_started) No Yes Yes No Yes No
Cheat sheet

Cheat sheet

  • image pulls a prebuilt image; build builds from a Dockerfile
  • depends_on controls start order, not readiness
  • ports uses HOST:CONTAINER order
  • environment and command override image defaults
  • Services resolve each other by service name
  • Dockerfile core instructions and CMD vs ENTRYPOINT
  • A default project network connects all services
  • A service resolves only on networks it joins
  • Network aliases and multi-network services
  • Custom networks are declared at the top level
  • Named volumes vs bind mounts
  • Named volumes need a top-level declaration
  • Volume data survives down, not down -v
  • Read-only mounts protect host files
  • links are legacy and not required for discovery
  • links can create a network alias
  • The Compose Specification dropped the version key
  • restart policy keeps services alive

Unlock with Premium — includes all practice exams and the complete study guide.

References

  1. Compose file reference (Compose Specification top-level elements)
  2. Compose file: Version and name top-level elements
  3. Compose Build Specification (build + image, pull_policy)
  4. Dockerfile reference (FROM, RUN, COPY, EXPOSE, CMD, ENTRYPOINT)
  5. Define services in Docker Compose (environment, depends_on, ports, expose, aliases, links, restart)
  6. Control startup and shutdown order in Compose
  7. Networking in Compose (default <project>_default bridge, embedded DNS, network membership)
  8. Docker Engine networking (embedded DNS server at 127.0.0.11)
  9. Compose file: networks top-level element (driver, external)
  10. Docker volumes (named, Docker-managed persistent storage)
  11. Docker bind mounts (host-path mounts, read-only)
  12. Compose file: volumes top-level element
  13. docker compose down (keeps named volumes; -v removes them)