AdoptOpenJDK を 11.0.5+10 → 11.0.6+10 へ、IntelliJ IDEA を 2019.3.1 → 2019.3.2 へ、Git for Windows を 2.24.1.2 → 2.25.0 へバージョンアップ

AdoptOpenJDK を 11.0.5+10 → 11.0.6+10 へバージョンアップする

※ksbysample-webapp-lending プロジェクトを開いた状態でバージョンアップしています。

1. https://adoptopenjdk.net/?variant=openjdk11&jvmVariant=hotspot を見ると 11.0.6+10 がダウンロードできるようになっていましたので、11.0.6+10 へバージョンアップします。

   

2. OpenJDK11U-jdk_x64_windows_hotspot_11.0.6_10.msi をダウンロードして D:\Java\jdk-11.0.6+10 へインストールした後、環境変数 JAVA_HOME のパスを D:\Java\jdk-11.0.6+10 へ変更しようとしたら、D:\Java\jdk-11.0.5+10\ のフォルダがまるごと消えていました。

   確認したところ OpenJDK11U-jdk_x64_windows_hotspot_11.0.5_10.msi をインストールした後に OpenJDK11U-jdk_x64_windows_hotspot_11.0.6_10.msi をインストールすると、11.0.5+10 が消えます。。。

   旧バージョンは残しておきたいので、D:\Java\jdk-11.0.5+10 → D:\Java\jdk-11.0.5+10x にリネームしてから D:\Java\jdk-11.0.6+10 にインストールし、インストール後に D:\Java\jdk-11.0.5+10 に戻します。

   環境変数 JAVA_HOME のパスを D:\Java\jdk-11.0.6+10 へ変更します。

   コマンドプロンプトから java -version を実行し、11.0.6 に変更されていることを確認します。

   

3. IntelliJ IDEA を再起動した後、プロジェクトで使用する JDK を 11.0.6+10 へ変更します。

4. 開いているプロジェクトを閉じて「Welcome to IntelliJ IDEA」ダイアログを表示します。

5. ダイアログ下部の「Configure」-「Structure for New Projects」を選択します。

   

6. 「Project Structure for New Projects」ダイアログが表示されます。画面左側で「Project Settings」-「Project」を選択後、画面右側の「Project SDK」の「New...」ボタンをクリックし、表示されるメニューから「JDK」を選択します。

   

7. 「Select Home Directory for JDK」ダイアログが表示されます。D:\Java\jdk-11.0.6+10 を選択した後、「OK」ボタンをクリックします。

   

8. 「Default Project Structure」ダイアログに戻るので、今度は「Project SDK」の「Edit」ボタンをクリックします。

   

9. 画面左側で「Platform Settings」-「SDKs」が選択された状態になるので、画面右上の入力フィールドで "11" → "11.0.6+10" へ変更します。

   

10. 次に中央のリストから「11.0.5+10」を選択した後、リストの上の「－」ボタンをクリックして削除します。

    

11. 「OK」ボタンをクリックして「Project Structure for New Projects」ダイアログを閉じます。

12. 「Welcome to IntelliJ IDEA」ダイアログに戻ったら、ksbysample-webapp-lending プロジェクトを開きます。

13. IntelliJ IDEA のメイン画面が開いたら、メニューから「File」-「Project Structure...」を選択します。

14. 「Project Structure」ダイアログが表示されます。以下の画像の状態になっているので、

    

    「Project SDK」を選択し直します。「Project SDK」を「11.0.6+10」に変更すると「Project language level」も自動で「SDK default (11 - Local variable syntax for lambda param」が選択されました。

    

15. 「OK」ボタンをクリックして「Project Structure」ダイアログを閉じます。

16. メイン画面に戻ると画面右下に「Indexing...」の表示が出るので、終了するまで待ちます。

17. Gradle Tool Window の左上にある「Refresh all Gradle projects」ボタンをクリックして更新します。

18. clean タスク実行 → Rebuild Project 実行 → build タスクを実行して、"BUILD SUCCESSFUL" のメッセージが出力されることを確認します。

    

19. Project Tool Window で src/test/groovy/ksbysample、src/test/java/ksbysample でコンテキストメニューを表示して「Run 'Tests in 'ksbysample'' with Coverage」を選択し、テストが全て成功することを確認します。

    

20. 特に問題は発生しませんでした。11.0.6+10 で開発を進めます。

IntelliJ IDEA を 2019.3.1 → 2019.3.2 へバージョンアップする

IntelliJ IDEA の 2019.3.2 がリリースされているのでバージョンアップします。

• IntelliJ IDEA 2019.3.2 is out!
  https://blog.jetbrains.com/idea/2020/01/intellij-idea-2019-3-2-is-out/

※ksbysample-webapp-lending プロジェクトを開いた状態でバージョンアップしています。

1. IntelliJ IDEA のメインメニューから「Help」-「Check for Updates...」を選択します。

2. 「IDE and Plugin Updates」ダイアログが表示されます（今回からデザインが変わりました）。左下に「Update and Restart」ボタンが表示されていますので、「Update and Restart」ボタンをクリックします。

   

3. Plugin の update も表示されました。このまま「Update and Restart」ボタンをクリックします。

   

4. Patch がダウンロードされて IntelliJ IDEA が再起動します。

5. IntelliJ IDEA が起動すると画面下部に「Indexing…」のメッセージが表示されますので、終了するまで待機します。

   

6. IntelliJ IDEA のメインメニューから「Help」-「About」を選択し、2019.3.2 へバージョンアップされていることを確認します。

7. Gradle Tool Window の左上にある「Refresh all Gradle projects」ボタンをクリックして更新します。

8. clean タスク実行 → Rebuild Project 実行 → build タスクを実行して、"BUILD SUCCESSFUL" のメッセージが出力されることを確認します。

   

9. Project Tool Window で src/test/groovy/ksbysample、src/test/java/ksbysample でコンテキストメニューを表示して「Run 'Tests in 'ksbysample'' with Coverage」を選択し、テストが全て成功することを確認します。

   

Git for Windows を 2.24.1.2 → 2.25.0 へバージョンアップする

Git for Windows の 2.25.0 がリリースされていたのでバージョンアップします。

1. https://gitforwindows.org/ の「Download」ボタンをクリックして Git-2.25.0-64-bit.exe をダウンロードします。

2. Git-2.25.0-64-bit.exe を実行します。

3. 「Git 2.25.0 Setup」ダイアログが表示されます。インストーラーの画面を一通り見たいので「Only show new options」のチェックを外してから [Next >] ボタンをクリックします。

4. 「Select Components」画面が表示されます。「Git LFS(Large File Support)」だけチェックした状態で [Next >]ボタンをクリックします。

5. 「Choosing the default editor used by Git」画面が表示されます。「Use Vim (the ubiquitous text editor) as Git's default editor」が選択された状態で [Next >]ボタンをクリックします。

6. 「Adjusting your PATH environment」画面が表示されます。中央の「Git from the command line and also from 3rd-party software」が選択されていることを確認後、[Next >]ボタンをクリックします。

7. 「Choosing HTTPS transport backend」画面が表示されます。「Use the OpenSSL library」が選択されていることを確認後、[Next >]ボタンをクリックします。

8. 「Configuring the line ending conversions」画面が表示されます。一番上の「Checkout Windows-style, commit Unix-style line endings」が選択されていることを確認した後、[Next >]ボタンをクリックします。

9. 「Configuring the terminal emulator to use with Git Bash」画面が表示されます。「Use Windows'default console window」が選択されていることを確認した後、[Next >]ボタンをクリックします。

10. 「Configuring extra options」画面が表示されます。「Enable file system caching」だけがチェックされていることを確認した後、[Next >]ボタンをクリックします。

11. 「Configuring experimental options」画面が表示されます。何もチェックせずに [Install]ボタンをクリックします。

12. インストールが完了すると「Completing the Git Setup Wizard」のメッセージが表示された画面が表示されます。中央の「View Release Notes」のチェックを外した後、[Next >]ボタンをクリックしてインストーラーを終了します（なぜか「Finish」ボタンではなくなりました）。

13. コマンドプロンプトを起動して git --version を実行し、git のバージョンが git version 2.25.0.windows.1 になっていることを確認します。

    

14. 特に問題はないようですので、2.25.0 で作業を進めたいと思います。

tfenv＋aws-vault＋direnv を組み合わせて Windows 上に Terraform の実行環境を構築する

概要

記事一覧はこちらです。

Windows 上に Terraform の実行環境を構築します。access key ID, secret access key は環境変数やテキストファイルに平文で設定・記述するのではなく Windows の資格情報マネージャーに登録します。また MFA を利用していなければ実行できないようにします。

• Terraform は exe を直接ダウンロードするのではなく tfenv を利用してインストールします。
• aws-vault を利用して access key ID, secret access key を Windows の資格情報マネージャーに登録します。
• access key ID, secret access key を発行する IAM ユーザには ReadOnlyAccess ポリシーだけ付与します。
• AdministratorAccess ポリシーを付与した IAM ロールを作成し、terraform 実行時にスイッチロールします。
• IAM ロールへスイッチロールできる IAM ユーザは IAM ポリシーで制限します。また MFA を利用していなければスイッチロールできないようにします。
• direnv をインストールして、ディレクトリ毎に実行する access key ID, secret access key（実際にはプロファイル）を切り替えられるようにします。

またタイトルには記述していませんが Git for Windows をインストールして git-cmd.exe＋bash.exe が起動できることが前提です（tfenv のページに Windows (64bit) - only tested in git-bash - currently presumed failing due to symlink issues in git-bash という記述があります）。この記事では git-cmd.exe＋bash.exe を D:\git\git-cmd.exe --command=usr/bin/bash.exe -l -i コマンドで起動しています。

参照したサイト・書籍

1. Terraform
   https://www.terraform.io/

2. tfutils/tfenv
   https://github.com/tfutils/tfenv

3. 99designs/aws-vault
   https://github.com/99designs/aws-vault

4. direnv/direnv
   https://github.com/direnv/direnv

5. MFA 保護 API アクセスの設定
   https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html

目次

1. tfenv と terraform をインストールする
2. IAM ユーザと IAM ロールを作成する
3. aws-vault をインストールして Windows の資格情報マネージャーに access key ID, secret access key を登録する
4. C:\Users\<ユーザ名>\.aws\config に設定を追加する
5. direnv をインストールする
6. C:\Users\<ユーザ名>\.bashrc に設定を追加する
7. ディレクトリに移動したら terraform 実行時に使用する aws の profile を自動で切り替えるよう設定する
8. Windows の資格情報マネージャーに保存した access key ID, secret access key は --no-session オプション付きで aws-vault を実行すれば取得できる

手順

tfenv と terraform をインストールする

tfutils/tfenv の Releases ページ（https://github.com/tfutils/tfenv/releases）から Latest release のラベルが付いている v1.0.2 の「Source code(zip)」のリンクをクリックして tfenv-1.0.2.zip をダウンロードします。

ダウンロードが完了したら tfenv-1.0.2.zip を解凍し、フォルダ名を tfenv に変更後 D:\ の下に移動します。

環境変数 Path に D:\tfenv\bin\ を追加した後、git-cmd.exe＋bash.exe を起動して tfenv コマンドが実行できることを確認します。

以下のコマンドを実行して、terraform の最新バージョンを確認してからインストールします。

• tfenv list-remote | head
• tfenv install 0.12.19
• tfenv list

terraform -version コマンドを実行すると 0.12.19 が表示されます。

起動した git-cmd.exe＋bash.exe を終了します。

IAM ユーザと IAM ロールを作成する

一時作業用の AdministratorAccess ポリシーを付与した IAM ユーザを作成して、access key ID, secret access key を発行します。

IAM ユーザと IAM ロールの作成には terraform を利用します。作業用に D:\work\ ディレクトリを新規作成します。その下に main.cf というファイルを新規作成して、以下の内容を記述します。

terraform {
  required_version = "0.12.19"
}

provider "aws" {
  region = "ap-northeast-1"
}

///////////////////////////////////////////////////////////////////////////////
// ReadOnlyUser
//
resource "aws_iam_user" "ReadOnlyUser" {
  name = "ReadOnlyUser"
  // MFAデバイスを登録していると削除できないので forace_destroy を true にしている
  force_destroy = true
}
resource "aws_iam_user_policy_attachment" "AttachReadOnlyAccessToReadOnlyUser" {
  user       = aws_iam_user.ReadOnlyUser.name
  policy_arn = "arn:aws:iam::aws:policy/ReadOnlyAccess"
}

///////////////////////////////////////////////////////////////////////////////
// AdminRole
//
data "aws_iam_policy_document" "SwitchAdminRolePolicy" {
  statement {
    effect = "Allow"
    actions = ["sts:AssumeRole"]
    principals {
      type        = "AWS"
      identifiers = [aws_iam_user.ReadOnlyUser.arn]
    }
    condition {
      test     = "Bool"
      variable = "aws:MultiFactorAuthPresent"
      values   = [true]
    }
  }
}
resource "aws_iam_role" "AdminRole" {
  name               = "AdminRole"
  assume_role_policy = data.aws_iam_policy_document.SwitchAdminRolePolicy.json
}
resource "aws_iam_role_policy_attachment" "AdminRole" {
  role       = aws_iam_role.AdminRole.name
  policy_arn = "arn:aws:iam::aws:policy/AdministratorAccess"
}

git-cmd.exe＋bash.exe を起動した後、カレントディレクトリを D:\work\ に変更してから環境変数 AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY に AdministratorAccess ポリシーを付与した一時作業用の IAM ユーザの access key ID, secret access key を設定します。

terraform init コマンドを実行してから、

terraform plan → terraform apply コマンドを実行して IAM ユーザ（ReadOnlyUser）、IAM ロール（AdminRole）を作成します（画面キャプチャは terraform apply の一部のみ）。

AWS マネジメントコンソールから一時作業用の IAM ユーザでサインインし、作成した IAM ユーザ（ReadOnlyUser）の「コンソールへのアクセスの有効化」「MFA デバイスの割り当て」「アクセスキーの作成」を行います（詳細な手順は省略します）。

MFA の ARN、access key ID, secret access key は後の設定で使用するのでメモしておきます。

作成した IAM ロール（AdminRole）のロール ARN も後の設定で使用するのでメモしておきます。

起動した git-cmd.exe＋bash.exe を終了します。

一時作業用の IAM ユーザの access key ID, secret access key は削除します。一時作業用の IAM ユーザも不要なら削除します。

aws-vault をインストールして Windows の資格情報マネージャーに access key ID, secret access key を登録する

99designs/aws-vault の Releases ページ（https://github.com/99designs/aws-vault/releases）から Latest release のラベルが付いている v5.1.2 の「aws-vault-windows-386.exe」のリンクをクリックして aws-vault-windows-386.exe をダウンロードします。

D:\ の直下に aws-vault ディレクトリを作成し、ダウンロードした aws-vault-windows-386.exe を移動して aws-vault.exe にリネームします。

環境変数 Path に D:\aws-vault\ を追加した後、git-cmd.exe＋bash.exe を起動して aws-vault コマンドが実行できることを確認します。

aws-vault add ReadOnlyUser コマンドを実行して IAM ユーザ（ReadOnlyUser）の access key ID, secret access key を Windows の資格情報マネージャーに登録します。

登録すると「資格情報マネージャー」の「Windows 資格情報」-「汎用資格情報」に aws-vault:aws-vault:ReadOnlyUser が追加されます。

起動した git-cmd.exe＋bash.exe を終了します。

C:\Users\<ユーザ名>\.aws\config に設定を追加する

C:\Users\<ユーザ名>\.aws\config をエディタで開いて aws-vault の Roles and MFA の記述を参考に設定を追加します。

[default]
output=json
region=ap-northeast-1

[profile ReadOnlyUser]
mfa_serial = arn:aws:iam::123456789012:mfa/ReadOnlyUser

[profile AdminRole]
source_profile = ReadOnlyUser
role_arn = arn:aws:iam::999999999999:role/AdminRole
mfa_serial = arn:aws:iam::123456789012:mfa/ReadOnlyUser

• aws-vault add ReadOnlyUser コマンドを実行した時に [profile readonlyuser] が追加されているので、readonlyuser → ReadOnlyUser に変更した後（IAM ユーザが大文字小文字を区別しないと知ったのはこのページを書いた後でした。。。） mfa_serial = ... の行を追加します。
• [profile AdminRole] の設定を追加します。
• mfa_serial = ... はどちらにも ReadOnlyUser の MFA の ARN を記述します。

一旦ここで動作確認します。git-cmd.exe＋bash.exe を起動してから aws-vault exec AdminRole -- aws s3 mb s3://<何か適当なBucket名> を実行して S3 Bucket を作成してみます。

初回の実行時には MFA の token が求められますので MFA デバイスで確認して入力します。この時 temporary security credentials が取得されますので２回目以降のコマンド実行では token の入力は求められません。temporary security credentials の有効期限はデフォルトで 1時間です（一時的なセキュリティ認証情報のリクエスト に記載があります）。

取得された temporary security credentials も Windows の資格情報マネージャーに登録されます。

有効期限が切れるか、これを削除すると再び MFA の token が求められます。

temporary security credentials を Windows の資格情報マネージャーに保存したくない場合（コマンド実行時に都度 MFA の token を求めるようにしたい場合）には、--no-session オプションを追加して aws-vault exec AdminRole --no-session -- aws s3 mb s3://<何か適当なBucket名> のようにコマンドを実行します。

作成した S3 Bucket は削除します。

起動した git-cmd.exe＋bash.exe を終了します。

direnv をインストールする

direnv/direnv の Releases ページ（https://github.com/direnv/direnv/releases）から Latest release のラベルが付いている v2.20.0 の「direnv.windows-amd64.exe」のリンクをクリックして direnv.windows-amd64.exe をダウンロードします。

D:\ の直下に direnv ディレクトリを作成し、ダウンロードした direnv.windows-amd64.exe を移動します（リネームはしません）。

C:\Users\<ユーザ名>\.bashrc に設定を追加する

C:\Users\<ユーザ名>\.bashrc をエディタで開いて設定を追加します。

# for direnv
alias direnv="/d/direnv/direnv.windows-amd64.exe"
_direnv_hook() {
  local previous_exit_status=$?;
  eval "$(MSYS_NO_PATHCONV=1 direnv export bash | sed 's|export PATH=|export _X_DIRENV_PATH=|g')";
  if [ -n "$_X_DIRENV_PATH" ]; then
    _X_DIRENV_PATH=$(cygpath -p "$_X_DIRENV_PATH")
    export "PATH=$_X_DIRENV_PATH"
    unset _X_DIRENV_PATH
  fi
  return $previous_exit_status;
};

if ! [[ "$PROMPT_COMMAND" =~ _direnv_hook ]]; then
  PROMPT_COMMAND="_direnv_hook;$PROMPT_COMMAND"
fi

# for aws-vault+terraform
tf() {
  aws-vault exec $AWS_PROFILE -- bash -c "terraform $@"
}

• alias direnv="/d/direnv/direnv.windows-amd64.exe" を追加します。
• _direnv_hook() { ... } と if ! [[ "$PROMPT_COMMAND" =~ _direnv_hook ]]; then ... fi を追加します。Setup に記載されている BASH 用の eval "$(direnv hook bash)" の設定だと git-cmd.exe＋bash.exe の環境で direnv の PATH_add が実行された時にパスが正しく設定されないので、PATH gets mangled when using direnv from git-bash on Windows に記載されていたコードを設定しています。
• aws-vault＋terraform の実行用に tf() { ... } を追加します。環境変数 AWS_PROFILE に使用するプロファイルを設定してから、terraform apply ならば tf apply のように terraform → tf に変更したコマンドを実行します。bash -c "terraform $@" は aws-vault exec can not successfully run with eval を参考にしました。また動作確認等で素の terraform コマンドを使う分けたりする必要性を感じなければ、関数名を tf() → terraform() に変えても構いません。その場合 terraform コマンドを実行するとこの関数が実行されるようになります。

ディレクトリに移動したら terraform 実行時に使用する aws の profile を自動で切り替えるよう設定する

D:\work2\ を作成し、その下に .envrc と main.cf を作成して VPC を１つ作成してみます。

D:\work2\ を作成してから git-cmd.exe＋bash.exe を起動してカレントディレクトリを D:\work2\ に変更します。touch .envrc コマンドを実行して .envrc を作成してから、

以下の内容を記述します。

export AWS_PROFILE=AdminRole

main.tf を作成し、以下の内容を記述します。

terraform {
  required_version = "0.12.19"
}

provider "aws" {
  region = "ap-northeast-1"
}

resource "aws_vpc" "sample-vpc" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true

  tags = {
    Name = "sample-vpc"
  }
}

direnv allow コマンドを実行します。

tf init コマンドを実行してから、

tf plan → tf apply コマンドを実行すると VPC が作成されました。

tf destroy コマンドを実行して作成した VPC を削除します。

.envrc を以下の内容に変更すると、

export AWS_PROFILE=ReadOnlyUser

tf apply コマンドを実行してもエラーとなり VPC は作成できません。

Windows の資格情報マネージャーに保存した access key ID, secret access key は --no-session オプション付きで aws-vault を実行すれば取得できる

Windows の資格情報マネージャーに保存された access key ID, secret access key を後から取得することはできないのか調べたところ、aws-vault exec ReadOnlyUser --no-session -- env | grep ^AWS コマンドを実行すれば取得できます。

下の画像の例では、temporary security credentials ではなく ReadOnlyUser の access key ID, secret access key が表示されています。

IAM ユーザには極力権限を付与せず（ReadOnlyAccess ポリシーも外してよいかもしれません）、強い権限はスイッチロール先の IAM ロールに与える（MFA も有効にする）方が良さそうです。

履歴

2020/01/19
初版発行。

Spring Boot 2.1.x の Web アプリを 2.2.x へバージョンアップする ( 感想 )

記事一覧はこちらです。

• 今回は大きな変更がなかったので、ひたすら色々なモジュールをバージョンアップして細かな変更点に対応していった感じです。2.0、2.1 へのバージョンアップと比較すると結構楽でした。

• Spring Boot 2.2 Release Notes から 1.5 以前の Release Notes へのリンクが消えました。https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-1.3-Release-Notes のように URL のバージョンを変更すればアクセスは可能ですが、1 系は EOL になったので当然の流れでしょう。ページ自体がなくなる可能性もあるので、1系は速やかに 2系にバージョンアップした方が良さそうです。

• -XX:TieredStopAtLevel=1 ＋ -Dspring.main.lazy-initialization=true で実行時間が短縮できるのは結構便利な気がします。しばらく開発環境やテスト時には利用していくつもりです。

• Gradle を 6 系にバージョンアップしましたが、Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0. のメッセージが出るようになりました。Gradle 7 になると compile 等の旧構文が使用できなくなるようです。5 系 → 6系が出るまで約 1年かかっているので、7 系が出るのも 1 年くらいなのかな？　Spring Framework の 6 系へのバージョンアップと重なったら大変そうです。。。（どうなるかは分かりませんが）

• 珍しく Checkstyle のバージョンアップでエラーが出ましたが、google_checks.xml が最新版に対応していることに気づけました。今後はバージョンアップ時に差分を反映していくことにします。

• Spotbugs の findsecbugs-plugin が結構いい指摘をしてくれます。Spotbugs を導入するなら一緒に導入することをお勧めします。

Spring Boot 2.1.x の Web アプリを 2.2.x へバージョンアップする ( その１４ )( Docker で複数の Tomcat を起動して動作確認する )

概要

記事一覧はこちらです。

Spring Boot 2.1.x の Web アプリを 2.2.x へバージョンアップする ( その１３ )( gradle の VM オプションを gradle.proeprties に移行する＋spring.main.lazy-initialization を試してみる２ ) の続きです。

• 今回の手順で確認できるのは以下の内容です。
  • jar ファイルを作成して動作確認します。
  • Tomcat の起動はサービスからではなく docker-compose.app.yml を使用して行います。
  • docker-compose.app.yml から起動するコンテナの docker image は最新版にバージョンアップします。

参照したサイト・書籍

目次

1. docker-compose.app.yml で起動するコンテナの docker image をバージョンアップする
2. Docker で複数の Tomcat を起動して動作確認する

手順

docker-compose.app.yml で起動するコンテナの docker image をバージョンアップする

docker-compose up -d コマンドを実行した後、build タスクを実行して jar ファイルを作成します。

docker-compose.app.yml の以下の点を変更します。

services:
  app:
    build:
      context: .
      dockerfile: docker/app/Dockerfile
    image: ksbysample-webapp-lending
    volumes:
      - ./build/libs/ksbysample-webapp-lending-2.2.2-RELEASE.jar:/app.jar
      - ./docker/app/docker-entrypoint.sh:/usr/local/bin/docker-entrypoint.sh
    environment:
      - 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/sh
    # stdin_open: true
    # tty: true

  haproxy-app:
    image: haproxy:2.1.2-alpine
    container_name: haproxy-app
    volumes:
      - ./docker/app/haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg:ro
    ports:
      - "8080:8080"
    depends_on:
      - app
  haproxy-app-rsyslog:
    image: rafpe/docker-haproxy-rsyslog:latest
    container_name: haproxy-app-rsyslog
    volumes:
      - ./docker/app/haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg:ro
    depends_on:
      - haproxy-app

• app コンテナの記述で - ./build/libs/ksbysample-webapp-lending-2.1.3-RELEASE.jar:/app.jar → - ./build/libs/ksbysample-webapp-lending-2.2.2-RELEASE.jar:/app.jar に変更します。
• haproxy-app コンテナの記述で image: haproxy:1.8.14-alpine → image: haproxy:2.1.2-alpine に変更します。
• haproxy-app-rsyslog コンテナの記述で image: rafpe/docker-haproxy-rsyslog → image: rafpe/docker-haproxy-rsyslog:latest に変更します。

docker/app/Dockerfile の以下の点を変更します。

FROM adoptopenjdk/openjdk11:jdk-11.0.5_10-alpine-slim
RUN apk add --no-cache tzdata
ENV TZ="Asia/Tokyo"
ENV LANG="ja_JP.UTF-8"
VOLUME /tmp
EXPOSE 8080
ENTRYPOINT ["docker-entrypoint.sh"]

• FROM adoptopenjdk/openjdk11:jdk-11.0.2.9-alpine-slim → FROM adoptopenjdk/openjdk11:jdk-11.0.5_10-alpine-slim に変更します。

IntelliJ IDEA の Service Tool Window から docker の ksbysample-webapp-lending:latest の image を削除した後、docker-compose -f docker-compose.app.yml --compatibility build --no-cache コマンドを実行して image を作り直します。。。が、docker/prometheus/storage の下のファイルを参照できず PermissionError が発生しました。

プロジェクトのルートディレクトリ直下に .dockerignore ファイルを作成して以下の内容を記述し、build 時に参照しないようにします。

docker/prometheus/storage/*

再度 docker-compose -f docker-compose.app.yml --compatibility build --no-cache コマンドを実行すると、今度は成功しました。

IntelliJ IDEA の Service Tool Window から不要になった以下の docker image を削除します。

• adoptopenjdk/openjdk11:jdk-11.0.2.9-alpine-slim

Docker で複数の Tomcat を起動して動作確認する

docker-compose -f docker-compose.app.yml --compatibility up -d、docker-compose -f docker-compose.mail.yml up -d コマンドを実行します。

http://localhost:8080/haproxy?stats にアクセスして全てのインスタンスが緑色になるまで待ちます。。。が、いつまで経っても緑色になりませんでした。

IntelliJ IDEA の Service Tool Window で app コンテナを見ると ... org.springframework.boot.context.properties.bind.BindException: Failed to bind properties under 'server.tomcat.basedir' to java.io.File エラーメッセージが出て落ちていました。

Docker で起動する時は product profile で起動しており、server.tomcat.basedir は application-product.properties では以下のように定義しています。起動しなくて当然でした。以前はよくこれで起動していましたね。。。

server.tomcat.basedir=D:/webapps/ksbysample-webapp-lending
logging.file.name=${server.tomcat.basedir}/logs/ksbysample-webapp-lending.log

spring.autoconfigure.exclude=com.integralblue.log4jdbc.spring.Log4jdbcAutoConfiguration

valueshelper.classpath.prefix=BOOT-INF.classes.

docker-compose -f docker-compose.app.yml --compatibility down コマンドを実行して app コンテナを終了させた後、docker/app/docker-entrypoint.sh の以下の点を変更します。

#!/bin/sh
# 改行コードを LF にすること。LF でないと実行されない。

export JAVA_OPTS="-Xms1024m -Xmx1024m -XX:MaxMetaspaceSize=384m"

exec java $JAVA_OPTS \
          -Djava.security.egd=file:/dev/./urandom \
          -Dspring.profiles.active=product \
          -Dserver.tomcat.basedir=/ \
          -Dlogging.appender=CONSOLE \
          -jar /app.jar

• -Dserver.tomcat.basedir=/ \ を追加します。

再び docker-compose -f docker-compose.app.yml --compatibility up -d コマンドを実行した後、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 コマンドを実行してコンテナを停止します。

履歴

2020/01/13
初版発行。

Spring Boot 2.1.x の Web アプリを 2.2.x へバージョンアップする ( その１３ )( gradle の VM オプションを gradle.proeprties に移行する＋spring.main.lazy-initialization を試してみる２ )

概要

記事一覧はこちらです。

Spring Boot 2.1.x の Web アプリを 2.2.x へバージョンアップする ( その１２ )( spring.main.lazy-initialization を試してみる ) の続きです。

• 今回の手順で確認できるのは以下の内容です。
  • IntelliJ IDEA の Gradle の VM オプションの設定項目が deprecated になっていたので、gradle.properties に移行します。
  • ユニットテスト実行時に -XX:TieredStopAtLevel=1、-Dspring.main.lazy-initialization=true を追加してテストの時間を短縮できるか試してみます。

参照したサイト・書籍

目次

1. gradle の VM オプションを gradle.proeprties に移行する
2. ユニットテスト実行時の VM オプションに -XX:TieredStopAtLevel=1、-Dspring.main.lazy-initialization=true を追加する

手順

gradle の VM オプションを gradle.proeprties に移行する

IntelliJ IDEA の設定を見直していた時に Gradle VM options の設定項目が deprecated になっていることに気づきました。代わりに gradle.properties に設定するよう記述されています。

プロジェクトのルートディレクトリ直下に gradle.properties を新規作成し、以下の内容を記述します。

org.gradle.jvmargs=-Dfile.encoding=UTF-8

IntelliJ IDEA の設定項目の値をクリアすると、設定項目自体が消えました。

ユニットテスト実行時の VM オプションに -XX:TieredStopAtLevel=1、-Dspring.main.lazy-initialization=true を追加する

Spring Boot 2.1.x の Web アプリを 2.2.x へバージョンアップする ( その１２ )( spring.main.lazy-initialization を試してみる ) で spring.main.lazy-initialization 設定時の動作を確認しましたが、ユニットテスト実行時に追加した時の動作確認をし忘れていましたので確認してみます。

build.gradle の jvmArgsForTask 変数に -XX:TieredStopAtLevel=1、-Dspring.main.lazy-initialization=true を追加します。testJUnit4AndSpock、test タスクだけでなく bootRun タスク時に付いていても問題ないので、共通の VM オプションを設定している変数 jvmArgsForTask に追加します。

def jvmArgsForTask = [
        "-ea",
        "-Dfile.encoding=UTF-8",
        "-Dsun.nio.cs.map=x-windows-iso2022jp/ISO-2022-JP",
        "-XX:TieredStopAtLevel=1",
        "-Dspring.main.lazy-initialization=true"
]

Gradle Tool Window の左上にある「Refresh all Gradle projects」ボタンをクリックして更新した後、clean タスク実行 → Rebuild Project 実行 → build タスクを実行すると、テストが１件失敗しました。

失敗したのは以下のテストです。このテストだけ実行してみます。

    @Nested
    @SpringBootTest
    class 次回から自動的にログインするのテスト {

        @RegisterExtension
        @Autowired
        public TestDataExtension testDataExtension;

        @RegisterExtension
        @Autowired
        public SecurityMockMvcExtension mvc;

        @Autowired
        ServletContext servletContext;

        @Test
        void 次回から自動的にログインするをチェックすれば次はログインしていなくてもログイン後の画面にアクセスできる()
                throws Exception {
            // ログイン前にはログイン後の画面にアクセスできない
            mvc.noauth.perform(get(Constant.URL_AFTER_LOGIN_FOR_ROLE_ADMIN))
                    .andExpect(status().isFound())
                    .andExpect(redirectedUrl("http://localhost/"))
                    .andExpect(unauthenticated());

            // 「次回から自動的にログインする」をチェックしてログインし、remember-me Cookie を生成する
            org.springframework.mock.web.MockHttpServletRequest request
                    = formLogin()
                    .user("id", mvc.MAILADDR_TANAKA_TARO)
                    .password("password", "taro")
                    .buildRequest(servletContext);
            request.addParameter("remember-me", "true");
            SimpleRequestBuilder simpleRequestBuilder = new SimpleRequestBuilder(request);
            MvcResult result = mvc.noauth.perform(simpleRequestBuilder)
                    .andExpect(status().isFound())
                    .andExpect(redirectedUrl(Constant.URL_AFTER_LOGIN_FOR_ROLE_ADMIN))
                    .andExpect(authenticated().withUsername(mvc.MAILADDR_TANAKA_TARO))
                    .andReturn();
            Cookie[] cookie = result.getResponse().getCookies();

            // remember-me Cookie を引き継いでログイン後の画面にアクセスするとアクセスできる
            mvc.noauth.perform(get(Constant.URL_AFTER_LOGIN_FOR_ROLE_ADMIN).cookie(cookie))
                    .andExpect(status().isOk())
                    .andExpect(content().contentType("text/html;charset=UTF-8"))
                    .andExpect(model().hasNoErrors())
                    .andExpect(authenticated().withUsername(mvc.MAILADDR_TANAKA_TARO));

            // ログイン画面にアクセスしても有効な remember-me Cookie があればログイン後の画面にリダイレクトする
            mvc.noauth.perform(get("/").cookie(cookie))
                    .andExpect(status().isFound())
                    .andExpect(redirectedUrl(Constant.URL_AFTER_LOGIN_FOR_ROLE_ADMIN))
                    .andExpect(authenticated().withUsername(mvc.MAILADDR_TANAKA_TARO));
        }

    }

IntelliJ IDEA のエディタから上のテストを１度実行した後（この時は -Dspring.main.lazy-initialization=true を指定していないので成功します）、メインメニューの「Run」-「Edit Configurations...」を選択します。

「Run/Debug Configurations」ダイアログが表示されたら、JUnit のテストの VM options に -XX:TieredStopAtLevel=1、-Dspring.main.lazy-initialization=true を追加します。

IntelliJ IDEA の画面上部から JUnit のテストを選択し実行すると、

今度は失敗しました。java.lang.IllegalStateException: UserDetailsService is required. のエラーメッセージが出ています。

LazyInitializationExcludeFilter.forBeanTypes(...) で UserDetailsService や LendingUserDetailsService を Lazy の対象から除外してみましたが、テストは成功しませんでした。

breakpoint を設定して何度も debug 実行して分かったのは以下の点でした。

• テストが失敗するのは以下のコードが実行された時でした。

• -Dspring.main.lazy-initialization=true を付けている時と付けない時で WebSecurityConfigurerAdapter$UserDetailsServiceDelegator#loadUserByUsername 内の delegate = delegateBuilder.getDefaultUserDetailsService(); の動作が異なっていました。

  -Dspring.main.lazy-initialization=true を付けている時は、delegateBuilder = AuthenticationConfiguration$DefaultPasswordEncoderAuthenticationManagerBuilder の時に delegateBuilder.getDefaultUserDetailsService() は null を返すのですが、

  -Dspring.main.lazy-initialization=true を付けていない時は、delegateBuilder = AuthenticationConfiguration$DefaultPasswordEncoderAuthenticationManagerBuilder の時に delegateBuilder.getDefaultUserDetailsService() は ksbysample.webapp.lending.security.LendingUserDetailsService のインスタンスを返します。

• このアプリで defaultUserDetailsService に影響しそうなのは ksbysample.webapp.lending.config.WebSecurityConfig#configAuthentication しかなかったので breakpoint を設定してみたところ、-Dspring.main.lazy-initialization=true を付けている時には breakpoint で止まりませんでした。lazy の対象になっていて起動時に実行されず、後で必要になってからも実行されていないようです。

そうであれば ksbysample.webapp.lending.config.WebSecurityConfig クラス自体を lazy の対象外にすれば解決しそうに思えたので、クラスに @Lazy(false) アノテーションを追加してみます。

@Lazy(false)
@Configuration
public class WebSecurityConfig {

その結果、テストの実行は成功し、

build タスクも成功するようになりました。

build タスクの実行時間も Spring Boot 2.1.x の Web アプリを 2.2.x へバージョンアップする ( その４ )( Spring Boot を 2.1.11 → 2.2.2 へバージョンアップする ) の時と比較すると 4分 → 3分 20秒 で 40秒程短くなりました。テストだと結構効果がありますね。

テストはこのまま -XX:TieredStopAtLevel=1、-Dspring.main.lazy-initialization=true を追加しておくことにします。

履歴

2020/01/13
初版発行。

Spring Boot 2.1.x の Web アプリを 2.2.x へバージョンアップする ( 番外編 )( IntelliJ IDEA の Translation・Redis プラグインを追加する )

概要

記事一覧はこちらです。

最近 Twitter で見かけたり、Download 数が多く便利そうに思えた IntelliJ IDEA のプラグインを追加したので、そのメモ書きです。

参照したサイト・書籍

目次

1. Translation
2. Redis

手順

Translation

Google 翻訳のエンジン等を利用して翻訳を支援してくれるプラグインです。

IntelliJ IDEA の Plugin の画面から Translation で検索してインストールします。

「Settings」ダイアログの「Other Settings」-「Translation」に設定項目が追加されます。追加したばかりで勝手も分からないので、デフォルト設定のままにします。

IntelliJ IDEA の画面右上に「Show Translation Dialog...」（青い方）と「Show Instant Translation Dialog...」（赤い方）の２つのボタンが追加されます。

「Show Translation Dialog...」（青い方）ボタンをクリックすると「Translation」ダイアログが表示されます。日本語を入力すれば英語の、英語を入力すれば日本語の翻訳結果が表示されます。

「Show Instant Translation Dialog...」（赤い方）ボタンをクリックすると別の「Translation」ダイアログが表示されます。左側に日本語を入力すると右側に英語の翻訳結果が表示されます。このダイアログは右側には入力できません。

エディタ上の文章も翻訳できます。例えば Spring のソースを開いてコメントを選択した後、右クリックメニューを表示してから「Translate」を選択すると、

日本語の翻訳結果が表示されます。日本語のコメントを選択すれば英語の翻訳結果を表示できます。

翻訳結果をエディタ上のソースに反映することもできます。翻訳したい文章を選択してから右クリックメニューを表示して「Translate and Replace...」を選択します。

候補が表示されるので（複数表示されることもあります）、選択して Enter を押すと、

翻訳結果に置き換わります。

Redis

Redis のデータを簡単に見るためのプラグインが欲しかったので、Redis プラグインをインストールします。

IntelliJ IDEA の Plugin の画面から Redis で検索してインストールします。ダウンロード数は「ledis」の方が多いのですが、インストールしてもなぜか動きませんでした。

インストールすると画面右側に「Redis Explorer」が追加され、クリックすると Redis Explorer Window が開きます。サーバを追加するために「＋」ボタンをクリックします。

「Add a Redis Server」ダイアログが表示されます。「Label」に localhost を入力、「redisCluster」をチェックしてから「Test Connection」ボタンを押して接続できることを確認した後、「OK」ボタンをクリックします。

Redis Explorer Window に「localhost」が追加れますので、その下の「Cluster」をダブルクリックすると中央にウィンドウが開いて Redis 内のデータが表示されます。

履歴

2020/01/12
初版発行。

Spring Boot 2.1.x の Web アプリを 2.2.x へバージョンアップする ( 番外編 )( IntelliJ IDEA の Grazie・GitToolBox プラグインを追加する )

概要

記事一覧はこちらです。

最近 Twitter で見かけたり、Download 数が多く便利そうに思えた IntelliJ IDEA のプラグインを追加したので、そのメモ書きです。 ２回に分けて書きます。

参照したサイト・書籍

目次

1. Grazie
2. GitToolBox

手順

Grazie

去年 Twitter で見かけた Jetbrains のプラグインです。コードやコメント等いろいろな箇所の文章の単純な typo から文法エラーまでチェックしてくれるそうです。

Try Grazie, the new plugin for IntelliJ IDEA, to check the spelling, grammar, and style of your natural language constructs: string literals, comments, commit messages, readme files, and any other text in over 15 languages. Read the blog post for details: https://t.co/lTv0Z4p1JE pic.twitter.com/sI2ZtWmKkt

— IntelliJ IDEA (@intellijidea) November 5, 2019

詳細な記事が Blog にも書かれています。

• Meet Grazie: the ultimate spelling, grammar, and style checker for IntelliJ IDEA
  https://blog.jetbrains.com/idea/2019/11/meet-grazie-the-ultimate-spelling-grammar-and-style-checker-for-intellij-idea/?utm_source=email&utm_medium=newsletter-november-2019&utm_campaign=plugin&utm_content=link-plugin-meet-grazie

去年見かけて気にしていたのですが、まだインストールしていなかったのでインストールします。

IntelliJ IDEA の Plugin の画面から Grazie で検索してインストールします。

IntelliJ IDEA を再起動後「Settings」ダイアログを開いて、「Tools」-「Grazie」から以下の設定をします。

• 「Native Languate」で「Japanese」を選択する。
• 「Check commit messages」をチェックする。

実際には typo の検出で使用することの方が多いかな？と思っていますが、このプラグイン、コメント内だけでなく変数名やメソッド名等の typo も検出してくれます。

例えば simpleRetryTemplate → simpleRettryTemplate（Retry の r が多い）に変更すると、Retty のところに波線が表示されて、

カーソルを移動してから Alt+Enter を押すとメニューが表示されるので「Type: Rename to...」を選択します。

そうすると typo している箇所だけでなくメソッド名全体の修正候補が表示されるので、選択してから Enter キーを押すと、

反映されます。

typo は気づかないことがよくあるので何とかしたいなと思っていましたが、このプラグインで解決できそうです。

GitToolBox

初見は @tonkotsuboy_com さんの Twitter でした。

WebStorm（IntelliJ IDEA、PhpStorm）でgit操作するなら、GitToolBoxを入れておくと捗ります。https://t.co/fuxxleaqHB

とくinline blameがお気に入り。コード上にコミットログが示され、バルーンからコミットの詳細を確認できます。#WebStorm #git pic.twitter.com/BsgtG8y5NA

— 鹿野 壮（Kano） (@tonkotsuboy_com) December 12, 2019

インストールしてみると確かに inline brame がとても便利です。作ったばかりのシステムだとあまり気にしませんが、作ってから時間が経ったシステムだと「これ、いつ誰が何のために書いたんだろう？」と思って確認したいことがあります。

プラグインをインストールしていない IntelliJ IDEA でもエディタ上に最終変更日と更新した人を表示してから Git の履歴にジャンプして確認することが可能ですが、ちょっとコメントを確認したいだけの時は少し手間でした。

このプラグインをインストールしておくとカーソルを当てた行に更新した人、最終変更日、コメントが表示される（しかもあまり邪魔にならない＋エディタが遅くならない）ので、すぐに確認できるようになります。

インストールは IntelliJ IDEA の Plugin の画面から GitToolBox で検索して行います。

インストール後「Settings」ダイアログを開くといろいろ設定項目が追加されています。inline blame の文字色等も変更できます。

inline blame 以外にも Project Window 上に現在のブランチ名が表示されたり、

画面右下に Blame: ... という表示が追加されて、現在カーソルがある行の変更した人、最終変更日が表示されたりします。

クリックすると git blame の内容が表示されて、

「Git Log」リンクをクリックすると Git Log が表示されて変更された commit にジャンプします。

「Affected Files」リンクをクリックすると該当行が変更された時の commit で変更されたファイル一覧が表示されて（複数ファイルを表示させたかったので上とは選択する行を変えています）、

履歴を見たいファイルを選択して右クリックメニューを表示→「History Up to Here」を選択すると、

選択したファイルのこれまでの変更履歴を表示させることもできます。

履歴

2020/01/12
初版発行。