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

[アーティクル]
03/11/2023

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"

アプリのデプロイ

ビルドツール

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 のドキュメントを参照してください。

アプリのログ記録

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 に転送することができます。

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 でアプリ認証を設定します。そこから、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 オブジェクトによって、各要求の種類がその種類の要求のコレクションにマップされます。以下のコードで、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 を構成する

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

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 インスタンスにアップロードするには、次の手順を行います。

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

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

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 ファイルの例は次のとおりです。この 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" 
               keystroreFile="${{user.home}}/.keystore" keystorePass="changeit"
               clientAuth="false" sslProtocol="TLS" />
  </xsl:template>

</xsl:stylesheet>

構成を完了する

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

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 資格情報を取得するための手順に従ってください。
サーバーレベルのデータソースを作成した場合は、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 アプリが仮想ネットワークに統合されている場合は、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 のハードウェアレベルにスケールアップする必要があります。

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

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

OpenJDK の Microsoft と Adoptium のビルドは、App Service for Java 8、11、および 17 で提供され、サポートされています。これらのバイナリは、Azure 向け OpenJDK の、実稼働可能なマルチプラットフォームの無料ディストリビューションとして提供されています。これらには、Java SE アプリケーションを構築および実行するためのすべてのコンポーネントが含まれています。ローカル開発またはテストの場合は、ダウンロードページから OpenJDK の Microsoft ビルドをインストールできます。次の表に、2022 年 1 月の App Service プラットフォームリリースに含まれる新しい Java バージョンを示します。

Java バージョン	Linux	Windows
Java 8	1.8.0_312 (Adoptium) *	1.8.0_312 (Adoptium)
Java 11	11.0.13 (Microsoft)	11.0.13 (Microsoft)
Java 17	17.0.1 (Microsoft)	17.0.1 (Microsoft)

* この後のリリースでは、Java 8 on Linux は OpenJDK の Adoptium ビルドから配布されます。

古いマイナーバージョンの Java にピン留めされている場合は、Azul Systems により提供されている非推奨の Azul Zulu for Azure バイナリをサイトで使用している可能性があります。これらのバイナリは引き続きサイトで使用できますが、セキュリティ修正プログラムや機能強化は新しいバージョンの OpenJDK でのみ使用できます。そのため、Web Apps を新しいバージョンの Java に定期的に更新することをお勧めします。

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

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

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

重大なセキュリティの脆弱性のパッチおよび修正プログラムは、OpenJDK の Microsoft ビルドで利用可能になり次第リリースされます。 "重大な" 脆弱性は、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 7 のコミュニティサポートは 2022 年 7 月 29 日に終了し、その時点で Java 7 は App Service から削除されます。 Java 7 で実行される Web アプリがある場合は、7 月 29 日より前に Java 8 または 11 にアップグレードしてください。

廃止と提供終了

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

ローカル開発

開発者は、ダウンロードサイトからローカル開発用の Microsoft Build of OpenJDK をダウンロードできます。

開発サポート

正規の Azure サポートプランを利用して Azure または Azure Stack 用の開発を行う場合、Microsoft による OpenJDK の Microsoft ビルドの製品サポートが利用できます。

次のステップ

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

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

Java バージョンを表示する

アプリのデプロイ

ビルド ツール

Maven

Gradle

IDE

Kudu API

Java SE

Tomcat

JBoss EAP

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

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

SSH コンソール アクセス

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

Java Profiler

アプリのログ記録

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

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

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 プラン

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

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

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

廃止と提供終了

ローカル開発

開発サポート

次のステップ

その他のリソース

その他のリソース

ビルドツール

SSH コンソールアクセス

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

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

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

Java キーストアを使用する

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

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

データソースの構成

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

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

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

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

JBoss EAP データソース

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

自動スケールルール

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