Spring Boot 2.4.0についてメモ

Spring Java Kubernetes

はじめに

先週、(2020/11/12)にSpring Boot 2.4が出ましたが、どんなのが出たのかまとめて、なんとなく違いを把握おこうと思います。
基本的にはリリースブログとRelease Notesの内容を個人的に気になったところを少し深ぼって、自分の理解をまとめようと思うので、正確な情報は本家のブログやそれに付随する記事等をご参照ください（なるべく、情報ソースのリンクはつけます）。
ちなみに、ドキュメントに書かれた変更点を自分の理解でまとめたものなので、基本的に機能に対しては動作検証などは行っておりません。

Spring Boot 2.4.0変更点

このブログでは以下のような変更点についてまとめます。

  • バージョニングスキーマの変更
  • 設定ファイルのプロセッサ変更
  • Volume Mounted Config Directory Trees
  • Startupエンドポイントのサポート
  • Docker/Buildpack Support
  • spring-boot-starter-testからJUnit 5’s Vintage Engineを削除
  • Java 15のサポート

この他、すべての変更点に関してはRelease Notesを参照してください。

バージョニングスキーマの変更

まず、今回のバージョンから新しいバージョンスキーマを利用するようです。
なので、今までは、2.3.4.RELEASEなどをPom等に記載していたと思いますが、今回のリリースからは2.4.0と記載するようになってます。
Spring Projectのバージョニング変更の詳細はこちらをご確認ください。

設定ファイルのプロセッサの変更

2.4よりapplication.popertiesやapplication.ymlの設定ファイルのプロセッシングロジックの見直しが行われているようです。新しいものはよりシンプルで、外部からの設定をより合理的な方法でロードするようになっています。
基本的には今までの設定ファイルを使えるようですが、例えば以下のような複雑な設定を行っている場合記述方法が変わっていたりするので注意が必要です。

  • spring.profiles<.*>のプロパティを利用している
  • Muti-document YAML Orderingを利用している

少しだけ注意点をまとめると、 プロファイルを利用している場合も注意が必要で、Jarの外部からapplication.popertiesを読み込む場合Jar内部のapplication-<profile>.popertiesを上書かないようになっているので気をつける必要があります。
また、Muti-document YAML Orderingを利用している場合(Yamlファイルを---セパレータで区切っている場合)その設定の反映順序が変わっています。2.3以前はプロファイルのアクティベーションの順序だったのが、Yaml内で宣言された順序で反映されるようになります。
詳細な、マイグレーションガイドについてはこちらをご覧ください。

ちなみに2.3以前のプロセッサで動かすことも可能で、その場合場spring.config.use-legacy-processing=trueを設定する必要があるようです。

Volume Mounted Config Directory Trees

spring.config.importプロバティが新しく追加され、Kubernetesなどの環境でVolumeマウントされたディレクトリ等からの設定をインポートすることが可能となりました。
spring.config.importを使った設定ファイルの読み込みは以下の2つのパターンで行なうことができます。

  • すべての設定をコンテンツとして含む単一な（もしくは複数の）設定ファイルの読み込み
  • ディレクトリーツリーに配置された、ファイル名がkeyでコンテンツがvalueとなるような設定の読み込み

前者については、例えば下記のように設定を行った場合、

spring.config.import=optional:file:./dev.properties

カレントディレクトリにdev.propertiesが存在すれば、その設定が既存の設定の上書きで反映されるようになります。このファイルは、複数指定することが可能で記述された順番で設定が読み込まれます。同じ設定を複数のファイルで行っている場合はあと勝ちになるようです。
ちなみにoptional:をつけることでファイルが存在しない場合になにもせずにスキップされるようになります。

後者についてはconfigtree:という表現を用いることでインポートが可能となります。 例えば、以下のようなディレクトリーツリーがあったとします。

etc/
  config/
    myapp/
      username
      password

ファイルのusernameとpasswordの中身が読み込みたい値です。
上記のディレクトリツリーに対して、以下のように設定を記述してやると値を読み込むことができます。

spring.config.import=optional:configtree:/etc/config/

この場合では、myapp.usernameとmyapp.passwordと言う設定をインジェクト（もしくはアサート）するようになります。
また、複数のディレクトリツリーを1つの親ディレクトリから読み込みたい場合などに置いてワイルドカードショートカットを利用して以下のように設定することができます。

spring.config.import=optional:configtree:/etc/config/*/

この場合、ディレクトリツリーが以下のようになっていると想定すると、

etc/
  config/
    dbconfig/
      db/
        username
        password
    mqconfig/
      mq/
        username
        password

それぞれ、db.username、db.password、mq.username、mq.passwordのプロパティが追加されるようになります。

この機能は、主にKubernetes環境に置いての利用を想定されているようです。ComfigMap等の書き換えが行われたらその設定が反映されるようになると思われます。 (後からご指摘頂いたのですが、こちら間違えでした。書き換えが行われたとしても設定が動的に反映されなかったことを手元の環境で確認してます。)

ActuatorのStartupエンドポイントのサポート

Kubernetes 1.18以降では Start Up Probeという機能がベータから正式リリースされています。
これは、Liveness ProbeやReadiness Probeと並んで追加されたもので、コンテナ起動時にのみ使用されるProbeです。
自分の理解のために、少し本筋から外れて説明すると、起動の遅いアプリケーションナなどに対して、コンテナのデットロックに対する迅速な反応を損なわずにLiveness Probeを設定するのが難しい場合があります。起動が遅いアプリケーションに対応してLiveness Probeを長く設定してしまうと、その分コンテナの再起動が遅れてしまうからです。これに対して、Startup Probeはコンテナ起動時のみに利用されるLiveness Probeの機能を提供することによって既存の問題に対してより簡単な解決方法を提供しています。
このStartup Probeに対して、Spring Actuatorでは専用のエンドポイントが追加されています。
(こちらもあとから指摘いただいたのですが、Startup Probeとは関係が無かったよです。)

アプリケーションの起動時の情報を取得するためのエンドポイントが新たに追加されています。
このエンドポイントでは、予想よりも起動が遅いBeanの情報などのスタートアップに関する情報を取得することができます。
取得できる情報の詳細に関してはこちらをご覧ください。

Docker/Buildpack Support

イメージの公開

Mavenプラグインのspring-boot:build-imageゴールやbootBuildImageタスクを用いて、Dockerレジストリにイメージをこう買うすることが可能になったようです。
例えば、Mavenでは以下のような設定を追加してレジストリを登録しておきます。

<project>
    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <configuration>
                    <image>
                        <name>docker.example.com/library/${project.artifactId}</name>
                        <publish>true</publish>
                    </image>
                    <docker>
                        <publishRegistry>
                            <username>user</username>
                            <password>secret</password>
                            <url>https://docker.example.com/v1/</url>
                            <email>user@example.com</email>
                        </publishRegistry>
                    </docker>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

ちなみにレジストリへの公開は以下のようなコマンドを用いても行なうことが可能です。

$ mvn spring-boot:build-image -Dspring-boot.build-image.imageName=docker.example.com/library/my-app:v1 -Dspring-boot.build-image.publish=true

認証

Spring BootのビルドパックサポートにおいてプライベートDockerレジストリに対する、username/password認証とトークン認証のどちらもサポートされるようになりました。
詳細に関してはこちらを参考にしてください。

spring-boot-starter-testからJUnit 5’s Vintage Engineを削除

spring-boot-starter-testからJUnit 5’s Vintage Engine(Junit4の記述で、Junit5のエンジンを利用する際に使われるエンジン)が削除されています。このため、アップグレードを行った際に、org.junit.Testがエラーで落ちるようになります。
もし、2.4以降でも、Vintage Engineを利用したい場合は以下のような依存を追加してやる必要があります。

<dependency>
    <groupId>org.junit.vintage</groupId>
    <artifactId>junit-vintage-engine</artifactId>
    <scope>test</scope>
    <exclusions>
        <exclusion>
            <groupId>org.hamcrest</groupId>
            <artifactId>hamcrest-core</artifactId>
        </exclusion>
    </exclusions>
</dependency>

Java 15のサポート

言葉通りです。
Java 8と11にも互換性があります。

依存のアップグレード

依存がアップグレードされています。詳細はこちらを確認ください。

参考資料