Learning Platform
Глоссарий Troubleshooting
Урок 01.03 · 20 мин
Начальный
SetupDocker ComposeAirflow CLIWeb UI

Окружение и first run

Этот урок — практический. К концу у вас будет работающий Airflow 2.10/2.11 в Docker, запущенный DAG, понимание базовых компонентов UI и CLI. Дальнейшие модули предполагают, что окружение поднято.


Требования

  • Docker Desktop / OrbStack — для macOS лучше OrbStack (быстрее, меньше памяти)
  • Минимум 4 ГБ свободной оперативной памяти для Airflow + Postgres + Redis
  • Python 3.11 — для запуска уроков и labs локально вне Docker
  • psql клиент — для прямого доступа к metadata DB (brew install libpq или apt install postgresql-client)
TIP

На macOS OrbStack заметно быстрее Docker Desktop и потребляет меньше памяти. Для labs курса разница ощутимая — особенно когда поднимаете multi-scheduler HA setup.


Установка через official docker-compose

Apache Airflow публикует официальный docker-compose.yaml для quick start. Скачайте его для версии 2.10.5 (LTS-патч):

mkdir airflow-course-env && cd airflow-course-env

curl -LfO 'https://airflow.apache.org/docs/apache-airflow/2.10.5/docker-compose.yaml'

mkdir -p ./dags ./logs ./plugins ./config

echo -e "AIRFLOW_UID=$(id -u)" > .env

Структура папок после команд:

airflow-course-env/
├── docker-compose.yaml    # Описание сервисов
├── .env                   # AIRFLOW_UID для прав на logs
├── dags/                  # Сюда складываете .py с DAG (mount в scheduler/worker)
├── logs/                  # Логи task instances
├── plugins/               # Custom plugins
└── config/                # airflow.cfg overrides

Запустите:

docker compose up airflow-init     # Однократно — инициализирует metadata DB
docker compose up -d               # Запускает все сервисы в фоне

После старта вы получите:

СервисПортЧто делает
postgres5432Metadata database (Airflow state)
redis6379Celery broker
airflow-webserver8080Flask Web UI + REST API v1
airflow-schedulerГлавный процесс scheduler (+ DagFileProcessor pool внутри)
airflow-workerCelery workers
airflow-triggererAsync triggers (deferrable operators)

Откройте http://localhost:8080 — увидите Airflow UI. Дефолтный логин/пароль: airflow / airflow.


Архитектура: что вы только что запустили

Минимальный setup Airflow 2.x
Webserver (Flask + FAB)airflow-webserver. Flask + Flask-AppBuilder + Gunicorn. Server-rendered UI на Jinja templates. REST API v1 (Flask-RESTful). В Airflow 3.x заменено на FastAPI + React (Task SDK boundary).
SQLAlchemy direct (2.x)
SchedulerГлавный мозг Airflow. Парсит DagBag (через DagFileProcessor pool внутри scheduler-процесса в 2.x), создаёт DagRun-ы по schedule, переводит TaskInstance scheduled → queued, кидает в executor. Может быть несколько scheduler-ов одновременно для HA (с 2.0).
TriggererОтдельный процесс с asyncio event loop. Держит тысячи активных triggers (для deferrable operators, AIP-40 stable с 2.5). Может быть несколько штук для HA.
Celery WorkerОдин или несколько worker pod-ов. Получают tasks из Redis broker, выполняют их через SQLAlchemy direct DB access, пишут результат в result backend (тот же Postgres). Concurrency на worker = worker_concurrency.
PostgreSQLMetadata database. Сердце Airflow. Таблицы: dag, dag_run, task_instance, xcom, connection, slot_pool, serialized_dag, trigger, log. Все компоненты (scheduler, workers, webserver, triggerer) конкурируют здесь через row-level locks. В 2.x workers имеют direct DB access.
RedisCelery broker. Queue для tasks. Один queue на executor instance + дополнительные queues для priority routing. Result backend Celery — Postgres (не Redis).

В модуле 01 мы детально разберём роль каждого компонента и почему в 2.x scheduler сам парсит DAGs, а в 3.x появился standalone DAG Processor.

NOTE

В 2.x DagFileProcessor — это пул дочерних процессов внутри scheduler-процесса (запускается через multiprocessing). Можно запустить standalone DAG Processor через airflow dag-processor, но это опциональная оптимизация для production. В 3.x этот компонент стал mandatory отдельным процессом (AIP-66).


Первый DAG

Создайте dags/hello_world.py:

from airflow.decorators import dag, task
from datetime import datetime

@dag(
    schedule=None,
    start_date=datetime(2026, 1, 1),
    catchup=False,
    tags=["intro"],
)
def hello_world():
    @task
    def say_hello() -> str:
        return "Hello from Airflow 2!"

    @task
    def shout(message: str):
        print(message.upper())

    shout(say_hello())

hello_world()

Несколько секунд — и DAG появится в UI (scheduler парсит каждые 30 секунд). Триггер вручную через кнопку Play → Trigger DAG, потом откройте Grid View — увидите execution.


Базовый CLI

Все важные операции доступны через airflow CLI внутри контейнера:

# Зайти в scheduler container
docker compose exec airflow-scheduler bash

# Список DAGs
airflow dags list

# Список tasks в конкретном DAG
airflow tasks list hello_world

# Triggered run конкретного DAG
airflow dags trigger hello_world

# Запустить task локально для тестов (без scheduler!)
airflow tasks test hello_world say_hello 2026-05-12

# Проверить parse errors в DAGs
airflow dags list-import-errors

# Backfill за прошлые даты
airflow dags backfill hello_world --start-date 2026-05-01 --end-date 2026-05-05

# Очистить metadata DB от старых runs (2.5+)
airflow db clean --keep-last 30

Прямой доступ к Postgres

Один из главных навыков для отладки — смотреть metadata DB напрямую:

docker compose exec postgres psql -U airflow -d airflow

# Список таблиц
\dt

# Состояние DagRun-ов
SELECT dag_id, run_id, state, start_date, end_date
FROM dag_run
ORDER BY start_date DESC LIMIT 10;

# Состояние конкретных TI
SELECT task_id, state, try_number, queued_dttm, start_date
FROM task_instance
WHERE dag_id = 'hello_world'
ORDER BY start_date DESC;

В модулях 04 и 05 мы будем активно использовать прямые SQL-запросы, чтобы понять, что делает scheduler в реальном времени.

WARNING

В production никогда не подключайтесь к metadata DB как Airflow user для запросов на чтение из приложений. У него широкие права. Создайте отдельного read-only пользователя.


Что дальше

В модуле 01 мы разберём процесс-level архитектуру 2.x: что делает Webserver vs Scheduler vs Workers vs Triggerer, как DagFileProcessor живёт внутри scheduler, как Workers получают tasks через Celery broker. Перед этим убедитесь, что:

  • docker compose up -d поднимает все сервисы без ошибок
  • UI открывается на :8080, виден ваш hello_world DAG
  • docker compose exec airflow-scheduler airflow dags list показывает DAG
  • docker compose exec postgres psql -U airflow -d airflow -c '\dt' показывает таблицы

Проверка знанийKnowledge check
В чём отличие минимального setup Airflow 2.x от Airflow 3.x по составу процессов?
ОтветAnswer
В 2.x минимальный setup: webserver (Flask), scheduler (включая DagFileProcessor pool), worker (Celery), triggerer (asyncio), postgres, redis. В 3.x: apiserver (FastAPI вместо Flask webserver), scheduler, **standalone DAG Processor (mandatory)**, worker (теперь через Task SDK без DB access), triggerer, postgres, redis. Ключевое отличие: в 3.x DAG Processor вынесен в отдельный процесс (AIP-66), workers общаются с control plane только через REST API (AIP-72 Task SDK), и webserver заменён на FastAPI с React UI.

Проверьте понимание

Результат: 0 из 0
Концептуальный
Вопрос 1 из 4. Какие компоненты обязательно поднимаются при `docker compose up` для Airflow 2.x?

Закончили урок?

Отметьте его как пройденный, чтобы отслеживать свой прогресс

Войдите чтобы оценить урок

Прогресс модуля
0 из 3