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

[アーティクル]
07/26/2024

この記事では、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 - Premium v3 および Isolated v2 価格レベルの Linux アプリでのみサポートされます。組み込みの JBoss EAP サーバーは、WAR または EAR パッケージとしてデプロイされたアプリを実行できます。

Note

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

現在の 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"

現在の 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

Azure Web アプリ用の Gradle プラグインを build.gradle に追加することで、このプラグインをセットアップします。
```
plugins {
  id "com.microsoft.azure.azurewebapp" version "1.10.0"
}
```

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

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
Windows

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

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

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 でログファイルを検査することもできます。

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 サブスクリプションで認証する必要があります。認証されると、ブラウザー内シェルが表示され、コンテナー内でコマンドを実行することができます。

SSH 接続

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
Windows

対象の 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"

時間指定の記録

時間を指定して記録を行うには、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
Windows

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

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

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

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

Note

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

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

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

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

アプリの設定 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 ビルドファイルを使用できます。

Note

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

クラスタリング

App Service では、JBoss EAP バージョン 7.4.1 以上でのクラスタリングがサポートされています。クラスタリングを有効にするには、Web アプリが仮想ネットワークに統合されている必要があります。 Web アプリは、仮想ネットワークに統合されている場合、再起動し、JBoss EAP インストールがクラスター化構成で自動的に起動します。 JBoss EAP インスタンスは、実行時に WEBSITES_PRIVATE_PORTS 環境変数に示されているポートを使用して、仮想ネットワーク統合で指定されたサブネット経由で通信します。任意の値を持つ 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 の価格レベルで利用できます。

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
conectionTimeout が WEBSITE_TOMCAT_CONNECTION_TIMEOUT に設定されている場合、既定値は 240000
maxThreads が WEBSITE_CATALINA_MAXTHREADS に設定されている場合、既定値は 200
maxConnections が WEBSITE_CATALINA_MAXCONNECTIONS に設定されている場合、既定値は 10000

Note

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

conectionTimeout、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 に設定されている場合、既定値は 0 [forever]

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 リファレンスドキュメントを入手してください。

次の方法で共有

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

Java バージョンを表示する

アプリのデプロイ

ビルドツール

Maven

Gradle

IDE

Kudu API

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

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

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

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

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

Java Profiler

Flight Recorder

継続的な記録

時間指定の記録

`.jfr` ファイルの分析

アプリのログ記録

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

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

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

Web ソケットを有効にする

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

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

ログの robots933456

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

クラスタリング

自動スケールルール

App Service プラン

Tomcat ベースライン構成

コネクタ

Host

バルブ

次のステップ

フィードバック

その他のリソース

次の方法で共有

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

Java バージョンを表示する

アプリのデプロイ

ビルド ツール

Maven

Gradle

IDE

Kudu API

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

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

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

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

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

Java Profiler

Flight Recorder

継続的な記録

.jfr ファイルの分析

アプリのログ記録

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

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

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

Web ソケットを有効にする

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

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

ログの robots933456

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

クラスタリング

自動スケール ルール

App Service プラン

Tomcat ベースライン構成

コネクタ

Host

バルブ

次のステップ

フィードバック

その他のリソース

ビルドツール

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

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

`.jfr` ファイルの分析

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

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

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

自動スケールルール