Docker环境下.NET Core API无法连接容器内SQL Server 报名称解析错误

从异常栈最底层的未知的名称或服务可以直接判定问题根源：运行API的容器根本无法通过配置的sqlserver主机名解析到SQL Server容器的内网IP。这不是SQL Server的密码、端口、远程访问权限配置问题——你能从本地SSMS通过localhost,1433正常登录，就说明SQL Server容器本身的启动、端口映射、认证配置都是正常的。

Docker Compose 会为同一份配置文件下的所有服务，自动创建一个专属桥接网络，网络内的容器可以互相通信，但内置DNS只识别配置文件里定义的「服务名」，不识别你给容器手动设置的hostname值：

• 你在compose里给SQL Server定义的服务键名是sqlserverService，这才是Docker DNS能识别的合法主机名
• 你手动给容器设置的hostname: 'sqlserver'，仅在容器内部的系统环境生效，其他容器发起请求时，查询Docker内置DNS根本找不到sqlserver的解析记录，自然抛出名称解析失败的错误。

• 最省事的改法：把连接字符串里的服务器地址，从sqlserver,1433改成compose里实际定义的服务名sqlserverService,1433，不需要调整其他配置，重启API服务就能正常连通。
• 如果不想改动现有连接字符串配置，可以直接把compose里的SQL Server服务名从sqlserverService改成sqlserver，这样Docker DNS就能直接匹配到连接字符串里写的主机名，零改动连接配置适配。
• 若想完全保留当前compose的服务名不动，可以在SQL Server的服务配置块下，给网络添加sqlserver作为服务别名，让Docker DNS同时把sqlserver解析到这个容器，适配现有连接字符串。

• 容器网络地址的规则差异：你从宿主机用SSMS连SQL Server时用的localhost,1433，是因为配置了端口映射把容器的1433端口暴露到了宿主机；但容器内部的localhost指的是API容器自身的网络栈，不是宿主机，也不是同网络的其他容器，绝对不能把连接字符串里的服务器地址改成localhost,1433，否则会尝试连接API容器自己的本地端口。
• 修正数据目录挂载错误：你当前配置的卷挂载是./data/mssql:/var/opt/mssql3，而mssql官方镜像默认的数据存储路径是/var/opt/mssql，你挂载的路径根本不是SQL Server实际使用的目录，会导致所有数据库配置、数据在容器重启后全部丢失，应该把挂载目标路径改成/var/opt/mssql。
• 连通性验证方法：改完配置后，可以进入API容器的交互终端，执行nslookup 你最终使用的主机名，如果能返回正常的容器内网IP，就说明DNS解析正常，再测试数据库连接就不会出现名称解析错误。

内容的提问来源于stack exchange，提问作者Robert