同Docker bridge网络容器无法通过别名访问，仅能IP连接的问题问询

1. 同网络容器为何无法通过服务名连接？ #

可能的原因包括以下几点：

• 容器别名/名称配置问题：默认bridge网络的DNS解析依赖容器的--name参数或network-alias设置，可通过docker inspect local-mysql查看NetworkSettings.Networks.bridge.Aliases字段，确认local-mysql是否为该容器在默认bridge网络中的有效别名/名称。
• 默认bridge网络的DNS限制：默认bridge网络的DNS解析能力弱于自定义网络，且容器必须通过--name显式命名才能被解析，若容器是通过compose默认生成的名称加入网络，可能无法被识别。
• 容器内DNS配置异常：检查local-app容器内的/etc/resolv.conf，确认是否指向Docker内置DNS服务器（通常为127.0.0.11），若使用主机DNS则无法解析容器别名。
• 拼写或运行状态问题：确认连接字符串里的local-mysql拼写无误，且local-mysql容器处于正常运行状态。
• DNS缓存影响：容器内的DNS缓存可能导致解析失败，尝试重启local-app容器解决。

2. 使用容器别名与IP的区别是什么？ #

• 灵活性差异：容器别名（服务名）通过Docker DNS动态解析，容器重启、重建后IP变更时，别名依然有效，无需修改连接配置；容器IP是临时分配的，容器重启后大概率会变化，每次都要更新连接地址。
• 维护成本：别名是逻辑标识，比如local-mysql比一串IP地址更直观，便于维护和理解；IP是物理网络地址，无语义，不利于长期维护。
• 依赖条件：别名依赖Docker内置DNS服务，DNS异常会导致解析失败；IP直接跳过解析步骤，只要网络连通就能连接，但缺乏灵活性。
• 多标识支持：一个容器可通过--network-alias在同一网络设置多个别名，适配不同访问场景；单个容器在一个网络中通常只有一个IP地址（除非配置多网卡）。

3. 不同docker-compose.yml中的服务如何使用links？ #

首先明确：links是Docker旧特性，官方更推荐使用自定义共享网络实现跨compose服务通信，若一定要用links，可按以下步骤操作：

1. 创建共享自定义网络：手动创建供多个compose项目共享的网络：

   docker network create shared-docker-net
   

2. 将各compose服务加入共享网络：在每个docker-compose.yml中，将需要通信的服务配置到该共享网络：

   version: '3'
   services:
     service-a:
       # 其他配置项
       networks:
         - shared-docker-net
   networks:
     shared-docker-net:
       external: true
   

3. 配置links（可选）：在需要连接其他compose服务的容器中，通过links指定目标服务名称，但实际上使用共享自定义网络后，直接用服务名即可解析，无需额外配置links——自定义网络自带跨服务DNS解析功能，比links更可靠。

注意：links仅会在容器/etc/hosts中添加静态条目，无法自动适配容器IP变化，而自定义网络的DNS解析会同步IP变更，因此更推荐用自定义网络替代links。

内容的提问来源于stack exchange，提问作者José Victor