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

W tym artykule przedstawiono najbardziej typową konfigurację wdrażania i środowiska uruchomieniowego dla aplikacji Java w usłudze App Service. Jeśli nigdy nie używasz usługi aplikacja systemu Azure Service, 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, znajdują się w często zadawanych pytaniach dotyczących usługi App Service.

usługa aplikacja systemu Azure uruchamia aplikacje internetowe Java w w pełni zarządzanej usłudze w trzech wariantach:

• Java SE — może uruchomić aplikację wdrożoną jako pakiet JAR zawierający serwer osadzony (taki jak Spring Boot, Dropwizard, Quarkus lub jeden z osadzonym serwerem Tomcat lub Jetty).
• Tomcat — wbudowany serwer Tomcat może uruchamiać aplikację wdrożona jako pakiet WAR.
• JBoss EAP — obsługiwane tylko w przypadku aplikacji systemu Linux w warstwach cenowych Bezpłatna, Premium v3 i Izolowana wersja 2. Wbudowany serwer JBoss EAP może uruchamiać aplikację wdrożona jako pakiet WAR lub EAR.

Uwaga

W przypadku aplikacji Spring zalecamy używanie usługi Azure Spring Apps. Można jednak nadal używać usługi aplikacja systemu Azure jako miejsca docelowego. Aby uzyskać porady, zobacz Wskazówki dotyczące miejsca docelowego obciążenia w języku Java.

Pokaż wersję języka Java

Linux

Aby wyświetlić bieżącą wersję języka Java, uruchom następujące polecenie w usłudze 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"

Windows

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

az webapp config show --name <app-name> --resource-group <resource-group-name> --query "[javaVersion, javaContainer, javaContainerVersion]"

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 windows | grep java

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

Wdrażanie aplikacji

Narzędzia Build Tools

Maven

Za pomocą wtyczki Maven dla usługi Azure Web Apps możesz łatwo przygotować projekt Java maven dla aplikacji internetowej platformy Azure 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 pliku build.gradle:

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

2. Skonfiguruj szczegóły aplikacji internetowej. Odpowiednie zasoby platformy Azure są tworzone, jeśli nie istnieją. Poniżej przedstawiono przykładową konfigurację, 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
   

Środowiska IDE

Platforma Azure zapewnia bezproblemowe środowisko programowania w usłudze Java App Service w popularnych środowiskach IDE Języka Java, w tym:

• VS Code: Java Web Apps z programem Visual Studio Code
• IntelliJ IDEA:Tworzenie aplikacji internetowej Hello World dla usługi aplikacja systemu Azure przy użyciu środowiska IntelliJ
• Eclipse:Tworzenie aplikacji internetowej Hello World dla usługi aplikacja systemu Azure przy użyciu środowiska Eclipse

Kudu API

Aby wdrożyć pliki .jar w środowisku Java SE, użyj /api/publish punktu końcowego witryny Kudu. Aby uzyskać więcej informacji na temat tego interfejsu API, zobacz tę dokumentację.

Uwaga

Aby zidentyfikować i uruchomić aplikację, aplikacja .jar musi mieć nazwę app.jar dla usługi App Service. Wtyczka Maven wykonuje to automatycznie podczas wdrażania. Jeśli nie chcesz zmienić nazwy pliku JAR na app.jar, możesz przekazać skrypt powłoki za pomocą polecenia , aby uruchomić aplikację .jar. Wklej ścieżkę bezwzględną do tego skryptu w polu tekstowym Plik startowy w sekcji Konfiguracja portalu. Skrypt uruchamiania nie jest uruchamiany z katalogu, do którego został umieszczony. W związku z tym zawsze należy używać ścieżek bezwzględnych do odwoływania się do plików w skrypcie startowym (na przykład: java -jar /home/myapp/myapp.jar).

Aby wdrożyć pliki war w usłudze Tomcat, użyj punktu końcowego /api/wardeploy/ do postu pliku archiwum. Aby uzyskać więcej informacji na temat tego interfejsu API, zobacz tę dokumentację.

Aby wdrożyć pliki war na platformie JBoss, użyj punktu końcowego /api/wardeploy/ do postu pliku archiwum. Aby uzyskać więcej informacji na temat tego interfejsu API, zobacz tę dokumentację.

Aby wdrożyć pliki ear, użyj protokołu FTP. Aplikacja .ear jest wdrażana w katalogu głównym kontekstu zdefiniowanym w konfiguracji aplikacji. Jeśli na przykład katalog główny kontekstu aplikacji to <context-root>myapp</context-root>, możesz przeglądać witrynę w ścieżce /myapp : http://my-app-name.azurewebsites.net/myapp. Jeśli chcesz, aby aplikacja internetowa była obsługiwana w ścieżce głównej, upewnij się, że aplikacja ustawia katalog główny kontekstu na ścieżkę główną: <context-root>/</context-root>. Aby uzyskać więcej informacji, zobacz Ustawianie katalogu głównego kontekstu 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 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 aplikacja systemu Azure Service.

Przesyłanie strumieniowe dzienników diagnostycznych

Linux

Dostęp do dzienników konsoli wygenerowanych z poziomu kontenera można uzyskać.

Najpierw włącz rejestrowanie kontenerów, uruchamiając następujące polecenie:

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

Zastąp <app-name> wartości i <resource-group-name> nazwami odpowiednimi dla 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 nie widzisz dzienników konsoli, sprawdź ponownie w ciągu 30 sekund.

Aby zatrzymać przesyłanie strumieniowe dzienników w dowolnym momencie, wpisz Ctrl+C.

Możesz również sprawdzić pliki dziennika w przeglądarce pod adresem https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Windows

Aby uzyskać dostęp do dzienników konsoli wygenerowanych wewnątrz kodu aplikacji w usłudze App Service, włącz rejestrowanie diagnostyczne, uruchamiając następujące polecenie w usłudze Cloud Shell:

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

Możliwe wartości parametru --level to: Error, Warning, Info i Verbose. Każdy kolejny poziom obejmuje poprzedni poziom. Na przykład poziom Error obejmuje tylko komunikaty o błędach, a poziom Verbose obejmuje wszystkie komunikaty.

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

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

Jeśli nie widzisz dzienników konsoli, sprawdź ponownie w ciągu 30 sekund.

Uwaga

Pliki dzienników można także sprawdzać w przeglądarce pod adresem https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Aby w dowolnym momencie zatrzymać przesyłanie strumieniowe dzienników, naciśnij kombinację klawiszy 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 w kontenerze, należy uruchomić aplikację.

Wklej następujący adres URL do przeglądarki i zastąp wartość <app-name> nazwą swojej aplikacji:

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

Jeśli nie masz jeszcze uwierzytelnienia, musisz uwierzytelnić się w subskrypcji platformy Azure, aby nawiązać połączenie. Po uwierzytelnieniu zostanie wyświetlona powłoka w przeglądarce umożliwiająca uruchamianie poleceń w kontenerze.

Uwaga

Wszelkie zmiany wprowadzone poza katalogiem /home są przechowywane w samym kontenerze i nie są zachowywane po ponownym uruchomieniu aplikacji.

Aby otworzyć zdalną sesję SSH z komputera lokalnego, zobacz Otwieranie sesji SSH z poziomu powłoki zdalnej.

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.

Java Profiler

Wszystkie środowiska uruchomieniowe Języka Java w usłudze aplikacja systemu Azure są dostarczane z narzędziem JDK Flight Recorder do profilowania obciążeń Java. Służy do rejestrowania zdarzeń JVM, systemu i aplikacji oraz rozwiązywania problemów w aplikacjach.

Aby dowiedzieć się więcej na temat programu Java Profiler, odwiedź dokumentację aplikacja systemu Azure Insights.

Flight Recorder

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

Linux

Za pomocą protokołu SSH w usłudze App Service uruchom jcmd polecenie , aby wyświetlić listę wszystkich uruchomionych procesów Java. Oprócz jcmd siebie powinna być widoczna aplikacja Java z numerem identyfikatora 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

Wykonaj następujące polecenie, aby uruchomić 30-sekundowe nagranie maszyny wirtualnej JVM. Profiluje maszynę JVM i tworzy plik JFR o nazwie jfr_example.jfr w katalogu głównym. (Zastąp wartość 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.

Nagrywanie ciągłe

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ść ustawienia aplikacji JAVA_OPTS jest przekazywana do polecenia po uruchomieniu java 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ć bieżące dane nagrywania JFR.dump przy użyciu polecenia .

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

Windows

Nagranie z czasem

Aby upłynąć pewien czas nagrywania, potrzebujesz identyfikatora PID (identyfikatora procesu) aplikacji Java. Aby znaleźć identyfikator PID, otwórz przeglądarkę w witrynie SCM aplikacji internetowej pod adresem https://<your-site-name>.scm.azurewebsites.net/ProcessExplorer/. Na tej stronie przedstawiono uruchomione procesy w aplikacji internetowej. Znajdź proces o nazwie "java" w tabeli i skopiuj odpowiedni identyfikator PID (identyfikator procesu).

Następnie otwórz konsolę debugowania na górnym pasku narzędzi witryny SCM i uruchom następujące polecenie. Zastąp wartość <pid> skopiowaną wcześniej identyfikatorem procesu. To polecenie uruchamia 30-sekundowe rejestrowanie profilera aplikacji Java i generuje plik o nazwie timed_recording_example.jfr w C:\home katalogu.

jcmd <pid> JFR.start name=TimedRecording settings=profile duration=30s filename="C:\home\timed_recording_example.JFR"

Analizowanie .jfr plików

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

Rejestrowanie aplikacji

Linux

Włącz rejestrowanie aplikacji za pośrednictwem witryny Azure Portal lub interfejsu wiersza polecenia platformy Azure, aby skonfigurować usługę App Service w celu zapisania standardowych strumieni błędów konsoli aplikacji i standardowych strumieni błędów konsoli do lokalnego systemu plików lub usługi Azure Blob Storage. 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 katalogu /home/LogFiles/Application/ .

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

Windows

Włącz rejestrowanie aplikacji za pośrednictwem witryny Azure Portal lub interfejsu wiersza polecenia platformy Azure, aby skonfigurować usługę App Service w celu zapisania standardowych strumieni błędów konsoli aplikacji i standardowych strumieni błędów konsoli do lokalnego systemu plików lub usługi Azure Blob Storage. Rejestrowanie w lokalnym wystąpieniu systemu plików usługi App Service jest wyłączone 12 godzin po jej włączeniu. 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 katalogu /home/LogFiles/Application/ .

Jeśli aplikacja używa logback lub Log4j do śledzenia, możesz przekazać te ślady do przeglądu w usłudze aplikacja systemu Azure Insights, korzystając z instrukcji konfiguracji struktury rejestrowania w artykule Eksploruj dzienniki śledzenia języka Java w usłudze Application Insights.

Uwaga

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

Dostosowywanie i dostrajanie

usługa aplikacja systemu Azure obsługuje dostrajanie i dostosowywanie za pośrednictwem witryny Azure Portal i interfejsu wiersza polecenia. Zapoznaj się z następującymi artykułami dotyczącymi konfiguracji aplikacji internetowej innej niż Java:

• Konfigurowanie ustawień aplikacji
• Konfigurowanie domeny niestandardowej
• Konfigurowanie powiązań TLS/SSL
• Dodawanie sieci CDN
• Konfigurowanie witryny Kudu

Lokalne kopiowanie zawartości aplikacji

Ustaw ustawienie JAVA_COPY_ALL aplikacji na wartość , aby true skopiować zawartość aplikacji do lokalnego procesu roboczego z udostępnionego 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.

Deweloperzy z jedną aplikacją z jednym miejscem wdrożenia w planie usługi App Service mogą korzystać z następujących opcji:

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

Podczas dostrajania ustawień sterty aplikacji przejrzyj szczegóły planu usługi App Service i uwzględnij wiele aplikacji i miejsca 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 witrynie Azure Portal w obszarze Ustawienia aplikacji internetowej utwórz nowe ustawienie aplikacji o nazwie o JAVA_OPTS 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>

Wstępne kompilowanie plików 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 za pomocą tego pliku kompilacji Ant.

robots933456 w dziennikach

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 oznacza po prostu, że ścieżka nie istnieje, ale pozwala usłudze App Service sprawdzić, czy kontener jest w dobrej kondycji i jest gotowy do reagowania 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ż automatycznie zaktualizować wersję poprawki, gdy staną się dostępne nowe wersje pomocnicze. W większości przypadków aplikacje produkcyjne powinny używać przypiętych wersji JVM poprawki. Zapobiega to nieoczekiwanym awariom podczas automatycznej aktualizacji wersji poprawki. Wszystkie aplikacje internetowe Java używają 64-bitowych maszyn JVM i nie można jej konfigurować.

Jeśli używasz serwera Tomcat, możesz przypiąć wersję poprawki serwera Tomcat. W systemie Windows można niezależnie przypiąć wersje poprawek maszyn wirtualnych JVM i Tomcat. W systemie Linux możesz przypiąć wersję poprawki serwera Tomcat; wersja poprawki maszyny wirtualnej JVM jest również przypięta, ale nie można jej oddzielnie konfigurować.

Jeśli zdecydujesz się przypiąć wersję pomocniczą, musisz okresowo aktualizować wersję pomocniczą JVM w aplikacji. Aby upewnić się, że aplikacja działa w nowszej wersji pomocniczej, utwórz miejsce przejściowe i zwiększ wersję pomocniczą w miejscu przejściowym. Po potwierdzeniu, że aplikacja działa poprawnie w nowej wersji pomocniczej, możesz zamienić miejsca przejściowe i produkcyjne.

Uruchamianie interfejsu wiersza polecenia narzędzia JBoss

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

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

W zależności od tego, gdzie JBoss 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 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, użyj niestandardowego skryptu uruchamiania lub polecenia uruchamiania. Aby zapoznać się z przykładem kompleksowego, zobacz Konfigurowanie źródeł danych dla aplikacji Tomcat, JBoss lub Java SE w usłudze aplikacja systemu Azure 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ń interfejsu wiersza polecenia, które można uruchomić, zobacz:

• Dokumentacja oprogramowania Red Hat JBoss EAP
• WildFly CLI Recipes

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. Po uruchomieniu wielu wystąpień z skalowaniem automatycznym wystąpienia JBoss EAP komunikują się ze sobą za pośrednictwem podsieci określonej w integracji sieci wirtualnej. Klastrowanie można wyłączyć, tworząc ustawienie aplikacji o nazwie WEBSITE_DISABLE_CLUSTERING z dowolną wartością.

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 protokołu JBoss EAP używają protokołu odnajdywania FILE_PING JGroups w celu odnajdywania nowych wystąpień i utrwalania informacji klastra, takich jak członkowie klastra, ich identyfikatory i adresy IP. W usłudze App Service te pliki znajdują się w obszarze /home/clusterinfo/. Pierwsze wystąpienie protokołu EAP do uruchomienia uzyskuje uprawnienia do odczytu/zapisu w pliku członkostwa w klastrze. Inne wystąpienia odczytują plik, znajdują węzeł podstawowy i koordynują go z tym węzłem, który ma zostać uwzględniony w klastrze i dodawany do pliku.

Uwaga

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

Typy planów usługi App Service w wersji 3 w warstwie Premium w wersji 3 i izolowanej w wersji 2 można opcjonalnie dystrybuować między Strefy dostępności w celu zwiększenia odporności i niezawodności obciążeń o znaczeniu krytycznym dla działania firmy. Ta architektura jest również nazywana nadmiarowością stref. Funkcja klastrowania JBoss EAP jest zgodna z funkcją nadmiarowości strefy.

Reguły automatycznego skalowania

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

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

Nie trzeba przyrostowo dodawać wystąpień (skalowanie w poziomie), można dodać wiele wystąpień do klastra naraz.

Plany usługi App Service

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

Cykl życia serwera JBoss

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

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

Zapoznaj się z odpowiednimi sekcjami poniżej, aby uzyskać szczegółowe informacje, a także możliwości dostosowywania go (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ą dostarczane 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.keyStorejavax.net.ssl.keyStorePassword i javax.net.ssl.keyStoreType zostaną dodane do zmiennej środowiskowejJAVA_TOOL_OPTIONS.
• Niektóre początkowe konfiguracje JVM są określane, takie jak katalogi rejestrowania i parametry stert 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_LIMITaplikacji , 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), gdy program JBoss zostanie zatrzymany.
• 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 program JBoss przy użyciu clustering konfiguracji. standalone W przeciwnym razie używana jest konfiguracja.
  • W przypadku clustering konfiguracji używany jest plik konfiguracji serwera standalone-azure-full-ha.xml .
  • W przypadku standalone konfiguracji używany jest plik konfiguracji serwera standalone-full.xml .

2. Faza uruchamiania serwera

• Jeśli program JBoss zostanie uruchomiony w clustering konfiguracji:
  • Każde wystąpienie JBoss otrzymuje identyfikator wewnętrzny z zakresu od 0 do liczby wystąpień, 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 ma miejsce identyczne wystąpienie usługi, które uległo awarii wcześniej i pozostawiło niezatwierdzone transakcje. Serwer jest skonfigurowany do wznowienia pracy nad tymi transakcjami.
• Niezależnie od tego, czy narzędzie JBoss rozpoczyna się od clustering konfiguracji lub standalone , jeśli wersja serwera ma wartość 7.4 lub nowszą, a środowisko uruchomieniowe korzysta z języka Java 17, konfiguracja zostanie zaktualizowana w celu włączenia podsystemu Elytron pod kątem 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 większej liczby flag mających wpływ na uruchomienie JBoss.

3. Faza konfiguracji serwera

• Na początku tej fazy usługa App Service najpierw czeka, aż serwer JBoss i interfejs administracyjny będą gotowe do odbierania żądań przed kontynuowaniem. Może to potrwać kilka sekund, jeśli usługa Application Insights jest włączona.
• Gdy zarówno serwer JBoss, jak i interfejs administracyjny są gotowe, usługa App Service wykonuje następujące czynności:
  • Dodaje moduł azure.appserviceJBoss, który udostępnia klasy narzędzi do rejestrowania i integracji z usługą App Service.
  • Aktualizuje rejestrator konsoli tak, aby używał trybu bezbarwnego, tak aby pliki dziennika nie są pełne sekwencji ucieczki kolorów.
  • Konfiguruje integrację z dziennikami usługi Azure Monitor.
  • Aktualizuje powiązania adresów IP interfejsów WSDL i zarządzania.
  • Dodaje moduł azure.appservice.easyauth JBoss 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, automatycznie wykrywa adresy URL JDBC usługi App Service 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 i dodaje źródło danych dla każdego adresu URL JDBC i ustawia nazwę 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.
• clustering Jeśli konfiguracja jest włączona, sprawdzany jest rejestrator konsoli, który ma zostać skonfigurowany.
• Jeśli istnieją pliki JAR wdrożone w katalogu /home/site/libs , 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 w następujący sposób:
  • Jeśli skonfigurowano polecenie uruchamiania (w witrynie Azure Portal z interfejsem wiersza polecenia platformy Azure itp.), 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 główny (nie ma potrzeby sudo), aby móc zainstalować pakiety systemu Linux lub uruchomić interfejs wiersza polecenia JBoss, aby wykonać więcej poleceń instalacji/dostosowywania narzędzia JBoss (tworzenie źródeł danych, instalowanie kart zasobów) itp. Aby uzyskać informacje na temat poleceń zarządzania pakietami systemu Ubuntu, zobacz dokumentację systemu Ubuntu Server. Aby zapoznać się z poleceniami interfejsu wiersza polecenia platformy JBoss, zobacz JBoss Management CLI Guide (Przewodnik po interfejsie wiersza polecenia zarządzania platformą JBoss).

4. Faza wdrażania aplikacji

Skrypt uruchamiania wdraża aplikacje na platformie JBoss, wyszukując następujące lokalizacje w kolejności pierwszeństwa:

• Jeśli skonfigurowano ustawienie WEBSITE_JAVA_WAR_FILE_NAMEaplikacji , wdróż plik wyznaczony przez niego.
• Jeśli /home/site/wwwroot/app.war istnieje, wdróż go.
• Jeśli istnieją inne pliki EAR i WAR w katalogu /home/site/wwwroot, wdróż je.
• Jeśli plik /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 katalogu /home/site/wwwroot istnieją jakiekolwiek autonomiczne strony JSP, skopiuj je do katalogu głównego serwera internetowego i wdróż je jako jedną aplikację internetową.
• Jeśli nie znaleziono jeszcze ż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 zakończeniu kroków wdrażania serwer JBoss 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 kończy się nieprawidłowo w clustering konfiguracji, wykonywana jest ostateczna funkcja o nazwie emit_alert_tx_store_not_empty . Funkcja sprawdza, czy proces JBoss pozostawił w dysku plik magazynu transakcji nonempty; 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 nieistniejące 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: dzięki zrozumieniu pliku server.xml i szczegółów konfiguracji serwera Tomcat można 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ć. Obejmuje to 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. Dzięki zrozumieniu pliku server.xml i szczegółów 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. Zrozumienie tych szczegółów jest niezbędne do pomyślnego wdrażania aplikacji i zapewnienia, że działają bezproblemowo na serwerze.

Podczas tworzenia aplikacji z wbudowanym serwerem Tomcat do hostowania obciążenia Java (pliku WAR lub pliku JAR) istnieją pewne ustawienia, które są gotowe do skonfigurowania serwera 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ą dalej stosowane na podstawie server.xml dystrybucji Tomcat po uruchomieniu. Są to przekształcenia 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 ustawiona na wartość 16384
• URIEncoding jest ustawiona na wartość UTF-8
• connectionTimeout jest ustawiona na WEBSITE_TOMCAT_CONNECTION_TIMEOUTwartość , która jest domyślnie ustawiona na 240000
• maxThreads jest ustawiona na WEBSITE_CATALINA_MAXTHREADSwartość , która jest domyślnie ustawiona na 200
• maxConnections jest ustawiona na WEBSITE_CATALINA_MAXCONNECTIONSwartość , która jest domyślnie ustawiona na 10000

Uwaga

Ustawienia connectionTimeout, maxThreads i maxConnections można dostosować za pomocą ustawień aplikacji

Poniżej przedstawiono przykładowe polecenia interfejsu wiersza polecenia, których można użyć do zmiany wartości connectionTimeout, maxThreads lub 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_BASEwartość , która jest domyślnie ustawiona na wartość lokalną WebappsLocalPath
• xmlBase jest ustawiona na AZURE_SITE_HOMEwartość , która jest domyślnie ustawiona na /site/wwwroot
• unpackWARs jest ustawiona na AZURE_UNPACK_WARSwartość , która jest domyślnie ustawiona na true
• workDir jest ustawiona na JAVA_TMP_DIRwartość , która jest domyślnie ustawiona TMP
• errorReportValveClass używa naszego niestandardowego zaworu raportu o błędach

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 na AZURE_LOGGING_DIRwartość , która jest domyślnie ustawiona na home\logFiles
• maxDays ma wartość WEBSITE_HTTPLOGGING_RETENTION_DAYS, która jest domyślnie ustawiona na 7. Jest to zgodne z domyślną platformą rejestrowania aplikacji

W systemie Linux ma wszystkie te same dostosowania, a także:

• Dodaje do zaworu niektóre strony błędów i raportowania:

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

Następne kroki

Odwiedź centrum Azure for Java Developers, aby znaleźć przewodniki Szybki start platformy Azure, samouczki i dokumentację referencyjną języka Java.

• App Service dla systemu Linux — często zadawane pytania
• Dokumentacja zmiennych środowiskowych i ustawień aplikacji