Udostępnij za pośrednictwem


Wdrażanie i konfigurowanie aplikacji Java SE, Tomcat lub JBoss EAP w usłudze Azure App Service

W tym artykule przedstawiono najbardziej typową konfigurację wdrażania i środowiska uruchomieniowego dla aplikacji Java w usłudze Azure App Service. Jeśli używasz usługi Azure App Service po raz pierwszy, najpierw zapoznaj się z przewodnikiem Szybki start języka Java. Odpowiedzi na ogólne pytania dotyczące korzystania z usługi App Service, które nie są specyficzne dla programowania w języku Java, można znaleźć w często zadawanych pytaniach dotyczących usługi App Service.

Usługa Azure App Service uruchamia aplikacje internetowe Java w pełni zarządzanej usłudze w trzech wariantach.

  • Java Standard Edition (SE): może uruchomić aplikację wdrożoną jako pakiet Java Archive (JAR), który zawiera serwer osadzony (taki jak Spring Boot, Quarkus, Dropwizard lub aplikacja z osadzonym serwerem Tomcat lub Jetty).
  • Tomcat: Wbudowany serwer Tomcat może uruchamiać aplikację wdrożoną jako archiwum aplikacji internetowej (pakiet WAR).
  • JBoss Enterprise Application Platform (EAP): wbudowany serwer JBoss EAP może uruchomić aplikację wdrożona jako pakiet WAR lub Enterprise Archive (EAR). Obsługiwane dla aplikacji systemu Linux w zestawie poziomów cenowych, w tym Free, Premium v3 i Isolated v2.gti

Pokaż wersję języka Java

Aby wyświetlić bieżącą wersję języka Java, uruchom następujące polecenie w usłudze Azure Cloud Shell:

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

Aby wyświetlić wszystkie obsługiwane wersje języka Java, uruchom następujące polecenie w usłudze Cloud Shell:

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

Pobieranie wersji języka Java w kontenerze systemu Linux

Aby uzyskać bardziej szczegółowe informacje o wersji w kontenerze systemu Linux, otwórz sesję SSH z kontenerem. Oto kilka przykładów tego, co możesz uruchomić.

Aby wyświetlić wersję języka Java w sesji SSH:

java -version

Aby wyświetlić wersję serwera Tomcat w sesji SSH:

sh /usr/local/tomcat/version.sh

Lub, jeśli serwer Tomcat znajduje się w lokalizacji niestandardowej, znajdź version.sh za pomocą:

find / -name "version.sh"

Aby wyświetlić wersję serwera JBoss EAP w sesji SSH:

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

Aby uzyskać więcej informacji na temat obsługi wersji, zobacz Zasady obsługi środowiska uruchomieniowego języka usługi App Service.

Co się stanie z nieaktualnymi środowiskami uruchomieniowymi w usłudze App Service?

Nieaktualne środowiska uruchomieniowe są wycofywane przez organizację nadzorującą lub mają znaczące luki w zabezpieczeniach. W związku z tym są one usuwane z tworzenia i konfigurowania stron w portalu. Gdy nieaktualne środowisko uruchomieniowe jest ukryte w portalu, każda aplikacja, która nadal korzysta z tego środowiska uruchomieniowego, będzie nadal działać.

Jeśli chcesz utworzyć aplikację z nieaktualną wersją środowiska uruchomieniowego, która nie jest już wyświetlana w portalu, użyj interfejsu wiersza polecenia platformy Azure, szablonu usługi ARM lub Bicep. Alternatywy wdrażania umożliwiają tworzenie zdeprecjonowanych środowisk uruchomieniowych, które zostały usunięte z portalu, ale nadal są obsługiwane.

Jeśli środowisko uruchomieniowe zostanie w pełni usunięte z platformy App Service, właściciel subskrypcji platformy Azure otrzyma powiadomienie e-mail przed usunięciem.

Wdrażanie aplikacji

Narzędzia do budowy

Maven

Korzystając z wtyczki Maven dla usługi Azure Web Apps, możesz łatwo przygotować projekt za pomocą jednego polecenia w katalogu głównym projektu:

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

To polecenie dodaje wtyczkę i powiązaną konfigurację azure-webapp-maven-plugin , wyświetlając monit o wybranie istniejącej aplikacji internetowej platformy Azure lub utworzenie nowej. Podczas konfigurowania próbuje wykryć, czy aplikacja powinna zostać wdrożona w środowisku Java SE, Tomcat lub (tylko system Linux) JBoss EAP. Następnie możesz wdrożyć aplikację Java na platformie Azure przy użyciu następującego polecenia:

mvn package azure-webapp:deploy

Oto przykładowa konfiguracja w pliku 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. Skonfiguruj wtyczkę Gradle dla usługi Azure Web Apps, dodając wtyczkę do elementu build.gradle.

    plugins {
      id "com.microsoft.azure.azurewebapp" version "1.10.0"
    }
    
  2. Skonfiguruj szczegóły aplikacji internetowej. Odpowiednie zasoby platformy Azure są tworzone, gdy ich brakuje. Oto przykładowa konfiguracja. Aby uzyskać szczegółowe informacje, zapoznaj się z tym dokumentem.

    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. Wdróż za pomocą jednego polecenia.

    gradle azureWebAppDeploy
    

IDE

Platforma Azure zapewnia bezproblemowe środowisko programowania w usłudze Java App Service w popularnych środowiskach Java Integrated Development Environment (IDE), w tym:

API Kudu i OneDeploy

Klienci wdrażania, tacy jak wtyczka Maven, GitHub Actions używający azure/webapps-deploy@v3 i nowsze, lub polecenie az webapp deploy, korzystają z metody OneDeploy, która jest wywoływana poprzez odwołanie się do punktu końcowego /api/publish witryny Kudu działającego w tle. Aby uzyskać więcej informacji na temat tego interfejsu API, zobacz tę dokumentację.

Gdy te metody wdrażania zostaną użyte, automatycznie zmienią nazwę podanego pliku JAR na app.jar podczas procesu wdrażania. Zostanie to umieszczone w obszarze /home/site/wwwwroot. Aby wdrożyć pliki JAR w środowisku Java SE, zobacz tę dokumentację.

Uwaga

Jeśli używasz alternatywnych metod, takich jak FTP lub starsze interfejsy API narzędzia ZipDeploy, ta metoda zmiany nazwy podanego pliku JAR nie zostanie wywołana. Zanotuj to, jeśli użyj pola tekstowego Plik startowy w sekcji Konfiguracja portalu, aby jawnie wywołać plik JAR.

Pliki WAR można wdrożyć w aplikacji Tomcat, postępując zgodnie z tą dokumentacją. Gdy powyższe metody wdrażania zostaną użyte, automatycznie zmienią nazwę podanego pliku war na app.war podczas procesu wdrażania. Zostanie to umieszczone w obszarze /home/site/wwwwroot i domyślnie obsługuje wdrażanie tylko jednego pliku WAR w obszarze wwwroot. Nie zostanie to umieszczone w katalogu /home/site/wwwroot/webapps, jak ma to miejsce przy użyciu interfejsów API do wdrażania, takich jak WarDeploy. Aby uniknąć wszelkich problemów ze starciami struktury plików, zaleca się użycie tylko jednego lub innego typu wdrożenia.

Aby wdrożyć pliki WAR w aplikacji JBoss EAP, zapoznaj się z tą dokumentacją. Gdy jest używana funkcja OneDeploy, spowoduje to automatyczne zmianę nazwy pliku WAR na app.war i zostanie umieszczony w obszarze /home/site/wwwroot.

Aby wdrożyć pliki EAR, użyj protokołu FTP. Aplikacja EAR jest wdrażana do rootu kontekstu zdefiniowanego w konfiguracji aplikacji. Jeśli chcesz, aby aplikacja internetowa była obsługiwana w ścieżce głównej, upewnij się, że aplikacja ustawia kontekst główny na ścieżkę główną: <context-root>/</context-root>. Aby uzyskać więcej informacji, zobacz Ustawianie głównego katalogu kontekstowego aplikacji internetowej.

Nie wdrażaj pliku WAR ani JAR przy użyciu protokołu FTP. Narzędzie FTP jest przeznaczone do przekazywania skryptów uruchamiania, zależności lub innych plików środowiska uruchomieniowego. Nie jest to optymalny wybór w przypadku wdrażania aplikacji internetowych.

Ponowne zapisywanie lub przekierowywanie adresu URL

Aby przepisać lub przekierować adres URL, użyj jednego z dostępnych rewriterów adresów URL, takich jak UrlRewriteFilter.

Tomcat zapewnia również zawór do ponownego zapisywania.

JBoss EAP zapewnia również zawór do ponownego zapisywania.

Rejestrowanie i debugowanie aplikacji

Raporty wydajności, wizualizacje ruchu i kontrole kondycji są dostępne dla każdej aplikacji za pośrednictwem witryny Azure Portal. Aby uzyskać więcej informacji, zobacz omówienie diagnostyki usługi aplikacji platformy Azure.

Przesyłaj logi diagnostyczne

Możesz uzyskać dostęp do dzienników konsoli generowanych wewnątrz kontenera.

Aby włączyć rejestrowanie kontenerów, uruchom następujące polecenie:

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

Zastąp <app-name> i <resource-group-name> nazwami odpowiednimi dla swojej aplikacji internetowej.

Po włączeniu rejestrowania kontenerów uruchom następujące polecenie, aby wyświetlić strumień dziennika:

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

Jeśli dzienniki konsoli nie są wyświetlane natychmiast, sprawdź ponownie w ciągu 30 sekund.

Aby zatrzymać strumieniowanie dzienników w dowolnym momencie, naciśnij Ctrl+C.

Aby uzyskać więcej informacji, zobacz Stream logs in Cloud Shell (Dzienniki usługi Stream w usłudze Cloud Shell).

Dostęp do konsoli SSH w systemie Linux

Aby otworzyć bezpośrednią sesję SSH z kontenerem, aplikacja powinna być uruchomiona.

Użyj polecenia az webapp ssh .

Jeśli nie masz jeszcze uwierzytelnienia, musisz uwierzytelnić się w subskrypcji platformy Azure, aby nawiązać połączenie. Po uwierzytelnieniu zobaczysz powłokę w przeglądarce, którą możesz używać do uruchamiania poleceń wewnątrz swojego kontenera.

Połączenie SSH

Uwaga

Wszelkie zmiany wprowadzone poza /home katalogiem są przechowywane w samym kontenerze i nie są utrwalane poza ponownym uruchomieniem aplikacji.

Aby otworzyć zdalną sesję SSH z twojego lokalnego komputera, zobacz Open SSH session from remote shell.

Narzędzia do rozwiązywania problemów z systemem Linux

Wbudowane obrazy Java są oparte na systemie operacyjnym Alpine Linux . apk Użyj menedżera pakietów, aby zainstalować wszystkie narzędzia do rozwiązywania problemów lub polecenia.

Profiler języka Java

Wszystkie środowiska uruchomieniowe Java w usłudze Azure App Service są wyposażone w Flight Recorder zestawu Java Development Kit (JDK) do profilowania obciążeń Java. Służy do rejestrowania maszyny wirtualnej Java (JVM), systemu i zdarzeń aplikacji oraz rozwiązywania problemów w aplikacjach.

Aby dowiedzieć się więcej na temat profilera Języka Java, odwiedź dokumentację usługi Azure Application Insights.

Rejestrator Lotu Java

Wszystkie środowiska uruchomieniowe Javy w usłudze App Service są wyposażone w narzędzie Java Flight Recorder. Służy do rejestrowania zdarzeń JVM, systemu i aplikacji oraz rozwiązywania problemów w aplikacjach Java.

Za pomocą protokołu SSH w ramach usługi App Service uruchom polecenie jcmd, aby wyświetlić listę wszystkich działających procesów Java. Oprócz jcmd powinna być widoczna aplikacja Java uruchomiona z numerem PID (identyfikatora procesu).

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

Wykonaj następujące polecenie, aby uruchomić 30-sekundowe nagranie maszyny wirtualnej JVM. Profiluje maszynę JVM i tworzy plik JFR (Java Flight Recorder) o nazwie jfr_example.jfr w katalogu głównym. Zastąp 116 identyfikatorem PID aplikacji Java.

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

W 30-sekundowym interwale można sprawdzić, czy nagranie odbywa się, uruchamiając polecenie jcmd 116 JFR.check. Polecenie wyświetla wszystkie nagrania dla danego procesu Java.

Ciągłe rejestrowanie

Narzędzie Java Flight Recorder umożliwia ciągłe profilowanie aplikacji Java przy minimalnym wpływie na wydajność środowiska uruchomieniowego. W tym celu uruchom następujące polecenie interfejsu wiersza polecenia platformy Azure, aby utworzyć ustawienie aplikacji o nazwie JAVA_OPTS z wymaganą konfiguracją. Zawartość JAVA_OPTS ustawienia aplikacji jest przekazywana do java polecenia w momencie uruchomienia aplikacji.

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 rozpoczęciu nagrywania można w dowolnym momencie zrzucić aktualne dane z nagrania, używając polecenia JFR.dump.

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

Analizowanie plików JFR

Użyj protokołu FTPS , aby pobrać plik JFR na komputer lokalny. Aby przeanalizować plik JFR, pobierz i zainstaluj narzędzie Java Mission Control (JMC). Aby uzyskać instrukcje dotyczące korzystania z narzędzia Java Mission Control, zapoznaj się z dokumentacją pakietu JMC i instrukcjami dotyczącymi instalacji.

Rejestrowanie aplikacji

Aby skonfigurować usługę App Service do zapisu standardowych danych wyjściowych konsoli aplikacji i standardowych strumieni błędów konsoli do lokalnego systemu plików lub usługi Azure Blob Storage, wykonaj następujące czynności. Włącz rejestrowanie aplikacji za pośrednictwem witryny Azure Portal lub w interfejsie wiersza polecenia platformy Azure. Jeśli potrzebujesz dłuższego przechowywania, skonfiguruj aplikację do zapisywania danych wyjściowych w kontenerze usługi Blob Storage.

Dzienniki aplikacji Java i Tomcat można znaleźć w /home/LogFiles/Application/ katalogu.

Rejestrowanie usługi Azure Blob Storage dla aplikacji opartych na systemie Linux można skonfigurować tylko przy użyciu usługi Azure Monitor.

Jeśli aplikacja używa usługi Logback lub Log4j do śledzenia, możesz przekazać te ślady do przeglądu w usłudze Azure Application Insights. Skorzystaj z instrukcji konfiguracji struktury rejestrowania w artykule Eksplorowanie dzienników śledzenia języka Java w usłudze Application Insights.

Uwaga

Ze względu na znaną lukę CVE-2021-44228w zabezpieczeniach należy użyć usługi Log4j w wersji 2.16 lub nowszej.

Dostosowywanie i dostrajanie

Usługa Azure App Service obsługuje dostrajanie i dostosowywanie bez konieczności dodatkowej konfiguracji za pośrednictwem portalu Azure i Azure CLI. Zapoznaj się z następującymi artykułami dotyczącymi konfiguracji aplikacji internetowej innej niż Java:

Lokalne kopiowanie zawartości aplikacji

Ustawienie aplikacji JAVA_COPY_ALL na true umożliwia kopiowanie zawartości aplikacji do lokalnego pracownika z współdzielonego systemu plików. To ustawienie pomaga rozwiązać problemy z blokowaniem plików.

Ustawianie opcji środowiska uruchomieniowego języka Java

Aby ustawić przydzieloną pamięć lub inne opcje środowiska uruchomieniowego JVM, utwórz ustawienie aplikacji o nazwie JAVA_OPTS z opcjami. Usługa App Service przekazuje to ustawienie jako zmienną środowiskową do środowiska uruchomieniowego Java po uruchomieniu.

W witrynie Azure Portal w obszarze Ustawienia aplikacji internetowej utwórz nowe ustawienie aplikacji o nazwie JAVA_OPTS zawierające inne ustawienia, takie jak -Xms512m -Xmx1204m.

W witrynie Azure Portal w obszarze Ustawienia aplikacji internetowej utwórz nowe ustawienie aplikacji o nazwie CATALINA_OPTS zawierające inne ustawienia, takie jak -Xms512m -Xmx1204m.

Aby skonfigurować ustawienie aplikacji z poziomu wtyczki Maven, dodaj tagi ustawień/wartości w sekcji wtyczki platformy Azure. W poniższym przykładzie ustawiono określony minimalny i maksymalny rozmiar sterty Java:

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

Uwaga

Nie musisz tworzyć pliku web.config w przypadku korzystania z serwera Tomcat w usłudze Windows App Service.

Domyślnie usługa App Service ustawia maksymalny rozmiar sterty JVM na 70% całkowitej pamięci dostępnej dla planu usługi App Service. Aby wyłączyć ustawienie domyślne, możesz użyć ustawienia aplikacji WEBSITE_DISABLE_JAVA_HEAP_CONFIGURATION="true".

Zwiększenie wydajności aplikacji na platformie może obejmować dostosowanie rozmiaru sterty w celu lepszego dopasowania do konkretnych potrzeb. Podczas dostrajania ustawień sterty aplikacji przejrzyj szczegóły planu usługi App Service i rozważ wymagania wielu aplikacji i miejsc wdrożenia, aby znaleźć optymalną alokację pamięci.

Włączanie gniazd internetowych

Włącz obsługę gniazd internetowych w witrynie Azure Portal w ustawieniach aplikacji dla aplikacji. Aby ustawienie zaczęły obowiązywać, należy ponownie uruchomić aplikację.

Włącz obsługę gniazd internetowych przy użyciu interfejsu wiersza polecenia platformy Azure za pomocą następującego polecenia:

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

Następnie uruchom ponownie aplikację:

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

Ustawianie domyślnego kodowania znaków

W portalu Azure, w Ustawieniach aplikacji dla aplikacji internetowej, utwórz nowe ustawienie aplikacji o nazwie JAVA_OPTS i wartości -Dfile.encoding=UTF-8.

Alternatywnie możesz skonfigurować ustawienie aplikacji przy użyciu wtyczki App Service Maven. Dodaj nazwę ustawienia i tagi wartości w konfiguracji wtyczki:

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

Prekompiluj pliki JSP

Aby zwiększyć wydajność aplikacji Tomcat, możesz skompilować pliki JSP przed wdrożeniem w usłudze App Service. Możesz użyć wtyczki Maven dostarczonej przez usługę Apache Sling lub użyć tego pliku kompilacji Ant.

Ignoruj komunikat robots933456 w logach

W dziennikach kontenera może zostać wyświetlony następujący komunikat:

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

Możesz bezpiecznie zignorować ten komunikat. /robots933456.txt jest fikcyjną ścieżką adresu URL, za pomocą której usługa App Service sprawdza, czy kontener jest w stanie obsługiwać żądania. Odpowiedź 404 wskazuje, że ścieżka nie istnieje i sygnalizuje usłudze App Service, że kontener jest w dobrej kondycji i gotowy do odpowiadania na żądania.

Wybieranie wersji środowiska uruchomieniowego Java

Usługa App Service umożliwia użytkownikom wybranie wersji głównej maszyny JVM, takiej jak Java 8 lub Java 11, oraz wersji poprawki, takiej jak 1.8.0_232 lub 11.0.5. Możesz również wybrać automatyczną aktualizację wersji poprawki, gdy nowe wersje pomocnicze będą dostępne. W większości przypadków aplikacje produkcyjne powinny używać przypiętych wersji poprawek JVM, które uniemożliwiają nieoczekiwane awarie podczas ich automatycznej aktualizacji. Wszystkie aplikacje internetowe Java używają 64-bitowych JVM-ów i nie można ich konfigurować.

Jeśli używasz Tomcat, możesz wybrać, aby przypiąć wersję poprawki Tomcat. W systemie Windows można niezależnie przypiąć wersje poprawek JVM i Tomcat. W systemie Linux możesz ustawić wersję poprawkową Tomcata. Wersja poprawki Java Virtual Machine (JVM) jest również przypięta, ale nie jest konfigurowana oddzielnie.

Jeśli zdecydujesz się przypiąć wersję podrzędną, musisz okresowo aktualizować wersję podrzędną JVM w aplikacji. Aby upewnić się, że aplikacja działa na nowszej wersji pomniejszej, utwórz gniazdo przejściowe i zwiększ wersję pomniejszą w gnieździe przejściowym. Po potwierdzeniu, że aplikacja działa poprawnie w nowej wersji pomniejszej, możesz zamienić sloty testowe i produkcyjne.

Uruchamianie interfejsu wiersza polecenia narzędzia JBoss

W sesji SSH aplikacji JBoss EAP możesz uruchomić JBoss CLI za pomocą następującego polecenia:

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

W zależności od tego, gdzie program JBoss EAP znajduje się w cyklu życia serwera, połączenie może nie być możliwe. Odczekaj kilka minut i spróbuj ponownie. Takie podejście jest przydatne w przypadku szybkiego sprawdzania bieżącego stanu serwera (na przykład w celu sprawdzenia, czy źródło danych jest prawidłowo skonfigurowane).

Ponadto zmiany wprowadzone na serwerze za pomocą interfejsu wiersza polecenia platformy JBoss w sesji SSH nie są utrwalane po ponownym uruchomieniu aplikacji. Za każdym razem, gdy aplikacja zostanie uruchomiona, serwer JBoss EAP rozpoczyna się od czystej instalacji. Podczas cyklu życia uruchamiania usługa App Service wykonuje niezbędne konfiguracje serwera i wdraża aplikację. Aby wprowadzić wszelkie trwałe zmiany na serwerze JBoss EAP, użyj niestandardowego skryptu uruchamiania lub polecenia uruchamiania. Aby zapoznać się z przykładem kompleksowego rozwiązania, zobaczysz Konfigurowanie źródeł danych dla aplikacji Java SE, Tomcat lub JBoss EAP w usłudze Azure App Service.

Alternatywnie możesz ręcznie skonfigurować usługę App Service tak, aby uruchamiała dowolny plik podczas uruchamiania. Na przykład:

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

Aby uzyskać więcej informacji na temat poleceń CLI, które można uruchomić, zapoznaj się z:

Klastrowanie

Usługa App Service obsługuje klastrowanie dla protokołu JBoss EAP w wersji 7.4.1 lub nowszej. Aby włączyć klastrowanie, aplikacja internetowa musi być zintegrowana z siecią wirtualną. Gdy aplikacja internetowa jest zintegrowana z siecią wirtualną, jest uruchamiana ponownie, a instalacja protokołu EAP JBoss automatycznie rozpoczyna się od konfiguracji klastrowanej. Gdy uruchamiasz wiele wystąpień ze skalowaniem automatycznym, wystąpienia JBoss EAP komunikują się ze sobą za pośrednictwem podsieci określonej w wirtualnej integracji sieciowej. Klastrowanie można wyłączyć, tworząc ustawienie aplikacji o nazwie WEBSITE_DISABLE_CLUSTERING z dowolną wartością.

Diagram przedstawiający aplikację JBoss EAP App Service zintegrowaną z siecią wirtualną, skalowaną do trzech instancji.

Uwaga

Jeśli włączasz integrację sieci wirtualnej z szablonem usługi ARM, musisz ręcznie ustawić właściwość vnetPrivatePorts na wartość 2. Jeśli włączysz integrację sieci wirtualnej z interfejsu wiersza polecenia lub portalu, ta właściwość zostanie ustawiona automatycznie.

Po włączeniu klastrowania, wystąpienia JBoss EAP używają protokołu JGroups do wykrywania nowych instancji i zachowywania informacji o klastrze (na przykład członków klastra, ich identyfikatorów i adresów IP). W usłudze App Service te pliki znajdują się w obszarze /home/clusterinfo/. Pierwsze wystąpienie protokołu EAP, które się uruchamia, uzyskuje uprawnienia do odczytu/zapisu w pliku członkostwa klastra. Inne instancje odczytują plik, znajdują węzeł podstawowy i koordynują działania z tym węzłem, aby zostać uwzględnionymi w klastrze i dodanymi do pliku.

Uwaga

Możesz uniknąć przekroczenia limitu czasu klastrowania JBoss EAP, czyszcząc przestarzałe pliki odnajdywania podczas uruchamiania aplikacji.

Typy planów usługi App Service: Premium V3, Premium V4 i Isolated V2 mogą być opcjonalnie dystrybuowane między strefami dostępności, aby zwiększyć odporność i niezawodność obciążeń o krytycznym znaczeniu dla działania firmy. Ta architektura jest również znana jako nadmiarowość strefowa. Funkcja klastrowania JBoss EAP jest zgodna z funkcją nadmiarowości strefowej.

Reguły automatycznego skalowania

Podczas konfigurowania reguł skalowania automatycznego na potrzeby skalowania w poziomie ważne jest, aby usunąć wystąpienia przyrostowo (pojedynczo), aby upewnić się, że każde usunięte wystąpienie może przenieść jego działanie (takie jak obsługa transakcji bazy danych) do innego elementu członkowskiego klastra. Podczas konfigurowania reguł autoskalowania w portalu w celu skalowania w dół użyj następujących opcji:

  • Operacja: "Zmniejsz liczbę o"
  • Schładz: "5 minut" lub więcej
  • Liczba wystąpień: 1

Nie trzeba stopniowo dodawać instancji (skalowanie poziome). Można jednorazowo dodać wiele wystąpień do klastra.

Plany usługi App Service

Protokół JBoss EAP jest dostępny w następujących warstwach cenowych: F1, P0v3, P1mv3, P2mv3, P3mv3, P4mv3, P5mv3, P0v4, P1mv4, P2mv4, P3mv4, P4mv4 i P5mv4.

Cykl życia serwera JBoss EAP

Aplikacja JBoss EAP w usłudze App Service przechodzi pięć odrębnych faz przed uruchomieniem serwera:

  1. Faza konfiguracji środowiska
  2. Faza uruchamiania serwera
  3. Faza konfiguracji serwera
  4. Faza wdrażania aplikacji
  5. Faza ponownego ładowania serwera

Szczegółowe informacje i możliwości dostosowywania można znaleźć w poniższych sekcjach (na przykład za pomocą ustawień aplikacji).

1. Faza konfiguracji środowiska

  • Usługa SSH jest uruchamiana w celu włączenia bezpiecznych sesji SSH z kontenerem.
  • Magazyn kluczy środowiska uruchomieniowego Java jest aktualizowany przy użyciu wszystkich certyfikatów publicznych i prywatnych zdefiniowanych w witrynie Azure Portal.
    • Certyfikaty publiczne są udostępniane przez platformę w katalogu /var/ssl/certs i są ładowane do $JRE_HOME/lib/security/cacerts.
    • Certyfikaty prywatne są dostarczane przez platformę w katalogu /var/ssl/private i są ładowane do $JRE_HOME/lib/security/client.jks.
  • Jeśli w tym kroku zostaną załadowane jakiekolwiek certyfikaty w magazynie kluczy Java, właściwości javax.net.ssl.keyStore, javax.net.ssl.keyStorePasswordi javax.net.ssl.keyStoreType zostaną dodane do zmiennej środowiskowej JAVA_OPTS .
  • Określana jest początkowa konfiguracja JVM, na przykład katalogi rejestrowania i parametry sterty pamięci Java:
    • Jeśli podasz flagi –Xms lub –Xmx dla pamięci w ustawieniu JAVA_OPTSaplikacji , te wartości zastąpią te, które są dostarczane przez platformę.
    • Jeśli skonfigurujesz ustawienie WEBSITES_CONTAINER_STOP_TIME_LIMIT aplikacji, wartość zostanie przekazana do właściwości org.wildfly.sigterm.suspend.timeout środowiska uruchomieniowego, która kontroluje maksymalny czas oczekiwania zamknięcia (w sekundach), kiedy JBoss EAP jest zatrzymywany.
  • Jeśli aplikacja jest zintegrowana z siecią wirtualną, środowisko uruchomieniowe usługi App Service przekazuje listę portów, które mają być używane do komunikacji między serwerami w zmiennej środowiskowej WEBSITE_PRIVATE_PORTS i uruchamia protokół JBoss EAP przy użyciu clustering konfiguracji. W przeciwnym razie zostanie użyta konfiguracja standalone.
    • W przypadku clustering konfiguracji używany jest plik standalone-azure-full-ha.xml konfiguracji serwera.
    • W przypadku standalone konfiguracji używany jest plik standalone-full.xml konfiguracji serwera.

2. Faza uruchamiania serwera

  • Jeśli JBoss EAP zostanie uruchomiony w clustering konfiguracji:
    • Każda instancja JBoss EAP otrzymuje identyfikator wewnętrzny z zakresu od 0 do liczby instancji, do których aplikacja jest skalowana w poziomie.
    • Jeśli niektóre pliki znajdują się w ścieżce magazynu transakcji dla tego wystąpienia serwera (przy użyciu jego identyfikatora wewnętrznego), oznacza to, że to wystąpienie serwera zastępuje identyczne wystąpienie usługi. Inne wystąpienie usługi wcześniej uległo awarii i pozostawiło niezatwierdzone transakcje. Serwer jest skonfigurowany do wznowienia pracy nad tymi transakcjami.
  • Niezależnie od tego, czy JBoss EAP rozpoczyna się w clustering konfiguracji lub standalone, jeśli wersja serwera jest 7.4 lub nowsza, a środowisko uruchomieniowe używa Java 17, konfiguracja zostanie zaktualizowana w celu włączenia podsystemu Elytron dla zabezpieczeń.
  • Jeśli skonfigurujesz ustawienie WEBSITE_JBOSS_OPTSaplikacji , wartość zostanie przekazana do skryptu uruchamiania JBoss. To ustawienie może służyć do udostępniania ścieżek do plików właściwości i innych flag, które wpływają na uruchamianie protokołu EAP JBoss.

3. Faza konfiguracji serwera

  • Na początku tej fazy usługa App Service najpierw czeka, aż zarówno serwer JBoss EAP, jak i interfejs administracyjny będą gotowe do odbierania żądań, zanim przejdzie dalej. Ten proces może potrwać kilka sekund, jeśli usługa Application Insights jest włączona.

  • Gdy zarówno serwer JBoss EAP, jak i interfejs administracyjny są gotowe, usługa App Service wykonuje następujące akcje:

    • Dodaje moduł azure.appserviceJBoss EAP, który udostępnia klasy narzędzi do rejestrowania i integracji z usługą App Service.
    • Aktualizuje rejestrator konsoli tak, aby używał trybu pozbawionego kolorów, aby pliki dziennika nie były pełne sekwencji ucieczki kolorów.
    • Konfiguruje integrację z dziennikami usługi Azure Monitor.
    • Aktualizuje adresy IP powiązań dla interfejsów WSDL (Web Services Description Language) i zarządzania.
    • Dodaje moduł azure.appservice.easyauth JBoss EAP na potrzeby integracji z uwierzytelnianiem usługi App Service i identyfikatorem Entra firmy Microsoft.
    • Aktualizuje konfigurację rejestrowania dzienników dostępu oraz nazwę i rotację głównego pliku dziennika serwera.
  • Jeśli ustawienie WEBSITE_SKIP_AUTOCONFIGURE_DATABASE aplikacji nie jest zdefiniowane, usługa App Service automatycznie wykrywa adresy URL łączności bazy danych Java (JDBC) w ustawieniach aplikacji usługi App Service. Jeśli istnieją prawidłowe adresy URL JDBC dla baz danych PostgreSQL, MySQL, MariaDB, Oracle, SQL Server lub Azure SQL Database, dodaje odpowiednie sterowniki do serwera, dodaje źródło danych dla każdego z adresów URL JDBC i ustawia nazwę Java Naming and Directory Interface (JNDI) dla każdego źródła danych na java:jboss/env/jdbc/<app-setting-name>_DS, gdzie <app-setting-name> jest nazwą ustawienia aplikacji.

  • Jeśli konfiguracja clustering jest włączona, sprawdzane jest, czy logger konsoli do skonfigurowania jest ustawiony.

  • Jeśli istnieją pliki JAR wdrożone w /home/site/libs katalogu, zostanie utworzony nowy moduł globalny ze wszystkimi tymi plikami JAR.

  • Na końcu fazy usługa App Service uruchamia niestandardowy skrypt uruchamiania, jeśli istnieje. Logika wyszukiwania niestandardowego skryptu uruchamiania jest definiowana w następujący sposób:

    • Jeśli skonfigurowano polecenie uruchamiania (na przykład za pośrednictwem witryny Azure Portal lub interfejsu wiersza polecenia platformy Azure), uruchom je; inaczej
    • Jeśli ścieżka /home/site/scripts/startup.sh istnieje, użyj jej; w przeciwnym razie
    • Jeśli ścieżka /home/startup.sh istnieje, użyj jej.

Niestandardowe polecenie uruchamiania lub skrypt jest uruchamiane jako użytkownik root (nie jest konieczny sudo), tak aby mogli instalować pakiety Linux lub uruchomić JBoss CLI, aby wykonać więcej poleceń instalacji/dostosowywania JBoss EAP, takich jak tworzenie źródeł danych i instalowanie adapterów zasobów. Aby uzyskać informacje na temat poleceń zarządzania pakietami systemu Ubuntu, zobacz dokumentację systemu Ubuntu Server. Aby zapoznać się z poleceniami interfejsu wiersza polecenia JBoss, zobacz JBoss Management CLI Guide.

4. Faza wdrażania aplikacji

Skrypt uruchamiania wdraża aplikacje do JBoss EAP, szukając w następujących lokalizacjach w kolejności pierwszeństwa:

  • Jeśli skonfigurowano ustawienia aplikacji WEBSITE_JAVA_WAR_FILE_NAME, wdróż plik wyznaczony przez to ustawienie.
  • Jeśli /home/site/wwwroot/app.war istnieje, wdróż go.
  • Jeśli istnieją inne pliki EAR i WAR w programie /home/site/wwwroot, wdróż je.
  • Jeśli /home/site/wwwroot/webapps istnieje, wdróż w nim pliki i katalogi. Pliki WAR są wdrażane jako same aplikacje, a katalogi są wdrażane jako "eksplodowane" (nieskompresowane) aplikacje internetowe.
  • Jeśli w systemie /home/site/wwwrootistnieją jakiekolwiek autonomiczne strony JSP, skopiuj je do katalogu głównego serwera internetowego i wdróż je jako jedną aplikację internetową.
  • Jeśli nie znaleziono żadnych plików możliwych do wdrożenia, w kontekście głównym wdróż domyślną stronę powitalną (stronę parkingu).

5. Faza ponownego ładowania serwera

  • Po wykonaniu kroków wdrażania serwer JBoss EAP zostanie ponownie załadowany, aby zastosować wszelkie zmiany, które wymagają ponownego załadowania serwera.
  • Po ponownym załadowaniu serwera aplikacje wdrożone na serwerze JBoss EAP powinny być gotowe do odpowiadania na żądania.
  • Serwer jest uruchamiany do momentu zatrzymania lub ponownego uruchomienia aplikacji usługi App Service. Możesz ręcznie zatrzymać lub ponownie uruchomić aplikację usługi App Service albo wyzwolić ponowne uruchomienie podczas wdrażania plików lub wprowadzić zmiany konfiguracji w aplikacji usługi App Service.
  • Jeśli serwer JBoss EAP zamyka się nieprawidłowo podczas konfiguracji clustering, wykonywana jest końcowa funkcja o nazwie emit_alert_tx_store_not_empty. Funkcja sprawdza, czy proces JBoss EAP pozostawił na dysku niepusty plik magazynu transakcji. Jeśli tak, w konsoli jest rejestrowany błąd: Error: finishing server with non-empty store for node XXXX. Po uruchomieniu nowego wystąpienia serwera wyszukuje te niepuste pliki magazynu transakcji w celu wznowienia pracy (zobacz 2. Faza uruchamiania serwera).

Konfiguracja punktu odniesienia serwera Tomcat

Uwaga

Ta sekcja dotyczy tylko systemu Linux.

Deweloperzy języka Java mogą dostosowywać ustawienia serwera, rozwiązywać problemy i wdrażać aplikacje w usłudze Tomcat z pewnością, jeśli wiedzą o pliku server.xml i szczegółach konfiguracji serwera Tomcat. Możliwe dostosowania obejmują:

  • Dostosowywanie konfiguracji serwera Tomcat: gdy rozumiesz plik server.xml i szczegóły konfiguracji serwera Tomcat, możesz dostosować ustawienia serwera w celu dopasowania ich do potrzeb aplikacji.
  • Debugowanie: po wdrożeniu aplikacji na serwerze Tomcat deweloperzy muszą znać konfigurację serwera, aby debugować wszelkie problemy, które mogą wystąpić. Ten proces obejmuje sprawdzanie dzienników serwera, badanie plików konfiguracji i identyfikowanie wszelkich błędów, które mogą wystąpić.
  • Rozwiązywanie problemów z serwerem Tomcat: Nieuchronnie deweloperzy języka Java napotykają problemy z serwerem Tomcat, takie jak problemy z wydajnością lub błędy konfiguracji. Gdy rozumiesz plik server.xml i szczegóły konfiguracji serwera Tomcat, deweloperzy mogą szybko diagnozować i rozwiązywać te problemy, co pozwala zaoszczędzić czas i nakład pracy.
  • Wdrażanie aplikacji w usłudze Tomcat: aby wdrożyć aplikację internetową Java w usłudze Tomcat, deweloperzy muszą wiedzieć, jak skonfigurować plik server.xml i inne ustawienia serwera Tomcat. Musisz zrozumieć te szczegóły, aby pomyślnie wdrożyć aplikacje i upewnić się, że działają bezproblemowo na serwerze.

Podczas tworzenia aplikacji z wbudowanym serwerem Tomcat do hostowania obciążenia Java (pliku WAR lub JAR) są dostępne pewne ustawienia domyślne konfiguracji Tomcat. Aby uzyskać szczegółowe informacje, w tym domyślną konfigurację serwera internetowego Tomcat, możesz zapoznać się z oficjalną dokumentacją serwera Apache Tomcat .

Ponadto istnieją pewne przekształcenia, które są stosowane dodatkowo do server.xml w dystrybucji Tomcat przy uruchomieniu. Te przekształcenia obejmują zmiany ustawień łącznika, hosta i zaworu .

Najnowsze wersje serwera Tomcat mają server.xml (8.5.58 i 9.0.38). Starsze wersje serwera Tomcat nie używają przekształceń i mogą mieć inne zachowanie w rezultacie.

Łącznik

<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 jest ustawiony na 16384.
  • URIEncoding jest ustawiony na UTF-8.
  • connectionTimeout jest ustawiona jako WEBSITE_TOMCAT_CONNECTION_TIMEOUT, która domyślnie ma wartość 240000.
  • maxThreads jest ustawiona jako WEBSITE_CATALINA_MAXTHREADS, która domyślnie ma wartość 200.
  • maxConnections jest ustawiona jako WEBSITE_CATALINA_MAXCONNECTIONS, która domyślnie ma wartość 10000.

Uwaga

Ustawienia connectionTimeout, maxThreadsi maxConnections można dostroić za pomocą ustawień aplikacji.

Poniżej przedstawiono przykładowe polecenia interfejsu wiersza polecenia, których można użyć do zmiany wartości connectionTimeout, maxThreadslub 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

Łącznik używa adresu kontenera zamiast 127.0.0.1.

Gospodarz

<Host appBase="${site.appbase}" xmlBase="${site.xmlbase}" unpackWARs="${site.unpackwars}" workDir="${site.tempdir}" errorReportValveClass="com.microsoft.azure.appservice.AppServiceErrorReportValve" name="localhost" autoDeploy="true">
  • appBase jest ustawiona na AZURE_SITE_APP_BASE, co domyślnie odnosi się do lokalnej WebappsLocalPath.
  • xmlBase jest ustawiona jako AZURE_SITE_HOME, która domyślnie ma wartość /site/wwwroot.
  • unpackWARs jest ustawiona jako AZURE_UNPACK_WARS, która domyślnie ma wartość true.
  • workDir jest ustawiona na JAVA_TMP_DIR, która domyślnie ustawia TMP jako wartość.
  • errorReportValveClass używa naszego niestandardowego zaworu zgłaszania błędów.

Zawór

<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 jest ustawiona jako AZURE_LOGGING_DIR, która domyślnie ma wartość home\logFiles.
  • maxDays jest ustawiona jako WEBSITE_HTTPLOGGING_RETENTION_DAYS, która domyślnie ma wartość 7. Ta wartość jest zgodna z domyślną platformą rejestrowania aplikacji.

W systemie Linux ma wszystkie te same dostosowania i dodaje niektóre strony błędów i raportowania do zaworu:

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

Odwiedź centrum Azure dla programistów Java, aby znaleźć przewodniki Szybki Start platformy Azure, samouczki i dokumentację referencyjną języka Java.