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.