first draft that allows non-running containers to be retrieved using allowEmptyServices

[acouvreur]

…allowEmptyServices

What does this PR do?

This PR is a draft attempting to change the allowEmptyServices capabilities to the Docker provider by allowing non running containers to be discovered.

Motivation

Non-running containers not returning 404, but 503 instead and having the full middleware chain built and executed on requests.

#9907

More

• Added/updated tests
• Added/updated documentation

Additional Notes

Test it yourself:

services:
  traefik:
    image: traefik:local
    command:
      - --entryPoints.http.address=:80
      - --providers.docker=true
      - --providers.docker.allowEmptyServices=true
      - --log.level=DEBUG
    ports:
      - "8080:80"
    volumes:
      - '/var/run/docker.sock:/var/run/docker.sock'

  whoami:
    image: containous/whoami:v1.5.0
    labels:
      - traefik.enable=true
      - traefik.http.routers.whoami.rule=PathPrefix(`/whoami`)

1. Pull this PR
2. make
3. docker build -t traefik:test .
4. docker compose up
5. docker compose down whoami
6. curl http://localhost:8080/whoami -> Error 500, but we want a 503 in the end.

You can add any middleware, and they will get exectued, which is the most important part.

[rtribotte]

Hello @acouvreur,

Thank you for this contribution!

The extension of the Docker provider allowEmptyServices option to include stopped containers could have a side effect that does not exist with other providers, or at least not the same meaning.

As the service definition with a docker container isn't a really "thing" (at most a docker-compose service), that Traefik can read and rely on, multiple stopped containers providing different dynamic configurations for the same resources (routers, middleware, etc...) can co-exist, which will result as being in error and dropped because of conflicting configurations found.

With docker-compose, this is mitigated if the service name never changes, as the stopped containers for the service are cleared.

With other providers, the service definition is what Traefik uses to create the configuration, and because this is not possible with Docker, I am wondering if this behavior should be controlled with the same allowEmptyServices option, WDYT?

[aless3]

Hello @acouvreur,

Thank you for this contribution!

The extension of the Docker provider allowEmptyServices option to include stopped containers could have a side effect that does not exist with other providers, or at least not the same meaning.

what about making allowEmptyServices a flag with 3 states? like on/off/also stopped or something like that? I don't know how go treats booleans and I don't know if this is feasible.
Or maybe another variable like allowStoppedServices? defaulting to off to not break existing workflows and basing this pr on that instead of allowEmptyServices?

As the service definition with a docker container isn't a really "thing" (at most a docker-compose service), that Traefik can read and rely on, multiple stopped containers providing different dynamic configurations for the same resources (routers, middleware, etc...) can co-exist, which will result as being in error and dropped because of conflicting configurations found.

well, making the default behavior with allowEmptyServices=true the same as now, and adding a way to allow users to "opt in" to the behavior of this pr, wouldn't this be an user error more than a traefik error?