当Airflow运行在Docker容器中时如何使用DockerOperator？

首先需要避开真正的Docker-in-Docker（特权模式运行Docker daemon嵌套）方案，该方案存在存储驱动兼容性、性能损耗、安全风险等问题，且迁移到K8s后兼容性极差，推荐以下两种生产可用方案：

方案一：挂载宿主机Docker套接字（最适合当前docker-compose部署场景，也兼容K8s过渡阶段） #

这种方案本质是让Airflow容器内的Docker客户端直接调用宿主机的Docker daemon，没有嵌套运行Docker，稳定性最高。
操作步骤：

• 修改你的docker-compose.yaml中Airflow worker服务的配置，新增宿主机docker sock的挂载卷：

services:
  airflow-worker:
    # 其他原有配置保持不变
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      # 可选：如果需要挂载本地文件到DockerOperator启动的容器，需要保持宿主机、Airflow容器、Operator启动容器的路径一致，比如统一挂载/opt/airflow/dags路径
      - ./dags:/opt/airflow/dags

• 进入Airflow worker容器安装Docker客户端（或者直接在你的Airflow自定义镜像中预装，避免每次重启重新安装）：
  基于Debian的镜像执行：apt update && apt install -y docker.io
  基于Alpine的镜像执行：apk add --no-cache docker-cli
• 给Airflow运行用户授予docker sock的访问权限：在镜像构建阶段执行RUN usermod -aG docker airflow，或者启动时执行chmod 666 /var/run/docker.sock（生产环境推荐前者，权限更可控）
• DockerOperator的配置和宿主机直接部署Airflow时完全一致，不需要额外修改参数。

方案二：使用Docker Remote API调用（更适合跨节点部署，以及后续迁移K8s后的兼容方案） #

如果后续要迁移到K8s，可以提前切换为远程调用独立Docker节点的方式，该方式迁移K8s后不需要调整DAG代码：

• 提前准备独立的Docker节点，开启Docker Remote API访问，配置好TLS证书做身份校验
• 在Airflow的连接配置中新增docker类型的连接，填写远程Docker节点的API地址、TLS证书等信息
• 在DAG的DockerOperator中指定docker_conn_id参数为你新增的连接ID即可，不需要在Airflow容器内做任何额外配置
• 迁移到K8s后，你可以直接将DockerOperator替换为KubernetesPodOperator，仅需少量参数调整即可，DAG逻辑不需要重构。

注意事项 #

• 挂载docker sock方案中，DockerOperator启动的所有容器都是运行在宿主机上，和Airflow容器是同级而非嵌套关系，注意端口、卷名不要冲突
• 如果需要在DockerOperator启动的容器中挂载文件，需要保证挂载路径在宿主机、Airflow容器、目标容器中完全一致，否则会出现文件找不到的问题
• 生产环境不要使用特权模式运行真正的DinD容器，存在严重的安全逃逸风险。

内容的提问来源于stack exchange，提问作者binarymason