Вправа n8n Queue Mode з Docker Compose: доведіть, що завдання виконав воркер
Практична вправа з режимом черги n8n у Docker Compose: сервіси, змінні середовища та перевірка логів, яка підтверджує виконання завдання воркером.
Перевірено за наведеними джерелами .
Редакційна вправа: формулювання завдання та мета
Це редакційна вправа: завдання, яке варто спробувати у власному середовищі, а не звіт про те, як ми його виконали. Мета — розгорнути режим черги (queue mode) n8n за допомогою Docker Compose, з'єднавши основний процес, черга Redis та щонайменше один воркер, а потім довести, що завдання насправді виконав саме воркер, а не основний процес. Власний пост n8n про бенчмарк, який описує тестовий прогін у вересні 2025 року й був опублікований у блозі n8n у січні 2026 року, подає режим черги як перший необхідний крок до масштабування самостійно розгорнутого інстансу, а не як опціональне доповнення — саме тому ця вправа будує саме режим черги, а не залишається при одному контейнері.
У задокументованій n8n архітектурі режиму черги основний інстанс отримує триґери, як-от вебхуки, тоді як окремі інстанси-воркери виконують самі запуски робочих процесів; ваш Compose-файл має точно відтворити цей розподіл, інакше ви фактично не перевірили режим черги. Ми вважаємо, що це розділення — найважливіша ідея, яку варто засвоїти ще до того, як братися за Docker Compose, бо кожна змінна середовища і кожен крок з усунення несправностей нижче існують саме для того, щоб її підтримати.
Sources: The n8n Scalability Benchmark – n8n Blog, Enable queue mode | Deploy | n8n Docs
Передумови та вхідні дані для режиму черги n8n
Перш ніж відкривати compose-файл, документація n8n з встановлення через Docker перелічує дві передумови: Docker Desktop, який включає Docker Compose, та робочі знання з налаштування й захисту серверів і контейнерів. Сама n8n наразі позначає цю сторінку як застарілу, тож актуальними варто вважати лише ці загальні передумови, а не будь-які номери версій чи команди, наведені там.
Для запуску режиму черги n8n через Docker Compose потрібні чотири вхідні сервіси: Redis для черги завдань, база даних, основний процес n8n та щонайменше один процес-воркер. Ми рекомендували би визначитися з Postgres від самого початку, а не додавати його пізніше, бо заміна бази даних під уже запущеним налаштуванням режиму черги значно складніша, ніж обрати її заздалегідь.
| Сервіс | Роль | Ключове налаштування |
|---|---|---|
| Redis | Зберігає черги завдань між основним процесом і воркерами | Стандартний порт, доступний за іменем хоста з інших сервісів |
| База даних | Зберігає робочі процеси, облікові дані та дані виконань | Рекомендуємо Postgres від самого початку, згідно з нашою ж порадою |
| Main (основний) | Отримує триґери та додає завдання до черги | EXECUTIONS_MODE=queue, спільний ключ шифрування |
| Worker (воркер) | Забирає завдання з черги та виконує їх | EXECUTIONS_MODE=queue, той самий ключ шифрування, опціональний флаг --concurrency |
Два параметри мають збігатися в усіх сервісах. Документація n8n вказує встановити EXECUTIONS_MODE у значення queue як на основному інстансі, так і на кожному воркері, і зазначає, що ключ шифрування основного інстансу потрібно передати всім вузлам-воркерам, оскільки воркерам він потрібен для розшифрування збережених облікових даних.
Sources: Install with Docker | Deploy | n8n Docs, Enable queue mode | Deploy | n8n Docs, Executions | Deploy | n8n Docs, Control concurrency | Deploy | n8n Docs
Кроки побудови: налаштування режиму черги n8n з Docker Compose
Ось режим черги n8n з Docker Compose, розбитий на сервіси, які ви додаєте в такому порядку.
- Додайте сервіс Redis без особливих змінних середовища, доступний внутрішньо для інших сервісів.
- Додайте сервіс бази даних з її обліковими даними та постійним томом (volume).
- Додайте основний (main) сервіс з EXECUTIONS_MODE=queue, з'єднанням до бази даних, хостом і портом Redis, спільним ключем шифрування та опублікованим портом для редактора і вебхуків.
- Додайте сервіс-воркер з тим самим EXECUTIONS_MODE, ключем шифрування, налаштуваннями бази даних і Redis, запущений командою worker без опублікованого порту.
Документація n8n описує паралельність на рівні воркера (concurrency) — скільки завдань один воркер виконує одночасно — як окремий механізм від паралельності звичайного режиму, що контролюється флагом --concurrency, тоді як ширший захисний механізм паралельності виконань у продакшені вимкнено за замовчуванням на самостійно розгорнутих інстансах. Для першого проходу з n8n queue mode docker залишіть обидва параметри за замовчуванням і починайте з одного воркера; налаштовуйте паралельність лише після того, як підтвердите, що базовий потік main-Redis-worker працює.
Sources: Enable queue mode | Deploy | n8n Docs, Control concurrency | Deploy | n8n Docs, Executions | Deploy | n8n Docs
Критерії завершення: доведення, що завдання виконав воркер
Завершення цієї вправи означає більше, ніж просто відсутність помилки. Вам потрібно запустити робочий процес через вебхук і показати, що запис про цей конкретний запуск з'являється в логу воркера, а не лише в логу основного процесу. Надана документація n8n не містить одного готового прикладу для цього; метод нижче редакційно поєднує дві окремо задокументовані функції, тож сприймайте його як наше власне поєднання, а не офіційну процедуру.
Документація n8n рекомендує надавати кожному воркеру унікальний шлях до журналу подій, коли воркери спільно використовують файлову систему з правом запису, та окремо описує рівень debug як найдетальніший рівень логування, вивід якого можна надсилати в консоль, у файл або в обидва місця. Встановіть рівень логування воркера на debug і вкажіть для нього окремий файл, запустіть вебхук, а потім відкрийте цей файл і переконайтеся, що виконання там відображається.
Варто чітко зазначити одне застереження: n8n документує сторінку Settings > Workers для спостереження за запущеними воркерами, але лише на планах self-hosted Enterprise та n8n Cloud Enterprise, тож читачі з Community-редакцією, які виконують цю вправу, не можуть покладатися на цей інтерфейс і мають натомість скористатися описаною вище перевіркою за логами.
Sources: Enable queue mode | Deploy | n8n Docs, Set up logging | Deploy | n8n Docs
Усунення несправностей та підсумки
За нашим досвідом, гарна перша перевірка — чи може воркер розшифрувати облікові дані, бо це часто зводиться до неспівпадіння ключа шифрування між main і worker. Далі перевірте, чи воркер взагалі може дістатися до Redis, бо невідповідність мережевих налаштувань у Compose — часта причина того, що завдання потрапляють до черги, але ніколи не обробляються, особливо коли запущено лише один воркер із надто низьким значенням паралельності.
- Переконайтеся, що N8N_ENCRYPTION_KEY точно збігається між main і worker
- Переконайтеся, що воркер може дістатися до Redis за налаштованим хостом і портом
- Переконайтеся, що деталі з'єднання з базою даних збігаються на main і worker
- Переконайтеся, що контейнер воркера запускає команду worker, а не стандартну команду main
Під час налагодження варто тримати в полі зору мотивацію цього всього. Той самий бенчмарк зафіксував 72 запити на секунду, а затримка залишалася нижче трьох секунд у навантажувальному тесті з одним вебхуком у режимі черги. Це власноруч заявлене n8n число на конкретному тестовому обладнанні, а не гарантія для вашого налаштування, тож сприймайте це як контекст того, чому ця архітектура важлива, а не як ціль для відтворення.
Ми би радили обережно ставитися до гонитви за цими показниками пропускної здатності в навчальній вправі: мета тут — правильно з'єднане налаштування main-worker-Redis, яке ви можете пояснити, а не число, скопійоване з чужого інстансу AWS.
Як орієнтовне рішення, завершена вправа повинна закінчуватися запущеними контейнерами main, worker, Redis і бази даних, вебхуком, який успішно повертає відповідь, та файлом журналу воркера, що містить запис про це виконання, тоді як лог основного процесу показує лише те, що запит було отримано й додано до черги. Це і є весь образ режиму черги n8n з Docker Compose для одного воркера: якщо будь-якого з цих трьох елементів немає, налаштування ще не завершене, яким би не була відповідь вебхука.
Sources: Enable queue mode | Deploy | n8n Docs, Control concurrency | Deploy | n8n Docs
