为什么 docker-compose 允许不同 project 的 service name 重名?

我自己会手动加一个 container_name:

dns 127.0.0.11 应该是一个假服务器吧，per service 的

因为实际的容器名会是两者组合 projectName_serviceName ，不存在实际的重复

只有 compose 内部网络可以通过 service name 访问，实际上的容器名会加上 project name ，而且默认并不在一个网络底下，完全没有影响

@coosir
@ByteCat
会加 project name 我知道。我疑问是既然用 service name 作为其中一种 dns 解析，为什么不限制唯一性。
是不是用 container name 作为主机名去通信更合理一些？ docker 是两种都提供了，而且 depends on 这些配置依赖的又是 service name ，不是 container name ，不太理解这个设计初衷。

@kyonn 因为当初的设计，docker compose 设计是部署在 docker swarm 上的，都默认 service 不会只有一个 instance ，数量是可以 scale 的

@kyonn 楼上不是说了吗，不同的 compose 是不同的网络，网络内部就是唯一的。为什么要额外添加心智负担？

@huihuimoe 复数个同名的 service 作用是? 引用某个 service, 这个 service 部署了好几个实例, 根据 dns 解析自动负载均衡?

@twofox 一般不会每个容器独占一个网络. 大部分容器可能都在一个网络下, 不同容器都可能用了某个数据库容器, 这时候如果出现 servcie 同名就比较奇怪, 根据我的试验, 也能正确连接到复数个 db 中正确的那个, 其他的 db 实例上会出现鉴权错误的问题.

@huihuimoe compose 和 swarm 是两个相互独立的项目吧？

因为 docker compose 本来就更适合于单机场景，通常一个 compose 文件一个网段，此时 service_name 是唯一的，不存在冲突。

```bash
networks:
net:
driver: bridge
external: false
ipam:
config:
- subnet: 172.19.0.0/24
...
...
```

如果你不指定 container_name ，通常会加上 project_name 前缀，和 index 后缀，swarm 也类似，用户完全不需要关心 container_name ，swarm 随机生成。

至于为什么不建议指定 container_name ，主要是不利于 scale ，非常不灵活。话说回来，有 scale 需求的，一般都上 K8s 了。

@COW 一般怎么个 scale 形式呢? 能否举个例子. 用同名 service name 相互代替? 还是负载均衡?

@kyonn #12 负载均衡，不过通常很少直接在 compose 里用 scale ，会集成 swarm 或者用 k8s 来实现

@COW 了解了, 多谢.