Using dynamic traefik labels in docker.compose.yml (e.g., .Task.Slot)?

Is it possible to use dynamic information from docker when creating the labels used by traefik? I've experimented with trying the following inside a service definition:

# sassfs backend service
      endpoint_mode: dnsrr
      mode: replicated
      replicas: 3
        failure_action: pause
      - TASK_SLOT={{.Task.Slot}}
      - 'traefik.enable=true'
      - 'traefik.http.middlewares.sassfs_be.stripprefix.forceslash=false'
      - 'traefik.http.middlewares.sassfs_be.stripprefix.prefixes=/${TASK_SLOT}'
      - 'traefik.http.routers.sassfs_be.entrypoints=http_alt'
      - 'traefik.http.routers.sassfs_be.rule=PathPrefix(`/${TASK_SLOT}`)'
      - ''

but ${TASK_SLOT} ends up evaluating to the empty string (running docker inspect on the container shows the TASK_SLOT set in the environment, but the labels end up being '/' indicating it wasn't available when it was evaluated.

What I'm trying to do is use traefik to access specific instances of a docker service. For example if I have 3 replicas of a container image running for a service, in some cases I need to be able to get at a specific container to inspect it (this would be for things like gathering performance statistics or debugging).

As a follow-up: what I'm really trying to accomplish is a way to use traefik to allow me to access specific instances of a docker service. To anyone who comes at me and talks about "cattle not pets" you still sometimes need to check the temperature of one of your cattle, you don't just shoot it in the head if you think it might be sick.

I think the only way you could achieve this is by using stickiness, which in turn changes the behavior of the entire router.

I suppose you could make another router on this service just to do this function.

Did either of you have any luck achieving this?

No, I didn't see any way I could accomplish the goal of a single traefik instance that could dynamically route to specific containers by name. The only way I could think to use stickiness would require a client capable of collecting and examining the cookies, which didn't seem useful for my use case.

Someone on the Docker Swarm slack channel did point out that there is a Pull Request to address the problem of not being able to register the container hostname with the dns resolver: which I think would give me a path forward.

For now I'm stuck with my current solution, which is just using haproxy and hashing on the incoming hostname of the request so that each unique hostnames gets routed to a unique backend, w/o control over which one that it is.

A Im just looking how to implement that with traefik, I have a modification for dockercloud-haproxy project which just implement that and I am using it in production.
O modification of stickiness could work if instead of using IP to locate servers in pkg.server.service.service or pkg.server.service.loadbalancer.wrr, use hostname, for example for:

    image: traefik/whoami:v1.6.0
    hostname: whoami-{{.Task.Slot}}

instead of storing in SessionCookie:


a valid option in swarm could be:


Any tip to modify Traefik source code and submit a PR?
Best regards, Marcelo.

I have an initial implementation of sticky functionality with {{.Task.Slot}} support, with only two file changes is possible to route to an specific task setting the cookie value. For example:

version: '3.6'

    image: alpine
    command: tail -f /dev/null
      - lb_network

    image: traefik/whoami:v1.6.0
    hostname: "{{.Service.Name}}-{{.Task.Slot}}"
      mode: replicated
      replicas: 3
        - traefik.enable=true
        - traefik.constraint-label=traefik-public
        - traefik.http.routers.whoami.rule=Path(`/whoami`)
        - traefik.http.routers.whoami.priority=10

and an URL call like:
$ curl -v --cookie "StickyCookie=" --resolve
will route to the Task Slot 1, if you change the cookie value to it will be routed to Slot 2.
File changes by now are:

mochoa@pocho:~/docker/traefik$ git status
On branch master
Your branch is behind 'origin/master' by 15 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   pkg/provider/docker/config.go
	modified:   pkg/provider/docker/docker.go

It support wildcard for {{.Task.Slot}}, {{.Service.Name}} and {{.Node.ID}} last is used with service deployed in global mode.
Cookies now look like:
Cookie: StickyCookie=
Next, I am trying to implement that if StickyCookie is empty, it will be filled at first call using the URL call, once I have this func working I'll submit a PR on GitHub.