如何在C#代码中用Azure DevOps服务连接访问DockerHub实现SQL集成测试CI

方案可行性与最优方案 #

你想把所有容器调度逻辑收敛到代码中的方案是完全可行的，也是更优的工程实践，完全避免了两套配置维护的问题，也支持单测试用例独立启动容器的需求。最优的做法是把Docker授权和容器调度逻辑解耦，不需要代码直接操作服务连接，只需要流水线提前完成Docker登录即可。

用服务连接实现代码层面DockerHub访问的方法 #

可以实现，而且操作非常简单，不需要改动你现有的容器调度代码，只需要在CI流水线最开始增加一个Docker登录任务：

- task: Docker@2
  displayName: 'DockerHub 登录'
  inputs:
    containerRegistry: DockerHub
    command: login

这个任务会通过你预先配置好的DockerHub服务连接完成当前代理环境的Docker认证，认证信息会写入到代理的Docker配置文件中。你代码中调用本地Docker Daemon拉取镜像的时候，会自动读取这份配置完成授权，不需要在代码里处理任何凭证逻辑。
这种方案下本地开发和CI环境的容器调度代码完全一致，只是CI多了一步无侵入的预登录操作，几乎没有额外维护成本。

其他代码层面访问DockerHub的方案 #

如果不想用服务连接预登录的方案，还有两种可选方案：

• 预先把需要用到的基础镜像（比如mcr.microsoft.com/mssql/server:2017-latest）同步到你团队的Azure容器注册表（ACR）中，给流水线运行账号开通ACR的镜像拉取权限，代码里直接替换为ACR的镜像地址即可，不需要额外处理DockerHub的授权
• 把DockerHub的用户名和个人访问令牌存为Azure DevOps流水线的保密变量，代码运行时读取这两个变量，主动执行docker login命令完成授权，这种方案需要注意不要在日志中输出凭证信息，安全性比服务连接方案低。

注意事项 #

• Azure DevOps托管代理默认已经启动了Docker Daemon，代码调用Docker SDK或者直接执行docker命令都可以正常运行
• 建议在代码中增加容器自动清理逻辑，测试运行完成后自动删除对应容器，避免占用代理资源
• 并行执行测试时不要写死容器名和端口，建议使用随机端口，测试启动时动态读取映射后的端口连接数据库，避免冲突

内容的提问来源于stack exchange，提问作者Matthias Müller