Migracja n8n na Traefik 3.3 i Postgres 16: przewodnik techniczny

# Bezpieczna migracja n8n: aktualizacja Traefik do 3.3 i Postgres do 16 bez utraty danych

Migracja n8n z przestarzałych wersji Traefik i Postgres na nowoczesny stos wymaga rozwiązania kluczowych problemów z kompatybilnością. W tym artykule znajdziesz techniczne przewodnictwo po zachowaniu danych i kont podczas przejścia z Traefik 1.x i Postgres 11 na aktualne wersje.

Przygotowanie: kopia zapasowa i klucz szyfrowania

Kluczowym etapem migracji jest prawidłowy eksport danych i zachowanie klucza szyfrowania. Bez niego dane uwierzytelniające (Credentials) staną się niedostępne po przeniesieniu. Dla n8n jest to krytyczne: system używa symetrycznego szyfrowania do przechowywania tokenów i haseł.

Wykonaj dwa obowiązkowe kroki:

• Utwórz zrzut bazy w formacie custom dla prawidłowego przywrócenia:

docker exec -t postgres_db pg_dump -U root -d n8n -Fc > /tmp/n8n_backup.dump
docker cp postgres_db:/tmp/n8n_backup.dump ./n8n_backup.dump

• Wyodrębnij aktualny klucz szyfrowania z konfiguracji. Źródło może być podwójne:

- Zmienna N8N_ENCRYPTION_KEY w docker-compose.yml

- Parametr encryptionKey w pliku ~/.n8n/config

Pominięcie tego kroku doprowadzi do błędu Needs first setup po uruchomieniu. System rozpozna bazę, ale nie będzie w stanie odszyfrować zapisanych danych uwierzytelniających.

Wdrażanie stosu: pułapki Traefik 3.3

Podczas wdrażania Traefik 3.3 pojawia się krytyczny problem niekompatybilności z Docker API. Router domyślnie używa przestarzałej wersji API (1.24), podczas gdy nowoczesne demony Dockera wymagają wersji 1.41 i wyższej. Objawia się to błędami 404 podczas próby wykrycia kontenerów.

Rozwiązanie — wymuszone ustawienie wersji API w zmiennych środowiskowych:

environment:
  - DOCKER_API_VERSION=1.41

Ta zmiana zmusza Traefik do poprawnego vzaimodeystviya z Docker Engine. Bez niej router nie widzi kontenerów n8n i Postgres, co uniemożliwia automatyczną konfigurację tras przez Docker Provider.

Zwróć uwagę na izolację sieciową: wszystkie serwisy muszą znajdować się we wspólnej niestandardowej sieci (n8n_net). To gwarantuje stabilną interakcję między kontenerami bez konfliktów routingu. Przykład poprawnej konfiguracji:

networks:
  n8n_net:
    name: n8n_net

services:
  traefik:
    networks:
      - n8n_net
  n8n:
    networks:
      - n8n_net
  postgres_db:
    networks:
      - n8n_net

Przywrócenie bazy w Postgres 16: rozwiązanie problemów z uprawnieniami

Postgres 16 wprowadza zmiany w domyślnej polityce bezpieczeństwa. Schemat public ma teraz ograniczone uprawnienia, co powoduje błąd permission denied for schema public podczas uruchamiania n8n.

Po przywróceniu zrzutu wykonaj:

docker cp n8n_backup.dump postgres_db:/tmp/
docker exec -i postgres_db pg_restore -U root -d n8n -1 /tmp/n8n_backup.dump

Następnie nadaj właścicielowi bazy pełne uprawnienia do schematu:

docker exec -it postgres_db psql -U root -d n8n -c "GRANT ALL ON SCHEMA public TO root;"

Ten krok jest konieczny, ponieważ n8n intensywnie korzysta ze schematu public do przechowywania metadanych. Pominięcie go doprowadzi do cyklicznego awarii kontenera n8n.

Poprawka Credentials: unikamy błędu "Needs first setup"

Nawet przy poprawnej transmisji N8N_ENCRYPTION_KEY przez zmienne środowiskowe n8n może go zignorować. Przyczyna — konflikt między zmienną środowiskową a lokalnym plikiem konfiguracyjnym. Podczas pierwszego uruchomienia system generuje nowy plik ~/.n8n/config, który nadpisuje klucz ze zmiennych.

Rozwiązanie:

• Usuń plik konfiguracyjny wewnątrz kontenera:

docker exec -it n8n rm /home/node/.n8n/config

• Uruchom ponownie serwis:

docker compose restart n8n

Ten krok zmusza n8n do użycia klucza ze zmiennych środowiskowych, a nie z lokalnego pliku. Upewnij się, że w docker-compose.yml podana jest oryginalna zmienna N8N_ENCRYPTION_KEY.

Dodatkowe niuanse: procesy w tle i SQLite

Podczas migracji mogą wystąpić problemy z zadaniami w tle korzystającymi z SQLite (np. parsery Telegram na Telethon). Po przeniesieniu pojawia się błąd sqlite3.OperationalError: database is locked.

Przyczyna — resztkowe pliki logowania (.session-journal, .session-wal), które blokują bazę. Rozwiązanie:

• Zainstaluj narzędzie psmisc:

apt install psmisc -y

• Wymuś zakończenie procesów trzymających blokadę:

fuser -k -v /root/parser_folder/session_name.session

• Usuń pliki tymczasowe:

rm -f /root/parser_folder/session_name.session-journal
rm -f /root/parser_folder/session_name.session-wal

• Uruchom ponownie usługę:

systemctl restart imię_sluzhby.service

Ważne: usuwanie logów nie wpływa na główny plik sesji. Autoryzacja w Telegramie jest zachowana.

Co ważne

• Klucz szyfrowania jest obowiązkowy — bez oryginalnego N8N_ENCRYPTION_KEY wszystkie Credentials staną się niedostępne.
• Traefik wymaga jawnego wskazania API — parametr DOCKER_API_VERSION=1.41 jest krytyczny dla wykrywania kontenerów.
• Postgres 16 ogranicza uprawnienia — konieczne jest ręczne wydanie GRANT ALL ON SCHEMA public.
• Lokalna konfiguracja n8n koliduje — usunięcie ~/.n8n/config rozwiązuje problem z kluczem szyfrowania.
• Blokady SQLite wymagają czyszczenia — usunięcie plików .journal i .wal przywraca działanie procesów w tle.

Po wykonaniu wszystkich kroków n8n uruchomi się z zachowaniem wszystkich procesów roboczych, webhooków i danych uwierzytelniających. Migracja między głównymi wersjami oprogramowania zawsze niesie ryzyka, ale przestrzeganie tych procedur minimalizuje przestoje i utratę danych.

— Editorial Team