对于 Linux 和 Airflow 容器，我们必须向容器提供主机用户 ID：
“在 Linux 上，快速启动需要知道您的主机用户 ID，并且需要将组 ID 设置为 0。否则，在 dags、日志和插件中创建的文件将以 root 用户所有权创建。您必须确保为 docker-compose 配置它们：mkdir -p ./dags ./logs ./plugins echo -e "AIRFLOW_UID=$(id -u)" > .env”
https://airflow.apache.org/docs/apache-airflow/stable/howto/docker-compose/index.html*
但是我们团队里既有使用 Windows 的开发人员，也有使用 Linux 的开发人员。如何将这两者合并为一个 docker-compose 文件，让配置统一，让两者都能正常工作呢？
答案1
您不必担心这个差异。
在 Linux 上，您提到的命令会将当前用户的 UID 记录到 airflow 环境配置中，以便应用程序在该用户下启动。这使得应用程序生成的所有配置文件和文件夹都归登录用户所有，因为它们从用户的当前目录挂载到 docker 容器。
注意：下面我所写的所有内容都假设您在 Windows 上使用 Linux 容器。如果您正在运行 Windows 原生容器，则需要检查是否有特定的气流指令。
在 Windows 上，运行 docker 容器最常见的方式是在 WSL“虚拟机”中运行它们，其中计算机的一小部分资源用于启动 Windows 内部的 Linux 发行版。
如果您的开发人员已经直接使用 WSL，并在 WSL 实例中安装了 docker，那么同样的步骤也适用。就 airflow 而言，它在 Linux 主机中运行，并且它不介意这一切都在另一个 Windows 应用程序中。如果您/您的开发人员习惯于以 Linux 为中心的开发工作流程，即使在 Windows 中也是如此。
另一方面，如果您主要关注 Windows，那么您的开发人员可能会使用 Docker Desktop 或类似的解决方案。大多数（如果不是全部）这些都会启动 Linux 虚拟机（可能本身使用 WSL），并在其提供的 Linux 环境中运行 docker。在这种情况下，dags/ logs/plugins目录将位于 Windows 文件夹中，然后将其映射到 WSL 发行版，并在容器内安装。在这种情况下，当 WSL 将 Windows 端文件转换为 Linux 端访问时，它会映射“在 Windows 上登录的任何用户”，您担心的问题就消失了。