Airflow安装依赖: scheduler容器command装git报错排查

首先明确结论：直接在docker-compose的command字段中执行安装命令不属于合理实现方案，存在以下明显缺陷：

• 容器每次重启、重建都会重复执行全量安装流程，服务启动速度慢，网络波动时会直接导致容器启动失败
• 官方Airflow镜像默认使用非root的airflow用户运行进程，无权限执行apt-get等系统级安装操作，这也是你遇到sudo: no tty present and no askpass program specified报错的核心原因
• 如果webserver、worker、triggerer等其他服务也需要相同依赖，需要在每个服务的配置中重复写安装逻辑，维护成本极高
• 你当前配置覆盖了镜像默认的entrypoint为/bin/sh，会跳过Airflow官方镜像内置的环境初始化、数据库检查、权限配置等逻辑，极易引发其他启动异常
• 安装过程产生的冗余缓存不会被持久化，会重复占用计算和存储资源

推荐实现方案 #

1. 生产/长期使用场景：构建自定义镜像（官方推荐） #

这是最稳定、符合容器最佳实践的方案，将依赖提前打包到镜像中，容器启动时直接运行服务即可。
首先在docker-compose.yml同级目录新建Dockerfile：

# 替换为你实际使用的Airflow基础镜像版本，和你当前compose里的airflow_image保持一致
FROM apache/airflow:2.9.2-python3.11

# 切换到root用户安装系统依赖
USER root
RUN apt-get update && apt-get install -y --no-install-recommends \
    git \
    # 在此处追加其他需要的系统依赖包
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

# 切回默认的airflow普通用户，符合容器安全运行要求
USER airflow

# 提前复制Python依赖清单并安装
COPY requirements.txt /tmp/requirements.txt
RUN pip install --no-cache-dir -r /tmp/requirements.txt

然后修改docker-compose.yml配置：

• 把scheduler、webserver、worker等所有需要依赖的服务的image字段替换为你自定义的镜像名，例如custom-airflow:latest
• 删除你手动加的entrypoint配置，以及command里的apt、pip安装逻辑，保留镜像默认的启动命令即可
  最后在compose目录执行构建命令：docker-compose build，构建完成后正常启动集群即可，所有依赖已经内置在镜像中，不存在权限问题，启动速度快，多服务可以复用同一个镜像。

2. 临时测试场景：进入容器手动安装 #

如果只是本地临时调试不想构建镜像，可以在集群正常启动后，用root权限进入运行中的容器安装：

1. 正常执行docker-compose up -d启动所有服务
2. 以root身份进入scheduler容器：docker exec -u root -it <你的scheduler容器实际名称> /bin/bash
3. 执行系统依赖安装：apt-get update && apt-get install -y git
4. 执行Python依赖安装：pip install -r /opt/airflow/tmp/requirements.txt
   注意：该方案安装的内容会在容器删除、重建后丢失，仅适合临时测试使用，不要用于生产环境。

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