12 подписчиков
В ответ на пост
Как правильный вопрос может уменьшить объём работы?
Постановка задачи наталкивает нас, что должен быть некий UI для управления тасками. Мы можем пойти начать описывать свой интерфейс, свой back для него, авторизацию и множество чего ещё. При этом в задаче ничего не говорится про то, кто пользователь этого UI.
Поэтому, задав вопрос: «Кто пользователь UI, кто будет запускать парсеры?», мы получаем ответ, что это администраторы продукта.
Соответственно, им мы можем предложить какой-нибудь стандартный интерфейс, например Airflow закрывает большинство наших требований.
Таким образом, мы только что сэкономили несколько месяцев работы команды с компетенциями: front dev, back dev, test, design.
Как может выглядеть наш стек для данной задачи:
airflow-scheduler — Планировщик отслеживает все задачи и DAG, а затем запускает экземпляры задач после выполнения их зависимостей.
airflow-webserver — Веб-сервер с UI. UI ограничемся этим.
airflow-worker — Воркер выполняет задачи, заданные планировщиком. Запускает парсеры.
airflow-triggerer — Инициатор запускает цикл событий для отложенных задач.
postgres — База метаданных для работы Airflow.
redis — Выступает в качестве брокера для пересылки сообщений из планировщика в воркер.
S3/minio — Для хранения сырых данных.
docker — Каждый парсер заворачиваем в docker образ для возможности запуска из воркера airflow. В целевой картине воркеры могут через API kubernetes запускать поды с парсерами.
Prometheus, Grafana — Для работы с метриками.
OpenSearch, Fluentd и Kibana — Для работы с логами.
Будем продолжать раскапывать этот кейс?
Следующим шагом было бы разумно рассмотреть процесс поставки новых парсеров и отключение старых.
1 минута
13 ноября 2024