1) DAG берётся из репозитория на github, ссылка на репозиторий есть в статье (шаг по установке airflow через helm) (есть на схеме работы Airflow) 2) Образ запускается DAG'ом, внутри самого образа лежит скрипт 3) Pod template в нашем случае генерится автоматически оператором, если есть необходимость использовать отдельный темплейт то можно посмотреть примеры в оф. документации Airflow 4) Авторизация не раскрывалась в статье из-за того, что если это всё расписывать то она станет слишком громоздкой. Airflow использует сервисаккаунт для запуска POD'ов, а gitsync не использует в нашем случае авторизацию, т.к. гитхаб не требует её для публичных репозиториев.
Для прода подходит (само собой - придётся что-то подкрутить под себя).
Не через докер для того, чтобы наглядно и пошагово показать процесс, с докером будет выглядеть не так наглядно что происходит "под капотом".
Scheduler на моей практике чаще всего умирает из-за того, что в разделе не хватает места для логов - в таком случае необходимо настроить ротацию. Ставить ещё один не вижу смысла (может я и не прав, конечно) - вместо одного контейнера будут падать два. Нужно выяснить из-за чего падает контейнер и устранить причину.
1) DAG берётся из репозитория на github, ссылка на репозиторий есть в статье (шаг по установке airflow через helm) (есть на схеме работы Airflow)
2) Образ запускается DAG'ом, внутри самого образа лежит скрипт
3) Pod template в нашем случае генерится автоматически оператором, если есть необходимость использовать отдельный темплейт то можно посмотреть примеры в оф. документации Airflow
4) Авторизация не раскрывалась в статье из-за того, что если это всё расписывать то она станет слишком громоздкой. Airflow использует сервисаккаунт для запуска POD'ов, а gitsync не использует в нашем случае авторизацию, т.к. гитхаб не требует её для публичных репозиториев.
k8s + официальный helm чарт должны решить эту проблему.
(Но насчёт разделения сред не уверен).
На связи автор статьи.
Для прода подходит (само собой - придётся что-то подкрутить под себя).
Не через докер для того, чтобы наглядно и пошагово показать процесс, с докером будет выглядеть не так наглядно что происходит "под капотом".
Scheduler на моей практике чаще всего умирает из-за того, что в разделе не хватает места для логов - в таком случае необходимо настроить ротацию. Ставить ещё один не вижу смысла (может я и не прав, конечно) - вместо одного контейнера будут падать два. Нужно выяснить из-за чего падает контейнер и устранить причину.
А будут ли статьи с рассмотрением других аннотаций, кроме BPMN?