Подскажите, как вы решаете проблемы доступов на "коммунальном" сервере, если, на сколько я помню, у airflow нет разграничения прав на "группы" дагов. Как следствие, любой человек с нужными правами может дергать любой даг...
Если бы вы почитали документацию по поводу поднятия airflow в docker для прода, то смогли узнать, как стоит сделать. Выдавать рута контейнеру, когда его специально забрали - это очень не секьюрно и антипаттерн...
Ну и конечно момент "По факту, AirFlow в данной задаче - это уже был лишний инструмент ;-)))" прям совсем звучит странно, качаем руками, права сами правим, сами заливаем, действительно, зачем тут автоматизированный инструмент...
Все правильно, но у вас в примере, хоть и вынесено в гит, но по факту, вы накидали неидемпотентные башульки в ci/cd, которые никак не могут быть классифицированы, как однотипно-настроенное состояние системы.
И да, IaC может существовать вне gitops, но не уверен, что возможно обратное, по крайне мере, ни одна статья и ни один пример/опыт компании про это не говорит.
Выглядит очень красиво все и даже вроде удобно, но возникает множество тонкостей и вопросов, я правильно понимаю:
1. это не опенсорс?
2. саппорт 24/7 нет? SLA тоже нет?
3. это only облачный сервис?
4. 21 век на дворе, но IaC в каком либо виде отсутствует?
5. Почему не рассмотрели прикрутить свою визуализацию для, например, графаны?
6. Можно ли быть уверенным, что сервис не умрет, если пустить на него нормальную нагрузку и смотреть графики в истории? Что находиться в бекенде для хранения?
7. В целом, хотелось бы увидеть архитектуру приложения, чтобы понимать, какие там могут быть тонкости?
При includeAll вы надеетесь на последовательность, которая задается сортировкой встроенного механизма вывода папок/файлов, там есть первая проблема.
Если у вас разработчик1 пишет миграцию 158 в своей ветке, разработчик2 пишет миграцию тоже 158 в своей ветке, то когда будут мерджи, будут ошибки, которые легко не решить в веб-интерфейсе, и это я еще не зацепил момент, когда объекты этих двух разрабов пересекаются…
З.Ы. ну и главный момент, как вы будете контролировать корректный и последовательный деплой миграций между дев и прод, например?
Т.е. вы предлагаете дублировать и сопровождать два разных инструмента или у вас разработчики сидят тоже на этом же инструменте, который имеет технические ограничения по отказоустойчивости и имеет более сложный порог входа?
1. Я правильно понимаю, что вы изобрели свой airflow, который, помимо кучи технических проблем, накладывает ограничение на легкость внедрения из-за узкоспециализированных либ?
2. Почему на графике airflow у вас находиться в сложных enterprise решениях, а tableau наоборот? И почему pentaho у вас в free/opensource, когда там уже очень много всего закрытого и поприетарного?
Пойду по порядку:
1. стабильная версия, даже если смотреть на первую версию — это 1.10.14
2. очень плохо устанавливать библиотеки для кролика, постгреса, селери через отдельные установки, а не через зависимости apache-airflow, могут быть (и скорее всего будут) проблемы с зависимостями
3. установка apache-airflow[all] в версии 1.10 не гарантировала установку всех дополнительных пакетов, хоть документация и заявляет обратное…
P.S. Ну и самое главное, вы рассказали как установить все это, но ни одного слова по поводу настройки и масштабирования, включая автоматическое…
Прочитал статью здесь и на медиум, но так и не понял, в каком режиме тестировался кролик, только в режиме «записи на диск», т.е. режим «in memory» не тестировался и не сравнивался априори?
Заработать заработал, но вот подборка не персонализированная, настройки сбились и выдают ошибку на повторную установку. Проблема актуальна на сейчас.
Спасибо за статью, все хорошо пояснено, кроме "примечания", some_metric может быть равна нулю или быть меньше нуля...
Подскажите, как вы решаете проблемы доступов на "коммунальном" сервере, если, на сколько я помню, у airflow нет разграничения прав на "группы" дагов. Как следствие, любой человек с нужными правами может дергать любой даг...
Я написал, где все можно прочитать
Если бы вы почитали документацию по поводу поднятия airflow в docker для прода, то смогли узнать, как стоит сделать. Выдавать рута контейнеру, когда его специально забрали - это очень не секьюрно и антипаттерн...
Ну и конечно момент "По факту, AirFlow в данной задаче - это уже был лишний инструмент ;-)))" прям совсем звучит странно, качаем руками, права сами правим, сами заливаем, действительно, зачем тут автоматизированный инструмент...
Все правильно, но у вас в примере, хоть и вынесено в гит, но по факту, вы накидали неидемпотентные башульки в ci/cd, которые никак не могут быть классифицированы, как однотипно-настроенное состояние системы.
И да, IaC может существовать вне gitops, но не уверен, что возможно обратное, по крайне мере, ни одна статья и ни один пример/опыт компании про это не говорит.
GitOps начинается с IaC, но у вас этого что-то не видно...
А добавить докеригнор в докеригнор не пробовали? :D
1. это не опенсорс?
2. саппорт 24/7 нет? SLA тоже нет?
3. это only облачный сервис?
4. 21 век на дворе, но IaC в каком либо виде отсутствует?
5. Почему не рассмотрели прикрутить свою визуализацию для, например, графаны?
6. Можно ли быть уверенным, что сервис не умрет, если пустить на него нормальную нагрузку и смотреть графики в истории? Что находиться в бекенде для хранения?
7. В целом, хотелось бы увидеть архитектуру приложения, чтобы понимать, какие там могут быть тонкости?
Если у вас разработчик1 пишет миграцию 158 в своей ветке, разработчик2 пишет миграцию тоже 158 в своей ветке, то когда будут мерджи, будут ошибки, которые легко не решить в веб-интерфейсе, и это я еще не зацепил момент, когда объекты этих двух разрабов пересекаются…
З.Ы. ну и главный момент, как вы будете контролировать корректный и последовательный деплой миграций между дев и прод, например?
2. Почему на графике airflow у вас находиться в сложных enterprise решениях, а tableau наоборот? И почему pentaho у вас в free/opensource, когда там уже очень много всего закрытого и поприетарного?
1. стабильная версия, даже если смотреть на первую версию — это 1.10.14
2. очень плохо устанавливать библиотеки для кролика, постгреса, селери через отдельные установки, а не через зависимости apache-airflow, могут быть (и скорее всего будут) проблемы с зависимостями
3. установка apache-airflow[all] в версии 1.10 не гарантировала установку всех дополнительных пакетов, хоть документация и заявляет обратное…
P.S. Ну и самое главное, вы рассказали как установить все это, но ни одного слова по поводу настройки и масштабирования, включая автоматическое…