Allow to route to invididual containers (e.g. variable substitution in frontend.rule)

[djtm]

Summary

Traefik changed the default frontend rule from Host:{containerName}.{domain} to Host:{service}.{project_name}.{domain} (see #1235). This breaks setups and makes some setups very difficult or impossible (e.g. see #1787): You can't easily attach to individual container. You'd need a manual frontend rule for each container. Or each container would need it's own service name.

Possible solutions

• Revert change - bad, would break new setups
• Allow manual reverting of the change via config - easy, but limited fix
• Combine both rules: add Host:{containerId}.{service}.{project_name}.{domain} (Rancher: Host:{containerId}.{serviceName}.{domain}) for invidual container and Host:{service}.{project_name}.{domain} (Rancher: Host:{serviceName}.{domain}) for a group of containers. Exposing individual containers could be a config flag: traefik.<service-name>.exposeIndividualContainerBy=<id|name|false>
• Allow variable name substitution for variables such as {containerName} {containerId} {service} {projectName} {domain}. traefik.frontend.rule=Host:{containerName}.{domain} would actually work as expected.

What did you do?

I've set a label: traefik.frontend.rule=Host:{containerName}.{domain}
My container is called sampleName, my domain is sampleDomain

What did you expect to see?

A route to sampleName.sampleDomain.

What did you see instead?

A route to {containerName}.{domain}.

[djtm]

Actually personally I'd want this in rancher. But docker would be nice, too, of course.

[redsux]

Hi,

It could be a nice feature !
For the moment I use a workaround with environment variables substitution in docker-compose...

I'll try to custom config_container.go on a fork.
If it works I'll send a PR.

Regards,

[aantono]

A templating of default FrontEndRule solution has been implemented for Consul Catalog provider via #1565, so a same pattern/approach can be taken here as well. See getFrontendRule

[warroyo]

i noticed this issue upgrading to 1.5.x from 1.4 . this really needs to be configurable at a global level. currently we have integrations with the old naming and 1.5 breaks this.

[sarahconor]

I have been also stuck at 1.4, also require a global setting (essentially backwards compatible). I wanted to upgrade to 1.5.x to leverage the backend http basic auth.

[djtm]

It seems rancher does not expose the individual containers but only services with containers in them:
https://github.com/containous/traefik/blob/0ea007b26f394013d18d6a3b39305743a7f73be4/provider/rancher/rancher.go#L51

So I think the config would need to split up the individual containers from service.Containers and then get their information. But containers only contains and IP address if I read the code correctly. So it seems to be a problem with the metadata supplied by rancher that it doesn't provide more information about individual containers in a service. However at least in V2, it seems complete information about the containers should be available:
https://rancher.com/docs/rancher/v1.6/en/rancher-services/metadata-service/

[jaydansand]

Thanks for all the work y'all do, Traefik is great and I want to keep using it, but.. this issue seems to have stalled since April, and I arrived here from Google because I, too, am getting stuck with Traefik 1.5+.

I'd love to be able to set a global default pattern such as Host:{containerName}.{domain}, or even do that per-docker-compose.yml so we can juggle co-running development versions with different container names or domains without having to hard-code every host in every containe everywhere. It's not portable or maintainable (for us).

[SeanHood]

I have a different use case for this feature. I'd like to run a number of services within a single stack accessible via a different Path: rule. Currently I have to set each service with the same Host: rule which is okay if I maintain a separate file for each stack or invent some hack with environment variables. Use case would be to have a single compose file that would enable us to spin up a new stack for each PR for testing.

Here's a quick example (Invoked with: docker stack deploy -c compose.yml dev):

services:
  app:
    image: app
    deploy:
      labels:
        - "traefik.frontend.rule=Host: dev-app.example.com"
  api:
    image: api
    deploy:
      labels:
        - "traefik.frontend.rule=Host: dev-app.example.com"; PathStrip: /api/"

What I'd like to do:

services:
  app:
    image: app
    deploy:
      labels:
        - "traefik.frontend.rule=Host: Host:{project_name}-{service}.{domain}"
  api:
    image: api
    deploy:
      labels:
        - "traefik.frontend.rule=Host: Host:{project_name}-{service}.{domain}"; PathStrip: /api/"

---

I'm aware this isn't a support forum but it's vaguely related to this. All of my Host rules come up like Host:{project_name}-{service}.{domain} rather than Host:{service}.{project_name}.{domain} contrary to what is suggested in #1235. And I'm not sure why. (Traefik v1.7.2 using traefik:alpine)

[wtatum]

I'm also interested in this feature. I'd love to stick to the default generated names but for my organization dealing with multiple levels of nested hostnames below the root name makes dealing with SSL certs and hostnames quite a bit more difficult. The option to use a pattern like Host:{project_name}-{service}.{domain} would make it pretty easy to throw a wildcard cert and wildcard DNS rule on a development server and "call it a day". The current default makes sense, but also makes a little more work for IT/devops, so an option to modify it would be really helpful.

[Gaff]

As a cheap solution, traefik could allow HostPrefix in the same way that it allows PathPrefix. It's probably going to work for many use cases?

[tfny]

Hey y'all, as we do not support version one anymore, I am going to close this issue. Thanks!