Azure App Service 向けの Java アプリを構成する

[アーティクル]
04/12/2024

Note

Spring アプリケーションの場合は、Azure Spring Apps を使用することをお勧めします。ただし、Azure App Service は引き続き宛先として使用できます。

Java 開発者は、Azure App Service を使用することで、フルマネージドサービス上で Java SE、Tomcat、JBoss EAP の Web アプリケーションを迅速にビルド、デプロイ、スケーリングすることができます。アプリケーションのデプロイは、Maven プラグインを使用して、コマンドラインから、または IntelliJ、Eclipse、Visual Studio Code などのエディターで行います。

このガイドでは、App Service を使用する Java 開発者向けに主要な概念と手順を示します。 Azure App Service を使用したことがない場合は、まず Java クイックスタートをお読みください。 Java 開発に限られない、App Service の使用に関する一般的な質問については、App Service の FAQ に関する記事で回答されています。

Java バージョンを表示する

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

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

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

アプリのデプロイ

ビルドツール

Maven

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

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

このコマンドによって、既存の Azure Web アプリを選択するか、新しいアプリを作成するかを選択するメッセージが表示され、azure-webapp-maven-plugin プラグインと関連する構成が追加されます。次のコマンドを使用して、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 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

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

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

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

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

Note

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

Tomcat

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

JBoss EAP

.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 アプリをデプロイするための最適な選択肢ではありません。

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

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

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

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 と入力します。

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

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

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

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

SSH コンソールアクセス

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

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

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

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

SSH 接続

Note

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

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

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

組み込みの 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 アプリケーションでの問題のトラブルシューティングを行うことができます。

時間指定の記録

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

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

`.jfr` ファイルの分析

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

アプリのログ記録

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

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 SE の場合は JAVA_OPTS という名前、Tomcat の場合は 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 ビルドファイルを使用できます。

セキュリティで保護されたアプリケーション

App Service で実行される Java アプリケーションは、他のアプリケーションと同じ一連のセキュリティのベストプラクティスを備えています。

ユーザーを認証する (Easy Auth)

[認証/承認] オプションを使用して、Azure portal でアプリ認証を設定します。そこから、Microsoft Entra ID、または Facebook、Google、GitHub などのソーシャルサインインを使用して、認証を有効にすることができます。 Azure portal の構成は、1 つの認証プロバイダーを構成するときにのみ機能します。詳細については、「Microsoft Entra サインインを使用するよう App Service アプリを構成する」と、他の ID プロバイダーの関連記事を参照してください。複数のサインインプロバイダーを有効にする必要がある場合は、「サインインとサインアウトのカスタマイズ」の手順に従います。

Java SE

Spring Boot 開発者は、Microsoft Entra Spring Boot スターターを使用して、使い慣れた Spring Security の注釈と API を使用してアプリケーションをセキュリティで保護することができます。 application.properties ファイルで最大ヘッダーサイズを大きくしてください。 16384 の値をお勧めします。

Tomcat

Tomcat アプリケーションでは、Principal オブジェクトを Map オブジェクトにキャストすることで、サーブレットから直接ユーザーの要求にアクセスできます。 Map オブジェクトによって、各要求の種類がその種類の要求のコレクションにマップされます。次のコード例では、request は HttpServletRequest のインスタンスです。

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

これで Map オブジェクトの特定の要求を検査できます。たとえば、次のコードスニペットでは、すべての要求の種類を反復処理し、各コレクションのコンテンツを出力します。

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

ユーザーをサインアウトさせるには、/.auth/ext/logout パスを使います。他のアクションを実行するには、サインインとサインアウトのカスタマイズに関するドキュメントを参照してください。 Tomcat の HttpServletRequest インターフェイスとそのメソッドに関する公式ドキュメントもあります。次のサーブレットメソッドも、ご利用の App Service 構成に基づいてハイドレートされます。

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

この機能を無効にするには、1 の値で WEBSITE_AUTH_SKIP_PRINCIPAL という名前のアプリケーション設定を作成します。 App Service によって追加されるすべてのサーブレットフィルターを無効にするには、1 の値を含む WEBSITE_SKIP_FILTERS という名前の設定を作成します。

TLS/SSL を構成する

既存の TLS/SSL 証明書をアップロードし、アプリケーションのドメイン名にバインドするには、「Azure App Service で TLS/SSL バインドを使用してカスタム DNS 名をセキュリティで保護する」の手順に従います。 TLS/SSL を適用するようにアプリを構成することもできます。

KeyVault 参照を使用する

Azure Key Vault では、アクセスポリシーと監査履歴を使用した一元的なシークレット管理を提供しています。シークレット (パスワードや接続文字列など) を KeyVault に格納し、環境変数を使用してアプリケーション内でこれらのシークレットにアクセスすることができます。

最初に、キーコンテナーへのアクセス権をアプリに付与したり、アプリケーション設定で自分のシークレットに対する KeyVault 参照を設定したりするための手順に従います。 App Service のターミナルにリモートでアクセスしている間に環境変数を出力することで、シークレットへの参照が解決されることを確認できます。

Spring または Tomcat 構成ファイルにこれらのシークレットを挿入するには、環境変数の挿入構文 (${MY_ENV_VAR}) を使用します。 Spring の構成ファイルについては、外部化された構成に関するこちらのドキュメントを参照してください。

Java キーストアを使用する

既定では、App Service Linux にアップロードされたパブリック証明書またはプライベート証明書は、コンテナーの起動時にそれぞれの Java キーストアに読み込まれます。証明書のアップロード後、証明書が Java キーストアに読み込まれるようにするために、App Service を再起動する必要があります。パブリック証明書は $JRE_HOME/lib/security/cacerts のキーストアに読み込まれ、プライベート証明書は $JRE_HOME/lib/security/client.jks に格納されます。

Java キーストアの証明書を使って JDBC 接続を暗号化するために、その他の構成が必要になる場合があります。選択した JDBC ドライバーのドキュメントを参照してください。

Java キーストアを初期化する

import java.security.KeyStore オブジェクトを初期化するには、キーストアファイルをパスワードと共に読み込みます。両方のキーストアの既定のパスワードは 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());

キーストアを手動で読み込む

キーストアに証明書を手動で読み込むことができます。アプリ設定 SKIP_JAVA_KEYSTORE_LOAD を作成し、値を 1 に設定して、証明書がキーストアに自動的に読み込まれないように App Service を無効にします。 Azure portal 経由で App Service にアップロードされたすべてのパブリック証明書は /var/ssl/certs/ に格納されます。プライベート証明書は /var/ssl/private/ に格納されます。

App Service への SSH 接続を開き、コマンド keytool を実行することで、Java キーツールと対話することやデバッグを行うことができます。コマンドの一覧については、キーツールのドキュメントを参照してください。キーストア API の詳細については、公式ドキュメントを参照してください。

APM プラットフォームを構成する

このセクションでは、Azure App Service にデプロイされた Java アプリケーションを Azure Monitor Application Insights、NewRelic、および AppDynamics アプリケーションパフォーマンスの監視 (APM) プラットフォームと接続する方法を示します。

Application Insights の構成

Azure Monitor Application Insights は、クラウドネイティブのアプリケーション監視サービスです。これを使用すると、障害、ボトルネック、使用パターンを監視して、アプリケーションのパフォーマンスを向上させること、および平均解決時間 (MTTR) を短縮することができます。数回のクリックまたは CLI コマンドで、Node.js または Java アプリを監視したり、ログ、メトリック、および分散トレースを自動収集したりすることができ、アプリに SDK を含める必要がなくなります。エージェントの構成に使用できるアプリ設定の詳細については、Application Insights のドキュメントを参照してください。

Azure Portal

Azure portal で Application Insights を有効にするには、左側のメニューで [Application Insights] に移動し、 [Application Insights を有効にする] を選択します。既定では、Web アプリと同じ名前の新しい Application Insights リソースが使用されます。既存の Application Insights リソースを使用することも、名前を変更することもできます。下部にある [適用] を選択します。

Azure CLI

Azure CLI を使用して有効にするには、Application Insights リソースを作成し、Application Insights を Web アプリに接続するために、Azure portal でいくつかのアプリ設定を指定する必要があります。

Application Insights 拡張機能を有効にする
```
az extension add -n application-insights
```
次の CLI コマンドを使用して、Application Insights のリソースを作成します。プレースホルダーは、任意のリソース名とグループに置き換えます。
```
az monitor app-insights component create --app <resource-name> -g <resource-group> --location westus2  --kind web --application-type web
```
connectionString および instrumentationKey の値を書き留めておいてください。これらの値は、次の手順で必要になります。

他の場所の一覧を取得するには、az account list-locations を実行します。

インストルメンテーションキー、接続文字列、および監視エージェントのバージョンを、Web アプリのアプリ設定として指定します。 <instrumentationKey> と <connectionString> は、前の手順で取得した値に置き換えてください。

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"

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"

New Relic の構成

NewRelic.com で NewRelic アカウントを作成します
NewRelic から Java エージェントをダウンロードします。これは、newrelic-java-x.x.x.zip のようなファイル名です。
ライセンスキーをコピーします。これは後ほどエージェントの構成を行う際に必要です。
App Service インスタンスに SSH で接続し、新しいディレクトリ /home/site/wwwroot/apm を作成します。
/home/site/wwwroot/apm の下にあるディレクトリにアンパックされた NewRelic Java エージェントファイルをアップロードします。エージェント用のファイルは /home/site/wwwroot/apm/newrelic 内にある必要があります。
/home/site/wwwroot/apm/newrelic/newrelic.yml で YAML ファイルを変更し、プレースホルダーライセンスの値を独自のライセンスキーに置き換えます。
Azure portal で App Service でアプリケーションを参照し、新しいアプリケーション設定を作成します。
- Java SE アプリの場合は、名前が JAVA_OPTS で値が -javaagent:/home/site/wwwroot/apm/newrelic/newrelic.jar の環境変数を作成します。
- Tomcat の場合は、名前が CATALINA_OPTS で値が -javaagent:/home/site/wwwroot/apm/newrelic/newrelic.jar の環境変数を作成します。

NewRelic.com で NewRelic アカウントを作成します
NewRelic から Java エージェントをダウンロードします。これは、newrelic-java-x.x.x.zip のようなファイル名です。
ライセンスキーをコピーします。これは後ほどエージェントの構成を行う際に必要です。
App Service インスタンスに SSH で接続し、新しいディレクトリ /home/site/wwwroot/apm を作成します。
/home/site/wwwroot/apm の下にあるディレクトリにアンパックされた NewRelic Java エージェントファイルをアップロードします。エージェント用のファイルは /home/site/wwwroot/apm/newrelic 内にある必要があります。
/home/site/wwwroot/apm/newrelic/newrelic.yml で YAML ファイルを変更し、プレースホルダーライセンスの値を独自のライセンスキーに置き換えます。
Azure portal で App Service でアプリケーションを参照し、新しいアプリケーション設定を作成します。
- Java SE アプリの場合は、名前が JAVA_OPTS で値が -javaagent:/home/site/wwwroot/apm/newrelic/newrelic.jar の環境変数を作成します。
- Tomcat の場合は、名前が CATALINA_OPTS で値が -javaagent:/home/site/wwwroot/apm/newrelic/newrelic.jar の環境変数を作成します。

JAVA_OPTS または CATALINA_OPTS 用の環境変数がすでにある場合、-javaagent:/... のオプションを現在値の最期に追加します。

AppDynamics の構成

AppDynamics.com で AppDynamics アカウントを作成します
AppDynamics の Web サイトから Java エージェントをダウンロードします。このファイル名は、AppServerAgent-x.x.x.xxxxx.zip のようになります。
Kudu コンソールを使用して、新しいディレクトリ /home/site/wwwroot/apm を作成します。
/home/site/wwwroot/apm の下にあるディレクトリに Java エージェントファイルをアップロードします。エージェント用のファイルは /home/site/wwwroot/apm/appdynamics 内にある必要があります。
Azure portal で App Service でアプリケーションを参照し、新しいアプリケーション設定を作成します。
- Java SE アプリの場合は、名前が JAVA_OPTS で値が -javaagent:/home/site/wwwroot/apm/appdynamics/javaagent.jar -Dappdynamics.agent.applicationName=<app-name> の環境変数を作成します。<app-name> は App Service の名前です。
- Tomcat アプリの場合は、名前が CATALINA_OPTS で値が -javaagent:/home/site/wwwroot/apm/appdynamics/javaagent.jar -Dappdynamics.agent.applicationName=<app-name> の環境変数を作成します。<app-name> は App Service の名前です。

AppDynamics.com で AppDynamics アカウントを作成します
AppDynamics の Web サイトから Java エージェントをダウンロードします。このファイル名は、AppServerAgent-x.x.x.xxxxx.zip のようになります。
App Service インスタンスに SSH で接続し、新しいディレクトリ /home/site/wwwroot/apm を作成します。
/home/site/wwwroot/apm の下にあるディレクトリに Java エージェントファイルをアップロードします。エージェント用のファイルは /home/site/wwwroot/apm/appdynamics 内にある必要があります。
Azure portal で App Service でアプリケーションを参照し、新しいアプリケーション設定を作成します。
- Java SE アプリの場合は、名前が JAVA_OPTS で値が -javaagent:/home/site/wwwroot/apm/appdynamics/javaagent.jar -Dappdynamics.agent.applicationName=<app-name> の環境変数を作成します。<app-name> は App Service の名前です。
- Tomcat アプリの場合は、名前が CATALINA_OPTS で値が -javaagent:/home/site/wwwroot/apm/appdynamics/javaagent.jar -Dappdynamics.agent.applicationName=<app-name> の環境変数を作成します。<app-name> は App Service の名前です。

Note

JAVA_OPTS または CATALINA_OPTS 用の環境変数がすでにある場合、-javaagent:/... のオプションを現在値の最期に追加します。

データソースの構成

Java SE

Spring Boot アプリケーション内のデータソースに接続するには、接続文字列を作成し、それらを application.properties ファイルに挿入することをお勧めします。

App Service ページの [構成] セクションに文字列の名前を設定し、JDBC 接続文字列を値フィールドに貼り付けて、タイプを [カスタム] に設定します。必要に応じて、この接続文字列をスロット設定として設定することができます。

この接続文字列は、CUSTOMCONNSTR_<your-string-name> という名前の環境変数としてアプリケーションにアクセスできます。たとえば、CUSTOMCONNSTR_exampledb のようにします。
application.properties ファイルで、環境変数名を使用してこの接続文字列を参照します。たとえば、例では次を使用します。
```
app.datasource.url=${CUSTOMCONNSTR_exampledb}
```

詳細については、データアクセスと外部化された構成に関する Spring Boot の資料を参照してください。

Tomcat

これらの説明は、すべてのデータベース接続に適用されます。プレースホルダーを、選択したデータベースのドライバークラス名と JAR ファイルに置き換える必要があります。一般的なデータベースのクラス名とドライバーのダウンロードを含む表を次に示します。

データベース	ドライバーのクラス名	JDBC ドライバー
PostgreSQL	`org.postgresql.Driver`	ダウンロード
MySQL	`com.mysql.jdbc.Driver`	ダウンロード ("プラットフォームに依存しない" を選択)
SQL Server	`com.microsoft.sqlserver.jdbc.SQLServerDriver`	ダウンロード

Java Database Connectivity (JDBC) または Java Persistence API (JPA) を使用するように Tomcat を構成するには、まず、起動時に Tomcat によって読み込まれる CATALINA_OPTS 環境変数をカスタマイズします。 App Service Maven プラグインのアプリ設定を使用して、次の値を設定します。

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

または、Azure portal の [構成]>[アプリケーション設定] ページで環境変数を設定します。

次に、データソースを Tomcat サーブレットで実行されている 1 つのアプリケーション、またはすべてのアプリケーションのどちらに対して使用可能にする必要があるかを判定します。

アプリケーションレベルデータソース

プロジェクトの META-INF/ ディレクトリ内に context.xml ファイルを作成します。 META-INF/ ディレクトリが存在しない場合は作成します。

context.xml で、Context 要素を追加してデータソースを JNDI アドレスにリンクします。 driverClassName プレースホルダーを、上の表にあるドライバーのクラス名に置き換えます。

<Context>
    <Resource
        name="jdbc/dbconnection"
        type="javax.sql.DataSource"
        url="${connURL}"
        driverClassName="<insert your driver class name>"
        username="${dbuser}"
        password="${dbpassword}"
    />
</Context>

アプリケーションでこのデータソースを使用するよう、アプリケーションの web.xml を更新します。

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

共有のサーバーレベルリソース

Windows での App Service 上の Tomcat インストールは、App Service プランの共有領域に存在します。サーバー全体の構成では、Tomcat インストールを直接変更することはできません。 Tomcat インストールにサーバーレベルの構成変更を加えるには、Tomcat をローカルフォルダーにコピーする必要があります。そこで、Tomcat の構成を変更できます。

アプリ起動時のカスタム Tomcat の作成を自動化する

スタートアップスクリプトを使用すると、Web アプリが起動する前にアクションを実行できます。 Tomcat をカスタマイズするためのスタートアップスクリプトでは、次の手順を完了する必要があります。

Tomcat が既にローカルにコピーされ、構成されているかどうかを確認します。そうなっている場合は、ここでスタートアップスクリプトを終了できます。
Tomcat をローカルにコピーします。
必要な構成変更を行います。
構成が正常に完了したことを示します。

Windows アプリの場合は、wwwroot ディレクトリに startup.cmd または startup.ps1 という名前のファイルを作成します。このファイルは、Tomcat サーバーが起動する前に自動的に実行されます。

この手順を完了する PowerShell スクリプトを次に示します。

    # 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

変換

Tomcat バージョンをカスタマイズするための一般的なユースケースは、server.xml、context.xml、または web.xml の Tomcat 構成ファイルの変更です。 App Service では、プラットフォーム機能を提供するために、既にこれらのファイルを変更しています。これらの機能を引き続き使用するには、これらのファイルを変更するときに、そこに含まれている内容を保持することが重要です。これを実現するには、XSL 変換 (XSLT) を使用することをお勧めします。ファイルの元の内容を保持したまま XML ファイルを変更するには、XSL 変換を使用します。

XSLT ファイルの例

この変換の例では、server.xml に新しいコネクタノードを追加します。 "恒等変換" に注意してください。これにより、ファイルの元の内容が保持されます。

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

XSL 変換のための関数

PowerShell には、XSL 変換を使用して XML ファイルを変換するための組み込みツールがあります。次のスクリプトは、この変換を実行するために startup.ps1 で使用できる関数の例です。

    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
    }

アプリ設定

プラットフォームでは、カスタムバージョンの Tomcat がインストールされている場所も認識している必要があります。インストールの場所は、CATALINA_BASE のアプリ設定で設定できます。

この設定は、次のように、Azure CLI を使用して変更できます。

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

または、次のように、この設定を Azure portal で手動で変更できます。

[設定]>[構成]>[アプリケーションの設定] の順に移動します。
[新しいアプリケーション設定] を選択します。
次の値を使用して設定を作成します。
1. 名前: CATALINA_BASE
2. 値: "%LOCAL_EXPANDED%\tomcat"

startup.ps1 の例

次のサンプルスクリプトでは、カスタム Tomcat をローカルフォルダーにコピーし、XSL 変換を実行してから、変換が成功したことを示します。

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

構成を完了する

最後に、ドライバーの JAR を Tomcat クラスパス内に配置し、App Service を再起動します。 JDBC ドライバーファイルが Tomcat クラスローダーで確実に使用できるように、これらのファイルを /home/site/lib ディレクトリに配置します。 Cloud Shell で、ドライバー JAR ごとに az webapp deploy --type=lib を実行します。

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

Tomcat

データベース	ドライバーのクラス名	JDBC ドライバー
PostgreSQL	`org.postgresql.Driver`	ダウンロード
MySQL	`com.mysql.jdbc.Driver`	ダウンロード ("プラットフォームに依存しない" を選択)
SQL Server	`com.microsoft.sqlserver.jdbc.SQLServerDriver`	ダウンロード

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

または、Azure portal の [構成]>[アプリケーション設定] ページで環境変数を設定します。

アプリケーションレベルデータソース

プロジェクトの META-INF/ ディレクトリ内に context.xml ファイルを作成します。 META-INF/ ディレクトリが存在しない場合は作成します。

<Context>
    <Resource
        name="jdbc/dbconnection"
        type="javax.sql.DataSource"
        url="${connURL}"
        driverClassName="<insert your driver class name>"
        username="${dbuser}"
        password="${dbpassword}"
    />
</Context>

アプリケーションでこのデータソースを使用するよう、アプリケーションの web.xml を更新します。

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

共有のサーバーレベルリソース

サーバーレベルの共有データソースを追加するには、Tomcat の server.xml を編集する必要があります。まず、スタートアップスクリプトをアップロードし、 [構成]>[スタートアップコマンド] でスクリプトへのパスを設定します。 FTP を使用してスタートアップスクリプトをアップロードできます。

スタートアップスクリプトによって、server.xml ファイルへの xsl 変換が作成され、結果の xml ファイルが /usr/local/tomcat/conf/server.xml に出力されます。スタートアップスクリプトでは、apk を使用して libxslt をインストールする必要があります。 xsl ファイルとスタートアップスクリプトは FTP 経由でアップロードできます。以下にスタートアップスクリプトの例を示します。

# 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

次の XSL ファイルの例では、新しいコネクタノードを Tomcat server.xml に追加します。

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

構成を完了する

最後に、ドライバーの JAR を Tomcat クラスパス内に配置し、App Service を再起動します。

JDBC ドライバーファイルが Tomcat クラスローダーで確実に使用できるように、これらのファイルを /home/site/lib ディレクトリに配置します。 Cloud Shell で、ドライバー JAR ごとに az webapp deploy --type=lib を実行します。

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

サーバーレベルのデータソースを作成した場合は、App Service Linux アプリケーションを再起動します。 Tomcat が CATALINA_BASE を /home/tomcat にリセットし、更新された構成を使用します。

JBoss EAP データソース

JBoss EAP を使用してデータソースを登録する場合の 3 つの主要なステップは、JDBC ドライバーのアップロード、モジュールとしての JDBC ドライバーの追加、モジュールの登録です。 App Service はステートレスのホスティングサービスであるため、データソースモジュールを追加および登録するための構成コマンドは、スクリプト化して、コンテナーの起動時に適用する必要があります。

データベースの JDBC ドライバーを入手します。

JDBC ドライバー用の XML モジュール定義ファイルを作成します。 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>

JBoss CLI コマンドが含まれる jboss-cli-commands.cli という名前のファイルを作成します。 JBoss コマンドを使用して、モジュールを追加し、データソースとして登録する必要があります。次の例では、PostgreSQL 用の JBoss CLI コマンドを示します。

#!/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

JBoss CLI コマンドを呼び出すスタートアップスクリプト startup_script.sh を作成します。次の例は、jboss-cli-commands.cli を呼び出す方法を示しています。後で、コンテナーの起動時にこのスクリプトを実行するように App Service を構成します。
```
$JBOSS_HOME/bin/jboss-cli.sh --connect --file=/home/site/deployments/tools/jboss-cli-commands.cli
```
任意の FTP クライアントを使用して、JDBC ドライバー、jboss-cli-commands.cli、startup_script.sh、およびモジュール定義を /site/deployments/tools/ にアップロードします。
コンテナーの起動時に startup_script.sh を実行するようにサイトを構成します。 Azure portal で、 [構成]>[一般設定]>[スタートアップコマンド] に移動します。スタートアップコマンドフィールドを /home/site/deployments/tools/startup_script.sh に設定します。変更内容を保存します。

データソースが JBoss サーバーに追加されたことを確認するには、webapp に SSH で接続して、$JBOSS_HOME/bin/jboss-cli.sh --connect を実行します。 JBoss に接続したら、/subsystem=datasources:read-resource を実行してデータソースの一覧を表示します。

ログの 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 EAP

JBoss EAP でのクラスタリング

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 インスタンスは、クラスターメンバーシップファイルに対する読み取り/書き込みアクセス許可を取得します。その他のインスタンスは、このファイルを読み取ってプライマリノードを見つけた後、クラスターに含まれ、このファイルに追加されるようにそのノードと調整します。

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

自動スケールルール

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

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

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

JBoss EAP App Service プラン

JBoss EAP は、Premium v3 および Isolated v2 App Service プランタイプでのみ使用できます。パブリックプレビュー中に別のレベルで JBoss EAP サイトを作成したお客様は、予期しない動作を避けるために、Premium または Isolated のハードウェアレベルにスケールアップする必要があります。

App Services での 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
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 向けの Java アプリを構成する

Java バージョンを表示する

アプリのデプロイ

ビルド ツール

Maven

Gradle

IDE

Kudu API

Java SE

Tomcat

JBoss EAP

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

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

SSH コンソール アクセス

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

Java Profiler

Flight Recorder

時間指定の記録

継続的な記録

.jfr ファイルの分析

アプリのログ記録

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

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

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

Web ソケットを有効にする

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

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

セキュリティで保護されたアプリケーション

ユーザーを認証する (Easy Auth)

Java SE

Tomcat

TLS/SSL を構成する

KeyVault 参照を使用する

Java キー ストアを使用する

Java キー ストアを初期化する

キー ストアを手動で読み込む

APM プラットフォームを構成する

Application Insights の構成

Azure Portal

Azure CLI

New Relic の構成

AppDynamics の構成

データ ソースの構成

Java SE

Tomcat

アプリケーション レベル データ ソース

共有のサーバーレベル リソース

アプリ起動時のカスタム Tomcat の作成を自動化する

変換

XSLT ファイルの例

XSL 変換のための関数

アプリ設定

startup.ps1 の例

構成を完了する

Tomcat

アプリケーション レベル データ ソース

共有のサーバーレベル リソース

構成を完了する

JBoss EAP データ ソース

ログの robots933456

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

JBoss EAP

JBoss EAP でのクラスタリング

自動スケール ルール

JBoss EAP App Service プラン

App Services での Tomcat ベースライン構成

コネクタ

Host

バルブ

次のステップ

その他のリソース

ビルドツール

SSH コンソールアクセス

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

`.jfr` ファイルの分析

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

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

Java キーストアを使用する

Java キーストアを初期化する

キーストアを手動で読み込む

データソースの構成

アプリケーションレベルデータソース

共有のサーバーレベルリソース

アプリケーションレベルデータソース

共有のサーバーレベルリソース

JBoss EAP データソース

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

自動スケールルール