Konfigurowanie aplikacji Java dla usługi aplikacja systemu Azure

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.

usługa aplikacja systemu Azure umożliwia deweloperom języka Java szybkie tworzenie, wdrażanie i skalowanie aplikacji internetowych Java SE, Tomcat i JBoss EAP w w pełni zarządzanej usłudze. Wdróż aplikacje za pomocą wtyczek maven z wiersza polecenia lub w edytorach, takich jak IntelliJ, Eclipse lub Visual Studio Code.

Ten przewodnik zawiera kluczowe pojęcia i instrukcje dla deweloperów języka Java korzystających z usługi 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.

Pokaż wersję języka Java

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

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.11.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. 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 11</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.7.1"
    }
    
  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 9.0' // or 'Java SE' if you want to run an executable jar
          javaVersion = 'Java 8'
        }
        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:

Kudu API

Java SE

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

Tomcat

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

JBoss EAP

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.

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

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.

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.

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

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.

Połączenie SSH

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

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 profilera Java, odwiedź dokumentację aplikacja systemu Azure Szczegółowe informacje.

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.

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"

Za pomocą protokołu SSH w usłudze App Service uruchom jcmd polecenie , aby wyświetlić listę wszystkich uruchomionych procesów Java. Oprócz samego narzędzia jcmd powinna zostać wyświetlona aplikacja Java uruchomiona przy użyciu numeru 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"

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

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 skonfigurowaniu. 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/ .

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.

Jeśli aplikacja używa logback lub Log4j do śledzenia, możesz przekazać te ślady do przeglądu w aplikacja systemu Azure Szczegółowe informacje, korzystając z instrukcji konfiguracji struktury rejestrowania w temacie Eksploruj dzienniki śledzenia języka Java w aplikacji Szczegółowe informacje.

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:

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 Aplikacja Ustawienia dla aplikacji internetowej utwórz nowe ustawienie aplikacji o nazwie JAVA_OPTS Java SE lub CATALINA_OPTS tomcat 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 Aplikacja Ustawienia dla aplikacji internetowej utwórz nowe ustawienie aplikacji o nazwie z 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.

Zabezpieczanie aplikacji

Aplikacje Java działające w usłudze App Service mają ten sam zestaw najlepszych rozwiązań w zakresie zabezpieczeń co inne aplikacje.

Uwierzytelnianie użytkowników (Easy Auth)

Skonfiguruj uwierzytelnianie aplikacji w witrynie Azure Portal przy użyciu opcji Uwierzytelnianie i autoryzacja . W tym miejscu możesz włączyć uwierzytelnianie przy użyciu identyfikatora Entra firmy Microsoft lub logów społecznościowych, takich jak Facebook, Google lub GitHub. Konfiguracja witryny Azure Portal działa tylko podczas konfigurowania pojedynczego dostawcy uwierzytelniania. Aby uzyskać więcej informacji, zobacz Configure your App Service app to use Microsoft Entra sign-in and the related articles for other identity providers (Konfigurowanie aplikacji usługi App Service pod kątem korzystania z logowania microsoft Entra) i powiązanych artykułów dla innych dostawców tożsamości. Jeśli musisz włączyć wielu dostawców logowania, postępuj zgodnie z instrukcjami w temacie Dostosowywanie logów i wylogowywanie.

Java SE

Deweloperzy platformy Spring Boot mogą używać szablonu startowego Microsoft Entra Spring Boot do zabezpieczania aplikacji przy użyciu znanych adnotacji i interfejsów API rozwiązania Spring Security. Pamiętaj, aby zwiększyć maksymalny rozmiar nagłówka w pliku application.properties . Sugerujemy wartość 16384.

Tomcat

Aplikacja Tomcat może uzyskiwać dostęp do oświadczeń użytkownika bezpośrednio z serwletu przez rzutowanie obiektu Principal do obiektu Map. Obiekt Map mapuje każdy typ oświadczenia na kolekcję oświadczeń dla tego typu. W poniższym przykładzie request kodu jest wystąpieniem HttpServletRequestklasy .

Map<String, Collection<String>> map = (Map<String, Collection<String>>) request.getUserPrincipal();

Teraz możesz sprawdzić obiekt pod kątem Map dowolnego konkretnego oświadczenia. Na przykład poniższy fragment kodu iteruje wszystkie typy oświadczeń i drukuje zawartość każdej kolekcji.

for (Object key : map.keySet()) {
        Object value = map.get(key);
        if (value != null && value instanceof Collection {
            Collection claims = (Collection) value;
            for (Object claim : claims) {
                System.out.println(claims);
            }
        }
    }

Aby wylogować użytkowników, użyj ścieżki /.auth/ext/logout . Aby wykonać inne akcje, zobacz dokumentację dotyczącą dostosowywania logów i wylogowyń. Istnieje również oficjalna dokumentacja interfejsu Tomcat HttpServletRequest i jego metod. Następujące metody serwletu są również nawodnione na podstawie konfiguracji usługi App Service:

public boolean isSecure()
public String getRemoteAddr()
public String getRemoteHost()
public String getScheme()
public int getServerPort()

Aby wyłączyć tę funkcję, utwórz ustawienie aplikacji o nazwie WEBSITE_AUTH_SKIP_PRINCIPAL z wartością 1. Aby wyłączyć wszystkie filtry serwletów dodane przez usługę App Service, utwórz ustawienie o nazwie WEBSITE_SKIP_FILTERS z wartością 1.

Konfigurowanie protokołu TLS/SSL

Aby przekazać istniejący certyfikat TLS/SSL i powiązać go z nazwą domeny aplikacji, postępuj zgodnie z instrukcjami w temacie Zabezpieczanie niestandardowej nazwy DNS z powiązaniem TLS/SSL w usłudze aplikacja systemu Azure Service. Aplikację można również skonfigurować tak, aby wymuszała protokół TLS/SSL.

Używanie odwołań do usługi KeyVault

Usługa Azure KeyVault zapewnia scentralizowane zarządzanie wpisami tajnymi za pomocą zasad dostępu i historii inspekcji. Wpisy tajne (takie jak hasła lub parametry połączenia) można przechowywać w usłudze KeyVault i uzyskiwać dostęp do tych wpisów tajnych w aplikacji za pomocą zmiennych środowiskowych.

Najpierw postępuj zgodnie z instrukcjami dotyczącymi udzielania aplikacji dostępu do magazynu kluczy i tworzenia odwołania do magazynu kluczy do wpisu tajnego w ustawieniu aplikacji. Możesz sprawdzić, czy odwołanie jest rozpoznawane jako wpis tajny, wyświetlając zmienną środowiskową podczas zdalnego uzyskiwania dostępu do terminalu usługi App Service.

Aby wstrzyknąć te wpisy tajne w pliku konfiguracji spring lub Tomcat, użyj składni iniekcji zmiennej środowiskowej (${MY_ENV_VAR}). Aby uzyskać informacje o plikach konfiguracji platformy Spring, zapoznaj się z tą dokumentacją dotyczącą konfiguracji zewnętrznych.

Korzystanie z magazynu kluczy Java

Domyślnie wszystkie certyfikaty publiczne lub prywatne przekazane do usługi App Service Dla systemu Linux są ładowane do odpowiednich magazynów kluczy Java podczas uruchamiania kontenera. Po przekazaniu certyfikatu należy ponownie uruchomić usługę App Service, aby była ładowana do magazynu kluczy Java. Certyfikaty publiczne są ładowane do magazynu kluczy w $JRE_HOME/lib/security/cacertslokalizacji , a certyfikaty prywatne są przechowywane w programie $JRE_HOME/lib/security/client.jks.

Do szyfrowania połączenia JDBC z certyfikatami w magazynie kluczy Java może być konieczna większa konfiguracja. Zapoznaj się z dokumentacją wybranego sterownika JDBC.

Inicjowanie magazynu kluczy Java

Aby zainicjować obiekt, załaduj import java.security.KeyStore plik magazynu kluczy przy użyciu hasła. Domyślne hasło dla obu magazynów kluczy to changeit.

KeyStore keyStore = KeyStore.getInstance("jks");
keyStore.load(
    new FileInputStream(System.getenv("JRE_HOME")+"/lib/security/cacerts"),
    "changeit".toCharArray());

KeyStore keyStore = KeyStore.getInstance("pkcs12");
keyStore.load(
    new FileInputStream(System.getenv("JRE_HOME")+"/lib/security/client.jks"),
    "changeit".toCharArray());

Ręczne ładowanie magazynu kluczy

Certyfikaty można załadować ręcznie do magazynu kluczy. Utwórz ustawienie aplikacji z SKIP_JAVA_KEYSTORE_LOADwartością 1 , aby wyłączyć usługę App Service z automatycznego ładowania certyfikatów do magazynu kluczy. Wszystkie certyfikaty publiczne przekazane do usługi App Service za pośrednictwem witryny Azure Portal są przechowywane w obszarze /var/ssl/certs/. Certyfikaty prywatne są przechowywane w obszarze /var/ssl/private/.

Możesz wchodzić w interakcję z narzędziem Java Key Tool lub debugować go, otwierając połączenie SSH z usługą App Service i uruchamiając polecenie keytool. Zapoznaj się z dokumentacją narzędzia key, aby uzyskać listę poleceń. Aby uzyskać więcej informacji na temat interfejsu API magazynu kluczy, zobacz oficjalną dokumentację.

Konfigurowanie platform APM

W tej sekcji przedstawiono sposób łączenia aplikacji Java wdrożonych w usłudze aplikacja systemu Azure przy użyciu platform azure Monitor Application Szczegółowe informacje, NewRelic i AppDynamics application performance monitoring (APM).

Konfigurowanie usługi Application Insights

Usługa Azure Monitor Application Szczegółowe informacje to natywna usługa monitorowania aplikacji w chmurze, która umożliwia klientom obserwowanie awarii, wąskich gardeł i wzorców użycia w celu poprawy wydajności aplikacji i skrócenia średniego czasu rozwiązania (MTTR). Za pomocą kilku kliknięć lub poleceń interfejsu wiersza polecenia możesz włączyć monitorowanie dla aplikacji Node.js lub Java, automatycznego zbierania dzienników, metryk i rozproszonych śladów, eliminując konieczność dołączania zestawu SDK w aplikacji. Aby uzyskać więcej informacji na temat dostępnych ustawień aplikacji do konfigurowania agenta, zobacz dokumentację application Szczegółowe informacje.

Azure Portal

Aby włączyć Szczegółowe informacje aplikacji w witrynie Azure Portal, przejdź do pozycji Aplikacja Szczegółowe informacje w menu po lewej stronie i wybierz pozycję Włącz aplikację Szczegółowe informacje. Domyślnie jest używany nowy zasób usługi Application Insights o tej samej nazwie co aplikacja internetowa. Możesz użyć istniejącego zasobu usługi Application Insights lub zmienić nazwę. Wybierz pozycję Zastosuj u dołu.

Interfejs wiersza polecenia platformy Azure

Aby włączyć za pomocą interfejsu wiersza polecenia platformy Azure, należy utworzyć zasób Szczegółowe informacje aplikacji i ustawić kilka ustawień aplikacji w witrynie Azure Portal, aby połączyć aplikację Szczegółowe informacje z aplikacją internetową.

  1. Włączanie rozszerzenia Szczegółowe informacje aplikacji

    az extension add -n application-insights
    
  2. Utwórz zasób aplikacji Szczegółowe informacje przy użyciu następującego polecenia interfejsu wiersza polecenia. Zastąp symbole zastępcze odpowiednią nazwą zasobu i grupą.

    az monitor app-insights component create --app <resource-name> -g <resource-group> --location westus2  --kind web --application-type web
    

    Zanotuj wartości i connectionStringinstrumentationKey, potrzebne będą te wartości w następnym kroku.

    Aby pobrać listę innych lokalizacji, uruchom polecenie az account list-locations.

  1. Ustaw klucz instrumentacji, parametry połączenia i wersję agenta monitorowania jako ustawienia aplikacji internetowej. Zastąp <instrumentationKey> wartości i <connectionString> wartościami z poprzedniego kroku.

    az webapp config appsettings set -n <webapp-name> -g <resource-group> --settings "APPINSIGHTS_INSTRUMENTATIONKEY=<instrumentationKey>" "APPLICATIONINSIGHTS_CONNECTION_STRING=<connectionString>" "ApplicationInsightsAgent_EXTENSION_VERSION=~3" "XDT_MicrosoftApplicationInsights_Mode=default" "XDT_MicrosoftApplicationInsights_Java=1"
    
  1. Ustaw klucz instrumentacji, parametry połączenia i wersję agenta monitorowania jako ustawienia aplikacji internetowej. Zastąp <instrumentationKey> wartości i <connectionString> wartościami z poprzedniego kroku.

    az webapp config appsettings set -n <webapp-name> -g <resource-group> --settings "APPINSIGHTS_INSTRUMENTATIONKEY=<instrumentationKey>" "APPLICATIONINSIGHTS_CONNECTION_STRING=<connectionString>" "ApplicationInsightsAgent_EXTENSION_VERSION=~3" "XDT_MicrosoftApplicationInsights_Mode=default"
    

Konfigurowanie nowej relikwii

  1. Tworzenie konta NewRelic w NewRelic.com

  2. Pobierz agenta Java z witryny NewRelic. Ma on nazwę pliku podobną do newrelic-java-x.x.x.zip.

  3. Skopiuj klucz licencji, który będzie potrzebny do późniejszego skonfigurowania agenta.

  4. Za pomocą protokołu SSH w wystąpieniu usługi App Service utwórz nowy katalog /home/site/wwwroot/apm.

  5. Przekaż rozpakowane pliki agenta Java NewRelic do katalogu w folderze /home/site/wwwroot/apm. Pliki agenta powinny znajdować się w folderze /home/site/wwwroot/apm/newrelic.

  6. Zmodyfikuj plik YAML w lokalizacji /home/site/wwwroot/apm/newrelic/newrelic.yml i zastąp wartość licencji symbolu zastępczego własnym kluczem licencji.

  7. W witrynie Azure Portal przejdź do aplikacji w usłudze App Service i utwórz nowe ustawienie aplikacji.

    • W przypadku aplikacji Java SE utwórz zmienną środowiskową o nazwie JAVA_OPTS z wartością -javaagent:/home/site/wwwroot/apm/newrelic/newrelic.jar.
    • W przypadku serwera Tomcat utwórz zmienną środowiskową o nazwie CATALINA_OPTS z wartością -javaagent:/home/site/wwwroot/apm/newrelic/newrelic.jar.
  1. Tworzenie konta NewRelic w NewRelic.com

  2. Pobierz agenta Java z witryny NewRelic. Ma on nazwę pliku podobną do newrelic-java-x.x.x.zip.

  3. Skopiuj klucz licencji. Będzie on potrzebny do późniejszego skonfigurowania agenta.

  4. Za pomocą protokołu SSH w wystąpieniu usługi App Service utwórz nowy katalog /home/site/wwwroot/apm.

  5. Przekaż rozpakowane pliki agenta Java NewRelic do katalogu w folderze /home/site/wwwroot/apm. Pliki agenta powinny znajdować się w folderze /home/site/wwwroot/apm/newrelic.

  6. Zmodyfikuj plik YAML w lokalizacji /home/site/wwwroot/apm/newrelic/newrelic.yml i zastąp wartość licencji symbolu zastępczego własnym kluczem licencji.

  7. W witrynie Azure Portal przejdź do aplikacji w usłudze App Service i utwórz nowe ustawienie aplikacji.

    • W przypadku aplikacji Java SE utwórz zmienną środowiskową o nazwie JAVA_OPTS z wartością -javaagent:/home/site/wwwroot/apm/newrelic/newrelic.jar.
    • W przypadku serwera Tomcat utwórz zmienną środowiskową o nazwie CATALINA_OPTS z wartością -javaagent:/home/site/wwwroot/apm/newrelic/newrelic.jar.

Jeśli masz już zmienną środowiskową JAVA_OPTS dla lub CATALINA_OPTS, dołącz -javaagent:/... opcję na końcu bieżącej wartości.

Konfigurowanie oprogramowania AppDynamics

  1. Tworzenie konta AppDynamics w AppDynamics.com

  2. Pobierz agenta Java z witryny internetowej AppDynamics. Nazwa pliku jest podobna do AppServerAgent-x.x.x.xxxxx.zip

  3. Użyj konsoli Kudu, aby utworzyć nowy katalog /home/site/wwwroot/apm.

  4. Przekaż pliki agenta Java do katalogu w folderze /home/site/wwwroot/apm. Pliki agenta powinny znajdować się w folderze /home/site/wwwroot/apm/appdynamics.

  5. W witrynie Azure Portal przejdź do aplikacji w usłudze App Service i utwórz nowe ustawienie aplikacji.

    • W przypadku aplikacji Java SE utwórz zmienną środowiskową o nazwie JAVA_OPTS z wartością -javaagent:/home/site/wwwroot/apm/appdynamics/javaagent.jar -Dappdynamics.agent.applicationName=<app-name> , w której <app-name> znajduje się nazwa usługi App Service.
    • W przypadku aplikacji Tomcat utwórz zmienną środowiskową o nazwie CATALINA_OPTS z wartością -javaagent:/home/site/wwwroot/apm/appdynamics/javaagent.jar -Dappdynamics.agent.applicationName=<app-name> , w której <app-name> znajduje się nazwa usługi App Service.
  1. Tworzenie konta AppDynamics w AppDynamics.com

  2. Pobierz agenta Java z witryny internetowej AppDynamics. Nazwa pliku jest podobna do AppServerAgent-x.x.x.xxxxx.zip

  3. Za pomocą protokołu SSH w wystąpieniu usługi App Service utwórz nowy katalog /home/site/wwwroot/apm.

  4. Przekaż pliki agenta Java do katalogu w folderze /home/site/wwwroot/apm. Pliki agenta powinny znajdować się w folderze /home/site/wwwroot/apm/appdynamics.

  5. W witrynie Azure Portal przejdź do aplikacji w usłudze App Service i utwórz nowe ustawienie aplikacji.

    • W przypadku aplikacji Java SE utwórz zmienną środowiskową o nazwie JAVA_OPTS z wartością -javaagent:/home/site/wwwroot/apm/appdynamics/javaagent.jar -Dappdynamics.agent.applicationName=<app-name> , w której <app-name> znajduje się nazwa usługi App Service.
    • W przypadku aplikacji Tomcat utwórz zmienną środowiskową o nazwie CATALINA_OPTS z wartością -javaagent:/home/site/wwwroot/apm/appdynamics/javaagent.jar -Dappdynamics.agent.applicationName=<app-name> , w której <app-name> znajduje się nazwa usługi App Service.

Uwaga

Jeśli masz już zmienną środowiskową JAVA_OPTS dla lub CATALINA_OPTS, dołącz -javaagent:/... opcję na końcu bieżącej wartości.

Konfigurowanie źródeł danych

Java SE

Aby nawiązać połączenie ze źródłami danych w aplikacjach Spring Boot, zalecamy utworzenie parametry połączenia i wstrzyknięcie ich do pliku application.properties.

  1. W sekcji "Konfiguracja" strony usługi App Service ustaw nazwę ciągu, wklej parametry połączenia JDBC w polu wartości i ustaw typ na "Niestandardowy". Opcjonalnie możesz ustawić tę parametry połączenia jako ustawienie miejsca.

    Ta parametry połączenia jest dostępna dla naszej aplikacji jako zmienna środowiskowa o nazwie CUSTOMCONNSTR_<your-string-name>. Na przykład CUSTOMCONNSTR_exampledb.

  2. W pliku application.properties odwołaj się do tego parametry połączenia z nazwą zmiennej środowiskowej. W naszym przykładzie użyjemy następującego polecenia.

    app.datasource.url=${CUSTOMCONNSTR_exampledb}
    

Aby uzyskać więcej informacji, zobacz dokumentację platformy Spring Boot dotyczącą dostępu do danych i konfiguracji zewnętrznych.

Tomcat

Te instrukcje dotyczą wszystkich połączeń bazy danych. Należy wypełnić symbole zastępcze nazwą klasy sterownika wybranej bazy danych i plikiem JAR. Podano tabelę zawierającą nazwy klas i pliki do pobrania sterowników dla typowych baz danych.

baza danych Nazwa klasy sterownika Sterownikiem JDBC
PostgreSQL org.postgresql.Driver Pobierz
MySQL com.mysql.jdbc.Driver Pobierz (wybierz pozycję "Niezależna od platformy")
SQL Server com.microsoft.sqlserver.jdbc.SQLServerDriver Pobierz

Aby skonfigurować serwer Tomcat do używania interfejsu Java Database Połączenie ivity (JDBC) lub interfejsu API trwałości języka Java (JPA), najpierw dostosuj CATALINA_OPTS zmienną środowiskową odczytaną przez serwer Tomcat podczas uruchamiania. Ustaw te wartości za pomocą ustawienia aplikacji w wtyczki App Service Maven:

<appSettings>
    <property>
        <name>CATALINA_OPTS</name>
        <value>"$CATALINA_OPTS -Ddbuser=${DBUSER} -Ddbpassword=${DBPASSWORD} -DconnURL=${CONNURL}"</value>
    </property>
</appSettings>

Możesz też ustawić zmienne środowiskowe na stronie Ustawienia aplikacji konfiguracji>w witrynie Azure Portal.

Następnie ustal, czy źródło danych powinno być dostępne dla jednej aplikacji, czy dla wszystkich aplikacji uruchomionych w serwletze Tomcat.

Źródła danych na poziomie aplikacji

  1. Utwórz plik context.xml w katalogu META-INF/ projektu. Utwórz katalog META-INF/, jeśli nie istnieje.

  2. W context.xml dodaj Context element, aby połączyć źródło danych z adresem JNDI. Zastąp driverClassName symbol zastępczy nazwą klasy sterownika z powyższej tabeli.

    <Context>
        <Resource
            name="jdbc/dbconnection"
            type="javax.sql.DataSource"
            url="${connURL}"
            driverClassName="<insert your driver class name>"
            username="${dbuser}"
            password="${dbpassword}"
        />
    </Context>
    
  3. Zaktualizuj web.xml aplikacji, aby użyć źródła danych w aplikacji.

    <resource-env-ref>
        <resource-env-ref-name>jdbc/dbconnection</resource-env-ref-name>
        <resource-env-ref-type>javax.sql.DataSource</resource-env-ref-type>
    </resource-env-ref>
    

Udostępnione zasoby na poziomie serwera

Instalacje serwera Tomcat w usłudze App Service w systemie Windows istnieją w przestrzeni udostępnionej w planie usługi App Service. Nie można bezpośrednio zmodyfikować instalacji serwera Tomcat dla konfiguracji całego serwera. Aby wprowadzić zmiany konfiguracji na poziomie serwera w instalacji serwera Tomcat, należy skopiować serwer Tomcat do folderu lokalnego, w którym można zmodyfikować konfigurację serwera Tomcat.

Automatyzowanie tworzenia niestandardowego serwera Tomcat podczas uruchamiania aplikacji

Skrypt uruchamiania umożliwia wykonywanie akcji przed uruchomieniem aplikacji internetowej. Skrypt uruchamiania do dostosowywania serwera Tomcat musi wykonać następujące czynności:

  1. Sprawdź, czy serwer Tomcat został już skopiowany i skonfigurowany lokalnie. Jeśli tak było, skrypt uruchamiania może zakończyć się tutaj.
  2. Skopiuj serwer Tomcat lokalnie.
  3. Wprowadź wymagane zmiany konfiguracji.
  4. Wskazuje, że konfiguracja została pomyślnie ukończona.

W przypadku aplikacji systemu Windows utwórz plik o nazwie startup.cmd lub startup.ps1 w wwwroot katalogu. Ten plik jest uruchamiany automatycznie przed uruchomieniem serwera Tomcat.

Oto skrypt programu PowerShell, który wykonuje następujące kroki:

    # Check for marker file indicating that config has already been done
    if(Test-Path "$Env:LOCAL_EXPANDED\tomcat\config_done_marker"){
        return 0
    }

    # Delete previous Tomcat directory if it exists
    # In case previous config isn't completed or a new config should be forcefully installed
    if(Test-Path "$Env:LOCAL_EXPANDED\tomcat"){
        Remove-Item "$Env:LOCAL_EXPANDED\tomcat" --recurse
    }

    # Copy Tomcat to local
    # Using the environment variable $AZURE_TOMCAT90_HOME uses the 'default' version of Tomcat
    Copy-Item -Path "$Env:AZURE_TOMCAT90_HOME\*" -Destination "$Env:LOCAL_EXPANDED\tomcat" -Recurse

    # Perform the required customization of Tomcat
    {... customization ...}

    # Mark that the operation was a success
    New-Item -Path "$Env:LOCAL_EXPANDED\tomcat\config_done_marker" -ItemType File
Przekształcenia

Typowym przypadkiem użycia dostosowywania wersji serwera Tomcat jest zmodyfikowanie server.xmlplików konfiguracji , context.xmllub web.xml Tomcat. Usługa App Service już modyfikuje te pliki w celu udostępnienia funkcji platformy. Aby nadal korzystać z tych funkcji, ważne jest zachowanie zawartości tych plików podczas wprowadzania zmian. W tym celu zalecamy użycie przekształcenia XSL (XSLT). Użyj przekształcenia XSL, aby wprowadzić zmiany w plikach XML przy zachowaniu oryginalnej zawartości pliku.

Przykładowy plik XSLT

W tym przykładzie przekształcenie powoduje dodanie nowego węzła łącznika do server.xmlprogramu . Zanotuj przekształcenie tożsamości, które zachowuje oryginalną zawartość pliku.

    <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:output method="xml" indent="yes"/>

    <!-- Identity transform: this ensures that the original contents of the file are included in the new file -->
    <!-- Ensure that your transform files include this block -->
    <xsl:template match="@* | node()" name="Copy">
      <xsl:copy>
        <xsl:apply-templates select="@* | node()"/>
      </xsl:copy>
    </xsl:template>

    <xsl:template match="@* | node()" mode="insertConnector">
      <xsl:call-template name="Copy" />
    </xsl:template>

    <xsl:template match="comment()[not(../Connector[@scheme = 'https']) and
                                   contains(., '&lt;Connector') and
                                   (contains(., 'scheme=&quot;https&quot;') or
                                    contains(., &quot;scheme='https'&quot;))]">
      <xsl:value-of select="." disable-output-escaping="yes" />
    </xsl:template>

    <xsl:template match="Service[not(Connector[@scheme = 'https'] or
                                     comment()[contains(., '&lt;Connector') and
                                               (contains(., 'scheme=&quot;https&quot;') or
                                                contains(., &quot;scheme='https'&quot;))]
                                    )]
                        ">
      <xsl:copy>
        <xsl:apply-templates select="@* | node()" mode="insertConnector" />
      </xsl:copy>
    </xsl:template>

    <!-- Add the new connector after the last existing Connnector if there's one -->
    <xsl:template match="Connector[last()]" mode="insertConnector">
      <xsl:call-template name="Copy" />

      <xsl:call-template name="AddConnector" />
    </xsl:template>

    <!-- ... or before the first Engine if there's no existing Connector -->
    <xsl:template match="Engine[1][not(preceding-sibling::Connector)]"
                  mode="insertConnector">
      <xsl:call-template name="AddConnector" />

      <xsl:call-template name="Copy" />
    </xsl:template>

    <xsl:template name="AddConnector">
      <!-- Add new line -->
      <xsl:text>&#xa;</xsl:text>
      <!-- This is the new connector -->
      <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" 
                 maxThreads="150" scheme="https" secure="true" 
                 keystoreFile="${{user.home}}/.keystore" keystorePass="changeit"
                 clientAuth="false" sslProtocol="TLS" />
    </xsl:template>

    </xsl:stylesheet>
Funkcja przekształcania XSL

Program PowerShell ma wbudowane narzędzia do przekształcania plików XML przy użyciu przekształceń XSL. Poniższy skrypt to przykładowa funkcja, której można użyć do startup.ps1 wykonania przekształcenia:

    function TransformXML{
        param ($xml, $xsl, $output)

        if (-not $xml -or -not $xsl -or -not $output)
        {
            return 0
        }

        Try
        {
            $xslt_settings = New-Object System.Xml.Xsl.XsltSettings;
            $XmlUrlResolver = New-Object System.Xml.XmlUrlResolver;
            $xslt_settings.EnableScript = 1;

            $xslt = New-Object System.Xml.Xsl.XslCompiledTransform;
            $xslt.Load($xsl,$xslt_settings,$XmlUrlResolver);
            $xslt.Transform($xml, $output);

        }

        Catch
        {
            $ErrorMessage = $_.Exception.Message
            $FailedItem = $_.Exception.ItemName
            Write-Host  'Error'$ErrorMessage':'$FailedItem':' $_.Exception;
            return 0
        }
        return 1
    }
Ustawienia aplikacji

Platforma musi również wiedzieć, gdzie zainstalowano niestandardową wersję serwera Tomcat. Lokalizację instalacji można ustawić w ustawieniu CATALINA_BASE aplikacji.

Aby zmienić to ustawienie, możesz użyć interfejsu wiersza polecenia platformy Azure:

    az webapp config appsettings set -g $MyResourceGroup -n $MyUniqueApp --settings CATALINA_BASE="%LOCAL_EXPANDED%\tomcat"

Możesz też ręcznie zmienić ustawienie w witrynie Azure Portal:

  1. Przejdź do pozycji Ustawienia> Ustawienia> aplikacji konfiguracji.
  2. Wybierz pozycję Nowe ustawienie aplikacji.
  3. Użyj tych wartości, aby utworzyć ustawienie:
    1. Nazwa: CATALINA_BASE
    2. Wartość: "%LOCAL_EXPANDED%\tomcat"
Przykład startup.ps1

Poniższy przykładowy skrypt kopiuje niestandardowy serwer Tomcat do folderu lokalnego, wykonuje przekształcenie XSL i wskazuje, że przekształcenie zakończyło się pomyślnie:

    # Locations of xml and xsl files
    $target_xml="$Env:LOCAL_EXPANDED\tomcat\conf\server.xml"
    $target_xsl="$Env:HOME\site\server.xsl"

    # Define the transform function
    # Useful if transforming multiple files
    function TransformXML{
        param ($xml, $xsl, $output)

        if (-not $xml -or -not $xsl -or -not $output)
        {
            return 0
        }

        Try
        {
            $xslt_settings = New-Object System.Xml.Xsl.XsltSettings;
            $XmlUrlResolver = New-Object System.Xml.XmlUrlResolver;
            $xslt_settings.EnableScript = 1;

            $xslt = New-Object System.Xml.Xsl.XslCompiledTransform;
            $xslt.Load($xsl,$xslt_settings,$XmlUrlResolver);
            $xslt.Transform($xml, $output);
        }

        Catch
        {
            $ErrorMessage = $_.Exception.Message
            $FailedItem = $_.Exception.ItemName
            echo  'Error'$ErrorMessage':'$FailedItem':' $_.Exception;
            return 0
        }
        return 1
    }

    $success = TransformXML -xml $target_xml -xsl $target_xsl -output $target_xml

    # Check for marker file indicating that config has already been done
    if(Test-Path "$Env:LOCAL_EXPANDED\tomcat\config_done_marker"){
        return 0
    }

    # Delete previous Tomcat directory if it exists
    # In case previous config isn't completed or a new config should be forcefully installed
    if(Test-Path "$Env:LOCAL_EXPANDED\tomcat"){
        Remove-Item "$Env:LOCAL_EXPANDED\tomcat" --recurse
    }

    md -Path "$Env:LOCAL_EXPANDED\tomcat"

    # Copy Tomcat to local
    # Using the environment variable $AZURE_TOMCAT90_HOME uses the 'default' version of Tomcat
    Copy-Item -Path "$Env:AZURE_TOMCAT90_HOME\*" "$Env:LOCAL_EXPANDED\tomcat" -Recurse

    # Perform the required customization of Tomcat
    $success = TransformXML -xml $target_xml -xsl $target_xsl -output $target_xml

    # Mark that the operation was a success if successful
    if($success){
        New-Item -Path "$Env:LOCAL_EXPANDED\tomcat\config_done_marker" -ItemType File
    }

Finalizowanie konfiguracji

Na koniec umieść sterowniki JAR w ścieżce klasy Tomcat i uruchom ponownie usługę App Service. Upewnij się, że pliki sterowników JDBC są dostępne dla klasyloader tomcat, umieszczając je w katalogu /home/site/lib . W usłudze Cloud Shell uruchom polecenie az webapp deploy --type=lib dla każdego sterownika JAR:

az webapp deploy --resource-group <group-name> --name <app-name> --src-path <jar-name>.jar --type=lib --target-path <jar-name>.jar

Tomcat

Te instrukcje dotyczą wszystkich połączeń bazy danych. Należy wypełnić symbole zastępcze nazwą klasy sterownika wybranej bazy danych i plikiem JAR. Podano tabelę zawierającą nazwy klas i pliki do pobrania sterowników dla typowych baz danych.

baza danych Nazwa klasy sterownika Sterownikiem JDBC
PostgreSQL org.postgresql.Driver Pobierz
MySQL com.mysql.jdbc.Driver Pobierz (wybierz pozycję "Niezależna od platformy")
SQL Server com.microsoft.sqlserver.jdbc.SQLServerDriver Pobierz

Aby skonfigurować serwer Tomcat do używania interfejsu Java Database Połączenie ivity (JDBC) lub interfejsu API trwałości języka Java (JPA), najpierw dostosuj CATALINA_OPTS zmienną środowiskową odczytaną przez serwer Tomcat podczas uruchamiania. Ustaw te wartości za pomocą ustawienia aplikacji w wtyczki App Service Maven:

<appSettings>
    <property>
        <name>CATALINA_OPTS</name>
        <value>"$CATALINA_OPTS -Ddbuser=${DBUSER} -Ddbpassword=${DBPASSWORD} -DconnURL=${CONNURL}"</value>
    </property>
</appSettings>

Możesz też ustawić zmienne środowiskowe na stronie Ustawienia aplikacji konfiguracji>w witrynie Azure Portal.

Następnie ustal, czy źródło danych powinno być dostępne dla jednej aplikacji, czy dla wszystkich aplikacji uruchomionych w serwletze Tomcat.

Źródła danych na poziomie aplikacji

  1. Utwórz plik context.xml w katalogu META-INF/ projektu. Utwórz katalog META-INF/, jeśli nie istnieje.

  2. W context.xml dodaj Context element, aby połączyć źródło danych z adresem JNDI. Zastąp driverClassName symbol zastępczy nazwą klasy sterownika z powyższej tabeli.

    <Context>
        <Resource
            name="jdbc/dbconnection"
            type="javax.sql.DataSource"
            url="${connURL}"
            driverClassName="<insert your driver class name>"
            username="${dbuser}"
            password="${dbpassword}"
        />
    </Context>
    
  3. Zaktualizuj web.xml aplikacji, aby użyć źródła danych w aplikacji.

    <resource-env-ref>
        <resource-env-ref-name>jdbc/dbconnection</resource-env-ref-name>
        <resource-env-ref-type>javax.sql.DataSource</resource-env-ref-type>
    </resource-env-ref>
    

Udostępnione zasoby na poziomie serwera

Dodanie udostępnionego źródła danych na poziomie serwera wymaga edytowania server.xml serwera. Najpierw przekaż skrypt uruchamiania i ustaw ścieżkę do skryptu w poleceniu uruchamiania konfiguracji>. Skrypt uruchamiania można przekazać przy użyciu protokołu FTP.

Skrypt uruchamiania spowoduje przekształcenie xsl w pliku server.xml i wyprowadzi wynikowy plik XML do /usr/local/tomcat/conf/server.xml. Skrypt uruchamiania powinien zainstalować plik libxslt za pośrednictwem pliku apk. Plik xsl i skrypt uruchamiania można przekazać za pośrednictwem protokołu FTP. Poniżej znajduje się przykładowy skrypt uruchamiania.

# Install libxslt. Also copy the transform file to /home/tomcat/conf/
apk add --update libxslt

# Usage: xsltproc --output output.xml style.xsl input.xml
xsltproc --output /home/tomcat/conf/server.xml /home/tomcat/conf/transform.xsl /usr/local/tomcat/conf/server.xml

Poniższy przykładowy plik XSL dodaje nowy węzeł łącznika do server.xml Tomcat.

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="xml" indent="yes"/>

  <xsl:template match="@* | node()" name="Copy">
    <xsl:copy>
      <xsl:apply-templates select="@* | node()"/>
    </xsl:copy>
  </xsl:template>

  <xsl:template match="@* | node()" mode="insertConnector">
    <xsl:call-template name="Copy" />
  </xsl:template>

  <xsl:template match="comment()[not(../Connector[@scheme = 'https']) and
                                 contains(., '&lt;Connector') and
                                 (contains(., 'scheme=&quot;https&quot;') or
                                  contains(., &quot;scheme='https'&quot;))]">
    <xsl:value-of select="." disable-output-escaping="yes" />
  </xsl:template>

  <xsl:template match="Service[not(Connector[@scheme = 'https'] or
                                   comment()[contains(., '&lt;Connector') and
                                             (contains(., 'scheme=&quot;https&quot;') or
                                              contains(., &quot;scheme='https'&quot;))]
                                  )]
                      ">
    <xsl:copy>
      <xsl:apply-templates select="@* | node()" mode="insertConnector" />
    </xsl:copy>
  </xsl:template>

  <!-- Add the new connector after the last existing Connnector if there's one -->
  <xsl:template match="Connector[last()]" mode="insertConnector">
    <xsl:call-template name="Copy" />

    <xsl:call-template name="AddConnector" />
  </xsl:template>

  <!-- ... or before the first Engine if there's no existing Connector -->
  <xsl:template match="Engine[1][not(preceding-sibling::Connector)]"
                mode="insertConnector">
    <xsl:call-template name="AddConnector" />

    <xsl:call-template name="Copy" />
  </xsl:template>

  <xsl:template name="AddConnector">
    <!-- Add new line -->
    <xsl:text>&#xa;</xsl:text>
    <!-- This is the new connector -->
    <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" 
               maxThreads="150" scheme="https" secure="true" 
               keystoreFile="${{user.home}}/.keystore" keystorePass="changeit"
               clientAuth="false" sslProtocol="TLS" />
  </xsl:template>

</xsl:stylesheet>

Finalizowanie konfiguracji

Na koniec umieść sterowniki JAR w ścieżce klasy Tomcat i uruchom ponownie usługę App Service.

  1. Upewnij się, że pliki sterowników JDBC są dostępne dla klasyloader tomcat, umieszczając je w katalogu /home/site/lib . W usłudze Cloud Shell uruchom polecenie az webapp deploy --type=lib dla każdego sterownika JAR:
az webapp deploy --resource-group <group-name> --name <app-name> --src-path <jar-name>.jar --type=lib --path <jar-name>.jar

Jeśli utworzono źródło danych na poziomie serwera, uruchom ponownie aplikację usługi App Service dla systemu Linux. Serwer Tomcat zostanie zresetowany CATALINA_BASE do /home/tomcat zaktualizowanej konfiguracji i użyje zaktualizowanej konfiguracji.

Źródła danych JBoss EAP

Istnieją trzy podstawowe kroki podczas rejestrowania źródła danych za pomocą protokołu JBoss EAP: przekazywanie sterownika JDBC, dodawanie sterownika JDBC jako modułu i rejestrowanie modułu. Usługa App Service to bezstanowa usługa hostingu, więc polecenia konfiguracji do dodawania i rejestrowania modułu źródła danych muszą być skryptowe i stosowane podczas uruchamiania kontenera.

  1. Uzyskaj sterownik JDBC bazy danych.

  2. Utwórz plik definicji modułu XML dla sterownika JDBC. W poniższym przykładzie przedstawiono definicję modułu dla bazy danych PostgreSQL.

    <?xml version="1.0" ?>
    <module xmlns="urn:jboss:module:1.1" name="org.postgres">
        <resources>
        <!-- ***** IMPORTANT : REPLACE THIS PLACEHOLDER *******-->
        <resource-root path="/home/site/deployments/tools/postgresql-42.2.12.jar" />
        </resources>
        <dependencies>
            <module name="javax.api"/>
            <module name="javax.transaction.api"/>
        </dependencies>
    </module>
    
  3. Umieść polecenia interfejsu wiersza polecenia JBoss w pliku o nazwie jboss-cli-commands.cli. Polecenia JBoss muszą dodać moduł i zarejestrować go jako źródło danych. W poniższym przykładzie przedstawiono polecenia interfejsu wiersza polecenia narzędzia JBoss dla bazy danych PostgreSQL.

    #!/usr/bin/env bash
    module add --name=org.postgres --resources=/home/site/deployments/tools/postgresql-42.2.12.jar --module-xml=/home/site/deployments/tools/postgres-module.xml
    
    /subsystem=datasources/jdbc-driver=postgres:add(driver-name="postgres",driver-module-name="org.postgres",driver-class-name=org.postgresql.Driver,driver-xa-datasource-class-name=org.postgresql.xa.PGXADataSource)
    
    data-source add --name=postgresDS --driver-name=postgres --jndi-name=java:jboss/datasources/postgresDS --connection-url=${POSTGRES_CONNECTION_URL,env.POSTGRES_CONNECTION_URL:jdbc:postgresql://db:5432/postgres} --user-name=${POSTGRES_SERVER_ADMIN_FULL_NAME,env.POSTGRES_SERVER_ADMIN_FULL_NAME:postgres} --password=${POSTGRES_SERVER_ADMIN_PASSWORD,env.POSTGRES_SERVER_ADMIN_PASSWORD:example} --use-ccm=true --max-pool-size=5 --blocking-timeout-wait-millis=5000 --enabled=true --driver-class=org.postgresql.Driver --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter --jta=true --use-java-context=true --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker
    
  4. Utwórz skrypt uruchamiania, startup_script.sh który wywołuje polecenia interfejsu wiersza polecenia JBoss. W poniższym przykładzie pokazano, jak wywołać element jboss-cli-commands.cli. Później skonfigurujesz usługę App Service tak, aby uruchamiała ten skrypt po uruchomieniu kontenera.

    $JBOSS_HOME/bin/jboss-cli.sh --connect --file=/home/site/deployments/tools/jboss-cli-commands.cli
    
  5. Korzystając z wybranego klienta FTP, przekaż sterownik JDBC, jboss-cli-commands.cli, startup_script.shi definicję modułu do ./site/deployments/tools/

  6. Skonfiguruj witrynę do uruchamiania startup_script.sh po uruchomieniu kontenera. W witrynie Azure Portal przejdź do pozycji Konfiguracja>Ogólna Ustawienia> Startup Polecenie. Ustaw pole polecenia uruchamiania na /home/site/deployments/tools/startup_script.sh. Zapisz swoje zmiany.

Aby potwierdzić, że źródło danych zostało dodane do serwera JBoss, protokół SSH do aplikacji internetowej i uruchom polecenie $JBOSS_HOME/bin/jboss-cli.sh --connect. Po nawiązaniu połączenia z narzędziem JBoss uruchom polecenie /subsystem=datasources:read-resource , aby wyświetlić listę źródeł danych.

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.

JBoss EAP

Klastrowanie w usłudze JBoss EAP

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. Wystąpienia protokołu JBoss EAP komunikują się za pośrednictwem podsieci określonej w integracji sieci wirtualnej przy użyciu portów wyświetlanych w zmiennej środowiskowej WEBSITES_PRIVATE_PORTS w czasie wykonywania. 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.

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

Protokół JBoss EAP jest dostępny tylko w typach Premium v3 i Izolowanych w wersji 2 usługi App Service. Klienci, którzy utworzyli witrynę JBoss EAP w innej warstwie w publicznej wersji zapoznawczej, powinni skalować w górę do warstwy Premium lub Izolowanej sprzętu, aby uniknąć nieoczekiwanego zachowania.

Konfiguracja linii bazowej serwera Tomcat w usługach App Services

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ń Połączenie or, hosta i zaworu.

Należy pamiętać, że 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
  • conectionTimeout 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 max Połączenie ions 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 conectionTimeout, maxThreads lub max Połączenie ions:

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
  • Połączenie or 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 0 [na zawsze]

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.