Konfigurowanie źródeł danych dla aplikacji Tomcat, JBoss lub Java SE w usłudze aplikacja systemu Azure Service

W tym artykule pokazano, jak skonfigurować źródła danych w aplikacji Java SE, Tomcat lub JBoss w usłudze App Service.

Azure App Service uruchamia aplikacje internetowe Java w pełni zarządzanej usłudze w trzech wariantach:

• Java Standard Edition (SE): może uruchomić aplikację wdrożoną jako pakiet Java Archive (JAR), który zawiera serwer osadzony (taki jak Spring Boot, Quarkus, Dropwizard lub aplikacja z osadzonym serwerem Tomcat lub Jetty).
• Tomcat: Wbudowany serwer Tomcat może uruchamiać aplikację wdrożona jako pakiet archiwum aplikacji internetowej (WAR).
• JBoss Enterprise Application Platform (EAP): wbudowany serwer JBoss EAP może uruchomić aplikację wdrożona jako pakiet WAR lub Enterprise Archive (EAR). Obsługiwane dla aplikacji systemu Linux w zestawie poziomów cenowych, w tym Free, Premium v3 i Isolated v2.gti

Uwaga / Notatka

Aplikacja JBoss EAP w usłudze App Service obsługuje teraz rozliczenia "Bring Your Own License" (BYOL), dzięki czemu klienci z istniejącymi subskrypcjami oprogramowania Red Hat mogą stosować te licencje bezpośrednio do wdrożeń protokołu EAP JBoss w usłudze Azure App Service. Dowiedz się więcej.

Konfigurowanie źródła danych

Aby nawiązać połączenie ze źródłami danych w aplikacjach Spring Boot, zalecamy utworzenie parametry połączenia i wstrzyknięcie ich do pliku application.properties.

1. W sekcji "Konfiguracja" strony usługi App Service ustaw nazwę ciągu, wklej parametry połączenia JDBC w polu wartości i ustaw typ na "Niestandardowy". Opcjonalnie możesz ustawić tę parametry połączenia jako ustawienie miejsca.

   Ta parametry połączenia jest dostępna dla naszej aplikacji jako zmienna środowiskowa o nazwie CUSTOMCONNSTR_<your-string-name>. Na przykład CUSTOMCONNSTR_exampledb.

2. W pliku application.properties odwołaj się do tego parametry połączenia z nazwą zmiennej środowiskowej. W naszym przykładzie użyjemy następującego kodu:

   app.datasource.url=${CUSTOMCONNSTR_exampledb}
   

Aby uzyskać więcej informacji, zobacz dokumentację platformy Spring Boot dotyczącą dostępu do danych i konfiguracji zewnętrznych.

Napiwek

Kontenery Tomcat systemu Linux mogą automatycznie konfigurować udostępnione źródła danych na serwerze Tomcat, ustawiając zmienną środowiskową WEBSITE_AUTOCONFIGURE_DATABASE na wartość true. Jedyne, co należy zrobić, to dodanie ustawienia aplikacji zawierającego prawidłową parametry połączenia JDBC do bazy danych Oracle, SQL Server, PostgreSQL lub MySQL (w tym poświadczeń połączenia), a usługa App Service automatycznie dodaje odpowiednią udostępnioną bazę danych do /usr/local/tomcat/conf/context.xml przy użyciu odpowiedniego sterownika dostępnego w kontenerze. Aby uzyskać kompleksowy scenariusz korzystający z tego podejścia, zobacz Samouczek: tworzenie aplikacji internetowej Tomcat przy użyciu usługi Azure App Service na Linux i MySQL.

Te instrukcje dotyczą wszystkich połączeń bazy danych. Należy wypełnić symbole zastępcze nazwą klasy sterownika wybranej bazy danych i plikiem JAR. Podano tabelę zawierającą nazwy klas oraz sterowniki do pobrania dla typowych baz danych.

baza danych	Nazwa klasy sterownika	Sterownik JDBC
PostgreSQL	org.postgresql.Driver	Pobierz
MySQL	com.mysql.jdbc.Driver	Pobierz (wybierz pozycję "Niezależna od platformy")
SQL Server	com.microsoft.sqlserver.jdbc.SQLServerDriver	Pobierz

Aby skonfigurować serwer Tomcat do używania interfejsu Java Database Connectivity (JDBC) lub interfejsu API trwałości języka Java (JPA), najpierw dostosuj CATALINA_OPTS zmienną środowiskową odczytaną przez serwer Tomcat podczas uruchamiania. Ustaw te wartości za pomocą ustawienia aplikacji w wtyczki App Service Maven:

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

Możesz też ustawić zmienne środowiskowe na stronie Ustawienia aplikacji konfiguracji>w witrynie Azure Portal.

Następnie ustal, czy źródło danych powinno być dostępne dla jednej aplikacji, czy dla wszystkich aplikacji uruchomionych w serwletze Tomcat.

Źródła danych na poziomie aplikacji

Aby skonfigurować źródło danych na poziomie aplikacji:

1. Utwórz plik context.xml w katalogu META-INF/ projektu. Utwórz katalog META-INF/, jeśli nie istnieje.

2. W context.xml dodaj Context element, aby połączyć źródło danych z adresem JNDI. Zastąp symbol driverClassName nazwą klasy sterownika z tabeli powyżej.

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

3. Zaktualizuj web.xml aplikacji, aby użyć źródła danych w aplikacji.

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

Udostępnione zasoby na poziomie serwera

Linux

Napiwek

Kontenery Tomcat systemu Linux mogą automatycznie stosować pliki XSLT przy użyciu następującej konwencji dla plików kopiowanych do /home/site/wwwroot: jeśli server.xml.xsl lub server.xml.xslt są obecne, zostaną one zastosowane do Tomcat server.xml. Jeśli context.xml.xsl lub context.xml.xslt są obecne, zostaną zastosowane do serwera Tomcat context.xml.

Dodanie udostępnionego źródła danych na poziomie serwera wymaga edytowania elementu server.xml Tomcat. Ponieważ zmiany plików spoza /home katalogu są efemeryczne, zmiany w plikach konfiguracji serwera Tomcat muszą być stosowane programowo w następujący sposób:

1. Przekaż skrypt uruchamiania i ustaw ścieżkę do skryptu w KonfiguracjiPoleceniu uruchamiania. Skrypt uruchamiania można przekazać przy użyciu protokołu FTP.

Skrypt uruchamiania stosuje transformację XSL na pliku server.xml i zapisuje wynikowy plik XML do /usr/local/tomcat/conf/server.xml. Skrypt uruchamiania powinien zainstalować libxslt lub xlstproc w zależności od dystrybucji wersji Tomcat aplikacji internetowej. Plik XSL i skrypt uruchamiania można przekazać za pośrednictwem protokołu FTP. Poniżej znajduje się przykładowy skrypt uruchamiania.

# 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

Poniższy przykładowy plik XSL dodaje nowy węzeł łącznika do 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 Connector 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>

Finalizowanie konfiguracji

Na koniec umieść pliki JAR sterowników w ścieżce klas Tomcata i uruchom ponownie Twój App Service.

1. Upewnij się, że pliki sterowników JDBC są dostępne dla classloadera Tomcat, umieszczając je w katalogu /home/site/lib. W usłudze Cloud Shell uruchom polecenie az webapp deploy --type=lib dla każdego sterownika JAR:

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

Jeśli utworzono źródło danych na poziomie serwera, uruchom ponownie aplikację usługi App Service dla systemu Linux. Program Tomcat resetuje CATALINA_BASE do /home/tomcat i używa zaktualizowanej konfiguracji.

Windows

Nie można bezpośrednio zmodyfikować instalacji serwera Tomcat dla konfiguracji całego serwera, ponieważ lokalizacja instalacji jest tylko do odczytu. Aby wprowadzić zmiany konfiguracji na poziomie serwera w instalacji serwera Tomcat, najprostszym sposobem jest wykonanie następujących czynności podczas uruchamiania aplikacji:

1. Skopiuj serwer Tomcat do katalogu lokalnego (%LOCAL_EXPANDED%) i użyj go jako CATALINA_BASE (zobacz dokumentację serwera Tomcat w tej zmiennej).
2. Dodaj udostępnione źródła danych do %LOCAL_EXPANDED%\tomcat\conf\server.xml przekształcenia XSL.

Dodawanie pliku startowego

Utwórz plik o nazwie startup.cmd w %HOME%\site\wwwroot katalogu. Ten plik jest uruchamiany automatycznie przed uruchomieniem serwera Tomcat. Plik powinien mieć następującą zawartość:

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

Dodawanie skryptu konfiguracji programu PowerShell

Następnie dodaj skrypt konfiguracji o nazwie configure.ps1 do %HOME%\site katalogu przy użyciu następującego kodu:

# 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 config has already been done
if (Test-Path "$marker_file") {
    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 -Path "$Env:LOCAL_EXPANDED\tomcat" -Recurse -Force
}

# Copy Tomcat to local
# Using the environment variable $AZURE_TOMCAT90_HOME uses the 'default' version of Tomcat
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 was a success if successful
if ($success) {
    New-Item -Path "$marker_file" -ItemType File
}

Ten program PowerShell wykonuje następujące czynności:

1. Sprawdź, czy istnieje już niestandardowa kopia serwera Tomcat. Jeśli tak, skrypt uruchamiania może zakończyć się tutaj.
2. Skopiuj serwer Tomcat lokalnie.
3. Dodaj udostępnione źródła danych do konfiguracji niestandardowego serwera Tomcat przy użyciu przekształcenia XSL.
4. Wskazuje, że konfiguracja została pomyślnie ukończona.

Dodaj plik przekształcenia XSL

Typowym przypadkiem użycia dostosowywania wbudowanej instalacji serwera Tomcat jest zmodyfikowanie plików konfiguracji Tomcat server.xml, context.xml lub web.xml. Usługa App Service już modyfikuje te pliki w celu udostępnienia funkcji platformy. Aby nadal korzystać z tych funkcji, ważne jest zachowanie zawartości tych plików podczas wprowadzania zmian. W tym celu należy użyć transformacji XSL (XSLT).

Dodaj plik przekształcenia XSL o nazwie configure.ps1 do katalogu %HOME%_\site . Możesz użyć następującego kodu przekształcenia XSL, aby dodać nowy węzeł łącznika do server.xml. Przekształcenie tożsamości na początku zachowuje oryginalną zawartość pliku konfiguracji.

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

Ustawianie CATALINA_BASE ustawienia aplikacji

Platforma musi również wiedzieć, gdzie zainstalowano niestandardową wersję serwera Tomcat. Lokalizację instalacji można ustawić w ustawieniu CATALINA_BASE aplikacji.

Aby zmienić to ustawienie, możesz użyć interfejsu wiersza polecenia platformy Azure:

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

Możesz też ręcznie zmienić ustawienie w witrynie Azure Portal:

1. Przejdź do Ustawienia>Konfiguracja>Ustawienia aplikacji.
2. Wybierz pozycję Nowe ustawienie aplikacji.
3. Użyj tych wartości, aby utworzyć ustawienie:
   1. Nazwa: CATALINA_BASE
   2. Wartość: "%LOCAL_EXPANDED%\tomcat"

Finalizowanie konfiguracji

Na koniec umieść sterowniki JAR w ścieżce klasy Tomcat i uruchom ponownie usługę App Service. Upewnij się, że pliki sterowników JDBC są dostępne dla classloadera Tomcat, umieszczając je w katalogu /home/site/lib. W usłudze Cloud Shell uruchom polecenie az webapp deploy --type=lib dla każdego sterownika JAR:

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

Napiwek

Domyślnie kontenery JBoss systemu Linux mogą automatycznie konfigurować udostępnione źródła danych na serwerze JBoss. Jedyną rzeczą, którą należy wykonać, jest dodanie ustawienia aplikacji zawierającego prawidłowe parametry połączenia JDBC do bazy danych Oracle, SQL Server, PostgreSQL lub MySQL (w tym poświadczeń połączenia) i dodania zmiennej WEBSITE_AUTOCONFIGURE_DATABASE Ustawienia aplikacji / Środowiska z wartością true. Obsługiwane są również połączenia JDBC utworzone za pomocą łącznika usługi. Usługa App Service automatycznie dodaje odpowiednie udostępnione źródło danych (na podstawie nazwy ustawienia aplikacji i sufiksu _DS), używając odpowiedniego sterownika dostępnego w kontenerze. Aby uzyskać kompleksowy scenariusz korzystający z tego podejścia, zobacz Samouczek: Budowanie aplikacji internetowej JBoss przy użyciu Azure App Service na systemie Linux i MySQL.

Podczas rejestrowania źródła danych za pomocą protokołu JBoss EAP należy wykonać trzy podstawowe kroki:

1. Przekaż sterownik JDBC.
2. Dodaj sterownik JDBC jako moduł.
3. Dodaj źródło danych za pomocą modułu .

Usługa App Service to bezstanowa usługa hostingu, dlatego należy umieścić te kroki w skrypcie uruchamiania i uruchomić go każdorazowo, gdy uruchamia się kontener JBoss. Używanie baz danych PostgreSQL, MySQL i SQL Database jako przykładów:

PostgreSQL

Uwaga / Notatka

Aplikacja JBoss EAP w usłudze App Service obsługuje teraz rozliczenia "Bring Your Own License" (BYOL), dzięki czemu klienci z istniejącymi subskrypcjami oprogramowania Red Hat mogą stosować te licencje bezpośrednio do wdrożeń protokołu EAP JBoss w usłudze Azure App Service. Dowiedz się więcej.

1. Umieść polecenia JBoss CLI w pliku o nazwie jboss-cli-commands.cli. Polecenia JBoss muszą dodać moduł i zarejestrować go jako źródło danych. W poniższym przykładzie przedstawiono polecenia JBoss CLI do tworzenia źródła danych PostgreSQL z nazwą 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
   

   Należy pamiętać, że module add polecenie używa trzech zmiennych środowiskowych (DB_HOST, DB_USERNAMEi DB_PASSWORD), które należy dodać w usłudze App Service jako ustawienia aplikacji. Skrypt dodaje je bez --resolve-parameter-values flagi, aby program JBoss nie zapisywał swoich wartości w postaci zwykłego tekstu.

2. Utwórz skrypt startowy, startup.sh, który wywołuje polecenia CLI JBoss. W poniższym przykładzie pokazano, jak wywołać element jboss-cli-commands.cli. Później skonfigurujesz usługę App Service tak, aby uruchamiała ten skrypt po uruchomieniu kontenera.

   $JBOSS_HOME/bin/jboss-cli.sh --connect --file=/home/site/scripts/jboss_cli_commands.cli
   

3. Korzystając z wybranej opcji wdrożenia, przekaż sterownik JDBC, jboss-cli-commands.cli i startup.sh do ścieżek określonych w odpowiednich skryptach. W szczególności przekaż startup.sh jako plik startowy. Na przykład:

   Interfejs wiersza polecenia platformy Azure

   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
   

   Aby uzyskać więcej informacji, zobacz Wdrażanie plików w usłudze App Service.

   Wtyczka Azure Maven

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

   Azure Pipelines

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

Aby potwierdzić, że źródło danych zostało dodane do serwera JBoss, protokół SSH do aplikacji internetowej i uruchom polecenie $JBOSS_HOME/bin/jboss-cli.sh --connect. Po nawiązaniu połączenia z narzędziem JBoss uruchom polecenie /subsystem=datasources:read-resource , aby wyświetlić listę źródeł danych.

Zgodnie z definicją w pliku jboss-cli-commands.cli, można uzyskać dostęp do połączenia PostgreSQL przy użyciu nazwy JNDI java:jboss/datasources/postgresDS.

MySQL

Uwaga / Notatka

Aplikacja JBoss EAP w usłudze App Service obsługuje teraz rozliczenia "Bring Your Own License" (BYOL), dzięki czemu klienci z istniejącymi subskrypcjami oprogramowania Red Hat mogą stosować te licencje bezpośrednio do wdrożeń protokołu EAP JBoss w usłudze Azure App Service. Dowiedz się więcej.

1. Umieść polecenia JBoss CLI w pliku o nazwie jboss-cli-commands.cli. Polecenia JBoss muszą dodać moduł i zarejestrować go jako źródło danych. W poniższym przykładzie przedstawiono polecenia interfejsu wiersza polecenia JBoss, służące do tworzenia źródła danych MySQL o nazwie 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
   

   Należy pamiętać, że module add polecenie używa trzech zmiennych środowiskowych (DB_HOST, DB_USERNAMEi DB_PASSWORD), które należy dodać w usłudze App Service jako ustawienia aplikacji. Skrypt dodaje je bez --resolve-parameter-values flagi, aby program JBoss nie zapisywał swoich wartości w postaci zwykłego tekstu.

2. Utwórz skrypt startowy, startup.sh, który wywołuje polecenia CLI JBoss. W poniższym przykładzie pokazano, jak wywołać element jboss-cli-commands.cli. Później skonfigurujesz usługę App Service tak, aby uruchamiała ten skrypt po uruchomieniu kontenera.

   $JBOSS_HOME/bin/jboss-cli.sh --connect --file=/home/site/scripts/jboss_cli_commands.cli
   

3. Korzystając z wybranej opcji wdrożenia, przekaż sterownik JDBC, jboss-cli-commands.cli i startup.sh do ścieżek określonych w odpowiednich skryptach. W szczególności przekaż startup.sh jako plik startowy. Na przykład:

   Interfejs wiersza polecenia platformy Azure

   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
   

   Aby uzyskać więcej informacji, zobacz Wdrażanie plików w usłudze App Service.

   Wtyczka Azure Maven

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

   Azure Pipelines

   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
   

Aby potwierdzić, że źródło danych zostało dodane do serwera JBoss, protokół SSH do aplikacji internetowej i uruchom polecenie $JBOSS_HOME/bin/jboss-cli.sh --connect. Po nawiązaniu połączenia z narzędziem JBoss uruchom polecenie /subsystem=datasources:read-resource , aby wyświetlić listę źródeł danych.

Zgodnie z definicją w pliku jboss-cli-commands.cli można uzyskać dostęp do połączenia MySQL przy użyciu nazwy JNDI java:jboss/datasources/mysqlDS.

SQL Database

Uwaga / Notatka

Aplikacja JBoss EAP w usłudze App Service obsługuje teraz rozliczenia "Bring Your Own License" (BYOL), dzięki czemu klienci z istniejącymi subskrypcjami oprogramowania Red Hat mogą stosować te licencje bezpośrednio do wdrożeń protokołu EAP JBoss w usłudze Azure App Service. Dowiedz się więcej.

1. Umieść polecenia JBoss CLI w pliku o nazwie jboss-cli-commands.cli. Polecenia JBoss muszą dodać moduł i zarejestrować go jako źródło danych. W poniższym przykładzie przedstawiono polecenia interfejsu wiersza polecenia JBoss służące do tworzenia źródła danych dla usługi Azure SQL Database z nazwą 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
   

   Należy pamiętać, że module add polecenie używa trzech zmiennych środowiskowych (DB_HOST, DB_USERNAMEi DB_PASSWORD), które należy dodać w usłudze App Service jako ustawienia aplikacji. Skrypt dodaje je bez --resolve-parameter-values flagi, aby program JBoss nie zapisywał swoich wartości w postaci zwykłego tekstu.

2. Utwórz skrypt startowy, startup.sh, który wywołuje polecenia CLI JBoss. W poniższym przykładzie pokazano, jak wywołać element jboss-cli-commands.cli. Później skonfigurujesz usługę App Service tak, aby uruchamiała ten skrypt po uruchomieniu kontenera.

   $JBOSS_HOME/bin/jboss-cli.sh --connect --file=/home/site/scripts/jboss_cli_commands.cli
   

3. Korzystając z wybranej opcji wdrożenia, przekaż sterownik JDBC, jboss-cli-commands.cli i startup.sh do ścieżek określonych w odpowiednich skryptach. W szczególności przekaż startup.sh jako plik startowy. Na przykład:

   Interfejs wiersza polecenia platformy Azure

   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
   

   Aby uzyskać więcej informacji, zobacz Wdrażanie plików w usłudze App Service.

   Wtyczka Azure Maven

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

   Azure Pipelines

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

Aby potwierdzić, że źródło danych zostało dodane do serwera JBoss, protokół SSH do aplikacji internetowej i uruchom polecenie $JBOSS_HOME/bin/jboss-cli.sh --connect. Po nawiązaniu połączenia z narzędziem JBoss uruchom polecenie /subsystem=datasources:read-resource , aby wyświetlić listę źródeł danych.

Zgodnie z definicją w pliku jboss-cli-commands.cli można uzyskać dostęp do połączenia usługi SQL Database przy użyciu nazwy java:jboss/datasources/sqlDSJNDI .

Treści powiązane

Odwiedź centrum Azure for Java Developers, aby znaleźć przewodniki Szybki start platformy Azure, samouczki i dokumentację referencyjną języka Java.

• App Service dla systemu Linux — często zadawane pytania
• Dokumentacja zmiennych środowiskowych i ustawień aplikacji