Комментарии 2
Спасибо за статью!
Пользуемся .airflowignore
Спасибо, как-то в документации не встречал
Используйте KubernetesPodOperator для запуска зависимостей и утилит, написанных не на Python.
И на Python тоже. Лучшей практикой будет обернуть все кастомные операторы в контейнер и запускать как KubernetesPodOperator, так вы избавитесь от множества проблем с версиями пакетов. И пайплайны будут простые и воспроизводимые (даже локально запустить будет проще).
Поэтому время от времени Composer предлагает апдейтнуть окружение: появляется кнопка, автоматически создается новый image, контейнеры и ваш инвайронмент переводится в новую версию Airflow.
Как у вас опыт с этим? Особенно интересно как апдейт окружение (изменение версии) подружить с Terraform
Спасибо, как-то в документации не встречал
Как и у любого проекта, обычно, документация пытается догнать фичи
И на Python тоже. Лучшей практикой будет обернуть все кастомные операторы в контейнер и запускать как KubernetesPodOperator, так вы избавитесь от множества проблем с версиями пакетов. И пайплайны будут простые и воспроизводимые (даже локально запустить будет проще).
Спасибо за дельный комментарий. Попробуем на новых операторах.
Как у вас опыт с этим? Особенно интересно как апдейт окружение (изменение версии) подружить с Terraform
Тут я к сожалению не подскажу, так-как для провиженинга окружения не используем Terraform. Вообще пока смотрим на это как на осторожную (требующую проверки) мануальную операцию.
Если у вас будут рабочие кейсы, я думаю сообщество будет признательно, если поделитесь в виде статьи или доклада.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Выжать максимум: Cloud Composer как fully-managed решение для Airflow