Configurar fontes de dados para um aplicativo Tomcat, JBoss ou Java SE no Serviço de Aplicativo do Azure

Este artigo mostra como configurar fontes de dados em um aplicativo Java SE, Tomcat ou JBoss no Serviço de Aplicativo.

O Azure App Service executa aplicações web Java em três tipos num serviço totalmente gerido:

Java Standard Edition (SE). O Java SE pode executar uma aplicação implementada como um pacote Java archive (JAR) que contenha um servidor embutido, como Spring Boot, Quarkus, Dropwizard, ou uma aplicação com um servidor Tomcat ou Jetty embutido.
Tomcat. O servidor Tomcat incorporado pode executar uma aplicação implementada como um pacote de arquivo de aplicações web (WAR).
JBoss Enterprise Application Platform (EAP): O servidor JBoss EAP integrado pode executar um aplicativo implantado como um pacote WAR ou Enterprise Archive (EAR). Esta opção é suportada para aplicações Linux num conjunto de preços que incluem Free, Premium v3 e Isolated v2.

Observação

O JBoss EAP no App Service agora suporta faturação Bring Your Own License (BYOL). O BYOL permite que os clientes que já têm subscrições Red Hat apliquem essas licenças diretamente às suas implementações JBoss EAP no Azure App Service. Para mais informações, consulte o Suporte BYOL para JBoss EAP no App Service.

Configurar a fonte de dados

Para se conectar a fontes de dados em aplicativos Spring Boot, sugerimos criar cadeias de conexão e injetá-las em seu arquivo application.properties .

No painel esquerdo da página do Serviço de Aplicações, selecione Definições>Variáveis de Ambiente. No separador Strings de Ligação , selecione Adicionar. Defina um Nome para a cadeia, cole a sua cadeia de ligação JDBC no campo Valor e defina o Tipo para Personalizado. Podes, opcionalmente, definir a string de ligação como uma configuração de slot.

A cadeia de ligação é acessível à sua aplicação como uma variável de ambiente chamada CUSTOMCONNSTR_<your-string-name>. Por exemplo, CUSTOMCONNSTR_exampledb.
No teu ficheiro application.properties , faz referência à string de ligação com o nome da variável de ambiente. Para o exemplo anterior, usaria este código:
```
app.datasource.url=${CUSTOMCONNSTR_exampledb}
```

Para mais informações, consulte a documentação do Spring Boot sobre acesso a dados e configuração externalizada.

Gorjeta

Os contentores Tomcat Linux podem configurar automaticamente fontes de dados partilhadas no servidor Tomcat se definir a variável WEBSITE_AUTOCONFIGURE_DATABASE de ambiente para true. A única coisa que tens de fazer é adicionar uma configuração de aplicação que contenha uma string de ligação JDBC válida a uma base de dados Oracle, SQL Server, PostgreSQL ou MySQL (incluindo as credenciais de ligação). O App Service adiciona automaticamente a base de dados partilhada correspondente a /usr/local/tomcat/conf/context.xml, usando um driver apropriado disponível no contentor. Para um cenário de ponta a ponta que utilize esta abordagem, veja Tutorial: Construir uma aplicação web Tomcat com Azure App Service em Linux e MySQL.

Estas instruções se aplicam a todas as conexões de banco de dados. Tens de substituir os marcadores de posição pelo nome da classe do driver da base de dados escolhida e pelo ficheiro JAR. A tabela seguinte fornece nomes de classes e downloads de drivers para bases de dados comuns.

Base de Dados	Nome da classe de pilotos	Controlador JDBC
PostgreSQL	`org.postgresql.Driver`	Transferir
MySQL	`com.mysql.jdbc.Driver`	Descarregar (Selecionar Plataforma Independente.)
SQL Server	`com.microsoft.sqlserver.jdbc.SQLServerDriver`	Transferir

Para configurar o Tomcat para usar Java Database Connectivity (JDBC) ou a Java Persistence API (JPA), personalize primeiro a CATALINA_OPTS variável de ambiente que é lida pelo Tomcat no arranque. Defina este valor usando uma definição de aplicação no plugin App Service Maven:

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

Ou define a variável ambiente no separador de definições da aplicação da página devariáveis de Ambiente de > no portal Azure.

De seguida, determine se a fonte de dados deve estar disponível para uma aplicação ou para todas as aplicações a correr no servlet Tomcat.

Fontes de dados no nível do aplicativo

Para configurar uma fonte de dados no nível do aplicativo:

Crie um arquivo context.xml no diretório META-INF/ do seu projeto. Crie o diretório META-INF/ se ele não existir.

No context.xml, adicione um Context elemento para vincular a fonte de dados a um endereço JNDI. Substitua o driverClassName espaço provisório pelo nome da classe do seu condutor na tabela que aparece anteriormente neste artigo.

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

Atualize o web.xml da sua aplicação para usar a fonte de dados na sua aplicação.

<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 compartilhados no nível do servidor

Linux
Windows

Gorjeta

Os contentores Tomcat para Linux podem aplicar automaticamente ficheiros XSLT usando a seguinte convenção para ficheiros copiados para /home/site/wwwroot: Se server.xml.xsl ou server.xml.xslt estiver presente, os ficheiros são aplicados ao arquivo do Tomcat server.xml. Se context.xml.xsl ou context.xml.xslt estiver presente, os ficheiros são aplicados no context.xml do Tomcat.

Adicionar uma fonte de dados compartilhada no nível do servidor requer que você edite o server.xmlTomcat . Como as alterações de ficheiros fora do diretório são efémeras, as alterações nos arquivos de configuração do Tomcat precisam ser aplicadas de forma programática, da seguinte forma:

Carrega um script de arranque e define o caminho para o script na Configuração das Definições>. No separador Definições da pilha, adicione o caminho na caixa de comando de inicialização. Podes carregar o script de arranque usando FTP.

O seu script de arranque faz uma transformação XSL no server.xml ficheiro e exporta o ficheiro XML resultante para /usr/local/tomcat/conf/server.xml. O script de arranque deve instalar libxslt ou xlstproc, dependendo da versão de distribuição do Tomcat da sua aplicação web, como indicado no comentário do exemplo de script seguinte. Podes usar FTP para carregar o teu ficheiro XSL e o script de arranque.

# 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

O ficheiro XSL de exemplo a seguir adiciona um novo nó de conector ao Tomcat server.xml.

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

Finalizar a configuração

Por fim, coloca os JARs do driver no caminho de classe do Tomcat e reinicia a aplicação App Service.

Certifique-se de que os arquivos do driver JDBC estejam disponíveis para o carregador de classes Tomcat colocando-os no diretório /home/site/lib . No Cloud Shell, execute az webapp deploy --type=lib para cada JAR de driver:

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

Se você criou uma fonte de dados no nível do servidor, reinicie o aplicativo Linux do Serviço de Aplicativo. O Tomcat restabelece CATALINA_BASE para /home/tomcat e utiliza a configuração atualizada.

Não é possível modificar diretamente uma instalação do Tomcat para configuração global do servidor, pois o local de instalação é de apenas leitura. A forma mais fácil de fazer alterações de configuração ao nível do servidor na sua instalação do Windows Tomcat é completar os seguintes passos no início da aplicação:

Copie o Tomcat para um diretório local (%LOCAL_EXPANDED%) e use essa cópia como CATALINA_BASE. (Consulte a documentação do Tomcat sobre esta variável).
Adicione as suas fontes de dados partilhadas a %LOCAL_EXPANDED%\tomcat\conf\server.xml usando a transformação XSL.

Adicionar um ficheiro de arranque

Crie um arquivo nomeado startup.cmd no %HOME%\site\wwwroot diretório. Esse arquivo é executado automaticamente antes que o servidor Tomcat seja iniciado. O ficheiro deve conter isto:

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

Adicionar o script de configuração do PowerShell

De seguida, adicione um script de configuração chamado configure.ps1 ao %HOME%\site diretório. O script contém 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 conclui as seguintes etapas:

Verifica se existe uma cópia personalizada do Tomcat. Se existir um, o script de arranque pode parar.
Copie o Tomcat localmente.
Adicione fontes de dados partilhadas à configuração personalizada do Tomcat usando a transformação XSL.
Indique que a configuração foi concluída com sucesso.

Adicionar arquivo de transformação XSL

Um caso de uso comum para personalizar a instalação integrada do Tomcat é modificar os arquivos de configuração do Tomcat, como server.xml, context.xml ou web.xml. O Serviço de Aplicativo já modifica esses arquivos para fornecer recursos da plataforma. Para continuar a usar estas funcionalidades, é necessário preservar o conteúdo destes ficheiros quando lhes faz alterações. Para preservar este conteúdo, use uma transformação XSL (XSLT).

Adicione um ficheiro de transformação XSL chamado server.xsl ao diretório %HOME%_\site . Você pode usar o seguinte código de transformação XSL para adicionar um novo nó de conector ao server.xml. A transformação de identidade no início preserva o conteúdo original do arquivo de configuração.

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

Definir a `CATALINA_BASE` definição da aplicação

A plataforma também precisa saber onde sua versão personalizada do Tomcat está instalada. Você pode definir o local da instalação na configuração do CATALINA_BASE aplicativo.

Você pode usar a CLI do Azure para alterar essa configuração:

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

Em alternativa, pode alterar manualmente a definição no portal Azure:

Vai a Definições>Variáveis de Ambiente>Definições da App.
Selecione Adicionar.
Use estes valores para criar a configuração:
1. Nome: CATALINA_BASE
2. Valor: "%LOCAL_EXPANDED%\tomcat"

Finalizar a configuração

Por fim, coloque os JARs do driver no classpath do Tomcat e reinicie o Serviço de Aplicações. Certifique-se de que os arquivos do driver JDBC estejam disponíveis para o carregador de classes Tomcat colocando-os no diretório /home/site/lib . No Cloud Shell, execute az webapp deploy --type=lib para cada JAR de driver:

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

Gorjeta

Por defeito, os contentores JBoss Linux podem configurar automaticamente fontes de dados partilhadas no servidor JBoss. A única coisa que precisas de fazer é adicionar uma configuração de aplicação que contenha uma string de ligação JDBC válida a uma base de dados Oracle, SQL Server, PostgreSQL ou MySQL (incluindo as credenciais de ligação), e adicionar a variável de definição da app / ambiente WEBSITE_AUTOCONFIGURE_DATABASE com o valor true. Também são suportadas ligações JDBC criadas com conector de serviço. O App Service adiciona automaticamente a fonte de dados partilhada correspondente (com base no nome da definição da aplicação e no sufixo _DS), usando um driver apropriado disponível no contentor. Para um cenário de ponta a ponta que utilize esta abordagem, veja Tutorial: Construir uma aplicação web JBoss com Azure App Service em Linux e MySQL.

Existem três passos principais para registar uma fonte de dados no JBoss EAP:

Carregue o driver JDBC.
Adicione o driver JDBC como um módulo.
Adicione uma fonte de dados com o módulo.

App Service é um serviço de alojamento sem estado, por isso precisa de inserir estes passos num script de arranque e executá-lo sempre que o contentor JBoss iniciar. Aqui estão exemplos de bases de dados PostgreSQL, MySQL e Azure SQL:

Observação

O JBoss EAP no App Service suporta a faturação Bring Your Own License (BYOL). O BYOL permite que os clientes que já têm subscrições Red Hat apliquem essas licenças diretamente às suas implementações JBoss EAP no Azure App Service. Para mais informações, consulte Suporte BYOL para JBoss EAP.

Coloque os comandos da CLI do JBoss em um arquivo chamado jboss-cli-commands.cli. Os comandos do JBoss devem adicionar o módulo e registrá-lo como fonte de dados. O exemplo a seguir mostra os comandos da CLI do JBoss para criar uma fonte de dados PostgreSQL com o 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
```
Observe que o module add comando usa três variáveis de ambiente (DB_HOST, DB_USERNAME, e DB_PASSWORD), que você deve adicionar no Serviço de Aplicativo como configurações do aplicativo. O script adiciona-os sem um sinalizador --resolve-parameter-values para que o JBoss não salve os seus valores em texto simples.
Crie um script de inicialização, startup.sh, que chame os comandos da CLI do JBoss. O exemplo seguinte mostra como chamar o seu ficheiro jboss-cli-commands.cli . Mais tarde, configura o App Service para executar este script quando o contentor inicia.
```
$JBOSS_HOME/bin/jboss-cli.sh --connect --file=/home/site/scripts/jboss-cli-commands.cli
```

Usando uma opção de implantação de sua escolha, carregue seu driver JDBC, jboss-cli-commands.cli e startup.sh para os caminhos especificados nos respetivos scripts. Carrega-startup.sh como ficheiro de arranque. Por exemplo:

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 obter mais informações, consulte Implantar arquivos no Serviço de Aplicativo.

<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 a fonte de dados foi adicionada ao servidor JBoss, faça SSH na sua aplicação web e execute $JBOSS_HOME/bin/jboss-cli.sh --connect. Depois de estar ligado ao JBoss, execute /subsystem=datasources:read-resource para imprimir uma lista das fontes de dados.

De acordo com a definição em jboss-cli-commands.cli, pode aceder à ligação PostgreSQL usando o nome JNDI java:jboss/datasources/postgresDS.

Observação

O JBoss EAP no Serviço de Aplicações suporta a faturação Bring Your Own License (BYOL). O BYOL permite que os clientes que já têm subscrições Red Hat apliquem essas licenças diretamente às suas implementações JBoss EAP no Azure App Service. Para mais informações, consulte o Suporte BYOL para JBoss EAP no Azure App Service.

Coloque os comandos da CLI do JBoss em um arquivo chamado jboss-cli-commands.cli. Os comandos do JBoss devem adicionar o módulo e registrá-lo como fonte de dados. O exemplo a seguir mostra os comandos da CLI do JBoss para criar uma fonte de dados MySQL com o nome java:jboss/datasources/mysqlDSJNDI .
```
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
```
Observe que o module add comando usa três variáveis de ambiente (DB_HOST, DB_USERNAME, e DB_PASSWORD), que você deve adicionar no Serviço de Aplicativo como configurações do aplicativo. O script adiciona-os sem um sinalizador --resolve-parameter-values para que o JBoss não salve os seus valores em texto simples.
Crie um script de inicialização, startup.sh, que chame os comandos da CLI do JBoss. O exemplo seguinte mostra como chamar o seu ficheiro jboss-cli-commands.cli . Mais tarde, configura o App Service para executar este script quando o contentor inicia.
```
$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 obter mais informações, consulte Implantar arquivos no Serviço de Aplicativo.

<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

De acordo com a definição em jboss-cli-commands.cli, pode aceder à ligação MySQL usando o nome JNDI java:jboss/datasources/mysqlDS.

Observação

O JBoss EAP no App Service suporta a faturação Bring Your Own License (BYOL). O BYOL permite que clientes com subscrições Red Hat existentes apliquem essas licenças diretamente às suas implementações JBoss EAP no Azure App Service. Para mais informações, consulte Suporte BYOL para JBoss EAP.

Coloque os comandos da CLI do JBoss em um arquivo chamado jboss-cli-commands.cli. Os comandos do JBoss devem adicionar o módulo e registrá-lo como fonte de dados. O exemplo seguinte mostra os comandos CLI do JBoss para criar uma fonte de dados para uma base de dados Azure SQL com o nome 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

Observe que o module add comando usa três variáveis de ambiente (DB_HOST, DB_USERNAME, e DB_PASSWORD), que você deve adicionar no Serviço de Aplicativo como configurações do aplicativo. O script adiciona-os sem um sinalizador --resolve-parameter-values para que o JBoss não salve os seus valores em texto simples.

Crie um script de inicialização, startup.sh, que chame os comandos da CLI do JBoss. O exemplo seguinte mostra como chamar o seu ficheiro jboss-cli-commands.cli . Mais tarde, configura o App Service para executar este script quando o contentor inicia.
```
$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 obter mais informações, consulte Implantar arquivos no Serviço de Aplicativo.

<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 a fonte de dados foi adicionada ao servidor JBoss, SSH em seu webapp e execute $JBOSS_HOME/bin/jboss-cli.sh --connect. Depois de estar ligado ao JBoss, execute /subsystem=datasources:read-resource para imprimir uma lista das fontes de dados.

De acordo com a definição em jboss-cli-commands.cli, pode aceder à ligação à base de dados SQL usando o nome JNDIjava:jboss/datasources/sqlDS.

Documentação do desenvolvedor do Azure para Java
FAQ do Serviço de Aplicações no Linux
Referência de variáveis de ambiente e configurações de aplicativo

Comentários

Esta página foi útil?

Last updated on 2026-04-24

Configurar fontes de dados para um aplicativo Tomcat, JBoss ou Java SE no Serviço de Aplicativo do Azure

Configurar a fonte de dados

Fontes de dados no nível do aplicativo

Recursos compartilhados no nível do servidor

Finalizar a configuração

Conteúdo relacionado

Comentários

Recursos adicionais