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

[kyonn]

如题. 容器之间可以通过 service name 通信,依赖于 容器启动时自动注册了 service name 为条目的 dns 记录. 那么为什么 允许不同项目的 service name 相同呢?

相同自定义网络下, 通过 container name 也是可以通信的, nslookup 也能查到 dns 记录, 是否使用 container name 作为通信主机名更好? 毕竟 container name 不允许重复?

如果是 k8s 编排容器, 一般是使用什么作为主机名通信?

[importmeta]

我自己会手动加一个 container_name:

[julyclyde]

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

[coosir]

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

[ByteCat]

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

[kyonn]

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

[huihuimoe]

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

[twofox]

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

[kyonn]

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

[kyonn]

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

[julyclyde]

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

[COW]

因为 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 了。

[kyonn]

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

[COW]

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

[kyonn]

@COW 了解了, 多谢.