Installare e deployare applicazioni Java con WildFly su Linux

Nel contesto di DevOps e di continui rilasci, WildFly si integra bene con strumenti di automazione, container Docker e orchestratori Kubernetes. Tuttavia, la sua potenza richiede una configurazione accurata, soprattutto per quanto riguarda la gestione delle risorse di sistema, la sicurezza e il monitoraggio. Scopriremo come impostare correttamente le variabili d’ambiente, creare un utente dedicato e proteggere il server da esecuzioni con privilegi eccessivi, riducendo così il rischio di vulnerabilità.

Infine, analizzeremo le principali problematiche che possono emergere in fase di avvio e deployment, fornendo metodi di troubleshooting basati sui log di WildFly e su comandi di sistema. Con questi accorgimenti, potrai far funzionare WildFly in modo stabile e performante, sia in ambienti di test che in produzione.

Prerequisiti operativi

Per avviare WildFly è indispensabile disporre di una Java LTS (OpenJDK è la scelta più comune). La versione consigliata è la più recente della serie 17 o 21, poiché garantisce la compatibilità con le ultime specifiche Java EE. Su Ubuntu, i pacchetti Java si installano con apt, mentre su RHEL o CentOS si utilizza yum/dnf. Dopo l’installazione, è necessario impostare le variabili d’ambiente JAVA_HOME (che punta alla directory di installazione di Java) e PATH (che include $JAVA_HOME/bin). Queste variabili consentono a WildFly di individuare il runtime Java corretto.

Un altro prerequisito fondamentale è la creazione di un utente di sistema dedicato a WildFly. Eseguire il server con privilegi di root espone l’intero host a potenziali attacchi: una vulnerabilità nel server potrebbe concedere privilegi di amministratore all’attaccante. Creare un utente, ad esempio wildfly, e assegnargli i permessi di lettura/scrittura solo sulle directory di WildFly garantisce un isolamento efficace.

Infine, è buona pratica verificare che le porte di rete richieste (di default 8080 per HTTP e 9990 per la console di gestione) siano libere e non utilizzate da altri servizi. Su sistemi con firewall attivo, occorre aprire queste porte sia per il traffico in entrata che per quello in uscita, assicurandosi che le regole siano coerenti con le politiche di sicurezza dell’organizzazione.

Download e installazione

Il primo passo consiste nello scaricare l’archivio di WildFly dal sito ufficiale (wildfly.org). L’archivio è disponibile in formato .zip o .tar.gz; scegli quello più comodo per il tuo ambiente. Una volta scaricato, estrai il contenuto nella directory di destinazione: su Ubuntu è consuetudine utilizzare /opt/wildfly, mentre su RHEL si preferisce /usr/share/wildfly. Indipendentemente dal percorso, la struttura interna rimane invariata, con le cartelle bin, modules, standalone, domain e configuration.

L’installazione manuale prevede semplicemente l’estrazione dei file e la configurazione dei permessi per l’utente wildfly. Se, invece, è disponibile un pacchetto pre‑compilato (ad esempio wildfly-*.rpm o wildfly-*.deb), l’installazione automatizza la creazione dell’utente di sistema, l’impostazione dei permessi corretti e la registrazione del servizio in systemd. Questo approccio riduce il rischio di errori manuali e velocizza la messa in produzione.

È importante distinguere il runtime (contenuto nelle directory bin e modules) dalla configurazione (presente in standalone/configuration o domain/configuration). Il runtime è immutabile durante l’esecuzione del server, mentre la configurazione è quello che gli amministratori modificheranno per adattare WildFly alle esigenze specifiche dell’applicazione, come la definizione di datasource, logging e subsystem.

Configurazione iniziale

WildFly può operare in due modalità distinte: standalone e domain. La modalità standalone è ideale per installazioni singole, tipiche di piccole e medie imprese, poiché semplifica la gestione e riduce la complessità amministrativa. La modalità domain, al contrario, è pensata per ambienti clusterizzati dove più server condividono una configurazione centralizzata; viene utilizzata soprattutto in contesti enterprise con requisiti di alta disponibilità.

I file principali di configurazione sono standalone.xml (per la modalità standalone) e host.xml (per la modalità domain). In questi file vengono definiti porte di ascolto, binding di rete e i vari subsystems (EJB, JPA, Messaging, ecc.). È consigliabile modificare le porte predefinite (8080 per HTTP e 9990 per la console di gestione) per evitare conflitti con altre applicazioni e per migliorare la sicurezza, ad esempio passando a 8081 e 9991.

Per garantire l’accesso sicuro alla console di gestione, utilizza lo script add-user.sh presente nella cartella bin. Questo strumento consente di creare utenti amministrativi con nome utente, password e ruoli specifici. È buona pratica creare almeno un utente con ruolo Administrator e uno con ruolo Monitor, limitando così i privilegi a chi realmente ne ha bisogno e riducendo la superficie di attacco.

Avvio come servizio di sistema

Per gestire WildFly come servizio di sistema, crea un unit‑file systemd denominato wildfly.service nella directory /etc/systemd/system/. Il contenuto tipico del file include il percorso di WILDFLY_HOME, le variabili JAVA_HOME, le opzioni di avvio (-b 0.0.0.0 per consentire connessioni remote) e la definizione dei percorsi dei log. Ecco un esempio di unit‑file (non modificare il codice, mantenerlo così com’è):

[Unit]
Description=WildFly Application Server
After=network.target

[Service]
Type=simple
User=wildfly
Group=wildfly
Environment=JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64
Environment=WILDFLY_HOME=/opt/wildfly
ExecStart=$WILDFLY_HOME/bin/standalone.sh -b 0.0.0.0
SuccessExitStatus=143
Restart=on-failure
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Una volta creato il file, ricarica la configurazione di systemd con systemctl daemon-reload, abilita il servizio all’avvio con systemctl enable wildfly e avvialo tramite systemctl start wildfly. Puoi monitorare lo stato del server usando systemctl status wildfly, che mostrerà informazioni utili come il PID, lo stato di attivazione e gli eventuali errori di avvio. Il logging verrà indirizzato a journald o, a seconda della configurazione, ai file situati in standalone/log.

Deploy di applicazioni Java

WildFly supporta i tradizionali pacchetti WAR (Web Application Archive) e EAR (Enterprise Archive). Il metodo più semplice per effettuare il deployment è copiare l’artefatto nella directory standalone/deployments; WildFly avvierà automaticamente il processo di autodeploy. Questa modalità è comoda per ambienti di test o per quick‑start, ma presenta dei limiti: non è consigliata per aggiornamenti frequenti o per contesti di alta disponibilità, poiché un errore di deployment può bloccare l’intero server.

Per deployment più controllati, utilizza la console web (accessibile tramite la porta di gestione) o la CLI (Command Line Interface). Un tipico comando CLI per aggiungere un'applicazione è:

/deployment add --name=myapp.war --runtime-name=myapp.war --content=/path/to/myapp.war

La CLI permette di specificare opzioni avanzate, come la modalità di exploded deployment (deployment non compresso) e le dipendenze di modulo, offrendo un maggiore controllo rispetto al semplice autodeploy.

Durante il processo di deployment, WildFly estrae il WAR, verifica le dipendenze (ad esempio le librerie presenti nella cartella WEB-INF/lib) e registra il modulo come pronto per l’esecuzione. Se il deployment è corretto, il server segnalerà lo stato OK nella console di gestione e l’applicazione sarà immediatamente disponibile all’indirizzo configurato.

Gestione e rollback dei deploy

WildFly consente di abilitare, disabilitare o rimuovere un’applicazione in modo dinamico tramite la CLI. I comandi più comuni sono:

/deployment undeploy --name=myapp.war
/deployment remove --name=myapp.war

Per gestire versioni multiple è consigliabile includere il numero di versione nel nome del file (ad esempio myapp-1.2.0.war). Mantieni una directory di backup contenente le versioni precedenti: in caso di problemi, il rollback si riduce a rimuovere la versione difettosa e a riattivare quella stabile, senza dover riavviare l’intero server.

Un approccio più avanzato prevede l’utilizzo di deployment‑scanner configurato per monitorare più directory contemporaneamente, consentendo di separare gli ambienti di staging e di produzione. In questo modo, le nuove versioni possono essere testate in una directory “staging” prima di essere spostate nella directory “production”, riducendo il rischio di downtime.

Troubleshooting comune

I problemi più frequenti in ambito WildFly includono conflitti di porte, uso di una versione di Java non supportata, permessi insufficienti sui file di configurazione o sui deployment, e perdite di memoria dovute a configurazioni errate di thread pool o datasource. Prima di intervenire, verifica sempre il contenuto dei log situati in standalone/log/server.log. Per isolare rapidamente gli errori, utilizza comandi come:

grep ERROR standalone/log/server.log
journalctl -u wildfly | grep ERROR

Se il server non si avvia, controlla le variabili JAVA_HOME e WILDFLY_HOME nel file di unit‑file systemd; un percorso errato è una delle cause più comuni di fallimento. Per problemi di memory leak, analizza le impostazioni dei pools (ad esempio thread-pool e datasource) e valuta di aumentare i valori di max-pool-size o di abilitare il GC logging per monitorare il comportamento della JVM.

Un’altra fonte di difficoltà può essere la sicurezza SELinux su RHEL: assicurati che le policy consentano al servizio WildFly di accedere a /opt/wildfly e ai file di log. In caso di dubbi, esegui temporaneamente il comando setenforce 0 per verificare se il problema è legato a SELinux, ricordando di ripristinare lo stato originale al termine del test.

Conclusione

WildFly rappresenta un compromesso ideale tra potenza, flessibilità e controllo: offre le funzionalità complete di un application server Java EE senza l’ingombro di soluzioni più monolitiche. È particolarmente indicato per progetti enterprise che richiedono gestione transazionale, servizi distribuiti e configurazioni fine‑grained delle risorse. Tuttavia, per applicazioni leggere o micro‑servizi, soluzioni più snelli come Spring Boot, Quarkus o Tomcat possono risultare più efficienti dal punto di vista delle risorse e della rapidità di deployment.

Implementando le best practice illustrate in questo articolo – dalla corretta impostazione delle variabili d’ambiente alla gestione dei deploy tramite CLI – potrai sfruttare al massimo le potenzialità di WildFly, garantendo al contempo sicurezza, scalabilità e affidabilità in tutti gli ambienti, dal testing alla produzione.