Configuración de orígenes de datos para una aplicación Tomcat, JBoss o Java SE en Azure App Service

En este artículo se muestra cómo configurar orígenes de datos en una aplicación Java SE, Tomcat o JBoss en App Service.

Azure App Service ejecuta aplicaciones web de Java en tres tipos en un servicio totalmente administrado:

Java Standard Edition (SE). Java SE puede ejecutar una aplicación implementada como un paquete de archivo java (JAR) que contiene un servidor incrustado, como Spring Boot, Quarkus, Dropwizard o una aplicación con un servidor de Tomcat o Jetty incrustado.
Tomcat. El servidor tomcat integrado puede ejecutar una aplicación implementada como un paquete de archivo de aplicaciones web (WAR).
JBoss Enterprise Application Platform (EAP): el servidor JBoss EAP integrado puede ejecutar una aplicación implementada como un paquete war o enterprise archive (EAR). Esta opción es compatible con las aplicaciones de Linux en un conjunto de planes de tarifa que incluyen Gratis, Premium v3 y Aislado v2.

Nota:

App Service ahora admite la facturación BYOL (Bring Your Own License) para JBoss EAP. BYOL permite a los clientes que tienen suscripciones de Red Hat existentes aplicar esas licencias directamente a sus implementaciones de JBoss EAP en Azure App Service. Para más información, consulte Compatibilidad de BYOL con JBoss EAP en App Service.

Configuración del origen de datos

Para conectarse a orígenes de datos en aplicaciones de Spring Boot, se recomienda crear cadenas de conexión e insertarlas en su archivo application.properties.

En el panel izquierdo de la página de App Service, seleccione Configuración>Variables de entorno. En la pestaña Cadenas de conexión , seleccione Agregar. Establezca un nombre para la cadena, pegue la cadena de conexión JDBC en el campo Valor y establezca el tipo en Personalizado. Opcionalmente, puede establecer la cadena de conexión como una configuración de ranura.

La cadena de conexión es accesible para la aplicación como una variable de entorno denominada CUSTOMCONNSTR_<your-string-name>. Por ejemplo, CUSTOMCONNSTR_exampledb.
En el archivo application.properties , haga referencia a la cadena de conexión con el nombre de la variable de entorno. En el ejemplo anterior, usaría este código:
```
app.datasource.url=${CUSTOMCONNSTR_exampledb}
```

Para obtener más información, consulte la documentación de Spring Boot sobre el acceso a datos y la configuración externa.

Sugerencia

Los contenedores de Tomcat de Linux pueden configurar automáticamente fuentes de datos compartidas en el servidor de Tomcat si se establece la variable de entorno de WEBSITE_AUTOCONFIGURE_DATABASE a true. Lo único que debe hacer es agregar una configuración de aplicación que contenga una cadena de conexión JDBC válida a una base de datos Oracle, SQL Server, PostgreSQL o MySQL (incluidas las credenciales de conexión). App Service agrega automáticamente la base de datos compartida correspondiente a /usr/local/tomcat/conf/context.xml, mediante un controlador adecuado que esté disponible en el contenedor. Para ver un escenario de un extremo a otro que use este enfoque, consulte Tutorial: Compilación de una aplicación web de Tomcat con Azure App Service en Linux y MySQL.

Estas instrucciones se aplican a todas las conexiones de base de datos. Debe reemplazar los marcadores de posición por el nombre de la clase de controlador de la base de datos elegida y el archivo JAR. En la tabla siguiente se proporcionan nombres de clase y descargas de controladores para bases de datos comunes.

Base de datos	Nombre de clase de controlador	Controlador JDBC
PostgreSQL	`org.postgresql.Driver`	Descargar
MySQL (en inglés)	`com.mysql.jdbc.Driver`	Descargar (seleccione Independiente de la plataforma).
Servidor SQL	`com.microsoft.sqlserver.jdbc.SQLServerDriver`	Descargar

Para configurar Tomcat para que use la conectividad de base de datos Java (JDBC) o la API de Persistencia Java (JPA), personalice primero la variable de entorno CATALINA_OPTS que lee Tomcat durante el inicio. Establezca este valor mediante una configuración de aplicación en el complemento Maven de App Service:

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

O bien, establezca la variable de entorno en la pestaña Configuración de la aplicación de la página Variables deentorno de > en Azure Portal.

A continuación, determine si el origen de datos debe estar disponible para una aplicación o para todas las aplicaciones que se ejecutan en el servlet de Tomcat.

Orígenes de datos de nivel de aplicación

Para configurar un origen de datos de nivel de aplicación:

Cree un archivo context.xml en el directorio META-INF / del proyecto. Si el directorio META-INF/ no existe, créelo.

En , context.xml, agregue un elemento Context para vincular el origen de datos a una dirección JNDI. Reemplaza el marcador de posición driverClassName con el nombre de la clase del controlador de la tabla que aparece anteriormente en este artículo.

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

Actualice el archivo web.xml de la aplicación para que use el origen de datos de su aplicación.

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

Recursos de nivel de servidor compartidos

Linux
Windows

Sugerencia

Los contenedores de Tomcat de Linux pueden aplicar automáticamente archivos XSLT mediante la siguiente convención para los archivos copiados en /home/site/wwwroot: Si server.xml.xsl o server.xml.xslt está presente, los archivos se aplican a la colección de server.xmlTomcat. Si context.xml.xsl o context.xml.xslt están presentes, los archivos se aplican al directorio de Tomcat context.xml.

Para agregar un origen de datos compartido de nivel de servidor, es necesario editar el server.xmlarchivo de Tomcat. Dado que los cambios de archivo fuera del /home directorio son efímeros, los cambios en los archivos de configuración de Tomcat deben aplicarse mediante programación, como se indica a continuación:

Cargue un script de inicio y establezca la ruta de acceso al script en Configuración>. En la pestaña Stack settings, agregue la ruta de acceso en el cuadro Comando de inicio. Puede cargar el script de inicio mediante FTP.

El script de inicio realiza una transformación XSL en el server.xml archivo y genera el archivo XML resultante en /usr/local/tomcat/conf/server.xml. El script de inicio debe instalar libxslt o xlstproc, en función de la distribución de la versión de Tomcat para la aplicación web, según se indica en el comentario del siguiente script de ejemplo. Puede usar FTP para cargar el archivo XSL y el script de inicio.

# Install the libxslt package on Alpine-based images:
apk add --update libxslt

# Install the xsltproc package on Debian or Ubuntu-based images:
apt install xsltproc

# Also copy the transform file to /home/tomcat/conf/
# 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

El siguiente archivo XSL agrega un nuevo nodo de conector al archivo server.xml de 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 connector if there is 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>

Finalización de la configuración

Por último, coloque los JAR del controlador en la ruta de clases de Tomcat y reinicie la aplicación de App Service.

Asegúrese de que los archivos del controlador JDBC estén disponibles para el cargador de clases de Tomcat. Para ello, colóquelos en el directorio /home/site/lib. En Cloud Shell, ejecute az webapp deploy --type=lib para cada archivo JAR del controlador:

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

Si ha creado un origen de datos de nivel de servidor, reinicie la aplicación App Service de Linux. Tomcat restablece CATALINA_BASE a /home/tomcat y usa la configuración actualizada.

No puede modificar directamente una instalación de Tomcat para la configuración de todo el servidor porque la ubicación de instalación es de solo lectura. La manera más fácil de realizar cambios de configuración de nivel de servidor en la instalación de Windows Tomcat es completar los pasos siguientes en el inicio de la aplicación:

Copie Tomcat en un directorio local (%LOCAL_EXPANDED%) y use esa copia como CATALINA_BASE. (Consulte la documentación de Tomcat sobre esta variable).
Agregue los orígenes de datos compartidos a %LOCAL_EXPANDED%\tomcat\conf\server.xml mediante la transformación XSL.

Adición de un archivo de inicio

Cree un archivo denominado startup.cmd en el directorio %HOME%\site\wwwroot. Se ejecutará automáticamente antes de que se inicie el servidor de Tomcat. El archivo debe contener esto:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -File  %HOME%\site\configure.ps1 > %HOME%\site\configure.log

Añada el script de configuración de PowerShell

A continuación, agregue un script de configuración llamado configure.ps1 al %HOME%\site directorio . El script contiene este código:

# Locations of XML and XSL files
$source_xml = "$Env:AZURE_TOMCAT90_HOME\conf\server.xml"
$target_xml = "$Env:LOCAL_EXPANDED\tomcat\conf\server.xml"
$target_xsl = "$Env:HOME\site\server.xsl"
$marker_file = "$Env:HOME\site\config_done_marker"

# 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
        Write-Error 'Error'$ErrorMessage':'$FailedItem':' $_.Exception;
        return 0
    }
    return 1
}

# Start here

# Check for marker file indicating that configuration has already been done
if (Test-Path "$marker_file") {
    return 0
}

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

# Copy Tomcat to local
# When you use the environment variable $AZURE_TOMCAT90_HOME, the 'default' version of Tomcat is used
New-Item "$Env:LOCAL_EXPANDED\tomcat" -ItemType Directory
Copy-Item -Path "$Env:AZURE_TOMCAT90_HOME\*" "$Env:LOCAL_EXPANDED\tomcat" -Recurse

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

# Mark that the operation succeeded if it did
if ($success) {
    New-Item -Path "$marker_file" -ItemType File
}

Este PowerShell completa los pasos siguientes:

Compruebe si existe una copia personalizada de Tomcat. Si existe algún script de inicio, este puede detenerse.
Copie Tomcat localmente.
Agregue orígenes de datos compartidos a la configuración personalizada de Tomcat mediante la transformación XSL.
Indique que la configuración se completó correctamente.

Adición de un archivo de transformación XSL

Un caso de uso común para personalizar la instalación integrada de Tomcat es modificar los archivos de configuración de Tomcat server.xml, context.xml o web.xml. App Service ya modifica estos archivos para proporcionar características de la plataforma. Para seguir usando estas características, debe conservar el contenido de estos archivos al realizar cambios en ellos. Para conservar este contenido, use una transformación XSL (XSLT).

Agregue un archivo de transformación XSL denominado server.xsl al directorio _\site de%HOME% . Puede usar el siguiente código de transformación XSL para agregar un nuevo nodo de conector a server.xml. La transformación de identidad al principio conserva el contenido original del archivo de configuración.

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

    <!-- Identity transform: this transform 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 connector if there is 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>

Establecer la configuración de la `CATALINA_BASE` aplicación

La plataforma también debe saber dónde está instalada la versión personalizada de Tomcat. Puede establecer la ubicación de la instalación en los ajustes CATALINA_BASE de la aplicación.

Puede usar la CLI de Azure para cambiar este valor:

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

Como alternativa, puede cambiar manualmente la configuración en Azure Portal:

Vaya a Configuración>Variables de entorno>Configuración de la aplicación.
Selecciona Agregar.
Use estos valores para crear la configuración:
1. Nombre: CATALINA_BASE
2. Valor: "%LOCAL_EXPANDED%\tomcat"

Finalización de la configuración

Por último, coloque los archivos JAR del controlador en la classpath de Tomcat y reinicie App Service. Asegúrese de que los archivos del controlador JDBC estén disponibles para el cargador de clases de Tomcat. Para ello, colóquelos en el directorio /home/site/lib. En Cloud Shell, ejecute az webapp deploy --type=lib para cada archivo JAR del controlador:

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

Sugerencia

De forma predeterminada, los contenedores de JBoss de Linux pueden configurar automáticamente orígenes de datos compartidos en el servidor JBoss. Lo único que debe hacer es agregar una configuración de aplicación que contenga una cadena de conexión JDBC válida a una base de datos Oracle, SQL Server, PostgreSQL o MySQL (incluidas las credenciales de conexión) y agregue la configuración de la aplicación o la variable WEBSITE_AUTOCONFIGURE_DATABASE de entorno con el valor true. También se admiten las conexiones JDBC creadas con el conector de servicio. App Service agrega automáticamente el origen de datos compartido correspondiente (basado en el nombre de la configuración de la aplicación y el sufijo _DS), mediante un controlador adecuado disponible en el contenedor. Para ver un escenario completo que use este enfoque, consulte Tutorial: Compilación de una aplicación web de JBoss con Azure App Service en Linux y MySQL.

Hay tres pasos principales para registrar un origen de datos con JBoss EAP:

Cargue el controlador JDBC.
Agregue el controlador JDBC como módulo.
Agregue un origen de datos con el módulo.

App Service es un servicio de hospedaje sin estado, por lo que debe colocar estos pasos en un script de inicio y ejecutarlo cada vez que se inicia el contenedor de JBoss. Estos son los ejemplos de PostgreSQL, MySQL y Azure SQL Database:

Nota:

JBoss EAP en App Service admite la facturación Trae tu propia licencia (BYOL). BYOL permite a los clientes que tienen suscripciones de Red Hat existentes aplicar esas licencias directamente a sus implementaciones de JBoss EAP en Azure App Service. Para obtener más información, consulte Compatibilidad de BYOL con JBoss EAP.

Coloque los comandos de la CLI de JBoss en un archivo denominado jboss-cli-commands.cli. Los comandos de JBoss deben agregar el módulo y registrarlo como un origen de datos. En el ejemplo siguiente se muestran los comandos de la CLI de JBoss para crear un origen de datos postgreSQL con el nombre JNDI java:jboss/datasources/postgresDS.
```
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
```
Tenga en cuenta que el comando module add usa tres variables de entorno (DB_HOST, DB_USERNAME y DB_PASSWORD), que debe agregar en App Service como configuración de la aplicación. El script los agrega sin la marca --resolve-parameter-values para que JBoss no guarde sus valores en texto no cifrado.
Cree un script de inicio, startup.sh, que llame a los comandos de la CLI de JBoss. En el ejemplo siguiente se muestra cómo llamar al archivo jboss-cli-commands.cli . Más adelante, configurará App Service para ejecutar este script cuando se inicie el contenedor.
```
$JBOSS_HOME/bin/jboss-cli.sh --connect --file=/home/site/scripts/jboss-cli-commands.cli
```

Usando una opción de implementación de su elección, cargue el controlador JDBC, jboss-cli-commands.cli, y startup.sh a las rutas de acceso especificadas en los scripts respectivos. Cargue startup.sh como un archivo de inicio. Por ejemplo:

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

Para obtener más información, vea Implementación de archivos en App Service.

<deployment>
    <resources>
        <resource>
            <!-- The lib type uploads to /home/site/libs by default. -->
            <type>lib</type>
            <directory>${project.build.directory}/${project.artifactId}/META-INF/lib</directory> <!-- Assume driver is part of POM dependencies. -->
            <includes>
                <include>postgresql-42.7.4.jar</include>
            </includes>
        </resource>
        <resource>
            <!-- The script type uploads to /home/site/scripts by default. -->
            <type>script</type>
            <directory>${project.scriptSourceDirectory}</directory> <!-- Assume script is in src/main/scripts. -->
            <includes>
                <include>jboss-cli-commands.cli</include>
            </includes>
        </resource>
        <resource>
            <!-- The startup type uploads to /home/site/scripts by default. -->
            <type>startup</type>
            <directory>${project.scriptSourceDirectory}</directory> <!-- Assume script is in src/main/scripts. -->
            <includes>
                <include>startup.sh</include>
            </includes>
        </resource>
        ...
    </resources>
</deployment>

variables: # Set <subscription-id>, <resource-group-name>, and <app-name> for your environment
- name: SUBSCRIPTION_ID
  value: <subscription-id>
- name: RESOURCE_GROUP_NAME
  value: <resource-group-name>
- name: APP_NAME
  value: <app-name>

steps: 
- task: AzureCLI@2
  displayName: Azure CLI
  inputs:
    azureSubscription: $(SUBSCRIPTION_ID)
    scriptType: bash
    scriptLocation: inlineScript
    inlineScript: |
      # 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

Para confirmar que el origen de datos se ha agregado al servidor JBoss, acceda mediante SSH a su aplicación web y ejecute $JBOSS_HOME/bin/jboss-cli.sh --connect. Después de conectarse a JBoss, ejecute /subsystem=datasources:read-resource para imprimir una lista de los orígenes de datos.

Según la definición de jboss-cli-commands.cli, puede acceder a la conexión de PostgreSQL mediante el nombre JNDI java:jboss/datasources/postgresDS.

Nota:

JBoss EAP en App Service admite la facturación Bring Your Own License (BYOL). BYOL permite a los clientes que tienen suscripciones de Red Hat existentes aplicar esas licencias directamente a sus implementaciones de JBoss EAP en Azure App Service. Para más información, consulte Compatibilidad de BYOL con JBoss EAP en Azure App Service.

Coloque los comandos de la CLI de JBoss en un archivo denominado jboss-cli-commands.cli. Los comandos de JBoss deben agregar el módulo y registrarlo como un origen de datos. En el ejemplo siguiente se muestran los comandos de la CLI de JBoss para crear un origen de datos MySQL con el nombre JNDI java:jboss/datasources/mysqlDS.
```
module add --name=com.mysql.mysql-connector-j --resources=/home/site/libs/mysql-connector-j-9.1.0.jar
/subsystem=datasources/jdbc-driver=mysql:add(driver-name="mysql",driver-module-name="com.mysql.mysql-connector-j",driver-class-name="com.mysql.cj.jdbc.Driver",driver-xa-datasource-class-name="com.mysql.cj.jdbc.MysqlXADataSource")
data-source add --name=mysql --driver-name="mysql" --jndi-name="java:jboss/datasources/mysqlDS" --connection-url="jdbc:mysql://\${env.DB_HOST}:5432/mysql?serverTimezone=UTC" --user-name="\${env.DB_USERNAME}" --password="\${env.DB_PASSWORD}" --enabled=true --use-java-context=true
```
Tenga en cuenta que el comando module add usa tres variables de entorno (DB_HOST, DB_USERNAME y DB_PASSWORD), que debe agregar en App Service como configuración de la aplicación. El script los agrega sin la marca --resolve-parameter-values para que JBoss no guarde sus valores en texto no cifrado.
Cree un script de inicio, startup.sh, que llame a los comandos de la CLI de JBoss. En el ejemplo siguiente se muestra cómo llamar al archivo jboss-cli-commands.cli . Más adelante, configurará App Service para ejecutar este script cuando se inicie el contenedor.
```
$JBOSS_HOME/bin/jboss-cli.sh --connect --file=/home/site/scripts/jboss-cli-commands.cli
```

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 mysql-connector-j-9.1.0.jar --target-path mysql-connector-j-9.1.0.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

Para obtener más información, vea Implementación de archivos en App Service.

<deployment>
    <resources>
        <resource>
            <!-- The lib type uploads to /home/site/libs by default. -->
            <type>lib</type>
            <directory>${project.build.directory}/${project.artifactId}/META-INF/lib</directory> <!-- Assume driver is part of POM dependencies. -->
            <includes>
                <include>mysql-connector-j-9.1.0.jar</include>
            </includes>
        </resource>
        <resource>
            <!-- The script type uploads to /home/site/scripts by default. -->
            <type>script</type>
            <directory>${project.scriptSourceDirectory}</directory> <!-- Assume script is in src/main/scripts. -->
            <includes>
                <include>jboss-cli-commands.cli</include>
            </includes>
        </resource>
        <resource>
            <!-- The startup type uploads to /home/site/scripts/startup.sh by default -->
            <type>startup</type>
            <directory>${project.scriptSourceDirectory}</directory> <!-- Assume script is in src/main/scripts. -->
            <includes>
                <include>startup.sh</include>
            </includes>
        </resource>
        ...
    </resources>
</deployment>

variables: # Set <subscription-id>, <resource-group-name>, <app-name> for your environment
- name: SUBSCRIPTION_ID
  value: <subscription-id>
- name: RESOURCE_GROUP_NAME
  value: <resource-group-name>
- name: APP_NAME
  value: <app-name>

steps: 
- task: AzureCLI@2
  displayName: Azure CLI
  inputs:
    azureSubscription: $(SUBSCRIPTION_ID)
    scriptType: bash
    scriptLocation: inlineScript
    inlineScript: |
      # The lib type uploads to /home/site/libs by default.
      az webapp deploy --resource-group $(RESOURCE_GROUP_NAME) --name $(APP_NAME) --src-path mysql-connector-j-9.1.0.jar --target-path mysql-connector-j-9.1.0.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

Para confirmar que el origen de datos se ha agregado al servidor JBoss, acceda a su aplicación web mediante SSH y ejecute $JBOSS_HOME/bin/jboss-cli.sh --connect. Después de conectarse a JBoss, ejecute /subsystem=datasources:read-resource para imprimir una lista de los orígenes de datos.

Según la definición de jboss-cli-commands.cli, puede acceder a la conexión MySQL usando el nombre JNDI java:jboss/datasources/mysqlDS.

Nota:

JBoss EAP en App Service admite la facturación con el modelo de traer su propia licencia (BYOL). BYOL permite a los clientes con suscripciones de Red Hat existentes aplicar esas licencias directamente a sus implementaciones de JBoss EAP en Azure App Service. Para obtener más información, consulte Compatibilidad de BYOL con JBoss EAP.

Coloque los comandos de la CLI de JBoss en un archivo denominado jboss-cli-commands.cli. Los comandos de JBoss deben agregar el módulo y registrarlo como un origen de datos. En el ejemplo siguiente se muestran los comandos de la CLI de JBoss para crear un origen de datos para una base de datos de Azure SQL con el nombre java:jboss/datasources/sqlDSJNDI .

module add --name=sqlserver --resources=/home/site/libs/mssql-jdbc-11.2.3.jre17.jar
/subsystem=datasources/jdbc-driver=sqlserver:add(driver-name="sqlserver",driver-module-name="sqlserver",driver-class-name="com.microsoft.sqlserver.jdbc.SQLServerDriver",driver-xa-datasource-class-name="com.microsoft.sqlserver.jdbc.SQLServerXADataSource")
data-source add --name=sqlDS --jndi-name=java:jboss/datasources/sqlDS --driver-name=sqlserver --connection-url="jdbc:sqlserver://\${env.DB_HOST}:1433;databaseName=master" --user-name="\${env.DB_USERNAME}" --password="\${env.DB_PASSWORD}" --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLExceptionSorter

Tenga en cuenta que el comando module add usa tres variables de entorno (DB_HOST, DB_USERNAME y DB_PASSWORD), que debe agregar en App Service como configuración de la aplicación. El script los agrega sin la marca --resolve-parameter-values para que JBoss no guarde sus valores en texto no cifrado.

Cree un script de inicio, startup.sh, que llame a los comandos de la CLI de JBoss. En el ejemplo siguiente se muestra cómo llamar al archivo jboss-cli-commands.cli . Más adelante, configurará App Service para ejecutar este script cuando se inicie el contenedor.
```
$JBOSS_HOME/bin/jboss-cli.sh --connect --file=/home/site/scripts/jboss-cli-commands.cli
```

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 mssql-jdbc-11.2.3.jre17.jar --target-path mssql-jdbc-11.2.3.jre17.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

Para obtener más información, vea Implementación de archivos en App Service.

<deployment>
    <resources>
        <resource>
            <!-- The lib type uploads to /home/site/libs by default. -->
            <type>lib</type>
            <directory>${project.build.directory}/${project.artifactId}/META-INF/lib</directory> <!-- Assume driver is part of POM dependencies. -->
            <includes>
                <include>mssql-jdbc-11.2.3.jre17.jar</include>
            </includes>
        </resource>
        <resource>
            <!-- The script type uploads to /home/site/scripts by default. -->
            <type>script</type>
            <directory>${project.scriptSourceDirectory}</directory> <!-- Assume script is in src/main/scripts. -->
            <includes>
                <include>jboss-cli-commands.cli</include>
            </includes>
        </resource>
        <resource>
            <!-- The startup type uploads to /home/site/scripts/startup.sh by default -->
            <type>startup</type>
            <directory>${project.scriptSourceDirectory}</directory> <!-- Assume script is in src/main/scripts. -->
            <includes>
                <include>startup.sh</include>
            </includes>
        </resource>
        ...
    </resources>
</deployment>

variables: # Set <subscription-id>, <resource-group-name>,  and <app-name> for your environment
- name: SUBSCRIPTION_ID
  value: <subscription-id>
- name: RESOURCE_GROUP_NAME
  value: <resource-group-name>
- name: APP_NAME
  value: <app-name>

steps: 
- task: AzureCLI@2
  displayName: Azure CLI
  inputs:
    azureSubscription: $(SUBSCRIPTION_ID)
    scriptType: bash
    scriptLocation: inlineScript
    inlineScript: |
      # The lib type uploads to /home/site/libs by default.
      az webapp deploy --resource-group $(RESOURCE_GROUP_NAME) --name $(APP_NAME) --src-path mssql-jdbc-11.2.3.jre17.jar --target-path mssql-jdbc-11.2.3.jre17.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

Para confirmar que el origen de datos se agregó al servidor JBoss, conéctese a su aplicación web mediante SSH y ejecute $JBOSS_HOME/bin/jboss-cli.sh --connect. Después de conectarse a JBoss, ejecute /subsystem=datasources:read-resource para imprimir una lista de los orígenes de datos.

Según la definición de jboss-cli-commands.cli, puede acceder a la conexión de la base de datos SQL mediante el nombre JNDI java:jboss/datasources/sqlDS.

Comentarios

¿Le resultó útil esta página?

Last updated on 2026-04-24

Configuración de orígenes de datos para una aplicación Tomcat, JBoss o Java SE en Azure App Service

Configuración del origen de datos

Orígenes de datos de nivel de aplicación

Recursos de nivel de servidor compartidos

Finalización de la configuración

Contenido relacionado

Comentarios

Recursos adicionales