Distribuire e configurare un'app Java SE, Tomcat o JBoss EAP nel servizio app di Azure

Per distribuire file jar (Java Archive) in Java SE, usare l'endpoint /api/publish del sito Kudu. Per altre informazioni su questa API, vedere questa documentazione.

Per distribuire file WAR in Tomcat, usare l'endpoint /api/wardeploy/ per POST il file di archivio. Per altre informazioni su questa API, vedere questa documentazione.

Per distribuire file WAR in JBoss EAP, usare l'endpoint /api/wardeploy/ per POST il file di archivio. Per altre informazioni su questa API, vedere questa documentazione.

Per distribuire i file EAR, utilizzare FTP. L'applicazione EAR viene distribuita nella radice del contesto definita nella configurazione dell'applicazione. Ad esempio, se la radice del contesto dell'app è <context-root>myapp</context-root>, è possibile esplorare il sito nel percorso /myapp: http://my-app-name.azurewebsites.net/myapp. Se desideri che la tua applicazione web venga servita nel percorso radice, assicurati che l'applicazione imposti il contesto root sul percorso radice: <context-root>/</context-root>. Per altre informazioni, vedere Impostazione della radice del contesto di un'applicazione Web.

Tomcat fornisce anche una valvola di riscrittura.

JBoss EAP fornisce anche una valvola di riscrittura.

Nel portale di Azure, in Impostazioni applicazione per l'app Web, creare una nuova impostazione dell'app denominata JAVA_OPTS che include altre impostazioni, ad esempio -Xms512m -Xmx1204m.

Nel portale di Azure, in Impostazioni applicazione per l'app Web, creare una nuova impostazione dell'app denominata CATALINA_OPTS che include altre impostazioni, ad esempio -Xms512m -Xmx1204m.

Precompilare i file JSP

Per migliorare le prestazioni delle applicazioni Tomcat, è possibile compilare i file JSP prima della distribuzione nel Servizio app di Azure. È possibile usare il plug-in Maven fornito da Apache Sling o usare questo file di compilazione Ant.

Se si usa Tomcat, è possibile scegliere di aggiungere la versione patch di Tomcat. In Windows è possibile aggiungere le versioni patch di JVM e Tomcat in modo indipendente. In Linux è possibile aggiungere la versione patch di Tomcat. Anche la versione patch della JVM viene bloccata ma non è configurabile separatamente.

Eseguire l'interfaccia della riga di comando di JBoss

Nella sessione SSH dell'app JBoss EAP è possibile eseguire l'interfaccia della riga di comando di JBoss con il comando seguente:

$JBOSS_HOME/bin/jboss-cli.sh --connect

A seconda della posizione in cui JBoss EAP si trova nel ciclo di vita del server, potrebbe non essere possibile connettersi. Attendere alcuni minuti e riprovare. Questo approccio è utile per i controlli rapidi dello stato del server corrente, ad esempio per verificare se un'origine dati è configurata correttamente.

Inoltre, le modifiche apportate al server con l'interfaccia della riga di comando di JBoss nella sessione SSH non vengono mantenute dopo il riavvio dell'app. Ogni volta che l'app viene avviata, il server JBoss EAP inizia con un'installazione pulita. Durante il ciclo di vita di avvio, il servizio app crea le configurazioni del server necessarie e distribuisce l'app. Per apportare modifiche persistenti nel server JBoss EAP, usare uno script di avvio personalizzato o un comando di avvio. Per un esempio end-to-end, vedere Configurare le origini dati per un'app Java SE, Tomcat o JBoss EAP nel servizio app di Azure.

In alternativa, è possibile configurare manualmente servizio app per eseguire qualsiasi file all'avvio. Ad esempio:

az webapp config set --resource-group <group-name> --name <app-name> --startup-file /home/site/scripts/foo.sh

Per altre informazioni sui comandi dell'interfaccia della riga di comando che è possibile eseguire, vedere:

• Documentazione di Red Hat JBoss EAP
• Ricette CLI di WildFly

Raggruppamento

Il servizio app supporta il clustering per JBoss EAP versioni 7.4.1 e successive. Per abilitare il clustering, l'app Web deve essere integrata con una rete virtuale. Quando l'app Web è integrata con una rete virtuale, viene riavviata e l'installazione di JBoss EAP viene avviata automaticamente con una configurazione in cluster. Quando si eseguono più istanze con scalabilità automatica, le istanze JBoss EAP comunicano tra loro tramite la subnet specificata nell'integrazione della rete virtuale. È possibile disabilitare il clustering creando un'impostazione dell'app denominata WEBSITE_DISABLE_CLUSTERING con qualsiasi valore.

Quando il clustering è abilitato, le istanze JBoss EAP usano il FILE_PING protocollo di individuazione JGroups per individuare nuove istanze e rendere persistenti le informazioni sul cluster, ad esempio i membri del cluster, i relativi identificatori e i relativi indirizzi IP. Nel servizio app questi file si trovano in /home/clusterinfo/. La prima istanza EAP da avviare ottiene le autorizzazioni di lettura/scrittura nel file di appartenenza al cluster. Altre istanze leggono il file, trovano il nodo primario e si coordinano con quel nodo per essere incluse nel cluster e aggiunte al file.

I tipi di piano di servizio app Premium V3 e Isolato V2 possono essere distribuiti facoltativamente tra le zone di disponibilità per migliorare la resilienza e l'affidabilità per i carichi di lavoro critici per l'azienda. Questa architettura è nota anche come ridondanza della zona. La funzionalità di clustering JBoss EAP è compatibile con la funzionalità di ridondanza della zona.

Regole di scalabilità automatica

Quando si configurano regole di scalabilità automatica per il ridimensionamento orizzontale, è importante rimuovere le istanze in modo incrementale (una alla volta) per assicurarsi che ogni istanza rimossa possa trasferire l'attività (ad esempio la gestione di una transazione di database) a un altro membro del cluster. Quando si configurano le regole di scalabilità automatica nel portale per ridurre le prestazioni, usare le opzioni seguenti:

• Operazione: "Diminuisci il conteggio di"
• Raffreddamento: "5 minuti" o superiore
• Numero di istanze: 1

Non è necessario aggiungere istanze progressivamente (scalare orizzontalmente). È possibile aggiungere più istanze al cluster alla volta.

Piani del servizio app

JBoss EAP è disponibile nei piani tariffari seguenti: F1, P0v3, P1mv3, P2mv3, P3mv3, P4mv3 e P5mv3.

Ciclo di vita del server JBoss EAP

Un'app JBoss EAP nel servizio app passa attraverso cinque fasi distinte prima di avviare il server:

1. Fase di configurazione dell'ambiente
2. Fase di avvio del server
3. Fase di configurazione del server
4. Fase di distribuzione dell'app
5. Fase di ricaricamento del server

Vedere le sezioni seguenti per informazioni dettagliate e opportunità di personalizzazione, ad esempio tramite le impostazioni dell'app.

1. Fase di configurazione dell'ambiente

• Il servizio SSH viene avviato per abilitare sessioni SSH sicure con il contenitore.
• L'archivio chiavi di runtime Java viene aggiornato con tutti i certificati pubblici e privati definiti nel portale di Azure.
  • I certificati pubblici vengono forniti dalla piattaforma nella /var/ssl/certs directory e vengono caricati in $JRE_HOME/lib/security/cacerts.
  • I certificati privati vengono forniti dalla piattaforma nella /var/ssl/private directory e vengono caricati in $JRE_HOME/lib/security/client.jks.
• Se in questo passaggio vengono caricati certificati nell'archivio chiavi Java, le proprietà javax.net.ssl.keyStore, javax.net.ssl.keyStorePassworde javax.net.ssl.keyStoreType vengono aggiunte alla JAVA_OPTS variabile di ambiente.
• Viene determinata una configurazione JVM iniziale, ad esempio le directory di registrazione e i parametri dell'heap della memoria Java:
  • Se fornisci i flag –Xms o –Xmx per la memoria nell'impostazione JAVA_OPTS, questi valori sostituiscono quelli forniti dalla piattaforma.
  • Se si configura l'impostazione WEBSITES_CONTAINER_STOP_TIME_LIMITdell'app , il valore viene passato alla proprietà org.wildfly.sigterm.suspend.timeoutdi runtime , che controlla il tempo di attesa massimo di arresto (in secondi) quando JBoss EAP viene arrestato.
• Se l'app è integrata con una rete virtuale, il runtime del servizio app passa un elenco di porte da usare per la comunicazione tra server nella variabile WEBSITE_PRIVATE_PORTS di ambiente e avvia JBoss EAP usando la clustering configurazione. In caso contrario, viene usata la standalone configurazione.
  • Per la clustering configurazione, viene usato il file standalone-azure-full-ha.xml di configurazione del server.
  • Per la standalone configurazione, viene usato il file standalone-full.xml di configurazione del server.

2. Fase di avvio del server

• Se JBoss EAP viene avviato nella clustering configurazione:
  • Ogni istanza di JBoss EAP riceve un identificatore interno compreso tra 0 e il numero di istanze in cui viene ridimensionata l'app.
  • Se alcuni file vengono trovati nel percorso dell'archivio transazioni per questa istanza del server (usando il relativo identificatore interno), significa che questa istanza del server sta prendendo il posto di un'istanza del servizio identica. L'altra istanza del servizio si era bloccata in precedenza e aveva lasciato transazioni non confermate. Il server è configurato per riprendere il lavoro su queste transazioni.
• Indipendentemente dal fatto che JBoss EAP venga avviato nella clustering configurazione o standalone , se la versione del server è 7.4 o successiva e il runtime usa Java 17, la configurazione viene aggiornata per abilitare il sottosistema Elytron per la sicurezza.
• Se si configura l'impostazione WEBSITE_JBOSS_OPTSdell'app , il valore viene passato allo script di avvio di JBoss. Questa impostazione può essere usata per fornire percorsi ai file di proprietà e altri flag che influenzano l'avvio di JBoss EAP.

3. Fase di configurazione del server

• All'inizio di questa fase, il servizio app attende innanzitutto che il server JBoss EAP e l'interfaccia di amministrazione siano pronti per ricevere le richieste prima di continuare. Questo processo può richiedere alcuni secondi se Application Insights è abilitato.

• Quando sia il server JBoss EAP che l'interfaccia di amministrazione sono pronti, il servizio app esegue le azioni seguenti:

  • Aggiunge il modulo azure.appserviceJBoss EAP , che fornisce classi di utilità per la registrazione e l'integrazione con il servizio app.
  • Aggiorna il logger della console per usare una modalità senza colore, in modo che i file di log non siano pieni di sequenze di escape dei colori.
  • Configura l'integrazione con i log di Monitoraggio di Azure.
  • Aggiorna gli indirizzi IP di associazione delle interfacce WSDL (Web Services Description Language) e delle interfacce di gestione.
  • Aggiunge il modulo JBoss EAP per l'integrazione con l'autenticazione di App Service e Microsoft Entra ID.
  • Aggiorna la configurazione di registrazione dei log di accesso e il nome e la rotazione del file di log del server principale.

• A meno che l'impostazione WEBSITE_SKIP_AUTOCONFIGURE_DATABASE dell'app non sia definita, App Service rileva automaticamente gli URL JDBC (Java Database Connectivity) nelle impostazioni dell'app. Se esistono URL JDBC validi per PostgreSQL, MySQL, MariaDB, Oracle, SQL Server o database SQL di Azure, aggiunge i driver corrispondenti al server, aggiunge un'origine dati per ogni URL JDBC e imposta il nome JDBC (Java Naming and Directory Interface) per ogni origine dati su java:jboss/env/jdbc/<app-setting-name>_DS, dove <app-setting-name> è il nome dell'impostazione dell'app.

• Se la clustering configurazione è abilitata, viene controllato il logger della console da configurare.

• Se sono presenti file JAR distribuiti nella /home/site/libs directory, viene creato un nuovo modulo globale con tutti questi file JAR.

• Alla fine della fase, App Service esegue lo script di avvio personalizzato, se presente. La logica di ricerca per lo script di avvio personalizzato è definita come segue:

  • Se è stato configurato un comando di avvio (ad esempio, tramite il portale di Azure o l'interfaccia della riga di comando di Azure), eseguirlo; altrimenti
  • Se il percorso /home/site/scripts/startup.sh esiste, usarlo; in caso contrario,
  • Se il percorso /home/startup.sh esiste, usarlo.

Il comando di avvio personalizzato o lo script viene eseguito come utente radice (non è necessario sudo), in modo da poter installare pacchetti Linux o avviare l'interfaccia della riga di comando di JBoss per eseguire più comandi di installazione/personalizzazione di JBoss EAP, ad esempio la creazione di origini dati e l'installazione di adattatori di risorse. Per informazioni sui comandi di gestione dei pacchetti Ubuntu, vedere la documentazione di Ubuntu Server. Per i comandi CLI di JBoss, vedere la Guida alla gestione CLI di JBoss.

4. Fase di distribuzione dell'app

Lo script di avvio distribuisce le app in JBoss EAP esaminando le posizioni seguenti, in ordine di precedenza:

• Se configuri l'impostazione dell'app WEBSITE_JAVA_WAR_FILE_NAME, distribuisci il file designato da tale impostazione.
• Se /home/site/wwwroot/app.war esiste, impiegalo.
• Se esistono altri file EAR e WAR in /home/site/wwwroot, distribuirli.
• Se /home/site/wwwroot/webapps esiste, distribuire i file e le directory in esso contenuti. I file WAR vengono impiegati come applicazioni autonome, e le directory vengono distribuite come applicazioni web scompresse.
• Se esistono pagine JSP autonome in /home/site/wwwroot, copiarle nella radice del server Web e distribuirle come un'unica app Web.
• Se non vengono trovati file distribuibili, distribuire la pagina iniziale predefinita (pagina di parcheggio) nel contesto radice.

5. Fase di ricaricamento del server

• Al termine della procedura di distribuzione, il server JBoss EAP viene ricaricato per applicare eventuali modifiche che richiedono un ricaricamento del server.
• Dopo il ricaricamento del server, le applicazioni distribuite nel server JBoss EAP devono essere pronte per rispondere alle richieste.
• Il server viene eseguito fino a quando l'app del servizio app non viene arrestata o riavviata. È possibile arrestare o riavviare manualmente l'App Service oppure attivare un riavvio quando si distribuiscono file o si apportano modifiche di configurazione all'App Service.
• Se il server JBoss EAP viene chiuso in modo anomalo nella clustering configurazione, viene eseguita una funzione finale denominata emit_alert_tx_store_not_empty . La funzione controlla se il processo JBoss EAP ha lasciato un file di memorizzazione delle transazioni non vuoto su disco. In tal caso, viene registrato un errore nella console: Error: finishing server with non-empty store for node XXXX. Quando viene avviata una nuova istanza del server, cerca questi file di archivio transazioni non netti per riprendere il lavoro (vedere 2. Fase di avvio del server).

Configurazione di base di Tomcat

Gli sviluppatori Java possono personalizzare le impostazioni del server, risolvere i problemi e distribuire applicazioni in Tomcat con sicurezza se conoscono i dettagli di configurazione e file server.xml di Tomcat. Le possibili personalizzazioni includono:

• Personalizzazione della configurazione di Tomcat: quando si comprende il file di server.xml e i dettagli di configurazione di Tomcat, è possibile ottimizzare le impostazioni del server in base alle esigenze delle applicazioni.
• Debug: quando un'applicazione viene distribuita in un server Tomcat, gli sviluppatori devono conoscere la configurazione del server per eseguire il debug di eventuali problemi che potrebbero verificarsi. Questo processo include il controllo dei log del server, l'analisi dei file di configurazione e l'identificazione di eventuali errori che potrebbero verificarsi.
• Risoluzione dei problemi di Tomcat: inevitabilmente, gli sviluppatori Java riscontrano problemi con il server Tomcat, ad esempio problemi di prestazioni o errori di configurazione. Quando si comprende il file di server.xml e i dettagli di configurazione di Tomcat, gli sviluppatori possono diagnosticare e risolvere rapidamente questi problemi, risparmiando tempo e fatica.
• Distribuzione di applicazioni in Tomcat: per distribuire un'applicazione Web Java in Tomcat, gli sviluppatori devono sapere come configurare il file server.xml e altre impostazioni Tomcat. È necessario comprendere questi dettagli per distribuire correttamente le applicazioni e assicurarsi che vengano eseguite senza problemi nel server.

Quando si crea un'app con Tomcat predefinito per ospitare il carico di lavoro Java (un file WAR o un file JAR), sono disponibili alcune impostazioni predefinite per la configurazione di Tomcat. È possibile fare riferimento alla documentazione ufficiale di Apache Tomcat per informazioni dettagliate, inclusa la configurazione predefinita per Il server Web Tomcat.

Inoltre, all'avvio vengono applicate alcune trasformazioni aggiuntive al file server.xml per la distribuzione di Tomcat. Queste trasformazioni includono modifiche alle impostazioni Connettore, Host e Valvola .

Le versioni più recenti di Tomcat hanno server.xml (8.5.58 e 9.0.38 e versioni successive). Le versioni precedenti di Tomcat non usano trasformazioni e potrebbero avere un comportamento diverso.

Connettore

<Connector port="${port.http}" address="127.0.0.1" maxHttpHeaderSize="16384" compression="on" URIEncoding="UTF-8" connectionTimeout="${site.connectionTimeout}" maxThreads="${catalina.maxThreads}" maxConnections="${catalina.maxConnections}" protocol="HTTP/1.1" redirectPort="8443"/>

• maxHttpHeaderSize è impostato su 16384.
• URIEncoding è impostato su UTF-8.
• connectionTimeout è impostato su WEBSITE_TOMCAT_CONNECTION_TIMEOUT, che per impostazione predefinita è 240000.
• maxThreads è impostato su WEBSITE_CATALINA_MAXTHREADS, che per impostazione predefinita è 200.
• maxConnections è impostato su WEBSITE_CATALINA_MAXCONNECTIONS, che per impostazione predefinita è 10000.

Di seguito sono riportati i comandi dell'interfaccia della riga di comando di esempio che è possibile usare per modificare i valori di connectionTimeout, maxThreadso maxConnections:

az webapp config appsettings set --resource-group myResourceGroup --name myApp --settings WEBSITE_TOMCAT_CONNECTION_TIMEOUT=120000

az webapp config appsettings set --resource-group myResourceGroup --name myApp --settings WEBSITE_CATALINA_MAXTHREADS=100

az webapp config appsettings set --resource-group myResourceGroup --name myApp --settings WEBSITE_CATALINA_MAXCONNECTIONS=5000

Il connettore usa l'indirizzo del contenitore anziché 127.0.0.1.

Padrone di casa / Ospitante / Conduttore (depending on the intended context)

<Host appBase="${site.appbase}" xmlBase="${site.xmlbase}" unpackWARs="${site.unpackwars}" workDir="${site.tempdir}" errorReportValveClass="com.microsoft.azure.appservice.AppServiceErrorReportValve" name="localhost" autoDeploy="true">

• appBase è impostato su AZURE_SITE_APP_BASE, che per impostazione predefinita è locale WebappsLocalPath.
• xmlBase è impostato su AZURE_SITE_HOME, che per impostazione predefinita è /site/wwwroot.
• unpackWARs è impostato su AZURE_UNPACK_WARS, che per impostazione predefinita è true.
• workDir è impostato su JAVA_TMP_DIR, che imposta TMP come impostazione predefinita.
• errorReportValveClass utilizza la nostra valvola personalizzata per la segnalazione degli errori.

Valvola

<Valve prefix="site_access_log.${catalina.instance.name}" pattern="%h %l %u %t &quot;%r&quot; %s %b %D %{x-arr-log-id}i" directory="${site.logdir}/http/RawLogs" maxDays="${site.logRetentionDays}" className="org.apache.catalina.valves.AccessLogValve" suffix=".txt"/>

• directory è impostato su AZURE_LOGGING_DIR, che per impostazione predefinita è home\logFiles.
• maxDays è impostato su WEBSITE_HTTPLOGGING_RETENTION_DAYS, che per impostazione predefinita è 7. Questo valore è allineato all'impostazione predefinita della piattaforma di registrazione delle applicazioni.

In Linux ha tutte le stesse personalizzazioni e aggiunge alcune pagine di errore e segnalazione alla valvola:

<xsl:attribute name="appServiceErrorPage">
    <xsl:value-of select="'${appService.valves.appServiceErrorPage}'"/>
</xsl:attribute>

<xsl:attribute name="showReport">
    <xsl:value-of select="'${catalina.valves.showReport}'"/>
</xsl:attribute>

<xsl:attribute name="showServerInfo">
    <xsl:value-of select="'${catalina.valves.showServerInfo}'"/>
</xsl:attribute>