Nasazení Java aplikace: Spring Boot nebo čistý jar na Java serveru

Java aplikace se nasazuje jako jediný spustitelný jar. Server od tebe potřebuje čtyři věci: verzi Javy alespoň tak novou, pro jakou jsi kompiloval, jar, který nese vlastní závislosti, kód, který naslouchá na portu, jenž server přidělil, a nároky na paměť, které se vejdou pod limit tarifu s rezervou. Všechno ostatní - proměnné prostředí, doména, logy, nasazení z GitHubu - stojí na těchto čtyřech věcech. Když je máš v pořádku, java -jar app.jar je celý příběh. Když jednu pokazíš, dostaneš chybu, která skutečnou příčinu pojmenuje jen zřídka.

Tento článek prochází celou cestu na hostovaném Java serveru: jakou verzi Javy zvolit, jak sestavit fat jar pomocí Mavenu nebo Gradle pro Spring Boot i pro všechno ostatní, jak se port dostane do tvého kódu, jak souvisí heap JVM s limitem kontejneru, jak předat konfiguraci, jak dostat sestavení z GitHubu na server bez kompilace přímo na něm a jak číst a uchovávat logy. Kde Java řada RE:NODE dělá něco konkrétního, říkáme to; zbytek platí pro libovolný hosting, který spouští jar v kontejneru. K produkčním detailům specifickým pro Spring - HikariCP, Actuator, hlavičky proxy - existuje doprovodný článek, nasazení Spring Bootu do produkce.

Jak Java server spouští tvůj jar#

Hostovaný Java server je kontejner s JDK uvnitř a pevným spouštěcím příkazem. V Java řadě RE:NODE je tento příkaz celý takto:

java -XX:MaxRAMPercentage=80.0 -Dterminal.jline=false -Dterminal.ansi=true \  -Dserver.port=${SERVER_PORT} -jar {{JARFILE}}

Vyplývají z toho tři věci a ovlivňují každou další část.

Za prvé, neexistuje žádný krok sestavení. Server spouští jar; nespouští Maven ani Gradle. Sestavuješ na vlastním počítači nebo v CI a na server jde jen hotový artefakt.

Za druhé, jar je pojmenovaný proměnnou JARFILE, která má výchozí hodnotu app.jar a je relativní ke složce serveru. Může obsahovat podsložku, takže build/app.jar nebo release/service.jar jsou v pořádku, pokud název končí na .jar. Mění se na záložce Startup.

Za třetí, o heapu a portu rozhoduje příkaz, ne ty. Strop heapu je 80 % paměti tarifu a port se předává jako systémová vlastnost server.port. Spring Boot tu vlastnost čte sám; jiné frameworky potřebují jeden řádek kódu, o něm je část o portu.

Samotný spouštěcí příkaz zákazník neupravuje - jen jeho proměnné. Je to záměr: spuštění serveru zůstává předvídatelné. Znamená to také, že obvyklé triky s přidáním -Xmx nebo -XX:+ExitOnOutOfMemoryError do příkazové řádky nejsou k dispozici, což u malých tarifů záleží a řeší to část o paměti.

Když se Java server poprvé vytvoří, není prázdný: spustí se s malou pracovní stránkou na vlastní adrese, sestavenou jako app.jar, takže první start ukáže něco užitečného místo pádu. Ta stránka je jen jar s výchozím názvem. Nahraj nebo nasaď vlastní app.jar a stránku nahradí; nic z tvého se jí nikdy nepřepíše.

Panel usoudí, že server dokončil start, když řádek v konzoli obsahuje jedno z několika slov: Started, Listening, Ready nebo Server running (v malých i velkých písmenech). Spring Bootové Started Application in 4.2 seconds odpovídá. Čistý jar, který při startu nic nevypíše, zůstane v panelu na „Starting“, přestože funguje bez problémů. Jakmile tvůj server přijímá spojení, vypiš řádek jako Listening on 0.0.0.0:<port> a stav bude správně.

Volba mezi Javou 17, 21 a 25#

Java řada nabízí tři image: Java 17, Java 21 a Java 25, všechno vydání s dlouhodobou podporou. Vybíráš v seznamu Docker Image na záložce Startup, nebo nastavením verze runtime na záložce GitHub, pokud se server nasazuje z repozitáře - změna tam server znovu sestaví na novém image.

Pravidlo je jednoduché: runtime musí mít stejnou major verzi jako cíl kompilace, nebo novější. Jar zkompilovaný pro 17 běží beze změny na 21 i 25. Jar zkompilovaný pro 21 odmítne na 17 nastartovat s UnsupportedClassVersionError a chyba uvádí verzi class souboru, ne verzi Javy:

Cíl si připni v sestavení a nespoléhej na to, jaké JDK zrovna je na build stroji. V Mavenu je to <maven.compiler.release>21</maven.compiler.release> v <properties>; v Gradle je to toolchain:

java {    toolchain {        languageVersion = JavaLanguageVersion.of(21)    }}

Co zvolit: Spring Boot 3 vyžaduje 17 nebo novější, stejně jako aktuální vydání Quarku a Micronautu. Pokud jsou tvé závislosti aktuální, rozumná výchozí volba je 21 - virtuální vlákna jsou tam stabilní a podpora má před sebou roky. Sáhni po 25, pokud chceš nejnovější LTS a tvé knihovny to dohnaly; nejdřív na ní spusť testy, protože na novém vydání se nejčastěji rozbijí nástroje založené na agentech a starší knihovny pracující s bytecodem. Verzi 17 nech pro kód, který přesunout nemůžeš, například službu na Spring Boot 2.7, a ber to jako migraci, kterou sobě dlužíš.

Sestavení jaru, který běží sám#

„Spustitelný“ znamená dvě věci: manifest uvádí Main-Class a každá závislost je uvnitř jaru nebo vedle něj. Jar sestavený obyčejným mvn package nemá ani jedno a skončí chybou no main manifest attribute, in app.jar nebo NoClassDefFoundError u první třídy z knihovny.

U Spring Bootu udělá obojí plugin Boot. ./mvnw package nebo ./gradlew bootJar vyrobí spustitelný fat jar s vestavěným webovým serverem. Dej mu pevný název, aby se JARFILE serveru nemusel mezi verzemi měnit:

<build>  <finalName>app</finalName>  <plugins>    <plugin>      <groupId>org.springframework.boot</groupId>      <artifactId>spring-boot-maven-plugin</artifactId>    </plugin>  </plugins></build>

Výsledkem je target/app.jar. Maven po sobě nechává také target/app.jar.original, tenký jar před přebalením; ignoruj ho. V Gradle zapisuje bootJar do build/libs/ a úloha jar vedle něj vytvoří druhý, obyčejný jar s příponou -plain. Nahraj ten bez přípony, nebo nastav na úloze bootJar hodnotu archiveFileName = "app.jar".

Jiné frameworky mají vlastní cestu ke stejnému výsledku:

• Quarkus ve výchozím stavu sestaví „fast jar“: target/quarkus-app/quarkus-run.jar plus vedle něj adresář lib. To funguje, pokud nahraješ celou složku quarkus-app a JARFILE nastavíš na quarkus-app/quarkus-run.jar. Pokud chceš jediný soubor, nastav quarkus.package.jar.type=uber-jar (starší vydání 3.x používala quarkus.package.type) a dostaneš jeden *-runner.jar.
• Ktor se svým pluginem pro Gradle má úlohu buildFatJar, která zapíše -all.jar do build/libs/.
• Micronaut projekty vygenerované přes Micronaut Launch obsahují plugin Shadow pro Gradle, takže ./gradlew shadowJar vyrobí -all.jar; v Mavenu vyrobí mvn package spustitelný jar se závislostmi.
• Čistá Java, Discord bot na JDA, služba na Javalinu: použij Maven Shade plugin nebo Gradle Shadow plugin a v jeho konfiguraci nastav hlavní třídu.

Výsledek zkontroluj dřív, než opustí tvůj počítač. java -jar target/app.jar by se mělo spustit bez čehokoli dalšího na classpath a unzip -p target/app.jar META-INF/MANIFEST.MF ukáže řádek Main-Class. Pokud se jar lokálně spustí obyčejným java -jar na stejné major verzi, kterou jsi vybral pro server, spustí se i tam.

Port: SERVER_PORT a server.port#

K tarifu patří přidělení - adresa a port - a aplikace musí naslouchat na tomto portu, na všech rozhraních. Ne na 8080 a ne na localhost. Služba na špatném portu čistě nastartuje, zaloguje, že je připravená, a nikomu neodpovídá.

Port se k tvému kódu dostává dvakrát. Je v prostředí jako SERVER_PORT a spouštěcí příkaz ho předává jako systémovou vlastnost server.port. Právě ta druhá podoba je důvod, proč Spring Boot nepotřebuje žádnou konfiguraci: systémové vlastnosti Javy mají ve Springu přednost před application.properties, takže cokoli si v jaru nastavíš jako server.port, přebije skutečná hodnota. To je užitečné a občas překvapivé, pokud jsi čekal, že vyhraje tvoje hodnota.

Každý další framework čte port po svém:

Quarkus navíc potřebuje quarkus.http.host=0.0.0.0, pokud jsi to měnil, a ručně psaný server se musí vázat na všechna rozhraní, ne na loopback. Vestavěný HTTP server z JDK stačí na stránku se stavem nebo malé API a ukazuje celý vzor:

import com.sun.net.httpserver.HttpServer;import java.net.InetSocketAddress;public class Main {    public static void main(String[] args) throws Exception {        int port = Integer.parseInt(System.getenv().getOrDefault("SERVER_PORT", "8080"));        HttpServer server = HttpServer.create(new InetSocketAddress("0.0.0.0", port), 0);        server.createContext("/", exchange -> {            byte[] body = "ok\n".getBytes();            exchange.sendResponseHeaders(200, body.length);            exchange.getResponseBody().write(body);            exchange.close();        });        server.start();        System.out.println("Listening on 0.0.0.0:" + port);    }}

Discord bot postavený na JDA nebo jakýkoli worker, který jen navazuje odchozí spojení, naslouchat nemusí. Přesto potřebuje startovací řádek, který panel pozná, takže vypiš Ready, jakmile se bot připojí.

Pro doménu a HTTPS dej před aplikaci slot reverzní proxy místo ukončování TLS v JVM. Tarify pro aplikace obsahují slot reverzní proxy: nasměruj záznam A na zobrazenou adresu a certifikát se vystaví a obnovuje automaticky. Aplikace dál mluví prostým HTTP na svém portu a skutečná adresa klienta přichází v X-Forwarded-For. Ve Spring Bootu zajistí server.forward-headers-strategy=framework, že request.getRemoteAddr() i generované URL tuto hlavičku respektují. Stranu DNS popisuje doména a její certifikát.

Paměť: heap, zbytek JVM a limit#

Tady se na malých tarifech pokazí většina nasazení Javy a tady se vyplatí znát spouštěcí příkaz.

Kontejner má pevný limit paměti rovný tarifu. Zátěž JVM je heap plus všechno, co heap není: metaspace pro načtené třídy, code cache JITu, jeden zásobník na vlákno, přímé bajtové buffery používané Netty a NIO a vlastní struktury garbage collectoru. Webová aplikace na Spring Bootu tím běžně nese několik set megabajtů ještě předtím, než obslouží první požadavek.

-XX:MaxRAMPercentage=80.0 dovolí heapu narůst na 80 % limitu kontejneru. JVM si ho nevezme celý najednou - heap začíná menší a roste, když aplikace alokuje rychleji, než kolektor uvolňuje - ale pod zátěží smí dosáhnout stropu a mimo-heapová paměť se musí vejít do toho, co zbyde:

Od 2 GB výš je to pro typickou službu pohodlné. Na 1 GB je to pro Spring Boot těsné: 205 MB pro metaspace, code cache a 200 vláken Tomcatu nechává málo místa a heap, který se při nárazu zaplní, může celek přetlačit přes hranici. Malé API na Javalinu, bot na JDA nebo služba na Quarku se na 1 GB vejde bez potíží. Aplikace na Spring Bootu s JPA je spokojenější na 2 GB.

Záleží na tom, co se stane na limitu. Na RE:NODE kernel kontejner zastaví a ten se čistě restartuje místo swapování. Existují tedy dvě různá selhání a vyžadují opačné opravy:

• `java.lang.OutOfMemoryError: Java heap space` v konzoli. Byl dosažen strop heapu a JVM to řekla. Data se nevejdou, nebo něco uniká. Odpovědí je větší tarif nebo méně držet v paměti.
• Restart bez jakékoli chyby Javy. Celý proces překročil limit kontejneru a byl zastaven zvenčí; JVM neměla šanci cokoli zalogovat. Heap sám problém nebyl - problém byla mimo-heapová paměť.

Protože je příkazová řádka pevná a proměnné začínající na JAVA, JDK_ nebo JVM nejdou z panelu nastavit, heap přes JAVA_TOOL_OPTIONS snížit nemůžeš. Co ovlivnit můžeš, je mimo-heapová strana, kde malé tarify s 1 GB obvykle selhávají:

# Méně vláken pro požadavky: každé má vlastní zásobníkserver.tomcat.threads.max=50# Beany vytvářet při prvním použití, ne všechny při startuspring.main.lazy-initialization=true# Nedržet sessiony JPA otevřené přes vrstvu zobrazeníspring.jpa.open-in-view=false

Líná inicializace snižuje paměť i čas startu za cenu pomalejších prvních požadavků a chyb, které se objeví později místo při bootu; než se na ni spolehneš, otestuj ji. Na Javě 21 a 25 nahradí spring.threads.virtual.enabled=true platformní vlákna pro požadavky virtuálními, což u služeb vázaných na I/O výrazně sníží paměť zásobníků. Kromě toho ořež závislosti, které nepoužíváš - každý starter přidává třídy do metaspace. Pokud jsi měřil a stále potřebuješ jiné nastavení heapu, napiš nám tiket, místo abys bojoval s limitem; a pokud aplikace opravdu potřebuje víc paměti, poctivá odpověď je další tarif. Kdy zvýšit tarif popisuje, jak před tím číst grafy.

Restarty se sledují. Hlídač pádů se dotazuje každé dvě minuty; restarty, které jsi vyžádal, se nepočítají, ale tři neplánované za hodinu zobrazí na stránce serveru varování a otevřou tiket a šest server pozastaví. Jar, který je na limitu zabíjen každých pár minut, je přesně to, co hlídač hledá, takže dimenzování oprav dřív, než to necháš běžet. Konzole zobrazuje graf paměti vůči limitu; sleduj ho během dne skutečného provozu. Obecné pozadí je v článku Linux swap a OOM killer.

Proměnné prostředí a tajné údaje#

Konfigurace, která se mezi prostředími mění - URL databáze, API klíče, název profilu - patří do prostředí, ne do jaru. Uvolněné vazby Spring Bootu (relaxed binding) převedou SPRING_DATASOURCE_URL na spring.datasource.url, SPRING_PROFILES_ACTIVE na spring.profiles.active a tak dále, takže většina nastavení nepotřebuje žádný kód.

Na RE:NODE se vlastní proměnné přidávají na záložce Variables serveru, v části „Your variables“: název a hodnota, které se v kontejneru nastaví při dalším startu, nejvýše 25 na server. Názvy tvoří velká písmena, číslice a podtržítka a začínají písmenem. Názvy, které už vlastní panel, démon nebo runtime jazyka, se odmítnou, a seznam je širší, než by sis myslel: cokoli začínající na SERVER_, JAVA, JDK_, JVM, APP_, DB_, DATABASE_, PG, POSTGRES, REDIS nebo AWS_, plus názvy jako PATH a CLASSPATH. Takže DB_PASSWORD se neuloží, zatímco SPRING_DATASOURCE_PASSWORD nebo ORDERS_DB_PASSWORD ano.

SPRING_PROFILES_ACTIVE=prodSPRING_DATASOURCE_URL=jdbc:postgresql://db-host:port/appdbSPRING_DATASOURCE_USERNAME=appuserSPRING_DATASOURCE_PASSWORD=change-meDISCORD_BOT_TOKEN=change-me

Hostitel a port výše jsou zástupné hodnoty - použij ty, které ukazuje tvůj databázový server. Mimo Spring čti proměnné přes System.getenv("NAME") a při startu hlasitě selži, pokud chybí povinná; jasná chyba v první vteřině je lepší než NullPointerException o hodinu později.

Pokud dáváš přednost souboru, Spring Boot čte také application.properties nebo application.yml umístěný vedle jaru nebo ve složce config/ vedle něj, a ty mají přednost před kopií zabalenou uvnitř jaru. Takový soubor drž na serveru, nikdy v repozitáři. Širší návyky - co je tajný údaj, rotace, držet .env mimo Git - jsou v článku proměnné prostředí a tajné údaje.

Tarify pro aplikace obsahují dva databázové sloty vytvářené v panelu, s vygenerovaným hostitelem, uživatelem a heslem, což malé službě vyhovuje. Pro PostgreSQL, MongoDB nebo MySQL na vlastním serveru dává hosting databází každému enginu vlastní tarif a přihlašovací údaje.

Nasazení z GitHubu bez sestavování na serveru#

Nahrát jar ručně přes správce souborů nebo SFTP je pro první nasazení v pořádku. U čehokoli, co aktualizuješ často, připoj GitHub.

Záložka GitHub propojí repozitář přes GitHub App s krátkodobými tokeny, takže fungují i privátní repozitáře. Vybereš produkční větev a složku pro kód a dva přepínače: stáhnout nejnovější commit při každém startu a nasadit při pushi, což restartuje běžící server a spustí zastavený. Každé nasazení se zaznamená.

Háček je ten z spouštěcího příkazu: server jar spouští, nesestavuje ho. Repozitář se zdrojovým kódem Javy na produkční větvi dává serveru nic ke spuštění. Čistý postup je nechat jar sestavit GitHub Actions, publikovat ho do větve, která neobsahuje nic než artefakt, a server nasměrovat na tuto větev.

name: Build jaron:  push:    branches: [main]permissions:  contents: writejobs:  build:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4      - uses: actions/setup-java@v4        with:          distribution: temurin          java-version: '21'          cache: maven      - run: ./mvnw -B -DskipTests package      - name: Publish the jar to the deploy branch        run: |          mkdir out && cp target/app.jar out/app.jar          cd out          git init -b deploy          git config user.name "github-actions[bot]"          git config user.email "github-actions[bot]@users.noreply.github.com"          git add app.jar          git commit -m "Build ${GITHUB_SHA::7}"          git push --force \            "https://x-access-token:${{ secrets.GITHUB_TOKEN }}@github.com/${{ github.repository }}.git" \            deploy

Pokud chceš, aby neprošlý test zastavil nasazení, spusť testy v kroku před balením; -DskipTests je tu jen proto, aby byl příklad krátký. Force-push čerstvé větve s jedním commitem je záměrný: jar commitnutý při každém sestavení na vrch toho předchozího by zvětšoval repozitář vždy o velikost jaru a tuhle historii nikdo nepotřebuje - historie zdrojů je na main.

Na serveru nastav produkční větev na deploy, zapni nasazení při pushi a JARFILE nech na app.jar. Verzi Javy pro sestavení a image serveru nastav na stejnou major verzi. Jedno upozornění ke složce: cokoli je ve složce s kódem, repozitář při každém startu nahradí. Pokud tvoje aplikace zapisuje nahrané soubory, soubor H2 nebo SQLite či logy, ať zapisuje mimo tuto složku - nebo dej kód do podsložky, například release, a JARFILE nastav na release/app.jar, aby kořen serveru zůstal tvůj.

Záložka GitHub má také kontrolu před nasazením (pre-flight check), která repozitář přečte dřív, než ho propojíš. Její kontroly runtime jsou psané pro Node.js, Python, Go, Bun a Deno, ne pro Javu, ale i tak jménem nahlásí commitnutý .env, aniž by ho otevřela, což se hodí u každého repozitáře. Víc o ní je v článku pre-flight check a stranu panelu u nasazení popisuje průvodce nasazením.

Logy: konzole, soubory a disk#

Konzole ukazuje standardní výstup procesu, nefiltrovaný a živě, s příkazovou řádkou, tlačítky napájení a grafy paměti a CPU vůči limitům. Pro většinu služeb je to log: Spring Boot, Quarkus i Logback logují ve výchozím stavu do konzole. Barevný výstup Spring Bootu i jeho zpracování konzolí jsou v pořádku; pokud barevné kódy zasírají zkopírovaný log, vypne je spring.output.ansi.enabled=never.

Konzole je živý pohled, ne archiv. Cokoli potřebuješ číst po restartu, piš navíc do souboru, a omez ho, protože limit disku je skutečný: server, který za běhu překročí limit disku, je zastaven a zamčen, dokud se místo neuvolní. Rotace Logbacku ve Spring Bootu potřebuje čtyři vlastnosti:

logging.file.name=logs/app.loglogging.logback.rollingpolicy.max-file-size=10MBlogging.logback.rollingpolicy.max-history=7logging.logback.rollingpolicy.total-size-cap=200MB

total-size-cap je ta, která chrání disk; bez ní drží max-history sedm dní, jakkoli jsou velké. Relativní cesta se vyhodnocuje od složky serveru, což je pracovní adresář. Soubory čti ve správci souborů nebo je stáhni přes SFTP.

Co logovat, je jiná otázka než kam. Loguj nejvýše jeden řádek na požadavek, chyby loguj se stack tracem jednou a nelogej těla požadavků ani hlavičky, které mohou nést tokeny. Dál jde článek logy, které stojí za uchování.

Zastavení patří do stejného obrazu. Tlačítko Stop pošle Ctrl+C, což JVM bere jako SIGINT a odpoví spuštěním shutdown hooků. Spring Boot toho využije pro řádné vypnutí: s server.shutdown=graceful přestane přijímat nové požadavky a nechá doběhnout ty rozpracované, nejvýše po dobu spring.lifecycle.timeout-per-shutdown-phase (výchozích 30 sekund). Díky tomu je restart při nasazení po pushi ohleduplný k požadavkům, které právě běží. Podrobnosti má řádné vypnutí a health checky.

Řešení potíží, když se Java server nespustí#

Chyby, které lidé skutečně vidí, a co která znamená:

• `Error: Unable to access jarfile app.jar`. Soubor uvedený v JARFILE tam není. Zkontroluj velikost písmen v názvu, složku a to, zda nasazení z GitHubu nedalo kód do podsložky.
• `no main manifest attribute, in app.jar`. Jar je knihovní, ne spustitelný. Sestav ho pluginem Boot, Shade nebo Shadow, nebo nahraj správný soubor - v Gradle ne ten s -plain.
• `UnsupportedClassVersionError ... class file version 65.0`. Zkompilováno pro novější Javu, než na jaké server běží. Změň image na záložce Startup, nebo nastav release sestavení tak, aby odpovídal.
• `NoClassDefFoundError` nebo `ClassNotFoundException` u třídy z knihovny. Závislosti nejsou v jaru. Oprava je stejná jako u chyby manifestu.
• Nastartuje, zaloguje, že je připravený, ale adresa neodpovídá. Naslouchá na jiném portu nebo na localhost. Podívej se do startovacího řádku logu na port a porovnej ho s přidělením.
• Panel ukazuje „Starting“ donekonečna. Aplikace funguje, ale nikdy nevypsala žádné ze startovacích slov. Vypiš Listening nebo Ready, jakmile běží.
• Restartuje se každých pár minut bez chyby. Proces narazil na limit paměti. Viz část o paměti.
• `APPLICATION FAILED TO START` ze Spring Bootu. Přečti si řádky „Description“ a „Action“ pod ním; obvykle mají pravdu. Nejčastější je chybějící URL datasource, což znamená, že se proměnná neuložila nebo má překlep.

FAQ#

Může server sestavit můj projekt pomocí Mavenu nebo Gradle?

Ne. Java server spouští hotový jar a nemá krok sestavení. Sestavuj na svém počítači nebo v CI - workflow GitHub Actions výše je obvyklá cesta - a nasazuj jen jar.

Mohu změnit -Xmx nebo jiné příznaky JVM?

Z panelu ne. Spouštěcí příkaz je pevný a nastavuje strop heapu na 80 % paměti tarifu a JAVA_TOOL_OPTIONS je jedním z rezervovaných názvů proměnných. Mimo-heapovou paměť můžeš snížit zevnitř aplikace, a pokud máš změřenou potřebu jiných příznaků, otevři tiket.

Kolik paměti potřebuje malá Java služba?

Čisté API v Javě nebo Javalinu, služba na Quarku nebo bot na JDA běží dobře na 1 GB. Webová aplikace na Spring Bootu s JPA je pohodlnější na 2 GB, protože mimo-heapová paměť JVM zabírá na malém tarifu větší podíl.

Potřebuji pro Spring Boot Actuator samostatný port?

Obvykle ne. Nechat Actuator na hlavním portu a zpřístupnit jen endpointy, které potřebuješ, například health, je jednodušší než spravovat druhý port a řádek management.endpoints.web.exposure.include=health to zařídí. Cokoli citlivějšího, například env nebo heapdump, by na veřejné adrese mělo zůstat nezveřejněné.

Mohu spustit soubor WAR?

Přímo ne - není nainstalovaný žádný servletový kontejner. Spring Boot umí stejnou aplikaci zabalit jako spustitelný jar s vestavěným Tomcatem, což je běžná cesta. Stará aplikace jen ve formátu WAR potřebuje nejdřív přebalit.

Zůstane server na verzi Javy, kterou jsem zvolil?

Ano. Verze je image, na kterém server běží, vybraný na záložce Startup nebo GitHub, a nemění se, dokud ji sám nezměníš.