Dela via

Distribuera och konfigurera en Java SE-, Tomcat- eller JBoss EAP-app i Azure App Service

Den här artikeln visar den vanligaste distributions- och körningskonfigurationen för Java-appar i Azure App Service. Om det är första gången du använder Azure App Service bör du först läsa igenom Java-snabbstarten. Du hittar svaren på allmänna frågor om hur du använder App Service som inte är specifika för Java-utveckling i Vanliga frågor och svar om App Service.

Azure App Service kör Java-webbprogram på en fullständigt hanterad tjänst i tre varianter:

  • Java Standard Edition (SE): Kan köra en app som distribueras som ett Java Archive-paket (JAR) som innehåller en inbäddad server (till exempel Spring Boot, Quarkus, Dropwizard eller en app med en inbäddad Tomcat- eller Jetty-server).
  • Tomcat: Den inbyggda Tomcat-servern kan köra en app som distribueras som ett WAR-paket (Web Application Archive).
  • JBoss Enterprise Application Platform (EAP): Den inbyggda JBoss EAP-servern kan köra en app som distribueras som ett WAR- eller företagsarkivpaket (EAR). Stöds för Linux-appar i en uppsättning prisnivåer som innehåller Kostnadsfri, Premium v3 och Isolerad v2.gti

Visa Java-version

Om du vill visa den aktuella Java-versionen kör du följande kommando i Azure Cloud Shell:

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

Om du vill visa alla Java-versioner som stöds kör du följande kommando i Cloud Shell:

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

Få Java-versionen i Linux-containern

Om du vill ha mer detaljerad versionsinformation i Linux-containern öppnar du en SSH-session med containern. Här är några exempel på vad du kan köra.

Så här visar du Java-versionen i SSH-sessionen:

java -version

Så här visar du Tomcat-serverversionen i SSH-sessionen:

sh /usr/local/tomcat/version.sh

Eller om Tomcat-servern finns på en anpassad plats kan du hitta version.sh med:

find / -name "version.sh"

Så här visar du JBoss EAP-serverversionen i SSH-sessionen:

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

Mer information om versionsstöd finns i Stödpolicy för språkramverk i App Service.

Vad händer med inaktuella körmiljöer i App Service?

Inaktuella körningsmiljöer avvecklas av den underhållande organisationen eller har visat sig ha betydande säkerhetsrisker. Därför tas de bort från skapa och konfigurera sidor i portalen. När en föråldrad runtime är dold från portalen fortsätter alla appar som fortfarande använder den att köra.

Om du vill skapa en app med en inaktuell körningsversion som inte längre visas på portalen använder du Azure CLI, ARM-mallen eller Bicep. Med de här distributionsalternativen kan du skapa inaktuella körmiljöer som har tagits bort i portalen, men som fortfarande stöds.

Om en runtime tas bort helt från App Service-plattformen får ägaren till din Azure-prenumeration ett e-postmeddelande innan borttagningen.

Att sätta igång din app

Byggverktyg

Maven

Genom att använda Plugin-programmet Maven för Azure Web Apps kan du enkelt förbereda projektet med ett kommando i projektroten:

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

Det här kommandot lägger till ett azure-webapp-maven-plugin plugin-program och den relaterade konfigurationen genom att uppmana dig att välja en befintlig Azure-webbapp eller skapa en ny. Under konfigurationen försöker den identifiera om ditt program ska distribueras till Java SE, Tomcat eller (endast Linux) JBoss EAP. Sedan kan du distribuera din Java-app till Azure med hjälp av följande kommando:

mvn package azure-webapp:deploy

Här är en exempelkonfiguration i 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. Konfigurera Gradle-plugin-programmet för Azure Web Apps genom att lägga till plugin-programmet i build.gradle:

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

  2. Konfigurera dina webbappdetaljer. Motsvarande Azure-resurser skapas om de inte finns. Här är en exempelkonfiguration. Mer information finns i det här dokumentet.

    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. Distribuera med ett kommando.

    gradle azureWebAppDeploy

IDE:er

Azure tillhandahåller sömlös Java App Service-utvecklingsupplevelse i populära Java Integrated Development Environments (IDE: er), inklusive:

Api:er för Kudu och OneDeploy

Distributionsklienter som Plugin-programmet Maven, GitHub Actions med azure/webapps-deploy@v3 och senare, eller kommandot az webapp deploy använder OneDeploy, som anropas genom att anropa /api/publish slutpunkten för Kudu-webbplatsen i bakgrunden. Mer information om det här API:et finns i den här dokumentationen.

När dessa distributionsmetoder används byter de automatiskt namn på den angivna JAR-filen till app.jar under distributionsprocessen. Detta placeras under /home/site/wwwwroot. Information om hur du distribuerar JAR-filer till Java SE finns i den här dokumentationen.

Anmärkning

Om du använder alternativa metoder som FTP eller äldre ZipDeploy-API:er anropas inte den här metoden för att byta namn på den angivna JAR-filen. Anteckna detta om du använder textrutan Startfil i avsnittet Konfiguration i portalen för att uttryckligen anropa JAR-filen.

Du kan distribuera WAR-filer till ditt Tomcat-program genom att följa den här dokumentationen. När dessa distributionsmetoder ovan används byter de automatiskt namn på den angivna War-filen till app.war under distributionsprocessen. Detta placeras under /home/site/wwwwroot och stöder som standard endast distribution av en WAR-fil under wwwroot. Detta placeras inte under den /home/site/wwwroot/webapps katalog som visas när du använder distributions-API:er som WarDeploy. För att undvika problem med filstrukturkonflikter rekommenderar vi att du endast använder den ena eller den andra distributionstypen.

Information om hur du distribuerar WAR-filer till JBoss EAP finns i den här dokumentationen. När OneDeploy används byter detta automatiskt namn på WAR-filen till app.war och placeras under /home/site/wwwroot.

Om du vill distribuera EAR-filer använder du FTP. DITT EAR-program distribueras till kontextroten som definierats i programmets konfiguration. Om du vill att webbappen ska levereras i rotsökvägen ska du säkerställa att appen ställer in kontextroten till rotsökvägen: <context-root>/</context-root>. Mer information finns i Ange kontextroten för ett webbprogram.

Distribuera inte war- eller JAR-filen med hjälp av FTP. FTP-verktyget är utformat för att ladda upp startskript, beroenden eller andra körningsfiler. Det är inte det optimala valet för att distribuera webbappar.

Skriva om eller omdirigera en URL

Om du vill skriva om eller omdirigera en URL använder du någon av de tillgängliga URL-skrivarna, till exempel UrlRewriteFilter.

Tomcat tillhandahåller också en omskrivningsventil.

JBoss EAP tillhandahåller också en omskrivningsventil.

Logga och felsöka appar

Prestandarapporter, trafikvisualiseringar och hälsokontroller är tillgängliga för varje app via Azure Portal. Mer information finns i Översikt över Azure App Service-diagnostik.

Strömma diagnostiska loggar

Du kan komma åt konsolloggarna som genereras inifrån containern.

Om du vill aktivera containerloggning kör du följande kommando:

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

Ersätt <app-name> och <resource-group-name> med namn som är lämpliga för din webbapp.

När du har aktiverat containerloggning kör du följande kommando för att se loggströmmen:

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

Om konsolloggarna inte visas omedelbart kontrollerar du igen om 30 sekunder.

Om du vill stoppa loggströmningen när som helst väljer du Ctrl+C.

Mer information finns i Stream-loggar i Cloud Shell.

SSH-konsolåtkomst i Linux

Om du vill öppna en direkt SSH-session med containern bör appen köras.

Använd kommandot az webapp ssh .

Om du inte redan har autentiserats måste du autentisera dig med din Azure-prenumeration för att kunna ansluta. När autentiseringen är klar visas ett gränssnitt i webbläsaren där du kan köra kommandon i containern.

SSH-anslutning

Anmärkning

Alla ändringar som du gör utanför /home katalogen lagras i själva containern och sparas inte längre än en appomstart.

Information om hur du öppnar en fjärr-SSH-session från den lokala datorn finns i Öppna SSH-session från fjärrgränssnittet.

Felsökningsverktyg för Linux

De inbyggda Java-avbildningarna baseras på operativsystemet Alpine Linux . apk Använd pakethanteraren för att installera felsökningsverktyg eller kommandon.

Java-profilerare

Alla Java-körningar i Azure App Service levereras med JDK(Java Development Kit) Flight Recorder för profilering av Java-arbetsbelastningar. Du kan använda den för att registrera JVM(Java Virtual Machine), system- och programhändelser och för att felsöka problem i dina program.

Mer information om Java-profileraren finns i Dokumentationen om Azure Application Insights.

Java Flight Recorder

Alla Java-runtime på App Service finns med Java Flight Recorder. Du kan använda den för att registrera JVM-, system- och programhändelser och för att felsöka problem i dina Java-program.

SSH till App Service och kör jcmd kommandot för att se en lista över alla Java-processer som körs. Förutom jcmd sig själv bör du se ditt Java-program köras med ett process-ID-nummer (PID).

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

Kör följande kommando för att starta en 30-sekunders inspelning av JVM. Den profilerar JVM och skapar en JFR-fil (Java Flight Recorder) med namnet jfr_example.jfr i hemkatalogen. Ersätt 116 med PID för din Java-app.

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

Under 30-sekundersintervallet kan du verifiera att inspelningen sker genom att köra jcmd 116 JFR.check. Kommandot visar alla inspelningar för den angivna Java-processen.

Kontinuerlig inspelning

Du kan använda Java Flight Recorder för att kontinuerligt profilera ditt Java-program med minimal påverkan på körningsprestanda. Det gör du genom att köra följande Azure CLI-kommando för att skapa en appinställning med namnet JAVA_OPTS med nödvändig konfiguration. Innehållet i appinställningen JAVA_OPTSjava skickas till kommandot när appen startar.

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

När inspelningen har startat kan du när som helst dumpa aktuella inspelningsdata med hjälp JFR.dump av kommandot .

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

Analysera JFR-filer

Använd FTPS för att ladda ned JFR-filen till den lokala datorn. Om du vill analysera JFR-filen laddar du ned och installerar Java Mission Control (JMC). Anvisningar om hur du använder Java Mission Control finns i JMC-dokumentationen och installationsanvisningarna.

Applikationsloggning

Gör följande för att konfigurera App Service för att skriva ut din applikations standardkonsolutmatning och standardkonsolfelmeddelanden till det lokala filsystemet eller Azure Blob Storage. Aktivera programloggning via Azure-portalen eller i Azure CLI. Om du behöver längre kvarhållning konfigurerar du programmet för att skriva utdata till en Blob Storage-container.

Dina Java- och Tomcat-apploggar finns i /home/LogFiles/Application/ katalogen.

Azure Blob Storage-loggning för Linux-baserade appar kan endast konfigureras med hjälp av Azure Monitor.

Om ditt program använder Logback eller Log4j för spårning kan du vidarebefordra dessa spårningar för granskning till Azure Application Insights. Använd konfigurationsinstruktionerna för loggningsramverket i Utforska Java-spårningsloggar i Application Insights.

Anmärkning

På grund av kända säkerhetsrisker CVE-2021-44228bör du använda Log4j version 2.16 eller senare.

Anpassning och justering

Azure App Service stöder out-of-the-box-justering och anpassning via Azure-portalen och Azure CLI. Läs följande artiklar om konfiguration av icke-Java-specifika webbappar:

Kopiera appinnehåll lokalt

Ange appinställningen JAVA_COPY_ALL till true för att kopiera appinnehållet till den lokala arbetaren från det delade filsystemet. Den här inställningen hjälper dig att åtgärda problem med fillåsning.

Ange Java-körningsalternativ

Om du vill ange allokerat minne eller andra JVM-körningsalternativ skapar du en appinställning med namnet JAVA_OPTS med alternativen. App Service skickar den här inställningen som en miljövariabel till Java-körningen när den startas.

I Azure-portalen, under Programinställningar för webbappen, skapar du en ny appinställning med namnet JAVA_OPTS som innehåller andra inställningar, till exempel -Xms512m -Xmx1204m.

I Azure-portalen, under Programinställningar för webbappen, skapar du en ny appinställning med namnet CATALINA_OPTS som innehåller andra inställningar, till exempel -Xms512m -Xmx1204m.

Om du vill konfigurera appinställningen från Plugin-programmet Maven lägger du till inställnings-/värdetaggar i avsnittet Azure-plugin-program. I följande exempel anges en specifik minsta och högsta Java-heapstorlek:

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

Anmärkning

Du behöver inte skapa en web.config-fil när du använder Tomcat i Windows App Service.

Som standard anger App Service JVM Max Heap-storleken till 70% av det totala tillgängliga minnet för App Service-planen. Om du vill inaktivera standardinställningen kan du använda appinställningen WEBSITE_DISABLE_JAVA_HEAP_CONFIGURATION="true".

Att förbättra programmets prestanda på plattformen kan innebära att justera heapstorleken så att den passar dina specifika behov bättre. När du justerar applikationens heap-inställningar, granska informationen om App Service-planen och ta hänsyn till kraven för flera applikationer och distributionsluckor för att hitta den optimala minnesallokeringen.

Aktivera webbsocketer

Aktivera stöd för webb socketar i Azure-portalen i programmets programinställningar . Du måste starta om programmet för att inställningen ska börja gälla.

Aktivera stöd för web socket med hjälp av Azure CLI med följande kommando:

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

Starta sedan om programmet:

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

Ange standardteckenkodning

I Azure-portalen under Programinställningar för webbappen skapar du en ny appinställning med namnet JAVA_OPTS med värdet -Dfile.encoding=UTF-8.

Du kan också konfigurera appinställningen med hjälp av Plugin-programmet App Service Maven. Lägg till inställningsnamnet och värdetaggar i plugin-konfigurationen:

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

Förkompilera JSP-filer

För att förbättra prestanda för Tomcat-program kan du kompilera dina JSP-filer innan du distribuerar till App Service. Du kan använda plugin-programmet Maven som tillhandahålls av Apache Sling eller använda den här Ant-byggfilen.

Ignorera robots933456-meddelandet i loggar

Du kan se följande meddelande i containerloggarna:

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

Du kan ignorera det här meddelandet. /robots933456.txt är en falsk URL-sökväg som App Service använder för att kontrollera om containern kan hantera förfrågningar. Ett 404-svar anger att sökvägen inte finns och signalerar till App Service att containern är felfri och redo att svara på begäranden.

Välj en Java-körningsversion

Med App Service kan användare välja huvudversionen av JVM, till exempel Java 8 eller Java 11, och korrigeringsversionen, till exempel 1.8.0_232 eller 11.0.5. Du kan också välja att uppdatera korrigeringsversionen automatiskt när nya delversioner blir tillgängliga. I de flesta fall bör produktionsappar använda låsta patchversioner av JVM, vilket förhindrar oväntade avbrott under en automatisk uppdatering av en patchversion. Alla Java-webbappar använder 64-bitars JVM:er och kan inte konfigureras.

Om du använder Tomcat kan du välja att fästa korrigeringsversionen av Tomcat. I Windows kan du fästa korrigeringsversionerna av JVM och Tomcat oberoende av varandra. I Linux kan du fästa korrigeringsversionen av Tomcat. Korrigeringsversionen av JVM är också fäst men kan inte konfigureras separat.

Om du väljer att låsa delversionen behöver du regelbundet uppdatera JVM-delversionen i appen. För att säkerställa att programmet körs på den nyare delversionen skapar du ett mellanlagringsfack och ökar delversionen på mellanlagringsplatsen. När du har bekräftat att applikationen körs korrekt på den nya mindre versionen kan du byta testplatsen och produktionsmiljön.

Kör JBoss CLI

I JBoss EAP-appens SSH-session kan du köra JBoss CLI med följande kommando:

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

Beroende på var JBoss EAP finns i serverns livscykel kanske du inte kan ansluta. Vänta några minuter och försök igen. Den här metoden är användbar för snabbkontroller av ditt aktuella servertillstånd (till exempel för att se om en datakälla är korrekt konfigurerad).

Dessutom sparas inte ändringar som du gör på servern med JBoss CLI i SSH-sessionen när appen startas om. Varje gång appen startas börjar JBoss EAP-servern med en ren installation. Under startlivscykeln gör App Service nödvändiga serverkonfigurationer och distribuerar appen. Om du vill göra beständiga ändringar på JBoss EAP-servern använder du ett anpassat startskript eller ett startkommando. Ett exempel från slutpunkt till slutpunkt finns i Konfigurera datakällor för en Java SE-, Tomcat- eller JBoss EAP-app i Azure App Service.

Du kan också konfigurera App Service manuellt för att köra valfri fil vid start. Till exempel:

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

Mer information om de CLI-kommandon som du kan köra finns i:

Klustring

App Service stöder klustring för JBoss EAP-versioner 7.4.1 och senare. För att aktivera klustring måste webbappen vara integrerad med ett virtuellt nätverk. När webbappen är integrerad med ett virtuellt nätverk startas den om och JBoss EAP-installationen startar automatiskt med en klustrad konfiguration. När du kör flera instanser med automatisk skalning kommunicerar JBoss EAP-instanserna med varandra via det undernät som anges i integreringen av det virtuella nätverket. Du kan inaktivera klustring genom att skapa en appinställning med namnet WEBSITE_DISABLE_CLUSTERING med valfritt värde.

Ett diagram som visar en virtuell nätverksintegrerad JBoss EAP App Service-app som skalas ut till tre instanser.

Anmärkning

Om du aktiverar integreringen av det virtuella nätverket med en ARM-mall måste du manuellt ange egenskapen vnetPrivatePorts till värdet 2. Om du aktiverar integrering av virtuella nätverk från CLI eller portalen anges den här egenskapen automatiskt.

När klustring är aktiverat använder FILE_PING JBoss EAP-instanserna JGroups-identifieringsprotokollet för att identifiera nya instanser och spara klusterinformation (till exempel klustermedlemmar, deras identifierare och deras IP-adresser). I App Service finns dessa filer under /home/clusterinfo/. Den första EAP-instansen som startar hämtar läs-/skrivbehörigheter för klustermedlemskapsfilen. Andra instanser läser filen, hittar den primära noden och koordinerar med den noden som ska ingå i klustret och läggs till i filen.

Anmärkning

Du kan undvika tidsgränser för JBoss EAP-klustring genom att rensa upp föråldrade identifieringsfiler under appstarten.

Typerna Premium V3, Premium V4 och Isolated V2 App Service Plan kan eventuellt distribueras mellan tillgänglighetszoner för att förbättra återhämtning och tillförlitlighet för dina affärskritiska arbetsbelastningar. Den här arkitekturen kallas även zonredundans. JBoss EAP-klustringsfunktionen är kompatibel med zonredundansfunktionen.

Regler för autoskalning

När du konfigurerar regler för automatisk skalning för horisontell skalning är det viktigt att ta bort instanser stegvis (en i taget) för att säkerställa att varje borttagen instans kan överföra sin aktivitet (till exempel hantering av en databastransaktion) till en annan medlem i klustret. Använd följande alternativ när du konfigurerar autoskalningsregler i portalen för nedskalning:

  • Åtgärd: "Minska antalet med"
  • Nedkylning: "5 minuter" eller mer
  • Antal instanser: 1

Du behöver inte stegvis lägga till instanser (skala ut). Du kan lägga till flera instanser i klustret i taget.

App Service-planer

JBoss EAP finns på följande prisnivåer: F1, P0v3, P1mv3, P2mv3, P3mv3, P4mv3, P5mv3, P0v4, P1mv4, P2mv4, P3mv4, P4mv4 och P5mv4.

JBoss EAP-serverlivscykel

En JBoss EAP-app i App Service genomgår fem olika faser innan servern startas:

  1. Miljöinställningsfas
  2. Serverstartfas
  3. Konfigurationsfas för server
  4. Distribueringsfas för app
  5. Serveromläsningsfasen

Se följande avsnitt för information och möjligheter att anpassa (till exempel via appinställningar).

1. Miljökonfigurationsfas

  • SSH-tjänsten startas för att aktivera säkra SSH-sessioner med containern.
  • Java Runtime-nyckelarkivet uppdateras med alla offentliga och privata certifikat som definieras i Azure-portalen.
    • Offentliga certifikat tillhandahålls av plattformen i /var/ssl/certs katalogen och de läses in till $JRE_HOME/lib/security/cacerts.
    • Privata certifikat tillhandahålls av plattformen i /var/ssl/private katalogen och de läses in till $JRE_HOME/lib/security/client.jks.
  • Om några certifikat läses in i Java-nyckelarkivet i det här steget läggs egenskaperna javax.net.ssl.keyStore, javax.net.ssl.keyStorePasswordoch javax.net.ssl.keyStoreType till i JAVA_OPTS miljövariabeln.
  • Vissa inledande JVM-konfigurationer bestäms, till exempel loggningskataloger och parametrar för Java-minnes-heapen.
    • Om du anger flaggorna –Xms eller –Xmx för minnet i appinställningen JAVA_OPTSåsidosätter dessa värden de som tillhandahålls av plattformen.
    • Om du konfigurerar appinställningen WEBSITES_CONTAINER_STOP_TIME_LIMITskickas värdet till egenskapen runtime org.wildfly.sigterm.suspend.timeout, som styr den maximala avstängningsväntetiden (i sekunder) när JBoss EAP stoppas.
  • Om appen är integrerad med ett virtuellt nätverk skickar App Service-körningen en lista över portar som ska användas för kommunikation mellan servrar i miljövariabeln WEBSITE_PRIVATE_PORTS och startar JBoss EAP med hjälp av konfigurationen clustering . Annars används konfigurationen standalone .
    • För konfigurationen clustering används serverkonfigurationsfilen standalone-azure-full-ha.xml .
    • För konfigurationen standalone används serverkonfigurationsfilen standalone-full.xml .

2. Fasen för serverstart

  • Om JBoss EAP startas i konfigurationen clustering :
    • Varje JBoss EAP-instans tar emot en intern identifierare mellan 0 och antalet instanser som appen skalas ut till.
    • Om vissa filer hittas i sökvägen till transaktionsarkivet för den här serverinstansen (med hjälp av dess interna identifierare) innebär det att den här serverinstansen äger platsen för en identisk tjänstinstans. Den andra tjänstinstansen kraschade tidigare och lämnade ogenomförda transaktioner bakom sig. Servern är konfigurerad för att återuppta arbetet med dessa transaktioner.
  • Oavsett om JBoss EAP startar i clustering eller standalone konfigurationen, om serverversionen är 7.4 eller senare och körningen använder Java 17, uppdateras konfigurationen för att aktivera Elytron-undersystemet för säkerhet.
  • Om du konfigurerar appinställningen WEBSITE_JBOSS_OPTSskickas värdet till JBoss-startskriptet. Den här inställningen kan användas för att ange sökvägar till egenskapsfiler och fler flaggor som påverkar starten av JBoss EAP.

3. Serverkonfigurationsfasen

  • I början av den här fasen väntar App Service först på att både JBoss EAP-servern och administratörsgränssnittet ska vara redo att ta emot begäranden innan du fortsätter. Den här processen kan ta några sekunder om Application Insights är aktiverat.

  • När både JBoss EAP-servern och administratörsgränssnittet är klara vidtar App Service följande åtgärder:

    • Lägger till JBoss EAP-modulen azure.appservice, som tillhandahåller verktygsklasser för loggning och integrering med App Service.
    • Uppdaterar konsolloggaren för att använda ett läge utan färg så att loggfilerna inte är fulla av färgstyrande sekvenser.
    • Konfigurerar integreringen med Azure Monitor-loggar.
    • Uppdaterar bindnings-IP-adresserna för WSDL (Web Services Description Language) och hanteringsgränssnitten.
    • Lägger till JBoss EAP-modulen azure.appservice.easyauth för integrering med App Service-autentisering och Microsoft Entra-ID.
    • Uppdaterar loggningskonfigurationen för åtkomstloggar och namn och rotation av huvudserverloggfilen.

  • Om inte appinställningen WEBSITE_SKIP_AUTOCONFIGURE_DATABASE har definierats identifierar App Service automatiskt JDBC-URL:er (Java Database Connectivity) i App Service-appinställningarna. Om det finns giltiga JDBC-URL:er för PostgreSQL, MySQL, MariaDB, Oracle, SQL Server eller Azure SQL Database lägger den till motsvarande drivrutiner till servern, lägger till en datakälla för var och en av JDBC-URL:erna och anger JNDI-namnet (Java Naming and Directory Interface) för varje datakälla till java:jboss/env/jdbc/<app-setting-name>_DS, där <app-setting-name> är namnet på appinställningen.

  • Om konfigurationen clustering är aktiverad kontrolleras den konsolloggare som ska konfigureras.

  • Om det finns JAR-filer som distribueras till /home/site/libs katalogen skapas en ny global modul med alla dessa JAR-filer.

  • I slutet av fasen kör App Service det anpassade startskriptet, om det finns ett sådant. Söklogik för det anpassade startskriptet definieras på följande sätt:

    • Om du har konfigurerat ett startkommando (till exempel via Azure-portalen eller Azure CLI) kör du det. annars
    • Om sökvägen /home/site/scripts/startup.sh finns använder du den, annars
    • Om sökvägen /home/startup.sh finns använder du den.

Det anpassade startkommandot eller skriptet körs som rotanvändare (inget behov av sudo), så att de kan installera Linux-paket eller starta JBoss CLI för att utföra fler JBoss EAP-installations-/anpassningskommandon som att skapa datakällor och installera resurskort. Information om Ubuntu-pakethanteringskommandon finns i Ubuntu Server-dokumentationen. JBoss CLI-kommandon finns i CLI-guiden för JBoss-hantering.

4. Fas för appdistribution

Startskriptet distribuerar appar till JBoss EAP genom att titta på följande platser i prioritetsordning:

  • Om du har konfigurerat appinställningen WEBSITE_JAVA_WAR_FILE_NAMEdistribuerar du filen som den har angett.
  • Om /home/site/wwwroot/app.war finns, distribuera det.
  • Om det finns andra EAR- och WAR-filer i /home/site/wwwrootdistribuerar du dem.
  • Om /home/site/wwwroot/webapps finns, distribuera filerna och katalogerna i den. WAR-filer distribueras som program i sig själva, och kataloger distribueras som "okomprimerade" webbappar.
  • Om det finns några fristående JSP-sidor i /home/site/wwwrootkopierar du dem till webbserverroten och distribuerar dem som en webbapp.
  • Om inga distributionsbara filer hittas distribuerar du standardsidan för välkomstsidan (parkeringssidan) i rotkontexten.

5. Omlastningsfasen för servern

  • När distributionsstegen har slutförts läses JBoss EAP-servern in igen för att tillämpa alla ändringar som kräver att en server läses in igen.
  • När servern har lästs in igen bör de program som distribueras till JBoss EAP-servern vara redo att svara på begäranden.
  • Servern körs tills App Service-appen har stoppats eller startats om. Du kan stoppa eller starta om App Service-appen manuellt, eller så utlöser du en omstart när du distribuerar filer eller gör konfigurationsändringar i App Service-appen.
  • Om JBoss EAP-servern avslutas onormalt i konfigurationen clustering körs en slutlig funktion med namnet emit_alert_tx_store_not_empty . Funktionen kontrollerar om JBoss EAP-processen lämnade en icke-sparad transaktionsarkivfil på disken. I så fall loggas ett fel i konsolen: Error: finishing server with non-empty store for node XXXX. När en ny serverinstans startas letar den efter de här icke-tomma transaktionslagringsfilerna för att återuppta arbetet (se 2. Serverstartsfasen).

Konfiguration av Tomcat-baslinje

Anmärkning

Det här avsnittet gäller endast för Linux.

Java-utvecklare kan anpassa serverinställningarna, felsöka problem och distribuera program till Tomcat med säkerhet om de känner till server.xml fil- och konfigurationsinformation om Tomcat. Möjliga anpassningar är:

  • Anpassa Tomcat-konfigurationen: När du förstår server.xml-filen och Tomcats konfigurationsinformation kan du finjustera serverinställningarna så att de matchar behoven i deras program.
  • Felsökning: När ett program distribueras på en Tomcat-server måste utvecklarna känna till serverkonfigurationen för att felsöka eventuella problem som kan uppstå. Den här processen omfattar att kontrollera serverloggarna, undersöka konfigurationsfilerna och identifiera eventuella fel som kan uppstå.
  • Felsökning av Tomcat-problem: Java-utvecklare stöter oundvikligen på problem med sin Tomcat-server, till exempel prestandaproblem eller konfigurationsfel. När du förstår server.xml-filen och Tomcats konfigurationsinformation kan utvecklare snabbt diagnostisera och felsöka dessa problem, vilket kan spara tid och arbete.
  • Distribuera program till Tomcat: För att distribuera en Java-webbapp till Tomcat måste utvecklare veta hur de konfigurerar server.xml-filen och andra Tomcat-inställningar. Du måste förstå den här informationen för att distribuera program korrekt och se till att de fungerar smidigt på servern.

När du skapar en app med inbyggd Tomcat för att hantera din Java-arbetsbelastning (en WAR-fil eller en JAR-fil) finns det vissa inställningar som du får som standard för Tomcat-konfiguration. Du kan läsa den officiella Apache Tomcat-dokumentationen för detaljerad information, inklusive standardkonfigurationen för Tomcat Web Server.

Dessutom finns det vissa transformeringar som appliceras utöver server.xml för Tomcat-distribution vid uppstart. Dessa transformationer omfattar ändringar i inställningarna för Kopplare, Värd och Ventil.

De senaste versionerna av Tomcat har server.xml (8.5.58 och 9.0.38 och senare). Äldre versioner av Tomcat använder inte transformeringar och kan därför ha ett annat beteende.

Anslutning

<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 är inställt på 16384.
  • URIEncoding är inställt på UTF-8.
  • connectionTimeout är inställt på WEBSITE_TOMCAT_CONNECTION_TIMEOUT, som standard är 240000.
  • maxThreads är inställt på WEBSITE_CATALINA_MAXTHREADS, som standard är 200.
  • maxConnections är inställt på WEBSITE_CATALINA_MAXCONNECTIONS, som standard är 10000.

Anmärkning

connectionTimeoutInställningarna , maxThreadsoch maxConnections kan justeras med appinställningar.

Följande är exempel på CLI-kommandon som du kan använda för att ändra värdena connectionTimeoutför , maxThreadseller maxConnections:

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

Anslutningsappen använder containerns adress i stället för 127.0.0.1.

värd

<Host appBase="${site.appbase}" xmlBase="${site.xmlbase}" unpackWARs="${site.unpackwars}" workDir="${site.tempdir}" errorReportValveClass="com.microsoft.azure.appservice.AppServiceErrorReportValve" name="localhost" autoDeploy="true">
  • appBase är inställt på AZURE_SITE_APP_BASE, vilket som standard är satt till lokal WebappsLocalPath.
  • xmlBase är inställt på AZURE_SITE_HOME, som standard är /site/wwwroot.
  • unpackWARs är inställt på AZURE_UNPACK_WARS, som standard är true.
  • workDir är inställt på JAVA_TMP_DIR, vilket definierar standardinställningen för TMP.
  • errorReportValveClass använder vår anpassade felrapportsmekanism.

Ventil

<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 är inställt på AZURE_LOGGING_DIR, som standard är home\logFiles.
  • maxDays är inställt på WEBSITE_HTTPLOGGING_RETENTION_DAYS, som standard är 7. Det här värdet överensstämmer med standardvärdet för programloggningsplattformen.

I Linux har den samma anpassning och lägger till några fel- och rapporteringssidor i ventilen:

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

Relaterat innehåll

Besök Azure for Java Developers Center för att hitta Azure-snabbstarter, självstudier och Java-referensdokumentation.