Azure App Service 内に Tomcat、JBoss、または Java SE アプリをデプロイして構成する

この記事では、App Service 内の Java アプリの最も一般的なデプロイとランタイム構成について説明します。 Azure App Service を使用したことがない場合は、まず Java クイック スタートをお読みください。 Java 開発に限られない、App Service の使用に関する一般的な質問については、App Service の FAQ に関する記事で回答されています。

Azure App Service は、以下の 3 つのバリエーションのフル マネージド サービス上で Java Web アプリケーションを実行します。

• Java SE - 埋め込みサーバー (Spring Boot、Dropwizard、Quarkus、埋め込み Tomcat または Jetty サーバーを含むものなど) を含む JAR パッケージとしてデプロイされたアプリを実行できます。
• Tomcat - 組み込みの Tomcat サーバーは、WAR パッケージとしてデプロイされたアプリを実行できます。
• JBoss EAP - Free、Premium v3、Isolated v2 価格レベルの Linux アプリでのみサポートされます。 組み込みの JBoss EAP サーバーは、WAR または EAR パッケージとしてデプロイされたアプリを実行できます。

Note

Spring アプリケーションの場合は、Azure Spring Apps を使用することをお勧めします。 ただし、Azure App Service は引き続き宛先として使用できます。 アドバイスについてはJava ワークロード宛先ガイダンスに関する記事を参照してください。

Java バージョンを表示する

Linux

現在の Java バージョンを表示するには、Cloud Shell で次のコマンドを実行します。

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

サポートされているすべての Java バージョンを表示するには、Cloud Shell で次のコマンドを実行します。

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

Windows

現在の Java バージョンを表示するには、Cloud Shell で次のコマンドを実行します。

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

サポートされているすべての Java バージョンを表示するには、Cloud Shell で次のコマンドを実行します。

az webapp list-runtimes --os windows | grep java

バージョン サポートの詳細については、App Service 言語ランタイム サポート ポリシーに関する記事を参照してください。

アプリのデプロイ

ビルド ツール

Maven

Azure Web アプリ用の Maven プラグインを使用すると、プロジェクト ルートで 1 つのコマンドを使用して、Azure Web アプリ用の Maven Java プロジェクトを簡単に準備できます。

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

このコマンドによって、既存の Azure Web アプリを選択するか、新しいアプリを作成するかを選択するメッセージが表示され、azure-webapp-maven-plugin プラグインと関連する構成が追加されます。 構成時に、これはアプリケーションを Java SE、Tomcat、JBoss EAP (Linux のみ) の内のどれにデプロイするべきかの検出を試みます。 次のコマンドを使用して、Java アプリを Azure にデプロイできます。

mvn package azure-webapp:deploy

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. Azure Web アプリ用の Gradle プラグインを build.gradle に追加することで、このプラグインをセットアップします。

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

2. Web アプリの詳細を構成します。 対応する Azure リソースが、存在しない場合、作成されます。 構成例を次に示します。詳細については、このドキュメントを参照してください。

   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. 1 つのコマンドでデプロイします。

   gradle azureWebAppDeploy
   

IDE

Azure では、次のような一般的な Java IDE でシームレスな Java App Service 開発エクスペリエンスを提供しています。

• VS コード: Visual Studio Code を使用した Java Web アプリ
• IntelliJ IDEA: IntelliJ を使用して Azure App Service 用の Hello World Web アプリを作成します
• Eclipse:Eclipse を使用して Azure App Service 用の Hello World Web アプリを作成します

Kudu API

Java SE に .jar ファイルをデプロイするには、Kudu サイトの /api/publish エンドポイントを使用します。 この API の詳細については、このドキュメントを参照してください。

Note

App Service でアプリケーションを識別して実行するには、.jar アプリケーションの名前を app.jar にする必要があります。 Maven プラグインが、デプロイ時にこれを自動的に行います。 JAR の名前を app.jar に変更したくない場合は、.jar アプリを実行するコマンドが含まれるシェル スクリプトをアップロードできます。 ポータルの構成セクションで [スタートアップ ファイル] テキスト ボックスにこのスクリプトの絶対パスを貼り付けます。 スタートアップ スクリプトは、配置先のディレクトリからは実行されません。 そのため、スタートアップ スクリプトでファイルを参照するには、常に絶対パスを使用します (例: java -jar /home/myapp/myapp.jar)。

.war ファイルを Tomcat にデプロイするには、/api/wardeploy/ エンドポイントを使用してアーカイブ ファイルを POST します。 この API の詳細については、このドキュメントを参照してください。

.war ファイルを JBoss にデプロイするには、/api/wardeploy/ エンドポイントを使用してアーカイブ ファイルを POST します。 この API の詳細については、このドキュメントを参照してください。

.ear ファイルをデプロイするには、FTP を使用します。 アプリケーションの構成で定義されているコンテキスト ルートに、.ear アプリケーションがデプロイされます。 たとえば、アプリのコンテキスト ルートが <context-root>myapp</context-root> の場合は、/myapp パスでサイトを閲覧できます (http://my-app-name.azurewebsites.net/myapp)。 Web アプリがルート パスで提供されるようにするには、アプリでコンテキスト ルートがルート パスに設定されていることを確認します (<context-root>/</context-root>)。 詳細については、「Setting the context root of a web application (Web アプリケーションのコンテキスト ルートの設定)」を参照してください。

FTP を使用して .war や .jar をデプロイしないでください。 FTP ツールは、スタートアップ スクリプト、依存関係、またはその他のランタイム ファイルをアップロードするために設計されています。 これは、Web アプリをデプロイするための最適な選択肢ではありません。

URL の書き換えまたはリダイレクト

URL を書き換える、またはリダイレクトするには、使用可能な URL リライターの 1 つ (UrlRewriteFilter など) を使用します。

Tomcat には、リライト バルブも用意されています。

JBoss には、リライト バルブも用意されています。

アプリのログ記録とデバッグ

パフォーマンス レポート、トラフィックの視覚エフェクト、および正常性検査は、Azure portal を介して各アプリに対して使用できます。 詳細については、「Azure App Service 診断の概要」を参照してください。

診断ログをストリーミングする

Linux

コンテナー内から生成されたコンソール ログにアクセスできます。

まず、次のコマンドを実行して、コンテナーのログ記録をオンにします。

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

<app-name> と <resource-group-name> は、Web アプリに適した名前に置き換えます。

コンテナーのログ記録がオンになったら、次のコマンドを実行して、ログのストリームを確認します。

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

コンソール ログがすぐに表示されない場合は、30 秒以内にもう一度確認します。

任意のタイミングでログのストリーミングを停止するには、Ctrl+C キーを押します。

ブラウザーから https://<app-name>.scm.azurewebsites.net/api/logs/docker でログ ファイルを検査することもできます。

Windows

App Service のアプリケーション コード内から生成されたコンソール ログにアクセスするには、Cloud Shell で次のコマンドを実行して、診断ログを有効にします。

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

--level で有効な値は、Error、Warning、Info、および Verbose です。 後続の各レベルには、前のレベルが含まれます。 たとえば、Error にはエラー メッセージのみが含まれ、Verbose にはすべてのメッセージが含まれます。

診断ログがオンになったら、次のコマンドを実行して、ログのストリームを確認します。

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

コンソール ログがすぐに表示されない場合は、30 秒以内にもう一度確認します。

Note

https://<app-name>.scm.azurewebsites.net/api/logs/docker で、ブラウザーからログ ファイルを検査することもできます。

任意のタイミングでログのストリーミングを停止するには、Ctrl+C と入力します。

詳細については、Cloud Shell でのログのストリーミングに関する記事をご覧ください。

Linux での SSH コンソール アクセス

コンテナーとの直接 SSH セッションを開くには、アプリが実行されている必要があります。

ブラウザーに次の URL を貼り付け、<app-name> をお使いのアプリの名前に置き換えます。

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

まだ認証されていない場合、接続するには Azure サブスクリプションで認証する必要があります。 認証されると、ブラウザー内シェルが表示され、コンテナー内でコマンドを実行することができます。

Note

/home ディレクトリの外部で行ったすべての変更は、コンテナー自体に格納され、アプリの再起動後には保持されません。

ローカル コンピューターからリモート SSH セッションを開くには、「リモート シェルから SSH セッションを開く」を参照してください。

Linux のトラブルシューティング ツール

組み込みの Java イメージは Alpine Linux オペレーティング システムに基づいています。 apk パッケージ マネージャーを使用し、トラブルシューティングのツールやコマンドをインストールします。

Java Profiler

Azure App Service 上のすべての Java ランタイムには、Java ワークロードをプロファイリングするための JDK Flight Recorder が付属しています。 これを使用すると、JVM、システム、アプリケーションのイベントを記録し、アプリケーションでの問題のトラブルシューティングを行うことができます。

Java Profiler の詳細については、Azure Application Insights のドキュメントを参照してください。

Flight Recorder

App Service 上のすべての Java ランタイムには、Java Flight Recorder が付属しています。 これを使用すると、JVM、システム、アプリケーションのイベントを記録し、Java アプリケーションでの問題のトラブルシューティングを行うことができます。

Linux

対象の App Service に SSH で接続し、jcmd コマンドを実行して、実行されているすべての Java プロセスの一覧を表示します。 jcmd 自体に加えて、実行されているご自分の Java アプリケーションとプロセス ID 番号 (pid) が表示されます。

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

JVM の 30 秒間の記録を開始するには、次のコマンドを実行します。 これにより、JVM がプロファイリングされて、jfr_example.jfr という名前の JFR ファイルがホーム ディレクトリに作成されます。 (116 は、ご自分の Java アプリの pid に置き換えてください。)

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

30 秒の期間中には、jcmd 116 JFR.check を実行することで、記録が取得されていることを確認できます。 コマンドにより、特定の Java プロセスに対するすべての記録が表示されます。

継続的な記録

Java Flight Recorder を使うと、ランタイムのパフォーマンスに対する影響を最小限にして、Java アプリケーションを継続的にプロファイリングできます。 そのためには、次の Azure CLI コマンドを実行し、必要な構成で JAVA_OPTS という名前のアプリ設定を作成します。 JAVA_OPTS アプリ設定の内容は、アプリの起動時に java コマンドに渡されます。

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

記録が開始されたら、JFR.dump コマンドを使用して、いつでも現在の記録データをダンプできます。

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

Windows

時間指定の記録

時間を指定して記録を行うには、Java アプリケーションの PID (プロセス ID) が必要です。 PID を検索するには、ブラウザーで Web アプリの SCM サイト (https://<your-site-name>.scm.azurewebsites.net/ProcessExplorer/) を開きます。 このページには、Web アプリで実行中のプロセスが表示されます。 テーブル内で "java" という名前のプロセスを探し、対応する PID (プロセス ID) をコピーします。

次に、SCM サイト上部のツール バーにある デバッグ コンソール を開き、次のコマンドを実行します。 <pid> を、先ほどコピーしたプロセス ID に置き換えます。 このコマンドにより、Java アプリケーションの 30 秒のプロファイラー記録が開始され、C:\home ディレクトリ内に timed_recording_example.jfr という名前のファイルが生成されます。

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

.jfr ファイルの分析

JFR ファイルをご自分のローカル コンピューターにダウンロードするには、FTPS を使います。 JFR ファイルを分析するには、Java Mission Control をダウンロードしてインストールします。 Java Mission Control については、JMC のドキュメントとインストール手順に関するページをご覧ください。

アプリのログ記録

Linux

Azure portal または Azure CLI を使用してアプリケーションのログ記録を有効にし、アプリケーションの標準コンソール出力および標準コンソール エラー ストリームをローカル ファイル システムまたは Azure BLOB ストレージに書き込むよう App Service を構成します。 リテンション期間を長くする必要がある場合は、BLOB ストレージ コンテナーに出力を書き込むようアプリケーションを構成します。

Java と Tomcat のアプリ ログは /home/LogFiles/Application/ ディレクトリにあります。

Linux ベースのアプリの Azure Blob Storage のログ記録を構成するには、Azure Monitor を使う必要があります。

Windows

Azure portal または Azure CLI を使用してアプリケーションのログ記録を有効にし、アプリケーションの標準コンソール出力および標準コンソール エラー ストリームをローカル ファイル システムまたは Azure BLOB ストレージに書き込むよう App Service を構成します。 ローカルの App Service ファイルシステム インスタンスへのログは、有効化の 12 時間後に無効になります。 リテンション期間を長くする必要がある場合は、BLOB ストレージ コンテナーに出力を書き込むようアプリケーションを構成します。

Java と Tomcat のアプリ ログは /home/LogFiles/Application/ ディレクトリにあります。

アプリケーションで Logback または Log4j をトレースに使用している場合は、「Application Insights を使用した Java トレース ログの探索」にあるログ記録フレームワークの構成手順に従って、これらのトレースを確認のために Azure Application Insights に転送することができます。

Note

既知の脆弱性 CVE-2021-44228 への対応のために、必ず Log4j バージョン 2.16 以降を使用してください。

カスタマイズとチューニング

Azure App Service では、Azure portal および CLI を使用したチューニングとカスタマイズが追加設定なしでサポートされています。 Java 以外の特定の Web アプリの構成については、次の記事を確認してください。

• アプリケーションの設定を構成する
• カスタム ドメインの設定
• TLS/SSL バインドを構成する
• CDN の追加
• Kudu サイトを構成する

アプリ コンテンツをローカルにコピーする

アプリの設定 JAVA_COPY_ALL を true に設定して、共有ファイル システムからローカル worker にアプリ コンテンツをコピーします。 この設定は、ファイル ロックの問題に対処するのに役立ちます。

Java ランタイム オプションを設定する

割り当てられたメモリまたはその他の JVM ランタイムのオプションを設定するには、アプリ設定を作成して JAVA_OPTS と名付け、オプションを指定します。 App Service では、開始時にこの設定が環境変数として Java ランタイムに渡されます。

Azure portal において、Web アプリの [アプリケーション設定] で、-Xms512m -Xmx1204m などのその他の設定を含む JAVA_OPTS という名前の新しいアプリ設定を作成します。

Azure portal において、Web アプリの [アプリケーション設定] で、-Xms512m -Xmx1204m などのその他の設定を含む CATALINA_OPTS という名前の新しいアプリ設定を作成します。

Maven プラグインからアプリ設定を構成するには、Azure プラグイン セクションで設定/値のタグを追加します。 次の例では、特定の最小および最大の Java ヒープ サイズを設定します。

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

Note

Windows App Service で Tomcat を使う場合は、Web.config ファイルを作成する必要はありません。

App Service プランで 1 つのデプロイ スロットを使用して 1 つのアプリケーションを実行している開発者は、次のオプションを使用できます。

• B1 および S1 インスタンス: -Xms1024m -Xmx1024m
• B2 および S2 インスタンス: -Xms3072m -Xmx3072m
• B3 および S3 インスタンス: -Xms6144m -Xmx6144m
• P1v2 インスタンス: -Xms3072m -Xmx3072m
• P2v2 インスタンス: -Xms6144m -Xmx6144m
• P3v2 インスタンス: -Xms12800m -Xmx12800m
• P1v3 インスタンス: -Xms6656m -Xmx6656m
• P2v3 インスタンス: -Xms14848m -Xmx14848m
• P3v3 インスタンス: -Xms30720m -Xmx30720m
• I1 インスタンス: -Xms3072m -Xmx3072m
• I2 インスタンス: -Xms6144m -Xmx6144m
• I3 インスタンス: -Xms12800m -Xmx12800m
• I1v2 インスタンス: -Xms6656m -Xmx6656m
• I2v2 インスタンス: -Xms14848m -Xmx14848m
• I3v2 インスタンス: -Xms30720m -Xmx30720m

アプリケーション ヒープ設定をチューニングする際には、App Service プランの詳細を確認し、複数のアプリケーションおよびデプロイ スロットのニーズを考慮して、メモリの最適な割り当てを特定する必要があります。

Web ソケットを有効にする

Azure portal のアプリケーション用の [アプリケーション設定] で、Web ソケットのサポートを有効にします。 設定を有効にするには、アプリケーションを再起動する必要があります。

Azure CLI を使用して、次のコマンドで Web ソケットのサポートを有効にします。

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

その後、アプリケーションを再起動します。

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

既定の文字エンコーディングを設定する

Azure portal の Web アプリ用の [アプリケーション設定] で、値 -Dfile.encoding=UTF-8 を含む、JAVA_OPTS という名前の新しいアプリ設定を作成します。

または、App Service Maven プラグインを使用してアプリ設定を構成できます。 プラグイン構成で、設定名および値のタグを追加します。

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

JSP ファイルをプリコンパイルする

Tomcat アプリケーションのパフォーマンスを向上させるには、App Service にデプロイする前に、JSP ファイルをコンパイルします。 Apache Sling によって提供されている Maven プラグインを使用するか、この Ant ビルド ファイルを使用できます。

ログの robots933456

コンテナー ログで次のメッセージが表示されることがあります。

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

このメッセージは無視してかまいません。 /robots933456.txt は、コンテナーが要求を処理できるかどうかを調べるために App Service が使用するダミーの URL パスです。 404 応答は、パスが存在しないことを示すだけですが、コンテナーが正常であり、要求に応答できる状態であることを App Service に知らせます。

Java ランタイム バージョンの選択

App Service を使うと、ユーザーは JVM のメジャー バージョン (Java 8 や Java 11 など)、パッチ バージョン (1.8.0_232 や 11.0.5 など) を選択できます。 新しいマイナー バージョンが利用可能になったらパッチ バージョンを自動的に更新するように選択することもできます。 ほとんどの場合、運用アプリにおいては、固定されたパッチ JVM バージョンを使用する必要があります。 これにより、パッチ バージョンの自動更新の間に、予期しない停止が発生するのを防ぐことができます。 すべての Java Web アプリは、64 ビットの JVM を使用します。これは構成できません。

Tomcat を使用している場合は、Tomcat のパッチ バージョンを固定することができます。 Windows では、JVM のパッチ バージョンと Tomcat のパッチ バージョンを個別に固定できます。 Linux では、Tomcat のパッチ バージョンを固定できます。JVM のパッチ バージョンも固定されますが、個別に構成することはできません。

マイナー バージョンの固定を選択した場合は、アプリの JVM のマイナー バージョンを定期的に更新する必要があります。 アプリケーションが新しいマイナー バージョンで確実に実行されるようにするには、ステージング スロットを作成し、ステージング スロットでマイナー バージョンをインクリメントします。 新しいマイナー バージョンでアプリケーションが正しく実行されることを確認したら、ステージング スロットと運用スロットを入れ替えることができます。

JBoss CLI を実行する

JBoss アプリの SSH セッションで、次のコマンドを使用して JBoss CLI を実行できます。

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

JBoss がサーバーのライフサイクル内のどこにあるかによっては、接続できない場合があります。 しばらく待ってから再試行してください。 このアプローチは、現在のサーバーの状態をすばやく確認する場合に便利です (データ ソースが適切に構成されているかどうかを確認する場合など)。

また、SSH セッションで JBoss CLI を使用してサーバーに加えた変更は、アプリの再起動後は保持されません。 アプリが起動するたびに、JBoss EAP サーバーはクリーン インストールで始まります。 スタートアップ ライフサイクル中、App Service によって必要なサーバー構成が作成され、アプリがデプロイされます。 JBoss サーバーで永続的な変更を行うには、カスタム スタートアップ スクリプトまたはスタートアップ コマンドを使用します。 エンド ツー エンドの例については、「Azure App Service で Tomcat、JBoss、または Java SE アプリのデータ ソースを構成する」を参照してください。

また、スタートアップ時に任意のファイルを実行するように App Service を手動で構成することもできます。 次に例を示します。

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

実行できる CLI コマンドの詳細については、以下を参照してください。

• Red Hat JBoss EAP のドキュメント
• WildFly CLI のレシピ

クラスタリング

App Service では、JBoss EAP バージョン 7.4.1 以上でのクラスタリングがサポートされています。 クラスタリングを有効にするには、Web アプリが仮想ネットワークに統合されている必要があります。 Web アプリは、仮想ネットワークに統合されている場合、再起動し、JBoss EAP インストールがクラスター化構成で自動的に起動します。 自動スケールを使用して複数のインスタンスを実行する場合、JBoss EAP インスタンスは、仮想ネットワーク統合で指定されたサブネットを介して相互に通信します。 任意の値を持つ WEBSITE_DISABLE_CLUSTERING という名前のアプリ設定を作成することによって、クラスタリングを無効にすることができます。

Note

ARM テンプレートを使用して仮想ネットワーク統合を有効にする場合は、プロパティ vnetPrivatePorts を 2 の値に手動で設定する必要があります。 CLI またはポータルから仮想ネットワーク統合を有効にする場合は、このプロパティが自動的に設定されます。

クラスタリングが有効になっていると、JBoss EAP インスタンスは FILE_PING JGroups 検出プロトコルを使用して新しいインスタンスを検出し、クラスター メンバーとその識別子や IP アドレスなどのクラスター情報を保持します。 App Service では、これらのファイルは /home/clusterinfo/ の下にあります。 起動する最初の EAP インスタンスは、クラスター メンバーシップ ファイルに対する読み取り/書き込みアクセス許可を取得します。 その他のインスタンスは、このファイルを読み取ってプライマリ ノードを見つけた後、クラスターに含まれ、このファイルに追加されるようにそのノードと調整します。

Note

JBoss クラスタリング タイムアウトを回避するには、アプリの起動中に古い検出ファイルをクリーンアップします。

Premium V3 と Isolated V2 の App Service プランの種類は、必要に応じて Availability Zones 全体に分散させて、Bus Critical ワークロードの回復性と信頼性を向上させることができます。 このアーキテクチャは、ゾーン冗長とも呼ばれます。 JBoss EAP クラスタリング機能は、ゾーン冗長機能と互換性があります。

自動スケール ルール

水平スケーリング用に自動スケール ルールを構成する場合は、削除された各インスタンスがそのアクティビティ (データベース トランザクションの処理など) をクラスターの別のメンバーに確実に転送できるように、インスタンスを段階的に (1 つずつ) 削除することが重要です。 スケール ダウンするようにポータルで自動スケーリング ルールを構成する場合は、次のオプションを使用します。

• [操作]: [カウントを減らす量]
• [クールダウン]: [5 分] 以上
• [インスタンス数]: 1

インスタンスを段階的に追加する (スケールアウトする) 必要はありません。一度に複数のインスタンスをクラスターに追加できます。

App Service プラン

JBoss EAP は、F1、P0v3、P1mv3、P2mv3、P3mv3、P4mv3、P5mv3 の価格レベルで利用できます。

JBoss サーバーのライフサイクル

App Service の JBoss EAP アプリは、5 つの異なるフェーズを経た後、実際にサーバーを起動します。

• 1.環境のセットアップ フェーズ
• 2.サーバー起動フェーズ
• 3.サーバーの構成フェーズ
• 4.アプリ デプロイ フェーズ
• 5.サーバーの再読み込みフェーズ

詳細およびカスタマイズの機会 (アプリ設定の使用など) については、以下の各セクションを参照してください。

1. 環境のセットアップ フェーズ

• SSH サービスが開始され、コンテナーとの安全な SSH セッションが有効になります。
• Java ランタイムのキーストアは、Azure portal で定義されているすべてのパブリック証明書とプライベート証明書で更新されます。
  • パブリック証明書は、/var/ssl/certs ディレクトリ内のプラットフォームによって提供され、$JRE_HOME/lib/security/cacerts に読み込まれます。
  • プライベート証明書は、/var/ssl/private ディレクトリ内のプラットフォームによって提供され、$JRE_HOME/lib/security/client.jks に読み込まれます。
• この手順で証明書が Java キーストアに読み込まれると、プロパティ javax.net.ssl.keyStore、javax.net.ssl.keyStorePassword、および javax.net.ssl.keyStoreType が JAVA_TOOL_OPTIONS 環境変数に追加されます。
• ログ ディレクトリや Java メモリ ヒープ パラメーターなど、初期 JVM 構成がいくつか決定されます。
  • アプリ設定 JAVA_OPTS でメモリに –Xms フラグまたは –Xmx フラグを指定すると、プラットフォームによって提供されるフラグは、これらの値によってオーバーライドされます。
  • アプリ設定を WEBSITES_CONTAINER_STOP_TIME_LIMIT を構成すると、この値はランタイム プロパティ org.wildfly.sigterm.suspend.timeout に渡され、これにより JBoss が停止しているときの最大シャットダウン待機時間 (秒単位) が制御されます。
• アプリが仮想ネットワークと統合されている場合、App Service ランタイムは、環境変数 WEBSITE_PRIVATE_PORTS のサーバー間通信に使用されるポートのリストを渡し、clustering 構成を使用して JBoss を起動します。 それ以外の場合は、standalone 構成が使用されます。
  • clustering 構成では、サーバー構成ファイル standalone-azure-full-ha.xml が使用されます。
  • standalone 構成では、サーバー構成ファイル standalone-full.xml が使用されます。

2. サーバー起動フェーズ

• clustering 構成で JBoss が起動された場合:
  • 各 JBoss インスタンスは、0 からアプリがスケールアウトされているインスタンス数までの内部識別子を受け取ります。
  • (その内部識別子を使用することで) このサーバー インスタンスのトランザクション ストア パスにファイルがいくつか見つかった場合、このサーバー インスタンスは、以前クラッシュして、トランザクションがコミットされないまま残っているサービス インスタンスの代わりになっていることを意味します。 サーバーは、これらのトランザクションの作業を再開するように構成されています。
• JBoss が clustering または standalone のどちらの構成で起動しているかに関係なく、サーバー バージョンが 7.4 以上で、ランタイムが Java 17 を使用している場合、構成は更新され、セキュリティのために Elytron サブシステムが有効になります。
• アプリ設定 WEBSITE_JBOSS_OPTS を構成すると、値は JBoss ランチャー スクリプトに渡されます。 この設定を使用すると、プロパティ ファイルへのパスや、JBoss の起動に影響するその他のフラグを指定できます。

3. サーバーの構成フェーズ

• このフェーズの開始時、App Service はまず、JBoss サーバーと管理インターフェイスの両方が要求を受信する準備が整うのを待ちます。その後、処理を続行します。 Application Insights が有効になっている場合、これには数秒かかることがあります。
• JBoss サーバーと管理インターフェイスの両方の準備ができたら、App Service は次の処理を実行します。
  • JBoss モジュール azure.appservice を追加します。このモジュールには、ログ記録と App Service との統合のためのユーティリティ クラスが用意されています。
  • 無色モードを使うようにコンソール ロガーを更新して、ログ ファイルがカラー エスケープ シーケンスでいっぱいにならないようにします。
  • Azure Monitor ログとの統合を設定します。
  • WSDL と管理インターフェイスのバインディング IP アドレスを更新します。
  • App Service 認証および Microsoft Entra ID との統合のために JBoss モジュール azure.appservice.easyauth を追加します。
  • アクセス ログのログ構成と、メイン サーバー ログ ファイルの名前とローテーションを更新します。
• アプリ設定 WEBSITE_SKIP_AUTOCONFIGURE_DATABASE が定義されていない限り、App Service により、App Service アプリ設定の JDBC URL が自動的に検出されます。 PostgreSQL、MySQL、MariaDB、Oracle、SQL Server、または Azure SQL Database に対して有効な JDBC URL が存在する場合、対応するドライバーがサーバーに追加され、JDBC URL それぞれに対してデータ ソースが追加され、データ ソースごとに JNDI 名が java:jboss/env/jdbc/<app-setting-name>_DS に設定されます。ここで <app-setting-name> はアプリ設定の名前です。
• clustering 構成が有効になっている場合は、構成するコンソール ロガーがオンになっています。
• /home/site/libs ディレクトリにデプロイされた JAR ファイルがある場合は、そのすべての JAR ファイルを使用して新しいグローバル モジュールが作成されます。
• フェーズの終了時、App Service によってカスタム スタートアップ スクリプトが実行されます (そのスクリプトが存在する場合)。 カスタム スタートアップ スクリプトの検索ロジックを次に示します。
  • (Azure portal や Azure CLI などを使用して) スタートアップ コマンドを構成した場合は、それを実行します。そうでない場合、
  • /home/site/scripts/startup.sh パスが存在する場合は、それを使用します。そうでない場合、
  • /home/startup.sh パスが存在する場合は、それを使用します。

カスタム スタートアップ コマンドまたはスクリプトはルート ユーザーとして実行されるため (sudo には不要)、Linux パッケージをインストールするか、JBoss CLI を起動して他の JBoss インストール/カスタマイズ コマンド (データソースの作成、リソース アダプターのインストールなど) を実行できます。Ubuntu パッケージ管理コマンドの詳細については、Ubuntu Server のドキュメントを参照してください。 JBoss CLI コマンドについては、JBoss 管理 CLI ガイドを参照してください。

4. アプリ デプロイ フェーズ

スタートアップ スクリプトは、優先順位に従って次の場所を検索し、アプリを JBoss にデプロイします。

• アプリ設定 WEBSITE_JAVA_WAR_FILE_NAME を構成した場合は、それによって指定されたファイルをデプロイします。
• /home/site/wwwroot/app.war が存在する場合は、それをデプロイします。
• 他の EAR ファイルと WAR ファイルが /home/site/wwwroot に存在する場合は、それをデプロイします。
• /home/site/wwwroot/webapps が存在する場合は、そのファイルとそのディレクトリをデプロイします。 WAR ファイルはアプリケーション自体として、ディレクトリは "展開済み" (圧縮されていない) Web アプリとしてデプロイされます。
• スタンドアロン JSP ページが /home/site/wwwroot に存在する場合は、それを Web サーバー ルートにコピーし、1 つの Web アプリとしてデプロイします。
• デプロイ可能なファイルがまだ見つからない場合は、既定のウェルカム ページ (パーキング ページ) をルート コンテキストにデプロイします。

5.サーバーの再読み込みフェーズ

• デプロイ手順が完了すると、JBoss サーバーは再読み込みされ、サーバーの再読み込みが必要な変更が適用されます。
• サーバーが再読み込みされると、JBoss EAP サーバーにデプロイされたアプリケーションは、要求に応答できるようになります。
• サーバーは、App Service アプリが停止または再起動されるまで実行されます。 App Service アプリは手動で停止または再起動できます。または、ファイルのデプロイ時または App Service アプリ構成の変更時に再起動をトリガーします。
• JBoss サーバーが clustering 構成で異常終了すると、emit_alert_tx_store_not_empty という最終的な関数が実行されます。 この関数は、JBoss プロセスにより空でないトランザクション ストア ファイルがディスクに残されたかどうかを確認し、残っている場合は、エラーがコンソールのログに記録されます: Error: finishing server with non-empty store for node XXXX。 新しいサーバー インスタンスが起動されると、その空でないトランザクション ストア ファイルが検索され、作業が再開されます (「2. サーバー起動フェーズ」を参照）。

Tomcat ベースライン構成

Note

このセクションは Linux にのみ適用されます。

Java 開発者は、Tomcat の server.xml ファイルと構成の詳細がわかっている場合は、サーバー設定のカスタマイズ、問題のトラブルシューティング、Tomcat へのアプリケーションのデプロイを確実に行うことができます。 次のようなカスタマイズが可能です。

• Tomcat 構成のカスタマイズ: server.xml ファイルと Tomcat の構成の詳細を理解することで、アプリケーションのニーズに合わせてサーバー設定を微調整することができます。
• デバッグ: アプリケーションが Tomcat サーバーにデプロイされるとき、開発者は発生する可能性のある問題をデバッグするためにサーバー構成を知る必要があります。 これには、サーバー ログの確認、構成ファイルの調査、発生している可能性のあるエラーの特定が含まれます。
• Tomcat の問題のトラブルシューティング: Java 開発者は、パフォーマンスの問題や構成エラーなど、Tomcat サーバーに関する問題に必然的に直面します。 server.xml ファイルと Tomcat の構成の詳細を理解することで、開発者はこれらの問題を迅速に診断してトラブルシューティングできるため、時間と労力を節約できます。
• Tomcat へのアプリケーションのデプロイ: Java Web アプリケーションを Tomcat にデプロイするには、開発者は server.xml ファイルとその他の Tomcat 設定を構成する方法を知る必要があります。 これらの詳細を理解することは、アプリケーションを正常にデプロイし、サーバー上で円滑に実行させるために不可欠です。

Java ワークロード (WAR ファイルまたは JAR ファイル) をホストするために組み込みの Tomcat を使用してアプリを作成する場合、Tomcat の構成には、すぐに使用できる特定の設定があります。 Tomcat Web Server の既定の構成など、詳細については、 公式 Apache Tomcat ドキュメント を参照してください。

さらに、起動時に Tomcat ディストリビューションの server.xml の上にさらに適用される特定の変換があります。 これらは、コネクタ、ホスト、バルブの設定への変換です。

最新バージョンの Tomcat には server.xml が存在します (8.5.58 および 9.0.38 以降)。 以前のバージョンの Tomcat では変換が使用されず、結果として動作が異なる可能性があります。

コネクタ

<Connector port="${port.http}" address="127.0.0.1" maxHttpHeaderSize="16384" compression="on" URIEncoding="UTF-8" connectionTimeout="${site.connectionTimeout}" maxThreads="${catalina.maxThreads}" maxConnections="${catalina.maxConnections}" protocol="HTTP/1.1" redirectPort="8443"/>

• maxHttpHeaderSize が 16384
• URIEncoding が UTF-8
• connectionTimeout が WEBSITE_TOMCAT_CONNECTION_TIMEOUT に設定されている場合、既定値は 240000
• maxThreads が WEBSITE_CATALINA_MAXTHREADS に設定されている場合、既定値は 200
• maxConnections が WEBSITE_CATALINA_MAXCONNECTIONS に設定されている場合、既定値は 10000

Note

connectionTimeout、maxThreads、maxConnections の設定は、アプリの設定で調整できます

connectionTimeout、maxThreads、maxConnections の値を変更するために使用できる CLI コマンドの例を次に示します。

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

• コネクタでは、127.0.0.1 ではなくコンテナーのアドレスを使用します

Host

<Host appBase="${site.appbase}" xmlBase="${site.xmlbase}" unpackWARs="${site.unpackwars}" workDir="${site.tempdir}" errorReportValveClass="com.microsoft.azure.appservice.AppServiceErrorReportValve" name="localhost" autoDeploy="true">

• appBase が AZURE_SITE_APP_BASE に設定されている場合、既定値はローカル WebappsLocalPath
• xmlBase が AZURE_SITE_HOME に設定されている場合、既定値は /site/wwwroot
• unpackWARs が AZURE_UNPACK_WARS に設定されている場合、既定値は true
• workDir が JAVA_TMP_DIR に設定されている場合、既定値は TMP
• errorReportValveClass は、カスタム エラー レポート バルブを使用します

バルブ

<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 が AZURE_LOGGING_DIR に設定されている場合、既定値は home\logFiles
• maxDays は WEBSITE_HTTPLOGGING_RETENTION_DAYS に設定され、その既定値は 7 です。 これは、Application Logging プラットフォームの既定値と一致します

Linux では、すべて同じカスタマイズに加え、次の機能も備わっています。

• エラーページとレポートページをバルブに追加します。

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

次のステップ

Java 開発者向けの Azure センターにアクセスして、Azure クイック スタート、チュートリアル、および Java リファレンス ドキュメントを入手してください。

• App Service Linux の FAQ
• 環境変数とアプリ設定のリファレンス