如何为官方docker-compose部署的Airflow配置远程调试

疑问1：创建Python Interpreter时应当选择哪个容器？ #

• 不要选airflow-worker容器当解释器挂载目标，优先选airflow-scheduler或者airflow-webserver容器。
• 原因很简单：worker是Celery架构下专门跑任务的常驻实例，启动后主进程会被worker服务占住，本身环境也是为任务执行做的适配，不适合拿来做调试解释器；scheduler和webserver容器带全了所有Airflow运行依赖、全局环境变量，和你本地挂载DAG目录的映射规则完全一致，用它做解释器不会出莫名其妙的路径、权限问题。

疑问2：直接在调试配置中设置运行Airflow二进制文件的方式是否正确？ #

• 这种配置方式是错的。你碰到的the following arguments are required: GROUP_OR_COMMAND报错，核心原因就是你直接跑了airflow二进制但没传任何子命令——Airflow CLI本身必须搭配具体的命令组/子命令才能跑，不带参数执行只会输出帮助信息，自然会报错。
• 日志里的FutureWarning只是配置项兼容性提示，不卡调试流程，等升级Airflow 3.0之前补全[api]板块下的auth_backends配置就行，不是阻塞性错误。
• 正确的调试配置走这几步就行：
  1. 远程解释器选scheduler容器内的Python路径，默认是/home/airflow/.local/bin/python
  2. 调试的目标脚本别选airflow二进制，换成容器内Airflow的Python入口文件，默认路径是/home/airflow/.local/lib/python3.7/site-packages/airflow/__main__.py
  3. 运行参数栏填你要执行的具体Airflow子命令，比如要启动webserver就填webserver，要调单个DAG任务就填tasks test <你的dag_id> <你的task_id> <执行日期>
  4. 工作目录设成容器内DAG的挂载根目录，默认是/opt/airflow/dags

你现在选airflow-worker当解释器本身就容易出配置冲突，先换成scheduler容器，再按上面的步骤调调试配置，就能正常打断点调DAG代码了。

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