Command: --providers.docker.constraints seems to have no effect

In my traefik.yml file, I can get constraints working as they used to in traefik v1 with this snippet:

    constraints: "Label(`traefik.tags`, `branch-local`)"

I can see the behaviour I expect and anything without the branch-local tag is not handled by this traefik instance. I see debug output as I would expect, such as:

branch_proxy.1.gw5yrkatssko@docker-desktop    | time="2020-03-14T10:58:17Z" level=debug msg="Container pruned by constraint expression: \"Label(`traefik.tags`, `branch-local`)\"" providerName=docker container=other-example-uuuvg811inqtdlyt1g0yvtm53

The constraints mechanism clearly works as it should, however, I can't use the yml file. I need to set the branch-something value dynamically from a build/deployment variable, not in my yml file, which is in a docker config; so, I need to do it in my docker-compose file.
If I add the following (similar to how we did in v1, and according to the new docs), it appears to be ignored):

    image: traefik:cantal
    command: --providers.docker.constraints="Label(`traefik.tags`,`branch-${NETWORK}`)"

If I go into the container and do a ps, I can see that the command is being correctly passed to the process command line:

    1 root      0:09 traefik traefik --providers.docker.constraints=Label(`traefik.tags`,`branch-local`)
   28 root      0:00 /bin/sh

All of the running docker services, however, now go to this traefik instance, and we no longer see the filter messages in the log.

Correction to previous self-reply. I had thought that the TRAEFIK_PROVIDERS_DOCKER_CONSTRAINTS environment variable was working but this is not the case (I had inadvertently left in the yml constraint from my testing). The environment variable also seems to have no effect. I have confirmed that the variable is also set:

/ # set | grep TRAEFIK


There are three different, mutually exclusive (e.g. you can use only one at the same time), ways to define static configuration options in Traefik, so you have to use only one.

Right, so they are mutually exclusive at the global level, i.e. if you use a single command line option, you can't use any environment variables. This wasn't clear from the documentation and I'd assumed the mutual exclusion was at a more granual level. This is now clear (although not very helpful). I can't see why it couldn't mix them sensibly, as most installations are likely to have a number of static options that rarely change and are much better expressed in a config file and a few dynamic requirements. I now have to take a nicely structured 20-line yml file, that is easy to read and edit, and translate it to 20 command line switches.
Perhaps something to think about for a feature request.
I do have a couple of other related feature requests. Where is the best place to put these?

1 Like

Also, it worked well this way in v1.