Configurare un'app Java per Servizio app di Azure

Articolo
04/16/2024

Nota

Per le applicazioni Spring, è consigliabile usare Azure Spring Apps. Tuttavia, è comunque possibile usare app Azure Servizio come destinazione.

app Azure Servizio consente agli sviluppatori Java di compilare, distribuire e ridimensionare rapidamente le applicazioni Web Java edizione Standard, Tomcat e JBoss EAP in un servizio completamente gestito. Distribuire applicazioni con plug-in Maven, dalla riga di comando o in editor come IntelliJ, Eclipse o Visual Studio Code.

Questa guida fornisce concetti chiave e istruzioni per gli sviluppatori Java che usano servizio app. Se non è mai stato usato app Azure Servizio, è necessario leggere prima la guida introduttiva di Java. Le domande generali sull'uso di servizio app non specifiche per lo sviluppo Java sono disponibili nelle domande frequenti servizio app.

Visualizzare la versione java

Per visualizzare la versione corrente di Java, eseguire il comando seguente in Cloud Shell:

az webapp config show --name <app-name> --resource-group <resource-group-name> --query "[javaVersion, javaContainer, javaContainerVersion]"

Per visualizzare tutte le versioni java supportate, eseguire il comando seguente in Cloud Shell:

az webapp list-runtimes --os windows | grep java

Per visualizzare la versione corrente di Java, eseguire il comando seguente in Cloud Shell:

az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion

Per visualizzare tutte le versioni java supportate, eseguire il comando seguente in Cloud Shell:

az webapp list-runtimes --os linux | grep "JAVA\|TOMCAT\|JBOSSEAP"

Per altre informazioni sul supporto della versione, vedere servizio app criteri di supporto del runtime del linguaggio.

Distribuzione dell'app

Build Tools

Maven

Con il plug-in Maven per Azure App Web, è possibile preparare facilmente il progetto Java Maven per App Web di Azure con un comando nella radice del progetto:

mvn com.microsoft.azure:azure-webapp-maven-plugin:2.11.0:config

Questo comando aggiunge un azure-webapp-maven-plugin plug-in e una configurazione correlata richiedendo di selezionare un'app Web di Azure esistente o crearne una nuova. Quindi è possibile distribuire l'app Java in Azure con il comando seguente:

mvn package azure-webapp:deploy

Ecco una configurazione di esempio in pom.xml:

<plugin> 
  <groupId>com.microsoft.azure</groupId>  
  <artifactId>azure-webapp-maven-plugin</artifactId>  
  <version>2.11.0</version>  
  <configuration>
    <subscriptionId>111111-11111-11111-1111111</subscriptionId>
    <resourceGroup>spring-boot-xxxxxxxxxx-rg</resourceGroup>
    <appName>spring-boot-xxxxxxxxxx</appName>
    <pricingTier>B2</pricingTier>
    <region>westus</region>
    <runtime>
      <os>Linux</os>      
      <webContainer>Java SE</webContainer>
      <javaVersion>Java 11</javaVersion>
    </runtime>
    <deployment>
      <resources>
        <resource>
          <type>jar</type>
          <directory>${project.basedir}/target</directory>
          <includes>
            <include>*.jar</include>
          </includes>
        </resource>
      </resources>
    </deployment>
  </configuration>
</plugin>

Gradle

Configurare il plug-in Gradle per Azure App Web aggiungendo il plug-in al :build.gradle
```
plugins {
  id "com.microsoft.azure.azurewebapp" version "1.7.1"
}
```

Configurare i dettagli dell'app Web. Le risorse di Azure corrispondenti vengono create se non esistono. Ecco una configurazione di esempio, per informazioni dettagliate, vedere questo documento.

azurewebapp {
    subscription = '<your subscription id>'
    resourceGroup = '<your resource group>'
    appName = '<your app name>'
    pricingTier = '<price tier like 'P1v2'>'
    region = '<region like 'westus'>'
    runtime {
      os = 'Linux'
      webContainer = 'Tomcat 9.0' // or 'Java SE' if you want to run an executable jar
      javaVersion = 'Java 8'
    }
    appSettings {
        <key> = <value>
    }
    auth {
        type = 'azure_cli' // support azure_cli, oauth2, device_code and service_principal
    }
}

Eseguire la distribuzione con un unico comando.
```
gradle azureWebAppDeploy
```

IDE

Azure offre un'esperienza di sviluppo java servizio app semplice negli IDE Java più diffusi, tra cui:

VS Code: Java App Web con Visual Studio Code
IntelliJ IDEA:Creare un'app Web Hello World per app Azure Servizio con IntelliJ
Eclipse:Creare un'app Web Hello World per app Azure Servizio con Eclipse

Kudu API

Java SE

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

Nota

L'applicazione .jar deve essere denominata app.jar per servizio app per identificare ed eseguire l'applicazione. Il plug-in Maven esegue automaticamente questa operazione durante la distribuzione. Se non si vuole rinominare il file JAR in app.jar, è possibile caricare uno script della shell con il comando per eseguire l'app .jar. Incollare il percorso assoluto di questo script nella casella di testo File di avvio nella sezione Configurazione del portale. Lo script di avvio non viene eseguito dalla directory in cui si trova. Pertanto, usare sempre percorsi assoluti per fare riferimento ai file dello script di avvio, ad esempio java -jar /home/myapp/myapp.jar.

Tomcat

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

JBoss EAP

Per distribuire file con estensione war in JBoss, usare l'endpoint /api/wardeploy/ per pubblicare il file di archivio. Per altre informazioni su questa API, vedere questa documentazione.

Per distribuire file con estensione ear, usare 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 /myapp percorso: http://my-app-name.azurewebsites.net/myapp. Se si vuole che l'app Web venga servita nel percorso radice, assicurarsi che l'app imposti la radice del contesto sul percorso radice: <context-root>/</context-root>. Per altre informazioni, vedere Impostazione della radice del contesto di un'applicazione Web.

Non distribuire il file con estensione war o .jar tramite FTP. Lo strumento FTP è stato progettato per caricare script di avvio, dipendenze o altri file di runtime. Non è la scelta ottimale per la distribuzione di app Web.

Registrazione e debug delle app

Nel portale di Azure sono disponibili report sulle prestazioni, visualizzazioni del traffico e controlli dell'integrità per ogni app. Per altre informazioni, vedere Panoramica approfondita della diagnostica del Servizio app di Azure.

Eseguire lo streaming dei log di diagnostica

Per accedere ai log della console generati dall'interno del codice dell'applicazione nel servizio app, attivare la registrazione diagnostica eseguendo il comando seguente in Cloud Shell:

az webapp log config --resource-group <resource-group-name> --name <app-name> --docker-container-logging filesystem --level Verbose

I valori possibili per --level sono: Error, Warning, Info e Verbose. Ogni livello successivo include il livello precedente. Ad esempio, Error include solo i messaggi di errore, mentre Verbose include tutti i messaggi.

Dopo aver attivato la registrazione diagnostica, eseguire il comando seguente per visualizzare il flusso di registrazione:

az webapp log tail --resource-group <resource-group-name> --name <app-name>

Se i log di console non sono immediatamente visibili, controllare nuovamente dopo 30 secondi.

Nota

È anche possibile esaminare i file di log nel browser all'indirizzo https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Per interrompere lo streaming dei log in qualsiasi momento, digitare Ctrl+C.

È possibile accedere ai log della console generati dall'interno del contenitore.

Prima di tutto attivare la registrazione del contenitore eseguendo questo comando:

az webapp log config --name <app-name> --resource-group <resource-group-name> --docker-container-logging filesystem

Sostituire <app-name> e <resource-group-name> con i valori appropriati per l'app Web.

Dopo che la registrazione del contenitore è attivata, eseguire il comando seguente per visualizzare il flusso di registrazione:

az webapp log tail --name <app-name> --resource-group <resource-group-name>

Se i log di console non sono immediatamente visibili, controllare nuovamente dopo 30 secondi.

Per interrompere lo streaming dei log in qualsiasi momento, premere CTRL+C.

È anche possibile ispezionare i file di log in un browser all'indirizzo https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Per altre informazioni, vedere Eseguire lo streaming dei log in Cloud Shell.

Accesso alla console SSH

Per aprire una sessione SSH diretta con il contenitore, l'app deve essere in esecuzione.

Incollare l'URL seguente nel browser e sostituire <app-name> con il nome dell'app:

https://<app-name>.scm.azurewebsites.net/webssh/host

Se non lo si è già fatto, per connettersi è necessario eseguire l'autenticazione con la sottoscrizione di Azure. Al termine dell'autenticazione viene visualizzata una shell nel browser, in cui è possibile eseguire i comandi all'interno del contenitore.

Connessione SSH

Nota

Le eventuali modifiche apportate all'esterno della directory /home vengono archiviate nel contenitore stesso e non persistono oltre il riavvio dell'app.

Per aprire una sessione SSH remota dal computer locale, vedere Aprire una sessione SSH dalla shell remota.

Strumenti per la risoluzione dei problemi

Le immagini Java integrate sono basate sul sistema operativo Alpine Linux. Usare la gestione pacchetti apk per installare gli strumenti o i comandi per la risoluzione dei problemi.

Java Profiler

Tutti i runtime Java in app Azure Service sono dotati di JDK Flight Recorder per la profilatura dei carichi di lavoro Java. È possibile usarlo per registrare eventi di JVM, sistema e applicazioni e risolvere i problemi nelle applicazioni.

Per altre informazioni su Java Profiler, vedere la documentazione di app Azure lication Insights.

Flight Recorder

Tutti i runtime Java in servizio app sono dotati di Java Flight Recorder. È possibile usarlo per registrare eventi di JVM, sistema e applicazioni e risolvere i problemi nelle applicazioni Java.

Registrazione temporizzata

Per eseguire una registrazione temporale, è necessario il PID (ID processo) dell'applicazione Java. Per trovare il PID, aprire un browser per il sito SCM dell'app Web all'indirizzo https://<your-site-name>.scm.azurewebsites.net/ProcessExplorer/. Questa pagina mostra i processi in esecuzione nell'app Web. Trovare il processo denominato "java" nella tabella e copiare il PID corrispondente (ID processo).

Aprire quindi la console di debug nella barra degli strumenti superiore del sito SCM ed eseguire il comando seguente. Sostituire <pid> con l'ID processo copiato in precedenza. Questo comando avvia una registrazione del profiler di 30 secondi dell'applicazione Java e genera un file denominato timed_recording_example.jfr nella C:\home directory.

jcmd <pid> JFR.start name=TimedRecording settings=profile duration=30s filename="C:\home\timed_recording_example.JFR"

Eseguire SSH nel servizio app ed eseguire il jcmd comando per visualizzare un elenco di tutti i processi Java in esecuzione. Oltre a jcmd, l'applicazione Java dovrebbe essere in esecuzione con un numero ID processo (PID).

078990bbcd11:/home# jcmd
Picked up JAVA_TOOL_OPTIONS: -Djava.net.preferIPv4Stack=true
147 sun.tools.jcmd.JCmd
116 /home/site/wwwroot/app.jar

Eseguire il comando seguente per avviare una registrazione di 30 secondi della JVM. Esegue la profilatura della JVM e crea un file JFR denominato jfr_example.jfr nella home directory. (Sostituire 116 con il PID dell'app Java.)

jcmd 116 JFR.start name=MyRecording settings=profile duration=30s filename="/home/jfr_example.jfr"

Durante l'intervallo di 30 secondi, è possibile verificare che la registrazione venga eseguita eseguendo jcmd 116 JFR.check. Il comando mostra tutte le registrazioni per il processo Java specificato.

Registrazione continua

È possibile usare Java Flight Recorder per profilare continuamente l'applicazione Java con un impatto minimo sulle prestazioni di runtime. A tale scopo, eseguire il comando dell'interfaccia della riga di comando di Azure seguente per creare un'impostazione dell'app denominata JAVA_OPTS con la configurazione necessaria. Il contenuto dell'impostazione dell'app JAVA_OPTS viene trasmesso al comando java quando l'app viene avviata.

az webapp config appsettings set -g <your_resource_group> -n <your_app_name> --settings JAVA_OPTS=-XX:StartFlightRecording=disk=true,name=continuous_recording,dumponexit=true,maxsize=1024m,maxage=1d

Dopo l'avvio della registrazione, è possibile eseguire il dump dei dati di registrazione correnti in qualsiasi momento usando il JFR.dump comando .

jcmd <pid> JFR.dump name=continuous_recording filename="/home/recording1.jfr"

Analizzare i `.jfr` file

Usare FTPS per scaricare il file JFR nel computer locale. Per analizzare il file JFR, scaricare e installare Java Mission Control. Per istruzioni su Java Mission Control, vedere la documentazione di JMC e le istruzioni di installazione.

Registrazione dell'app

Abilitare la registrazione dell'applicazione tramite il portale di Azure o l'interfaccia della riga di comando di Azure per configurare il servizio app per scrivere l'output della console standard dell'applicazione e i flussi di errori della console standard nel file system locale o in Archiviazione BLOB di Azure. La registrazione all'istanza del file system locale servizio app è disabilitata 12 ore dopo la configurazione. Se è necessario un periodo di conservazione più lungo, configurare l'applicazione per scrivere l'output in un contenitore di archiviazione BLOB. I log delle app Java e Tomcat sono reperibili nella directory /home/LogFiles/Application/.

Abilitare la registrazione dell'applicazione tramite il portale di Azure o l'interfaccia della riga di comando di Azure per configurare il servizio app per scrivere l'output della console standard dell'applicazione e i flussi di errori della console standard nel file system locale o in Archiviazione BLOB di Azure. Se è necessario un periodo di conservazione più lungo, configurare l'applicazione per scrivere l'output in un contenitore di archiviazione BLOB. I log delle app Java e Tomcat sono reperibili nella directory /home/LogFiles/Application/.

Archiviazione BLOB di Azure la registrazione per le app basate su Linux può essere configurata solo usando Monitoraggio di Azure.

Se l'applicazione usa Logback o Log4j per la traccia, è possibile inoltrare queste tracce per la revisione ad Azure Application Insights usando le istruzioni di configurazione del framework di registrazione illustrate in Esplorare i log di traccia Java in Application Insights.

Nota

A causa della vulnerabilità nota CVE-2021-44228, assicurarsi di usare Log4j versione 2.16 o successiva.

Personalizzazione e ottimizzazione

app Azure Servizio supporta l'ottimizzazione e la personalizzazione predefinite tramite portale di Azure e l'interfaccia della riga di comando. Per la configurazione delle app Web non specifiche di Java, vedere gli articoli seguenti:

Copiare il contenuto dell'app in locale

Impostare l'impostazione JAVA_COPY_ALL dell'app su true per copiare il contenuto dell'app nel ruolo di lavoro locale dal file system condiviso. Questa impostazione consente di risolvere i problemi di blocco dei file.

Impostare le opzioni di runtime Java

Per impostare la memoria allocata o altre opzioni di runtime JVM, creare un'impostazione dell'app denominata JAVA_OPTS con le opzioni. servizio app passa questa impostazione come variabile di ambiente al runtime Java all'avvio.

Nella portale di Azure, in Application Impostazioni for the Web app (Applicazione Impostazioni per l'app Web) creare una nuova impostazione dell'app denominata JAVA_OPTS per Java edizione Standard o CATALINA_OPTS per Tomcat che include altre impostazioni, ad esempio -Xms512m -Xmx1204m.

Per configurare l'impostazione dell'app dal plug-in Maven, aggiungere i tag setting/value nella sezione dei plug-in di Azure. L'esempio seguente imposta le dimensioni heap Java specifiche minime e massime:

<appSettings>
    <property>
        <name>JAVA_OPTS</name>
        <value>-Xms1024m -Xmx1024m</value>
    </property>
</appSettings>

Nota

Non è necessario creare un file web.config quando si usa Tomcat in Windows servizio app.

Gli sviluppatori che eseguono una singola applicazione con uno slot di distribuzione nel piano di servizio app possono usare le opzioni seguenti:

Istanze B1 e S1: -Xms1024m -Xmx1024m
Istanze B2 e S2: -Xms3072m -Xmx3072m
Istanze B3 e S3: -Xms6144m -Xmx6144m
Istanze P1v2: -Xms3072m -Xmx3072m
Istanze P2v2: -Xms6144m -Xmx6144m
Istanze P3v2: -Xms12800m -Xmx12800m
Istanze P1v3: -Xms6656m -Xmx6656m
Istanze P2v3: -Xms14848m -Xmx14848m
Istanze P3v3: -Xms30720m -Xmx30720m
Istanze di I1: -Xms3072m -Xmx3072m
Istanze di I2: -Xms6144m -Xmx6144m
Istanze di I3: -Xms12800m -Xmx12800m
Istanze di I1v2: -Xms6656m -Xmx6656m
Istanze di I2v2: -Xms14848m -Xmx14848m
Istanze di I3v2: -Xms30720m -Xmx30720m

Quando si ottimizzano le impostazioni heap delle applicazioni, esaminare i dettagli del piano di servizio app e tenere in considerazione le esigenze di più applicazioni e slot di distribuzione per trovare l'allocazione ottimale della memoria.

Attivare i Web Socket

Attivare il supporto per i Web Socket nel portale di Azure in Impostazioni applicazione per l'applicazione. Per rendere effettiva l'impostazione, è necessario riavviare l'applicazione.

Attivare il supporto per i Web Socket usando l'interfaccia della riga di comando di Azure con il comando seguente:

az webapp config set --name <app-name> --resource-group <resource-group-name> --web-sockets-enabled true

Riavviare quindi l'applicazione:

az webapp stop --name <app-name> --resource-group <resource-group-name>
az webapp start --name <app-name> --resource-group <resource-group-name>

Impostare la codifica dei caratteri predefinita

Nel portale di Azure, sotto Impostazioni applicazione per l'app Web creare una nuova impostazione dell'app denominata JAVA_OPTS con il valore -Dfile.encoding=UTF-8.

In alternativa, è possibile configurare l'impostazione dell'app usando il plug-in Maven del servizio app. Aggiungere i tag name e value dell'impostazione nella configurazione del plug-in:

<appSettings>
    <property>
        <name>JAVA_OPTS</name>
        <value>-Dfile.encoding=UTF-8</value>
    </property>
</appSettings>

Pre-compilare 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 questo file di compilazione Ant.

Proteggere le applicazioni

Le applicazioni Java in esecuzione in servizio app hanno lo stesso set di procedure consigliate per la sicurezza di altre applicazioni.

Autenticare gli utenti (Easy Auth)

Configurare l'autenticazione dell'app nel portale di Azure con l'opzione Autenticazione e autorizzazione, Da qui è possibile abilitare l'autenticazione usando l'ID Microsoft Entra o gli accessi di social networking, ad esempio Facebook, Google o GitHub. La configurazione nel portale di Azure funziona solo quando si configura un singolo provider di autenticazione. Per altre informazioni, vedere Configurare l'app servizio app per l'uso dell'accesso a Microsoft Entra e gli articoli correlati per altri provider di identità. Se è necessario abilitare più provider di accesso, seguire le istruzioni in Personalizzare gli accessi e le disconnessazioni.

Java SE

Gli sviluppatori Spring Boot possono usare lo starter Microsoft Entra Spring Boot per proteggere le applicazioni usando annotazioni e API di Spring Security familiari. Assicurarsi di aumentare le dimensioni massime dell'intestazione nel file application.properties. È consigliabile il valore 16384.

Tomcat

L'applicazione Tomcat può accedere alle attestazioni dell'utente direttamente dalla servlet eseguendo il cast dell'oggetto Principal a un oggetto Map. L'oggetto esegue il Map mapping di ogni tipo di attestazione a una raccolta di attestazioni per tale tipo. Nell'esempio di codice seguente è request un'istanza di HttpServletRequest.

Map<String, Collection<String>> map = (Map<String, Collection<String>>) request.getUserPrincipal();

A questo punto è possibile esaminare l'oggetto Map per qualsiasi attestazione specifica. Il frammento di codice seguente, ad esempio, esegue l'iterazione di tutti i tipi di attestazione e stampa il contenuto di ogni raccolta.

for (Object key : map.keySet()) {
        Object value = map.get(key);
        if (value != null && value instanceof Collection {
            Collection claims = (Collection) value;
            for (Object claim : claims) {
                System.out.println(claims);
            }
        }
    }

Per disconnettere gli utenti, usare il /.auth/ext/logout percorso. Per eseguire altre azioni, vedere la documentazione su Personalizzare gli accessi e le disconnessazioni. È disponibile anche la documentazione ufficiale sull'interfaccia Tomcat HttpServletRequest e sui relativi metodi. Anche i seguenti metodi servlet vengono idratati in base alla configurazione del Servizio app di Azure:

public boolean isSecure()
public String getRemoteAddr()
public String getRemoteHost()
public String getScheme()
public int getServerPort()

Per disabilitare questa funzionalità, creare un'impostazione dell'applicazione denominata WEBSITE_AUTH_SKIP_PRINCIPAL con un valore di 1. Per disabilitare tutti i filtri servlet aggiunti dal Servizio app di Azure, creare un'impostazione denominata WEBSITE_SKIP_FILTERS con un valore di 1.

Configurare TLS/SSL

Per caricare un certificato TLS/SSL esistente e associarlo al nome di dominio dell'applicazione, seguire le istruzioni riportate in Proteggere un nome DNS personalizzato con un'associazione TLS/SSL in app Azure Servizio. È anche possibile configurare l'app per applicare TLS/SSL.

Usare i riferimenti di KeyVault

Azure KeyVault fornisce la gestione centralizzata dei segreti con i criteri di accesso e la cronologia controlli. È possibile archiviare segreti (ad esempio password o stringhe di connessione) in KeyVault e accedere a questi segreti nell'applicazione tramite le variabili di ambiente.

Prima di tutto, seguire le istruzioni per concedere all'app l'accesso a un insieme di credenziali delle chiavi e creare un riferimento keyvault al segreto in un'impostazione dell'applicazione. È possibile verificare che il riferimento venga risolto nel segreto stampando la variabile di ambiente durante l'accesso remoto al terminale del Servizio app di Azure.

Per inserire questi segreti nel file di configurazione di Spring o Tomcat, usare la sintassi di inserimento delle variabili di ambiente (${MY_ENV_VAR}). Per i file di configurazione spring, vedere questa documentazione sulle configurazioni esterne.

Usare l'archivio chiavi Java

Per impostazione predefinita, tutti i certificati pubblici o privati caricati in servizio app Linux vengono caricati nei rispettivi archivi chiavi Java all'avvio del contenitore. Dopo aver caricato il certificato, è necessario riavviare il servizio app perché venga caricato nell'archivio chiavi Java. I certificati pubblici vengono caricati nell'archivio chiavi in $JRE_HOME/lib/security/cacerts, mentre i certificati privati vengono archiviati in $JRE_HOME/lib/security/client.jks.

Potrebbe essere necessaria una configurazione maggiore per crittografare la connessione JDBC con i certificati nell'archivio chiavi Java. Fare riferimento alla documentazione relativa al driver JDBC scelto.

Inizializzare l'archivio chiavi Java

Per inizializzare l'oggetto import java.security.KeyStore, caricare il file dell'archivio chiavi con la password. La password predefinita per entrambi gli archivi chiavi è changeit.

KeyStore keyStore = KeyStore.getInstance("jks");
keyStore.load(
    new FileInputStream(System.getenv("JRE_HOME")+"/lib/security/cacerts"),
    "changeit".toCharArray());

KeyStore keyStore = KeyStore.getInstance("pkcs12");
keyStore.load(
    new FileInputStream(System.getenv("JRE_HOME")+"/lib/security/client.jks"),
    "changeit".toCharArray());

Caricare manualmente l'archivio chiavi

È possibile caricare manualmente i certificati nell'archivio chiavi. Creare un'impostazione dell'app, SKIP_JAVA_KEYSTORE_LOAD, con un valore 1 per disabilitare il caricamento automatico dei certificati nell'archivio chiavi da parte del Servizio app di Azure. Tutti i certificati pubblici caricati nel Servizio app di Azure tramite il portale di Azure vengono archiviati in /var/ssl/certs/. Tutti i certificati privati sono archiviati in /var/ssl/private/.

È possibile interagire o eseguire il debug dello strumento chiave Java aprendo una connessione SSH al Servizio app di Azure ed eseguendo il comando keytool. Per un elenco di comandi, vedere la documentazione dello strumento chiave. Per altre informazioni sull'API KeyStore, vedere la documentazione ufficiale.

Configurare le piattaforme APM

Questa sezione illustra come connettere le applicazioni Java distribuite in app Azure Servizio con Application Insights di Monitoraggio di Azure, NewRelic e le piattaforme di monitoraggio delle prestazioni delle applicazioni AppDynamics .This section how to connect Java applications deployed on app Azure Service with Azure Monitor Application Insights, NewRelic, and AppDynamics application performance monitoring (APM).

Configurare Application Insights

Application Insights di Monitoraggio di Azure è un servizio di monitoraggio delle applicazioni nativo del cloud che consente ai clienti di osservare errori, colli di bottiglia e modelli di utilizzo per migliorare le prestazioni dell'applicazione e ridurre il tempo medio di risoluzione (MTTR). Con pochi clic o comandi dell'interfaccia della riga di comando, è possibile abilitare il monitoraggio per le app Node.js o Java, la raccolta automatica di log, metriche e tracce distribuite, eliminando la necessità di includere un SDK nell'app. Per altre informazioni sulle impostazioni dell'app disponibili per la configurazione dell'agente, vedere la documentazione di Application Insights.

Azure portal

Per abilitare Application Insights dalla portale di Azure, passare ad Application Insights nel menu a sinistra e selezionare Attiva Application Insights. Per impostazione predefinita, viene usata una nuova risorsa di Application Insights con lo stesso nome dell'app Web. È possibile scegliere di usare una risorsa di Application Insights esistente o modificare il nome. Selezionare Applica nella parte inferiore.

Interfaccia della riga di comando di Azure

Per abilitare tramite l'interfaccia della riga di comando di Azure, è necessario creare una risorsa di Application Insights e impostare un paio di impostazioni dell'app nel portale di Azure per connettere Application Insights all'app Web.

Abilitare l'estensione Application Insights
```
az extension add -n application-insights
```
Creare una risorsa di Application Insights usando il comando dell'interfaccia della riga di comando seguente. Sostituire i segnaposto con il nome e il gruppo di risorse desiderati.
```
az monitor app-insights component create --app <resource-name> -g <resource-group> --location westus2  --kind web --application-type web
```
Si notino i valori per connectionString e instrumentationKey, questi valori saranno necessari nel passaggio successivo.

Per recuperare un elenco di altri percorsi, eseguire az account list-locations.

Impostare la chiave di strumentazione, stringa di connessione e la versione dell'agente di monitoraggio come impostazioni dell'app nell'app Web. Sostituire <instrumentationKey> e <connectionString> con i valori del passaggio precedente.

az webapp config appsettings set -n <webapp-name> -g <resource-group> --settings "APPINSIGHTS_INSTRUMENTATIONKEY=<instrumentationKey>" "APPLICATIONINSIGHTS_CONNECTION_STRING=<connectionString>" "ApplicationInsightsAgent_EXTENSION_VERSION=~3" "XDT_MicrosoftApplicationInsights_Mode=default" "XDT_MicrosoftApplicationInsights_Java=1"

az webapp config appsettings set -n <webapp-name> -g <resource-group> --settings "APPINSIGHTS_INSTRUMENTATIONKEY=<instrumentationKey>" "APPLICATIONINSIGHTS_CONNECTION_STRING=<connectionString>" "ApplicationInsightsAgent_EXTENSION_VERSION=~3" "XDT_MicrosoftApplicationInsights_Mode=default"

Configurare New Relic

Creare un account NewRelic in NewRelic.com
Scaricare l'agente Java da NewRelic. Ha un nome di file simile a newrelic-java-x.x.x.zip.
Copiare il codice di licenza, necessario per configurare l'agente in un secondo momento.
Usare SSH per connettersi all'istanza del Servizio app di Azure e creare una nuova directory /home/site/wwwroot/apm.
Caricare i file dell'agente Java NewRelic decompressi in una directory in /home/site/wwwroot/apm. I file per l'agente devono trovarsi in /home/site/wwwroot/apm/newrelic.
Modificare il file YAML in /home/site/wwwroot/apm/newrelic/newrelic.yml e sostituire il valore della licenza segnaposto con il proprio codice di licenza.
Nel portale di Azure passare all'applicazione nel servizio app e creare una nuova impostazione dell'applicazione.
- Per le app Java edizione Standard creare una variabile di ambiente denominata JAVA_OPTS con il valore -javaagent:/home/site/wwwroot/apm/newrelic/newrelic.jar.
- Per Tomcat, creare una variabile di ambiente denominata CATALINA_OPTS con il valore -javaagent:/home/site/wwwroot/apm/newrelic/newrelic.jar.

Creare un account NewRelic in NewRelic.com
Scaricare l'agente Java da NewRelic. Ha un nome di file simile a newrelic-java-x.x.x.zip.
Copiare il codice di licenza, che sarà necessario per configurare l'agente in un secondo momento.
Usare SSH per connettersi all'istanza del Servizio app di Azure e creare una nuova directory /home/site/wwwroot/apm.
Caricare i file dell'agente Java NewRelic decompressi in una directory in /home/site/wwwroot/apm. I file per l'agente devono trovarsi in /home/site/wwwroot/apm/newrelic.
Modificare il file YAML in /home/site/wwwroot/apm/newrelic/newrelic.yml e sostituire il valore della licenza segnaposto con il proprio codice di licenza.
Nel portale di Azure passare all'applicazione nel servizio app e creare una nuova impostazione dell'applicazione.
- Per le app Java edizione Standard creare una variabile di ambiente denominata JAVA_OPTS con il valore -javaagent:/home/site/wwwroot/apm/newrelic/newrelic.jar.
- Per Tomcat, creare una variabile di ambiente denominata CATALINA_OPTS con il valore -javaagent:/home/site/wwwroot/apm/newrelic/newrelic.jar.

Se si dispone già di una variabile di ambiente per JAVA_OPTS oppure CATALINA_OPTS, aggiungere l'opzione -javaagent:/... alla fine del valore corrente.

Configurare AppDynamics

Creare un account AppDynamics in AppDynamics.com
Scaricare l'agente Java dal sito Web AppDynamics. Il nome del file è simile a AppServerAgent-x.x.x.xxxxx.zip
Usare la console Kudu per creare una nuova directory /home/site/wwwroot/apm.
Caricare i file dell'agente Java decompressi in una directory in /home/site/wwwroot/apm. I file per l'agente devono trovarsi in /home/site/wwwroot/apm/appdynamics.
Nel portale di Azure passare all'applicazione nel servizio app e creare una nuova impostazione dell'applicazione.
- Per le app Java edizione Standard, creare una variabile di ambiente denominata con il valore <app-name>-javaagent:/home/site/wwwroot/apm/appdynamics/javaagent.jar -Dappdynamics.agent.applicationName=<app-name> dove JAVA_OPTS è il nome servizio app.
- Per le app Tomcat, creare una variabile di ambiente denominata con il valore -javaagent:/home/site/wwwroot/apm/appdynamics/javaagent.jar -Dappdynamics.agent.applicationName=<app-name><app-name> dove CATALINA_OPTS è il nome servizio app.

Creare un account AppDynamics in AppDynamics.com
Scaricare l'agente Java dal sito Web AppDynamics. Il nome del file è simile a AppServerAgent-x.x.x.xxxxx.zip
Usare SSH per connettersi all'istanza del Servizio app di Azure e creare una nuova directory /home/site/wwwroot/apm.
Caricare i file dell'agente Java decompressi in una directory in /home/site/wwwroot/apm. I file per l'agente devono trovarsi in /home/site/wwwroot/apm/appdynamics.
Nel portale di Azure passare all'applicazione nel servizio app e creare una nuova impostazione dell'applicazione.
- Per le app Java edizione Standard, creare una variabile di ambiente denominata con il valore <app-name>-javaagent:/home/site/wwwroot/apm/appdynamics/javaagent.jar -Dappdynamics.agent.applicationName=<app-name> dove JAVA_OPTS è il nome servizio app.
- Per le app Tomcat, creare una variabile di ambiente denominata con il valore -javaagent:/home/site/wwwroot/apm/appdynamics/javaagent.jar -Dappdynamics.agent.applicationName=<app-name><app-name> dove CATALINA_OPTS è il nome servizio app.

Nota

Se si dispone già di una variabile di ambiente per JAVA_OPTS oppure CATALINA_OPTS, aggiungere l'opzione -javaagent:/... alla fine del valore corrente.

Configurare le origini dati

Java SE

Per connettersi alle origini dati nelle applicazioni Spring Boot, è consigliabile creare stringhe di connessione e inserirle nel file application.properties.

Nella sezione "Configurazione" della pagina del Servizio app di Azure, impostare un nome per la stringa, incollare la stringa di connessione JDBC nel campo valore e impostare il tipo su "Personalizzato". Facoltativamente, è possibile impostare questa stringa di connessione come impostazione dello slot.

Questa stringa di connessione è accessibile all'applicazione come variabile di ambiente denominata CUSTOMCONNSTR_<your-string-name>. Ad esempio: CUSTOMCONNSTR_exampledb.
Nel file application.properties, fare riferimento a questa stringa di connessione con il nome della variabile di ambiente. Per questo esempio, si userà il codice seguente.
```
app.datasource.url=${CUSTOMCONNSTR_exampledb}
```

Per altre informazioni, vedere la documentazione di Spring Boot sull'accesso ai dati e sulle configurazioni esterne.

Tomcat

Queste istruzioni si applicano a tutte le connessioni di database. È necessario inserire segnaposto con il nome della classe driver e il file JAR scelti del database. Viene fornita una tabella con i nomi delle classi e i download dei driver per i database più comuni.

Database	Nome della classe del driver	Driver JDBC
PostgreSQL	`org.postgresql.Driver`	Scaricare
MySQL	`com.mysql.jdbc.Driver`	Scaricare (selezionare "Indipendente dalla piattaforma")
SQL Server	`com.microsoft.sqlserver.jdbc.SQLServerDriver`	Scaricare

Per configurare Tomcat per l'uso di Java Database Connectivity (JDBC) o Java Persistence API (JPA), personalizzare prima la variabile di ambiente CATALINA_OPTS letta da Tomcat all'avvio. Impostare questi valori tramite un'impostazione app nel plug-in Maven del servizio app:

<appSettings>
    <property>
        <name>CATALINA_OPTS</name>
        <value>"$CATALINA_OPTS -Ddbuser=${DBUSER} -Ddbpassword=${DBPASSWORD} -DconnURL=${CONNURL}"</value>
    </property>
</appSettings>

In alternativa, impostare le variabili di ambiente nella pagina Configurazione>Impostazioni dell'applicazione nel portale di Azure.

Determinare quindi se l'origine dati deve essere disponibile per un'applicazione o per tutte le applicazioni in esecuzione nel servlet Tomcat.

Origini dati a livello di applicazione

Creare un file context.xml nella directory META-INF/ del progetto. Creare la directory META-INF/ se non esiste.

In context-xml aggiungere un elemento Context per collegare l'origine dati a un indirizzo JNDI. Sostituire il segnaposto driverClassName con il nome della classe del driver indicato nella tabella precedente.

<Context>
    <Resource
        name="jdbc/dbconnection"
        type="javax.sql.DataSource"
        url="${connURL}"
        driverClassName="<insert your driver class name>"
        username="${dbuser}"
        password="${dbpassword}"
    />
</Context>

Aggiornare il file web.xml dell'applicazione per usare l'origine dati nell'applicazione.

<resource-env-ref>
    <resource-env-ref-name>jdbc/dbconnection</resource-env-ref-name>
    <resource-env-ref-type>javax.sql.DataSource</resource-env-ref-type>
</resource-env-ref>

Risorse a livello di server condiviso

Le installazioni tomcat in servizio app in Windows esistono nello spazio condiviso nel piano di servizio app. Non è possibile modificare direttamente un'installazione tomcat per la configurazione a livello di server. Per apportare modifiche alla configurazione a livello di server all'installazione di Tomcat, è necessario copiare Tomcat in una cartella locale, in cui è possibile modificare la configurazione di Tomcat.

Automatizzare la creazione di Tomcat personalizzato all'avvio dell'app

È possibile usare uno script di avvio per eseguire azioni prima dell'avvio di un'app Web. Lo script di avvio per la personalizzazione di Tomcat deve completare i passaggi seguenti:

Controllare se Tomcat è già stato copiato e configurato in locale. In caso affermativo, lo script di avvio può terminare qui.
Copiare Tomcat in locale.
Apportare le modifiche di configurazione necessarie.
Indicare che la configurazione è stata completata correttamente.

Per le app di Windows, creare un file denominato startup.cmd o startup.ps1 nella wwwroot directory . Questo file viene eseguito automaticamente prima dell'avvio del server Tomcat.

Ecco uno script di PowerShell che completa questi passaggi:

    # Check for marker file indicating that config has already been done
    if(Test-Path "$Env:LOCAL_EXPANDED\tomcat\config_done_marker"){
        return 0
    }

    # Delete previous Tomcat directory if it exists
    # In case previous config isn't completed or a new config should be forcefully installed
    if(Test-Path "$Env:LOCAL_EXPANDED\tomcat"){
        Remove-Item "$Env:LOCAL_EXPANDED\tomcat" --recurse
    }

    # Copy Tomcat to local
    # Using the environment variable $AZURE_TOMCAT90_HOME uses the 'default' version of Tomcat
    Copy-Item -Path "$Env:AZURE_TOMCAT90_HOME\*" -Destination "$Env:LOCAL_EXPANDED\tomcat" -Recurse

    # Perform the required customization of Tomcat
    {... customization ...}

    # Mark that the operation was a success
    New-Item -Path "$Env:LOCAL_EXPANDED\tomcat\config_done_marker" -ItemType File

Trasformazioni

Un caso d'uso comune per personalizzare una versione di Tomcat consiste nel modificare i server.xmlfile di configurazione , context.xmlo web.xml Tomcat. servizio app già modifica questi file per fornire funzionalità della piattaforma. Per continuare a usare queste funzionalità, è importante conservare il contenuto di questi file quando si apportano modifiche. A tale scopo, è consigliabile usare una trasformazione XSL (XSLT). Utilizzare una trasformazione XSL per apportare modifiche ai file XML mantenendo il contenuto originale del file.

File XSLT di esempio

In questa trasformazione di esempio viene aggiunto un nuovo nodo connettore a server.xml. Prendere nota di Identity Transform, che mantiene il contenuto originale del file.

    <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:output method="xml" indent="yes"/>

    <!-- Identity transform: this ensures that the original contents of the file are included in the new file -->
    <!-- Ensure that your transform files include this block -->
    <xsl:template match="@* | node()" name="Copy">
      <xsl:copy>
        <xsl:apply-templates select="@* | node()"/>
      </xsl:copy>
    </xsl:template>

    <xsl:template match="@* | node()" mode="insertConnector">
      <xsl:call-template name="Copy" />
    </xsl:template>

    <xsl:template match="comment()[not(../Connector[@scheme = 'https']) and
                                   contains(., '&lt;Connector') and
                                   (contains(., 'scheme=&quot;https&quot;') or
                                    contains(., &quot;scheme='https'&quot;))]">
      <xsl:value-of select="." disable-output-escaping="yes" />
    </xsl:template>

    <xsl:template match="Service[not(Connector[@scheme = 'https'] or
                                     comment()[contains(., '&lt;Connector') and
                                               (contains(., 'scheme=&quot;https&quot;') or
                                                contains(., &quot;scheme='https'&quot;))]
                                    )]
                        ">
      <xsl:copy>
        <xsl:apply-templates select="@* | node()" mode="insertConnector" />
      </xsl:copy>
    </xsl:template>

    <!-- Add the new connector after the last existing Connnector if there's one -->
    <xsl:template match="Connector[last()]" mode="insertConnector">
      <xsl:call-template name="Copy" />

      <xsl:call-template name="AddConnector" />
    </xsl:template>

    <!-- ... or before the first Engine if there's no existing Connector -->
    <xsl:template match="Engine[1][not(preceding-sibling::Connector)]"
                  mode="insertConnector">
      <xsl:call-template name="AddConnector" />

      <xsl:call-template name="Copy" />
    </xsl:template>

    <xsl:template name="AddConnector">
      <!-- Add new line -->
      <xsl:text>&#xa;</xsl:text>
      <!-- This is the new connector -->
      <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" 
                 maxThreads="150" scheme="https" secure="true" 
                 keystoreFile="${{user.home}}/.keystore" keystorePass="changeit"
                 clientAuth="false" sslProtocol="TLS" />
    </xsl:template>

    </xsl:stylesheet>

Funzione per la trasformazione XSL

PowerShell include strumenti predefiniti per trasformare i file XML usando trasformazioni XSL. Lo script seguente è una funzione di esempio che è possibile usare in startup.ps1 per eseguire la trasformazione:

    function TransformXML{
        param ($xml, $xsl, $output)

        if (-not $xml -or -not $xsl -or -not $output)
        {
            return 0
        }

        Try
        {
            $xslt_settings = New-Object System.Xml.Xsl.XsltSettings;
            $XmlUrlResolver = New-Object System.Xml.XmlUrlResolver;
            $xslt_settings.EnableScript = 1;

            $xslt = New-Object System.Xml.Xsl.XslCompiledTransform;
            $xslt.Load($xsl,$xslt_settings,$XmlUrlResolver);
            $xslt.Transform($xml, $output);

        }

        Catch
        {
            $ErrorMessage = $_.Exception.Message
            $FailedItem = $_.Exception.ItemName
            Write-Host  'Error'$ErrorMessage':'$FailedItem':' $_.Exception;
            return 0
        }
        return 1
    }

Impostazioni app

La piattaforma deve anche sapere dove è installata la versione personalizzata di Tomcat. È possibile impostare il percorso dell'installazione nell'impostazione dell'app CATALINA_BASE .

È possibile usare l'interfaccia della riga di comando di Azure per modificare questa impostazione:

    az webapp config appsettings set -g $MyResourceGroup -n $MyUniqueApp --settings CATALINA_BASE="%LOCAL_EXPANDED%\tomcat"

In alternativa, è possibile modificare manualmente l'impostazione nel portale di Azure:

Passare a Impostazioni> Configurazione delle>impostazioni dell'applicazione.
Selezionare Nuova impostazione applicazione.
Usare questi valori per creare l'impostazione:
1. Nome: CATALINA_BASE
2. Valore: "%LOCAL_EXPANDED%\tomcat"

Esempio di startup.ps1

Lo script di esempio seguente copia un Tomcat personalizzato in una cartella locale, esegue una trasformazione XSL e indica che la trasformazione è stata completata correttamente:

    # Locations of xml and xsl files
    $target_xml="$Env:LOCAL_EXPANDED\tomcat\conf\server.xml"
    $target_xsl="$Env:HOME\site\server.xsl"

    # Define the transform function
    # Useful if transforming multiple files
    function TransformXML{
        param ($xml, $xsl, $output)

        if (-not $xml -or -not $xsl -or -not $output)
        {
            return 0
        }

        Try
        {
            $xslt_settings = New-Object System.Xml.Xsl.XsltSettings;
            $XmlUrlResolver = New-Object System.Xml.XmlUrlResolver;
            $xslt_settings.EnableScript = 1;

            $xslt = New-Object System.Xml.Xsl.XslCompiledTransform;
            $xslt.Load($xsl,$xslt_settings,$XmlUrlResolver);
            $xslt.Transform($xml, $output);
        }

        Catch
        {
            $ErrorMessage = $_.Exception.Message
            $FailedItem = $_.Exception.ItemName
            echo  'Error'$ErrorMessage':'$FailedItem':' $_.Exception;
            return 0
        }
        return 1
    }

    $success = TransformXML -xml $target_xml -xsl $target_xsl -output $target_xml

    # Check for marker file indicating that config has already been done
    if(Test-Path "$Env:LOCAL_EXPANDED\tomcat\config_done_marker"){
        return 0
    }

    # Delete previous Tomcat directory if it exists
    # In case previous config isn't completed or a new config should be forcefully installed
    if(Test-Path "$Env:LOCAL_EXPANDED\tomcat"){
        Remove-Item "$Env:LOCAL_EXPANDED\tomcat" --recurse
    }

    md -Path "$Env:LOCAL_EXPANDED\tomcat"

    # Copy Tomcat to local
    # Using the environment variable $AZURE_TOMCAT90_HOME uses the 'default' version of Tomcat
    Copy-Item -Path "$Env:AZURE_TOMCAT90_HOME\*" "$Env:LOCAL_EXPANDED\tomcat" -Recurse

    # Perform the required customization of Tomcat
    $success = TransformXML -xml $target_xml -xsl $target_xsl -output $target_xml

    # Mark that the operation was a success if successful
    if($success){
        New-Item -Path "$Env:LOCAL_EXPANDED\tomcat\config_done_marker" -ItemType File
    }

Completare la configurazione

Infine, si inserisce il driver JAR nel classpath Tomcat e si riavvia il servizio app. Assicurarsi che i file del driver JDBC siano disponibili per il classloader Tomcat inserendoli nella directory /home/site/lib . In Cloud Shell eseguire az webapp deploy --type=lib per ogni driver JAR:

az webapp deploy --resource-group <group-name> --name <app-name> --src-path <jar-name>.jar --type=lib --target-path <jar-name>.jar

Tomcat

Database	Nome della classe del driver	Driver JDBC
PostgreSQL	`org.postgresql.Driver`	Scaricare
MySQL	`com.mysql.jdbc.Driver`	Scaricare (selezionare "Indipendente dalla piattaforma")
SQL Server	`com.microsoft.sqlserver.jdbc.SQLServerDriver`	Scaricare

<appSettings>
    <property>
        <name>CATALINA_OPTS</name>
        <value>"$CATALINA_OPTS -Ddbuser=${DBUSER} -Ddbpassword=${DBPASSWORD} -DconnURL=${CONNURL}"</value>
    </property>
</appSettings>

In alternativa, impostare le variabili di ambiente nella pagina Configurazione>Impostazioni dell'applicazione nel portale di Azure.

Determinare quindi se l'origine dati deve essere disponibile per un'applicazione o per tutte le applicazioni in esecuzione nel servlet Tomcat.

Origini dati a livello di applicazione

Creare un file context.xml nella directory META-INF/ del progetto. Creare la directory META-INF/ se non esiste.

<Context>
    <Resource
        name="jdbc/dbconnection"
        type="javax.sql.DataSource"
        url="${connURL}"
        driverClassName="<insert your driver class name>"
        username="${dbuser}"
        password="${dbpassword}"
    />
</Context>

Aggiornare il file web.xml dell'applicazione per usare l'origine dati nell'applicazione.

<resource-env-ref>
    <resource-env-ref-name>jdbc/dbconnection</resource-env-ref-name>
    <resource-env-ref-type>javax.sql.DataSource</resource-env-ref-type>
</resource-env-ref>

Risorse a livello di server condiviso

L'aggiunta di un'origine dati condivisa a livello di server richiede di modificare il server.xml di Tomcat. Per prima cosa, caricare uno script di avvio e impostare il percorso dello script in Configuration>Comando di avvio. È possibile caricare lo script di avvio usando FTP.

Lo script di avvio effettuerà una trasformazione xsl sul file server.xml e restituirà il file xml risultante a /usr/local/tomcat/conf/server.xml. Lo script di avvio deve installare libxslt tramite apk. Il file xsl e lo script di avvio possono essere caricati tramite FTP. Di seguito è riportato uno script di avvio di esempio.

# Install libxslt. Also copy the transform file to /home/tomcat/conf/
apk add --update libxslt

# Usage: xsltproc --output output.xml style.xsl input.xml
xsltproc --output /home/tomcat/conf/server.xml /home/tomcat/conf/transform.xsl /usr/local/tomcat/conf/server.xml

Il file XSL di esempio seguente aggiunge un nuovo nodo connettore al server.xml Tomcat.

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="xml" indent="yes"/>

  <xsl:template match="@* | node()" name="Copy">
    <xsl:copy>
      <xsl:apply-templates select="@* | node()"/>
    </xsl:copy>
  </xsl:template>

  <xsl:template match="@* | node()" mode="insertConnector">
    <xsl:call-template name="Copy" />
  </xsl:template>

  <xsl:template match="comment()[not(../Connector[@scheme = 'https']) and
                                 contains(., '&lt;Connector') and
                                 (contains(., 'scheme=&quot;https&quot;') or
                                  contains(., &quot;scheme='https'&quot;))]">
    <xsl:value-of select="." disable-output-escaping="yes" />
  </xsl:template>

  <xsl:template match="Service[not(Connector[@scheme = 'https'] or
                                   comment()[contains(., '&lt;Connector') and
                                             (contains(., 'scheme=&quot;https&quot;') or
                                              contains(., &quot;scheme='https'&quot;))]
                                  )]
                      ">
    <xsl:copy>
      <xsl:apply-templates select="@* | node()" mode="insertConnector" />
    </xsl:copy>
  </xsl:template>

  <!-- Add the new connector after the last existing Connnector if there's one -->
  <xsl:template match="Connector[last()]" mode="insertConnector">
    <xsl:call-template name="Copy" />

    <xsl:call-template name="AddConnector" />
  </xsl:template>

  <!-- ... or before the first Engine if there's no existing Connector -->
  <xsl:template match="Engine[1][not(preceding-sibling::Connector)]"
                mode="insertConnector">
    <xsl:call-template name="AddConnector" />

    <xsl:call-template name="Copy" />
  </xsl:template>

  <xsl:template name="AddConnector">
    <!-- Add new line -->
    <xsl:text>&#xa;</xsl:text>
    <!-- This is the new connector -->
    <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" 
               maxThreads="150" scheme="https" secure="true" 
               keystoreFile="${{user.home}}/.keystore" keystorePass="changeit"
               clientAuth="false" sslProtocol="TLS" />
  </xsl:template>

</xsl:stylesheet>

Completare la configurazione

Infine, inserire i file driver con estensione jar nel classpath Tomcat e riavviare il Servizio app di Azure.

Assicurarsi che i file del driver JDBC siano disponibili per il classloader Tomcat inserendoli nella directory /home/site/lib . In Cloud Shell eseguire az webapp deploy --type=lib per ogni driver JAR:

az webapp deploy --resource-group <group-name> --name <app-name> --src-path <jar-name>.jar --type=lib --path <jar-name>.jar

Se è stata creata un'origine dati a livello di server, riavviare l'applicazione Linux del Servizio app. Tomcat reimposterà CATALINA_BASE su /home/tomcat e userà la configurazione aggiornata.

Origini dati JBoss EAP

Durante la registrazione di un'origine dati con JBoss EAP sono necessari tre passaggi principali: caricamento del driver JDBC, aggiunta del driver JDBC come modulo e registrazione del modulo. servizio app è un servizio di hosting senza stato, quindi i comandi di configurazione per l'aggiunta e la registrazione del modulo dell'origine dati devono essere scriptati e applicati all'avvio del contenitore.

Ottenere il driver JDBC del database.

Creare un file di definizione del modulo XML per il driver JDBC. L'esempio seguente illustra una definizione di modulo per PostgreSQL.

<?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="org.postgres">
    <resources>
    <!-- ***** IMPORTANT : REPLACE THIS PLACEHOLDER *******-->
    <resource-root path="/home/site/deployments/tools/postgresql-42.2.12.jar" />
    </resources>
    <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
    </dependencies>
</module>

Inserire i comandi dell'interfaccia della riga di comando di JBoss in un file denominato jboss-cli-commands.cli. I comandi JBoss devono aggiungere il modulo e registrarlo come origine dati. L'esempio seguente illustra i comandi dell'interfaccia della riga di comando di JBoss per PostgreSQL.

#!/usr/bin/env bash
module add --name=org.postgres --resources=/home/site/deployments/tools/postgresql-42.2.12.jar --module-xml=/home/site/deployments/tools/postgres-module.xml

/subsystem=datasources/jdbc-driver=postgres:add(driver-name="postgres",driver-module-name="org.postgres",driver-class-name=org.postgresql.Driver,driver-xa-datasource-class-name=org.postgresql.xa.PGXADataSource)

data-source add --name=postgresDS --driver-name=postgres --jndi-name=java:jboss/datasources/postgresDS --connection-url=${POSTGRES_CONNECTION_URL,env.POSTGRES_CONNECTION_URL:jdbc:postgresql://db:5432/postgres} --user-name=${POSTGRES_SERVER_ADMIN_FULL_NAME,env.POSTGRES_SERVER_ADMIN_FULL_NAME:postgres} --password=${POSTGRES_SERVER_ADMIN_PASSWORD,env.POSTGRES_SERVER_ADMIN_PASSWORD:example} --use-ccm=true --max-pool-size=5 --blocking-timeout-wait-millis=5000 --enabled=true --driver-class=org.postgresql.Driver --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter --jta=true --use-java-context=true --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker

Creare uno script di avvio che startup_script.sh chiama i comandi dell'interfaccia della riga di comando di JBoss. Nell'esempio seguente viene illustrato come chiamare .jboss-cli-commands.cli Successivamente, si configurerà servizio app per eseguire questo script all'avvio del contenitore.
```
$JBOSS_HOME/bin/jboss-cli.sh --connect --file=/home/site/deployments/tools/jboss-cli-commands.cli
```
Usando un client FTP di propria scelta, caricare il driver JDBC, jboss-cli-commands.cli, startup_script.she la definizione del modulo in /site/deployments/tools/.
Configurare il sito per l'esecuzione startup_script.sh all'avvio del contenitore. Nella portale di Azure passare a Configurazione>generale Impostazioni> Comando di avvio. Impostare il campo del comando di avvio su /home/site/deployments/tools/startup_script.sh. Selezionare Salva per salvare le modifiche.

Per verificare che l'origine dati sia stata aggiunta al server JBoss, eseguire SSH nell'app Web ed eseguire $JBOSS_HOME/bin/jboss-cli.sh --connect. Dopo aver eseguito la connessione a JBoss, eseguire /subsystem=datasources:read-resource per stampare un elenco delle origini dati.

robots933456 nei log

È possibile che nei log del contenitore venga visualizzato il messaggio seguente:

2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"

Questo messaggio può tranquillamente essere ignorato. /robots933456.txt è un percorso URL fittizio usato dal servizio app per verificare se il contenitore è in grado di gestire le richieste. Una risposta 404 indica semplicemente che il percorso non esiste, ma consente al servizio app di capire che il contenitore è integro e pronto per rispondere alle richieste.

Scelta di una versione di runtime Java

servizio app consente agli utenti di scegliere la versione principale della JVM, ad esempio Java 8 o Java 11, e la versione patch, ad esempio 1.8.0_232 o 11.0.5. È anche possibile scegliere di aggiornare automaticamente la versione della patch man mano che diventano disponibili nuove versioni secondarie. Nella maggior parte dei casi, le app di produzione devono usare versioni JVM patch aggiunte. In questo modo si evitano interruzioni impreviste durante l'aggiornamento automatico di una versione patch. Tutte le app Web Java usano JVM a 64 bit e non sono configurabili.

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 aggiunta ma non è configurabile separatamente.

Se si sceglie di aggiungere la versione secondaria, è necessario aggiornare periodicamente la versione secondaria di JVM nell'app. Per assicurarsi che l'applicazione venga eseguita nella versione secondaria più recente, creare uno slot di staging e incrementare la versione secondaria nello slot di staging. Dopo aver verificato che l'applicazione venga eseguita correttamente nella nuova versione secondaria, è possibile scambiare gli slot di gestione temporanea e di produzione.

JBoss EAP

Clustering in JBoss EAP

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. Le istanze di JBoss EAP comunicano sulla subnet specificata nell'integrazione della rete virtuale, usando le porte visualizzate nella variabile di ambiente in WEBSITES_PRIVATE_PORTS fase di esecuzione. È possibile disabilitare il clustering creando un'impostazione dell'app denominata WEBSITE_DISABLE_CLUSTERING con qualsiasi valore.

Nota

Se si abilita l'integrazione della rete virtuale con un modello di Resource Manager, è necessario impostare manualmente la proprietà vnetPrivatePorts su un valore di 2. Se si abilita l'integrazione della rete virtuale dall'interfaccia della riga di comando o dal portale, questa proprietà viene impostata automaticamente.

Quando il clustering è abilitato, le istanze JBoss EAP usano il protocollo di individuazione FILE_PING JGroups per individuare nuove istanze e rendere persistenti le informazioni del cluster, ad esempio i membri del cluster, i relativi identificatori e i relativi indirizzi IP. In 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 il nodo da includere nel cluster e aggiunte al file.

I tipi di piano Premium V3 e Isolated V2 servizio app possono essere distribuiti facoltativamente tra 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: "Riduci conteggio per"
Raffreddamento: "5 minuti" o superiore
Numero di istanze: 1

Non è necessario aggiungere istanze in modo incrementale (aumento del numero di istanze), è possibile aggiungere più istanze al cluster alla volta.

Piani di servizio app JBoss EAP

JBoss EAP è disponibile solo nei tipi premium v3 e Isolated v2 servizio app Plan. I clienti che hanno creato un sito JBoss EAP in un livello diverso durante l'anteprima pubblica devono aumentare fino al livello hardware Premium o Isolato per evitare comportamenti imprevisti.

Configurazione della linea di base Tomcat in servizio app

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: comprendendo i dettagli di configurazione di server.xml e 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. Sono inclusi 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. Comprendendo i dettagli di configurazione del file di server.xml e 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. Comprendere questi dettagli è essenziale per distribuire correttamente le applicazioni e garantire 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.

Esistono inoltre alcune trasformazioni che vengono ulteriormente applicate al server.xml per la distribuzione Tomcat all'avvio. Si tratta di trasformazioni per le impostazioni di Connessione or, host e valvola.

Si noti che 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.

Connector

<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
conectionTimeout è 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

Nota

Le impostazioni connectionTimeout, maxThreads e max Connessione ions possono essere ottimizzate con le impostazioni dell'app

Di seguito sono riportati i comandi dell'interfaccia della riga di comando di esempio che è possibile usare per modificare i valori di conectionTimeout, maxThreads o max Connessione ions:

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

Connessione or usa l'indirizzo del contenitore anziché 127.0.0.1

Host

<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, per impostazione predefinita TMP
errorReportValveClass usa la valvola di segnalazione degli errori personalizzata

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
maxDaysWEBSITE_HTTPLOGGING_RETENTION_DAYSè , che per impostazione predefinita è 0 [forever]

In Linux include tutte le stesse personalizzazioni, oltre a:

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>

Passaggi successivi

Per trovare guide introduttive di Azure, esercitazioni e documentazione di riferimento su Java, visitare la pagina Azure per sviluppatori Java.

Configurare un'app Java per Servizio app di Azure

Visualizzare la versione java

Distribuzione dell'app

Build Tools

Maven

Gradle

IDE

Kudu API

Java SE

Tomcat

JBoss EAP

Registrazione e debug delle app

Eseguire lo streaming dei log di diagnostica

Accesso alla console SSH

Strumenti per la risoluzione dei problemi

Java Profiler

Flight Recorder

Registrazione temporizzata

Registrazione continua

Analizzare i .jfr file

Registrazione dell'app

Personalizzazione e ottimizzazione

Copiare il contenuto dell'app in locale

Impostare le opzioni di runtime Java

Attivare i Web Socket

Impostare la codifica dei caratteri predefinita

Pre-compilare i file JSP

Proteggere le applicazioni

Autenticare gli utenti (Easy Auth)

Java SE

Tomcat

Configurare TLS/SSL

Usare i riferimenti di KeyVault

Usare l'archivio chiavi Java

Inizializzare l'archivio chiavi Java

Caricare manualmente l'archivio chiavi

Configurare le piattaforme APM

Configurare Application Insights

Azure portal

Interfaccia della riga di comando di Azure

Configurare New Relic

Configurare AppDynamics

Configurare le origini dati

Java SE

Tomcat

Origini dati a livello di applicazione

Risorse a livello di server condiviso

Automatizzare la creazione di Tomcat personalizzato all'avvio dell'app

Trasformazioni

File XSLT di esempio

Funzione per la trasformazione XSL

Impostazioni app

Esempio di startup.ps1

Completare la configurazione

Tomcat

Origini dati a livello di applicazione

Risorse a livello di server condiviso

Completare la configurazione

Origini dati JBoss EAP

robots933456 nei log

Scelta di una versione di runtime Java

JBoss EAP

Clustering in JBoss EAP

Regole di scalabilità automatica

Piani di servizio app JBoss EAP

Configurazione della linea di base Tomcat in servizio app

Connector

Host

Valvola

Passaggi successivi

Risorse aggiuntive

Analizzare i `.jfr` file