1 04/11/2026 11 min

WildFly si installa bene su Ubuntu 20.04 e 22.04 LTS, ma la differenza la fanno i dettagli: versione Java corretta, utente dedicato, servizio systemd pulito e una configurazione che non esponga l’amministrazione oltre il necessario. Se l’obiettivo è avere un application server Java stabile in produzione, conviene impostarlo subito in modo ordinato, invece di limitarsi a scompattare l’archivio e avviarlo a mano.

In questa guida l’obiettivo è portare WildFly online in modo ripetibile, con installazione manuale in /opt, avvio come servizio, accesso all’interfaccia admin solo dove serve e una verifica finale semplice ma concreta. La procedura vale per entrambe le LTS di Ubuntu; dove cambia qualcosa, lo segnalo esplicitamente.

Scelta della versione Java e prerequisiti

WildFly recente richiede una Java moderna. Su Ubuntu 20.04 e 22.04 la scelta più lineare è OpenJDK 17, che è una baseline solida per molte installazioni attuali. Se hai già un vincolo applicativo specifico, verifica prima la matrice di compatibilità della tua versione di WildFly e della tua applicazione; non tutte le release si comportano allo stesso modo con versioni Java diverse.

Servono privilegi sudo, connettività verso i repository Ubuntu e spazio disco sufficiente per runtime, log e applicazione. Se prevedi deploy frequenti, tieni conto anche dello spazio per eventuali backup della configurazione e per il contenuto di standalone/deployments.

Installa i pacchetti necessari:

sudo apt update
sudo apt install -y openjdk-17-jdk curl tar unzip

Verifica subito la Java attiva:

java -version
readlink -f $(which java)

Il controllo atteso è una OpenJDK 17.x e un percorso coerente con il pacchetto appena installato, tipicamente sotto /usr/lib/jvm/. Se il sistema ha più versioni Java, conviene fissare quella corretta prima di andare avanti.

Download e installazione in /opt

La pratica più pulita è tenere WildFly fuori da /home e fuori dai path temporanei. /opt è una scelta comune per software di terze parti gestito manualmente. Evita di installarlo come root in directory casuali: ti complica permessi, backup e aggiornamenti.

Recupera il pacchetto dalla release ufficiale di WildFly. Qui uso una variabile per rendere il flusso più chiaro; sostituisci la versione con quella che vuoi realmente distribuire.

cd /tmp
WILDFLY_VERSION=33.0.2.Final
curl -LO https://github.com/wildfly/wildfly/releases/download/${WILDFLY_VERSION}/wildfly-${WILDFLY_VERSION}.tar.gz
sudo mkdir -p /opt/wildfly
sudo tar -xzf wildfly-${WILDFLY_VERSION}.tar.gz -C /opt
sudo ln -sfn /opt/wildfly-${WILDFLY_VERSION} /opt/wildfly

Il link simbolico /opt/wildfly è utile perché separa il nome fisico della release dal path usato dal servizio. Quando aggiorni WildFly, puoi scompattare una nuova versione e cambiare il link, lasciando invariati i riferimenti operativi.

Controlla che la directory esista e che il contenuto sia quello atteso:

ls -l /opt/wildfly
ls -l /opt/wildfly/bin

Devi vedere script come standalone.sh e add-user.sh. Se non compaiono, il tarball non è stato estratto correttamente oppure il link simbolico punta alla directory sbagliata.

Utente di servizio e permessi minimi

WildFly non va eseguito come root. Crea un utente dedicato senza shell interattiva, in modo da limitare il danno in caso di compromissione applicativa. Questo è un punto banale solo in apparenza: in produzione fa differenza tra un processo applicativo e un processo con privilegi inutili.

sudo useradd --system --no-create-home --shell /usr/sbin/nologin wildfly
sudo chown -R wildfly:wildfly /opt/wildfly-${WILDFLY_VERSION}
sudo chown -h wildfly:wildfly /opt/wildfly

Se prevedi directory esterne per log o dati persistenti, assegnale esplicitamente all’utente wildfly. Non allargare i permessi “per fare prima”: è il modo più rapido per creare incidenti difficili da ricostruire.

Configurazione iniziale di WildFly

La configurazione iniziale parte dal file di avvio e dai parametri di ascolto. In modalità standalone, WildFly usa di default la porta 8080 per l’applicazione e la 9990 per la console di management. In un server esposto su rete, queste porte vanno gestite con attenzione: 8080 può essere dietro reverse proxy, mentre 9990 non dovrebbe essere pubblica se non per accessi amministrativi controllati.

Per un primo test locale puoi avviare il server manualmente:

sudo -u wildfly /opt/wildfly/bin/standalone.sh

Se tutto è corretto, vedrai il bootstrap completarsi e il server ascoltare sulle porte previste. In una macchina remota, interrompi il test con Ctrl+C e passa subito al servizio systemd; l’avvio manuale serve solo a validare Java, permessi e integrità dell’installazione.

Puoi anche verificare le porte in ascolto con:

ss -ltnp | grep -E '8080|9990'

Se non compare nulla, il server non è partito correttamente oppure è terminato subito per un errore di configurazione o di Java. In quel caso i log di avvio sono il primo punto da leggere.

Avvio come servizio systemd

Per un server vero, il passaggio decisivo è il servizio systemd. Ti permette restart automatico, logging standardizzato e una gestione coerente con il resto della macchina. È anche il punto in cui conviene fissare path, memoria JVM e variabili d’ambiente in modo esplicito.

Crea un file di servizio dedicato in /etc/systemd/system/wildfly.service:

[Unit]
Description=WildFly Application Server
After=network.target [Service]
Type=simple
User=wildfly
Group=wildfly
WorkingDirectory=/opt/wildfly
Environment=JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64
Environment=JBOSS_HOME=/opt/wildfly
ExecStart=/opt/wildfly/bin/standalone.sh -b 0.0.0.0 -bmanagement 127.0.0.1
ExecStop=/opt/wildfly/bin/jboss-cli.sh --connect command=:shutdown
Restart=on-failure
RestartSec=10
LimitNOFILE=65535 [Install]
WantedBy=multi-user.target

Questo esempio espone l’applicazione su tutte le interfacce con -b 0.0.0.0, ma lascia la management interface su localhost. È una scelta prudente per un primo assetto: la console admin resta accessibile solo dalla macchina stessa, quindi la apri solo tramite SSH tunnel o da una rete di management controllata.

Ricarica systemd e abilita il servizio:

sudo systemctl daemon-reload
sudo systemctl enable --now wildfly

Verifica stato e log:

systemctl status wildfly --no-pager
journalctl -u wildfly -b --no-pager

La condizione OK è il servizio active (running) e nessun errore ripetuto nel journal. Se il servizio entra in loop di restart, di solito il problema è un path errato, un Java non compatibile, una permission negata o un binding su porta già occupata.

Accesso alla management console in modo sicuro

La console di management è utile, ma non va trattata come una pagina web qualunque. Se la esponi fuori da localhost, fallo con criterio: IP consentiti, VPN, bastion host o reverse proxy con autenticazione forte. L’errore tipico è lasciare la 9990 aperta su Internet “solo per comodità”.

Per creare l’account amministrativo, usa lo script incluso:

sudo -u wildfly /opt/wildfly/bin/add-user.sh

Lo script modifica i file utente di WildFly in /opt/wildfly/standalone/configuration/. Tieni presente che non stai creando un account di sistema, ma un utente applicativo per la console e le operazioni di management.

Se devi collegarti alla console da remoto senza aprire la porta pubblicamente, un tunnel SSH è la soluzione più semplice e meno rischiosa:

ssh -L 9990:127.0.0.1:9990 utente@server

Poi apri http://127.0.0.1:9990/console dal tuo browser locale. In questo modo la management interface resta raggiungibile senza esporla direttamente.

Deploy di una applicazione .war

Il metodo più semplice per un primo deploy è copiare un file .war in /opt/wildfly/standalone/deployments/. WildFly monitora quella directory e distribuisce l’app automaticamente. È una soluzione pratica, ma in ambienti più strutturati potresti preferire un deploy via CLI o pipeline CI/CD.

sudo cp myapp.war /opt/wildfly/standalone/deployments/
sudo chown wildfly:wildfly /opt/wildfly/standalone/deployments/myapp.war

Per capire se il deploy è andato a buon fine, controlla i marker nella stessa directory: WildFly crea file come myapp.war.deployed quando il rilascio è completato. Se compare .failed, l’app non è partita e il log spiega il motivo.

Un controllo rapido può essere questo:

ls -l /opt/wildfly/standalone/deployments/
grep -i myapp /opt/wildfly/standalone/log/server.log

Il file server.log è spesso il punto più utile per i problemi applicativi iniziali: classi mancanti, datasource non configurati, errori di startup del framework o conflitti di dipendenze emergono quasi sempre lì.

Datasource JDBC e configurazione database

Se l’applicazione usa un database, la parte importante non è solo “far vedere” il DB a WildFly, ma configurare correttamente datasource, driver e pooling. Qui la differenza tra un ambiente da laboratorio e uno usabile in produzione si vede subito.

WildFly include meccanismi per registrare driver e datasource nella configurazione standalone. La procedura esatta varia a seconda del database e della versione del driver, ma il principio resta lo stesso: driver nel modulo corretto o come deployment, datasource registrato con parametri coerenti, test di connessione prima del go-live.

Se usi la CLI di management, il vantaggio è che la configurazione diventa ripetibile e meno soggetta a errori manuali. Un esempio di connessione alla CLI:

/opt/wildfly/bin/jboss-cli.sh --connect

Da qui puoi ispezionare la configurazione attiva e, se necessario, aggiungere o verificare il datasource. La sintassi dipende dal backend scelto, quindi è corretto consultare la documentazione della tua release prima di applicare comandi in produzione. In generale, dopo ogni modifica, verifica sempre il test di connessione del datasource dalla console o dalla CLI.

Tuning iniziale della JVM

Il tuning serio arriva dopo aver osservato il carico reale, ma una base sensata aiuta. Non ha senso partire con valori aggressivi “a sentimento”: meglio definire un set minimo, misurare e poi correggere. Su macchine con memoria limitata, una configurazione troppo generosa porta facilmente a OOM o a pressione sullo swap.

Puoi impostare parametri JVM in un file dedicato, per esempio /opt/wildfly/bin/standalone.conf o un file custom richiamato dal servizio. Un esempio prudente:

JAVA_OPTS="$JAVA_OPTS -Xms512m -Xmx1024m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m"

Questi valori sono solo un punto di partenza. Se la JVM cresce oltre il previsto, il problema può essere nell’applicazione, in una cache non controllata o in un carico maggiore del previsto. La misura giusta non è “alzare tutto”, ma osservare heap, GC, tempi di risposta e memoria residente del processo.

Firewall, porte e superficie esposta

Se la macchina ha UFW attivo, consenti solo le porte necessarie. In molti casi la 8080 può essere raggiunta solo da bilanciatori o reti interne, mentre la 9990 dovrebbe restare chiusa verso l’esterno. L’errore classico è aprire entrambe le porte “per fare prima” e rimandare la segmentazione a dopo, quando ormai il server è già in produzione.

sudo ufw allow 8080/tcp
sudo ufw deny 9990/tcp
sudo ufw status verbose

Se usi un reverse proxy come Nginx o Apache davanti a WildFly, la 8080 può anche restare non esposta direttamente al pubblico, purché il proxy abbia accesso alla rete interna. In quel caso la configurazione della rete è parte integrante dell’architettura, non un dettaglio accessorio.

Verifica finale e controlli operativi

A installazione completata, la verifica non dovrebbe limitarsi a “la pagina risponde”. Devi controllare almeno quattro punti: servizio attivo, porte in ascolto, log pulito e applicazione raggiungibile. Se uno di questi manca, il sistema non è davvero pronto.

systemctl is-active wildfly
ss -ltnp | grep -E '8080|9990'
curl -I http://127.0.0.1:8080/
journalctl -u wildfly -b --no-pager | tail -n 50

Il controllo curl -I deve restituire una risposta HTTP coerente con ciò che hai deployato. Se non hai ancora caricato un’applicazione, una risposta dal server è comunque un segnale utile: indica che WildFly è vivo e che il layer HTTP funziona.

Per il deploy applicativo, osserva anche il comportamento dopo un restart del servizio. Un ambiente ben costruito deve ripartire senza interventi manuali e senza perdere la configurazione. Riavvia solo dopo aver salvato eventuali modifiche a servizio, configurazione o runtime.

Aggiornamento della release WildFly

Quando devi aggiornare WildFly, la strategia più pulita è affiancare la nuova versione, verificare la compatibilità e poi spostare il link simbolico. Questo riduce il rischio rispetto a modificare in place una directory già in uso.

sudo systemctl stop wildfly
cd /tmp
NEW_VERSION=34.0.1.Final
curl -LO https://github.com/wildfly/wildfly/releases/download/${NEW_VERSION}/wildfly-${NEW_VERSION}.tar.gz
sudo tar -xzf wildfly-${NEW_VERSION}.tar.gz -C /opt
sudo chown -R wildfly:wildfly /opt/wildfly-${NEW_VERSION}
sudo ln -sfn /opt/wildfly-${NEW_VERSION} /opt/wildfly
sudo systemctl start wildfly

Il rischio qui è limitato al cambio di runtime, ma il rollback deve essere immediato: basta ripuntare /opt/wildfly alla versione precedente e riavviare il servizio. Prima dell’upgrade, conserva una copia della configurazione corrente, in particolare i file in /opt/wildfly/standalone/configuration/.

Problemi tipici in avvio

Se WildFly non parte, i casi più frequenti sono abbastanza prevedibili. Java sbagliata o mancante, porta già occupata, permessi errati sulla directory di installazione, file di configurazione corrotto o memoria insufficiente. Il modo giusto di procedere è non toccare tutto insieme: prima leggi il log, poi fai una modifica minima e reversibile.

Se il log segnala una porta occupata, identifica il processo che la sta usando prima di cambiare binding o fermare servizi a caso:

sudo lsof -iTCP:8080 -sTCP:LISTEN -n -P
sudo lsof -iTCP:9990 -sTCP:LISTEN -n -P

Se il problema è di memoria, riduci il profilo JVM o aumenta le risorse della macchina solo dopo aver verificato il carico reale. Se il problema è di permessi, correggi ownership e verifica che l’utente wildfly possa leggere e scrivere dove serve, senza concedere accessi inutili al resto del filesystem.

Assunzioni: installazione standalone su Ubuntu 20.04 o 22.04 LTS, WildFly avviato come servizio systemd, Java 17 come runtime di riferimento.