Wdróż Node.js na Nodion

Wdróż Node.js krok po kroku

1. Nasłuchuj na PORT Nodion ustawia PORT dla procesu web i kieruje tam ruch. Odczytaj tę zmienną i nasłuchuj na 0.0.0.0. Fastify domyślnie nasłuchuje na localhost, więc przekaż host: '0.0.0.0' do listen. server.js

   const express = require("express");
   
   const app = express();
   app.get("/", (req, res) => res.send("ok"));
   
   const port = process.env.PORT || 3000;
   app.listen(port, "0.0.0.0");

2. Dodaj do repozytorium lockfile i skrypt start Dodaj do repozytorium package-lock.json, yarn.lock, pnpm-lock.yaml lub bun.lock; bez pliku lockfile build kończy się błędem. Nodion uruchamia skrypt start bezpośrednio, więc hooki npm, takie jak prestart, się nie wykonują. Bez skryptu start znane frameworki, takie jak Nuxt, otrzymują własne polecenie domyślne; wszystko inne uruchamia się przez node server.js, index.js lub app.js, a w ostateczności przez node .. Zależności deweloperskie są usuwane po buildzie, więc narzędzia potrzebne podczas działania aplikacji, takie jak tsx czy CLI do migracji, powinny być w dependencies. package.json

   "scripts": {
     "start": "node server.js"
   }

3. TypeScript: zachowaj plik wejściowy w JavaScripcie Jeśli package.json ma skrypt build i nie istnieje żaden z plików server.js, app.js, index.js, src/server.js, src/index.js ani src/app.js, Nodion traktuje repozytorium jako stronę statyczną i nie uruchamia Twojego serwera. Dokładnie tak wygląda serwer w TypeScripcie, który tsc kompiluje do dist/. Dodaj obok package.json plik index.js, który ładuje skompilowany serwer (przykład wymaga "type": "module"; w CommonJS napisz require("./dist/server.js")), i skieruj skrypt start na skompilowany plik, na przykład node dist/server.js, a nie na narzędzie deweloperskie. index.js

   import "./dist/server.js";

4. Utwórz aplikację i ustaw zmienne W dashboardzie utwórz aplikację ze swojego repozytorium GitHub, GitLab, Bitbucket lub Gitea, wybierz branch i region EU Central. Zmienne odczytywane przez skrypt build wymagają zaznaczenia opcji Build w zakładce Environment; pozostałe istnieją tylko podczas działania aplikacji. Klucze API oznacz jako sekrety.
5. Podłącz PostgreSQL i uruchom migracje Utwórz bazę danych PostgreSQL w tym samym regionie i podłącz ją w zakładce Environment: od następnego wdrożenia Twoja aplikacja odczytuje DATABASE_URL. Linia release: w Procfile uruchamia się raz na każdy build, po buildzie i przed startem nowej wersji; jeśli się nie powiedzie, działająca wersja pozostaje online. Procfile

   release: npm run migrate

6. Wdrażaj przez push Każdy push do brancha tworzy nowy release. Ruch przechodzi na niego, gdy / odpowie statusem 2xx lub 3xx. Jeśli Twoje API odpowiada na / kodem 404, dodaj trasę taką jak /health i ustaw ją w ustawieniach aplikacji jako ścieżkę health checku.

Warto wiedzieć

• Vite w package.json oznacza stronę statycznąGdy vite jest w dependencies lub devDependencies, Nodion buduje repozytorium jako stronę statyczną i publikuje tylko wynik buildu, nawet jeśli istnieje server.js. To samo dotyczy projektów Angular, Gatsby, Create React App i Eleventy. Dla serwera Node.js, który buduje też frontend Vite, użyj Dockerfile.
• BunJeśli w repozytorium jest bun.lock, Nodion instaluje zależności i uruchamia build przez Bun. Aplikacja nadal startuje przez skrypt start, więc skrypt musi wywoływać Bun, na przykład "start": "bun run index.ts"; bez skryptu start Nodion uruchamia aplikację przez node. Opisana wyżej zasada pliku wejściowego dotyczy też projektów Bun.
• Workery kolejekWpisz web: node server.js i worker: node worker.js do Procfile; bez linii web: pierwszy wpis w Procfile inny niż release: staje się poleceniem domyślnym. Następnie w zakładce Processes dodaj proces o nazwie worker bez portu. Valkey w tym samym regionie daje Twojej kolejce REDIS_URL.

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ć

• Alternatywy dla Heroku z hostingiem w UE: porównanie 5 opcji Niemiecka platforma i amerykańskie chmury z regionami w UE, porównane pod względem siedziby, regionów i zarządzanych baz danych.
• 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.

Node.js na Nodion: pytania i odpowiedzi