Testcontainers-dotnet 在 Azure Pipelines 中的 Docker Wormhole 模式解决方案

在基于容器的持续集成环境中使用 Testcontainers-dotnet 时，开发人员可能会遇到"Initialization has been cancelled"的错误。这种情况特别容易出现在 Azure Pipelines 自托管代理的特定配置中。本文将深入分析问题根源并提供完整的解决方案。

问题现象

当开发者在本地环境（无论是 Linux 还是 Windows）运行 C# 测试时，Testcontainers 能够正常工作，Ryuk 容器和测试容器都能成功创建。然而，在 Azure Pipelines 环境中运行时，虽然 Ryuk 容器能够创建，但随后会出现超时，并抛出"Initialization has been cancelled"的错误。

值得注意的是，同样的测试场景在 Python 版本的 Testcontainers 中却能正常运行，这表明这是一个特定于 Testcontainers-dotnet 的问题。

根本原因分析

经过深入调查，发现问题源于 Docker Wormhole 模式下的特殊配置需求。当使用自托管的 Azure Pipelines 代理时，典型的配置是：

1. 在 Windows 上运行 Docker Desktop（使用 WSL2 后端）
2. Azure DevOps 构建代理本身运行在容器中
3. 将 Docker 守护进程套接字挂载到该容器内

这种配置形成了一个"Docker Wormhole"模式，即容器内的 Docker 客户端通过挂载的套接字与宿主机上的 Docker 守护进程通信。在这种模式下，Testcontainers-dotnet 需要额外的配置才能正确处理容器间的网络连接。

解决方案

要解决这个问题，需要进行以下两项关键配置：

1. 挂载原始 Docker 套接字： 在启动自托管代理容器时，确保挂载的是原始 Docker 套接字：

   /var/run/docker.sock.raw:/var/run/docker.sock
   

2. 设置主机覆盖环境变量： 在运行测试时，设置 TESTCONTAINERS_HOST_OVERRIDE 环境变量：

   - script: dotnet test
     env:
       TESTCONTAINERS_HOST_OVERRIDE: host.docker.internal
   

技术原理

这个解决方案背后的技术原理是：

1. 原始套接字挂载：使用 .raw 后缀确保套接字以原始模式挂载，避免权限和功能限制问题。

2. 主机覆盖：TESTCONTAINERS_HOST_OVERRIDE 环境变量告诉 Testcontainers 如何从容器内部访问宿主机网络。在 Docker Desktop 环境中，host.docker.internal 是一个特殊的 DNS 名称，解析为宿主机的内部 IP 地址。

最佳实践建议

1. 对于 Azure Pipelines，优先考虑使用 Microsoft 托管的代理（如 ubuntu-latest），这些代理已经过优化，通常不需要额外配置。

2. 当必须使用自托管代理时：

   • 确保代理容器有足够的资源（CPU 和内存）
   • 考虑增加 Testcontainers 的超时设置
   • 定期更新代理容器中的 Docker 版本

3. 在开发环境中，可以通过设置相同的环境变量来保持配置一致性。

总结

Testcontainers-dotnet 在复杂的容器化 CI/CD 环境中运行时，需要特别注意网络连接的特殊性。通过正确配置 Docker 套接字挂载方式和主机覆盖环境变量，可以解决"Initialization has been cancelled"错误，确保测试容器在各种环境中都能可靠运行。

理解这些配置背后的原理不仅有助于解决当前问题，也为处理其他类似的容器网络问题提供了思路。随着容器技术的普及，这类"容器中的容器"场景会越来越常见，掌握其配置要点将成为现代开发者的必备技能。