morfix.ru
Почему n8n требует обновления инфраструктуры?
Проект n8n, как любое серьёзное приложение для автоматизации рабочих процессов, развивается быстро. Версии Traefik 1.x и PostgreSQL 11 давно вышли из поддержки, оставляя системы уязвимыми и неэффективными. Но главная проблема — это совместимость: новые версии n8n перестают работать со старыми компонентами инфраструктуры. Миграция неизбежна, но её нужно провести правильно, чтобы не потерять данные работников, истории выполнения автоматизаций и конфиги сложных workflow.
В этой статье мы разберём реальный сценарий обновления с акцентом на сохранение данных, резервные копии и пошаговую стратегию миграции.
Подготовка: аудит текущего состояния
Перед любой миграцией нужно понять, что у вас есть. Команда должна создать инвентарь всех компонентов и определить объём данных.
Что проверить
- Размер базы данных PostgreSQL 11: команда
SELECT pg_database.datname, pg_size_pretty(pg_database_size(pg_database.datname)) FROM pg_database;покажет объём. Если БД больше 100 ГБ, придётся распланировать окно обслуживания тщательнее. - Количество рабочих процессов в n8n: это основная метрика для планирования времени миграции.
- Версия Traefik и его конфигурация: версия 1.x использует совершенно другой синтаксис чем 3.3. Экспортируйте текущие правила маршрутизации.
- Зависимости приложения: проверьте, какие внешние сервисы и API интегрированы с n8n.
- Текущий бэкап-процесс: убедитесь, что у вас есть актуальная резервная копия.
Стратегия миграции: горячее переключение против холодного старта
Существует два подхода, каждый с плюсами и минусами.
Холодная миграция (рекомендуется для большинства)
Останавливаем n8n, снимаем полный бэкап PostgreSQL 11, создаём новую инстанцию PostgreSQL 16, восстанавливаем данные, обновляем Traefik, запускаем n8n. Время простоя: от 30 минут до нескольких часов в зависимости от размера БД.
Преимущества: надёжность, простота откатки, полный контроль над процессом.
Горячая миграция (для критичных систем)
Запускаем новый стек параллельно, синхронизируем данные в реальном времени через репликацию PostgreSQL, проводим финальное переключение. Время простоя: минуты.
Недостатки: высокая сложность, требует expertise, больше точек отказа.
Для большинства проектов холодная миграция предпочтительнее. Рассмотрим именно её.
Пошаговая инструкция миграции
Шаг 1: Резервная копия
pg_dump -h localhost -U postgres -d n8n_db > n8n_backup_$(date +%Y%m%d_%H%M%S).sqlСохраните дамп на отдельном хранилище — не на той же машине. Проверьте размер файла и убедитесь, что у вас достаточно места на целевом сервере.
Шаг 2: Подготовка PostgreSQL 16
Установите PostgreSQL 16 на новый сервер или отдельный порт. Создайте пользователя и базу:
createuser -U postgres n8n_user
createdb -U postgres -O n8n_user n8n_dbШаг 3: Восстановление данных
psql -U postgres -d n8n_db < n8n_backup.sqlЭто самый длительный этап. Для больших БД может занять часы. Используйте утилиту pv для мониторинга прогресса:
pv n8n_backup.sql | psql -U postgres -d n8n_dbШаг 4: Миграция конфигурации Traefik
Здесь главное отличие между версиями. Traefik 1.x использовал файлы конфигурации в формате TOML с простой структурой. Traefik 3.3 требует динамической конфигурации через провайдеры (Docker, Kubernetes, статические файлы).
Пример конфигурации Traefik 3.3 для n8n:
[entryPoints]
[entryPoints.web]
address =