Penpot项目Nginx容器DNS解析问题的分析与解决

问题背景

在容器化部署场景中，DNS解析是一个常见但容易被忽视的问题。Penpot作为一款开源的设计协作平台，其官方提供的Docker Compose部署方案在标准Docker环境下运行良好，但在Podman环境中却遇到了DNS解析问题。这个问题的核心在于Nginx容器中硬编码的DNS解析器地址127.0.0.11，这个地址是Docker特有的内部DNS服务地址，而Podman采用了不同的网络架构。

技术细节分析

在Docker环境中，容器内部通过127.0.0.11这个特殊IP地址访问内置的DNS服务。这个地址会由Docker自动处理，将DNS请求转发到宿主机的DNS配置。然而在Podman环境中：

1. Podman使用不同的网络模型，DNS服务通常通过Podman网络网关提供
2. 硬编码的127.0.0.11在Podman中无法正常工作
3. 这导致Nginx无法解析外部域名，如Google字体服务等

具体表现为Nginx日志中出现类似错误：

recv() failed (111: Connection refused) while resolving, resolver: 127.0.0.11:53
*51 fonts.googleapis.com could not be resolved (110: Operation timed out)

临时解决方案

在官方修复前，用户可以采用以下临时解决方案：

1. 手动修改Nginx配置文件中的resolver行，指向Podman网络网关IP
2. 使用环境变量PENPOT_INTERNAL_RESOLVER覆盖默认值
3. 创建自定义网络并指定固定子网，确保网关IP不变

例如在docker-compose.yaml中添加：

environment:
  PENPOT_INTERNAL_RESOLVER: "10.89.7.1 10.89.8.1"

官方修复方案

Penpot开发团队采纳了社区建议，参考了Nginx Proxy Manager的实现方式，通过以下改进实现了更智能的DNS解析：

1. 在容器启动时动态读取/etc/resolv.conf文件
2. 提取其中的nameserver地址
3. 自动生成适用于当前容器环境的resolver配置

这种方案具有以下优势：

• 兼容Docker和Podman环境
• 遵循容器编排工具的网络配置
• 减少手动配置需求
• 提高部署灵活性

最佳实践建议

对于使用Penpot的用户，特别是选择自建部署的，建议：

1. 保持组件更新，特别是2.5及以上版本已包含此修复
2. 了解容器网络基础知识，有助于排查类似问题
3. 对于生产环境，考虑使用Traefik等专业反向代理
4. 监控Nginx日志，及时发现解析问题

总结

容器环境中的DNS解析问题看似简单，实则涉及复杂的网络架构差异。Penpot团队通过社区反馈快速响应，实现了更智能的解决方案，体现了开源项目的协作优势。这也提醒我们，在设计容器化应用时，应当考虑不同容器运行时环境的差异，避免硬编码特定实现细节。

对于技术团队而言，理解这类问题的解决思路比记住具体配置更重要，这有助于在遇到类似问题时快速定位和解决。