Megosztás a következőn keresztül:

Java SE, Tomcat vagy JBoss EAP-alkalmazás üzembe helyezése és konfigurálása az Azure App Service-ben

Ez a cikk a Java-alkalmazások azure App Service-ben történő leggyakoribb üzembe helyezési és futtatókörnyezeti konfigurációját mutatja be. Ha először használja az Azure App Service-t, először olvassa el a Java rövid útmutatóját. Az App Service használatával kapcsolatos általános kérdésekre adott válaszokat az App Service gyakori kérdései között találja, amelyek nem a Java-fejlesztésre vonatkoznak.

Azure-alkalmazás szolgáltatás Java-webalkalmazásokat futtat egy teljes körűen felügyelt szolgáltatáson három változatban:

  • Java Standard Edition (SE): Futtathat egy Java Archive (JAR) csomagként üzembe helyezett alkalmazást, amely beágyazott kiszolgálót (például Spring Boot, Quarkus, Dropwizard vagy beágyazott Tomcat- vagy Jetty-kiszolgálóval rendelkező alkalmazást) tartalmaz.
  • Tomcat: A beépített Tomcat-kiszolgáló webalkalmazás-archívumként (WAR) üzembe helyezett alkalmazást futtathat.
  • JBoss Enterprise Application Platform (EAP): A beépített JBoss EAP-kiszolgáló futtathat war vagy vállalati archívum (EAR) csomagként üzembe helyezett alkalmazást. Támogatott Linux-alkalmazásokhoz olyan tarifacsomagokban, amelyek tartalmazzák az ingyenes, prémium v3-at és az izolált v2.gti-t

A Java-verzió megjelenítése

Az aktuális Java-verzió megjelenítéséhez futtassa a következő parancsot az Azure Cloud Shellben:

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

Az összes támogatott Java-verzió megjelenítéséhez futtassa a következő parancsot a Cloud Shellben:

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

A Java-verzió lekérése a Linux-tárolóban

A Linux-tárolóban részletesebb verzióinformációkért nyisson meg egy SSH-munkamenetet a tárolóval. Íme néhány példa a futtatható feladatokra.

A Java-verzió megtekintése az SSH-munkamenetben:

java -version

A Tomcat-kiszolgáló verziójának megtekintése az SSH-munkamenetben:

sh /usr/local/tomcat/version.sh

Vagy ha a Tomcat-kiszolgáló egyéni helyen található, keresse meg a version.sh-t a következő módon:

find / -name "version.sh"

A JBoss EAP-kiszolgáló verziójának megtekintése az SSH-munkamenetben:

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

A verziótámogatásról további információt az App Service nyelvi futtatókörnyezet támogatási szabályzatában talál.

Mi történik az elavult futtatókörnyezetekkel az App Service-ben?

Az elavult futtatókörnyezeteket a fenntartó szervezet elavultnak nyilvánítja, vagy jelentős biztonsági réseket fedez fel ezekben. Ennek megfelelően el lesznek távolítva a portál lapjainak létrehozása és konfigurálása során. Ha egy elavult futtatókörnyezet el van rejtve a portálon, a futtatókörnyezetet még használó alkalmazások továbbra is futnak.

Ha olyan elavult futtatókörnyezeti verziójú alkalmazást szeretne létrehozni, amely már nem jelenik meg a portálon, használja az Azure CLI-t, az ARM-sablont vagy a Bicep-et. Ezek az üzembe helyezési alternatívák lehetővé teszik elavult futtatókörnyezetek létrehozását, amelyeket eltávolítottak a portálról, de továbbra is támogatottak.

Ha egy futtatókörnyezet teljesen el lett távolítva az App Service-platformról, az Azure-előfizetés tulajdonosa e-mailben értesítést kap az eltávolítás előtt.

Az alkalmazás üzembe helyezése

Építőeszközök

Maven

Az Maven beépülő modult az Azure Web Apps-hoz használva egyszerűen előkészítheti projektjét egyetlen paranccsal a projekt alapértelmezett könyvtárában.

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

Ez a parancs hozzáad egy beépülő modult azure-webapp-maven-plugin és a kapcsolódó konfigurációt, és megkéri, hogy válasszon ki egy meglévő Azure-webalkalmazást, vagy hozzon létre egy újat. A konfiguráció során megpróbálja észlelni, hogy az alkalmazást telepíteni kell-e a Java SE-ben, a Tomcatben vagy (csak Linuxon) a JBoss EAP-ben. Ezután a Következő paranccsal telepítheti a Java-alkalmazást az Azure-ban:

mvn package azure-webapp:deploy

Íme egy mintakonfiguráció a következőben 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. Az Azure Web Apps Gradle beépülő moduljának beállításához adja hozzá a beépülő modult az alábbi módon: build.gradle

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

  2. Konfigurálja a webalkalmazás adatait. A megfelelő Azure-erőforrások akkor jönnek létre, ha nem léteznek. Íme egy mintakonfiguráció. Részletekért tekintse meg ezt a dokumentumot.

    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. Üzembe helyezés egyetlen paranccsal.

    gradle azureWebAppDeploy

Integrált fejlesztőkörnyezetek

Az Azure zökkenőmentes Java App Service-fejlesztési élményt nyújt a népszerű Java integrált fejlesztési környezetekben (IDE-kben), beleértve a következőket:

Kudu és OneDeploy API-k

Az üzembehelyezési ügyfelek, mint például a Maven beépülő modul, a GitHub Actions a azure/webapps-deploy@v3 és újabb verziókkal, vagy az az webapp deploy parancs a OneDeploy-t használja, amely a Kudu webhely /api/publish végpontjának meghívásával működik. Az API-val kapcsolatos további információkért tekintse meg ezt a dokumentációt.

Ha ezeket az üzembehelyezési módszereket használják, automatikusan átnevezik a megadott JAR-fájlt app.jar az üzembe helyezési folyamat során. Ezt a program a következő alá helyezi: /home/site/wwwwroot. A JAR-fájlok Java SE-ben való üzembe helyezéséhez tekintse meg ezt a dokumentációt.

Feljegyzés

Ha olyan alternatív metódusokat használ, mint az FTP vagy a régebbi ZipDeploy API-k, a megadott JAR-fájl átnevezésének ez a metódusa nem lesz meghívva. Jegyezze fel ezt, ha a portál Konfiguráció szakaszában található Indítási fájl szövegmezővel kifejezetten meghívja a JAR-fájlt.

A dokumentációt követve WAR-fájlokat helyezhet üzembe a Tomcat-alkalmazásban. A fenti üzembehelyezési módszerek használata esetén a rendszer automatikusan átnevezi a megadott War-fájlt app.war az üzembe helyezési folyamat során. Ez a /home/site/wwwwroot alatt fog elhelyezkedni, és alapértelmezés szerint csak egy WAR-fájl telepítését támogatja a wwwroot alatt. Ez nem kerül a címtár alá, ahogyan az üzembe helyezési API-k, például a /home/site/wwwroot/webapps WarDeploy használatakor látható. A fájlstruktúra ütközéseivel kapcsolatos problémák elkerülése érdekében javasoljuk, hogy csak az egyik vagy a másik központi telepítési típust használja.

A WAR-fájlok JBoss EAP-ban való üzembe helyezéséhez tekintse meg ezt a dokumentációt. A OneDeploy használata esetén ez automatikusan átnevezi a WAR-fájlt app.war , és az alá /home/site/wwwrootkerül.

Az EAR-fájlok üzembe helyezéséhez használja az FTP-t. Az EAR-alkalmazás az alkalmazás konfigurációjában meghatározott környezetgyökérre van üzembe helyezve. Ha azt szeretné, hogy a webalkalmazás a gyökér útvonalon legyen kiszolgálva, győződjön meg arról, hogy az alkalmazás a kontextus gyökerét a gyökér elérési útra állítja: <context-root>/</context-root>. További információ: A webalkalmazás környezetgyökerének beállítása.

Ne telepítse a WAR-t vagy a JAR-t FTP-vel. Az FTP-eszköz indítási szkriptek, függőségek vagy más futtatókörnyezeti fájlok feltöltésére lett kialakítva. Nem ez az optimális választás a webalkalmazások üzembe helyezéséhez.

URL-cím átírása vagy átirányítása

URL-cím átírásához vagy átirányításához használja az egyik elérhető URL-írót, például az UrlRewriteFiltert.

A Tomcat egy újraírási szelepet is biztosít.

A JBoss EAP egy újraírási szelepet is biztosít.

Alkalmazások naplózása és hibakeresése

A teljesítményjelentések, a forgalmi vizualizációk és az állapotellenőrzések minden alkalmazáshoz elérhetők az Azure Portalon keresztül. További információkért tekintse meg az Azure App Service diagnosztikai áttekintését.

Diagnosztikai naplók streamelése

A tárolón belülről létrehozott konzolnaplókhoz hozzáférhet.

A tárolónaplózás bekapcsolásához futtassa a következő parancsot:

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

Cserélje le <app-name> és <resource-group-name> a webalkalmazásnak megfelelő nevekre.

A tárolónaplózás bekapcsolása után futtassa a következő parancsot a naplóstream megtekintéséhez:

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

Ha a konzolnaplók nem jelennek meg azonnal, ellenőrizze újra 30 másodpercen belül.

Ha bármikor le szeretné állítani a naplóstreamelést, válassza a CtrlC+.

További információ: Streamnaplók a Cloud Shellben.

SSH-konzolhozzáférés Linuxon

Ha közvetlen SSH-munkamenetet szeretne megnyitni a tárolóval, az alkalmazásnak futnia kell.

Használja az az webapp ssh parancsot.

Ha még nem végezte el a hitelesítést, a csatlakozáshoz el kell végeznie a hitelesítést az Azure-előfizetésével. A hitelesítés után egy böngészőn belüli felület jelenik meg, ahol a tárolón belül futtathat parancsokat.

SSH-kapcsolat

Feljegyzés

A /home könyvtáron kívül végzett módosítások a tároló magában tárolódnak, és nem őrződnek meg az alkalmazás újraindítása után.

Ha távoli SSH-munkamenetet szeretne megnyitni a helyi gépről, olvassa el az SSH-munkamenet megnyitása távoli rendszerhéjból című témakört.

Linux hibaelhárító eszközök

A beépített Java-rendszerképek az Alpine Linux operációs rendszeren alapulnak. A csomagkezelővel telepítheti a apk hibaelhárítási eszközöket vagy parancsokat.

Java-profilkészítő

Az Azure App Service összes Java-futtatókörnyezetéhez elérhető a Java Development Kit (JDK) Flight Recorder a Java-számítási feladatok profilkészítéséhez. Segítségével rögzítheti a Java virtuális gépet (JVM), a rendszer- és alkalmazáseseményeket, és elháríthatja az alkalmazásokkal kapcsolatos problémákat.

A Java-profilkészítőről az Azure Application Insights dokumentációjában olvashat bővebben.

Java Repülésrögzítő

Az App Service összes Java-futtatókörnyezete a Java Flight Recordert használja. Segítségével JVM-, rendszer- és alkalmazáseseményeket rögzíthet, és elháríthatja a Java-alkalmazások problémáit.

SSH az App Service-be, és futtassa a parancsot az jcmd összes futó Java-folyamat listájának megtekintéséhez. A jcmd mellett látni kell, hogy a Java-alkalmazás folyamata fut egy folyamatazonosítóval (PID).

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

Hajtsa végre a következő parancsot a JVM 30 másodperces felvételének elindításához. Profilt készít a JVM-ről, és létrehoz egy Java Flight Recorder (JFR) fájlt jfr_example.jfr a kezdőkönyvtárban. Cserélje le 116 a Java-alkalmazás PID-jével.

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

A 30 másodperces időköz alatt ellenőrizheti, hogy a felvétel folyamatban van-e úgy, hogy futtatja a jcmd 116 JFR.check parancsot. A parancs az adott Java-folyamat összes felvételét megjeleníti.

Folyamatos rögzítés

A Java Flight Recorder használatával folyamatosan profilt készíthet a Java-alkalmazásról, minimális hatással a futtatókörnyezet teljesítményére. Ehhez futtassa a következő Azure CLI-parancsot a szükséges konfigurációval elnevezett JAVA_OPTS alkalmazásbeállítás létrehozásához. Az alkalmazásbeállítás tartalma a JAVA_OPTS parancsnak lesz átadva az java alkalmazás indításakor.

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

A felvétel indítása után a JFR.dump parancs használatával bármikor kiírhatja az aktuális rögzítési adatokat.

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

JFR-fájlok elemzése

Az FTPS használatával töltse le a JFR-fájlt a helyi gépre. A JFR-fájl elemzéséhez töltse le és telepítse a Java Mission Controlt (JMC). A Java Mission Control használatára vonatkozó utasításokért tekintse meg a JMC dokumentációját és a telepítési utasításokat.

Alkalmazásnaplózás

Ha úgy szeretné konfigurálni az App Service-t, hogy az alkalmazás standard konzolkimenetét és standard konzolhibáit írja a helyi fájlrendszerbe vagy az Azure Blob Storage-ba, tegye a következőket. Alkalmazásnaplózás engedélyezése az Azure Portalon vagy az Azure CLI-ben. Ha hosszabb megőrzésre van szüksége, konfigurálja az alkalmazást úgy, hogy kimenetet írjon egy Blob Storage-tárolóba.

A Java- és a Tomcat-alkalmazásnaplók a /home/LogFiles/Application/ címtárban találhatók.

A Linux-alapú alkalmazások Azure Blob Storage-naplózása csak az Azure Monitor használatával konfigurálható.

Ha az alkalmazás a logbacket vagy a Log4j-t használja a nyomkövetéshez, ezeket a nyomkövetéseket továbbíthatja áttekintésre az Azure Application Insightsba. Használja a naplózási keretrendszer konfigurációs utasításait az Application Insights Java-nyomkövetési naplóinak feltárására.

Feljegyzés

Ismert biztonsági rés CVE-2021-44228miatt mindenképpen használja a Log4j 2.16-os vagy újabb verzióját.

Testreszabás és finomhangolás

Az Azure App Service támogatja a beépített hangolást és testreszabást az Azure Portalon és az Azure CLI-vel. Tekintse át a nem Java-specifikus webalkalmazás-konfigurációval kapcsolatos alábbi cikkeket:

Az alkalmazás tartalmának helyi másolása

Állítsa be az alkalmazásbeállítást JAVA_COPY_ALL úgy, hogy true, annak érdekében, hogy az alkalmazás tartalmát a megosztott fájlrendszerből a helyi feldolgozóba másolja. Ez a beállítás segít a fájlzárolási problémák megoldásában.

Java-futtatókörnyezet beállításainak megadása

A lefoglalt memória vagy más JVM-futtatókörnyezet beállításainak beállításához hozzon létre egy alkalmazásbeállítást a beállításokkal együttJAVA_OPTS. Az App Service környezeti változóként továbbítja ezt a beállítást a Java-futtatókörnyezetnek az indításkor.

Az Azure Portalon a webalkalmazás Alkalmazásbeállítások területén hozzon létre egy új alkalmazásbeállítást JAVA_OPTS , amely más beállításokat is tartalmaz, például -Xms512m -Xmx1204m.

Az Azure Portalon a webalkalmazás Alkalmazásbeállítások területén hozzon létre egy új alkalmazásbeállítást CATALINA_OPTS , amely más beállításokat is tartalmaz, például -Xms512m -Xmx1204m.

Ha az alkalmazásbeállítást a Maven beépülő modulból szeretné konfigurálni, adja hozzá a beállítási/értékcímkéket az Azure beépülő modul szakaszában. Az alábbi példa egy meghatározott minimális és maximális Java-halomméretet állít be:

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

Feljegyzés

A Tomcat Windows App Service-en való használatakor nem kell web.config fájlt létrehoznia.

Az App Service alapértelmezés szerint a JVM maximális halomméretét 70% állítja be az App Service-csomaghoz rendelkezésre álló teljes memóriamennyiséghez. Az alapértelmezett beállítás letiltásához az WEBSITE_DISABLE_JAVA_HEAP_CONFIGURATION="true" alkalmazásbeállítást használhatja.

Az alkalmazás teljesítményének növelése a platformon magában foglalhatja a halomméretnek az adott igényeknek jobban megfelelő módosítását. Az alkalmazás halombeállításainak finomhangolásakor tekintse át az App Service-csomag részleteit, és tekintse át több alkalmazás és üzembehelyezési hely követelményeit, hogy megtalálja az optimális memóriafoglalást.

Webes socketek bekapcsolása

Kapcsolja be a webes szoftvercsatornák támogatását az Azure Portalon az alkalmazás alkalmazásbeállításaiban . A beállítás érvénybe lépéséhez újra kell indítania az alkalmazást.

A webes szoftvercsatornák támogatásának bekapcsolása az Azure CLI-vel a következő paranccsal:

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

Ezután indítsa újra az alkalmazást:

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

Alapértelmezett karakterkódolás beállítása

Az Azure Portalon a webalkalmazás Alkalmazásbeállítások területén hozzon létre egy új, értékekkel JAVA_OPTSelnevezett -Dfile.encoding=UTF-8 alkalmazásbeállítást.

Másik lehetőségként az App Service Maven beépülő modullal konfigurálhatja az alkalmazásbeállítást. Adja hozzá a beállításnevet és az értékcímkéket a beépülő modul konfigurációjában:

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

Precompile JSP-fájlok

A Tomcat-alkalmazások teljesítményének javítása érdekében az App Service-ben való üzembe helyezés előtt lefordíthatja a JSP-fájlokat. Használhatja az Apache Sling által biztosított Maven beépülő modult , vagy használhatja ezt az Ant buildfájlt.

A robotok933456 üzenetének figyelmen kívül hagyása a naplókban

A tárolónaplókban a következő üzenet jelenhet meg:

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

Az üzenet biztonságosan figyelmen kívül hagyható. /robots933456.txt egy olyan próba URL-cím, amelyet az App Service annak a vizsgálatára használ, hogy a tároló képes-e a kérések kiszolgálására. A 404-válasz azt jelzi, hogy az elérési út nem létezik, és jelzi az App Service-nek, hogy a tároló kifogástalan állapotban van, és készen áll a kérésekre való válaszadásra.

Java-futtatókörnyezeti verzió kiválasztása

Az App Service lehetővé teszi, hogy a felhasználók kiválasztják a JVM főverzióját, például a Java 8-at vagy a Java 11-et, valamint a javítás verzióját, például az 1.8.0_232-es vagy a 11.0.5-ös verziót. Dönthet úgy is, hogy az új alverziók elérhetővé válásával automatikusan frissíti a javításverziót. A legtöbb esetben az éles alkalmazásoknak rögzített patch JVM verziók használatát kellene választaniuk, amelyek megakadályozzák a váratlan leállásokat a patch verziók automatikus frissítése során. Minden Java-webalkalmazás 64 bites JVM-eket használ, és nem konfigurálható.

Ha Tomcat-et használ, dönthet úgy, hogy rögzíti a Tomcat patch verzióját. Windows rendszeren a JVM és a Tomcat javításverzióit egymástól függetlenül rögzítheti. Linuxon rögzítheti a Tomcat javításverzióját. A JVM javításverziója is rögzítve van, de külön nem konfigurálható.

Ha azt választja, hogy rögzíti az alverziót, akkor rendszeresen frissítenie kell a JVM alverzióját az alkalmazásban. Annak érdekében, hogy az alkalmazás az újabb alverzión fusson, hozzon létre egy átmeneti pontot, és növelje az alverziót az előkészítési ponton. Miután meggyőződett arról, hogy az alkalmazás megfelelően fut az új alverzióban, felcserélheti az előkészítési és éles pontokat.

A JBoss parancssori felületének futtatása

A JBoss EAP alkalmazás SSH-munkamenetében a JBoss CLI a következő paranccsal futtatható:

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

Attól függően, hogy a JBoss EAP hol található a kiszolgáló életciklusában, előfordulhat, hogy nem tud csatlakozni. Várjon néhány percet, majd próbálkozzon újra. Ez a módszer hasznos az aktuális kiszolgálóállapot gyors ellenőrzéséhez (például annak ellenőrzéséhez, hogy egy adatforrás megfelelően van-e konfigurálva).

A kiszolgálón az SSH-munkamenetben a JBoss parancssori felülettel végzett módosítások sem maradnak meg az alkalmazás újraindítása után. Az alkalmazás minden indításakor a JBoss EAP-kiszolgáló tiszta telepítéssel kezdődik. Az indítási életciklus során az App Service végrehajtja a szükséges kiszolgálókonfigurációkat, és üzembe helyezi az alkalmazást. A JBoss EAP-kiszolgálón végzett állandó módosítások elvégzéséhez használjon egyéni indítási szkriptet vagy indítási parancsot. Egy teljes körű példáért lásd: Adatforrások konfigurálása Java SE, Tomcat vagy JBoss EAP-alkalmazáshoz az Azure App Service-ben.

Másik lehetőségként manuálisan is konfigurálhatja az App Service-t úgy, hogy bármilyen fájlt futtatjon indításkor. Példa:

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

A futtatható parancssori felületi parancsokkal kapcsolatos további információkért lásd:

Klaszterezés

Az App Service a JBoss EAP 7.4.1-es és újabb verziók fürtözését támogatja. A fürtözés engedélyezéséhez a webalkalmazásnak integrálva kell lennie egy virtuális hálózattal. Amikor a webalkalmazás integrálva van egy virtuális hálózattal, újraindul, és a JBoss EAP telepítése automatikusan fürtözött konfigurációval indul el. Ha több példányt futtat automatikus skálázással, a JBoss EAP-példányok kommunikálnak egymással a virtuális hálózati integrációban megadott alhálózaton keresztül. A klaszterezés letiltásához hozzon létre egy alkalmazásbeállítást WEBSITE_DISABLE_CLUSTERING névvel és tetszőleges értékkel.

Egy virtuális hálózattal integrált JBoss EAP App Service-alkalmazást ábrázoló diagram, amely három példányra van felskálázva.

Feljegyzés

Ha arm-sablonnal engedélyezi a virtuális hálózat integrációját, manuálisan kell beállítania a tulajdonság vnetPrivatePorts értékét 2. Ha engedélyezi a virtuális hálózati integrációt a parancssori felületről vagy a portálról, ez a tulajdonság automatikusan be van állítva.

Ha engedélyezve van a fürtözés, a JBoss EAP-példányok a FILE_PING JGroups felderítési protokollt használják az új példányok felderítésére és a fürtinformációk (például a fürttagok, azonosítóik és IP-címük) megőrzésére. Az App Service-ben ezek a fájlok a következő alatt /home/clusterinfo/találhatók: . Az első EAP példány megszerzi az olvasási és írási jogosultságokat a klaszter tagsági fájljához. Más példányok beolvassák a fájlt, megkeresik az elsődleges csomópontot, és egyeztetnek a fürtbe felvenni kívánt csomóponttal, és hozzáadják a fájlhoz.

Feljegyzés

Elkerülheti a JBoss EAP-fürtözés időtúllépését, ha az alkalmazás indításakor megtisztítja az elavult felderítési fájlokat.

A Prémium V3, a Prémium V4 és az Izolált V2 App Service-csomagtípusok opcionálisan eloszthatók a rendelkezésre állási zónák között, így javítva az üzleti szempontból kritikus fontosságú számítási feladatok rugalmasságát és megbízhatóságát. Ezt az architektúrát zónaredundanciának is nevezik. A JBoss EAP fürtözési funkció kompatibilis a zónaredundancia funkcióval.

Automatikus méretezési szabályok

Amikor automatikus skálázási szabályokat konfigurál a horizontális skálázáshoz, fontos, hogy a példányokat fokozatosan (egyenként) távolítsa el, hogy az egyes eltávolított példányok átadhassák a tevékenységeit (például egy adatbázis-tranzakció kezelését) a fürt egy másik tagjára. Ha az automatikus méretezési szabályokat a portálon a vertikális leskálázásra konfigurálja, használja az alábbi beállításokat:

  • Művelet: "Darabszám csökkentése"
  • Lehűlés: "5 perc" vagy több
  • Példányszám: 1

Nem kell növekményesen hozzáadnia példányokat (horizontális felskálázás). Egyszerre több példányt is hozzáadhat a fürthöz.

App Service-csomagok

A JBoss EAP a következő tarifacsomagokban érhető el: F1, P0v3, P1mv3, P2mv3, P3mv3, P4mv3, P5mv3, P0v4, P1mv4, P2mv4, P3mv4, P4mv4 és P5mv4.

JBoss EAP-kiszolgáló életciklusa

Egy JBoss EAP-alkalmazás az App Service-ben öt különböző fázison megy keresztül a kiszolgáló elindítása előtt:

  1. Környezetbeállítási fázis
  2. Kiszolgálóindítási fázis
  3. Kiszolgálókonfigurációs fázis
  4. Alkalmazástelepítési fázis
  5. Kiszolgáló újrabetöltési fázisa

A részletekért és a testreszabási lehetőségekért tekintse meg a következő szakaszokat (például az alkalmazásbeállításokon keresztül).

1. Környezetbeállítási fázis

  • Az SSH szolgáltatás megkezdte a biztonságos SSH-munkamenetek engedélyezését a tárolóval.
  • A Java-futtatókörnyezeti kulcstár frissül az Azure Portalon definiált nyilvános és privát tanúsítványokkal.
    • A nyilvános tanúsítványokat a platform biztosítja a /var/ssl/certs könyvtárban, és betöltik a $JRE_HOME/lib/security/cacerts-ba.
    • A platform által biztosított magántanúsítványok a /var/ssl/private könyvtárban találhatók, és betöltődnek a $JRE_HOME/lib/security/client.jks könyvtárba.
  • Ha ebben a lépésben bármilyen tanúsítvány betöltődik a Java-kulcstárba, a tulajdonságok javax.net.ssl.keyStorejavax.net.ssl.keyStorePasswordjavax.net.ssl.keyStoreType bekerülnek a JAVA_OPTS környezeti változóba.
  • Meghatározunk néhány kezdeti JVM-konfigurációt, például a naplózási könyvtárakat és a Java memória halomparamétereit:
    • Ha az –Xms vagy –Xmx memória-zászlókat megadja az alkalmazás beállításainál JAVA_OPTS, ezek az értékek felülbírálják a platform által biztosítottakat.
    • Ha konfigurálja az alkalmazásbeállítást WEBSITES_CONTAINER_STOP_TIME_LIMIT, a rendszer átadja az értéket a futtatókörnyezet tulajdonságnak org.wildfly.sigterm.suspend.timeout, amely a JBoss EAP leállításakor a maximális leállítási várakozási időt (másodpercben) szabályozza.
  • Ha az alkalmazás integrálva van egy virtuális hálózattal, az App Service-futtatókörnyezet átadja a környezeti változóban WEBSITE_PRIVATE_PORTS a kiszolgálóközi kommunikációhoz használandó portok listáját, és elindítja a JBoss EAP-t a clustering konfiguráció használatával. Ellenkező esetben a standalone konfigurációt használja a rendszer.
    • A clustering konfigurációhoz a szerver konfigurációs fájlja standalone-azure-full-ha.xml van használva.
    • A standalone konfigurációhoz a szerver konfigurációs fájlja standalone-full.xml van használva.

2. Kiszolgálóindítási fázis

  • Ha a JBoss EAP elindul a clustering konfigurációban:
    • Minden JBoss EAP-példány kap egy belső azonosítót, amely 0 és az alkalmazás skálázott példányainak száma közötti tartományba esik.
    • Ha néhány fájlt találnak a kiszolgálópéldány tranzakciós tárolási útvonalában (a belső azonosítójának használatával), az azt jelenti, hogy ez a kiszolgálópéldány egy azonos szolgáltatáspéldányt helyettesít. A másik szolgáltatáspéldány korábban összeomlott, és nem véglegesített tranzakciókat hagyott hátra. A kiszolgáló úgy van konfigurálva, hogy folytassa a munkát ezeken a tranzakciókon.
  • Függetlenül attól, hogy a JBoss EAP a clusteringstandalone konfigurációban indul-e el, ha a kiszolgáló verziója 7.4-es vagy újabb, és a futtatókörnyezet Java 17-et használ, a konfiguráció frissül az Elytron alrendszer biztonságának engedélyezéséhez.
  • Ha konfigurálja az alkalmazásbeállítást WEBSITE_JBOSS_OPTS, az érték a JBoss-indítószkriptnek lesz átadva. Ez a beállítás a tulajdonságfájlok elérési útját és a JBoss EAP indítását befolyásoló további jelzők megadására használható.

3. Kiszolgálókonfigurációs fázis

  • A fázis elején az App Service először megvárja, amíg a JBoss EAP-kiszolgáló és a rendszergazdai felület készen áll a kérések fogadására a folytatás előtt. Ez a folyamat eltarthat néhány másodpercig, ha az Application Insights engedélyezve van.

  • Ha a JBoss EAP-kiszolgáló és a felügyeleti felület is készen áll, az App Service a következő műveleteket hajtja végre:

    • Hozzáadja a JBoss EAP modult azure.appservice, amely segédprogramosztályokat biztosít a naplózáshoz és az App Service-vel való integrációhoz.
    • Frissíti a konzolnaplózót, hogy színtelen módot használjon, hogy a naplófájlok ne teljenek meg színtelen sorozatokkal.
    • Az Azure Monitor-naplókkal való integráció beállítása.
    • Frissíti a webszolgáltatások leírási nyelvének (WSDL) és felügyeleti felületeinek kötési IP-címét.
    • Hozzáadja a JBoss EAP modult azure.appservice.easyauth az App Service-hitelesítéssel és a Microsoft Entra-azonosítóval való integrációhoz.
    • Frissíti a hozzáférési naplók naplózási konfigurációját, valamint a fő kiszolgáló naplófájljának nevét és rotációját.

  • Ha nincs megadva az alkalmazásbeállítás WEBSITE_SKIP_AUTOCONFIGURE_DATABASE , az App Service automatikusan észleli a Java Database Connectivity (JDBC) URL-címeit az App Service alkalmazásbeállításaiban. Ha léteznek érvényes JDBC URL-címek a PostgreSQL, a MySQL, a MariaDB, az Oracle, az SQL Server vagy az Azure SQL Database esetében, hozzáadja a megfelelő illesztőprogramokat a kiszolgálóhoz, hozzáad egy adatforrást az egyes JDBC URL-címekhez, és beállítja a Java Naming and Directory Interface (JNDI) nevet az egyes adatforrásokhoz java:jboss/env/jdbc/<app-setting-name>_DS, ahol <app-setting-name> az alkalmazásbeállítás neve szerepel.

  • Ha a clustering konfiguráció engedélyezve van, a konfigurálni kívánt konzolnaplózó be van jelölve.

  • Ha jar-fájlok vannak üzembe helyezve a /home/site/libs címtárban, a rendszer létrehoz egy új globális modult az összes jar-fájllal.

  • A fázis végén az App Service futtatja az egyéni indítási szkriptet, ha van ilyen. Az egyéni indítási szkript keresési logikája a következőképpen van definiálva:

    • Ha indítási parancsot konfigurált (például az Azure Portalon vagy az Azure CLI-ben), futtassa; egyébként
    • Ha az elérési út /home/site/scripts/startup.sh létezik, használja; ellenkező esetben
    • Ha az elérési út /home/startup.sh létezik, használja.

Az egyéni indítási parancs vagy szkript gyökérfelhasználóként fut (nincs szükség rá sudo), így linuxos csomagokat telepíthetnek, vagy elindíthatják a JBoss parancssori felületet további JBoss EAP-telepítési/testreszabási parancsok végrehajtásához, például adatforrások létrehozása és erőforrás-adapterek telepítése céljából. Az Ubuntu-csomagkezelési parancsokkal kapcsolatos információkért tekintse meg az Ubuntu Server dokumentációját. JBoss CLI-parancsok esetén lásd a JBoss felügyeleti parancssori felületének útmutatójában.

4. Alkalmazástelepítési fázis

Az indítási szkript alkalmazásokat helyez üzembe a JBoss EAP-ban az alábbi helyeken, sorrendben:

  • Ha konfigurálta az alkalmazásbeállítást WEBSITE_JAVA_WAR_FILE_NAME, telepítse az általa kijelölt fájlt.
  • Ha /home/site/wwwroot/app.war létezik, telepítse.
  • Ha más EAR- és WAR-fájlok is léteznek /home/site/wwwroot, telepítse őket.
  • Ha /home/site/wwwroot/webapps létezik, helyezzen üzembe benne fájlokat és könyvtárakat. A WAR-fájlok alkalmazásként vannak üzembe helyezve, a címtárak pedig "robbantott" (tömörítetlen) webalkalmazásként vannak üzembe helyezve.
  • Ha bármely különálló JSP-lap létezik, /home/site/wwwrootmásolja őket a webkiszolgáló gyökérkönyvtárba, és helyezze üzembe őket egy webalkalmazásként.
  • Ha nem találhatók üzembe helyezhető fájlok, helyezze üzembe az alapértelmezett üdvözlőlapot (parkolási oldalt) a gyökérkörnyezetben.

5. Kiszolgáló újrabetöltési fázisa

  • Az üzembe helyezési lépések elvégzése után a JBoss EAP-kiszolgáló újra betöltődik a kiszolgáló újratöltését igénylő módosítások alkalmazásához.
  • A kiszolgáló újratöltése után a JBoss EAP-kiszolgálón üzembe helyezett alkalmazásoknak készen kell állniuk a kérelmek megválaszolására.
  • A kiszolgáló addig fut, amíg az App Service-alkalmazás le nem áll vagy újra nem indul. Manuálisan leállíthatja vagy újraindíthatja az App Service-alkalmazást, vagy újraindíthatja a fájlokat, vagy konfigurációs módosításokat hajthat végre az App Service-alkalmazásban.
  • Ha a JBoss EAP-kiszolgáló rendellenesen kilép a clustering konfigurációból, a rendszer végrehajt egy végső függvényt emit_alert_tx_store_not_empty . A függvény ellenőrzi, hogy a JBoss EAP-folyamat nem létező tranzakciótárfájlt hagyott-e a lemezen. Ha igen, a rendszer hibát naplóz a konzolon: Error: finishing server with non-empty store for node XXXX. Amikor egy új kiszolgálópéldány elindul, a művelet folytatásához megkeresi ezeket a nem alkalmas tranzakciótároló-fájlokat (lásd : 2. Kiszolgálóindítási fázis).

Tomcat alapkonfiguráció

Feljegyzés

Ez a szakasz csak Linuxra vonatkozik.

A Java-fejlesztők megbízhatóan testre szabhatják a kiszolgáló beállításait, elháríthatják a problémákat, és magabiztosan helyezhetnek üzembe alkalmazásokat a Tomcatben, ha ismerik a Tomcat server.xml fájl- és konfigurációs adatait. A lehetséges testreszabások a következők:

  • A Tomcat konfigurációjának testreszabása: A server.xml fájl és a Tomcat konfigurációs adatainak megismerése után finomhangolhatja a kiszolgáló beállításait az alkalmazások igényeinek megfelelően.
  • Hibakeresés: Ha egy alkalmazás telepítve van egy Tomcat-kiszolgálón, a fejlesztőknek ismernie kell a kiszolgáló konfigurációját az esetleges problémák hibakereséséhez. Ez a folyamat magában foglalja a kiszolgálónaplók ellenőrzését, a konfigurációs fájlok vizsgálatát és az esetleges hibák azonosítását.
  • A Tomcat hibáinak elhárítása: A Java-fejlesztők elkerülhetetlenül problémákat tapasztalnak a Tomcat-kiszolgálójukkal, például teljesítményproblémákkal vagy konfigurációs hibákkal. Ha ismeri a server.xml fájlt és a Tomcat konfigurációs adatait, a fejlesztők gyorsan diagnosztizálhatják és elháríthatják ezeket a problémákat, ami időt és energiát takaríthat meg.
  • Alkalmazások üzembe helyezése a Tomcatben: Ha Java-webalkalmazást szeretne üzembe helyezni a Tomcatben, a fejlesztőknek tudniuk kell, hogyan konfigurálják a server.xml fájlt és más Tomcat-beállításokat. Ezeket a részleteket ismernie kell az alkalmazások sikeres üzembe helyezéséhez, és gondoskodnia kell arról, hogy zökkenőmentesen fussanak a kiszolgálón.

Ha egy beépített Tomcattel rendelkező alkalmazást hoz létre a Java-számítási feladatok (war- vagy JAR-fájlok) üzemeltetéséhez, bizonyos beállításokat ki kell vennie a Tomcat-konfiguráció keretéből. Részletes információkért tekintse meg az Apache Tomcat hivatalos dokumentációját , beleértve a Tomcat Web Server alapértelmezett konfigurációját is.

Emellett vannak bizonyos átalakítások is, amelyek a Tomcat-eloszlás server.xml felül vannak alkalmazva a kezdéskor. Ezek az átalakítások magukban foglalják az összekötő, a gazdagép és a szelep beállításainak módosítását.

A Tomcat legújabb verziói server.xml (8.5.58-at és 9.0.38-at) használnak. A Tomcat régebbi verziói nem használnak átalakításokat, és ennek következtében eltérő viselkedésük lehet.

Csatlakozó

<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 16384értékre van állítva.
  • URIEncoding UTF-8értékre van állítva.
  • connectionTimeoutbeállítás értéke WEBSITE_TOMCAT_CONNECTION_TIMEOUT, amely alapértelmezés szerint a következő.240000
  • maxThreadsbeállítás értéke WEBSITE_CATALINA_MAXTHREADS, amely alapértelmezés szerint a következő.200
  • maxConnectionsbeállítás értéke WEBSITE_CATALINA_MAXCONNECTIONS, amely alapértelmezés szerint a következő.10000

Feljegyzés

A connectionTimeout, maxThreadsés maxConnections a beállítások az alkalmazásbeállításokkal hangolhatók.

Az alábbiakban példa cli-parancsokat láthat, amelyekkel módosíthatja connectionTimeoutaz , maxThreadsvagy maxConnectionsa következő értékeket:

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

Az összekötő a tároló címét használja a 127.0.0.1 helyett.

Házigazda

<Host appBase="${site.appbase}" xmlBase="${site.xmlbase}" unpackWARs="${site.unpackwars}" workDir="${site.tempdir}" errorReportValveClass="com.microsoft.azure.appservice.AppServiceErrorReportValve" name="localhost" autoDeploy="true">
  • appBaseértéke a helyi AZURE_SITE_APP_BASEértékre van állítvaWebappsLocalPath.
  • xmlBasebeállítás értéke AZURE_SITE_HOME, amely alapértelmezés szerint a következő./site/wwwroot
  • unpackWARsbeállítás értéke AZURE_UNPACK_WARS, amely alapértelmezés szerint a következő.true
  • workDir értéke JAVA_TMP_DIR-re van állítva, amely alapértelmezettként TMP-t használ.
  • errorReportValveClass a mi testreszabott hibajelentési szelepünket használja.

Szelep

<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"/>
  • directorybeállítás értéke AZURE_LOGGING_DIR, amely alapértelmezés szerint a következő.home\logFiles
  • maxDaysbeállítás értéke WEBSITE_HTTPLOGGING_RETENTION_DAYS, amely alapértelmezés szerint a következő.7 Ez az érték az alkalmazásnaplózási platform alapértelmezett értékéhez igazodik.

Linuxon ugyanazzal a testreszabással rendelkezik, és hiba- és jelentésoldalakat ad hozzá a szelephez:

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

Kapcsolódó tartalom

Látogasson el az Azure for Java Fejlesztői központba az Azure rövid útmutatóihoz, oktatóanyagaihoz és Java-referenciadokumentációihoz.