Spring Boot 2.4.x の Web アプリを 2.5.x へバージョンアップする ( その１３ )( Spring Boot を 2.5.4 → 2.5.5 へ、Eclipse Adoptium OpenJDK（Eclipse Temurin） を 11.0.12+7 → 17+35 へバージョンアップする )
概要
記事一覧はこちらです。
- 今回の手順で確認できるのは以下の内容です。
参照したサイト・書籍
目次
- Spring Boot を 2.5.4 → 2.5.5 へバージョンアップする
- Eclipse Adoptium OpenJDK（Eclipse Temurin） を 11.0.12+7 → 17+35 へバージョンアップする
- build タスク時に pmdMain タスクと test タスクで出力された警告を確認する
手順
Spring Boot を 2.5.4 → 2.5.5 へバージョンアップする
build.gradle の以下の点を変更します。
buildscript {
ext {
group "ksbysample"
version "2.5.5"
}
repositories {
mavenCentral()
maven { url "https://repo.spring.io/release/" }
gradlePluginPortal()
}
dependencies {
// for doma-codegen-plugin
classpath "org.postgresql:postgresql:42.2.24"
}
}
plugins {
id "java"
id "eclipse"
id "idea"
id "org.springframework.boot" version "2.5.5"
id "io.spring.dependency-management" version "1.0.11.RELEASE"
id "groovy"
id "checkstyle"
id "com.github.spotbugs" version "4.7.3"
id "pmd"
id "net.ltgt.errorprone" version "2.0.2"
id "com.gorylenko.gradle-git-properties" version "2.3.1"
id "org.seasar.doma.codegen" version "1.4.1"
}
..........
dependencyManagement {
imports {
// bomProperty に指定可能な property は以下の URL の BOM に記述がある
// https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-dependencies/2.5.4/spring-boot-dependencies-2.5.4.pom
mavenBom(org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES) {
// Spring Boot の BOM に定義されているバージョンから変更する場合には、ここに以下のように記述する
// bomProperty "thymeleaf.version", "3.0.9.RELEASE"
}
mavenBom("org.junit:junit-bom:5.8.1")
}
}
dependencies {
def spockVersion = "2.0-groovy-3.0"
def jdbcDriver = "org.postgresql:postgresql:42.2.24"
def domaVersion = "2.49.0"
def lombokVersion = "1.18.20"
def errorproneVersion = "2.9.0"
..........
Spring Boot 2.5.5 へのバージョンアップとして以下の点を変更します。
- buildscript block の以下の点を変更します。
version "2.5.4"→version "2.5.5"
- plugins block の以下の点を変更します。
id "org.springframework.boot" version "2.5.4"→id "org.springframework.boot" version "2.5.5"
各種ライブラリのバージョンアップとして以下の点を変更します。
- buildscript block の以下の点を変更します。
classpath "org.postgresql:postgresql:42.2.23"→classpath "org.postgresql:postgresql:42.2.24"
- dependencyManagement block の以下の点を変更します。
mavenBom("org.junit:junit-bom:5.7.2")→mavenBom("org.junit:junit-bom:5.8.1")
- dependencies block の以下の点を変更します。
def jdbcDriver = "org.postgresql:postgresql:42.2.23"→def jdbcDriver = "org.postgresql:postgresql:42.2.24"def domaVersion = "2.47.1"→def domaVersion = "2.49.0"
Gradle Tool Window の左上にある「Reload All Gradle Projects」ボタンをクリックして更新します。
clean タスク実行 → Rebuild Project 実行 → build タスクを実行すると "BUILD SUCCESSFUL" のメッセージが出力されました。
Eclipse Adoptium OpenJDK（Eclipse Temurin） を 11.0.12+7 → 17+35 へバージョンアップする
IntelliJ IDEA を終了させます。
https://adoptium.net/index.html から OpenJDK17-jdk_x64_windows_hotspot_17_35.msi をダウンロードします。
インストール時に削除されるかもしれないので D:\Java\jdk-11.0.12.7-hotspot → D:\Java\jdk-11.0.12.7-hotspotx にリネームします。
インストーラーを実行して D:\java\jdk-17.0.0.35-hotspot へインストールした後、環境変数 JAVA_HOME のパスを D:\java\jdk-17.0.0.35-hotspot へ変更します。
コマンドプロンプトから
java -versionを実行し、17+35に変更されていることを確認します。
D:\Java\jdk-11.0.12.7-hotspotx → D:\Java\jdk-11.0.12.7-hotspot に戻します。
IntelliJ IDEA を起動します。
「Welcome to IntelliJ IDEA」ダイアログで ksbysample-webapp-lending プロジェクトを開いて、プロジェクトが使用する JDK を 11.0.12+7 に変更します。
IntelliJ IDEA のメイン画面が開いたら、メニューから「File」-「Project Structure...」を選択します。
「Project Structure」ダイアログが表示されます。「Project SDK」で D:\Java\jdk-17.0.0.35-hotspot を選択します（なぜか２行表示されています）。
「Experimental Feature Alert」のダイアログが表示されるので「Accept」ボタンをクリックします。
「Project SDK」の「Edit」ボタンをクリックします。
「Project Structure」ダイアログが表示されます。画面左側で「Platform Settings」-「SDKs」を選択して、中央のリストから「11.0.12.7」を選択した後、リストの上の「－」ボタンをクリックして削除します。
中央のリストから「17」を選択した後、"17" → "17+35" へ変更します。
「OK」ボタンをクリックして「Project Structure for New Projects」ダイアログを閉じます。
メイン画面に戻ると画面右下に「Indexing...」の表示が出るので、終了するまで待ちます。
build.gradle の sourceCompatibility、targetCompatibility の設定を JavaVersion.VERSION_17 に変更します。
sourceCompatibility = JavaVersion.VERSION_11→sourceCompatibility = JavaVersion.VERSION_17targetCompatibility = JavaVersion.VERSION_11→targetCompatibility = JavaVersion.VERSION_17
Gradle Tool Window の左上にある「Refresh all Gradle projects」ボタンをクリックして更新します。
clean タスク実行 → Rebuild Project 実行 → build タスクを実行すると "BUILD SUCCESSFUL" のメッセージが出力されますが、pmdMain タスクと test タスクで警告が出力されました。
pmdMain タスクで出力された警告は以下のものでした。
- WARNING: A terminally deprecated method in java.lang.System has been called
- WARNING: System::setSecurityManager has been called by edu.umd.cs.findbugs.ba.jsr305.TypeQualifierValue (file:/C:/Users/root/.gradle/caches/modules-2/files-2.1/com.github.spotbugs/spotbugs/4.4.0/83d0d8856de551bb4aa2f4b815a61b606c93acf/spotbugs-4.4.0.jar)
- WARNING: Please consider reporting this to the maintainers of edu.umd.cs.findbugs.ba.jsr305.TypeQualifierValue
- WARNING: System::setSecurityManager will be removed in a future release
test タスクで出力された警告は以下のものでした。
- OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended
調査は後回しにして先に進めます。
Project Tool Window で src/test でコンテキストメニューを表示して「More Run/Debug」-「Run 'All Tests' with Coverage」を選択し、テストが全て成功することを確認します。
build タスク時に pmdMain タスクと test タスクで出力された警告を確認する
WARNING: System::setSecurityManager will be removed in a future release
pmdMain タスクで出力された警告ですが、将来 Security Manager を廃止するために非推奨になっているためでした（https://openjdk.java.net/jeps/411 参照）。 ログを見ると spotbugs-4.4.0.jar で System::setSecurityManager が呼び出されているので PMD ではなく SpotBugs が原因でした。
SpotBugs は 4.4.1 がリリースされていたのでバージョンアップしてみましたが、警告が出力される状況は解消されなかったので、現時点では 4.4 のままとし SpotBugs の対応を待つことにします。
OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended
以下の URL にこの警告に関する記述があり、
- How to avoid "Sharing is only supported for boot loader classes because bootstrap classpath has been appended" warning during debug with Java 11?
https://stackoverflow.com/questions/54205486/how-to-avoid-sharing-is-only-supported-for-boot-loader-classes-because-bootstra - Improve Launch Times On Java 13 With Application Class-Data Sharing https://nipafx.dev/java-application-class-data-sharing/
test タスク実行時の jvmArgs に -Xshare:off オプションを追加すれば警告が出力されないようにはできますが、気にするような警告ではないようなので、今は出力されたままにすることにします。
Java 17 は特にエラーも出ずに切り替えることができました。
ただし Lombok は現在使用している 1.18.20 ではまだ PLATFORM: JDK16 support added. 止まりで正式に Java 17 対応を表明してはいないので（https://projectlombok.org/changelog 参照）、Lombok を使うなら Java 17 の利用は Lombok の正式対応を待った方が良さそうです。
Gradle もまだ Java 17 には正式に対応していませんでした（https://github.com/gradle/gradle/issues/16857 参照）。7.3 で対応するそうです。
履歴
2021/09/26
初版発行。
IntelliJ IDEA を 2021.2.1 → 2021.2.2 へバージョンアップ
IntelliJ IDEA を 2021.2.1 → 2021.2.2 へバージョンアップする
IntelliJ IDEA の 2021.2.2 がリリースされているのでバージョンアップします。
- IntelliJ IDEA 2021.2.2 Is Available
https://blog.jetbrains.com/idea/2021/09/intellij-idea-2021-2-2/
※ksbysample-webapp-lending プロジェクトを開いた状態でバージョンアップしています。
IntelliJ IDEA のメインメニューから「Help」-「Check for Updates...」を選択します。
「IntelliJ IDEA and Plugin Updates」ダイアログが表示されます。右下に「Update and Restart」ボタンが表示されていますので、「Update and Restart」ボタンをクリックします。
Plugin の update も表示されました。このまま「Update」ボタンをクリックします。
Patch がダウンロードされて IntelliJ IDEA が再起動します。
IntelliJ IDEA が起動すると画面下部に「Indexing」のメッセージが表示されますので、終了するまで待機します。
IntelliJ IDEA のメインメニューから「Help」-「About」を選択し、2021.2.2 へバージョンアップされていることを確認します。
clean タスク実行 → Rebuild Project 実行 → build タスクを実行して、"BUILD SUCCESSFUL" のメッセージが出力されることを確認します。
Project Tool Window で src/test でコンテキストメニューを表示して「More Run/Debug」-「Run 'All Tests' with Coverage」を選択し、テストが全て成功することを確認します。
Spring Boot 2.4.x の Web アプリを 2.5.x へバージョンアップする ( その１２ )( build.gradle から --add-opens=.....=ALL-UNNAMED の記述を削除する )
概要
記事一覧はこちらです。
Spring Boot 2.4.x の Web アプリを 2.5.x へバージョンアップする ( その１１ )( Docker で複数の Tomcat を起動して動作確認する ) の続きです。
- 今回の手順で確認できるのは以下の内容です。
- build.gradle に不要になった
-add-opens=.....=ALL-UNNAMEDの記述が残っていたので削除します。
- build.gradle に不要になった
参照したサイト・書籍
目次
手順
build.gradle を変更する
build.gradle を見直していたところ、以下の記述が残っていることに気づきました。今回のバージョンアップで groovy が 3系になって powermock も依存関係から削除しており、このオプションは不要になっているはずなので削除します。
// JDK 11 に変更後、test タスク実行時に groovy と powermock が JDKの内部部分にアクセスするためにコードでリフレクションを使用 // していて WARNING が出るため、JVM の起動時オプションの --add-opens を指定して WARNING が出ないようにする def jvmArgsAddOpens = [ "--add-opens=java.base/java.io=ALL-UNNAMED", "--add-opens=java.base/java.lang=ALL-UNNAMED", "--add-opens=java.base/java.lang.invoke=ALL-UNNAMED", "--add-opens=java.base/java.lang.ref=ALL-UNNAMED", "--add-opens=java.base/java.lang.reflect=ALL-UNNAMED", "--add-opens=java.base/java.net=ALL-UNNAMED", "--add-opens=java.base/java.security=ALL-UNNAMED", "--add-opens=java.base/java.util=ALL-UNNAMED" ]
build.gradle の以下の点を変更します。
test {
jvmArgs = jvmArgsForTask +
["-Dspring.profiles.active=unittest"]
// for JUnit 5
useJUnitPlatform()
testLogging {
afterSuite printTestCount
}
}
def jvmArgsAddOpens = [ "--add-opens=java.base/java.io=ALL-UNNAMED", ... ]の記述を削除します。- test タスクの jvmArgs の記述から
jvmArgsAddOpens +を削除します。
clean タスク実行 → Rebuild Project 実行 → build タスクを実行すると "BUILD SUCCESSFUL" のメッセージが出力されました。
履歴
2021/09/26
初版発行。
Spring Boot 2.4.x の Web アプリを 2.5.x へバージョンアップする ( 感想 )
記事一覧はこちらです。
Spring Boot 2.5 Release Notes には結構記述がありますが、アプリに直接影響が出る変更がなく今回もバージョンアップするだけで終わりました。
Gradle 7.x、Spock 2.x、Groovy 3.x へのバージョンアップは少し時間がかかるかもしれないと思っていましたが、ほとんど問題は発生しませんでした。
今回のバージョンアップには関係ありませんが、今年の 9/1～9/3 に開催された Spring One で 2022年4Q にリリース予定の Spring Framework 6 + Spring Boot 3 から Jakarta EE 9 がベースラインになるとのアナウンスがありました（
javax.*→jakarta.*パッケージへ切り替えるのも Spring Boot 3 からになる模様）。IntelliJ IDEA は 2021年7月にリリースされた 2021.2 でjavax.*→jakarta.*パッケージへの移行を支援する「Automatic migration from Java EE to Jakarta EE」の機能がリリースされました。
「Run」ボタンをクリックすると
javax.*パッケージが使用されている箇所を洗い出してくれます。
Spring Boot 3 にバージョンアップする時にこの機能を使うと思いますが、１年以上前にリリースされた機能を覚えていられるのかな。。。
javax.*→jakarta.*パッケージへの切替については Support for Jakarta EE 9 (annotations and interfaces in jakarta.* namespace) で議論されていますので、しばらくの間は要チェックでしょう。また、Unable to upgrade to latest Tomcat - Spring framework and RestEasy don't support Tomcat 10 や http://tomcat.apache.org/migration-10.html を見ると Tomcat 10 にバージョンアップするには jakarta.* パッケージへの変更が必須のようです。Embedded Tomcat ならば Spring Boot 3 になるまでは Tomcat 10 は使用されず問題にならないかもしれませんが、Tomcat 10 のサーバを別途構築して war ファイルを作成して deploy しなければならない場合には Spring Boot 3 になるまで deploy できないことに気づかないかもしれません。後者の環境で deploy したことがないので本当にそうなのかは分かりませんが、
jakarta.*パッケージの利用有無は１年くらいは要注意でしょう。
Spring Boot 2.4.x の Web アプリを 2.5.x へバージョンアップする ( その１１ )( Docker で複数の Tomcat を起動して動作確認する )
概要
記事一覧はこちらです。
Spring Boot 2.4.x の Web アプリを 2.5.x へバージョンアップする ( その１０ )( Docker コンテナの image をバージョンアップする ) の続きです。
- 今回の手順で確認できるのは以下の内容です。
- Build OCI images with Cloud Native Buildpacks の機能で作成した Docker image で Web アプリを実行して動作確認します。
参照したサイト・書籍
目次
- clean タスク実行 → Rebuild Project 実行 → build タスクを実行する
- bootBuildImage タスクを実行する
- docker-compose.app.yml を変更する
- Docker で複数の Tomcat を起動して動作確認する
- Docker Compose V2 では
--compatibilityオプションが無くなったのか。。。と思ったが、docker-compose -f docker-compose.app.yml up -dで app コンテナが３つ起動する
手順
clean タスク実行 → Rebuild Project 実行 → build タスクを実行する
clean タスク実行 → Rebuild Project 実行 → build タスクを実行して BUILD SUCCESSFUL のメッセージが出力されることを確認します。
bootBuildImage タスクを実行する
bootBuildImage タスクを実行して Successfully built image 'docker.io/library/ksbysample-webapp-lending:2.5.4' と BUILD SUCCESSFUL のメッセージが出力されることを確認します。
docker-compose.app.yml を変更する
docker-compose.app.yml を以下のように変更します。
app: image: ksbysample-webapp-lending:2.5.4 environment: - JAVA_TOOL_OPTIONS=-Dspring.profiles.active=product -Dlogging.appender=CONSOLE - SPRING_DATASOURCE_HIKARI_JDBC_URL=jdbc:postgresql://postgresql/ksbylending - SPRING_MAIL_HOST=mail-server - SPRING_RABBITMQ_HOST=haproxy deploy: mode: replicated replicas: 3 # entrypoint: /bin/bash # stdin_open: true # tty: true
image: ksbysample-webapp-lending:2.4.3→image: ksbysample-webapp-lending:2.5.4に変更します。
Docker で複数の Tomcat を起動して動作確認する
docker-compose -f docker-compose.mail.yml up -d、docker-compose -f docker-compose.app.yml --compatibility up -d コマンドを実行します。Docker の「Experimental Features」の「Use Docker Compose V2 release candidate」を有効にしていたのですが、V2 では --compatibility オプションが無くなっているようです。「Use Docker Compose V2 release candidate」を無効にすることにします。
http://localhost:8080/haproxy?stats にアクセスして全てのインスタンスが緑色になるまで待ちます。
以下の手順で動作確認します ( 画面キャプチャは省略します )。
- ブラウザを起動して http://localhost:8080/ にアクセスしてログイン画面を表示します。tanaka.taro@sample.com / taro でログインします。
- 検索対象図書館登録画面が表示されます。"東京都" で検索した後、一覧表示されている図書館から「国立国会図書館東京本館」を選択します。
- ログアウトします。
- ログイン画面に戻るので suzuki.hanako@test.co.jp / hanako でログインします。
- 貸出希望書籍 CSV ファイルアップロード画面が表示されます。以下の内容が記述された CSV ファイルをアップロードします。
"ISBN","書名"
"978-4-7741-6366-6","GitHub実践入門"
"978-4-7741-5377-3","JUnit実践入門"
"978-4-7973-8014-9","Java最強リファレンス"
"978-4-7973-4778-4","アジャイルソフトウェア開発の奥義"
"978-4-87311-704-1","Javaによる関数型プログラミング" - 「貸出状況を確認しました」のメールが送信されるので、メールに記述されている URL にアクセスします。
- 貸出申請画面が表示されます。３冊程「申請する」を選択して申請します。
- ログアウトします。
- 「貸出申請がありました」のメールが送信されるので、メールに記述されている URL にアクセスします。ログイン画面が表示されるので、tanaka.taro@sample.com / taro でログインします。
- 貸出承認画面が表示されます。「承認」あるいは「却下」を選択して確定させます。
- ログアウトします。
- 「貸出申請が承認・却下されました」のメールが送信されるので、メールに記述されている URL にアクセスします。ログイン画面が表示されるので、suzuki.hanako@test.co.jp / hanako でログインします。
- 貸出申請結果確認画面が表示されるので内容を確認します。
動作確認は特に問題ありませんでした。
docker-compose -f docker-compose.app.yml --compatibility down、docker-compose -f docker-compose.mail.yml down、docker-compose down コマンドを実行してコンテナを停止します。
Docker Compose V2 では --compatibility オプションが無くなったのか。。。と思ったが、docker-compose -f docker-compose.app.yml up -d で app コンテナが３つ起動する
Docker Compose V2 では --compatibility オプションが無くなって残念。。。と思ったのですが、試しに --compatibility オプションを削除して docker-compose -f docker-compose.app.yml up -d コマンドを実行してみたところ app コンテナが３つ起動しました。--compatibility オプションなして同じコンテナの複数起動がサポートされるようになったようです。
履歴
2021/09/12
初版発行。
AdoptOpenJDK 11.0.11+9 を Eclipse Adoptium OpenJDK 11.0.12+7 へ、IntelliJ IDEA を 2021.1.3 → 2021.2.1 へ、Git for Windows を 2.32.0.2 → 2.33.0.2 へバージョンアップ
AdoptOpenJDK 11.0.11+9 を Eclipse Adoptium OpenJDK 11.0.12+7 へバージョンアップする
※ksbysample-webapp-lending プロジェクトを開いた状態でバージョンアップしています。
AdoptOpenJDK は Eclipse Adoptium へ 2021年8月に移行されましたので、Eclipse Adoptium OpenJDK 11.0.12+7 へバージョンアップします。
https://adoptium.net/index.html から OpenJDK11U-jdk_x64_windows_hotspot_11.0.12_7.msi をダウンロードします。
インストール時に削除されるかもしれないので D:\Java\jdk-11.0.11.9-hotspot → D:\Java\jdk-11.0.11.9-hotspotx にリネームします。
インストーラーを実行して D:\Java\jdk-11.0.12.7-hotspot へインストールした後、環境変数 JAVA_HOME のパスを D:\Java\jdk-11.0.12.7-hotspot へ変更します。
コマンドプロンプトから
java -versionを実行し、11.0.12に変更されていることを確認します。
D:\Java\jdk-11.0.11.9-hotspotx → D:\Java\jdk-11.0.11.9-hotspot に戻します。
IntelliJ IDEA を再起動します。
「Welcome to IntelliJ IDEA」ダイアログで ksbysample-webapp-lending プロジェクトを開いて、プロジェクトが使用する JDK を 11.0.12+7 に変更します。
IntelliJ IDEA のメイン画面が開いたら、メニューから「File」-「Project Structure...」を選択します。
「Project Structure」ダイアログが表示されます。「Project SDK」で D:\Java\jdk-11.0.12.7-hotspot を選択します。
「Project SDK」の「Edit」ボタンをクリックします。
「Project Structure」ダイアログが表示されます。画面左側で「Platform Settings」-「SDKs」を選択して、中央のリストから「11.0.11.9」を選択した後、リストの上の「－」ボタンをクリックして削除します。
中央のリストから「11」を選択した後、"11" → "11.0.12+7" へ変更します。
「OK」ボタンをクリックして「Project Structure for New Projects」ダイアログを閉じます。
メイン画面に戻ると画面右下に「Indexing...」の表示が出るので、終了するまで待ちます。
Gradle Tool Window の左上にある「Refresh all Gradle projects」ボタンをクリックして更新します。
clean タスク実行 → Rebuild Project 実行 → build タスクを実行して、"BUILD SUCCESSFUL" のメッセージが出力されることを確認します。
Project Tool Window で src/test でコンテキストメニューを表示して「More Run/Debug」-「Run 'All Tests' with Coverage」を選択し、テストが全て成功することを確認します。
特に問題は発生しませんでした。Eclipse Adoptium OpenJDK 11.0.12+7 で開発を進めます。
IntelliJ IDEA を 2021.1.3 → 2021.2.1 へバージョンアップする
IntelliJ IDEA の 2021.2.1 がリリースされているのでバージョンアップします。
- IntelliJ IDEA 2021.2 Is Out!
https://blog.jetbrains.com/idea/2021/07/intellij-idea-2021-2/ - IntelliJ IDEA 2021.2.1 Is Available
https://blog.jetbrains.com/idea/2021/08/intellij-idea-2021-2-1/
※ksbysample-webapp-lending プロジェクトを開いた状態でバージョンアップしています。
IntelliJ IDEA のメインメニューから「Help」-「Check for Updates...」を選択します。
「IntelliJ IDEA and Plugin Updates」ダイアログが表示されます。右下に「Update and Restart」ボタンが表示されていますので、「Update and Restart」ボタンをクリックします。
Plugin の update も表示されました。このまま「Update」ボタンをクリックします。
Patch がダウンロードされて IntelliJ IDEA が再起動します。
IntelliJ IDEA が起動すると画面下部に「Indexing」のメッセージが表示されますので、終了するまで待機します。
IntelliJ IDEA のメインメニューから「Help」-「About」を選択し、2021.2.1 へバージョンアップされていることを確認します。
clean タスク実行 → Rebuild Project 実行 → build タスクを実行して、"BUILD SUCCESSFUL" のメッセージが出力されることを確認します。
Project Tool Window で src/test でコンテキストメニューを表示して「More Run/Debug」-「Run 'All Tests' with Coverage」を選択し、テストが全て成功することを確認します。
最後にメジャーバージョンアップなので以前のバージョンの C:\Users\root\AppData\Local\JetBrains\IntelliJIdea2021.1 を削除します。
Git for Windows を 2.32.0.2 → 2.33.0.2 へバージョンアップする
Git for Windows の 2.33.0.2 がリリースされていたのでバージョンアップします。
https://gitforwindows.org/ の「Download」ボタンをクリックして Git-2.33.0.2-64-bit.exe をダウンロードします。
Git-2.33.0.2-64-bit.exe を実行します。
「Git 2.33.0.2 Setup」ダイアログが表示されます。インストーラーの画面を一通り見たいので「Only show new options」のチェックを外してから [Next >] ボタンをクリックします。
「Select Components」画面が表示されます。「Git LFS(Large File Support)」だけチェックした状態で [Next >]ボタンをクリックします。
「Choosing the default editor used by Git」画面が表示されます。「Use Vim (the ubiquitous text editor) as Git's default editor」が選択された状態で [Next >]ボタンをクリックします。
「Adjusting the name of the initial branch in new repositories」画面が表示されます。「Let Git decide」が選択されていることを確認後、[Next >]ボタンをクリックします。
「Adjusting your PATH environment」画面が表示されます。中央の「Git from the command line and also from 3rd-party software」が選択されていることを確認後、[Next >]ボタンをクリックします。
「Choosing the SSH executable」画面が表示されます。「Use bundled OpenSSL」が選択されていることを確認後、[Next >]ボタンをクリックします。
「Choosing HTTPS transport backend」画面が表示されます。「Use the OpenSSL library」が選択されていることを確認後、[Next >]ボタンをクリックします。
「Configuring the line ending conversions」画面が表示されます。一番上の「Checkout Windows-style, commit Unix-style line endings」が選択されていることを確認した後、[Next >]ボタンをクリックします。
「Configuring the terminal emulator to use with Git Bash」画面が表示されます。「Use Windows'default console window」が選択されていることを確認した後、[Next >]ボタンをクリックします。
「Choose the default behavior of
git pull」画面が表示されます。「Default (fast-forward or merge)」が選択されていることを確認した後、[Next >]ボタンをクリックします。「Choose a credential helper」画面が表示されます。「None」が選択されていることを確認した後、[Next >]ボタンをクリックします。
「Configuring extra options」画面が表示されます。「Enable file system caching」だけがチェックされていることを確認した後、[Next >]ボタンをクリックします。
「Configuring experimental options」画面が表示されます。何もチェックせずに [Install]ボタンをクリックします。
インストールが完了すると「Completing the Git Setup Wizard」のメッセージが表示された画面が表示されます。中央の「View Release Notes」のチェックを外した後、[Next >]ボタンをクリックしてインストーラーを終了します。
コマンドプロンプトを起動して
git --versionを実行し、git のバージョンがgit version 2.33.0.windows.2になっていることを確認します。
特に問題はないようですので、2.33.0.2 で作業を進めたいと思います。
Spring Boot 2.4.x の Web アプリを 2.5.x へバージョンアップする ( その１０ )( Docker コンテナの image をバージョンアップする )
概要
記事一覧はこちらです。
Spring Boot 2.4.x の Web アプリを 2.5.x へバージョンアップする ( その９ )( SpotBugs を 4.2.1 → 4.4.0 へバージョンアップする ) の続きです。
- 今回の手順で確認できるのは以下の内容です。
- Docker コンテナの image をバージョンアップします。
参照したサイト・書籍
postgres / pgadmin4
https://github.com/postgres/pgadmin4- Dockerfile はトップ直下に、entrypoint.sh は /pkg/docker の下にあります。
pgAdmin - The config.py File
https://www.pgadmin.org/docs/pgadmin4/development/config_py.html
目次
- docker-compose.yml を変更する
- .env を変更する
docker-compose up -dコマンドを実行する- 動作確認
- pgAdmin 4 のコンテナが起動しない問題を解消する
手順
docker-compose.yml を変更する
services: prometheus: image: prom/prometheus:v2.29.2 .......... grafana: image: grafana/grafana:8.1.3 .......... redis_exporter: image: oliver006/redis_exporter:v1.27.0-alpine ..........
- prometheus で
image: prom/prometheus:v2.25.0→image: prom/prometheus:v2.29.2に変更します。 - grafana で
image: grafana/grafana:7.4.3→image: grafana/grafana:8.1.3に変更します。 - redis_exporter で
image: oliver006/redis_exporter:v1.17.1-alpine→image: oliver006/redis_exporter:v1.27.0-alpineに変更します。
.env を変更する
HOST_IP_ADDRESS=192.168.3.4 REDIS_VERSION=6.2.5 REDIS_CLUSTER_1_PORT=6379 REDIS_CLUSTER_2_PORT=6380 REDIS_CLUSTER_3_PORT=6381 REDIS_CLUSTER_4_PORT=6382 REDIS_CLUSTER_5_PORT=6383 REDIS_CLUSTER_6_PORT=6384 RABBITMQ_VERSION=3.9.5-management RABBITMQ_ERLANG_COOKIE=Uzkm93w5e1Lz8AcP RABBITMQ_DEFAULT_USER=rabbitmq RABBITMQ_DEFAULT_PASS=12345678 RABBITMQ_DEFAULT_VHOST=/ HAPROXY_VERSION=2.4.4 POSTGRESQL_VERSION=13.4 PGADMIN4_VERSION=5.6 FLYWAY_VERSION=7.15.0 FLYWAY_URL=jdbc:postgresql://postgresql/ksbylending FLYWAY_USER=ksbylending_user FLYWAY_PASSWORD=xxxxxxxx POSTGRES_EXPORTER_USER=postgres_exporter POSTGRES_EXPORTER_PASSWORD=zzzzzzzz MAILSERVER_VERSION=release-v7.2.0
- 以下の点を変更します。
REDIS_VERSION=6.2.1→REDIS_VERSION=6.2.5RABBITMQ_VERSION=3.8.14-management→RABBITMQ_VERSION=3.9.5-managementHAPROXY_VERSION=2.3.6→HAPROXY_VERSION=2.4.4POSTGRESQL_VERSION=12.6→POSTGRESQL_VERSION=13.4PGADMIN4_VERSION=5.0→PGADMIN4_VERSION=5.6FLYWAY_VERSION=7.5.4→FLYWAY_VERSION=7.15.0
docker-compose up -d コマンドを実行する
以下のコマンドを実行して docker image を更新・ダウンロードします（画面キャプチャはなし）。
docker-compose build --no-cacheコマンドを実行し、Dockerfile で作成している image を更新します。docker-compose up -dコマンドを実行してコンテナ一式（メールサーバ・rainloop を除く）を起動します。
動作確認
http://localhost:1936/haproxy?stats にアクセスして RabbitMQ が起動することを確認します。
http://localhost:15672/ にアクセスして rabbitmq / 12345678 でログインし、rabbitmq1～3 が正常に動作していることを確認します。
clean タスク実行 → Rebuild Project 実行 → build タスクを実行して BUILD SUCCESSFUL のメッセージが出力されることを確認します。
http://localhost:9090/graph にアクセスして Prometheus の画面が表示されることを確認します。
http://localhost:3000/ にアクセスして admin / admin でログインし、画面が表示されることを確認します。
http://localhost:12000/ にアクセスして postgres@example.com / yyyyyyyy でログインし、画面が表示されることを確認します。。。が画面が表示されませんでした。
Docker のログを見ると /var/lib/pgadmin/sessions に書き込み権限がないという警告ログが出力されてコンテナが終了していました。原因の調査は後で行います。
WARNING: Failed to set ACL on the directory containing the configuration database:
[Errno 1] Operation not permitted: '/var/lib/pgadmin'
HINT : You may need to manually set the permissions on
/var/lib/pgadmin to allow pgadmin to write to it.
IntelliJ IDEA の Service から redis-cluster-6379 コンテナに Create Terminal で接続して、redis-cli → cluster nodes コマンドを実行してクラスタ構成になっていることを確認します。
pgAdmin 4 のコンテナが起動しない問題を解消する
調べてみたところ、
- ローカルの ./docker/pgadmin4/data を Docker コンテナの /var/lib/pgadmin にマウントしているが、マウントしているディレクトリの permission は変更できず、/var/lib/pgadmin/sessions の権限チェックに引っかかっているためエラーとなり起動しない。
- https://www.pgadmin.org/docs/pgadmin4/development/config_py.html を見ると SESSION_DB_PATH という設定項目が存在し、デフォルトは
SESSION_DB_PATH = os.path.join(DATA_DIR, 'sessions')だが別のパスに変更することができる模様。 - docker-compose.yml で
PGADMIN_CONFIG_＋設定項目名で設定ができる。
という結果でしたので、sessions 用のディレクトリを /var/lib/pgadmin/sessions 以外の場所に作成し、適切な権限を付与して、かつ GADMIN_CONFIG_SESSION_DB_PATH を設定することで回避することにします。
docker/pgadmin4 の下に Dockerfile を新規作成し、以下の内容を記述します。
ARG PGADMIN4_VERSION
FROM dpage/pgadmin4:${PGADMIN4_VERSION}
USER root
RUN mkdir /var/lib/pgadmin_session
RUN chown pgadmin:pgadmin /var/lib/pgadmin_session
RUN chmod 0700 /var/lib/pgadmin_session
docker-compose.yml の pgadmin4 の記述を以下のように変更します。
pgadmin4: build: context: ./docker/pgadmin4 args: - PGADMIN4_VERSION=${PGADMIN4_VERSION} image: dpage/pgadmin4:${PGADMIN4_VERSION}-custom container_name: pgadmin4 ports: - "12000:80" environment: # TZ=Asia/Tokyo を設定してみたが日本時間に変わらなかったのでコメントアウトしておく # - TZ=Asia/Tokyo # PGADMIN_DEFAULT_EMAIL には接続する PostgreSQL の ユーザ名を設定する（サーバを追加する時楽なため） - PGADMIN_DEFAULT_EMAIL=postgres@example.com - PGADMIN_DEFAULT_PASSWORD=yyyyyyyy # PGADMIN_CONFIG_CONSOLE_LOG_LEVEL は debug 用 # 設定値は https://www.pgadmin.org/docs/pgadmin4/development/config_py.html の CONSOLE_LOG_LEVEL 参照 - PGADMIN_CONFIG_CONSOLE_LOG_LEVEL=10 - PGADMIN_CONFIG_SESSION_DB_PATH='/var/lib/pgadmin_session' volumes: - ./docker/pgadmin4/data:/var/lib/pgadmin
- build の記述を追加します。
image: dpage/pgadmin4:${PGADMIN4_VERSION}→image: dpage/pgadmin4:${PGADMIN4_VERSION}-customに変更します。- environment に
- PGADMIN_CONFIG_SESSION_DB_PATH='/var/lib/pgadmin_session'を追加します。
docker-compose build --no-cache コマンドを実行した後、docker-compose down、docker-compose up -d コマンドを実行してコンテナを再起動します。
http://localhost:12000/ にアクセスすると無事ログイン画面が表示されて、
postgres@example.com / yyyyyyyy でログインすると、登録済の情報で PostgreSQL に接続することができることが確認できました。
最後にローカルに残っている更新前のバージョンの Docker イメージを削除します。
履歴
2021/09/11
初版発行。
