一个徽章背后的工程陷阱：我们怎么被/etc/resolv.conf击败两次|conf|dev|dns|resolv|工程陷阱|徽章|端口

GitHub上那个"在开发容器中打开"的徽章，可能是开发者工具里性价比最高的功能。用户点一下，等Docker拉完镜像，工具就直接跑起来了——不用装依赖，不用配证书，不用查端口占没占。从"有点意思"到"真在用"，中间只隔了一个镜像下载时间。

但把这个体验做出来，要踩的坑完全没写在文档里。这篇文章记录我们给Topaz做开发容器的过程：三个服务怎么塞进Docker Compose，为什么两次DNS方案都被/etc/resolv.conf干掉，以及最终跑通的架构长什么样。

Topaz是个单文件程序，模拟Azure的全套服务：存储、密钥库、服务总线、事件中心、容器注册表、托管身份、RBAC、ARM、Entra ID。开发容器的目标很简单：用VS Code打开仓库时，Topaz Host已经在跑，所有服务端口可达，TLS证书可信，*.topaz.local.dev能解析——全程零手动配置。

最终要实现的终端效果是这样的：敲topaz health返回健康状态，用curl https://topaz.local.dev:8899/health能通，甚至curl https://my-vault.vault.topaz.local.dev:8898/secrets也能直接拿到响应。后两条命令用主机名而不是IP，这就是最棘手的工程问题。

架构上用了Docker Compose模式，VS Code的Dev Containers扩展原生支持。三个服务：devcontainer（VS Code工作区容器）、topaz（Topaz Host边车）、dns-sidecar（通配符DNS解析器）。三者共享一个固定子网的桥接网络（172.28.0.0/16），IP静态分配：devcontainer在172.28.0.2，topaz在172.28.0.10，dns-sidecar在172.28.0.53。固定IP很重要——DNS配置要在容器启动前就指向一个稳定地址，dnsmasq的address=/.topaz.local.dev/172.28.0.10规则也要提前知道Topaz的位置。