Migracja z Heroku

Przenieś aplikację z Heroku razem z bazą danych, config vars i domeną.

Ten przewodnik opisuje przeniesienie jednej aplikacji z Heroku na Nodion: kodu, config vars, Heroku Postgres, Heroku Key-Value Store, zadań Scheduler i własną domenę. Zaplanuj krótką przerwę w zapisach na czas kopiowania bazy danych. Nie ma importera dla app.json ani heroku.yml; każdy krok poniżej to kilka kliknięć lub poleceń.

Odpowiedniki usług i funkcji

1. Utwórz projekt i bazę danych

Utwórz projekt, a w nim bazę danych PostgreSQL w regionie, w którym ma działać aplikacja (EU Central dla Frankfurtu nad Menem). Aplikacja i jej baza danych muszą być w tym samym regionie; Nodion nie pozwala podłączyć bazy z innego regionu. Wybierz wersję Postgres co najmniej tak nową jak wersja Twojej bazy na Heroku. Więcej w sekcji Bazy danych.

2. Skopiuj bazę danych

Najpierw zatrzymaj wszystkie zapisy. W maintenance mode Heroku dyno typu worker i zadania Scheduler nadal działają. Dlatego przeskaluj do zera każdy typ procesu, który zapisuje dane (nie tylko worker), i usuń zadania w Heroku Scheduler na czas kopiowania. Według Heroku maintenance mode nie jest dostępny dla aplikacji Fir; tam przeskaluj do zera również web albo zatrzymaj zapisy w samej aplikacji:

bashheroku maintenance:on --app example-app
heroku ps:scale worker=0 --app example-app   # every process type that writes

Na Fir:

bashheroku ps:scale web=0 worker=0 --app example-app   # Fir: no maintenance mode

Następnie utwórz i pobierz backup. Heroku zapisuje go jako latest.dump w formacie custom pg_dump (dokumentacja Heroku). Heroku zaleca PGBackups dla baz do 20 GB; w przypadku większych uruchom pg_dump bezpośrednio z adresem URL zwróconym przez heroku pg:credentials:url (bazy classic) lub heroku data:pg:credentials:url (bazy Advanced, dokumentacja Heroku).

bashheroku pg:backups:capture --app example-app
heroku pg:backups:download --app example-app

Bazy Advanced nie obsługują PGBackups. Dla nich i dla baz większych niż 20 GB wykonaj dump bezpośrednio w tym samym formacie custom, z adresem URL z odpowiedniego polecenia credentials. Według Heroku bazy Private i Shield nie przyjmują połączeń zewnętrznych (a Shield nie ma PGBackups); dla nich postępuj zgodnie z procedurą, którą Heroku opisuje dla Private Spaces.

bashpg_dump -Fc --no-acl --no-owner -f latest.dump \
  "postgres://USER:PASSWORD@HOST:5432/DATABASE?sslmode=require"

W Nodion otwórz zakładkę Overview bazy danych i kliknij Enable public access. Poczekaj, aż endpoint przestanie pokazywać Provisioning, a następnie skopiuj adres połączenia (connection URL) widoczny w dashboardzie (zawsze TLS, sslmode=require). Dodaj swój adres IP do dozwolonych źródeł (allowed sources), aby nikt poza Tobą nie mógł się połączyć. Następnie przywróć dane:

bashpg_restore --verbose --no-owner --no-acl \
  --dbname "postgresql://nodion:PASSWORD@HOST:PORT/DATABASE?sslmode=require" \
  latest.dump

Użyj pg_restore co najmniej tak nowego jak nowszy z dwóch serwerów. Jeśli przywracanie zgłasza błędy dotyczące schematu heroku_ext, najpierw go utwórz: CREATE SCHEMA heroku_ext; (to rada samego Heroku). Sprawdź liczbę wierszy w zakładce Browse bazy danych, a potem ponownie wyłącz dostęp publiczny; baza danych działa dalej wewnętrznie.

Pusty Valkey wystarczy tylko wtedy, gdy Twoja aplikacja używa Key-Value Store jako cache lub jako kolejki, którą najpierw opróżnisz. Jeśli są tam dane, których potrzebujesz (na przykład sesje lub trwałe klucze), przenieś je przed wyłączeniem albo zachowaj źródło, dopóki nie przestanie być potrzebne.

3. Utwórz aplikację

Utwórz aplikację z repozytorium Git ze strategią Buildpacks. Buildpacki czytają Twój Procfile: web jest procesem domyślnym, a pozostałe linie stają się typami procesów (Buildpacks). W przypadku Node.js po buildzie uruchamia się skrypt heroku-postbuild. Tak jak na Heroku, proces web dostaje zmienną PORT.

Jeśli Procfile nie ma linii web:, jego pierwsza linia staje się domyślna i działa w procesie web w Nodion. Nodion sprawdza ten proces przez HTTP, zanim zacznie on obsługiwać ruch, więc worker bez serwera HTTP nie przejdzie tej kontroli. Zachowaj linię web: dla serwera HTTP swojej aplikacji.

Linie w Procfile nie tworzą procesów. Dla linii worker: przejdź do Processes → New process i nadaj procesowi nazwę worker i zostaw polecenie puste; wtedy uruchamia on typ procesu o tej samej nazwie.

Linia release: uruchamia się raz na deploy, zanim wystartuje web. Jeśli się nie powiedzie, deploy kończy się błędem, a poprzedni release nadal obsługuje ruch. Jeśli build na Heroku korzystał z heroku.yml, użyj strategii Dockerfile: tam nie ma Procfile, więc ustaw polecenie release aplikacji (Settings, w karcie Preview environments, gdzie pole pojawia się po włączeniu środowisk podglądu, lub release_command przez API). Nodion nie ustawia PORT dla aplikacji z Dockerfile; aplikacja nasłuchuje na porcie procesu web (w przeciwnym razie na porcie z EXPOSE obrazu, a jeśli go brak, na 8080).

4. Przenieś config vars

Wyeksportuj config vars w formacie shell (Heroku CLI):

bashheroku config -s --app example-app > heroku.env

Wklej linie w Environment, Add many, i zaimportuj je. Sprawdź wynik: wartości z cudzysłowami lub ukośnikami wstecznymi mogą wymagać ręcznej poprawki, a wartości wielowierszowe (na przykład klucze PEM) wprowadzisz przez CLI lub API. Zaimportowane zmienne nie są tajne; sekrety ustawiaj poleceniem nodion env set KEY=value --secret.

Następnie usuń DATABASE_URL i REDIS_URL z zaimportowanych zmiennych: zmienna ustawiona przez Ciebie nadpisuje wartość wstrzykiwaną przez podłączoną bazę danych. Użyj Attach database dla bazy Postgres (url jako DATABASE_URL) i dla Valkey (url jako REDIS_URL).

Wewnątrz Nodion połączenie przebiega przez sieć prywatną bez TLS (sslmode=disable). Jeśli Twój kod wymusza SSL dla bazy danych, jak wymaga tego Heroku, wyłącz to dla tego URL; to samo dotyczy rediss:// do Valkey.

5. Zadania Scheduler stają się zadaniami cron

Dodaj każde zadanie Heroku Scheduler w zakładce Cron aplikacji: harmonogram cron z pięcioma polami w UTC, to samo polecenie, timeout do 30 minut. Aplikacja może mieć do 8 zadań cron; dopóki trwa uruchomienie, kolejne wywołanie jest pomijane.

6. Wdróż i sprawdź

Zrób deploy, obserwuj zakładkę Logs i otwórz aplikację pod jej nazwą hosta w Nodion. Jeśli / nie odpowiada szybko kodem 2xx lub 3xx, ustaw własną ścieżkę health check w Settings.

7. Przenieś domenę

Dodaj domenę w zakładce Domains. Nodion pokazuje dwa rekordy: rekord TXT _nodion-challenge.your-domain i CNAME (w domenie głównej rekord ALIAS) wskazujący na domyślną nazwę hosta aplikacji. Rekord TXT możesz dodać z wyprzedzeniem. Certyfikat jest wystawiany, gdy CNAME wskazuje na Nodion, więc licz się z kilkoma minutami bez ważnego certyfikatu po przełączeniu i wcześniej obniż TTL.

8. Wyłącz Heroku

Gdy ruch i dane działają już w Nodion, usuń aplikację z Heroku. Według Heroku tego nie można cofnąć, więc zachowaj latest.dump.

bashheroku apps:destroy --app example-app

Co działa inaczej

• Nie ma trybu konserwacji (maintenance mode) ani pipelines z promowaniem między aplikacjami.
• Zamiast one-off dynos zakładka Shell otwiera terminal w działającym procesie.
• CLI pobiera logi, ale nie obsługuje ich śledzenia na bieżąco; oglądaj je na żywo w zakładce Logs.
• Środowiska podglądu nie potrzebują app.json; każde dostaje pustą bazę danych.
• Rollback ponownie wdraża wcześniejszy obraz z bieżącymi zmiennymi środowiskowymi.

Co dalej

Nodion w porównaniu z Heroku, Cennik, Aplikacje i Bazy danych.