Add option to remove service name as default alias on networks

[randombk]

(Copied from https://forums.docker.com/t/add-option-to-remove-service-name-as-default-alias-on-networks/106172 after I realized this was a compose-specific request)

I am facing an issue where two separate docker compose projects sharing a common externally defined docker network would encounter DNS name collisions when both projects have a service with the same name.

Example Setup:

project1/docker-compose.yml:

version: '3'

networks:
  app_internal:
    driver: bridge
  shared:
    external:
      name: shared_network

services:
  database:
    ...
    networks:
      app_internal:
      shared:
        aliases:
          - project1-database

project2/docker-compose.yml:

version: '3'

networks:
  app_internal:
    driver: bridge
  shared:
    external:
      name: shared_network

services:
  database:
    ...
    networks:
      app_internal:
      shared:
        aliases:
          - project2-database

Problem:

shared_network is an externally created docker network common to both project1 and project2. When I spin both projects up, both the project1_database_1 and project2_database_1 containers are aliased to database on shared_network, in addition to the custom aliases provided.

Making things worse, when I try to communicate with database on other containers in project1 or project2 who are also connected to shared_network, it's a tossup whether I'll be talking with project1_database_1 or project2_database_1 .

Desired Outcome for Example:

• The only aliases project1_database_1 and project2_database_1 should be known by on shared_network are the custom aliases provided.
• From within project1:
  • The DNS for database should always point to project1_database_1 over the project1_app_internal network
  • The DNS for project1-database should always point to project1_database_1 over the shared_network network
  • The DNS for project2-database should always point to project2_database_1 over the shared_network network
• Ditto for project2

Feature Request:

Currently, the problematic behavior occurs because of this interaction in the Docker-compose documentation:

Other containers on the same network can use *either* the service name or this alias to connect to one of the service’s containers. (emphasis mine)

I would like to have an option at either a service level or a network level to tell Docker Compose not to add the service name as an alias when attaching a network.

[randombk]

In short, I'm looking for a flag that would toggle the logic in

compose/compose/service.py

Lines 805 to 810 in 5b7851f

	def _get_aliases(self, network, container=None):
	return list(
	{self.name} |
	({container.short_id} if container else set()) |
	set(network.get('aliases', ()))
	)

into something that looks more like

 def _get_aliases(self, network, container=None): 
     return list( 
         ({container.short_id} if container else set()) | 
         set(network.get('aliases', ()) or [self.name]) 
     ) 

where it would only use the configured aliases if present and non-empty, and default to the service name if no custom aliases are provided.

[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.

[marekkon]

I really like the idea of breaking the website name in definition from the host name on a shared network and this functionality would be very helpful.

I also have a second scenario where I would see this functionality. When I work on several branches using worktree, I wish I could switch to another branch without having to turn off the containers of the other branch. Currently, it is not possible, especially since the definition of these services is almost identical.

An additional, huge advantage would be the ability to define / overwrite these aliases in the override file.

[stale]

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

[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.

[randombk]

I'd like to keep this alive.

This issue is still a problem on the latest release, and no effective solution is available.

[stale]

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

[theothermatt]

I'm seeing exactly this too, and it took me a while to track down, since I assumed that if I provided a list of aliases the automatically generated ones wouldn't be present. Is there anywhere in the documentation that states that the generated aliases will still be added in addition to the ones specified explicitly?

[anttivikman]

While there is a workaround for this "just don't use same names". It's annoying since it requires you to be aware of the names used in different stacks (when you have generic router that routes traffic domain based to multiple stacks). This seems like relatively small development effort, that would significantly ease up our DevOps. I'm talking about use case in Swarm mode.

[a-parser]

any workaround on this issue?

[timephy]

Hey, i am facing the same issue.
I guess the easiest workaround for me would be using a generic service name, and then alias it to a specific name in the internal network (which will hopefully never appear in the public network)...

[tmo1]

I just ran into this - see my write-up at Stack Overflow. I certainly think that the feature requested here and / or better documentation and warnings would be desirable.

[crossdot]

Just got the same problem

[bd781n]

version: '3'

networks:
app_internal:
driver: bridge
shared:
external:
name: shared_network

services:
database:
...
networks:
app_internal:
shared:
aliases:
- project1-database