使用Airflow官方Docker镜像时，如何搭建含其他服务的运行环境？

1. 是否需要部署两个Postgres服务？ #

不需要。官方Airflow的Postgres是用来存储Airflow元数据（比如任务调度记录、DAG状态等）的。如果课程中用Postgres是为了业务数据存储（比如任务生成的业务数据），完全可以复用这个Postgres实例，只要在Airflow的连接配置里新增一个指向该实例的业务数据库连接即可。如果你的业务数据和Airflow元数据需要严格隔离，也可以单独部署一个Postgres，但这不是必须的，优先复用能减少资源占用和维护成本。

2. 是否要编辑yaml文件加入所有所需服务？ #

是的，但可以灵活处理：

• 直接编辑官方的docker-compose.yml，把jupyter、minio等附加服务的配置追加到文件末尾，这样用docker-compose up就能一次性启动所有服务。
• 更推荐的方式是使用docker-compose override文件：创建docker-compose.override.yml，把附加服务的配置写在这里，启动时docker-compose会自动合并官方yaml和override文件的配置。这样官方的核心配置文件可以保持原样，后续升级Airflow时直接替换官方yaml即可，不会丢失自定义的附加服务配置。

举个简单的minio和jupyter的override配置示例：

version: '3.8'
services:
  minio:
    image: minio/minio:latest
    command: server /data --console-address ":9001"
    ports:
      - "9000:9000"
      - "9001:9001"
    volumes:
      - minio_data:/data
    environment:
      MINIO_ROOT_USER: admin
      MINIO_ROOT_PASSWORD: password

  jupyter:
    image: jupyter/minimal-notebook:latest
    ports:
      - "8888:8888"
    volumes:
      - ./dags:/home/jovyan/work/dags
    environment:
      JUPYTER_TOKEN: airflow123
volumes:
  minio_data:

3. 有没有其他更规范的实现方式？ #

推荐以下规范方案：

• 用override文件分离核心与自定义服务：如上面所说，官方yaml存核心Airflow服务，override文件存jupyter、minio等附加服务，便于版本升级和配置管理。
• 用.env文件统一管理环境变量：把Airflow的元数据库密码、minio的账号密码、jupyter的token等敏感信息或可变配置放到.env文件中，docker-compose会自动读取这些变量，避免硬编码在yaml文件里。
• 标准化Airflow与附加服务的交互：
  • 把minio配置为Airflow的S3兼容存储，用来存放DAG文件、任务日志或输出数据，需要在Airflow的连接中新增S3类型连接，指向minio的地址和账号信息。
  • 挂载DAG目录到jupyter容器，这样在jupyter中编写的DAG可以直接同步到Airflow的DAG目录，无需手动复制。
• 遵循官方最佳实践：官方docker-compose配置已经包含了CeleryExecutor、Redis队列等生产级组件，不要随意修改核心服务的配置（如Airflow的执行器、元数据库连接），如果需要调整，优先通过.env文件中的环境变量来修改。

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