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

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 | 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 --linux | grep "JAVA\|TOMCAT\|JBOSSEAP"

アプリのデプロイ

ビルド ツール

Maven

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

mvn com.microsoft.azure:azure-webapp-maven-plugin:2.1.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.1.0</version>  
  <configuration>
    <subscriptionId>111111-11111-11111-1111111</subscriptionId>
    <resourceGroup>spring-boot-xxxxxxxxxx-rg</resourceGroup>
    <appName>spring-boot-xxxxxxxxxx</appName>
    <pricingTier>B2</pricingTier>
    <region>westus</region>
    <runtime>
      <os>Linux</os>      
      <webContainer>Java SE</webContainer>
      <javaVersion>Java 11</javaVersion>
    </runtime>
    <deployment>
      <resources>
        <resource>
          <type>jar</type>
          <directory>${project.basedir}/target</directory>
          <includes>
            <include>*.jar</include>
          </includes>
        </resource>
      </resources>
    </deployment>
  </configuration>
</plugin> 

Gradle

  1. プラグインを build.gradle に追加して、Azure Web アプリ用の Gradle プラグイン をセットアップします。

    plugins {
      id "com.microsoft.azure.azurewebapp" version "1.1.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 9.0' // or 'Java SE' if you want to run an executable jar
          javaVersion = 'Java 8'
        }
        appSettings {
            <key> = <value>
        }
        auth {
            type = 'azure_cli' // support azure_cli, oauth2, device_code and service_principal
        }
    }
    
  3. 1 つのコマンドでデプロイします。

    gradle azureWebAppDeploy
    

IDE

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

Kudu API

Java SE

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

注意

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 で有効な値は、ErrorWarningInfo、および Verbose です。 後続の各レベルには、前のレベルが含まれます。 たとえば、Error にはエラー メッセージのみが含まれ、Verbose にはすべてのメッセージが含まれます。

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

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

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

注意

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

注意

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

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

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

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

Flight Recorder

Azul JVM を使用する App Service のすべての Java ランタイムには、Zulu 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 秒の記録が開始され、D:\home ディレクトリに timed_recording_example.jfr という名前のファイルが生成されます。

jcmd <pid> JFR.start name=TimedRecording settings=profile duration=30s filename="D:\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 プロセスに対するすべての記録が表示されます。

継続的な記録

Zulu 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 ファイルを分析するには、Zulu Mission Control をダウンロードしてインストールします。 Zulu Mission Control については、Azul のドキュメントインストール手順をご覧ください。

アプリのログ記録

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 ベースの App Services の Azure Blob Storage のログ記録は Azure Monitor (プレビュー) を使用してのみ構成できます

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

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

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

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>-Xms512m -Xmx1204m</value>
    </property>
</appSettings>

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

  • B1 および S1 インスタンス: -Xms1024m -Xmx1024m
  • B2 および S2 インスタンス: -Xms3072m -Xmx3072m
  • B3 および S3 インスタンス: -Xms6144m -Xmx6144m

アプリケーション ヒープ設定をチューニングする際には、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 でアプリ認証を設定します。 そこから、Azure Active Directory、または Facebook、Google、GitHub などのソーシャル ログインを使用して、認証を有効にすることができます。 Azure portal の構成は、1 つの認証プロバイダーを構成するときにのみ機能します。 詳細については、「Azure Active Directory ログインを使用するよう App Service アプリを構成する」と、他の ID プロバイダーの関連記事を参照してください。 複数のサインイン プロバイダーを有効にする必要がある場合は、サインインとサインアウトのカスタマイズに関する記事の手順に従います。

Java SE

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

Tomcat

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

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 を構成する

Azure App Service での TLS/SSL バインドによるカスタム DNS 名のセキュリティ保護に関する記事の手順に従って、既存の TLS/SSL 証明書をアップロードし、アプリケーションのドメイン名にバインドします。 既定では、アプリケーションで引き続き HTTP 接続が許可されます。チュートリアルの特定の手順に従って、TLS/SSL を適用します。

KeyVault 参照を使用する

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

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

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

Java キー ストアを使用する

既定では、App Service Linux にアップロードされたパブリック証明書またはプライベート証明書は、コンテナーの起動時にそれぞれの Java キー ストアに読み込まれます。 証明書のアップロード後、証明書が Java キー ストアに読み込まれるようにするために、App Service を再起動する必要があります。 パブリック証明書は $JAVA_HOME/jre/lib/security/cacerts のキー ストアに読み込まれ、プライベート証明書は $JAVA_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("JAVA_HOME")+"/lib/security/cacets"),
    "changeit".toCharArray());

KeyStore keyStore = KeyStore.getInstance("pkcs12");
keyStore.load(
    new FileInputStream(System.getenv("JAVA_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 を含める必要がなくなります。

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 でいくつかのアプリ設定を指定する必要があります。

  1. Application Insights 拡張機能を有効にする

    az extension add -n application-insights
    
  2. 次の 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 を実行します。

  1. インストルメンテーション キー、接続文字列、および監視エージェントのバージョンを、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"
    
  1. インストルメンテーション キー、接続文字列、および監視エージェントのバージョンを、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"
    

New Relic の構成

  1. NewRelic.com で NewRelic アカウントを作成します

  2. NewRelic から Java エージェントをダウンロードします。ファイル名は newrelic-java-x.x.x.zip のようになります。

  3. ライセンス キーをコピーします。これは後ほどエージェントの構成を行う際に必要です。

  4. App Service インスタンスに SSH で接続し、新しいディレクトリ /home/site/wwwroot/apm を作成します。

  5. /home/site/wwwroot/apm の下にあるディレクトリにアンパックされた NewRelic Java エージェント ファイルをアップロードします。 エージェント用のファイルは /home/site/wwwroot/apm/newrelic 内にある必要があります。

  6. /home/site/wwwroot/apm/newrelic/newrelic.yml で YAML ファイルを変更し、プレース ホルダー ライセンスの値を独自のライセンス キーに置き換えます。

  7. 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 の環境変数を作成します。
  1. NewRelic.com で NewRelic アカウントを作成します

  2. NewRelic から Java エージェントをダウンロードします。ファイル名は newrelic-java-x.x.x.zip のようになります。

  3. ライセンス キーをコピーします。これは後ほどエージェントの構成を行う際に必要です。

  4. App Service インスタンスに SSH で接続し、新しいディレクトリ /home/site/wwwroot/apm を作成します。

  5. /home/site/wwwroot/apm の下にあるディレクトリにアンパックされた NewRelic Java エージェント ファイルをアップロードします。 エージェント用のファイルは /home/site/wwwroot/apm/newrelic 内にある必要があります。

  6. /home/site/wwwroot/apm/newrelic/newrelic.yml で YAML ファイルを変更し、プレース ホルダー ライセンスの値を独自のライセンス キーに置き換えます。

  7. 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 の構成

  1. AppDynamics.com で AppDynamics アカウントを作成します

  2. AppDynamics の Web サイトから Java エージェントをダウンロードします。ファイル名は AppServerAgent-x.x.x.xxxxx.zip のようになります

  3. Kudu コンソールを使用して、新しいディレクトリ /home/site/wwwroot/apm を作成します。

  4. /home/site/wwwroot/apm の下にあるディレクトリに Java エージェント ファイルをアップロードします。 エージェント用のファイルは /home/site/wwwroot/apm/appdynamics 内にある必要があります。

  5. 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 の名前です。
  1. AppDynamics.com で AppDynamics アカウントを作成します

  2. AppDynamics の Web サイトから Java エージェントをダウンロードします。ファイル名は AppServerAgent-x.x.x.xxxxx.zip のようになります

  3. App Service インスタンスに SSH で接続し、新しいディレクトリ /home/site/wwwroot/apm を作成します。

  4. /home/site/wwwroot/apm の下にあるディレクトリに Java エージェント ファイルをアップロードします。 エージェント用のファイルは /home/site/wwwroot/apm/appdynamics 内にある必要があります。

  5. 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 の名前です。

注意

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

データ ソースの構成

Java SE

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

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

    この接続文字列は、CUSTOMCONNSTR_<your-string-name> という名前の環境変数としてアプリケーションにアクセスできます。 たとえば、先ほど作成した接続文字列の名前は CUSTOMCONNSTR_exampledb になります。

  2. 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 つのアプリケーション、またはすべてのアプリケーションのどちらに対して使用可能にする必要があるかを判定します。

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

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

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

    <Context>
        <Resource
            name="jdbc/dbconnection"
            type="javax.sql.DataSource"
            url="${dbuser}"
            driverClassName="<insert your driver class name>"
            username="${dbpassword}"
            password="${connURL}"
        />
    </Context>
    
  3. アプリケーションでこのデータ ソースを使用するよう、アプリケーションの 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 をカスタマイズするためのスタートアップ スクリプトでは、次の手順を完了する必要があります。

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

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 could not be 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.xmlcontext.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 is 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 is 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" 
                 keystroreFile="${{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. [設定] > [構成] > [アプリケーションの設定] の順に移動します。
  2. [新しいアプリケーション設定] を選択します。
  3. 次の値を使用して設定を作成します。
    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 could not be 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/tomcat/lib ディレクトリに配置します。 (このディレクトリがまだ存在しない場合は作成します。)これらのファイルを App Service インスタンスにアップロードするには、次の手順を行います。

  1. Cloud Shell で、Web アプリ拡張機能をインストールします。

    az extension add -–name webapp
    
  2. 次の CLI コマンドを実行して、ローカル システムから App Service への SSH トンネルを作成します。

    az webapp remote-connection create --resource-group <resource-group-name> --name <app-name> --port <port-on-local-machine>
    
  3. SFTP クライアントを使用してローカルのトンネル ポートに接続し、ファイルを /home/tomcat/lib フォルダーにアップロードします。

あるいは、FTP クライアントを使用して JDBC ドライバーをアップロードできます。 FTP 資格情報を取得するための手順に従ってください。


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 つのアプリケーション、またはすべてのアプリケーションのどちらに対して使用可能にする必要があるかを判定します。

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

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

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

    <Context>
        <Resource
            name="jdbc/dbconnection"
            type="javax.sql.DataSource"
            url="${dbuser}"
            driverClassName="<insert your driver class name>"
            username="${dbpassword}"
            password="${connURL}"
        />
    </Context>
    
  3. アプリケーションでこのデータ ソースを使用するよう、アプリケーションの 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 ファイルの例は次のとおりです。 この 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 is 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 is 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" 
               keystroreFile="${{user.home}}/.keystore" keystorePass="changeit"
               clientAuth="false" sslProtocol="TLS" />
  </xsl:template>

</xsl:stylesheet>

構成を完了する

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

  1. JDBC ドライバー ファイルが Tomcat クラスローダーで確実に使用できるように、これらのファイルを /home/tomcat/lib ディレクトリに配置します。 (このディレクトリがまだ存在しない場合は作成します。)これらのファイルを App Service インスタンスにアップロードするには、次の手順を行います。

    1. Cloud Shell で、Web アプリ拡張機能をインストールします。
    az extension add -–name webapp
    
    1. 次の CLI コマンドを実行して、ローカル システムから App Service への SSH トンネルを作成します。
    az webapp remote-connection create --resource-group <resource-group-name> --name <app-name> --port <port-on-local-machine>
    
    1. SFTP クライアントを使用してローカルのトンネル ポートに接続し、ファイルを /home/tomcat/lib フォルダーにアップロードします。

    あるいは、FTP クライアントを使用して JDBC ドライバーをアップロードできます。 FTP 資格情報を取得するための手順に従ってください。

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

JBoss EAP

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

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

  2. 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>
    
  3. 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
    
  4. 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
    
  5. 任意の FTP クライアントを使用して、JDBC ドライバー、jboss-cli-commands.clistartup_script.sh、およびモジュール定義を /site/deployments/tools/ にアップロードします。

  6. コンテナーの起動時に 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 を使用します。これは構成できません。

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

JBoss EAP App Service プラン

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

Java ランタイムのサポート ステートメント

JDK のバージョンとメンテナンス

Azure でサポートされている Java Development Kit (JDK) は、Azul Systems で提供されている Zulu です。 OpenJDK の Azul Zulu Enterprise ビルドは、Microsoft および Azul Systems でサポートされる、Azure と Azure Stack 用の OpenJDK の無料でマルチプラット フォーム対応の実稼働可能なディストリビューションです。 これらには、Java SE アプリケーションを構築および実行するためのすべてのコンポーネントが含まれています。 Java JDK のインストールに関するページから JDK をインストールできます。

メジャー バージョンの更新プログラムは、Azure App Service の新しいランタイム オプションによって提供されます。 お客様は、App Service デプロイを構成することで Java のこれらの新しいバージョンに更新します。また、主要な更新プログラムをテストし、ニーズを満たしていることを確認する必要があります。

サポートされている JDK は、毎年 1 月、4 月、7 月、および 10 月の四半期ごとに自動的に適用されます。 Azure 上の Java の詳細については、こちらのサポート ドキュメントを参照してください。

セキュリティ更新プログラム

重大なセキュリティの脆弱性のパッチおよび修正プログラムは、Azul Systems から利用可能になり次第リリースされます。 "重大な" 脆弱性は、NIST Common Vulnerability Scoring System バージョン 2 で 9.0 以上の基本スコアにより定義されます。

Tomcat 8.0 は、2018 年 9 月 30 日にサポートが終了 (EOL) しました。 ランタイムは Azure App Service で引き続き機能しますが、Azure では Tomcat 8.0 へのセキュリティ更新プログラムは適用されません。 可能であれば、Tomcat 8.5 または 9.0 にアプリケーションを移行してください。 Azure App Service では、Tomcat 8.5 と 9.0 の両方を使用できます。 詳細については、Tomcat の公式 Web サイトを参照してください。

廃止と提供終了

サポートされている Java ランタイムが廃止予定の場合、影響を受けるランタイムを使用している Azure の開発者には、ランタイム終了の少なくとも 6 か月前までに廃止の通知が送信されます。

ローカル開発

開発者は、Azul のダウンロード サイトから運用エディションの Azul Zulu Enterprise JDK をローカルでのデプロイ用にダウンロードできます。

開発サポート

正規の Azure サポート プランを利用して Azure または Azure Stack 用の開発を行うとき、Microsoft では Azure がサポートする Azul Zulu JDK の製品サポートを利用できます。

次のステップ

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