はじめに

Azure Spring Apps には Basic, Standardという Tier もあります。 Enterprise 版では　VMWare Tanzu の機能を取り込んでおり、とても便利に使うことができるようになっています。ここでは Enterprise 版についてのみの Tips を書いていきます。

環境

spa-enterprise という名前の　　Azure Spring Apps を構築済みです。
リソースグループ名は rg-springapps です。
Azure Spring Apps の中に dotnetapp という　　Polyglot アプリを Azure Portal で作成済みです。

Azure CLI の準備

　Azure Spring Apps そのものの操作は Azure Portal から大抵のことはできますが、デプロイはAzure CLI が必要です。 Azure CLI をローカルにインストールするか Azure Portal の Clous Shell を使う必要があります。そして Azure Spring Apps の操作を Azure CLI で行うには az spring コマンドを使うのですが、このコマンドは既定ではインストールされていません。次のコマンドを使用してインストールします。

zsh

az extension add --name spring --upgrade
az provider register --namespace Microsoft.SaaS

これ以降、az spring コマンドを使う Tips を下記に記載しています。az コマンドのオプション名が長くて嫌になってしまいます。次の２つの Tips を覚えておいてください。

オプション名の短縮版を使う
- --service は　-s
- --resource-group は -g
- --name は　-n
リソースグループと Azure Spring Apps のオプション値の既定値をセットしてそもそも入力しないで済むようにする
- リソースグループの既定値をセットする（このディレクトリで叩く時だけ）
```
az config set defaults.group=MyResourceGroup --local
```
- Azure Spring Apps 名の既定値をセットする（このディレクトリで叩く時だけ）
```
 az config set defaults.spring=asa-enterprise --local
```

--local をつけておくと、そのディレクトリでコマンドを叩く時だけの既定値をセットしたことになります。値は ./.azure/configに保存されます。 --localをつけないと、設定値は~/.azure/configに保存されます。

Java の Spring Boot のアプリをデプロイする

ソースを Upload ＆デプロイする

Java ソースを Upload してビルド＆コンテナ化＆デプロイします。既定では JDK 11でビルドするので、JDK のバージョンを変えたい場合は次のように環境変数で JDK バージョンを指定する必要があります。

zsh

az spring app deploy \
-s spa-enterprise \
-g rg-springapps \
-n demo \
--build-env "BP_JVM_VERSION=17.*" \
--source-path .

jar ファイルをUpload＆デプロイする

特に難しいことはありませんが、Spring Boot Initializr でアプリを作ると、ルートに mvnw ファイルが作成されると思います。jar ファイルを作るときはこの mvnwを使って jar ファイルを作ることを強くお勧めします。
仮に同じバージョンの Maven がローカルにインストールされているとしても、mvnw を使って作った jar ファイルでないと Azure Spring Apps へのデプロイは失敗します。この不思議な挙動の理由はわかりませんが、あまり深く追求する必要はないでしょう。

zsh

az spring app deploy \
-s spa-enterprise \
-g rg-springapps \
-n demo \
--artifact-path target/demo-0.0.1-SNAPSHOT.jar

mvnwファイルを使う jar ファイルの作成

zsh

./mvnw clean package

独自コンテナレジストリを使う

　本番用の Azure Spring Apps を構築する場合は独自のコンテナレジストリを使用することを強くお勧めします。細かい話は「Azure Spring Apps Enterprise の Tips (Python版) - 初回デプロイに失敗した時は要注意」に記載しましたが、独自のコンテナレジストリを使用することでビルドとデプロイのプロセスが分離され、トラブル発生時の問題特定にとても役に立ちます。プロセスが分離されるだけでソースアップロードによるビルドは変わらず実行できますし、ビルド結果生成されたイメージが見える化されるため、管理が容易になります。

　Azure Spring Apps を作成後に独自コンテナレジストリを使うようにすることはできません。作成時に指定する必要があります。ここでは Azure Container Registry を使うように Azure Spring Apps Enterprise を作成する方法をご紹介します。

Azure Container Registryを作成してください。作成後、左メニューのアクセスキーを選択し、右側の管理者ユーザーを有効にします。

ログインサーバー、ユーザー名、パスワードを控えておきます。

Azure Spring Apps Enterprise を作成します。この時、VMWare Tanzu の設定画面でコンテナーレジストリの箇所で「独自のコンテナーレジストリを使用してビルドされたイメージを保存する」にチェックを入れます。そして、Azure Container Registry のログインサーバー、ユーザー名、パスワード情報を指定します。

ソースからビルドした結果をコンテナレジストリへ Push

　独自コンテナレジストリを使う場合、ビルドとデプロイのプロセスが分離されるため、まずビルドします。ソースを Upload ＆ビルドした結果をコンテナレジストリに Push するコマンドを叩きます。

zsh

az spring build-service build create \
-s spa-enterprise \
-g rg-springapps \
--name springapp \
--source-path .

初回のコマンドは上記のように

az spring build-service build create

ですが、2回目からは下記のように

az spring build-service build update

create を update に変更します。

ビルドが正常に終了すると、コンテナレジストリにイメージが格納されます。この時、最新イメージのタグ名は result となっています。latest ではないので注意しましょう。

また、独自コンテナレジストリを使用する場合はビルド結果を Azure Spring Apps が保持しています。過去のビルド結果を見ることも、ビルド結果そのものを削除することも可能です。

ビルド結果はこのように履歴が残っていきます。Managed のコンテナレジストリを使う場合であってもこのビルド結果は見れるようにして欲しいものですが、残念ながらそうはなっていません。

トラブル発生時はこのビルド結果を削除してやり直すことも手段の１つであることは覚えておくと良いでしょう。

コンテナイメージを指定してデプロイ

　ビルドした結果、イメージがコンテナレジストリに格納されたらデプロイをします。次のコマンドを使います。

zsh

az spring app deploy \
-s spa-enterprise \
-g rg-springapps \
--name springapp \
--container-image <イメージ名>:result \
--container-registry <コンテナレジストリサーバーアドレス> \
--registry-username <ユーザー名> \
--registry-password <パスワード>

ビルド時はコンテナレジストリを指定する必要がないのに、デプロイ時はコンテナレジストのアドレスどころかユーザー名とパスワードまで指定する必要があります。これはかなり使い勝手が悪いです。Managed IDを使うなどで指定が不要になると良いのですが。今後の更なる改善に期待したいところです。

分散トレース&カスタムログを出力する

Java アプリを使用時の場合、Azure Spring Apps では Appliaction Insights を自動的にセットアップ可能です。

Azure Spring Apps と Application Insights を紐づけておく必要があります。Azure Spring Apps を作成時に Application Insights 指定するか、作成後に指定するかどちらかになります。

紐づけられた Application Insights は、Azure Spring Apps のビルダーとバインドします。バインドは Azure Spring Apps 作成時に Appliation Insghts を指定した場合は自動的に行われています。

操作の詳細は Microsoft 公式ページをご確認ください。

このバインドによって、コンテナをビルドする時に自動的にApplication Insights の設定が適用されます。ソースで何かセットアップする必要はありません。

分散トレースには上記のセットアップが完了しているだけで自動的に可能になっています。

カスタムログを出力する

こちらも設定は一切不要です。以下のようにカスタムログを出力するようにソースを実装してみます。

HelloController.java

package com.example.demo;

+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class HelloController {

+    private static final Logger log = LoggerFactory.getLogger(HelloController.class);

    @GetMapping("/")
    public String Hello() {
+        log.info("Hello World is called");
        return "Hello World!";
    }
}

デプロイします。

zsh

az spring app deploy \
-n <YOUR_ASA_APP_NAME> \
--build-env "BP_JVM_VERSION=17.*" \
--source-path .

正常にデプロイが完了したら、何回か Endpoint にアクセスしておきます。そのあと、Log　が出力されていることを確認します。左メニューのログを選択し、クエリに AppPlatformLogsforSpring を入力し、実行ボタンをクリックします。

実行ログがいくつか出てくると思いますので、ログの一番左の「>」をクリックするとログの詳細が見れるように展開します。Logプロパティを見ると、カスタムログが出力されていることが確認できます。

Service Registry を使う

Azure Spring Apps Enterprise では　VMware Tanzu® Service Registry を Service Registry として使います。

セットアップ

　以前は Azure Spring Apps Enterprise を作成時に Service Registry を有効にしないと後から有効にはできなかったのですが、今は Azure Portal から有効・無効にすることができます。

　左メニューの「VMWare Tanzu コンポーネント」のサービスレジストリを選択し、右側の「管理」クリックします。新しくパネルが表示されます。パネルには「サービスレジストリを有効にする」チェックボックがありますので、このチェックボックスをON/OFFしてから下の適用ボタンをクリックします。

アプリケーションを Service Register に登録

　登録はとても簡単で Azure Portal からポチポチするだけです。左メニューの「VMWare Tanzu コンポーネント」のサービスレジストリを選択し、右側の「アプリをバインドしています」→「アプリをバインドします」をクリックします。

　ポップアップの中のドロップダウンから作成済みのアプリケーションを選択し、適用ボタンをクリックします。これでアプリケーションの Service Registry への登録は完了です。

Service Registry に登録されたアプリケーションを呼び出す

　公式 docs の説明では Eureka Client を Autowired アノテーションで付与したフィールドに Injection してもらうにも関わらずそれを使わない、というなかなかひどい実装例が記載してあります。実際には次のようにします。

java

@Autowired
private EurekaClient discoveryClient;

public String serviceUrl() {
    InstanceInfo instance = discoveryClient.getNextServerFromEureka("STORES", false);
    return instance.getHomePageUrl();
}

参考ページ

追記：実は Service Registry は不要？？

　Azure Spring Apps は裏側で Kubernetes が稼働しており、 Kubernetes は既定で Service Discovery を搭載しています。そのため、Service Registryへアプリケーションを登録しなくても　http://アプリ名で別アプリを呼び出すことが可能です。

　となると、 Service Registry は不要です。いちいちアプリケーションを登録する必要なんてありません。
複数ノードを跨る場合などに Service Registry は威力を発揮しますが、Azure Spring Apps ではそのような基盤を意識する必要がないため、わざわざ Serivce Registry を使う意味はほぼありません。