Sdílet prostřednictvím

Nasazení a konfigurace aplikace Tomcat, JBoss nebo Java SE ve službě Aplikace Azure Service

  • Článek

Tento článek ukazuje nejběžnější konfiguraci nasazení a modulu runtime pro aplikace v Javě ve službě App Service. Pokud jste službu Aplikace Azure Service nikdy nepoužívali, měli byste si nejprve přečíst rychlý start pro Javu. Obecné dotazy týkající se používání služby App Service, které nejsou specifické pro vývoj v Javě, najdete v nejčastějších dotazech ke službě App Service.

Aplikace Azure Služba spouští webové aplikace Java v plně spravované službě ve třech variantách:

  • Java SE – Může spustit aplikaci nasazenou jako balíček JAR, který obsahuje vložený server (například Spring Boot, Dropwizard, Quarkus nebo jeden s vloženým serverem Tomcat nebo Jetty).
  • Tomcat – Integrovaný server Tomcat může spustit aplikaci nasazenou jako balíček WAR.
  • JBoss EAP – Podporuje se jenom pro linuxové aplikace v cenových úrovních Free, Premium v3 a Isolated v2. Integrovaný server JBoss EAP může spustit aplikaci nasazenou jako balíček WAR nebo EAR.

Poznámka:

Pro aplikace Spring doporučujeme používat Azure Spring Apps. Službu Aplikace Azure však můžete použít jako cíl. Rady najdete v pokynech k cíli úloh v Javě.

Zobrazit verzi Javy

Pokud chcete zobrazit aktuální verzi Javy, spusťte v Cloud Shellu následující příkaz:

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

Pokud chcete zobrazit všechny podporované verze Javy, spusťte v Cloud Shellu následující příkaz:

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

Další informace o podpoře verzí najdete v tématu Zásady podpory modulu runtime jazyka App Service.

Nasazení aplikace

Build Tools

Maven

S modulem plug-in Maven pro Azure Web Apps můžete snadno připravit projekt Maven Java pro Azure Web App jedním příkazem v kořenovém adresáři projektu:

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

Tento příkaz přidá modul azure-webapp-maven-plugin plug-in a související konfiguraci tím, že vás vyzve k výběru existující webové aplikace Azure nebo vytvoření nové. Během konfigurace se pokusí zjistit, jestli se vaše aplikace má nasadit do Java SE, Tomcat nebo (jenom Linux) JBoss EAP. Pak můžete aplikaci v Javě nasadit do Azure pomocí následujícího příkazu:

mvn package azure-webapp:deploy

Tady je ukázková konfigurace v 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. Nastavte modul plug-in Gradle pro Azure Web Apps tak, že do svého modulu plug-in přidáte build.gradle:

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

  2. Nakonfigurujte podrobnosti o webové aplikaci. Odpovídající prostředky Azure se vytvoří, pokud neexistují. Tady je ukázková konfigurace, kde najdete podrobnosti v tomto dokumentu.

    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. Nasazení pomocí jednoho příkazu

    gradle azureWebAppDeploy

Prostředí IDE

Azure poskytuje bezproblémové vývojové prostředí služby Java App Service v oblíbených prostředích Java IDEs, včetně následujících:

Kudu API

Pokud chcete nasadit soubory .jar do Javy SE, použijte /api/publish koncový bod webu Kudu. Další informace o tomto rozhraní API najdete v této dokumentaci.

Poznámka:

Aby služba App Service identifikovala a spustila vaši aplikaci, musí být vaše .jar aplikace pojmenovaná app.jar . Modul plug-in Maven to udělá automaticky během nasazování. Pokud nechcete soubor JAR přejmenovat na app.jar, můžete nahrát skript prostředí pomocí příkazu pro spuštění .jar aplikace. Do textového pole Spouštěcí soubor vložte absolutní cestu k tomuto skriptu v části Konfigurace portálu. Spouštěcí skript se nespustí z adresáře, do kterého je umístěný. Proto ve spouštěcím skriptu vždy používejte absolutní cesty k referenčním souborům (například: java -jar /home/myapp/myapp.jar).

Pokud chcete nasadit soubory .war do Tomcatu, použijte /api/wardeploy/ koncový bod k odeslání archivu souboru. Další informace o tomto rozhraní API najdete v této dokumentaci.

Pokud chcete nasadit soubory .war do JBoss, použijte /api/wardeploy/ koncový bod k odeslání archivu souboru. Další informace o tomto rozhraní API najdete v této dokumentaci.

K nasazení souborů .ear použijte protokol FTP. Aplikace .ear se nasadí do kořene kontextu definovaného v konfiguraci vaší aplikace. Pokud je například kontextová kořen aplikace <context-root>myapp</context-root>, můžete web procházet na cestě /myapp : http://my-app-name.azurewebsites.net/myapp. Pokud chcete, aby byla vaše webová aplikace obsluhována v kořenové cestě, ujistěte se, že vaše aplikace nastaví kořen kontextu na kořenovou cestu: <context-root>/</context-root>. Další informace naleznete v tématu Nastavení kontextového kořene webové aplikace.

Nenasazujte své .war ani .jar pomocí FTP. Nástroj FTP je navržený tak, aby nahrál spouštěcí skripty, závislosti nebo jiné soubory modulu runtime. Není to optimální volba pro nasazení webových aplikací.

Přepsání nebo přesměrování adresy URL

Pokud chcete přepsat nebo přesměrovat adresu URL, použijte jeden z dostupných rewriterů adres URL, například UrlRewriteFilter.

Tomcat také poskytuje přepisový ventil.

JBoss také poskytuje přepisový ventil.

Protokolování a ladění aplikací

Sestavy výkonu, vizualizace provozu a kontroly stavu jsou dostupné pro každou aplikaci prostřednictvím webu Azure Portal. Další informace najdete v tématu Aplikace Azure Přehled diagnostiky služby.

Streamování diagnostických protokolů

Přístup k protokolům konzoly vygenerovaným z kontejneru.

Nejprve zapněte protokolování kontejneru spuštěním následujícího příkazu:

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

Nahraďte <app-name> názvy vhodné pro vaši webovou aplikaci a <resource-group-name> nahraďte je názvy.

Jakmile je protokolování kontejneru zapnuté, spuštěním následujícího příkazu zobrazte stream protokolu:

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

Pokud nevidíte protokoly konzoly okamžitě, podívejte se znovu za 30 sekund.

Pokud chcete streamování protokolů kdykoli zastavit, zadejte Ctrl+C.

Soubory protokolu můžete také zkontrolovat v prohlížeči na adrese https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Další informace najdete v tématu Protokoly streamu v Cloud Shellu.

Přístup ke konzole SSH v Linuxu

Pokud chcete otevřít přímou relaci SSH s kontejnerem, vaše aplikace by měla být spuštěná.

Vložte následující adresu URL do vašeho prohlížeče a <app-name> nahraďte názvem vaší aplikace:

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

Pokud ještě nejste ověření, budete se muset ověřit s vaším předplatným Azure, abyste se mohli připojit. Po ověření se vám zobrazí prostředí prohlížeče, ve kterém můžete spouště příkazy uvnitř vašeho kontejneru.

Připojení SSH

Poznámka:

Všechny změny provedené mimo adresář /home se uloží ve vlastním kontejneru a po restartování aplikace se neuchovají.

Pokud chcete otevřít vzdálenou relaci SSH z místního počítače, projděte si téma věnované otevření relace SSH ze vzdáleného prostředí.

Nástroje pro řešení potíží s Linuxem

Integrované image Java jsou založené na operačním systému Alpine Linux . apk Pomocí správce balíčků nainstalujte všechny nástroje nebo příkazy pro řešení potíží.

Java Profiler

Všechny moduly runtime Javy ve službě Aplikace Azure jsou součástí nástroje JDK Flight Recorder pro profilaci úloh Javy. Můžete ho použít k zaznamenání událostí prostředí JVM, systému a aplikací a řešení problémů ve vašich aplikacích.

Další informace o nástroji Java Profiler najdete v dokumentaci k Aplikace Azure lication Insights.

Flight Recorder

Všechny moduly runtime Java ve službě App Service jsou součástí nástroje Java Flight Recorder. Můžete ho použít k zaznamenání událostí JVM, systému a aplikací a řešení problémů v aplikacích v Javě.

Připojte se ke službě App Service pomocí SSH a spusťte jcmd příkaz, abyste zobrazili seznam všech spuštěných procesů Javy. Kromě jcmd sebe byste měli vidět, že vaše aplikace v Javě běží s číslem ID procesu (pid).

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

Spuštěním následujícího příkazu spusťte 30sekundový záznam prostředí JVM. Profiluje JVM a vytvoří soubor JFR s názvem jfr_example.jfr v domovském adresáři. (Nahraďte 116 pid vaší aplikace v Javě.)

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

Během 30sekundového intervalu můžete ověřit, že záznam probíhá spuštěním jcmd 116 JFR.check. Příkaz zobrazí všechny nahrávky pro daný proces Javy.

Průběžný záznam

Pomocí nástroje Java Flight Recorder můžete průběžně profilovat aplikaci v Javě s minimálním dopadem na výkon modulu runtime. Spuštěním následujícího příkazu Azure CLI vytvořte nastavení aplikace s názvem JAVA_OPTS s potřebnou konfigurací. Obsah nastavení aplikace JAVA_OPTS se předá java příkazu při spuštění aplikace.

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

Jakmile se záznam spustí, můžete pomocí příkazu kdykoli vyhodit aktuální data záznamu JFR.dump .

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

Analýza .jfr souborů

Pomocí FTPS stáhněte soubor JFR do místního počítače. Pokud chcete analyzovat soubor JFR, stáhněte a nainstalujte Java Mission Control. Pokyny k nástroji Java Mission Control najdete v dokumentaci JMC a pokyny k instalaci.

Protokolování aplikace

Povolte protokolování aplikace prostřednictvím webu Azure Portal nebo Azure CLI a nakonfigurujte službu App Service tak, aby zapisuje standardní výstup konzoly a standardní datové proudy chyb konzoly do místního systému souborů nebo do služby Azure Blob Storage. Pokud potřebujete delší dobu uchovávání, nakonfigurujte aplikaci tak, aby zapisuje výstup do kontejneru úložiště objektů blob.

Protokoly aplikace Java a Tomcat najdete v adresáři /home/LogFiles/Application/ .

Protokolování služby Azure Blob Storage pro aplikace založené na Linuxu je možné nakonfigurovat pouze pomocí služby Azure Monitor.

Pokud vaše aplikace pro trasování používá logback nebo Log4j, můžete tyto trasování předat pro kontrolu do Aplikace Azure lication Insights pomocí pokynů pro konfiguraci rozhraní protokolování v části Prozkoumání protokolů trasování Java v Application Insights.

Poznámka:

Kvůli známé chybě zabezpečení CVE-2021-44228 nezapomeňte použít Log4j verze 2.16 nebo novější.

Přizpůsobení a ladění

Aplikace Azure Služba podporuje oddělování a přizpůsobení prostřednictvím webu Azure Portal a rozhraní příkazového řádku. V následujících článcích najdete informace o konfiguraci webové aplikace, která není specifická pro Javu:

Místní kopírování obsahu aplikace

Nastavte nastavení JAVA_COPY_ALL aplikace tak, aby true se obsah aplikace zkopíroval do místního pracovního procesu ze sdíleného systému souborů. Toto nastavení pomáhá řešit problémy se zamykáním souborů.

Nastavení možností modulu runtime Java

Pokud chcete nastavit přidělenou paměť nebo jiné možnosti modulu runtime JVM, vytvořte nastavení aplikace s názvem JAVA_OPTS s možnostmi. App Service toto nastavení předá jako proměnnou prostředí modulu runtime Java při spuštění.

Na webu Azure Portal v části Nastavení aplikace pro webovou aplikaci vytvořte nové nastavení aplikace s názvem JAVA_OPTS , které obsahuje další nastavení, například -Xms512m -Xmx1204m.

Na webu Azure Portal v části Nastavení aplikace pro webovou aplikaci vytvořte nové nastavení aplikace s názvem CATALINA_OPTS , které obsahuje další nastavení, například -Xms512m -Xmx1204m.

Pokud chcete nakonfigurovat nastavení aplikace z modulu plug-in Maven, přidejte do části Modul plug-in Azure značky nastavení/hodnoty. Následující příklad nastaví konkrétní minimální a maximální velikost haldy Java:

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

Poznámka:

Při používání tomcat ve Službě Windows App Service nemusíte vytvářet soubor web.config.

Vývojáři, kteří v plánu služby App Service používají jednu aplikaci s jedním slotem nasazení, můžou použít následující možnosti:

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

Při ladění nastavení haldy aplikace zkontrolujte podrobnosti plánu služby App Service a vezměte v úvahu několik aplikací a slotů nasazení, abyste našli optimální přidělení paměti.

Zapnutí webových soketů

Zapněte podporu webových soketů na webu Azure Portal v nastavení aplikace pro aplikaci. Aby se nastavení projevilo, musíte aplikaci restartovat.

Zapněte podporu webového soketu pomocí Azure CLI pomocí následujícího příkazu:

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

Pak restartujte aplikaci:

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

Nastavení výchozího kódování znaků

Na webu Azure Portal vytvořte v části Nastavení aplikace pro webovou aplikaci nové nastavení aplikace s názvem JAVA_OPTS hodnota -Dfile.encoding=UTF-8.

Případně můžete nakonfigurovat nastavení aplikace pomocí modulu plug-in App Service Maven. Do konfigurace modulu plug-in přidejte značky názvu a hodnoty nastavení:

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

Předběžné kompilace souborů JSP

Pokud chcete zlepšit výkon aplikací Tomcat, můžete soubory JSP před nasazením do služby App Service zkompilovat. Můžete použít modul plug-in Maven, který poskytuje Apache Sling, nebo použít tento soubor sestavení Ant.

robots933456 v protokolech

V protokolech kontejneru se může zobrazit následující zpráva:

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

Tuto zprávu klidně ignorujte. /robots933456.txt je fiktivní cesta URL, kterou App Service používá ke kontrole, jestli kontejner dokáže obsloužit požadavky. Odpověď 404 jednoduše indikuje, že příslušná cesta neexistuje, ale dá službě App Service vědět, že kontejner je v pořádku a je připravený reagovat na požadavky.

Volba verze modulu runtime Java

App Service umožňuje uživatelům zvolit hlavní verzi prostředí JVM, jako je Java 8 nebo Java 11, a verzi opravy, například 1.8.0_232 nebo 11.0.5. Můžete také zvolit, aby se verze oprav automaticky aktualizovala, jakmile budou k dispozici nové podverze. Ve většině případů by produkční aplikace měly používat připnuté verze JVM oprav. Tím se zabrání neočekávaným výpadkům během automatického aktualizace verze opravy. Všechny webové aplikace v Javě používají 64bitové virtuální počítače JVM a nedají se konfigurovat.

Pokud používáte Tomcat, můžete se rozhodnout připnout verzi opravy tomcat. Ve Windows můžete nezávisle připnout verze oprav prostředí JVM a Tomcat. V Linuxu můžete připnout verzi opravy Tomcat; Verze opravy prostředí JVM je také připnutá, ale není samostatně konfigurovatelná.

Pokud se rozhodnete připnout podverzi, musíte v aplikaci pravidelně aktualizovat podverzi JVM. Pokud chcete zajistit, aby vaše aplikace běžela v novější podverzi, vytvořte přípravný slot a v přípravném slotu navyšte podverzi. Jakmile ověříte, že aplikace funguje správně v nové podverzi, můžete prohodit přípravné a produkční sloty.

Spuštění rozhraní příkazového řádku JBoss

V relaci SSH aplikace JBoss můžete spustit JBoss CLI pomocí následujícího příkazu:

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

V závislosti na tom, kde je JBoss v životním cyklu serveru, se možná nebudete moct připojit. Počkejte několik minut a zkuste akci zopakovat. Tento přístup je užitečný pro rychlé kontroly aktuálního stavu serveru (například pro zjištění, jestli je zdroj dat správně nakonfigurovaný).

Změny provedené na serveru pomocí rozhraní příkazového řádku JBoss v relaci SSH se po restartování aplikace neuchovávají. Při každém spuštění aplikace začne server JBoss EAP čistou instalací. Během životního cyklu spuštění služba App Service provede potřebné konfigurace serveru a nasadí aplikaci. K provedení trvalých změn na serveru JBoss použijte vlastní spouštěcí skript nebo spouštěcí příkaz. Kompletní příklad najdete v tématu Konfigurace zdrojů dat pro aplikaci Tomcat, JBoss nebo Java SE ve službě Aplikace Azure Service.

Alternativně můžete službu App Service nakonfigurovat ručně tak, aby při spuštění spustila libovolný soubor. Příklad:

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

Další informace o příkazech rozhraní příkazového řádku, které můžete spustit, najdete tady:

Clustering

App Service podporuje clustering pro JBoss EAP verze 7.4.1 a vyšší. Aby bylo možné povolit clustering, musí být vaše webová aplikace integrovaná s virtuální sítí. Když je webová aplikace integrovaná s virtuální sítí, restartuje se a instalace protokolu EAP JBoss se automaticky spustí s clusterovanou konfigurací. Když spustíte více instancí s automatickým škálováním, instance EAP JBoss vzájemně komunikují přes podsíť zadanou v integraci virtuální sítě. Clustering můžete zakázat vytvořením nastavení aplikace s názvem WEBSITE_DISABLE_CLUSTERING s libovolnou hodnotou.

Diagram znázorňující aplikaci JBoss App Service s integrovanou virtuální sítí, škálovanou na tři instance

Poznámka:

Pokud povolíte integraci virtuální sítě se šablonou ARM, musíte vlastnost vnetPrivatePorts nastavit ručně na hodnotu 2. Pokud povolíte integraci virtuální sítě z rozhraní příkazového řádku nebo portálu, nastaví se tato vlastnost automaticky.

Když je clustering povolený, instance EAP JBoss používají protokol zjišťování FILE_PING JGroups ke zjišťování nových instancí a uchování informací o clusteru, jako jsou členové clusteru, jejich identifikátory a jejich IP adresy. Ve službě App Service jsou tyto soubory pod /home/clusterinfo/. První instance protokolu EAP, která se má spustit, získá oprávnění ke čtení a zápisu v souboru členství v clusteru. Ostatní instance načtou soubor, najdou primární uzel a koordinují se s tímto uzlem, který se má zahrnout do clusteru a přidat do souboru.

Poznámka:

Vypršení časových limitů clusteringu JBoss se můžete vyhnout vyčištěním zastaralých souborů zjišťování během spuštění aplikace.

Typy plánů služby App Service Úrovně Premium V3 a Izolované verze 2 je možné volitelně distribuovat napříč Zóny dostupnosti, aby se zlepšila odolnost a spolehlivost pro důležité obchodní úlohy. Tato architektura se také označuje jako redundance zón. Funkce clusteringu JBoss EAP je kompatibilní s funkcí redundance zón.

Pravidla automatického škálování

Při konfiguraci pravidel automatického škálování pro horizontální škálování je důležité odebrat instance postupně (po jednom) a zajistit tak, aby každá odebraná instance přenesla svoji aktivitu (například zpracování databázové transakce) do jiného člena clusteru. Při konfiguraci pravidel automatického škálování na portálu pro vertikální snížení kapacity použijte následující možnosti:

  • Operace: "Snížit počet o"
  • Vychladnutí: "5 minut" nebo vyšší
  • Počet instancí: 1

Nemusíte postupně přidávat instance (horizontální navýšení kapacity), do clusteru můžete postupně přidávat více instancí.

Plány služby App Service

JBoss EAP je k dispozici v následujících cenových úrovních: F1, P0v3, P1mv3, P2mv3, P3mv3, P4mv3 a P5mv3.

Životní cyklus serveru JBoss

Aplikace JBoss EAP ve službě App Service prochází pěti různými fázemi, než skutečně spustíte server.

Podrobnosti a příležitosti k jeho přizpůsobení (například prostřednictvím nastavení aplikace) najdete níže v příslušných částech.

1. Fáze nastavení prostředí

  • Služba SSH se spustí pro povolení zabezpečených relací SSH s kontejnerem.
  • Úložiště klíčů modulu runtime Java se aktualizuje o všechny veřejné a privátní certifikáty definované na webu Azure Portal.
    • Veřejné certifikáty poskytuje platforma v adresáři /var/ssl/certs a načtou se do $JRE_HOME/lib/security/cacerts.
    • Privátní certifikáty poskytuje platforma v adresáři /var/ssl/private a načtou se do $JRE_HOME/lib/security/client.jks.
  • Pokud jsou v tomto kroku načteny nějaké certifikáty do úložiště klíčů Java, vlastnosti javax.net.ssl.keyStorejavax.net.ssl.keyStorePassword a javax.net.ssl.keyStoreType jsou přidány do JAVA_TOOL_OPTIONS proměnné prostředí.
  • Určuje se některá počáteční konfigurace prostředí JVM, jako jsou například adresáře protokolování a parametry haldy paměti Java:
    • Pokud v nastavení JAVA_OPTSaplikace zadáte –Xms nebo –Xmx označíte příznak pro paměť, tyto hodnoty přepíšou ty, které poskytuje platforma.
    • Pokud nakonfigurujete nastavení WEBSITES_CONTAINER_STOP_TIME_LIMITaplikace , hodnota se předá vlastnosti org.wildfly.sigterm.suspend.timeoutmodulu runtime, která řídí maximální dobu čekání na vypnutí (v sekundách), když je JBoss zastavena.
  • Pokud je aplikace integrovaná s virtuální sítí, modul runtime služby App Service předá seznam portů, které se mají použít pro komunikaci mezi servery v proměnné WEBSITE_PRIVATE_PORTS prostředí a spustí JBoss pomocí clustering konfigurace. standalone V opačném případě se použije konfigurace.
    • clustering Pro konfiguraci se použije konfigurační soubor serveru standalone-azure-full-ha.xml.
    • standalone Pro konfiguraci se použije konfigurační soubor serveru standalone-full.xml.

2. Fáze spuštění serveru

  • Pokud se JBoss spustí v clustering konfiguraci:
    • Každá instance JBoss přijímá interní identifikátor mezi 0 a počtem instancí, na které se aplikace škáluje.
    • Pokud jsou některé soubory nalezeny v cestě k úložišti transakcí pro tuto instanci serveru (pomocí jeho interního identifikátoru), znamená to, že tato instance serveru se nachází místo identické instance služby, která se dříve chybově ukončila a opustila nepotvrzené transakce za sebou. Server je nakonfigurován tak, aby obnovil práci na těchto transakcích.
  • Bez ohledu na to, jestli se JBosss spouští v clustering konfiguraci, standalone pokud je verze serveru 7.4 nebo vyšší a modul runtime používá Javu 17, je konfigurace aktualizována tak, aby umožňovala subsystém Elytron pro zabezpečení.
  • Pokud nakonfigurujete nastavení WEBSITE_JBOSS_OPTSaplikace, předá se hodnota skriptu spouštěče JBoss. Toto nastavení lze použít k poskytování cest k souborům vlastností a dalším příznakům, které ovlivňují spuštění JBoss.

3. Fáze konfigurace serveru

  • Na začátku této fáze služba App Service nejprve čeká, až bude server JBoss i rozhraní pro správu připravené přijímat požadavky, než budete pokračovat. Pokud je služba Application Insights povolená, může to trvat několik sekund.
  • Jakmile je server JBoss i rozhraní pro správu připravené, app Service provede následující akce:
    • Přidá modul azure.appserviceJBoss, který poskytuje třídy nástrojů pro protokolování a integraci se službou App Service.
    • Aktualizuje protokolovací nástroj konzoly tak, aby používal bezbarvý režim tak, aby soubory protokolů nejsou plné sekvence pro zapouzdření barev.
    • Nastaví integraci s protokoly služby Azure Monitor.
    • Aktualizuje vazbové IP adresy rozhraní WSDL a správy.
    • Přidá modul azure.appservice.easyauth JBoss pro integraci s ověřováním služby App Service a ID Microsoft Entra.
    • Aktualizuje konfiguraci protokolování protokolů přístupu a název a obměnu souboru protokolu hlavního serveru.
  • Pokud není definované nastavení WEBSITE_SKIP_AUTOCONFIGURE_DATABASE aplikace, služba App Service automaticky definuje adresy URL JDBC v nastavení aplikace služby App Service. Pokud existují platné adresy URL JDBC pro PostgreSQL, MySQL, MariaDB, Oracle, SQL Server nebo Azure SQL Database, přidá na server odpovídající ovladače a přidá zdroj dat pro každou adresu URL JDBC a nastaví název JNDI pro každý zdroj dat na java:jboss/env/jdbc/<app-setting-name>_DS, kde <app-setting-name> je název nastavení aplikace.
  • clustering Pokud je konfigurace povolená, zkontroluje se protokolovací nástroj konzoly, který se má nakonfigurovat.
  • Pokud jsou do adresáře /home/site/libs nasazené soubory JAR, vytvoří se nový globální modul se všemi těmito soubory JAR.
  • Na konci fáze služba App Service spustí vlastní spouštěcí skript, pokud existuje. Vyhledávací logika pro vlastní spouštěcí skript následujícím způsobem:
    • Pokud jste nakonfigurovali spouštěcí příkaz (na webu Azure Portal, pomocí Azure CLI atd.), spusťte ho; jinak
    • Pokud cesta /home/site/scripts/startup.sh existuje, použijte ji; jinak
    • Pokud cesta /home/startup.sh existuje, použijte ji.

Vlastní spouštěcí příkaz nebo skript se spustí jako uživatel root (není potřebasudo), aby mohl nainstalovat balíčky Linuxu nebo spustit rozhraní příkazového řádku JBoss, aby provedl více příkazů instalace a přizpůsobení JBoss (vytváření zdrojů dat, instalace adaptérů prostředků) atd. Informace o příkazech pro správu balíčků Ubuntu najdete v dokumentaci k Ubuntu Serveru. Příkazy rozhraní příkazového řádku JBoss najdete v průvodci rozhraním příkazového řádku pro správu JBoss.

4. Fáze nasazení aplikace

Spouštěcí skript nasadí aplikace do JBoss tak, že hledá v následujících umístěních podle priority:

  • Pokud jste nakonfigurovali nastavení WEBSITE_JAVA_WAR_FILE_NAMEaplikace, nasaďte soubor určený ho.
  • Pokud existuje /home/site/wwwroot/app.war , nasaďte ji.
  • Pokud v adresáři /home/site/wwwroot existují nějaké jiné soubory EAR a WAR, nasaďte je.
  • Pokud existuje /home/site/wwwroot/webapps , nasaďte do něj soubory a adresáře. Soubory WAR se nasazují jako samotné aplikace a adresáře se nasazují jako "rozložené" (nekomprimované) webové aplikace.
  • Pokud v adresáři /home/site/wwwroot existují některé samostatné stránky JSP, zkopírujte je do kořenového adresáře webového serveru a nasaďte je jako jednu webovou aplikaci.
  • Pokud se zatím nenašly žádné nasaditelné soubory, nasaďte výchozí úvodní stránku (parkovací stránku) v kořenovém kontextu.

5. Fáze opětovného načtení serveru

  • Po dokončení kroků nasazení se server JBoss znovu načte, aby se použily všechny změny, které vyžadují opětovné načtení serveru.
  • Po opětovném načtení serveru by aplikace nasazené na server JBoss EAP měly být připravené reagovat na požadavky.
  • Server se spustí, dokud se aplikace App Service nezastaví nebo nerestartuje. Aplikaci App Service můžete ručně zastavit nebo restartovat nebo aktivovat restartování při nasazování souborů nebo provádění změn konfigurace aplikace App Service.
  • Pokud server JBoss ukončí neobvykle v clustering konfiguraci, spustí se konečná funkce.emit_alert_tx_store_not_empty Funkce zkontroluje, jestli proces JBoss opustil neprázdný soubor úložiště transakcí na disku; pokud ano, v konzole se zaprotokoluje chyba: Error: finishing server with non-empty store for node XXXX. Když je spuštěna nová instance serveru, hledá tyto neprázdné soubory úložiště transakcí k obnovení práce (viz 2. Fáze spuštění serveru).

Základní konfigurace Tomcatu

Poznámka:

Tato část platí jenom pro Linux.

Vývojáři v Javě můžou přizpůsobit nastavení serveru, řešit problémy a nasazovat aplikace do Tomcat s jistotou, pokud vědí o souboru server.xml a podrobnostech konfigurace Tomcatu. Mezi možná přizpůsobení patří:

  • Přizpůsobení konfigurace Tomcat: Pochopením server.xml souboru a podrobností o konfiguraci Tomcat můžete doladit nastavení serveru tak, aby odpovídalo potřebám jejich aplikací.
  • Ladění: Když je aplikace nasazená na serveru Tomcat, musí vývojáři znát konfiguraci serveru, aby mohli ladit případné problémy. To zahrnuje kontrolu protokolů serveru, zkoumání konfiguračních souborů a identifikaci chyb, ke kterým může dojít.
  • Řešení potíží se službou Tomcat: Vývojáři v Javě narazí na problémy se svým serverem Tomcat, jako jsou problémy s výkonem nebo chyby konfigurace. Díky pochopení server.xml souboru a podrobností o konfiguraci Tomcat můžou vývojáři tyto problémy rychle diagnostikovat a řešit, což může ušetřit čas a úsilí.
  • Nasazování aplikací do Tomcat: Pokud chcete nasadit webovou aplikaci Java do Tomcatu, musí vývojáři vědět, jak nakonfigurovat server.xml soubor a další nastavení Tomcatu. Pochopení těchto podrobností je nezbytné pro úspěšné nasazení aplikací a zajištění bezproblémového spuštění na serveru.

Když vytvoříte aplikaci s integrovanou službou Tomcat pro hostování úloh v Javě (soubor WAR nebo soubor JAR), jsou k dispozici určitá nastavení, která se dostanou mimo konfiguraci Tomcat. Podrobné informace, včetně výchozí konfigurace webového serveru Tomcat, najdete v oficiální dokumentaci k Apache Tomcat.

Kromě toho existují určité transformace, které jsou dále použity nad server.xml pro distribuci Tomcat po spuštění. Jedná se o transformace nastavení konektoru, hostitele a ventilu.

Nejnovější verze Tomcat mají server.xml (8.5.58 a 9.0.38 dále). Starší verze Tomcat nepoužívají transformace a v důsledku toho můžou mít jiné chování.

Konektor

<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 je nastavená na 16384
  • URIEncoding je nastavená na UTF-8
  • connectionTimeout je nastavená na WEBSITE_TOMCAT_CONNECTION_TIMEOUThodnotu , která je výchozí hodnota 240000
  • maxThreads je nastavená na WEBSITE_CATALINA_MAXTHREADShodnotu , která je výchozí hodnota 200
  • maxConnections je nastavená na WEBSITE_CATALINA_MAXCONNECTIONShodnotu , která je výchozí hodnota 10000

Poznámka:

Nastavení connectionTimeout, maxThreads a maxConnections je možné ladit pomocí nastavení aplikace.

Následuje příklad příkazů rozhraní příkazového řádku, které můžete použít ke změně hodnot connectionTimeout, maxThreads nebo 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
  • Konektor používá adresu kontejneru místo 127.0.0.1.

Hostitelský počítač

<Host appBase="${site.appbase}" xmlBase="${site.xmlbase}" unpackWARs="${site.unpackwars}" workDir="${site.tempdir}" errorReportValveClass="com.microsoft.azure.appservice.AppServiceErrorReportValve" name="localhost" autoDeploy="true">
  • appBase je nastavená na AZURE_SITE_APP_BASEhodnotu , která výchozí hodnota je místní. WebappsLocalPath
  • xmlBase je nastavená na AZURE_SITE_HOMEhodnotu , která je výchozí hodnota /site/wwwroot
  • unpackWARs je nastavená na AZURE_UNPACK_WARShodnotu , která je výchozí hodnota true
  • workDir je nastavená na JAVA_TMP_DIRhodnotu , která výchozí nastavení TMP
  • errorReportValveClass používá náš vlastní ventil pro hlášení chyb.

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 je nastavená na AZURE_LOGGING_DIRhodnotu , která je výchozí hodnota home\logFiles
  • maxDays je na WEBSITE_HTTPLOGGING_RETENTION_DAYShodnotu , která je výchozí hodnotou 7. To odpovídá výchozí platformě protokolování aplikace.

V Linuxu má všechna stejná přizpůsobení a navíc:

  • Přidá do ventilu několik chyb a nahlašuje stránky:

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

Další kroky

Navštivte centrum pro vývojáře v Azure pro Javu a najděte referenční dokumentaci k Azure pro rychlý start, kurzy a referenční dokumentaci k Javě.