Управление рабочими процессами и зависимостями непрерывной интеграции Apache Airflow

Я подумываю начать использовать Apache Airflow для проекта, и мне интересно, как люди управляют непрерывной интеграцией и зависимостями с помощью воздушного потока. В частности, скажем, у меня есть следующие настройки

3 сервера Airflow: разработка и производство.

У меня есть два Python DAG, исходный код которых я хочу сохранить в отдельных репозиториях. Сами DAG просты, в основном просто используйте оператор Python для вызова main (* args, ** kwargs). Однако на самом деле код, выполняемый main, очень велик и растягивает несколько файлов / модулей. Каждая база кода Python имеет разные зависимости, например,

Dag1 использует Python2.7 pandas == 0.18.1, запросы = 2.13.0

Dag2 использует Python3.6 pandas == 0.20.0 и Numba == 0.27, а также некоторый цитонизированный код, который необходимо скомпилировать.

Как мне управлять Airflow, запускающим эти два Dag с совершенно разными зависимостями? Кроме того, как мне управлять непрерывной интеграцией кода для обоих этих Dags в каждую отдельную среду Airflow (dev, staging, Prod) (я просто получаю jenkins или что-то еще для ssh на сервер воздушного потока и делаю что-то вроде git pull origin BRANCH )

Надеюсь, этот вопрос не слишком расплывчатый, и люди видят мои проблемы.


person Roger Thomas    schedule 10.07.2017    source источник


Ответы (1)


Мы используем docker для запуска кода с разными зависимостями и DockerOperator в Airflow DAG, который может запускать контейнеры докеров, также на удаленных машинах (с уже запущенным демоном докеров). На самом деле у нас есть только один сервер воздушного потока для выполнения заданий, но больше машин с запущенным демоном докеров, который вызывают исполнители воздушного потока.

Для непрерывной интеграции мы используем gitlab CI с реестром контейнеров Gitlab для каждого репозитория. Это должно быть легко сделать с помощью Jenkins.

person Him    schedule 15.07.2017
comment
Спасибо @Him, я более или менее пришел к тем же выводам, но с зависимостями python, заключенными в virtualenv, а не с использованием DockerOperator, но вполне может в конечном итоге переключиться на это. - person Roger Thomas; 17.07.2017