Перейти к содержанию

CookBook Airflow in Docker

Страница в разработке!

-------------------

В данном cookbook разберем как правильно поднимать Airflow при помощи технологий Docker.

База

Apache Airflow - это платформа для создания, планирования и мониторинга рабочих процессов (конвейеров данных), написанных в виде DAG (ориентированных ацикличных графов).

Простым языком

Инструмент для автоматизации работы, выставления задач на расписание, возможность контролировать операции друг за другом.

Прежде чем перейти к настройке, важно понять, из каких компонентов состоит Airflow и какие дополнительные сервисы ему требуются. Ниже кратко вспомним компоненты и сервисы:

Сервисы используемые Airflow

Metadata Database (База данных метаданных) – внешний сервис базы данных, где Airflow хранит информацию о DAG’ах, задачах, история выполнений и т.д. Мы будем использовать PostgreSQL как пример основной базы данных Airflow.

Message Broker (Брокер сообщений) – необходим при использовании распределённого планировщика CeleryExecutor. Брокер (например, Redis или RabbitMQ) позволяет планировщику Airflow отправлять задания исполнителям (воркерам).

Компоненты Airflow

Airflow Webserver (Веб-сервер) – веб-интерфейс Airflow для мониторинга и управления, доступный по адресу http://localhost:8080 по умолчанию.

Airflow Scheduler (Планировщик) – компонент, который отслеживает расписание DAG’ов и запускает задачи, когда выполнены их зависимости.

Airflow Executor – определяет как задачи будут выполняться. Выбор режима исполнения (Executor): Airflow может работать в разных режимах исполнения задач:

  • CeleryExecutor – распределённый режим, при котором планировщик использует брокер сообщений для распределения задач на один или несколько воркеров.

  • LocalExecutor – локальный многопоточный режим. Все задачи запускаются локально в том же процессе (в отдельных тредах/процессах) планировщика без брокера. Подходит для одиночного сервера, упрощает настройку (не нужен Redis/RabbitMQ и воркер-контейнеры).

  • SequentialExecutor – последовательный режим (один поток), используется только для тестов или отладки, поскольку выполняет по одной задаче за раз. Нет смысла его применять даже для учебных проектов, поэтому практически не используется.

Airflow Worker (Исполнитель задач) – процессы-воркеры, выполняющие задачи.

Airflow Triggerer (Триггер) – компонент, введённый в Airflow 2+, обрабатывающий асинхронные операции (для сенсоров/триггеров). Позволяет задачам типа сенсор (sensor) и deferrable operators “заморозиться” и ожидать события.

Airflow DAG Processor (Парсер DAG) – (опционально выносится отдельно) процесс, который читает файлы DAG и парсит их. В стандартном docker-compose от Airflow может не быть отдельного контейнера для этого (парсер запускается внутри планировщика), но некоторые продвинутые композиции выделяют его.

Airflow Init (Инициализация) – вспомогательный одноразовый контейнер для инициализации среды: применяет миграции к базе данных и создаёт учетную запись администратора Airflow.

Flower (Monitoring UI) – опциональный веб-интерфейс для мониторинга Celery-кластера (доступен по http://localhost:5555, если включён)

Обрати внимание

Triggerer и DAG Processor это отдельные контейнеры, выполняющие свои функции изолировано.

Подготовка окружения и структуры проекта

1) Создаем рабочую директорию – в ней будут храниться файлы конфигурации и папки для DAG’ов, логов и плагинов.

Bash
mkdir -p airflow-project/{dags,logs,plugins}
Эти каталоги будут монтироваться в контейнеры Airflow, чтобы мы могли редактировать DAG-файлы на хосте, просматривать логи, добавлять плагины, и чтобы эти данные сохранялись между перезапусками контейнеров.

2) Создаем файл окружения .env – Docker Compose может загружать переменные окружения из .env файла в той же папке, что и compose-файл. Добавим переменную с пользователем AIRFLOW_UID- UID нашего текущего пользователя.

Для Windows и Linux/WSL

Для Windows Docker Desktop данное значение не критично – если AIRFLOW_UID не задан, будет выдано предупреждение, но его можно игнорироватьairflow.apache.org. Чтобы избавиться от предупреждения на Windows, можно просто вручную создать файл .env со строчкой AIRFLOW_UID=50000 (50000 – UID по умолчанию, используемый в образе Airflow) Для Linux/WSL в .env переменную AIRFLOW_UID – нужно указать UID текущего пользователя. Это нужно, чтобы запущенные контейнеры Airflow создавали файлы (в папках dags, logs, plugins) с нашим UID, а не с UID root. Иначе при совместном использовании volumes могут возникнуть проблемы с правами доступа.

Bash
echo -e "AIRFLOW_UID=$(id -u)" > airflow-project/.env

3) (Опционально) Сформировать Fernet Key – это ключ шифрования, используемый Airflow для хранения паролей подключений в базе данных.

Bash
python -c "from cryptography.fernet import Fernet; print(Fernet.generate_key().decode())"
Полученную строку (длиной 32 символа) запишем в .env как значение переменной AIRFLOW__CORE__FERNET_KEY. Тогда все контейнеры Airflow получат этот ключ из файла окружения и будут использовать его для шифрования/дешифрования паролей подключенийairflow.apache.org.

Примечание

Если пропустить этот шаг, Airflow всё равно запустится, но при перезапусках ключ может меняться, что затруднит работу с уже сохранёнными подключениями.

Более подробно про структуру Airflow будет отдельный пост, смотри за обновления в канале https://t.me/etl_kitchen

Airflow в Docker

Dockerfile

Подготовим dockerfile airflow где добавим зависимости requirements. Это необходимо для того чтобы контейнер сохранял установленные библиотеки и не переустанавливал их каждый раз при запуске.

Text Only
FROM apache/airflow:3.1.1

COPY requirements.txt /requirements.txt

RUN pip install --no-cache-dir "apache-airflow==${AIRFLOW_VERSION}" -r /requirements.txt