问题描述
在与他们的DevOps讨论是否在集成测试中使用Testcontainers时遇到了一些问题。TestContainers是一个用于测试的工具，可以创建临时容器进行测试。该工具需要一个环境变量DOCKER_HOST=tcp://127.0.0.1:2375与Docker进行通信。
用户的DevOps拒绝设置这个环境变量，并解释说出于安全原因，他不希望应用程序与Docker通信。
用户提出了一个观点，即该工具在运行测试时是与Docker进行交互的，现在他有以下问题：
– 在这方面是否存在安全考虑？
– 我还能提出哪些更有说服力的论点？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
安全考虑
关于Docker的安全问题，通常已经在其他地方得到了很好的回答，例如这里：https://stackoverflow.com/questions/40844197/what-is-the-docker-security-risk-of-var-run-docker-sock。
在你的具体情况下，有以下几点需要考虑：
1. 测试应该在某个测试服务器上运行，甚至可以在每次测试运行后销毁/重置的虚拟机中运行，这样可能的意外事故不会影响其他系统。
2. 要想利用这个设置，攻击者可能需要能够修改你的测试代码，如果他们能够做到这一点，你已经会面临比特权Docker访问更大的问题了。
论点
当与你的DevOps进行讨论时，你可以提出以下论点来说明在集成测试中使用TestContainers是合理且安全的：
1. 隔离性： TestContainers旨在提供一个隔离的测试环境，通过创建临时容器来运行测试，可以确保测试环境不会影响其他系统。这种隔离性有助于避免测试过程中可能的问题波及到生产环境。
2. 可复现性： 使用临时容器可以确保每次测试运行都在相同的环境中进行，从而提供了可复现性。这有助于识别和修复与环境相关的问题，同时还便于团队成员在不同环境中运行相同的测试。
3. 便捷性： TestContainers简化了测试环境的设置过程，无需手动准备测试数据库或其他依赖项。这节省了时间和精力，并促使团队更频繁地运行集成测试。
在讨论中，强调TestContainers的设计目标是与Docker进行交互，以创建一个临时的测试环境。同时，你可以分享其他组织或项目在使用TestContainers进行集成测试时取得的成功经验。
结论
在集成测试中使用TestContainers是一个合理且有益的做法。它可以为测试提供隔离、可复现的环境，并简化测试设置过程。在与DevOps讨论时，强调TestContainers的设计目标以及其他组织的成功实践，有助于更好地理解其价值和安全性。