Skip to content

Docker and Labels

Documented only. This chapter was not run. The lab sandbox has no Docker, so nothing here was executed the way chapters 4 to 8 were; it follows the project's official documentation, and criteria.md records that plainly. What is verified is everything the chapter rests on: the Docker provider produces the same routers, services and middlewares the file provider does — only their source differs.

The file provider's folder is a fine place to describe services that sit still. Containers do not sit still: they start, stop, get replaced by newer images, and change addresses. The Docker provider watches Docker itself. When a container starts, Traefik reads its labels — key/value pairs set at creation — and builds the same objects you have been writing by hand. When the container stops, its routes disappear. Nothing is restarted, including Traefik.

The shape of it

Static configuration turns the provider on and states the default posture:

providers:
  docker:
    exposedByDefault: false

exposedByDefault: false is the setting that matters: containers are not routed until a label opts them in. The alternative — every container published the moment it exists — surprises everyone exactly once.

A container then describes its own site in labels, in the Compose dialect most readers will meet:

services:
  fern:
    image: example/fern:latest
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.fern.rule=Host(`fern.test`)"
      - "traefik.http.routers.fern.entrypoints=web"
      - "traefik.http.services.fern.loadbalancer.server.port=9001"

Read it against chapter 4: router fern, a Host rule, an entrypoint, and the one new fact — the port inside the container, which Traefik cannot guess when a container exposes several (or publishes none). Middleware labels (traefik.http.middlewares...) and TLS labels follow the same grammar; the whole dynamic vocabulary translates, at the cost of living in strings inside another file's strings — the quoting in real Compose files is the fiddliest part of the Docker workflow, and the dashboard (chapter 8) is how you check what Traefik made of them.

The networking fact everyone trips on

Traefik must be able to reach the containers it routes to. Run in Docker itself (the usual arrangement), Traefik joins the same Docker network as the services and addresses them by container name over that network — the published ports on the host are not the path traffic takes. Run as a host binary against Docker, it needs the Docker socket and network access to the containers' addresses. Either way, "the container is up and I can curl it on its published port" does not prove Traefik can reach it; the 502s of chapter 15 are where that difference surfaces.

File or Docker: choosing

  • Containers that come and go — Docker provider; the labels travel with the service's own definition.
  • Services outside Docker — the file provider; Traefik cannot label what Docker does not run.
  • Both at once is normal: providers coexist, each contributing its own objects, distinguished by the @docker and @file suffixes of chapter 2.