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?

I'm interested in it too. I would like to have a custom error page for a stopped container. and it only works if the container is running or unhealthy. If the container is stopped, I just get a simple 404.

It's been a while!

I've reworked this all from scratch.

Basically all it does now is that the container status is now reported in the structure dockerData, which is then used to return a nil server if AllowEmptyServices is set to true.

We can talk about having a dedicated field for that feature specifically, but in my opinion this is what the feature is supposed to be.

AllowEmptyServices is about allowing services that are empty to be registered by Traefik, which is shown like that in the UI:

It returns a 503 no available server as expected, and you can have a middleware in front catching the request and do whatever you want with it.

Any news @rtribotte ?

Hi @acouvreur, sorry for the late reply.

We have given some more thought to changing the behaviour of the allowEmptyServices option and have come to the conclusion that we cannot introduce a breaking change.
In fact, exposing stopped containers from now on could lead to conflicting exposed routers, where the empty service router can take precedence over one with active service, and thus breaking some setups.

Also, as mentioned above, the lack of service definition in Docker is the a blocker to considering a stopped container as defining a service.

So we do not think that using this option in your use case is the best option.

However, we think the ability to discover a stopped container could be an opt-in feature per container by introducing a new label, WDYT?

@rtribotte Thanks for your answer. Just to be sure to understand correclty, your proposition is to keep the PR of @acouvreur but with an additionnal config or label parameter like "visibleWhenStopped" with default value to false ?

Can't believe it finally happend... Thank you all. I'm excited to test it out when it's available

Can't believe it finally happend... Thank you all. I'm excited to test it out when it's available

Crazy right? A year and a half in the making

I've just tested to start a single container.