Migracja z platformy Render

Przenieś usługi z Render razem z ich Postgresem, zmiennymi środowiskowymi i domenami.

Na platformie Render każda część aplikacji jest osobną usługą: web service, background worker, private service, cron job. W Nodion budujesz jeden obraz i uruchamiasz z niego kilka procesów w jednej aplikacji; cron joby należą do aplikacji. Nodion nie czyta pliku render.yaml, więc ustawienia przenosisz ręcznie.

Odpowiedniki w Nodion

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. Aplikacja i jej baza danych muszą być w tym samym regionie. Wybierz wersję Postgresa co najmniej tak nową jak wersja bazy w Render. Więcej na stronie Bazy danych.

2. Skopiuj bazę danych

Zewnętrzny URL bazy danych znajdziesz na stronie Info bazy w Render; Render przyjmuje połączenia zewnętrzne tylko przez TLS (dokumentacja Render). Wstrzymaj zapisy ze swoich usług, a potem utwórz dump tak, jak opisuje to dokumentacja backupów Render. -n public obejmuje tylko schemat public; pomiń tę opcję, jeśli Twoja aplikacja używa innych schematów.

bashpg_dump --dbname="RENDER_EXTERNAL_DATABASE_URL" -n public --no-owner \
  --format=directory --jobs=4 --compress=0 -f render.dump/

W Nodion otwórz zakładkę Overview bazy danych i kliknij Enable public access. Gdy endpoint nie pokazuje już statusu Provisioning, skopiuj URL połączenia (zawsze TLS) i dodaj własny adres IP w Allowed sources. Następnie przywróć dane:

bashpg_restore --verbose --no-owner --no-privileges --jobs=4 --format=directory \
  --dbname="postgresql://nodion:PASSWORD@HOST:PORT/DATABASE?sslmode=require" \
  render.dump/

Użyj pg_restore w wersji co najmniej tak nowej jak nowszy z dwóch serwerów. Sprawdź liczbę wierszy w zakładce Browse, a potem ponownie wyłącz dostęp publiczny; baza danych dalej działa wewnętrznie.

3. Utwórz aplikację i jej procesy

Utwórz aplikację z repozytorium Git, z którego korzysta web service. Jeśli Render budował usługę z build command i start command, użyj strategii Buildpacks (Buildpacks); polecenia ustawia Procfile, a bez niego obowiązują ustawienia domyślne języka. Jeśli usługa działała na Dockerze, użyj strategii Dockerfile.

Render ustawia PORT domyślnie na 10000. Nodion ustawia PORT dla procesu web w aplikacjach z buildpackami (domyślnie 8080); jeśli Twoja aplikacja odczytuje PORT, nic się nie zmienia. Jeśli 10000 jest zakodowane na sztywno, zmień to. W aplikacjach z Dockerfile Nodion nie ustawia PORT; aplikacja nasłuchuje na porcie procesu web.

Każdy background worker z tego samego repozytorium dodaj w Processes → New process jako kolejny proces i wpisz jego polecenie startowe. Private service również staje się procesem, z portem. Uwaga: każdy proces z portem dostaje obok adresu wewnętrznego publiczną domyślną nazwę hosta; nie ma usług wyłącznie prywatnych. Zabezpiecz taki port w aplikacji (na przykład uwierzytelnianiem). Nazwy hostów Nodion można wyłączyć tylko dla całej aplikacji, gdy aktywna jest własna domena. Worker, który tylko konsumuje kolejkę, nie potrzebuje portu. Przenieś pre-deploy command do linii release: w Procfile (buildpacki) lub do polecenia release aplikacji (Settings, karta Preview environments, w której pole pojawia się po włączeniu preview, albo release_command przez API). Uruchamia się raz na wdrożenie, przed web; jeśli się nie powiedzie, poprzedni release pozostaje aktywny.

4. Przenieś zmienne środowiskowe

Render nie dokumentuje eksportu zmiennych środowiskowych z dashboardu; Render API zwraca zmienne usługi, ale nie te z environment groups (dokumentacja Render API, GET /services/{serviceId}/env-vars; o environment groups przeczytasz w dokumentacji Render). Zbierz je jako linie KEY=value, łącznie z wartościami z environment groups, i wklej w Environment, Add many. Sekrety ustaw poleceniem nodion env set KEY=value --secret, a wartości wielowierszowe przez CLI lub API. Nodion nie ma plików z sekretami (secret files): zapisz ich zawartość jako zmienną sekretną (--secret) i niech aplikacja odczyta ją ze zmiennej albo sama zapisze plik przy starcie. Sekrety nie powinny trafiać do obrazu, przed czym ostrzega też Render.

Następnie usuń skopiowane z Render zmienne DATABASE_URL i REDIS_URL: zmienna ustawiona przez Ciebie nadpisuje wartość podłączonej bazy danych. Podłącz bazy danych przez Attach database. Wewnątrz Nodion połączenie działa bez TLS (sslmode=disable); jeśli Twój kod wymusza SSL, wyłącz to dla tego URL-a, i tak samo dla rediss:// do Valkey.

5. Przenieś cron joby

Cron job w Render to osobna usługa z harmonogramem w UTC (dokumentacja Render). W Nodion dodajesz go w zakładce Cron aplikacji, której kodu potrzebuje: pięciopolowy harmonogram w UTC, polecenie, timeout do 30 minut, do 8 zadań na aplikację. Jeśli poprzednie uruchomienie jeszcze trwa, kolejne jest pomijane.

6. Wdróż, przenieś domenę, wyłącz Render

Wdróż aplikację i sprawdź zakładkę Logs. Następnie dodaj domenę w zakładce Domains i ustaw dwa rekordy, które pokazuje Nodion: TXT _nodion-challenge.your-domain oraz CNAME (w domenie głównej: ALIAS) na domyślną nazwę hosta aplikacji. Nodion nie udostępnia celu dla rekordu A, więc w domenie głównej Twój dostawca DNS musi obsługiwać ALIAS, ANAME lub CNAME flattening. Certyfikat pojawia się, gdy CNAME wskazuje na Nodion; licz się z kilkoma minutami bez ważnego certyfikatu i wcześniej obniż TTL.

Gdy wszystko działa, usuń usługi w Render (Render CLI). Render nie przechowuje backupów usuniętej bazy danych, więc zachowaj swój dump.

bashrender services delete my-service --confirm

Usunięcie usługi nie usuwa bazy danych ani instancji Key Value. W płatnych instancjach Render domyślnie zapisuje dane Key Value na dysku (dokumentacja Render): pusty Valkey wystarczy tylko dla cache i kolejek, które wcześniej opróżnisz; jeśli potrzebujesz kluczy, przenieś je przed usunięciem instancji. Potem samodzielnie usuń bazę Render Postgres przyciskiem Delete Database na dole jej strony Info (dokumentacja Render), a także każdą instancję Key Value; polecenia CLI dla obu znajdziesz w dokumentacji Render CLI.

Co działa inaczej

• Nie ma environment groups ani secret files; każda zmienna należy do jednej aplikacji.
• Workery i private services to procesy aplikacji, a nie osobne usługi.
• Cron joby działają w istniejącej aplikacji, z jej aktywnym release'em.
• CLI pobiera logi, ale nie obsługuje ich śledzenia na bieżąco; oglądaj je na żywo w zakładce Logs.

Dalej

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