Sdílet prostřednictvím

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

Tento článek ukazuje nejběžnější konfiguraci nasazení a modulu runtime pro aplikace v Javě ve službě Azure App Service. Pokud používáte Azure App Service poprvé, měli byste si nejdřív přečíst rychlý start v Javě. Odpovědi na 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.

Azure App Service provozuje webové aplikace Java na plně spravované službě ve třech variantách.

  • Java Standard Edition (SE): Může spustit aplikaci nasazenou jako balíček Java Archive (JAR), který obsahuje vložený server (například Spring Boot, Quarkus, Dropwizard nebo aplikaci s vloženým serverem Tomcat nebo Jetty).
  • Tomcat: Integrovaný server Tomcat může spustit aplikaci nasazenou jako balíček archivu webových aplikací (WAR).
  • JBoss Enterprise Application Platform (EAP): Integrovaný server JBoss EAP může spustit aplikaci nasazenou jako balíček WAR nebo enterprise archive (EAR). Podporováno pro aplikace pro Linux v sadě cenových úrovní, které zahrnují Free, Premium v3 a Isolated v2.gti.

Zobrazení verze Javy

Pokud chcete zobrazit aktuální verzi Javy, spusťte v Azure 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"

Získání verze Javy v kontejneru Linuxu

Pro podrobnější informace o verzi v kontejneru Linuxu otevřete relaci SSH s kontejnerem. Zde je několik příkladů toho, co můžete spustit.

Pro zobrazení verze Java v SSH relaci:

java -version

Chcete-li zobrazit verzi serveru Tomcat v relaci SSH:

sh /usr/local/tomcat/version.sh

Nebo pokud je váš server Tomcat na vlastní místě, najděte version.sh pomocí:

find / -name "version.sh"

Zobrazení verze serveru EAP JBoss v relaci SSH:

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

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

Co se stane se zastaralými runtimy ve službě App Service?

Zastaralé verze runtime jsou organizací, která je spravuje, zrušeny nebo mají zásadní bezpečnostní zranitelnosti. Proto se odeberou z vytváření a konfigurace stránek na portálu. Pokud je zastaralý modul runtime skrytý na portálu, všechny aplikace, které stále používají tento modul runtime, budou dál běžet.

Pokud chcete vytvořit aplikaci se zastaralou verzí modulu runtime, která se už na portálu nezobrazuje, použijte Azure CLI, šablonu ARM nebo Bicep. Tyto alternativy nasazení umožňují vytvářet zastaralé moduly runtime, které byly odebrány na portálu, ale stále se podporují.

Pokud je modul runtime plně odebraný z platformy Služby App Service, obdrží vlastník předplatného Azure před odebráním e-mailové oznámení.

Nasazení vaší aplikace

Nástroje pro sestavení

Znalec

Pomocí modulu plug-in Maven pro Azure Web Apps můžete projekt snadno připravit 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 tak, ž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 plugin Gradle pro webové aplikace Azure přidáním pluginu do :

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

Integrovaná vývojová prostředí

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

Rozhraní API Kudu a OneDeploy

Nástroje pro nasazení, jako je Maven plugin, GitHub Actions používající azure/webapps-deploy@v3 a novější, nebo příkaz az webapp deploy, používají OneDeploy, který je vyvolán voláním /api/publish koncového bodu webu Kudu na pozadí. Další informace o tomto rozhraní API najdete v této dokumentaci.

Když se tyto metody nasazení použijí, automaticky přejmenují zadaný soubor JAR na app.jar během procesu nasazení. Bude umístěn pod /home/site/wwwwroot. Informace o nasazení souborů JAR do java SE najdete v této dokumentaci.

Poznámka

Pokud používáte alternativní metody, jako je FTP nebo starší rozhraní ZIPDeploy API, nebude tato metoda přejmenování zadaného souboru JAR vyvolána. Poznamenejte si to, pokud použijete textové pole Spouštěcí soubor v části Konfigurace portálu k explicitní volání souboru JAR.

Soubory WAR můžete nasadit do aplikace Tomcat podle této dokumentace. Pokud se použijí výše uvedené metody nasazení, automaticky přejmenují zadaný soubor War na app.war během procesu nasazení. Tato možnost bude umístěna pod /home/site/wwwwroot a ve výchozím nastavení podporuje pouze nasazení jednoho souboru WAR v části wwwroot. Toto nebude umístěno do /home/site/wwwroot/webapps složky jako při použití API pro nasazení, jako je WarDeploy. Pokud se chcete vyhnout problémům se strukturou souborů, doporučujeme použít pouze jeden nebo druhý typ nasazení.

Informace o nasazení souborů WAR do protokolu JBoss EAP najdete v této dokumentaci. Při použití OneDeploy to automaticky přejmenuje WAR soubor a app.war bude umístěn pod /home/site/wwwroot.

K nasazení souborů EAR použijte FTP. Aplikace EAR je nasazena do kořene kontextu definovaného v konfiguraci vaší aplikace. Pokud chcete, aby byla vaše webová aplikace obsluhována v kořenové cestě, ujistěte se, že vaše aplikace nastaví kontextový kořen na kořenovou cestu: <context-root>/</context-root>. Další informace naleznete v tématu Nastavení kontextového kořene webové aplikace.

Nenasazujte war ani soubor JAR pomocí ftp. Nástroj FTP je určen pro nahrávání spouštěcích skriptů, závislostí nebo jiných souborů pro běh. 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 některý z dostupných rewriterů adres URL, například UrlRewriteFilter.

Tomcat také poskytuje přepisový ventil.

JBoss EAP také poskytuje přepisový ventil.

Logování a ladění aplikací

Výkonnostní zprávy, vizualizace provozu a kontrolní prohlídky zdravotního stavu jsou dostupné pro každou aplikaci prostřednictvím portálu Azure. Další informace najdete v přehledu diagnostiky služby Azure App Service.

Přenášet diagnostické protokoly

K logům konzole vygenerovaným uvnitř kontejneru můžete přistupovat.

Protokolování kontejneru zapnete 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> a <resource-group-name> názvy, které jsou vhodné pro vaši webovou aplikaci.

Po zapnutí protokolování kontejneru spusťte následující příkaz, abyste viděli stream protokolu:

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

Pokud se protokoly konzoly nezobrazí okamžitě, zkontrolujte to znovu za 30 sekund.

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

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

Přístup ke konzoli SSH v systému Linux

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

Použijte příkaz az webapp ssh .

Pokud ještě nejste ověřeni, musíte se ověřit pomocí svého předplatného Azure, abyste se mohli připojit. Po úspěšném ověření se zobrazí shell v prohlížeči, kde můžete spouštět příkazy uvnitř svého kontejneru.

Připojení SSH

Poznámka

Všechny změny, které uděláte mimo /home adresář, se uloží do samotného kontejneru a nezachovají se za restartováním aplikace.

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

Nástroje pro odstraňování problémů v Linuxu

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

Profiler v Javě

Všechny moduly runtime Javy v Azure App Service přicházejí s nástrojem Java Development Kit (JDK) Flight Recorder pro profilaci úloh Javy. Můžete ho použít k zaznamenání prostředí Java Virtual Machine (JVM), událostí systému a aplikací a k řešení problémů ve vašich aplikacích.

Další informace o profileru Java najdete v dokumentaci k Azure Application Insights.

Java Flight Recorder

Všechny Java runtime na App Service obsahují Java Flight Recorder. Můžete ho použít k zaznamenání událostí prostředí JVM, systému a aplikací a k řešení problémů v aplikacích v Javě.

Připojte se ke službě App Service s protokolem SSH a spusťte jcmd příkaz, který zobrazí seznam všech spuštěných procesů Javy. Kromě samotného jcmd byste měli vidět, že vaše aplikace Java 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

Proveďte následující příkaz k zahájení 30sekundového záznamu JVM. Profiluje JVM a vytvoří soubor Java Flight Recorder (JFR) pojmenovaný jfr_example.jfr v domovském adresáři. Nahraďte 116 KÓD 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 záznamy pro daný proces Java.

Průběžný záznam

Můžete použít Java Flight Recorder ke kontinuálnímu profilování vaší aplikace Java s minimálním dopadem na výkon za běhu. Uděláte to tak, že 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í. Při spuštění aplikace se příkazu JAVA_OPTS předá obsah nastavení java 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

Po spuštění záznamu můžete aktuální data záznamu JFR.dump kdykoli vyřadit pomocí příkazu.

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

Analýza souborů JFR

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 (JMC). Pokyny, jak používat Java Mission Control, najdete v dokumentaci JMC a pokyny k instalaci.

Protokolování aplikace

Pokud chcete nakonfigurovat 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, postupujte následovně. Povolte protokolování aplikace prostřednictvím webu Azure Portal nebo v Azure CLI. Pokud potřebujete delší dobu uchovávání, nakonfigurujte aplikaci tak, aby zapisuje výstup do kontejneru Blob Storage.

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

Protokolování služby Azure Blob Storage pro linuxové aplikace je možné nakonfigurovat jenom pomocí služby Azure Monitor.

Pokud vaše aplikace pro trasování používá logback nebo Log4j , můžete tyto trasování předat ke kontrole do Azure Application Insights. Použijte pokyny ke konfiguraci rámce protokolování v části Prozkoumání trasovacích protokolů v Javě v nástroji Application Insights.

Poznámka

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

Přizpůsobení a ladění

Azure App Service podporuje předběžné ladění a přizpůsobení prostřednictvím webu Azure Portal a Azure CLI. Přečtěte si následující články o konfiguraci webových aplikací, které nejsou specifické pro Java.

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

Nastavte nastavení aplikace JAVA_COPY_ALL na true pro kopírování obsahu vaší aplikace na místního pracovníka ze sdíleného souborového systému. Toto nastavení pomáhá řešit problémy se zamykáním souborů.

Nastavit možnosti běhu Javy

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 pomocí pluginu Maven, přidejte do sekce pluginu Azure značky pro nastavení a hodnoty. Následující příklad nastavuje specifickou minimální a maximální velikost Java heapu.

<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 web.config soubor.

Služba App Service ve výchozím nastavení nastaví maximální velikost haldy JVM na 70% celkové paměti dostupné pro plán služby App Service. Pokud chcete výchozí nastavení zakázat, můžete použít nastavení aplikace WEBSITE_DISABLE_JAVA_HEAP_CONFIGURATION="true".

Zvýšení výkonu aplikace na platformě může zahrnovat úpravu velikosti haldy tak, aby lépe vyhovovala vašim konkrétním potřebám. Při ladění nastavení haldy aplikace si projděte podrobnosti plánu služby App Service a zvažte požadavky více aplikací a slotů nasazení, abyste našli optimální přidělení paměti.

Zapněte webové sockety

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

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

Poté restartujte svou aplikaci:

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

Nastavit výchozí 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 nastavení aplikace nakonfigurovat pomocí modulu plug-in App Service Maven. Přidejte názvy nastavení a hodnotové značky do konfigurace pluginu.

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

Předkompilní soubory JSP

Pro zlepšení výkonu aplikací Tomcat můžete zkompilovat své JSP soubory před jejich nasazením na App Service. Můžete použít modul plug-in Maven , který poskytuje Apache Sling, nebo použít tento soubor sestavení Ant.

Ignorovat zprávu 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 můžete klidně ignorovat. /robots933456.txt je zástupná cesta URL, kterou používá App Service k ověření, zda je kontejner schopen zpracovávat požadavky. Odpověď 404 značí, že cesta neexistuje, a signalizuje app Service, že kontejner je v pořádku a 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 opravená verze automaticky aktualizovala, jakmile budou k dispozici nové menší verze. Ve většině případů by produkční aplikace měly používat připnuté verze opravy JVM, které brání neplánovaným výpadkům během automatické aktualizace verze opravy. Všechny webové aplikace Java používají 64bitové JVM a není konfigurovatelné.

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

Pokud se rozhodnete připnout vedlejší verzi, musíte pravidelně aktualizovat vedlejší verzi JVM v aplikaci. Aby bylo zajištěno, že vaše aplikace poběží na novější vedlejší verzi, vytvořte testovací slot a zvyšte vedlejší verzi na tomto testovacím slotu. Jakmile potvrdíte, že aplikace běží správně na nové menší verzi, můžete prohodit přípravné a produkční sloty.

Spusťte rozhraní příkazového řádku JBoss

V relaci SSH aplikace JBoss EAP 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 protokol EAP JBoss v životním cyklu serveru, možná nebudete moct připojit. Počkejte několik minut a zkuste to znovu. Tento přístup je užitečný pro rychlé kontroly aktuálního stavu vašeho serveru (například pro zjištění, zda je datový zdroj správně nakonfigurován).

Změny, které provedete na serveru pomocí rozhraní příkazového řádku JBoss v relaci SSH, se po restartování aplikace neuchovávají. Pokaždé, když se aplikace spustí, JBoss EAP server začne s č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 EAP 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 Java SE, Tomcat nebo JBoss EAP ve službě Azure App Service.

Případně můžete ručně nakonfigurovat App Service tak, aby při spuštění spouštěl libovolný soubor. Napří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:

Shlukování

Aplikační služba podporuje clustering pro JBoss EAP verze 7.4.1 a novější. 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ě. Nastavení clusterování 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 EAP 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 JBoss EAP používají FILE_PING protokol zjišťování JGroups ke zjišťování nových instancí a uchování informací o clusteru (například členové clusteru, jejich identifikátory a JEJICH IP adresy). Ve službě App Service jsou tyto soubory pod /home/clusterinfo/. První instance EAP, která se spustí, získá oprávnění pro čtení/zápis do souboru obsahujícího členství v clusteru. Ostatní instance čtou soubor, najdou primární uzel a koordinují se s tímto uzlem, aby byly zahrnuty do clusteru a přidány do souboru.

Poznámka

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

Plány služby App Service úrovně Premium V3, Premium V4 a Izolované V2 je možné volitelně distribuovat napříč zónami dostupnosti ke zlepšení odolnosti a spolehlivosti pro klíčové obchodní úlohy. Tato architektura se také označuje jako redundance zón. Funkce shlukování JBoss EAP je kompatibilní s funkcí zónové redundance.

Pravidla automatického škálování

Když konfigurujete pravidla 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 můžete vertikálně snížit kapacitu pomocí následujících možností:

  • Operace: "Snížit počet o"
  • Chlazení: "5 minut" nebo více
  • Počet instancí: 1

Nemusíte postupně přidávat instance (horizontálně navyšovat kapacitu). Do clusteru můžete přidat více instancí najednou.

Plány App Service

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

Životní cyklus serveru JBoss EAP

Aplikace EAP JBoss ve službě App Service před spuštěním serveru prochází pěti různými fázemi:

  1. Fáze nastavení prostředí
  2. Fáze spuštění serveru
  3. Fáze konfigurace serveru
  4. Fáze nasazení aplikace
  5. Fáze opětovného načtení serveru

Podrobnosti a příležitosti k přizpůsobení (například prostřednictvím nastavení aplikace) najdete v následující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 jsou poskytovány platformou /var/ssl/certs v adresáři a jsou načteny do $JRE_HOME/lib/security/cacerts.
    • Privátní certifikáty jsou poskytovány platformou v /var/ssl/private adresáři a jsou načteny 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.keyStorePassworda javax.net.ssl.keyStoreType jsou přidány do JAVA_OPTS proměnné prostředí.
  • Určuje se některá počáteční konfigurace prostředí JVM, například adresáře protokolování a parametry haldy paměti Java:
    • Pokud ve vašem nastavení aplikace –Xms poskytnete příznaky –Xmx nebo JAVA_OPTS pro paměť, tyto hodnoty přepíší hodnoty poskytované platformou.
    • 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) při zastavení protokolu JBoss EAP.
  • 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 EAP pomocí clustering konfigurace. Jinak se použije konfigurace standalone.
    • clustering Pro konfiguraci se použije konfigurační soubor standalone-azure-full-ha.xml serveru.
    • standalone Pro konfiguraci se použije konfigurační soubor standalone-full.xml serveru.

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

  • Pokud je JBoss EAP spuštěn v konfiguraci clustering:
    • Každá instance EAP JBoss přijímá interní identifikátor mezi 0 a počtem instancí, na které je aplikace škálovaná.
    • Pokud jsou v cestě k úložišti transakcí pro tuto instanci serveru (pomocí jeho interního identifikátoru) nalezeny nějaké soubory, znamená to, že tato instance serveru nahrazuje identickou instanci služby. Druhá instance služby se dříve chybově ukončila a opustila nepotvrzené transakce. Server je nakonfigurován tak, aby pokračoval v práci na těchto transakcích.
  • Bez ohledu na to, jestli se JBoss EAP spouští v clustering nebo standalone konfiguraci, pokud je server ve verzi 7.4 nebo novější a běhové prostředí používá Javu 17, je konfigurace aktualizována pro zapnutí subsystému Elytron pro zabezpečení.
  • Pokud nastavíte WEBSITE_JBOSS_OPTS konfiguraci aplikace, hodnota se předá do spouštěcího skriptu 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 EAP.

3. Fáze konfigurace serveru

  • Na začátku této fáze služba App Service nejprve čeká, až budou server JBoss EAP i rozhraní pro správu připravené přijímat požadavky, než bude pokračovat. Pokud je služba Application Insights povolená, může tento proces trvat několik sekund.

  • Jakmile je server JBoss EAP i rozhraní pro správu připravené, služba App Service provede následující akce:

    • Přidá modul azure.appserviceJBoss EAP, 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 režim bez barev, takže soubory protokolu nejsou plné sekvencí pro únik barev.
    • Nastaví integraci s protokoly Azure Monitor.
    • Aktualizuje vazbové IP adresy rozhraní WSDL (Web Services Description Language) a rozhraní pro správu.
    • Přidá modul azure.appservice.easyauth JBoss EAP pro integraci s ověřováním služby App Service a ID Microsoft Entra.
    • Aktualizuje konfiguraci logování přístupových záznamů a název a rotaci hlavního souboru serverového logu.

  • Pokud není definované nastavení WEBSITE_SKIP_AUTOCONFIGURE_DATABASE aplikace, služba App Service automaticky dedetuje adresy URL služby Java Database Connectivity (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, přidá zdroj dat pro každou z adres URL JDBC a nastaví název rozhraní Java Pro pojmenování a adresářové rozhraní (JNDI) pro každý zdroj dat na java:jboss/env/jdbc/<app-setting-name>_DS, kde <app-setting-name> je název nastavení aplikace.

  • Pokud je konfigurace clustering povolena, zkontroluje se, zda je konzolový logger nakonfigurován.

  • Pokud jsou do /home/site/libs adresáře nasazené soubory JAR, vytvoří se nový globální modul se všemi těmito soubory JAR.

  • Na konci této fáze spustí služba App Service vlastní skript pro spuštění, pokud existuje. Logika vyhledávání pro vlastní spouštěcí skript je definována takto:

    • Pokud jste nakonfigurovali spouštěcí příkaz (například prostřednictvím webu Azure Portal nebo Azure CLI), 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řeba sudo), takže může nainstalovat linuxové balíčky nebo spustit JBoss CLI k provádění dalších příkazů pro instalaci/přizpůsobení JBoss EAP, jako je vytváření datových zdrojů a instalace adaptérů prostředků. 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 protokolu EAP JBoss tak, že hledá v následujících umístěních podle priority:

  • Pokud jste nakonfigurovali nastavení aplikace WEBSITE_JAVA_WAR_FILE_NAME, nasazujte soubor, který je tímto nastavením určen.
  • Pokud /home/site/wwwroot/app.war existuje, nasaďte ho.
  • Pokud existují nějaké další soubory EAR či WAR v /home/site/wwwroot, nasaďte je.
  • Pokud /home/site/wwwroot/webapps existuje, nasaďte v něm soubory a adresáře. Soubory WAR jsou nasazeny jako samotné aplikace a adresáře jsou nasazeny jako "exploded" (nekomprimované) webové aplikace.
  • Pokud existují /home/site/wwwrootně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 nejsou nalezeny žádné nasaditelné soubory, nasaďte výchozí úvodní stránku (parkovací stránku) v kořenovém kontextu.

5. Fáze znovunačtení serveru

  • Po dokončení kroků nasazení se server JBoss EAP 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 běží, dokud není aplikace App Service zastavena nebo restartována. Aplikaci App Service můžete ručně zastavit nebo restartovat, nebo spustit restart při nasazení souborů nebo při provádění změn v konfiguraci aplikace App Service.
  • Pokud se server JBoss EAP v konfiguraci clustering ukončí neobvykle, spustí se konečná funkce emit_alert_tx_store_not_empty. Funkce zkontroluje, jestli proces EAP JBoss opustil soubor neprázdného ú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 Tomcat

Poznámka

Tato část platí jenom pro Linux.

Vývojáři v Javě mohou přizpůsobit nastavení serveru, řešit problémy a s jistotou nasadit aplikace na Tomcat, pokud znají soubor server.xml a podrobnosti o konfiguraci Tomcat. Možné úpravy zahrnují:

  • Přizpůsobení konfigurace Tomcat: Když rozumíte souboru server.xml a podrobnostem konfigurace Tomcatu, můžete nastavení serveru vyladit tak, aby odpovídalo potřebám jejich aplikací.
  • Ladění: Když je aplikace nasazena na server Tomcat, vývojáři potřebují znát konfiguraci serveru, aby mohli ladit případné problémy, které by mohly nastat. Tento proces zahrnuje kontrolu protokolů serveru, zkoumání konfiguračních souborů a identifikaci chyb, ke kterým může dojít.
  • Řešení problémů s Tomcatem: Nevyhnutelně se Java vývojáři setkávají s problémy se svým Tomcat serverem, jako jsou problémy s výkonem nebo chyby v konfiguraci. Když rozumíte server.xml souboru a podrobnostem konfigurace Tomcatu, můžou vývojáři tyto problémy rychle diagnostikovat a řešit, což může ušetřit čas a úsilí.
  • Nasazení aplikací na Tomcat: Aby mohli vývojáři nasadit Java webovou aplikaci na Tomcat, musí vědět, jak nakonfigurovat soubor server.xml a další nastavení Tomcatu. Tyto podrobnosti potřebujete pochopit, abyste úspěšně nasadili aplikace a zajistili, že běží hladce na serveru.

Při vytváření aplikace s integrovaným serverem Tomcat pro hostování zátěže Java (soubor WAR nebo soubor JAR) získáte určité nastavení pro konfiguraci Tomcat, které je dostupné již od začátku. 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é se po spuštění použijí nad server.xml pro distribuci Tomcat. Mezi tyto transformace patří změny nastavení konektoru, hostitele a ventilu .

Nejnovější verze Tomcat mají server.xml (8.5.58 a 9.0.38 a novější). Starší verze Tomcatu nevyužívají transformace, což může vést k odlišným vlastnostem 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 nastaveno na 16384.
  • URIEncoding je nastaveno na UTF-8.
  • connectionTimeout je nastavena na WEBSITE_TOMCAT_CONNECTION_TIMEOUThodnotu , která má výchozí hodnotu 240000.
  • maxThreads je nastavena na WEBSITE_CATALINA_MAXTHREADShodnotu , která má výchozí hodnotu 200.
  • maxConnections je nastavena na WEBSITE_CATALINA_MAXCONNECTIONShodnotu , která má výchozí hodnotu 10000.

Poznámka

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

Následují příklady 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.

Hostitel

<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 nastavena na AZURE_SITE_APP_BASEhodnotu , která je ve výchozím nastavení nastavena na místní WebappsLocalPath.
  • xmlBase je nastavena na AZURE_SITE_HOMEhodnotu , která má výchozí hodnotu /site/wwwroot.
  • unpackWARs je nastavena na AZURE_UNPACK_WARShodnotu , která má výchozí hodnotu true.
  • workDir je nastavena na JAVA_TMP_DIR, což je výchozí 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 nastavena na AZURE_LOGGING_DIRhodnotu , která má výchozí hodnotu home\logFiles.
  • maxDays je nastavena na WEBSITE_HTTPLOGGING_RETENTION_DAYShodnotu , která má výchozí hodnotu 7. Tato hodnota odpovídá výchozímu nastavení platformy protokolování aplikace.

Na Linuxu má všechna stejná přizpůsobení a přidává několik chybových a oznamovacích stránek.

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

Související obsah

Navštivte centrum Azure pro vývojáře v Javě, kde najdete rychlé návody, tutoriály a referenční dokumentaci k Azure i Javě.