N8n runners enabled

N8n Runners Enabled: Архитектура, Настройка и Практическое Применение

Концепция «Runners» в n8n представляет собой механизм горизонтального масштабирования и распределения выполнения рабочих процессов (workflows). Когда функция «N8n runners enabled» активирована, это означает, что экземпляр n8n перестает быть изолированным сервером и становится частью кластера, где обязанности по запуску рабочих процессов разделены между главным экземпляром (webhook processor, UI) и одним или несколькими воркерами (runners). Это фундаментальное изменение архитектуры, предназначенное для повышения производительности, отказоустойчивости и способности обрабатывать высокие нагрузки.

Архитектурный Сдвиг: От Монолита к Распределенной Системе

В стандартном, одиночном развертывании n8n выполняет все функции: обслуживает веб-интерфейс, принимает вебхуки, хранит данные и исполняет рабочие процессы. Это создает ограничения по производительности и создает единую точку отказа. Активация runners разделяет эти роли:

Главный экземпляр (Main Instance / Leader): Отвечает за обслуживание пользовательского интерфейса, управление рабочими процессами (создание, редактирование), прием триггеров (вебхуков, опросов) и постановку задач в очередь. Он является «мозгом» системы.
Воркеры (Workers / Runners): Это экземпляры n8n, запущенные с определенной конфигурацией. Их единственная задача — брать задания (активации рабочих процессов) из общей очереди (например, Redis) и выполнять их. Они не обслуживают UI и не принимают вебхуки напрямую.

Общая схема работы выглядит так:

Триггер (например, вебхук) срабатывает на главном экземпляре.
Главный экземпляр создает задание (execution) и помещает его в общую очередь сообщений.
Свободный runner извлекает это задание из очереди.
Runner загружает необходимые данные рабочего процесса и выполняет его.
Runner записывает результат выполнения (логи, статус, данные) в общую базу данных.
Главный экземпляр, отслеживая базу данных, отображает статус и результаты выполнения в UI пользователю.

Ключевые Компоненты для Активации Runners

Для корректной работы распределенного режима необходимы следующие внешние компоненты:

Общая База Данных: Все экземпляры (главный и runners) должны быть подключены к одной и той же PostgreSQL/MySQL базе данных. Это источник истины для рабочих процессов, учетных записей и метаданных выполнений.
Очередь Сообщений: Обязательно требуется Redis или аналогичная система очередей (например, RabbitMQ через отдельный пакет). Очередь служит для передачи заданий от главного экземпляра к runners.
Внешнее Хранилище Файлов (опционально, но рекомендуется): Для корректной работы с вложениями и бинарными данными между всеми узлами необходимо использовать внешнее хранилище, такое как S3, MinIO или Google Cloud Storage.

Подробная Конфигурация

Активация runners осуществляется через переменные окружения или конфигурационный файл. Ниже приведены ключевые настройки.

Конфигурация Главного Экземпляра (Producer)

EXECUTIONS_MODE=queue — самый важный параметр. Переключает n8n в режим очереди.
DB_TYPE=postgresdb — тип общей БД.
DB_POSTGRESDB_HOST=ваш-postgres-хост — хост БД.
QUEUE_BULL_REDIS_HOST=ваш-redis-хост — хост Redis для очереди.
N8N_ENCRYPTION_KEY=ваш-секретный-ключ — единый ключ шифрования для всех экземпляров.
Остальные настройки (порт, пользователь, пароль БД и Redis) задаются соответствующими переменными.

Конфигурация Воркера (Runner / Consumer)

Все те же настройки БД и Redis, что и у главного экземпляра.
EXECUTIONS_MODE=queue — также должен быть установлен.
N8N_ENCRYPTION_KEY=ваш-секретный-ключ — должен совпадать с ключом на главном экземпляре.
N8N_PROCESS_TYPE=worker — критически важная переменная, которая указывает экземпляру работать только как воркер, без веб-сервера и интерфейса.
Можно ограничить потребление ресурсов: EXECUTIONS_PROCESSOR_MAX_THREADS=10 (макс. потоков на runner).

Сравнение Режимов Выполнения

Параметр	Режим «regular» (по умолчанию)	Режим «queue» (runners enabled)
Архитектура	Монолитная (все в одном процессе)	Распределенная (главный экземпляр + воркеры)
Масштабируемость	Вертикальная (увеличение ресурсов сервера)	Горизонтальная (добавление новых runners)
Отказоустойчивость	Низкая (падение сервера останавливает все)	Высокая (падение runner’а не влияет на систему, задания забирают другие)
Обработка пиковых нагрузок	Ограничена мощностью одного сервера	Нагрузка распределяется по пулу воркеров
Сложность развертывания	Низкая (одна команда/контейнер)	Средняя/высокая (требует настройки БД, очереди, нескольких экземпляров)

Практические Сценарии Использования и Преимущества

Активация runners целесообразна в следующих случаях:

Высокая частота запусков рабочих процессов: Когда количество одновременных или запланированных выполнений превышает возможности одного сервера.
Длительные (Long-Running) рабочие процессы: Задачи, выполняющиеся минуты или часы, блокируют ресурсы главного экземпляра. Runners позволяют изолировать их выполнение.
Повышение доступности (High Availability): Главный экземпляр можно развернуть в отказоустойчивой конфигурации, а пул runners обеспечивает непрерывность выполнения бизнес-логики.
Разделение сред: Можно иметь выделенных runners для разных типов задач (например, отдельный runner для обработки платежей с повышенным приоритетом и безопасностью).
Облачные и контейнерные развертывания: Идеально подходит для оркестраторов Kubernetes, где можно автоматически масштабировать количество pods-runners в зависимости от нагрузки.

Потенциальные Проблемы и Особенности

Сложность отладки: Логи выполнения распределены между разными серверами. Необходимо использовать централизованное логирование (ELK Stack, Loki).
Зависимость от внешних сервисов: Отказ Redis или общей БД парализует всю систему.
Консистентность данных: Все узлы должны быть синхронизированы по времени (NTP). Критически важно использовать одинаковый N8N_ENCRYPTION_KEY.
Особые триггеры: Триггеры, основанные на опросе (polling), будут выполняться на главном экземпляре. Триггеры, активируемые событиями (вебхуки, сообщения из очереди), также инициируются на главном экземпляре, но само выполнение рабочего процесса передается runner’у.
Локальные переменные и секреты: Должны быть доступны на всех runners, если они используются в рабочих процессах.

Ответы на Часто Задаваемые Вопросы (FAQ)

Можно ли запустить несколько главных экземпляров для отказоустойчивости?

Нет, в текущей архитектуре n8n может быть активен только один главный экземпляр (с веб-сервером), который управляет триггерами и очередью. Для отказоустойчивости главного экземпляра требуется использовать механизмы активного/пассивного резервирования (например, с помощью Pacemaker или аналогичных оркестраторов), где в любой момент времени активен только один узел с ролью «main». Runners же могут быть множественными и активными одновременно.

Как передаются файлы и вложения между главным экземпляром и runners?

При использовании локальной файловой системы по умолчанию файлы, созданные на одном узле, будут недоступны на другом. Для корректной работы необходимо настроить внешнее хранилище объектов (S3, MinIO, GCS) через переменные окружения, такие как N8N_DEFAULT_BINARY_DATA_MODE и N8N_S3_*. Тогда все бинарные данные будут сохраняться и читаться из общего хранилища.

Можно ли запустить runner на отдельном сервере с другой ОС или архитектурой?

Да, это возможно, при условии, что версия n8n, ключ шифрования (N8N_ENCRYPTION_KEY) и конфигурация подключения к БД и Redis идентичны. Однако рекомендуется использовать одинаковые среды для избежания потенциальных проблем с зависимостями узлов.

Как отлаживать рабочий процесс, который выполняется на runner?

Прямая отладка на runner затруднена. Основной метод — использовать расширенное логирование внутри рабочего процесса (узлы «Function» или «Code» для вывода данных) и анализировать консольные логи runner’а через систему централизованного сбора логов. Также можно временно переключить конкретный рабочий процесс в режим «Manual» и запускать его вручную на главном экземпляре для отладки.

Влияет ли активация runners на работу вебхуков?

Да, но положительно. Главный экземпляр продолжает принимать HTTP-запросы вебхуков. Однако вместо того чтобы выполнять связанный рабочий процесс самостоятельно, он немедленно ставит задание в очередь. Это освобождает главный экземпляр для быстрого ответа на входящий запрос (например, возврата HTTP 200), что повышает стабильность и позволяет обрабатывать большие пиковые нагрузки вебхуков.

Можно ли смешивать режимы? Часть рабочих процессов на главном экземпляре, а часть на runners?

Нет, при активации режима очереди (EXECUTIONS_MODE=queue) все выполнения рабочих процессов, инициированные триггерами, будут помещаться в очередь для runners. Ручной запуск из интерфейса также будет отправлен в очередь. Разделение на уровне отдельных процессов невозможно. Однако можно управлять приоритетом заданий в очереди.

Как очистить «зависшие» задания в очереди?

Необходимо работать напрямую с системой очередей. Для Redis можно использовать клиент командной строки или инструменты администрирования для просмотра (команды KEYS bull:*) и удаления заданий из конкретных очередей Bull. Рекомендуется предварительно остановить всех runners и главный экземпляр перед такой очисткой.