Wdróż Spring Boot na Nodion

Wdróż Spring Boot krok po kroku

1. Zachowaj wrapper i przypnij wersję Javy Projekty ze Spring Initializr mają już mvnw lub gradlew. Nodion wykonuje ./mvnw -B -DskipTests clean package lub ./gradlew build -x test --no-daemon i uruchamia największy plik jar w target/ lub build/libs/, pomijając jar -plain z Gradle. Budowanie projektu Gradle bez wrappera kończy się błędem; projekt Maven bez wrappera Nodion buduje własnym Mavenem. Wersja Javy pochodzi z system.properties (domyślnie 21), a nie z toolchainu w Twoim pliku buildu. system.properties

   java.runtime.version=21

2. Dodaj Actuator dla health checku Ruch przełącza się dopiero wtedy, gdy ścieżka health checku odpowie kodem 2xx lub 3xx, a domyślna ścieżka / w wielu aplikacjach Spring Boot zwraca 404. Dodaj Actuator (w Gradle: implementation 'org.springframework.boot:spring-boot-starter-actuator') i w ustawieniach aplikacji ustaw ścieżkę health checku na /actuator/health. pom.xml

   <dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-actuator</artifactId>
   </dependency>

3. Skieruj datasource na własne zmienne Spring Boot oczekuje URL-a JDBC i nie odczytuje DATABASE_URL, który jest URL-em postgres://. W application.properties odwołaj się do własnych zmiennych i dodaj sterownik PostgreSQL org.postgresql:postgresql jako zależność potrzebną podczas działania aplikacji. Nodion wypełni te zmienne, gdy w następnym kroku podłączysz bazę danych. application.properties

   spring.datasource.url=jdbc:postgresql://${DB_HOST}:${DB_PORT}/${DB_NAME}
   spring.datasource.username=${DB_USER}
   spring.datasource.password=${DB_PASSWORD}

4. Utwórz aplikację i podłącz PostgreSQL Utwórz aplikację ze swojego repozytorium w regionie EU Central z co najmniej 1 GB pamięci, a następnie bazę danych PostgreSQL w tym samym regionie. Podłączając ją w zakładce Environment, przekaż host, port, nazwę bazy danych, użytkownika i hasło jako DB_HOST, DB_PORT, DB_NAME, DB_USER i DB_PASSWORD. Zmienne pojawią się przy następnym wdrożeniu.
5. Wdrażaj przez push Każdy push do brancha tworzy nowy release. Migracje Flyway lub Liquibase uruchamiają się przy starcie nowej wersji, zanim przejdzie ona health check; do tego czasu ruch obsługuje działająca wersja, więc dbaj o to, aby migracje były zgodne ze starym kodem.

Warto wiedzieć

• PamięćZaplanuj 1 GB lub więcej na instancję. JVM domyślnie dostaje JAVA_TOOL_OPTIONS=-XX:MaxRAMPercentage=80.0, więc sterta (heap) może zająć większość pamięci instancji. Ustaw JAVA_TOOL_OPTIONS, aby to zastąpić, albo JAVA_OPTS, aby dodać flagi do polecenia startowego.
• Spring SecurityJeśli definiujesz własny security filter chain, zezwól na dostęp do /actuator/health bez logowania. Przy odpowiedzi 401 lub 403 na ścieżce health checku wersja nigdy nie staje się gotowa, a po 10 minutach release zostaje przerwany, podczas gdy stara wersja nadal obsługuje ruch.
• Projekty wielomodułoweNodion szuka plików jar tylko bezpośrednio w target/ i build/libs/ katalogu Base directory. Jeśli jar Boot powstaje w katalogu modułu, uruchom go linią w pliku Procfile i sam przekaż port, na przykład web: java -Dserver.port=$PORT -jar app/build/libs/app.jar.

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.

Spring Boot na Nodion: pytania i odpowiedzi