Configurare le origini dati per un'app Tomcat, JBoss o Java SE nel servizio app di Azure

Questo articolo illustra come configurare le origini dati in un'app Java SE, Tomcat o JBoss nel servizio app.

Il servizio app di Azure esegue applicazioni Web Java in un servizio completamente gestito in tre varianti:

  • Java SE: può eseguire un'app distribuita come pacchetto JAR che contiene un server incorporato (ad esempio Spring Boot, Dropwizard, Quarkus o uno con un server Tomcat o Jetty incorporato).
  • Tomcat: il server Tomcat predefinito può eseguire un'app distribuita come pacchetto WAR.
  • JBoss EAP: supportato per le app Linux solo nei piani tariffari Gratuito, Premium v3 e Isolato v2. Il server JBoss EAP predefinito può eseguire un'app distribuita come pacchetto WAR o EAR.

Nota

Per le applicazioni Spring, è consigliabile usare Azure Spring Apps. Tuttavia, è comunque possibile usare il Servizio app di Azure come destinazione. Per consigli, vedere Indicazioni sulla destinazione del carico di lavoro Java.

Configurare l'origine dati

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

  1. 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.

  2. 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 Spring Boot sull'accesso ai dati e configurazioni esterne.

Suggerimento

Per impostazione predefinita, i contenitori Tomcat Linux possono configurare automaticamente le origini dati condivise nel server Tomcat. L'unica cosa da fare è aggiungere un'impostazione dell'app che contiene un stringa di connessione JDBC valido a un database Oracle, SQL Server, PostgreSQL o MySQL (incluse le credenziali di connessione) e servizio app aggiunge automaticamente il database condiviso corrispondente a /usr/local/tomcat/conf/context.xml, usando un driver appropriato disponibile nel contenitore. Per uno scenario end-to-end con questo approccio, vedere Esercitazione: Creare un'app Web Tomcat con il servizio app di Azure in Linux e MySQL.

Queste istruzioni si applicano a tutte le connessioni di database. È necessario sostituire i segnaposto con il nome della classe del driver del database scelto e il file JAR. 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

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

  2. 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>
    
  3. 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. Il modo più affidabile per eseguire questa operazione è il seguente:

  1. Per prima cosa, caricare uno script di avvio e impostare il percorso dello script in Configurazione>Comando di avvio. È possibile caricare lo script di avvio usando FTP.

Lo script di avvio crea una trasformazione xsl nel file server.xml e restituisce il file XML risultante in /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.

  1. Assicurarsi che i file driver JDBC siano disponibili per il caricatore di classe Tomcat inserendoli nella directory /home/site/lib. In Cloud Shell eseguire az webapp deploy --type=lib per ogni file JAR del driver:
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 reimposta CATALINA_BASE su /home/tomcat e usa la configurazione aggiornata.

Suggerimento

Per impostazione predefinita, i contenitori JBoss Linux possono configurare automaticamente le origini dati condivise nel server JBoss. L'unica cosa da fare è aggiungere un'impostazione dell'app che contiene un stringa di connessione JDBC valido a un database Oracle, SQL Server, PostgreSQL o MySQL (incluse le credenziali di connessione) e servizio app aggiunge automaticamente l'origine dati condivisa corrispondente, usando un driver appropriato disponibile nel contenitore. Per uno scenario end-to-end con questo approccio, vedere Esercitazione: Creare un'app Web JBoss con il servizio app Azure in Linux e MySQL.

La registrazione di un'origine dati con JBoss EAP prevede tre passaggi principali:

  1. Caricare il driver JDBC.
  2. Aggiungere il driver JDBC come modulo.
  3. Aggiungere un'origine dati con il modulo .

servizio app è un servizio di hosting senza stato, pertanto è necessario inserire questi passaggi in uno script di avvio ed eseguirlo ogni volta che viene avviato il contenitore JBoss. Uso di PostgreSQL, MySQL e database SQL come esempio:

  1. 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 la creazione di un'origine dati PostgreSQL con il nome java:jboss/datasources/postgresDSJNDI .

    module add --name=org.postgresql --resources=/home/site/libs/postgresql-42.7.4.jar
    /subsystem=datasources/jdbc-driver=postgresql:add(driver-name="postgresql",driver-module-name="org.postgresql",driver-class-name="org.postgresql.Driver",driver-xa-datasource-class-name="org.postgresql.xa.PGXADataSource")
    data-source add --name=postgresql --driver-name="postgresql" --jndi-name="java:jboss/datasources/postgresDS" --connection-url="jdbc:postgresql://\${env.DB_HOST}:5432/postgres" --user-name="\${env.DB_USERNAME}" --password="\${env.DB_PASSWORD}" --enabled=true --use-java-context=true
    

    Si noti che il module add comando usa tre variabili di ambiente (DB_HOST, DB_USERNAMEe DB_PASSWORD), che è necessario aggiungere in servizio app come impostazioni dell'app. Lo script li aggiunge senza il --resolve-parameter-values flag in modo che JBoss non salvi i valori in testo non crittografato.

  2. Creare uno script di avvio, startup.sh, che 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à il servizio app per eseguire questo script all'avvio del contenitore.

    $JBOSS_HOME/bin/jboss-cli.sh --connect --file=/home/site/scripts/jboss_cli_commands.cli
    
  3. Usando un'opzione di distribuzione di propria scelta, caricare il driver JDBC, jboss-cli-commands.cli e startup.sh nei percorsi specificati nei rispettivi script. In particolare, caricare startup.sh come file di avvio. Ad esempio:

    export RESOURCE_GROUP_NAME=<resource-group-name>
    export APP_NAME=<app-name>
    
    # The lib type uploads to /home/site/libs by default.
    az webapp deploy --resource-group $RESOURCE_GROUP_NAME --name $APP_NAME --src-path postgresql-42.7.4.jar --target-path postgresql-42.7.4.jar --type lib
    az webapp deploy --resource-group $RESOURCE_GROUP_NAME --name $APP_NAME --src-path jboss_cli_commands.cli --target-path /home/site/scripts/jboss_cli_commands.cli --type static
    # The startup type uploads to /home/site/scripts/startup.sh by default.
    az webapp deploy --resource-group $RESOURCE_GROUP_NAME --name $APP_NAME --src-path startup.sh --type startup
    

    Per altre informazioni, vedere Distribuire file in servizio app.

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 il /subsystem=datasources:read-resource per stampare un elenco delle origini dati.

Come definito in precedenza da jboss-cli-commands.cli , è possibile accedere alla connessione PostgreSQL usando il nome java:jboss/datasources/postgresDSJNDI .

Passaggi successivi

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