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 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 --name <app-name> --resource-group <resource-group-name> --query "[javaVersion, javaContainer, javaContainerVersion]"

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

az webapp list-runtimes --os windows | grep java

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-portalen. Mer information finns i Översikt över Azure App Service-diagnostik.

Strömma diagnostikloggar

Om du vill komma åt konsolloggarna som genereras i din programkod i App Service aktiverar du diagnostisk loggning genom att köra följande kommando i Cloud Shell:

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

Möjliga värden för --level är: Error, Warning, Info och Verbose. Varje efterföljande nivå omfattar den föregående nivån. Exempel: Error omfattar endast felmeddelanden och Verbose omfattar alla meddelanden.

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

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

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

Kommentar

Du kan även granska loggfilerna från din webbläsare via https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Skriv Ctrl+C när som helst för att stoppa loggströmningen.

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.

Tidsförd inspelning

Om du vill ta en tidsbaserad inspelning behöver du PID (process-ID) för Java-programmet. Om du vill hitta PID:en öppnar du en webbläsare till webbappens SCM-webbplats på https://<your-site-name>.scm.azurewebsites.net/ProcessExplorer/. Den här sidan visar de processer som körs i webbappen. Hitta processen med namnet "java" i tabellen och kopiera motsvarande PID (process-ID).

Öppna sedan felsökningskonsolen i det översta verktygsfältet på SCM-platsen och kör följande kommando. Ersätt <pid> med det process-ID som du kopierade tidigare. Det här kommandot startar en 30-sekunders profilerarinspelning av ditt Java-program och genererar en fil med namnet timed_recording_example.jfr i C:\home katalogen.

jcmd <pid> JFR.start name=TimedRecording settings=profile duration=30s filename="C:\home\timed_recording_example.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-portalen 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. Loggning till den lokala App Service-filsysteminstansen inaktiveras 12 timmar efter att du har aktiverat den. 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/ .

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 direktjustering och anpassning via Azure-portalen 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.

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>

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

Kommentar

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.

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. JBoss EAP-instanserna kommunicerar via det undernät som anges i integreringen av det virtuella nätverket med hjälp av portarna som visas i WEBSITES_PRIVATE_PORTS miljövariabeln vid körning. Du kan inaktivera klustring genom att skapa en appinställning med namnet WEBSITE_DISABLE_CLUSTERING med valfritt värde.

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 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 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 är endast tillgängligt på App Service-plantyperna Premium v3 och Isolerad v2. Kunder som skapade en JBoss EAP-webbplats på en annan nivå under den offentliga förhandsversionen bör skala upp till Premium- eller Isolerad maskinvarunivå för att undvika oväntat beteende.

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.

Koppling

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