Apache Airflow Docker 镜像定制配方Recipes实战gcloud / Hadoop / Beam Go 三种镜像扩展方案【免费下载链接】airflowApache Airflow - A platform to programmatically author, schedule, and monitor workflows项目地址: https://gitcode.com/GitHub_Trending/ai/airflowAirflow 官方发布的apache/airflow参考镜像reference image只内置了一组最常见的 extras 与 providers当你的 DAG 需要调用gcloud、在 Hadoop 集群上执行任务或运行 Beam Go Pipeline 时就必须对镜像做二次定制。本文基于仓库 docker-stack-docs/recipes.rst 的官方配方结合镜像仓库中的真实 Dockerfile 与 providers 源码完整讲解三种社区验证过的镜像扩展方案读完即可照着写出可复现、可上生产的定制 Dockerfile。一、为什么需要 Recipes参考镜像的边界Apache Airflow 社区在每个版本发布时都会同时产出apache/airflow参考镜像regular 与 slim 两类镜像中默认安装了AIRFLOW_HOME/opt/airflowDAG 默认位于/opt/airflow/dags日志位于/opt/airflow/logs见 docker-stack-docs/index.rst。regular 镜像虽然内置了最常见的 extras 与 providers但它不包含gcloud、Go、Java/Hadoop/Hive 这类运行时二进制——这些是部分 Operator 执行任务的硬性前置条件。例如GKEStartPodOperator 的类注释明确写道This Operator assumes that the system has gcloud installed and has configured a connection id with a service account.——它假定系统已安装gcloudBeamRunGoPipelineOperator 用于Launch Apache Beam pipelines written in Go运行环境必须存在 Go 工具链。因此官方在文档中开辟了 Recipes 章节收录社区提交的、经过验证的镜像扩展配方。任何用户都可以通过提交 Pull Request 贡献自己的配方供其他成员复用。这正是本文要讲解的三个官方配方。二、通用构建模型以 BASE_AIRFLOW_IMAGE 为基底三个配方采用完全一致的镜像定制模型在官方镜像之上叠加运行时而不是从头编写镜像。其核心是ARG BASE_AIRFLOW_IMAGEFROM ${BASE_AIRFLOW_IMAGE}的构建参数传递机制ARG BASE_AIRFLOW_IMAGE FROM ${BASE_AIRFLOW_IMAGE}配合统一的构建命令以 gcloud 配方为例docker build . \ --pull \ --build-arg BASE_AIRFLOW_IMAGEapache/airflow:2.0.2 \ --tag my-airflow-image:0.0.1要点说明--pull强制拉取最新基础镜像避免使用本地过期缓存BASE_AIRFLOW_IMAGE必须显式传入否则FROM中的变量为空会构建失败官方配方示例中的apache/airflow:2.0.2、apache/airflow:2.2.5只是当时验证过的版本你可以替换为当前实际使用的版本标签如apache/airflow:3.4.0或slim系列--tag my-airflow-image:0.0.1为定制镜像命名便于后续在 docker-compose 或 Helm Chart 中引用。从 Dockerfile 可以看到官方基础镜像默认定义ARG AIRFLOW_UID50000并最终以非 root 的airflow用户运行。三个配方都遵循同一安全约定安装阶段临时切换到USER 0root以获取写权限安装完成后切回USER ${AIRFLOW_UID}保证最终镜像不以 root 运行。三、Recipe 1安装 Google Cloud SDKgcloud / kubectl3.1 适用场景当你使用 Google Cloud 相关的 Kubernetes 类 Operator如GKEStartPodOperator执行任务时需要gcloud命令行工具。官方配方还指出You can also run these commands with BashOperator——即你也可以用BashOperator在 DAG 中直接执行同样的安装命令适用于任务级安装而非镜像级定制。3.2 完整 Dockerfile 解析配方文件见 gcloud.Dockerfile完整内容如下ARG BASE_AIRFLOW_IMAGE FROM ${BASE_AIRFLOW_IMAGE} SHELL [/bin/bash, -o, pipefail, -e, -u, -x, -c] USER 0 ARG CLOUD_SDK_VERSION322.0.0 ENV GCLOUD_HOME/opt/google-cloud-sdk ENV PATH${GCLOUD_HOME}/bin/:${PATH} RUN DOWNLOAD_URLhttps://dl.google.com/dl/cloudsdk/channels/rapid/downloads/google-cloud-sdk-${CLOUD_SDK_VERSION}-linux-x86_64.tar.gz \ TMP_DIR$(mktemp -d) \ curl -fL ${DOWNLOAD_URL} --output ${TMP_DIR}/google-cloud-sdk.tar.gz \ mkdir -p ${GCLOUD_HOME} \ tar xzf ${TMP_DIR}/google-cloud-sdk.tar.gz -C ${GCLOUD_HOME} --strip-components1 \ ${GCLOUD_HOME}/install.sh \ --bash-completionfalse \ --path-updatefalse \ --usage-reportingfalse \ --additional-components alpha beta kubectl \ --quiet \ rm -rf ${TMP_DIR} \ rm -rf ${GCLOUD_HOME}/.install/.backup/ \ gcloud --version USER ${AIRFLOW_UID}逐段要点SHELL [/bin/bash, -o, pipefail, -e, -u, -x, -c]切换到严格模式 bashpipefail保证管道任一段失败即构建失败-e遇错即停-x输出执行过程便于排查USER 0安装过程需要 root 权限写入/optARG CLOUD_SDK_VERSION322.0.0SDK 版本以构建参数暴露可覆盖ENV GCLOUD_HOME/opt/google-cloud-sdk固定安装目录--additional-components alpha beta kubectl额外安装 alpha、beta 通道组件和kubectl这是在容器内调用GKEStartPodOperator与 K8s API 交互的关键依赖--path-updatefalse 显式ENV PATH不修改全局 bashrc直接注入 PATH保证所有用户含 airflow 用户可见结尾gcloud --version验证安装成功镜像构建阶段即失败快速反馈USER ${AIRFLOW_UID}切回普通用户保持官方镜像的非 root 安全基线。3.3 构建与验证docker build . \ --pull \ --build-arg BASE_AIRFLOW_IMAGEapache/airflow:2.0.2 \ --tag my-airflow-image:0.0.1构建完成后可进入容器验证docker run --rm my-airflow-image:0.0.1 gcloud version四、Recipe 2安装 Apache Hadoop 技术栈4.1 适用场景Airflow 常被用于调度 Hadoop 集群上的任务。在容器内运行这类任务需要补齐四个组件Java Runtime Environment (JRE)、Apache Hadoop、Apache Hive以及Cloud Storage connector for Apache HadoopGCS 连接器用于访问 Google Cloud Storage。4.2 完整 Dockerfile 解析配方文件见 hadoop.Dockerfile分四步第一步安装 JREAdoptOpenJDK 8RUN mkdir -pv /usr/share/man/man1 \ mkdir -pv /usr/share/man/man7 \ curl -fsSL https://adoptopenjdk.jfrog.io/adoptopenjdk/api/gpg/key/public | apt-key add - \ echo deb https://adoptopenjdk.jfrog.io/adoptopenjdk/deb/ $(lsb_release -cs) main \ /etc/apt/sources.list.d/adoptopenjdk.list \ apt-get update \ apt-get install --no-install-recommends -y \ adoptopenjdk-8-hotspot-jre \ apt-get autoremove -yqq --purge \ apt-get clean \ rm -rf /var/lib/apt/lists/* ENV JAVA_HOME/usr/lib/jvm/adoptopenjdk-8-hotspot-jre-amd64先创建 man 手册目录解决某些基础镜像的 apt 安装报错再通过 AdoptOpenJDK 官方 apt 源安装 JRE最后autoremoveclean 删除 apt 列表缓存以控制镜像体积。第二步安装 Apache HadoopARG HADOOP_VERSION2.10.1 ENV HADOOP_HOME/opt/hadoop ENV HADOOP_CONF_DIR/etc/hadoop ENV MULTIHOMED_NETWORK1 ENV USERroot RUN HADOOP_URLhttps://archive.apache.org/dist/hadoop/common/hadoop-$HADOOP_VERSION/hadoop-$HADOOP_VERSION.tar.gz \ curl https://dist.apache.org/repos/dist/release/hadoop/common/KEYS | gpg --import - \ curl -fSL $HADOOP_URL -o /tmp/hadoop.tar.gz \ curl -fSL $HADOOP_URL.asc -o /tmp/hadoop.tar.gz.asc \ gpg --verify /tmp/hadoop.tar.gz.asc \ mkdir -p ${HADOOP_HOME} \ tar -xvf /tmp/hadoop.tar.gz -C ${HADOOP_HOME} --strip-components1 \ rm /tmp/hadoop.tar.gz /tmp/hadoop.tar.gz.asc \ ln -s ${HADOOP_HOME}/etc/hadoop /etc/hadoop \ mkdir ${HADOOP_HOME}/logs \ mkdir /hadoop-data ENV PATH$HADOOP_HOME/bin/:$PATH值得注意的细节先导入 Apache 官方 KEYS再同时下载.tar.gz与.asc签名文件并执行gpg --verify校验包完整性这是该配方安全意识的体现ln -s将配置目录软链到/etc/hadoop统一管理MULTIHEDOWN_NETWORK1用于规避多网卡环境下的 Hadoop 网络问题。第三步安装 Apache HiveARG HIVE_VERSION2.3.7 ENV HIVE_HOME/opt/hive ENV HIVE_CONF_DIR/etc/hive RUN HIVE_URLhttps://archive.apache.org/dist/hive/hive-${HIVE_VERSION}/apache-hive-${HIVE_VERSION}-bin.tar.gz \ curl -fSL https://downloads.apache.org/hive/KEYS | gpg --import - \ curl -fSL $HIVE_URL -o /tmp/hive.tar.gz \ curl -fSL $HIVE_URL.asc -o /tmp/hive.tar.gz.asc \ gpg --verify /tmp/hive.tar.gz.asc \ mkdir -p ${HIVE_HOME} \ tar -xf /tmp/hive.tar.gz -C ${HIVE_HOME} --strip-components1 \ rm /tmp/hive.tar.gz /tmp/hive.tar.gz.asc \ ln -s ${HIVE_HOME}/etc/hive ${HIVE_CONF_DIR} \ mkdir ${HIVE_HOME}/logs ENV PATH$HIVE_HOME/bin/:$PATH同样遵循导入 KEYS → 下载 → 校验签名 → 解压 → 清理的流程并把hive命令加入 PATH。第四步安装 GCS connectorARG GCS_VARIANThadoop2 ARG GCS_VERSION2.1.5 RUN GCS_JAR_PATH/opt/spark/jars/gcs-connector-${GCS_VARIANT}-${GCS_VERSION}.jar \ GCS_JAR_URLhttps://storage.googleapis.com/hadoop-lib/gcs/gcs-connector-${GCS_VARIANT}-${GCS_VERSION}.jar \ curl ${GCS_JAR_URL} -o ${GCS_JAR_PATH} ENV HADOOP_CLASSPATH/opt/spark/jars/gcs-connector-${GCS_VARIANT}-${GCS_VERSION}.jar:$HADOOP_CLASSPATHGCS 连接器以 JAR 形式下载到/opt/spark/jars并通过HADOOP_CLASSPATH注入到 Hadoop 运行环境使 Hadoop/Hive 能够直接读写 GCS 上的数据。4.3 构建命令docker build . \ --pull \ --build-arg BASE_AIRFLOW_IMAGEapache/airflow:2.0.2 \ --tag my-airflow-image:0.0.1如需更换组件版本可通过--build-arg覆盖配方中的HADOOP_VERSION、HIVE_VERSION、GCS_VERSION、GCS_VARIANT等参数。五、Recipe 3安装 Apache Beam Go 工具链5.1 适用场景要运行 Beam Go Pipeline由 BeamRunGoPipelineOperator 调度容器内必须有 Go 工具链。官方要求同时满足两个 provider 版本前提apache-airflow-providers-google6.5.0与apache-airflow-providers-apache-beam3.2.0。5.2 完整 Dockerfile 解析配方文件见 go-beam.DockerfileARG BASE_AIRFLOW_IMAGE FROM ${BASE_AIRFLOW_IMAGE} SHELL [/bin/bash, -o, pipefail, -e, -u, -x, -c] USER 0 ARG GO_VERSION1.16.4 ENV GO_INSTALL_DIR/usr/local/go # Install Go RUN if [[ $(uname -a) *x86_64* ]] ; then export ARCHamd64 ; else export ARCHarm64 ; fi \ DOWNLOAD_URLhttps://dl.google.com/go/go${GO_VERSION}.linux-${ARCH}.tar.gz \ TMP_DIR$(mktemp -d) \ curl -fL ${DOWNLOAD_URL} --output ${TMP_DIR}/go.linux-${ARCH}.tar.gz \ mkdir -p ${GO_INSTALL_DIR} \ tar xzf ${TMP_DIR}/go.linux-${ARCH}.tar.gz -C ${GO_INSTALL_DIR} --strip-components1 \ rm -rf ${TMP_DIR} ENV GOROOT/usr/local/go ENV PATH$GOROOT/bin:$PATH USER ${AIRFLOW_UID}该配方最值得学习的细节是CPU 架构自适应通过uname -a判断构建平台是x86_64amd64还是 arm64再选择对应的 Go 安装包。这也呼应了 docker-stack-docs/index.rst 中官方镜像为多平台 AMD/ARM 镜像的说明——定制镜像同样需要考虑架构差异。安装完成后设置GOROOT并把$GOROOT/bin加入 PATH。5.3 构建命令docker build . \ --pull \ --build-arg BASE_AIRFLOW_IMAGEapache/airflow:2.2.5 \ --tag my-airflow-image:0.0.1六、配方之外更多镜像扩展方向三个配方展示的是叠加外部二进制运行时这一类需求。仓库 docker-stack-docs/docker-examples/extending 下还提供了其他同构的扩展示例可互相参照安装 PyPI 包add-pypi-packages/DockerfileRUN pip install --no-cache-dir apache-airflow${AIRFLOW_VERSION} lxml通过${AIRFLOW_VERSION}环境变量对齐基础镜像的 Airflow 版本避免依赖冲突安装 apt 系统包add-apt-packages/DockerfileUSER root安装后apt-get autoremoveclean 清理列表缓存最后USER airflow切回其他示例还包括add-providers、add-python-venv、add-airflow-configuration、embedding-dags、custom-providers等见 docker-examples/extending 目录。它们与 Recipes 的共同模式可以总结为三条黄金法则以官方镜像为基底用--build-arg BASE_AIRFLOW_IMAGE显式传递基础镜像标签安装期USER 0交付期切回${AIRFLOW_UID}维护非 root 安全基线AIRFLOW_UID默认50000见 Dockerfile安装后清理缓存与临时文件apt 列表、mktemp -d临时目录、.install/.backup控制镜像体积。七、安全与维护注意事项参考镜像发布后基本固定按 docker-stack-docs/index.rst 的说明版本化参考镜像在发布后仅在极例外情况下更新不会随依赖新版本自动升级——即使其中包含安全修复也是如此。因此安全扫描发现第三方组件漏洞时官方给出的首选对策正是参照本文这类 Recipes 自建镜像基于最新基础镜像手动升级依赖。自建镜像的安全建议以官方最新镜像或slim系列为基底只安装实际需要的 extras 与 providers手动升级存在漏洞的依赖并把这一过程与定期升级 Airflow 版本相结合。源码完整性与供应链安全Hadoop/Hive 配方示范了导入官方 KEYS → 校验.asc签名的下载流程gcloud配方则示范了安装后立即执行gcloud --version做构建期验证。自定义配方时应沿用这两类实践。多架构支持参考镜像本身是多平台 AMD/ARM 镜像定制配方时注意架构相关的下载源参考 go-beam 配方的uname -a分支判断。结语本文基于 recipes.rst 官方文档完整拆解了 gcloud、Hadoop 技术栈、Beam Go 三种经过社区验证的镜像扩展配方它们共用ARG BASE_AIRFLOW_IMAGE传递基底、USER 0→USER ${AIRFLOW_UID}的权限切换、严格的 SHELL 选项与构建期验证三个骨架。结合 gcloud.Dockerfile、hadoop.Dockerfile、go-beam.Dockerfile 三个源文件以及GKEStartPodOperator、BeamRunGoPipelineOperator的源码注释你可以举一反三为自己的 Airflow 部署定制出既满足 Operator 运行时要求、又保持非 root 安全基线的专属镜像。若要贡献自己的配方只需参照 docker-stack-docs/docker-examples 目录中的现有示例提交 Pull Request 即可。【免费下载链接】airflowApache Airflow - A platform to programmatically author, schedule, and monitor workflows项目地址: https://gitcode.com/GitHub_Trending/ai/airflow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考