具有不同 conda 环境的气流

Question

我有一个生态系统，其中有多个 git 存储库。每个存储库都有自己的 conda 环境，该环境非常特定于该存储库和 does stuff。

在研究气流时，它似乎非常适合我面临的问题。

很多气流用户可能很熟悉我的堆栈，即：

• environment required for airflow 并不是我需要运行的所有代码的一刀切

我很想知道人们在野外是如何处理这个问题的。

大多数 [DAG][2] 是否调用 [bash 运算符][3] 与 [python 运算符][4]？

所有python operator 任务实际上是通过[requests][5] 或类似抽象的方式调用Web 服务的理想化愿景是什么？

我肯定计划使用气流来解决一些混乱的问题，但想确保我的构建方向正确，并且没有找到关于这个确切问题的组织清晰的文档。

在每个环境中安装气流并让每个气流实例拥有各种任务（这甚至可能导致我不熟悉的气流问题）似乎是 100% 次优的，并且不在项目的愿景中。如果我在这一点上错了，我应该立即改正​​。

感谢社区中可以为此提供指导的任何人。

[2]：https://airflow.apache.org/docs/apache-airflow/1.10.12/concepts.html#:~:text=In%20Airflow%2C%20a%20DAG%20%E2%80%93%20or,and%20their%20dependencies)%20as%20code。 [3]：https://airflow.apache.org/docs/apache-airflow/stable/howto/operator/bash.html [4]：https://airflow.apache.org/docs/apache-airflow/stable/howto/operator/python.html [5]：https://docs.python-requests.org/en/latest/

Answer 1

对于您的情况，您可以使用：

• PythonVirtualeEnvOperator - 这个每次需要时都会构建新的 virtualenv，所以可能有点脆弱
• KubernetesPodOperator - 您可以在其中拥有具有不同环境的不同映像变体，并为每项任务选择您想要的映像（需要 Kubernetes）
• DockerOperator - 与 KubernetesPodOperator 相同，但只需要 Docker 引擎

不过最好的方法是从 Airflow 2.2 开始。

在新的 Airflow 2.2（字面意思是几天前发布）中，您还拥有新的 @task.docker 装饰器，它可以让您结合两全其美：

1. 单独的图像以使您的环境保持隔离和可管理
2. 在 DAG 中作为常规修饰函数编写的 Python 代码。

更多信息在这里：

https://airflow.apache.org/docs/apache-airflow/stable/tutorial_taskflow_api.html#using-the-taskflow-api-with-docker-or-virtual-environments