Wdróż Docker na Nodion

Wdróż Docker krok po kroku

1. Nasłuchuj na 0.0.0.0 i podaj port w EXPOSE Nodion buduje Twój Dockerfile bez zmian i uruchamia CMD lub ENTRYPOINT obrazu. Nie ustawia zmiennej PORT: Twój serwer nasłuchuje na wszystkich interfejsach na stałym porcie, a EXPOSE wskazuje formularzowi tworzenia aplikacji port. Buildy wieloetapowe działają; uruchamiany jest ostatni etap (stage). Dockerfile

   FROM python:3.13-slim
   WORKDIR /app
   COPY requirements.txt .
   RUN pip install --no-cache-dir -r requirements.txt
   COPY . .
   EXPOSE 8000
   CMD ["gunicorn", "app:app", "--bind", "0.0.0.0:8000"]

2. Utwórz aplikację W dashboardzie utwórz aplikację ze swojego repozytorium GitHub, GitLab, Bitbucket lub Gitea, wybierz branch i region EU Central. Jeśli w repozytorium jest Dockerfile, formularz zaznacza strategię Dockerfile i uzupełnia port na podstawie EXPOSE. W monorepo ustaw Base directory (kontekst buildu) i nazwę pliku Dockerfile.
3. Przekaż wartości na czas buildu jako build args Zmienne z zaznaczoną opcją Build w zakładce Environment trafiają do buildu jako Docker build args, więc zadeklaruj je przez ARG na etapie, który je odczytuje. Wszystkie inne zmienne oraz podłączone bazy danych, takie jak DATABASE_URL, istnieją dopiero wtedy, gdy kontener działa. Dockerfile

   FROM node:24-slim AS build
   ARG VITE_API_URL
   WORKDIR /app
   COPY . .
   RUN npm ci && npm run build

4. Uruchamiaj migracje raz przy każdym wdrożeniu Ustaw polecenie migracji jako polecenie release aplikacji: uruchamia się raz przy każdym wdrożeniu, z nowego obrazu, zanim wystartuje nowa wersja. Jeśli zakończy się błędem, wdrożenie zostanie zatrzymane, a działająca wersja nadal obsługuje ruch. Ustaw je w polu API release_command; w panelu to pole pojawia się obecnie w ustawieniach aplikacji dopiero po włączeniu środowisk podglądu (preview). Migracje można też uruchamiać w entrypoincie lub poleceniu startowym, ale wtedy każda instancja uruchamia je przy każdym starcie.
5. Wdrażaj przez push Każdy push do brancha buduje nowy obraz we Frankfurcie. Ruch przechodzi na niego, gdy proces web odpowie na ścieżce health checku (domyślnie /) kodem 2xx lub 3xx. Instrukcja HEALTHCHECK Dockera w obrazie jest ignorowana.

Warto wiedzieć

• Brak zmiennej PORTJeśli Twój serwer odczytuje PORT, ustaw tę zmienną samodzielnie, przez ENV PORT=8000 w Dockerfile albo jako zmienną w zakładce Environment, i ustaw taką samą wartość jak port procesu webowego.
• Gotowe obrazyPomiń build z Gita i wdróż obraz z Docker Hub, GitHub Container Registry, rejestru Nodion albo prywatnego rejestru, którego dane dostępowe są zapisane w Nodion. Obowiązują te same zasady dotyczące portu i health checku.
• USER, .dockerignore i commitUSER obrazu jest respektowany, .dockerignore w kontekście buildu jest stosowany, a .git nigdy nie trafia do buildu. Zadeklaruj ARG NODION_GIT_SHA, aby zapisać hash commita w obrazie.

Czym Nodion zajmuje się za Ciebie

• Wdrożenia bez przestojów Wypchnij zmiany do swojej gałęzi, a Nodion zbuduje nowy release. Ruch przełącza się, gdy nowe instancje przejdą health check; nieudany release nie wpływa na działającą wersję. Aplikacje z lokalnym wolumenem są natomiast uruchamiane ponownie, bo dysk należy do jednej instancji.
• Bazy danych obok aplikacji Zarządzane PostgreSQL, pgvector, MySQL, Valkey i ClickHouse w tym samym regionie. Podłączone bazy danych trafiają do aplikacji jako DATABASE_URL, REDIS_URL lub CLICKHOUSE_URL.
• Środowiska podglądu dla pull requestów Włącz środowiska podglądu, a każdy pull request z Twojego repozytorium dostanie własną aplikację z własnym adresem URL i nowymi, pustymi bazami danych, tworzoną automatycznie lub ręcznie. Forki i pull requesty od botów są pomijane.
• Workery, zadania cron i skalowanie Uruchamiaj workery jako dodatkowe procesy tej samej aplikacji, planuj zadania w zakładce Cron i skaluj każdy proces do 16 instancji.
• Etap release W przypadku buildpacków linia release: w Procfile uruchamia się przy każdym nowym buildzie. Aplikacje z Dockerfile, a także ponowne wdrożenia i rollbacki do wcześniejszego obrazu, korzystają z polecenia release ustawionego w samej aplikacji, które ma też pierwszeństwo przed linią z Procfile. W przypadku stron statycznych krok release działa w obrazie zawierającym tylko zbudowane pliki.
• Logi i metryki W dashboardzie znajdziesz logi z builda, release'u i działania aplikacji oraz metryki CPU, pamięci, dysku i sieci dla każdej instancji.
• Domeny i HTTPS Domyślna nazwa hosta z HTTPS od pierwszego wdrożenia; Twoje własne domeny automatycznie dostają certyfikaty.

Warto przeczytać

• Dockerfile vs buildpacki: co wybrać dla aplikacji? Oba podejścia zamieniają Twój kod w obraz kontenera. Różni je to, kto pisze kroki builda, a od tego zależą kontrola, utrzymanie i aktualizacje bezpieczeństwa.
• Alternatywy dla Railway w Europie: porównanie 5 opcji Kontenery i bazy danych rozliczane według zużycia, z firmą lub regionem w UE: pięć alternatyw dla Railway w porównaniu rozliczeń, baz danych i lokalizacji.

Docker na Nodion: pytania i odpowiedzi