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

これらのデプロイ方法を使用すると、デプロイ プロセス中に指定された JAR ファイルの名前が自動的に app.jar に変更されます。 これは /home/site/wwwwrootの下に配置されます。 JAR ファイルを Java SE にデプロイするには、 このドキュメントを参照してください。

このドキュメントに従って、WAR ファイルを Tomcat アプリケーションにデプロイできます。 上記のデプロイ方法を使用すると、展開プロセス中に、提供された War ファイルの名前が自動的に app.war に変更されます。 これは /home/site/wwwwroot の下に配置され、既定では、 wwwrootの下に 1 つの WAR ファイルのデプロイのみがサポートされます。 これは、WarDeploy などのデプロイ API を使用する場合のように、 ディレクトリの下/home/site/wwwroot/webapps。 ファイル構造の競合に関する問題を回避するには、一方または他の展開の種類のみを使用することをお勧めします。

WAR ファイルを JBoss EAP にデプロイするには、 このドキュメントを参照してください。 OneDeploy を使用すると、WAR ファイルの名前が自動的に app.war に変更され、 /home/site/wwwrootの下に配置されます。

EAR ファイルをデプロイするには、 FTP を使用します。 EAR アプリケーションは、アプリケーションの構成で定義されているコンテキスト・ルートにデプロイされます。 Web アプリがルート パスで提供されるようにするには、アプリでコンテキスト ルートがルート パスに設定されていることを確認します (<context-root>/</context-root>)。 詳細については、「 Web アプリケーションのコンテキスト ルートの設定」を参照してください。

Tomcat には 書き換えバルブも用意されています。

JBoss EAP には 書き換えバルブも用意されています。

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

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

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

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

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

JBoss CLI を実行する

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

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

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

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

また、スタートアップ時に任意のファイルを実行するように 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 という名前のアプリ設定を作成することによって、クラスタリングを無効にすることができます。

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

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

自動スケール ルール

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

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

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

App Service プラン

JBoss EAP は、F1、P0v3、P1mv3、P2mv3、P3mv3、P4mv3、P0v4、P1mv4、P2mv4、P3mv4、P4mv4、P5mv4 の価格レベルで利用できます。

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

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_OPTS 環境変数に追加されます。
• ログ ディレクトリや Java メモリ ヒープ パラメーターなど、いくつかの初期 JVM 構成が決定されます。
  • アプリ設定 –Xms でメモリに –Xmx フラグまたは JAVA_OPTS フラグを指定すると、プラットフォームによって提供されるフラグは、これらの値によってオーバーライドされます。
  • アプリ設定を WEBSITES_CONTAINER_STOP_TIME_LIMIT構成した場合、この値はランタイム プロパティ org.wildfly.sigterm.suspend.timeoutに渡されます。このプロパティは、JBoss EAP が停止しているときの最大シャットダウン待機時間 (秒単位) を制御します。
• アプリが仮想ネットワークと統合されている場合、App Service ランタイムは環境変数 WEBSITE_PRIVATE_PORTS でサーバー間通信に使用するポートの一覧を渡し、 clustering 構成を使用して JBoss EAP を起動します。 それ以外の場合は、standalone 構成が使用されます。
  • clustering構成では、サーバー構成ファイルstandalone-azure-full-ha.xmlが使用されます。
  • standalone構成では、サーバー構成ファイルstandalone-full.xmlが使用されます。

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

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

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

• このフェーズの開始時に、App Service はまず、JBoss EAP サーバーと管理インターフェイスの両方が要求を受信する準備が整うのを待ってから続行します。 Application Insights が有効になっている場合、このプロセスには数秒かかることがあります。

• JBoss EAP Server と管理インターフェイスの両方の準備ができたら、App Service は次のアクションを実行します。

  • ログ記録と App Service との統合のためのユーティリティ クラスを提供する JBoss EAP モジュール azure.appserviceを追加します。
  • ログ ファイルがカラー エスケープ シーケンスでいっぱいにならないよう、コンソール ロガーを更新して無色モードを使用します。
  • Azure Monitor ログとの統合を設定します。
  • Web サービス記述言語 (WSDL) および管理インターフェイスのバインド IP アドレスを更新します。
  • azure.appservice.easyauthと Microsoft Entra ID と統合するための JBoss EAP モジュール を追加します。
  • アクセス ログのログ構成と、メイン サーバー ログ ファイルの名前とローテーションを更新します。

• アプリ設定 WEBSITE_SKIP_AUTOCONFIGURE_DATABASE が定義されていない限り、App Service は App Service アプリ設定で Java Database Connectivity (JDBC) URL を自動検出します。 PostgreSQL、MySQL、MariaDB、Oracle、SQL Server、または Azure SQL Database に対して有効な JDBC URL が存在する場合は、サーバーに対応するドライバーを追加し、各 JDBC URL のデータ ソースを追加し、各データ ソースの Java 名前付けおよびディレクトリ インターフェイス (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 EAP のインストール/カスタマイズ コマンドを実行したりできます。 Ubuntu パッケージ管理コマンドの詳細については、 Ubuntu Server のドキュメントを参照してください。 JBoss CLI コマンドについては、 JBoss Management CLI ガイドを参照してください。

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

スタートアップ スクリプトは、優先順位に従って次の場所を調べることで、JBoss EAP にアプリをデプロイします。

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

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

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

Tomcat ベースライン構成

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 に設定されます。

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 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 に設定されます。 この値は、アプリケーション ログ プラットフォームの既定値に合わせて調整されます。

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>