Delen via

Een Java SE-, Tomcat- of JBoss EAP-app implementeren en configureren in Azure App Service

In dit artikel vindt u de meest voorkomende implementatie- en runtimeconfiguratie voor Java-apps in Azure App Service. Als het uw eerste keer is dat u Azure App Service gebruikt, moet u eerst de Java-quickstart lezen. U vindt de antwoorden op algemene vragen over het gebruik van App Service die niet specifiek zijn voor Java-ontwikkeling in de veelgestelde vragen over App Service.

Azure-app Service voert Java-webtoepassingen uit op een volledig beheerde service in drie varianten:

  • Java Standard Edition (SE): Kan een app uitvoeren die is geïmplementeerd als een Jar-pakket (Java Archive) dat een ingesloten server bevat (zoals Spring Boot, Quarkus, Dropwizard of een app met een ingesloten Tomcat- of Jetty-server).
  • Tomcat: De ingebouwde Tomcat-server kan een app uitvoeren die is geïmplementeerd als een WAR-pakket (Web Application Archive).
  • JBoss Enterprise Application Platform (EAP): de ingebouwde JBoss EAP-server kan een app uitvoeren die is geïmplementeerd als een WAR- of Enterprise Archive-pakket (EAR). Ondersteund voor Linux-apps in een set prijscategorieën, waaronder Gratis, Premium v3 en Isolated v2.gti

De Java-versie weergeven

Voer de volgende opdracht uit in Azure Cloud Shell om de huidige Java-versie weer te geven:

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

Als u alle ondersteunde Java-versies wilt weergeven, voert u de volgende opdracht uit in Cloud Shell:

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

De Java-versie ophalen in de Linux-container

Open een SSH-sessie met de container voor meer gedetailleerde versie-informatie in de Linux-container. Hier volgen enkele voorbeelden van wat u kunt uitvoeren.

Ga als volgt te werk om de Java-versie in de SSH-sessie weer te geven:

java -version

De Tomcat-serverversie weergeven in de SSH-sessie:

sh /usr/local/tomcat/version.sh

Als uw Tomcat-server zich op een aangepaste locatie bevindt, vindt u version.sh als volgt:

find / -name "version.sh"

De JBoss EAP-serverversie weergeven in de SSH-sessie:

$JBOSS_HOME/bin/jboss-cli.sh --connect --commands=:product-info

Zie voor meer informatie over versieondersteuning het ondersteuningsbeleid voor de taalruntime van App Service.

Wat gebeurt er met verouderde runtimes in App Service?

Verouderde runtimes worden afgedaan door de organisatie die ze onderhoudt of blijken aanzienlijke beveiligingsproblemen te hebben. Dienovereenkomstig worden ze verwijderd uit het maken en configureren van pagina's in de portal. Wanneer een verouderde runtime is verborgen in de portal, blijft elke app die die runtime gebruikt, nog steeds actief.

Als u een app wilt maken met een verouderde runtimeversie die niet meer wordt weergegeven in de portal, gebruikt u de Azure CLI, ARM-sjabloon of Bicep. Met deze implementatiealternatieven kunt u afgeschafte runtimes maken die zijn verwijderd in de portal, maar die nog steeds worden ondersteund.

Als een runtime volledig is verwijderd uit het App Service-platform, ontvangt de eigenaar van uw Azure-abonnement een e-mailmelding voordat deze wordt verwijderd.

Uw app implementeren

Bouwhulpmiddelen

Maven

Met behulp van de Maven-invoegtoepassing voor Azure Web Apps kunt u uw project eenvoudig voorbereiden met één opdracht in de hoofdmap van uw project:

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

Met deze opdracht voegt u een azure-webapp-maven-plugin invoegtoepassing en de bijbehorende configuratie toe door u te vragen een bestaande Azure-web-app te selecteren of een nieuwe te maken. Tijdens de configuratie wordt geprobeerd te detecteren of uw toepassing moet worden geïmplementeerd in Java SE, Tomcat of (alleen Linux) JBoss EAP. Vervolgens kunt u uw Java-app implementeren in Azure met behulp van de volgende opdracht:

mvn package azure-webapp:deploy

Hier volgt een voorbeeldconfiguratie in pom.xml:

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

Gradle

  1. Stel de Gradle-invoegtoepassing voor Azure Web Apps in door de invoegtoepassing toe te voegen aan build.gradle:

    plugins {
  id "com.microsoft.azure.azurewebapp" version "1.10.0"
}

  2. Configureer de details van uw web-app. Als ze niet bestaan, worden de bijbehorende Azure-resources gemaakt. Hier volgt een voorbeeldconfiguratie. Raadpleeg dit document voor meer informatie.

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

  3. Implementeren met één opdracht.

    gradle azureWebAppDeploy

IDE's

Azure biedt een naadloze Java App Service-ontwikkelervaring in populaire Java Integrated Development Environments (IDE's), waaronder:

Kudu- en OneDeploy-API’s

Implementatieclients zoals de Maven-invoegtoepassing, GitHub Actions die gebruikmaken van azure/webapps-deploy@v3 en hoger, of de opdracht az webapp deploy gebruiken OneDeploy, die wordt aangeroepen door het /api/publish eindpunt van de Kudu-site onder de schermen aan te roepen. Zie deze documentatie voor meer informatie over deze API.

Wanneer deze implementatiemethoden worden gebruikt, wordt de naam van het opgegeven JAR-bestand app.jar automatisch gewijzigd tijdens het implementatieproces. Dit zal onder /home/site/wwwwrootgeplaatst worden. Raadpleeg deze documentatie voor het implementeren van JAR-bestanden in Java SE.

Notitie

Als u alternatieve methoden zoals FTP of oudere ZipDeploy-API's gebruikt, wordt deze methode voor het wijzigen van de naam van het opgegeven JAR-bestand niet aangeroepen. Noteer dit als u het tekstvak Opstartbestand in de sectie Configuratie van de portal gebruikt om uw JAR-bestand expliciet aan te roepen.

U kunt WAR-bestanden implementeren in uw Tomcat-toepassing door deze documentatie te volgen. Wanneer deze bovenstaande implementatiemethoden worden gebruikt, wordt de naam van het opgegeven War-bestand app.war automatisch gewijzigd tijdens het implementatieproces. Dit wordt onder /home/site/wwwwroot geplaatst en biedt standaard alleen ondersteuning voor het implementeren van één WAR-bestand onder wwwroot. Dit wordt niet onder de /home/site/wwwroot/webapps map geplaatst, zoals wordt weergegeven bij het gebruik van implementatie-API's zoals WarDeploy. Om problemen met bestandsstructuurconflicten te voorkomen, is het raadzaam om slechts één of het andere implementatietype te gebruiken.

Raadpleeg deze documentatie voor het implementeren van WAR-bestanden in JBoss EAP. Wanneer OneDeploy wordt gebruikt, wordt de naam van het WAR-bestand app.war automatisch gewijzigd in en geplaatst onder /home/site/wwwroot.

Als u EAR-bestanden wilt implementeren, gebruikt u FTP. Uw EAR-toepassing wordt geïmplementeerd in de contexthoofdmap die is gedefinieerd in de configuratie van uw toepassing. Als u wilt dat uw web-app wordt bediend in het rootpad, moet u ervoor zorgen dat uw app de context root instelt op het rootpad: <context-root>/</context-root>. Zie De contexthoofdmap van een webtoepassing instellen voor meer informatie.

Implementeer uw WAR of JAR niet met BEHULP van FTP. Het FTP-hulpprogramma is ontworpen voor het uploaden van opstartscripts, afhankelijkheden of andere runtimebestanden. Het is niet de optimale keuze voor het implementeren van web-apps.

Een URL herschrijven of omleiden

Als u een URL wilt herschrijven of omleiden, gebruikt u een van de beschikbare URL-rewriters, zoals UrlRewriteFilter.

Tomcat biedt ook een herschrijfklep.

JBoss EAP biedt ook een herschrijfklep.

Logboekregistratie en foutopsporing van apps

Prestatierapporten, verkeersvisualisaties en statuscontroles zijn beschikbaar voor elke app via Azure Portal. Zie het overzicht van diagnostische gegevens van Azure App Service voor meer informatie.

Diagnostische logboeken streamen

U hebt vanuit de container toegang tot de consolelogboeken.

Voer de volgende opdracht uit om containerlogboekregistratie in te schakelen:

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

Vervang <app-name> en <resource-group-name> door namen die geschikt zijn voor uw webapplicatie.

Nadat u containerlogboekregistratie hebt ingeschakeld, voert u de volgende opdracht uit om de logboekstream te zien:

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

Als consolelogboeken niet onmiddellijk worden weergegeven, controleert u het na 30 seconden opnieuw.

Als u wilt stoppen met logboekstreaming, selecteert u Ctrl+C.

Zie Stream-logboeken in Cloud Shell voor meer informatie.

Toegang tot de SSH-console in Linux

Als u een directe SSH-sessie met uw container wilt openen, moet uw app worden uitgevoerd.

Gebruik de opdracht az webapp ssh .

Als u nog niet bent geverifieerd moet u zich verifiëren met uw Azure-abonnement om verbinding te maken. Nadat u bent geverifieerd, ziet u een shell in de browser waarin u opdrachten binnen uw container kunt uitvoeren.

SSH-verbinding

Notitie

Wijzigingen die u buiten de /home map aanbrengt, worden opgeslagen in de container zelf en blijven niet behouden na het opnieuw opstarten van de app.

Als u een externe SSH-sessie vanaf uw lokale computer wilt openen, raadpleegt u SSH-sessie openen vanuit externe shell.

Hulpprogramma's voor probleemoplossing voor Linux

De ingebouwde Java-afbeeldingen zijn gebaseerd op het Alpine Linux-besturingssysteem. Gebruik pakketbeheer apk om hulpprogramma's of opdrachten voor probleemoplossing te installeren.

Java Profiler

Alle Java-runtimes in Azure App Service worden geleverd met de Java Development Kit (JDK) Flight Recorder voor het profileren van Java-workloads. U kunt deze gebruiken om JVM (Java Virtual Machine), systeem- en toepassingsevenementen vast te leggen en om problemen in uw toepassingen op te lossen.

Ga naar de Documentatie van Azure Application Insights voor meer informatie over java profiler.

Java Flight Recorder

Alle Java-runtimes in App Service worden geleverd met de Java Flight Recorder. U kunt deze gebruiken om JVM-, systeem- en toepassingsevenementen vast te leggen en om problemen in uw Java-toepassingen op te lossen.

SSH in App Service en voer de jcmd opdracht uit om een lijst weer te geven van alle Java-processen die worden uitgevoerd. Naast jcmd zelf zou u uw Java-toepassing moeten zien draaien met een PID-nummer (proces-ID).

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

Voer de volgende opdracht uit om een opname van 30 seconden van de JVM te starten. Het profileert de JVM en maakt een JFR-bestand (Java Flight Recorder) met de naam jfr_example.jfr in de basismap. Vervang door 116 de PID van uw Java-app.

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

Tijdens het interval van 30 seconden kunt u controleren of de opname plaatsvindt door uit te voeren jcmd 116 JFR.check. De opdracht toont alle opnamen voor het opgegeven Java-proces.

Voortdurende opname

U kunt Java Flight Recorder gebruiken om uw Java-toepassing continu te profilen met minimale invloed op runtimeprestaties. Voer hiervoor de volgende Azure CLI-opdracht uit om een app-instelling JAVA_OPTS te maken met de benodigde configuratie. De inhoud van de JAVA_OPTS app-instelling wordt doorgegeven aan de java opdracht wanneer uw app wordt gestart.

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

Nadat de opname is gestart, kunt u de huidige opnamegegevens op elk gewenst moment dumpen met behulp van de JFR.dump opdracht.

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

JFR-bestanden analyseren

Gebruik FTPS om uw JFR-bestand te downloaden naar uw lokale computer. Als u het JFR-bestand wilt analyseren, downloadt en installeert u Java Mission Control (JMC). Zie de JMC-documentatie en de installatie-instructies voor instructies over het gebruik van Java Mission Control.

App-logboekregistratie

Ga als volgt te werk om App Service te configureren voor het schrijven van de standaardconsole-uitvoer van uw toepassing en standaardconsolefoutstromen naar het lokale bestandssysteem of Azure Blob Storage. Schakel toepassingslogboekregistratie in via De Azure-portal of in de Azure CLI. Als u langere retentie nodig hebt, configureert u de toepassing om uitvoer naar een Blob Storage-container te schrijven.

Uw Java- en Tomcat-app-logboeken vindt u in de /home/LogFiles/Application/ map.

Logboekregistratie van Azure Blob Storage voor Linux-apps kan alleen worden geconfigureerd met behulp van Azure Monitor.

Als uw toepassing gebruikmaakt van Logback of Log4j voor tracering, kunt u deze traceringen doorsturen voor controle in Azure Application Insights. Gebruik de configuratie-instructies voor het logboekregistratieframework in Java-traceringslogboeken verkennen in Application Insights.

Notitie

Vanwege een bekend beveiligingsprobleem CVE-2021-44228moet u Log4j versie 2.16 of hoger gebruiken.

Aanpassing en afstemming

Azure App Service biedt ondersteuning voor out-of-the-box afstemming en aanpassing via Azure Portal en de Azure CLI. Raadpleeg de volgende artikelen voor niet-Java-specifieke web-app-configuratie:

App-inhoud lokaal kopiëren

Stel de app-instelling JAVA_COPY_ALL op true om de inhoud van uw app naar de lokale worker te kopiëren vanuit het gedeelde bestandssysteem. Deze instelling helpt bij het oplossen van problemen met het vergrendelen van bestanden.

De Java-runtimeopties instellen

Als u toegewezen geheugen of andere JVM-runtimeopties wilt instellen, maakt u een app-instelling met de naam JAVA_OPTS met de opties. App Service geeft deze instelling door als een omgevingsvariabele aan de Java-runtime wanneer deze wordt gestart.

Maak in het Azure Portal onder Toepassingsinstellingen voor de web-app een nieuwe app-instelling met de naam JAVA_OPTS, die andere instellingen omvat, zoals -Xms512m -Xmx1204m.

Maak in het Azure Portal onder Toepassingsinstellingen voor de web-app een nieuwe app-instelling met de naam CATALINA_OPTS, die andere instellingen omvat, zoals -Xms512m -Xmx1204m.

Als u de app-instelling wilt configureren vanuit de Maven-invoegtoepassing, voegt u tags voor instelling/waarde toe in de sectie van de Azure-invoegtoepassing. In het volgende voorbeeld wordt een specifieke minimale en maximale Java-heapgrootte ingesteld:

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

Notitie

U hoeft geen web.config-bestand te maken wanneer u Tomcat gebruikt in Windows App Service.

Standaard stelt App Service de maximale heapgrootte van de JVM in op 70% van het totale geheugen dat beschikbaar is voor het App Service-plan. Als u de standaardinstelling wilt uitschakelen, kunt u de app-instelling WEBSITE_DISABLE_JAVA_HEAP_CONFIGURATION="true" gebruiken.

Als u de prestaties van uw toepassing op het platform verbetert, kan het nodig zijn om de heap-grootte aan te passen aan uw specifieke behoeften. Bij het afstemmen van de heap-instellingen van uw App Service-plan, controleer de details van uw App Service-plan en houd rekening met de vereisten van meerdere toepassingen en implementatieslots om de optimale geheugentoewijzing te vinden.

Websockets inschakelen

Schakel ondersteuning in voor websockets in Azure Portal in de toepassingsinstellingen voor de toepassing. U moet de toepassing opnieuw starten om de instelling van kracht te laten worden.

Schakel ondersteuning voor websockets in met behulp van de Azure CLI met de volgende opdracht:

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

Start de toepassing vervolgens opnieuw op:

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

Standaardtekencodering instellen

Maak in Azure Portal onder Toepassingsinstellingen voor de web-app een nieuwe app-instelling met de naam JAVA_OPTS waarde -Dfile.encoding=UTF-8.

U kunt de app-instelling ook configureren met behulp van de App Service Maven-invoegtoepassing. Voeg de instellingsnaam en waardetags toe in de configuratie van de invoegtoepassing:

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

JSP-bestanden vooraf compileren

Om de prestaties van Tomcat-toepassingen te verbeteren, kunt u uw JSP-bestanden compileren voordat u implementeert in App Service. U kunt de Maven-invoegtoepassing van Apache Sling gebruiken of dit Ant-buildbestand gebruiken.

Het robots933456-bericht negeren in logboeken

Mogelijk ziet u het volgende bericht in de containerlogboeken:

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

U kunt dit bericht veilig negeren. /robots933456.txt is een dummy-URL-pad dat App Service gebruikt om te controleren of de container aanvragen kan verwerken. Een 404-antwoord geeft aan dat het pad niet bestaat en geeft aan App Service aan dat de container in orde is en klaar is om te reageren op aanvragen.

Een Java Runtime-versie kiezen

Met App Service kunnen gebruikers de primaire versie van de JVM kiezen, zoals Java 8 of Java 11, en de patchversie, zoals 1.8.0_232 of 11.0.5. U kunt er ook voor kiezen om de patchversie automatisch bij te werken naarmate er nieuwe secundaire versies beschikbaar komen. In de meeste gevallen moeten productie-apps gebruikmaken van vastgemaakte JVM-versies van patches, waardoor onverwachte storingen tijdens een automatische update van een patchversie worden voorkomen. Alle Java-web-apps gebruiken 64-bits JVM's en kunnen niet worden geconfigureerd.

Als u Tomcat gebruikt, kunt u ervoor kiezen om de patchversie van Tomcat vast te zetten. In Windows kunt u de patchversies van de JVM en Tomcat onafhankelijk vastmaken. Op Linux kunt u de patchversie van Tomcat vastzetten. De patchversie van de JVM is ook vastgemaakt, maar kan niet afzonderlijk worden geconfigureerd.

Als u ervoor kiest om de secundaire versie vast te maken, moet u de secundaire JVM-versie regelmatig bijwerken in de app. Maak een staging-slot aan en verhoog de subversie op het staging-slot om ervoor te zorgen dat uw toepassing op de nieuwere subversie draait. Nadat u hebt bevestigd dat de applicatie correct wordt uitgevoerd op de nieuwe kleine versie, kunt u de faserings- en productieslots omwisselen.

De JBoss CLI uitvoeren

In de SSH-sessie van uw JBoss EAP-app kunt u de JBoss CLI uitvoeren met de volgende opdracht:

$JBOSS_HOME/bin/jboss-cli.sh --connect

Afhankelijk van waar JBoss EAP zich in de levenscyclus van de server bevindt, kunt u mogelijk geen verbinding maken. Wacht een paar minuten en probeer het opnieuw. Deze methode is handig voor snelle controles van de huidige serverstatus (bijvoorbeeld om te zien of een gegevensbron juist is geconfigureerd).

Wijzigingen die u aanbrengt in de server met de JBoss CLI in de SSH-sessie, blijven ook niet behouden nadat de app opnieuw is opgestart. Telkens wanneer de app wordt gestart, begint de JBoss EAP-server met een schone installatie. Tijdens de opstartlevenscyclus maakt App Service de benodigde serverconfiguraties en implementeert de app. Als u permanente wijzigingen wilt aanbrengen in de JBoss EAP-server, gebruikt u een aangepast opstartscript of een opstartopdracht. Zie Gegevensbronnen configureren voor een Java SE-, Tomcat- of JBoss EAP-app in Azure App Service voor een end-to-end-voorbeeld.

U kunt App Service ook handmatig configureren om elk bestand uit te voeren bij het opstarten. Voorbeeld:

az webapp config set --resource-group <group-name> --name <app-name> --startup-file /home/site/scripts/foo.sh

Zie voor meer informatie over de CLI-opdrachten die u kunt uitvoeren:

Clusteranalyse

App Service ondersteunt clustering voor JBoss EAP-versies 7.4.1 en hoger. Als u clustering wilt inschakelen, moet uw web-app worden geïntegreerd met een virtueel netwerk. Wanneer de web-app is geïntegreerd met een virtueel netwerk, wordt deze opnieuw opgestart en wordt de JBoss EAP-installatie automatisch gestart met een geclusterde configuratie. Wanneer u meerdere exemplaren uitvoert met automatisch schalen, communiceren de JBoss EAP-exemplaren met elkaar via het subnet dat is opgegeven in de integratie van het virtuele netwerk. U kunt clustering uitschakelen door een app-instelling te maken met een willekeurige WEBSITE_DISABLE_CLUSTERING waarde.

Een diagram met een in een virtueel netwerk geïntegreerd JBoss EAP App Service-app, uitgeschaald naar drie exemplaren.

Notitie

Als u de integratie van uw virtuele netwerk met een ARM-sjabloon inschakelt, moet u de eigenschap vnetPrivatePorts handmatig instellen op een waarde van 2. Als u integratie van virtuele netwerken vanuit de CLI of portal inschakelt, wordt deze eigenschap automatisch voor u ingesteld.

Wanneer clustering is ingeschakeld, gebruiken de JBoss EAP-exemplaren het FILE_PING JGroups-detectieprotocol om nieuwe exemplaren te detecteren en clustergegevens te behouden (bijvoorbeeld: de clusterleden, hun id's en hun IP-adressen). In App Service bevinden deze bestanden zich onder /home/clusterinfo/. Het eerste EAP-exemplaar om te beginnen krijgt lees-/schrijfmachtigingen voor het clusterlidmaatschapsbestand. Andere exemplaren lezen het bestand, zoeken het primaire knooppunt en coördineren met dat knooppunt zodat zij in het cluster worden opgenomen en aan het bestand worden toegevoegd.

Notitie

U kunt time-outs voor JBoss EAP-clustering voorkomen door verouderde detectiebestanden op te schonen tijdens het opstarten van uw app.

De typen Premium V3- en Premium V4- en Isolated V2 App Service-abonnementen kunnen eventueel worden gedistribueerd over beschikbaarheidszones om de tolerantie en betrouwbaarheid voor uw bedrijfskritieke workloads te verbeteren. Deze architectuur wordt ook wel zoneredundantie genoemd. De JBoss EAP-clusterfunctie is compatibel met de functie zoneredundantie.

Regels voor automatische schaalvergroting

Wanneer u regels voor automatische schaalaanpassing configureert voor horizontaal schalen, is het belangrijk dat u exemplaren incrementeel (één voor één) verwijdert om ervoor te zorgen dat elk verwijderd exemplaar de activiteit kan overdragen (zoals het verwerken van een databasetransactie) naar een ander lid van het cluster. Wanneer u uw regels voor automatische schaalaanpassing in de portal configureert om omlaag te schalen, gebruikt u de volgende opties:

  • Bewerking: 'Aantal verminderen met'
  • Afkoelen: '5 minuten' of hoger
  • Aantal exemplaren: 1

U hoeft geen exemplaren incrementeel toe te voegen (uitschalen). U kunt meerdere exemplaren tegelijk toevoegen aan het cluster.

App Service-plannen

JBoss EAP is beschikbaar in de volgende prijscategorieën: F1, P0v3, P1mv3, P2mv3, P3mv3, P4mv3, P5mv3, P0v4, P1mv4, P2mv4, P3mv4, P4mv4 en P5mv4.

Levenscyclus van JBoss EAP-server

Een JBoss EAP-app in App Service doorloopt vijf verschillende fasen voordat de server wordt gestart:

  1. Opbouwfase van de omgeving
  2. Serverlanceringsfase
  3. Serverconfiguratiefase
  4. Implementatiefase van app
  5. Fase voor het opnieuw laden van de server

Zie de volgende secties voor meer informatie en mogelijkheden om aan te passen (zoals via app-instellingen).

1. Installatiefase van de omgeving

  • De SSH-service wordt gestart om beveiligde SSH-sessies met de container in te schakelen.
  • De Java Runtime-sleutelopslag wordt bijgewerkt met alle openbare en persoonlijke certificaten die zijn gedefinieerd in Azure Portal.
    • Openbare certificaten worden geleverd door het platform in de /var/ssl/certs map en worden geladen in $JRE_HOME/lib/security/cacerts.
    • Privécertificaten worden geleverd door het platform in de /var/ssl/private map en worden geladen in $JRE_HOME/lib/security/client.jks.
  • Als er in deze stap certificaten in het Java-sleutelarchief worden geladen, worden de eigenschappen javax.net.ssl.keyStoreen javax.net.ssl.keyStorePasswordjavax.net.ssl.keyStoreType toegevoegd aan de JAVA_OPTS omgevingsvariabele.
  • Sommige initiële JVM-configuratie wordt bepaald, zoals logboekmappen en heap-parameters voor Java-geheugen:
    • Als u de –Xms of –Xmx vlaggen voor geheugen in de app-instelling JAVA_OPTSopgeeft, overschrijven deze waarden de waarden die door het platform worden geleverd.
    • Als u de app-instelling WEBSITES_CONTAINER_STOP_TIME_LIMITconfigureert, wordt de waarde doorgegeven aan de runtime-eigenschap org.wildfly.sigterm.suspend.timeout, waarmee de maximale wachttijd voor afsluiten (in seconden) wordt bepaald wanneer JBoss EAP wordt gestopt.
  • Als de app is geïntegreerd met een virtueel netwerk, geeft de App Service-runtime een lijst met poorten door die moeten worden gebruikt voor communicatie tussen servers in de omgevingsvariabele WEBSITE_PRIVATE_PORTS en start JBoss EAP met behulp van de clustering configuratie. Anders wordt de standalone configuratie gebruikt.
    • Voor de clustering configuratie wordt het serverconfiguratiebestand standalone-azure-full-ha.xml gebruikt.
    • Voor de standalone configuratie wordt het serverconfiguratiebestand standalone-full.xml gebruikt.

2. Startfase van de server

  • Als JBoss EAP wordt gestart in de clustering configuratie:
    • Elk JBoss EAP-exemplaar ontvangt een interne identificatie tussen 0 en het aantal exemplaren waarnaar de app wordt opgeschaald.
    • Als er bestanden worden gevonden in het transactiearchiefpad voor dit serverexemplaar (met behulp van de interne identificatie), betekent dit dat deze serverinstantie de plaats inneemt van een identieke service-instantie. Het andere service-exemplaar is eerder gecrasht en heeft niet-doorgevoerde transacties achtergelaten. De server is geconfigureerd om het werk voor deze transacties te hervatten.
  • Ongeacht of JBoss EAP in de clustering of standalone configuratie wordt gestart, als de serverversie 7.4 of hoger is en de runtime Java 17 gebruikt, wordt de configuratie bijgewerkt om het Elytron-subsysteem in te schakelen voor beveiliging.
  • Als u de app-instelling WEBSITE_JBOSS_OPTSconfigureert, wordt de waarde doorgegeven aan het JBoss-startprogrammascript. Deze instelling kan worden gebruikt om paden naar eigenschapsbestanden en meer vlaggen te bieden die van invloed zijn op het opstarten van JBoss EAP.

3. Serverconfiguratiefase

  • Aan het begin van deze fase wacht App Service eerst op zowel de JBoss EAP-server als de beheerinterface om aanvragen te ontvangen voordat u doorgaat. Dit proces kan enkele seconden duren als Application Insights is ingeschakeld.

  • Wanneer zowel JBoss EAP Server als de beheerinterface gereed zijn, voert App Service de volgende acties uit:

    • Voegt de JBoss EAP-module azure.appservicetoe, die hulpprogrammaklassen biedt voor logboekregistratie en integratie met App Service.
    • Werkt de consolelogger bij om een modus zonder kleur te gebruiken, zodat logboekbestanden niet vol zijn met kleuren-escapesequenties.
    • Hiermee stelt u de integratie met Azure Monitor-logboeken in.
    • Hiermee worden de binding-IP-adressen van de WSDL-interfaces (Web Services Description Language) en beheerinterfaces bijgewerkt.
    • Voegt de JBoss EAP-module azure.appservice.easyauth toe voor integratie met App Service-verificatie en Microsoft Entra-id.
    • Hiermee werkt u de logboekconfiguratie van toegangslogboeken en de naam en rotatie van het logboekbestand van de hoofdserver bij.

  • Tenzij de app-instelling WEBSITE_SKIP_AUTOCONFIGURE_DATABASE is gedefinieerd, worden JDBC-URL's (Java Database Connectivity) automatisch gedetecteerd in de App Service-app-instellingen. Als er geldige JDBC-URL's bestaan voor PostgreSQL, MySQL, MariaDB, Oracle, SQL Server of Azure SQL Database, worden de bijbehorende stuurprogramma's toegevoegd aan de server, wordt er een gegevensbron toegevoegd voor elk van de JDBC-URL's en wordt de JNDI-naam (Java Naming and Directory Interface) voor elke gegevensbron java:jboss/env/jdbc/<app-setting-name>_DSingesteld op , waar <app-setting-name> is de naam van de app-instelling.

  • Als de clustering configuratie is ingeschakeld, wordt de te configureren consolelogger gecontroleerd.

  • Als er JAR-bestanden zijn geïmplementeerd in de /home/site/libs map, wordt er een nieuwe globale module gemaakt met al deze JAR-bestanden.

  • Aan het einde van de fase voert App Service het aangepaste opstartscript uit, indien aanwezig. De zoeklogica voor het aangepaste opstartscript wordt als volgt gedefinieerd:

    • Als u een opstartopdracht hebt geconfigureerd (bijvoorbeeld via Azure Portal of de Azure CLI), voert u deze uit; anders
    • Als het pad /home/site/scripts/startup.sh bestaat, gebruikt u het; anders,
    • Als het pad /home/startup.sh bestaat, gebruikt u het.

De aangepaste opstartopdracht of het aangepaste script wordt uitgevoerd als hoofdgebruiker (niet nodig sudo), zodat ze Linux-pakketten kunnen installeren of de JBoss CLI kunnen starten om meer JBoss EAP-installatie-/aanpassingsopdrachten uit te voeren, zoals het maken van gegevensbronnen en het installeren van resourceadapters. Zie de Ubuntu Server-documentatie voor informatie over Ubuntu-pakketbeheeropdrachten. Zie de JBoss Management CLI-handleiding voor JBoss CLI-opdrachten.

4. Implementatiefase van app

Apps worden door het opstartscript geïnstalleerd in JBoss EAP door te zoeken in de volgende locaties, in volgorde van prioriteit:

  • Als u de app-instelling WEBSITE_JAVA_WAR_FILE_NAMEhebt geconfigureerd, implementeert u het bestand dat is opgegeven.
  • Als /home/site/wwwroot/app.war bestaat, roll deze uit.
  • Indien er andere EAR- en WAR-bestanden aanwezig zijn /home/site/wwwroot, zet deze in.
  • Als /home/site/wwwroot/webapps bestaat, rol de bestanden en mappen erin uit. WAR-bestanden worden geïmplementeerd als zelfstandige toepassingen en directory's worden geïmplementeerd als "exploded" (niet-gecomprimeerde) web-apps.
  • Als er zelfstandige JSP-pagina's aanwezig zijn /home/site/wwwroot, kopieert u deze naar de hoofdmap van de webserver en implementeert u deze als één web-app.
  • Als er geen implementeerbare bestanden worden gevonden, implementeert u de standaard welkomstpagina (parkeerpagina) in de hoofdcontext.

5. Herlaadfase van de server

  • Nadat de implementatiestappen zijn voltooid, wordt de JBoss EAP-server opnieuw geladen om wijzigingen toe te passen waarvoor een server opnieuw moet worden geladen.
  • Nadat de server opnieuw is geladen, moeten de toepassingen die zijn geïmplementeerd op de JBoss EAP-server gereed zijn om te reageren op aanvragen.
  • De server wordt uitgevoerd totdat de App Service-app is gestopt of opnieuw wordt opgestart. U kunt de App Service-app handmatig stoppen of opnieuw starten, of u activeert een herstart wanneer u bestanden implementeert of configuratiewijzigingen aanbrengt in de App Service-app.
  • Als de JBoss EAP-server abnormaal wordt afgesloten in de clustering configuratie, wordt een laatste functie, genaamd emit_alert_tx_store_not_empty, uitgevoerd. De functie controleert of het JBoss EAP-proces een niet-lege transactieopslagbestand op schijf heeft achtergelaten. Zo ja, dan wordt er een fout vastgelegd in de console: Error: finishing server with non-empty store for node XXXX. Wanneer een nieuwe serverinstantie wordt gestart, zoekt het naar deze niet-lege transactieopslagbestanden om het werk te hervatten (zie 2. Startfase van de server).

Tomcat basisconfiguratie

Notitie

Deze sectie is alleen van toepassing op Linux.

Java-ontwikkelaars kunnen de serverinstellingen aanpassen, problemen oplossen en toepassingen met vertrouwen implementeren in Tomcat als ze weten wat de server.xml bestand- en configuratiedetails van Tomcat zijn. Mogelijke aanpassingen zijn:

  • Tomcat-configuratie aanpassen: wanneer u de server.xml bestand en de configuratiegegevens van Tomcat begrijpt, kunt u de serverinstellingen aanpassen aan de behoeften van hun toepassingen.
  • Foutopsporing: wanneer een toepassing wordt geïmplementeerd op een Tomcat-server, moeten ontwikkelaars weten wat de serverconfiguratie is om eventuele problemen op te sporen. Dit proces omvat het controleren van de serverlogboeken, het onderzoeken van de configuratiebestanden en het identificeren van eventuele fouten die kunnen optreden.
  • Problemen met Tomcat oplossen: Onvermijdelijk ondervinden Java-ontwikkelaars problemen met hun Tomcat-server, zoals prestatieproblemen of configuratiefouten. Wanneer u inzicht krijgt in het server.xml-bestand en de configuratiegegevens van Tomcat, kunnen ontwikkelaars deze problemen snel diagnosticeren en oplossen, waardoor tijd en moeite kunnen worden bespaard.
  • Toepassingen implementeren in Tomcat: ontwikkelaars moeten weten hoe ze het server.xml-bestand en andere Tomcat-instellingen moeten configureren om een Java-webtoepassing te implementeren in Tomcat. U moet deze details begrijpen om toepassingen succesvol te implementeren en ervoor te zorgen dat ze probleemloos op de server worden uitgevoerd.

Wanneer u een app met ingebouwde Tomcat maakt om uw Java-workload (een WAR-bestand of een JAR-bestand) te hosten, zijn er bepaalde instellingen die u uit het vak voor Tomcat-configuratie haalt. Raadpleeg de officiële Apache Tomcat-documentatie voor gedetailleerde informatie, waaronder de standaardconfiguratie voor Tomcat-webserver.

Daarnaast zijn er bepaalde transformaties die bovenop de server.xml van de Tomcat-distributie bij het opstarten worden toegepast. Deze transformaties omvatten wijzigingen in de connector-, host- en klepinstellingen .

De nieuwste versies van Tomcat hebben server.xml (8.5.58 en 9.0.38 en hoger). Oudere versies van Tomcat gebruiken geen transformaties en hebben mogelijk ander gedrag als gevolg.

Verbindingsstuk

<Connector port="${port.http}" address="127.0.0.1" maxHttpHeaderSize="16384" compression="on" URIEncoding="UTF-8" connectionTimeout="${site.connectionTimeout}" maxThreads="${catalina.maxThreads}" maxConnections="${catalina.maxConnections}" protocol="HTTP/1.1" redirectPort="8443"/>
  • maxHttpHeaderSize is ingesteld op 16384.
  • URIEncoding is ingesteld op UTF-8.
  • connectionTimeout is ingesteld op WEBSITE_TOMCAT_CONNECTION_TIMEOUT, wat standaard 240000 is.
  • maxThreads is ingesteld op WEBSITE_CATALINA_MAXTHREADS, wat standaard 200 is.
  • maxConnections is ingesteld op WEBSITE_CATALINA_MAXCONNECTIONS, wat standaard 10000 is.

Notitie

De instellingen connectionTimeout, maxThreads en maxConnections kunnen worden afgestemd met de app-instellingen.

Hieronder vindt u voorbeelden van CLI-commando's die u kunt gebruiken om de waarden van connectionTimeout, maxThreads, of maxConnections te wijzigen.

az webapp config appsettings set --resource-group myResourceGroup --name myApp --settings WEBSITE_TOMCAT_CONNECTION_TIMEOUT=120000

az webapp config appsettings set --resource-group myResourceGroup --name myApp --settings WEBSITE_CATALINA_MAXTHREADS=100

az webapp config appsettings set --resource-group myResourceGroup --name myApp --settings WEBSITE_CATALINA_MAXCONNECTIONS=5000

Connector gebruikt het adres van de container in plaats van 127.0.0.1.

Gastheer

<Host appBase="${site.appbase}" xmlBase="${site.xmlbase}" unpackWARs="${site.unpackwars}" workDir="${site.tempdir}" errorReportValveClass="com.microsoft.azure.appservice.AppServiceErrorReportValve" name="localhost" autoDeploy="true">
  • appBase is ingesteld op AZURE_SITE_APP_BASE, wat standaard is ingesteld op lokaal WebappsLocalPath.
  • xmlBase is ingesteld op AZURE_SITE_HOME, wat standaard /site/wwwroot is.
  • unpackWARs is ingesteld op AZURE_UNPACK_WARS, wat standaard true is.
  • workDir is ingesteld op JAVA_TMP_DIR, dat TMP op standaardwaarden instelt.
  • errorReportValveClass maakt gebruik van onze unieke foutmeldingsklep.

Ventiel

<Valve prefix="site_access_log.${catalina.instance.name}" pattern="%h %l %u %t &quot;%r&quot; %s %b %D %{x-arr-log-id}i" directory="${site.logdir}/http/RawLogs" maxDays="${site.logRetentionDays}" className="org.apache.catalina.valves.AccessLogValve" suffix=".txt"/>
  • directory is ingesteld op AZURE_LOGGING_DIR, wat standaard home\logFiles is.
  • maxDays is ingesteld op WEBSITE_HTTPLOGGING_RETENTION_DAYS, wat standaard 7 is. Deze waarde komt overeen met het standaardplatform voor toepassingslogboekregistratie.

In Linux heeft het allemaal dezelfde aanpassing en voegt het enkele fout- en rapportagepagina's toe aan de klep:

<xsl:attribute name="appServiceErrorPage">
    <xsl:value-of select="'${appService.valves.appServiceErrorPage}'"/>
</xsl:attribute>

<xsl:attribute name="showReport">
    <xsl:value-of select="'${catalina.valves.showReport}'"/>
</xsl:attribute>

<xsl:attribute name="showServerInfo">
    <xsl:value-of select="'${catalina.valves.showServerInfo}'"/>
</xsl:attribute>

Verwante inhoud

Ga naar het Azure voor Java-ontwikkelaarscentrum om azure-snelstartgidsen, zelfstudies en Java-referentiedocumentatie te vinden.