With the Docker provider, Traefik reads labels on your containers and derives routes from them. Publishing a service means describing its name, port and health alongside it, without changing the proxy. This lesson is for administrators, operators and developers running containerized services. It explains how Traefik discovers containers, why you should disable exposure by default, how to connect the proxy and backend through a Docker network, and how to distribute traffic across instances. It also shows how the proxy removes a stopped instance or one marked unhealthy by a check, then returns it to service. The lesson targets Traefik 3.7.15 and ends with an assessed lab on a virtual machine.
What you will learn
The progression starts with container discovery and follows traffic through to backend availability.
- Explain how the Docker provider turns labels into configuration
- Explain exposure policies and explicit publication
- Connect Traefik and a backend through a dedicated Docker network, without publishing a host port
- Distribute traffic across several containers for one service
- Distinguish a Docker stop from an application failure and identify the check that removes the target
- Diagnose a missing container,
404,502or504
Prerequisites
This lesson assumes you know the concepts from
Traefik: entrypoints, routers, services and
middlewares: the router selects a route, the service distributes
traffic and the provider supplies configuration. It also uses the
request-flow vocabulary from
Publishing a web service: request flow: reverse proxy, Host header, and active and passive probes.
For the practical work, know the basics of Docker Compose and how to read a YAML file, as covered in the Docker training. The lab provides its own virtual machine. Installing Traefik outside Docker (binary or package) is covered in Installing Traefik v3; certificates are covered in Traefik and automatic HTTPS with ACME.
How does Traefik discover your containers?
The Docker provider queries the Docker engine, reads each container's labels and rebuilds the configuration whenever something changes. At startup, Traefik lists containers; afterward, it listens for engine events (creation, stop and removal) and recalculates its routes. A new container can therefore be published without restarting the proxy, and a removed container leaves the configuration.
A label is a key-value pair attached to a container and stored by Docker, which does not interpret its meaning. Traefik interprets labels in its namespace to build routers and services. These are the same objects introduced in the concepts lesson; only their source changes. The provider itself belongs to static configuration, read at startup. Labels are dynamic configuration, refreshed from engine events.
By default, the provider connects to the engine through the Unix socket
/var/run/docker.sock to read containers. This file grants access to the
entire Docker API and is a sensitive point of this provider, covered
in a dedicated section below. The Swarm provider, which reads services in a
Swarm cluster, is outside this lesson's scope.
Why disable exposure by default?
A permissive exposure policy can make containers public when they were never intended for public access. The Docker provider lets you choose whether containers are discovered automatically or must be declared explicitly. An explicit policy makes publication intentional and easier to review.
The difference matters for a database, an administration tool or an internal service sharing the proxy network. With exposure enabled by default, a default rule may make such a container reachable. With an explicit policy, publication is a deliberate action visible in the Compose file. Forgetting a declaration leaves a service unavailable rather than exposed.
Not creating a route is not network isolation. Other members of a Docker network may still reach a container, even when Traefik does not publish it. Discovery and connectivity are separate controls. A sensitive service also needs a separate network that the proxy does not need to join.
Which Docker network should Traefik share with the backend?
Traefik reaches a backend through a Docker network, so the proxy and application need a shared network path. Without connectivity, the router may recognize the requested name but fail to reach the service. Docker creates a network for each Compose project, which is a common source of failures when the proxy and application belong to different projects.
A publication network limits which services the proxy can reach. Databases and internal services stay on their own networks. When a container belongs to several networks, the provider must use the one that connects it to the proxy. Compose may also prefix a network name with the project name, so check the name that was actually created before diagnosing a connectivity failure.
Publishing a port makes a container reachable from the host and, depending on the bind address and firewall, from other machines. Traefik can reach a backend on its internal network without publishing that backend's port on the host. Direct port publication bypasses the proxy's rules, so check client access and proxy access separately.
Which parts of a publication should you distinguish?
A publication combines several objects, but each answers a different question. The provider discovers containers and their metadata; the router recognizes a request; the service represents one or more instances; the network lets the proxy reach them. If a request fails, check these responsibilities in order instead of changing several layers at once.
| Element | Question to ask |
|---|---|
| Discovery | Has Traefik loaded the container's metadata? |
| Router | Does the request match a published rule? |
| Service | Is the expected backend part of the service's target pool? |
| Network | Can the proxy reach the backend over a shared network? |
This model supports diagnosis without depending on one particular example. It also prevents you from confusing a missing route with an unreachable backend: the first problem occurs before the service, the second after route selection.
How does Traefik distribute traffic across a service's containers?
Traefik distributes requests across the instances it knows for one service. The configuration must represent those containers as targets of the same service, and every target must be reachable from the proxy. An instance that is not discovered or is on the wrong network cannot join the pool.
Load balancing is simplest for stateless applications: any instance can handle a request without losing the context needed to answer it. If an application keeps an in-memory session, persistence may be necessary, but it complicates scaling and replacing an instance. Check the service's actual behavior instead of inferring it from the number of containers.
How does Traefik remove a stopped or unhealthy instance?
A stopped instance is removed after the Docker provider receives the engine event and refreshes its configuration. An unhealthy instance may still have a running container even though the application cannot serve requests correctly.
If a Docker HEALTHCHECK is configured and marks a container unhealthy, the
Docker provider excludes it from the generated service. Traefik can also run
its own HTTP health check against a backend and remove a target from
rotation. These are separate mechanisms: the first uses Docker's reported
state; the second periodically requests an application health route.
Its reaction time depends on the interval and timeout. A slow probe sends
requests to a failed instance for longer; an overly frequent probe adds load.
These checks affect routing, not the container lifecycle: they do not restart the container. Traefik can return the target to service when its health state recovers. Retries can reduce some failures, but do not fit every operation. Replaying a request that changes data may duplicate an effect.
What should you do about the Docker socket?
Mounting the Docker socket in Traefik gives the proxy power equivalent to
administrator access on the host. The Docker provider needs it to read
containers, but the same channel can create, stop or remove them. A
read-only mount (:ro) does not remove this power: it protects the socket
file, not the requests sent through it. This is a real risk for a proxy
exposed to the Internet, because a Traefik vulnerability could become host
takeover.
This lesson does not detail the mitigation. The Docker socket proxy (in French) lesson explains why a direct mount is risky and how to limit available operations on the Docker socket. The lesson Protecting Traefik places this choice among other entry-point protections. A direct mount is not suitable for an exposed deployment.
Practice: observe service availability
The lab asks you to publish a containerized service and study how the proxy behaves when its targets change state. You build your configuration on a virtual machine and check the result from a client. The lab scenario describes the task and assessment criteria; this lesson provides the discovery, networking and health model without giving you a configuration to copy.
How should you diagnose a failed publication?
Start by checking whether the provider discovered the target, then whether the router matches the requested name. If the route exists but no response arrives, inspect network connectivity and the actual listening port. Finally, compare process state with application state: a running container is not necessarily a healthy backend. Proxy and service logs help you follow these steps without changing several layers at once.
A response code is a clue, not a complete diagnosis. A 404 may indicate
a missing route; 502 or 504 point to different backend communication
problems. Check what Traefik loaded and compare it with the request it
received before changing labels or networks.
Key points
Reliable publication depends on several independent controls. Check each layer instead of changing configuration at random.
- The Docker provider turns metadata into routers and services.
- Container discovery and network connectivity are separate controls.
- Direct port publication can bypass the proxy.
- Load balancing works across known and reachable instances of the same service.
- Docker reports a stop; an unhealthy application needs a configured health check.
- The Docker socket provides powerful engine access; a read-only mount does not limit the available operations.
- To diagnose a failure, follow discovery, routing, connectivity and health.
Knowledge check
The quiz covers discovery, networking and service availability.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
Continue the course: Traefik and the file provider: publish a service outside a container
A new full quiz with random questions
Work again only on the questions you missed