Allow using wildcards in Docker-Compose network > aliases

[KevinGhadyani-minted]

Is your feature request related to a problem? Please describe.
When setting up a Proxy service in Docker-Compose, I need to always define hostnames both in my hosts file and in networks > [NETWORK_NAME] > aliases.

For instance:

• frontend.myapp.localhost
• api.myapp.localhost

I would like both domains to point at the proxy at whichever port I defined. This way, I can have multiple services running on the same port.

If my host machine targets frontend.myapp.localhost or api.myapp.localhost, because I have those domains setup in my hosts file, everything works fine.

The problem occurs when everything is behind the proxy. For instance, I'm doing server-side rendering and frontend.myapp.localhost now tries to call out to api.myapp.localhost before sending me some HTML. All of a sudden, I need to be using the docker-compose container name of api instead.

The way I fix this is by assigning aliases on the docker-compose proxy app network:

services:
  proxy:
    networks:
      proxy:
        aliases:
          - api.myapp.localhost
          - frontend.myapp.localhost

Describe the solution you'd like

1. It'd be a lot easier for me to do *.myapp.localhost instead of having to define each and every one.
2. If my proxy application could look into the directories of other apps, pull in their proxy configs, and create an alias file for docker-compose which generates the aliases property.

Either solution fits my needs, but #1 is far easier to implement. A combination of the two would be ideal because then anyone could use this proxy image and only need to ensure they're passing in a list of directories to check for configs.

Describe alternatives you've considered
Right now, I'm manually putting in every alias, but because my proxy app needs to be an independent repository, I have to manually add every possible alias by hand. In my case, that's 70+ applications to manage. If they change their URL, that's time I have to spend updating these local aliases.

Good luck to any dev that has to bisect older code in a different repo. It won't work if they changed the URL alias passed into the proxy.

[codestub]

anyone aware of a workaround for this?

[KevinGhadyani-minted]

The way I'm doing it right now is manually putting each app's URL in there.

[NAR8789]

Workaround: set up a dnsmasq container for hosting the wildcard entries, then point other containers' dns at that container.

Caveats:

• The dnsmasq container needs a static IP, to make it easy to point other containers' dns at it.
• Whatever service you're assigning wildcard names to probably also wants a static IP, to make the dnsmasq config easy to write.
• Assigning manual IPs requires also manually setting your docker-compose network's subnet.
• In order to avoid IP conflicts with auto-assigned IPs, you probably want to manually set your docker-compose network's ip_range, so that you can guaranteeably assign non-conflicting static IPs.
  • You'll also need to use composefile v2, because ip_range is not supported in composefile v3. As far as I know though, the only reason to use composefile v3 is if you want to use swarm mode. Given that v3 still lets you assign static IPs though, maybe there's a better way to avoid conflicts that I'm not aware of?

Example config: https://gist.github.com/NAR8789/92da076d0c35b434107fb4f4f198fd12

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[boomshadow]

Bump! (I didn't want this issue to get auto-closed). This feature would be extremely helpful due to the fact that our dockerized app requires knowing the domain, and it uses sub-domain based multi-tenant routing. Our work around was to put all the common URL's in the network aliases. It works but its not ideal because we have many dozens of subdomains we'd like to actually include.

Example of what we have:

networks:
  my_network:
    aliases:
      - demo.local.ourdomain.com
      - foo.local.ourdomain.com
      - bar.local.ourdomain.com
      - buzz.local.ourdomain.com

[stale]

This issue has been automatically marked as not stale anymore due to the recent activity.

[microerror]

Bump! (I didn't want this issue to get auto-closed). This feature would be extremely helpful due to the fact that our dockerized app requires knowing the domain, and it uses sub-domain based multi-tenant routing. Our work around was to put all the common URL's in the network aliases. It works but its not ideal because we have many dozens of subdomains we'd like to actually include.

Example of what we have:

networks:
  my_network:
    aliases:
      - demo.local.ourdomain.com
      - foo.local.ourdomain.com
      - bar.local.ourdomain.com
      - buzz.local.ourdomain.com

The solution posted with dnsmasq works

If you follow the steps posted by @NAR8789 then all you need to do is add the dns: ip-of-container-running-dnsmasq in docker-compose.yml

I use *.localhost tld for local development. Any container that needs to curl or ping anything that ends with .localhost correctly resolves the IP of nginx container which in turn correctly routes the request to http-processing container(s).

[boomshadow]

The dnsmasq solution is a good work-around. I'm thankful for the information as I was able to use it. As its written, it only supports docker compose v2. With a tiny modification, it can work for v3, which is a requirement for my use case.

https://gist.github.com/NAR8789/92da076d0c35b434107fb4f4f198fd12?permalink_comment_id=4137904#gistcomment-4137904

It would still be great if Docker Compose natively supported wildcard aliases though. It would alleviate this extra complexity in the compose file.

[MFAshby]

I think it's not docker-compose's issue but rather docker (or libnetwork). You can't achieve this kind of wildcard alias with plain docker CLI either.

Opened moby/moby#43442 about this same problem.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[nphmuller]

Commenting to make sure the issue won't be closed.

[stale]

This issue has been automatically closed because it had not recent activity during the stale period.

[nphmuller]

:(

[outdooracorn]

Please reopen this issue. It's still a requested feature and isn't stale.

Pinging @docker staff for visibility @glours @nicksieger @ndeloof @StefanScherer @ulyssessouza @laurazard

Edit: Please and thank you!

[stale]

This issue has been automatically marked as not stale anymore due to the recent activity.

[maoxuner]

I need this feature too. However, I think it must be a feature of docker internal dns not docker compose. moby/moby#43444

[ndeloof]

Compose just passes the aliases configuration to engine, and Compose can't offer something that the docker engine doesn't support.
Until moby/moby#43442 we won't be able to provide this feature, and if/once fixed this will be available to compose users without any extra effort.

[ndeloof]

Closing this issue as "not planned". Obviously, if moby/moby#43442 get eventually fixed, we would add support in docker compose to support this usage.