如何在Airflow 2.0中使用DockerOperator拉取GitLab私有Docker镜像并解决权限问题

现有配置与报错情况 #

在AWS EC2实例上通过Docker部署Airflow 2.0，运行DockerOperator拉取GitLab容器Registry私有镜像时持续报权限错误，已完成如下配置仍未解决问题：

• DAG中DockerOperator初始化代码：

java_test_scheduler = DockerOperator(
    task_id='Java-hello-world-test-scheduler',
    image='registry.gitlab.com/mobinalhassan/jamay_aeronova:latest',
    auto_remove=True,
    force_pull=True,
    dag=dag
)

• docker-compose中为Airflow组件挂载的卷：

- /var/run/docker.sock:/var/run/docker.sock
- $HOME/.ssh:/root/.ssh:ro
- $HOME/.docker:/root/.docker

• 实际运行报错日志：

sock.connect(self.unix_socket) PermissionError: [Errno 13] Permission denied

核心待解决问题 #

• 正确配置DockerOperator从GitLab容器Registry拉取私有镜像的流程
• 在Airflow中为GitLab容器Registry配置对应Docker连接的方法

问题根因 #

日志中出现的套接字权限拒绝错误，本质是两层问题叠加导致：

1. 权限不匹配：Airflow 2.0默认容器运行用户为UID 50000的airflow用户，并非root，无法直接访问宿主机映射进来的/var/run/docker.sock套接字文件，这是当前报错的直接原因
2. 认证配置方式错误：直接挂载宿主机$HOME/.docker、$HOME/.ssh目录的方式存在权限路径不匹配问题，且DockerOperator默认没有加载GitLab Registry的认证信息，即使解决套接字访问问题，拉取私有镜像时仍会被Registry拒绝

分步解决操作 #

1. 修复docker.sock访问权限 #

根据自身安全策略选择任意一种方式即可：

• 临时测试方案：在宿主机上执行命令开放套接字文件的全局读写权限sudo chmod 666 /var/run/docker.sock
• 容器配置方案：在docker-compose文件中，为运行DockerOperator任务的Airflow Worker/Scheduler组件添加user: root配置，让容器内进程拥有访问套接字的权限
• 安全可控方案：在Airflow容器的启动入口命令中加入权限调整逻辑，容器启动时自动将挂载的docker.sock权限调整为允许当前用户访问，避免宿主机层面的权限修改

注意：之前配置的$HOME/.ssh:/root/.ssh:ro挂载属于多余配置，GitLab Registry的Docker拉取走HTTP认证流程，和SSH密钥无关，可以移除减少不必要的配置；同时$HOME/.docker:/root/.docker挂载也可以移除，这种直接挂载宿主机配置目录的方式容易因为文件权限不匹配导致认证信息加载失败，可靠性更低。

2. 配置GitLab Registry的Docker连接 #

不要直接依赖宿主机的docker登录配置，使用Airflow内置连接管理实现认证：

• 提前在GitLab侧创建仅拥有目标项目镜像拉取权限的Deploy Token，避免使用个人账号密码带来的安全风险
• 打开Airflow WebUI，进入连接管理页面，新建类型为Docker的连接：
  • Host字段填写GitLab Registry地址https://registry.gitlab.com
  • Login字段填写Deploy Token的用户名
  • Password字段填写Deploy Token的对应密钥
  • Email字段填写关联的GitLab账号邮箱
• 保存连接后，在DockerOperator实例化代码中添加docker_conn_id参数，指定刚创建的Docker连接ID，Airflow会自动在调用Docker API时携带对应认证信息完成私有镜像拉取，不需要额外挂载.docker配置目录。

内容的提问来源于stack exchange，提问作者Mobin Al Hassan