Wdróż SvelteKit na Nodion

Wdróż SvelteKit krok po kroku

1. Zastąp adapter-auto adapterem adapter-node Uruchom npm i -D @sveltejs/adapter-node, usuń @sveltejs/adapter-auto i użyj nowego adaptera w konfiguracji. Nodion odczytuje adapter z package.json, a konfiguracja decyduje, co zapisuje build, więc zmień jedno i drugie. W SvelteKit 3 konfiguracja znajduje się w opcjach sveltekit() w vite.config.js; w SvelteKit 2 to kit.adapter w svelte.config.js. vite.config.js (SvelteKit 3)

   import adapter from "@sveltejs/adapter-node";
   import { sveltekit } from "@sveltejs/kit/vite";
   import { defineConfig } from "vite";
   
   export default defineConfig({
     plugins: [
       sveltekit({
         adapter: adapter(),
         paths: { origin: "https://shop.example.com" },
       }),
     ],
   });

2. Dodaj lockfile do repozytorium, pomiń skrypt start Dodaj swój lockfile do repozytorium; bez niego build kończy się błędem. Nodion uruchamia Twój skrypt build i uruchamia node build, a adapter-node nasłuchuje na porcie PORT ustawianym przez Nodion. Skrypt start, jeśli go dodasz, zastępuje to polecenie.
3. Ustaw publiczny adres aplikacji (origin) Nodion kończy połączenie HTTPS przed Twoją aplikacją, więc SvelteKit nie rozpozna z żądania, jakiego adresu URL używają odwiedzający, a bez tej informacji wysłane formularze są odrzucane jako żądania między witrynami (cross-site). W SvelteKit 3 ustaw paths.origin na swój publiczny URL, jak w konfiguracji powyżej; zastępuje to zmienną ORIGIN z adapter-node. W SvelteKit 2 ustaw zamiast tego ORIGIN w zakładce Environment, na przykład https://shop.example.com.
4. Zmienne na czas buildu i działania aplikacji Wartości z $env/static/private i $env/static/public są wstawiane do kodu podczas buildu, więc wymagają opcji Build w zakładce Environment. $env/dynamic/private i $env/dynamic/public są odczytywane podczas działania serwera i działają ze zwykłymi zmiennymi.
5. Utwórz aplikację i zrób push W dashboardzie utwórz aplikację ze swojego repozytorium GitHub, GitLab, Bitbucket lub Gitea w regionie EU Central. Każdy push tworzy nowy release, a ruch przechodzi na niego, gdy / odpowie statusem 2xx lub 3xx. Jeśli / odpowiada kodem 401 lub 404, dodaj trasę taką jak src/routes/health/+server.js, która zwraca 200, i ustaw /health jako ścieżkę health checku.

Warto wiedzieć

• Strony statyczne z adapter-staticZ @sveltejs/adapter-static Nodion udostępnia build/ przez statyczny serwer WWW z obsługą nieznanych ścieżek przez index.html. Wygeneruj strony przed wdrożeniem (prerender) przez export const prerender = true w głównym +layout.js. Dla aplikacji single-page wyłącz tam SSR i ustaw fallback: 'index.html' w opcjach adaptera, bo Nodion potrzebuje pliku index.html w build/. Nie działa żaden serwer Node.js, więc wystarczy najmniejszy rozmiar.
• Tylko jeden adapter w package.jsonNodion najpierw szuka adapter-static, potem adapter-node. Jeśli oba są zainstalowane, aplikacja jest budowana jako strona statyczna, więc usuń adapter, którego nie używasz.

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ć

• Środowiska podglądu: aplikacja dla każdego pull requesta Działająca kopia Twojej aplikacji dla każdego pull requesta: do czego przydają się środowiska podglądu, gdzie robi się trudno i jak obsługuje je Nodion.
• 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.

SvelteKit na Nodion: pytania i odpowiedzi