Dela via

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

  • Artikel

Den här artikeln visar den vanligaste distributions- och körningskonfigurationen för Java-appar i App Service. Om du aldrig har använt Azure App Service bör du läsa igenom Java-snabbstarten först. Allmänna frågor om hur du använder App Service som inte är specifika för Java-utveckling besvaras 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 SE – Kan köra en app som distribueras som ett JAR-paket som innehåller en inbäddad server (till exempel Spring Boot, Dropwizard, Quarkus eller en med en inbäddad Tomcat- eller Jetty-server).
  • Tomcat – Den inbyggda Tomcat-servern kan köra en app som distribueras som ett WAR-paket.
  • JBoss EAP – Stöds endast för Linux-appar på prisnivåerna Kostnadsfri, Premium v3 och Isolerad v2. Den inbyggda JBoss EAP-servern kan köra en app som distribueras som ett WAR- eller EAR-paket.

Kommentar

För Spring-program rekommenderar vi att du använder Azure Spring Apps. Du kan dock fortfarande använda Azure App Service som mål. Mer information finns i Vägledning för Java-arbetsbelastningsmål.

Visa Java-version

Om du vill visa den aktuella Java-versionen kör du följande kommando i 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"

Mer information om versionsstöd finns i Supportprincip för språkkörning i App Service.

Distribuera din app

Build Tools

Maven

Med Plugin-programmet Maven för Azure Web Apps kan du enkelt förbereda ditt Maven Java-projekt för Azure Web App 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 en relaterad konfiguration 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 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 information om webbappen. Motsvarande Azure-resurser skapas om de inte finns. Här är en exempelkonfiguration för mer information 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 ger sömlös Utveckling av Java App Service i populära Java-ID:er, inklusive:

Kudu API

Om du vill distribuera .jar filer till Java SE använder du /api/publish slutpunkten för Kudu-webbplatsen. Mer information om det här API:et finns i den här dokumentationen.

Kommentar

Ditt .jar-program måste namnges app.jar för Att App Service ska kunna identifiera och köra ditt program. Plugin-programmet Maven gör detta åt dig automatiskt under distributionen. Om du inte vill byta namn på jar-filen till app.jar kan du ladda upp ett gränssnittsskript med kommandot för att köra din .jar-app. Klistra in den absoluta sökvägen till det här skriptet i textrutan Startfil i avsnittet Konfiguration i portalen. Startskriptet körs inte från den katalog som det placeras i. Använd därför alltid absoluta sökvägar för att referera till filer i startskriptet (till exempel: java -jar /home/myapp/myapp.jar).

Om du vill distribuera .war-filer till Tomcat använder du /api/wardeploy/ slutpunkten för att PUBLICERA din arkivfil. Mer information om det här API:et finns i den här dokumentationen.

Om du vill distribuera .war-filer till JBoss använder du /api/wardeploy/ slutpunkten för att PUBLICERA din arkivfil. Mer information om det här API:et finns i den här dokumentationen.

Om du vill distribuera .ear-filer använder du FTP. .ear-programmet distribueras till kontextroten som definierats i programmets konfiguration. Om kontextroten för din app till exempel är <context-root>myapp</context-root>kan du bläddra på webbplatsen på /myapp sökvägen: http://my-app-name.azurewebsites.net/myapp. Om du vill att webbappen ska hanteras i rotsökvägen kontrollerar du att appen anger kontextroten till rotsökvägen: <context-root>/</context-root>. Mer information finns i Ange kontextroten för ett webbprogram.

Distribuera inte .war eller .jar med 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 URL

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

Tomcat tillhandahåller också en omskrivningsventil.

JBoss innehå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 diagnostikloggar

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

Aktivera först containerloggning genom att köra 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 de namn som är lämpliga för din webbapp.

När containerloggning har aktiverats kör du följande kommando för att visa loggströmmen:

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

Om du inte ser konsolloggarna omedelbart kan du titta efter igen efter 30 sekunder.

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

Du kan också granska loggfilerna i en webbläsare på https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Mer information finns i Stream-loggar i Cloud Shell.

SSH-konsolåtkomst i Linux

Om du ska öppna en SSH-direktsession med din container måste appen vara igång.

Klistra in följande URL i webbläsaren och ersätt <app-name> med namnet på appen:

https://<app-name>.scm.azurewebsites.net/webssh/host

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

Kommentar

Eventuella ändringar som du gör utanför katalogen /start lagras i själva containern och finns inte kvar om appen startas om.

Om du vill öppna en SSH-fjärrsession från den lokala datorn, kan du läsa mer i Öppna SSH-session från fjärrgränssnitt.

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 Profiler

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

Mer information om Java Profiler finns i Dokumentationen om Azure Application Insights.

Flight Recorder

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

SSH till Din 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 att Java-programmet körs 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 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 JAVA_OPTS appinställning skickas till java kommandot när appen startas.

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 startar kan du när som helst dumpa aktuella inspelningsdata med hjälp av JFR.dump 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. Anvisningar om Java Mission Control finns i JMC-dokumentationen och installationsanvisningarna.

Apploggning

Aktivera programloggning via Azure Portal eller Azure CLI för att konfigurera App Service för att skriva programmets standardkonsolutdata och standardkonsolfelströmmar till det lokala filsystemet eller Azure Blob Storage. 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 katalogen /home/LogFiles/Application/ .

Azure Blob Storage-loggning för Linux-baserade appar kan bara konfigureras med 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 med hjälp av konfigurationsinstruktionerna för loggningsramverket i Utforska Java-spårningsloggar i Application Insights.

Kommentar

På grund av kända säkerhetsrisker cve-2021-44228, se till att 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 Portal och 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.

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

Under Programinställningar för webbappen i Azure Portal 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>

Kommentar

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

Utvecklare som kör ett enda program med ett distributionsfack i sin App Service-plan kan använda följande alternativ:

  • B1- och S1-instanser: -Xms1024m -Xmx1024m
  • B2- och S2-instanser: -Xms3072m -Xmx3072m
  • B3- och S3-instanser: -Xms6144m -Xmx6144m
  • P1v2-instanser: -Xms3072m -Xmx3072m
  • P2v2-instanser: -Xms6144m -Xmx6144m
  • P3v2-instanser: -Xms12800m -Xmx12800m
  • P1v3-instanser: -Xms6656m -Xmx6656m
  • P2v3-instanser: -Xms14848m -Xmx14848m
  • P3v3-instanser: -Xms30720m -Xmx30720m
  • I1-instanser: -Xms3072m -Xmx3072m
  • I2-instanser: -Xms6144m -Xmx6144m
  • I3-instanser: -Xms12800m -Xmx12800m
  • I1v2-instanser: -Xms6656m -Xmx6656m
  • I2v2-instanser: -Xms14848m -Xmx14848m
  • I3v2-instanser: -Xms30720m -Xmx30720m

När du justerar inställningarna för programmets heap granskar du din App Service-planinformation och tar hänsyn till att flera program och distributionsfack måste hitta den optimala allokeringen av minne.

Aktivera webbsocketer

Aktivera stöd för webb socketar i Azure Portal 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

Under Programinställningar för webbappen i Azure Portal 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.

robots933456 i loggar

Följande meddelande kan visas 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 dummysökväg för URL:en som App Service använder till att kontrollera om containern kan hantera begäranden. Ett 404-svar innebär helt enkelt att sökvägen inte finns, men det låter App Service veta att containern är felfri och redo att svara på begäranden.

Välja 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 fästa JVM-versioner för korrigeringar. Detta förhindrar oväntade avbrott under en automatisk uppdateringsversion. 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 fästa delversionen måste 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 programmet körs korrekt på den nya delversionen kan du byta mellanlagrings- och produktionsfack.

Kör JBoss CLI

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

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

Beroende på var JBoss 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-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 Tomcat-, JBoss- eller Java SE-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 vnet-integrerad JBoss App Service-app, utskalad till tre instanser.

Kommentar

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 ställs den här egenskapen in automatiskt.

När klustring är aktiverat använder JBoss EAP-instanserna identifieringsprotokollet FILE_PING JGroups för att identifiera nya instanser och spara klusterinformationen som 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.

Kommentar

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

App Service-typerna Premium V3 och Isolated V2 kan distribueras över 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 att skala ned:

  • Åtgärd: "Minska antalet med"
  • Nedkylning: "5 minuter" eller större
  • 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 och P5mv3.

JBoss-serverlivscykel

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

Se respektive avsnitt nedan för mer information samt möjligheter att anpassa den (till exempel via appinställningar).

1. Miljökonfigurationsfas

  • SSH-tjänsten startas för att aktivera säkra SSH-sessioner med containern.
  • Keystore för Java-körningen uppdateras med alla offentliga och privata certifikat som definierats i Azure Portal.
    • Offentliga certifikat tillhandahålls av plattformen i katalogen /var/ssl/certs och de läses in till $JRE_HOME/lib/security/cacerts.
    • Privata certifikat tillhandahålls av plattformen i katalogen /var/ssl/private 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.keyStorejavax.net.ssl.keyStorePassword och javax.net.ssl.keyStoreType till i JAVA_TOOL_OPTIONS miljövariabeln.
  • Viss inledande JVM-konfiguration bestäms, till exempel loggningskataloger och Parametrar för Java-minnes-heap:
    • 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 körningsegenskapen org.wildfly.sigterm.suspend.timeout, som styr den maximala avstängningsväntetiden (i sekunder) när JBoss 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 starta JBoss 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 startas i konfigurationen clustering :
    • Varje JBoss-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 tar platsen för en identisk tjänstinstans som kraschade tidigare och lämnade ogenomförda transaktioner bakom sig. Servern är konfigurerad för att återuppta arbetet med dessa transaktioner.
  • Oavsett om JBoss 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.

3. Serverkonfigurationsfasen

  • I början av den här fasen väntar App Service först på att både JBoss-servern och administratörsgränssnittet ska vara redo att ta emot begäranden innan du fortsätter. Det kan ta några sekunder om Application Insights är aktiverat.
  • När både JBoss Server och administratörsgränssnittet är klara gör App Service följande:
    • Lägger till JBoss-modulen azure.appservice, som tillhandahåller verktygsklasser för loggning och integrering med App Service.
    • Uppdaterar konsolloggaren så att den använder ett färglöst läge så att loggfilerna inte är fulla av färgspringande sekvenser.
    • Konfigurerar integreringen med Azure Monitor-loggar.
    • Uppdaterar bindnings-IP-adresserna för WSDL och hanteringsgränssnitten.
    • Lägger till JBoss-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 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 och lägger till en datakälla för var och en av JDBC-URL:en och anger JNDI-namnet 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 katalogen /home/site/libs 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 på följande sätt:
    • Om du har konfigurerat ett startkommando (i Azure Portal, med Azure CLI osv.) 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-installations-/anpassningskommandon (skapa datakällor, installera resurskort) osv. 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 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 distribuerar du det.
  • Om det finns andra EAR- och WAR-filer i /home/site/wwwroot distribuerar du dem.
  • Om /home/site/wwwroot/webapps finns distribuerar du filerna och katalogerna i den. WAR-filer distribueras som själva programmen och kataloger distribueras som "sprängda" (okomprimerade) webbappar.
  • Om det finns några fristående JSP-sidor i /home/site/wwwroot kopierar du dem till webbserverroten och distribuerar dem som en webbapp.
  • Om inga distributionsbara filer hittas ännu distribuerar du standardsidan för välkomstsidan (parkeringssidan) i rotkontexten.

5. Omlastningsfasen för servern

  • När distributionsstegen är klara läses JBoss-servern in igen för att tillämpa alla ändringar som kräver en serveromläsning.
  • 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-servern avslutas onormalt i konfigurationen clustering körs en slutlig funktion med namnet emit_alert_tx_store_not_empty . Funktionen kontrollerar om JBoss-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-snåla transaktionsarkivfilerna för att återuppta arbetet (se 2. Serverstartsfasen).

Konfiguration av Tomcat-baslinje

Kommentar

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-konfiguration: Genom att förstå 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å. Detta inkluderar 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. Genom att förstå server.xml fil 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. Att förstå den här informationen är viktigt för att distribuera program korrekt och se till att de fungerar smidigt på servern.

När du skapar en app med inbyggd Tomcat som värd för din Java-arbetsbelastning (en WAR-fil eller en JAR-fil) finns det vissa inställningar som du kommer ur rutan för Tomcat-konfiguration. Du kan läsa den officiella Apache Tomcat-dokumentationen för detaljerad information, inklusive standardkonfigurationen för Tomcat-webbservern.

Dessutom finns det vissa transformeringar som tillämpas ytterligare ovanpå server.xml för Tomcat-distribution vid start. Det här är transformeringar till inställningarna Anslutningsprogram, 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.

Anslutningsapp

<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älld på 16384
  • URIEncoding är inställd på UTF-8
  • conectionTimeout ä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

Kommentar

Inställningarna connectionTimeout, maxThreads och maxConnections kan justeras med appinställningar

Följande är exempel på CLI-kommandon som du kan använda för att ändra värdena för conectionTimeout, maxThreads eller 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

Host

<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, som standard är 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, som standard TMP
  • errorReportValveClass använder vår anpassade felrapportventil

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 till WEBSITE_HTTPLOGGING_RETENTION_DAYS, som standard till 0 [forever]

I Linux har den samma anpassning, plus:

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

Nästa steg

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