Spring Boot 2.2.x の Web アプリを 2.3.x へバージョンアップする ( その14 )( Docker コンテナの image をバージョンアップする、Spring Boot Statistics のデータが表示されていない Panel を修正する+Dashboard に JVM (Micrometer) を追加する )
概要
記事一覧はこちらです。
- 今回の手順で確認できるのは以下の内容です。
- Grafana の Dashboard の Spring Boot Statistics にデータが表示されていない Panel があるので表示されるように修正します。
- Grafana の Dashboard に JVM (Micrometer) を追加します。
参照したサイト・書籍
Actuator metrics do not include http.server.requests
https://stackoverflow.com/questions/60345738/actuator-metrics-do-not-include-http-server-requestsmicrometer-metrics / micrometer
https://github.com/micrometer-metrics/micrometerSpring Boot default metrics
https://tomgregory.com/spring-boot-default-metrics/
目次
手順
Spring Boot Statistics のデータが表示されていない Panel を修正する
docker-compose up -d
コマンドでコンテナを起動+IntelliJ IDEA から Web アプリを起動して作業します。
Process Open Files
Edit 画面で参照している metrics を確認すると process_files_open
、process_files_max
の2つでした。
http://localhost:8080/actuator/prometheus にアクセスして出力されている metrics を確認してみましたが、どちらもありません。。。
調べていた時に Actuator metrics do not include http.server.requests を見つけました。/acutator/metrics
という endpoint があるらしく、この endpoint にアクセスすると取得可能な metrics 一覧が出力されますが process_files_open
ではなく process.files.open
と表示されるようです。
micrometer-metrics / micrometer で process.files.open
で検索してみると micrometer/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/system/FileDescriptorMetrics.java がヒットしましたが、この中に this.osBeanClass = getFirstClassFound(UNIX_OPERATING_SYSTEM_BEAN_CLASS_NAMES);
というコードがありました。おそらく Web アプリを Unix 系の OS で動作させた時しか process_files_open
、process_files_max
は取れないのでしょう。
試してみます。まず /acutator/metrics
の endpoint を使用できるようにするために src/main/resources/application.properties の management.endpoints.web.exposure.include に metrics
を追加します。
.......... management.endpoints.web.exposure.include=health,info,loggers,prometheus,metrics management.metrics.tags.application=lending ..........
コンテナで Web アプリを起動する時の JDK を AdoptOpenJDK 11.0.9.1+1 にします。docker/app/Dockerfile の以下の点を変更します。
FROM adoptopenjdk/openjdk11:jdk-11.0.9.1_1-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.5_10-alpine-slim
→FROM adoptopenjdk/openjdk11:jdk-11.0.9.1_1-alpine-slim
に変更します。
app コンテナを起動する時の jar ファイルを ksbysample-webapp-lending-2.3.7-RELEASE.jar にします。docker-compose.app.yml の以下の点を変更します。
app: build: context: . dockerfile: docker/app/Dockerfile image: ksbysample-webapp-lending volumes: - ./build/libs/ksbysample-webapp-lending-2.3.7-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.3.2-alpine container_name: haproxy-app volumes: - ./docker/app/haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg:ro ports: - "8080:8080" depends_on: - app ..........
- app コンテナの volumes の設定で
- ./build/libs/ksbysample-webapp-lending-2.2.2-RELEASE.jar:/app.jar
→- ./build/libs/ksbysample-webapp-lending-2.3.7-RELEASE.jar:/app.jar
に変更します。 - haproxy-app コンテナの image の設定で
haproxy:2.1.2-alpine
→haproxy:2.3.2-alpine
に変更します。
以下の手順で Alpine Linux 上で Web アプリを起動します。
- Gradle の build コマンドで ksbysample-webapp-lending-2.3.7-RELEASE.jar を生成する。
docker-compose -f docker-compose.app.yml --compatibility build --no-cache
コマンドを実行して app コンテナ起動用の Docker image を作成する。docker-compose -f docker-compose.mail.yml up -d
コマンドを実行してメールサーバのコンテナを起動する。docker-compose -f docker-compose.app.yml --compatibility up -d
コマンドを実行して app コンテナを起動する。
http://localhost:8080/actuator/metrics にアクセスすると以下の JSON が出力され、process.files.open
、process.files.max
が入っていました。
{ "names": [ "hikaricp.connections", "hikaricp.connections.acquire", "hikaricp.connections.active", "hikaricp.connections.creation", "hikaricp.connections.idle", "hikaricp.connections.max", "hikaricp.connections.min", "hikaricp.connections.pending", "hikaricp.connections.timeout", "hikaricp.connections.usage", "http.server.requests", "jdbc.connections.active", "jdbc.connections.idle", "jdbc.connections.max", "jdbc.connections.min", "jvm.buffer.count", "jvm.buffer.memory.used", "jvm.buffer.total.capacity", "jvm.classes.loaded", "jvm.classes.unloaded", "jvm.gc.live.data.size", "jvm.gc.max.data.size", "jvm.gc.memory.allocated", "jvm.gc.memory.promoted", "jvm.gc.pause", "jvm.memory.committed", "jvm.memory.max", "jvm.memory.used", "jvm.threads.daemon", "jvm.threads.live", "jvm.threads.peak", "jvm.threads.states", "logback.events", "process.cpu.usage", "process.files.max", "process.files.open", "process.start.time", "process.uptime", "rabbitmq.acknowledged", "rabbitmq.acknowledged_published", "rabbitmq.channels", "rabbitmq.connections", "rabbitmq.consumed", "rabbitmq.failed_to_publish", "rabbitmq.not_acknowledged_published", "rabbitmq.published", "rabbitmq.rejected", "rabbitmq.unrouted_published", "system.cpu.count", "system.cpu.usage", "system.load.average.1m", "tomcat.sessions.active.current", "tomcat.sessions.active.max", "tomcat.sessions.alive.max", "tomcat.sessions.created", "tomcat.sessions.expired", "tomcat.sessions.rejected" ] }
ただし Prometheus の画面で検索すると process_files_open
はなく process_files_open_files
になっていました。process_files_max
も process_files_max_files
でした。
Edit 画面で参照する metrics を process_files_open_files
、process_files_max_files
に変更すると「Process Open Files」に metrics が表示されるようになりました。
$memory_pool_nonheap (non-heap)
Edit 画面で参照している metrics を確認すると以下の Query が記述されていました。
jvm_memory_used_bytes{instance="$instance", application="$application", id="$memory_pool_nonheap"}
jvm_memory_committed_bytes{instance="$instance", application="$application", id="$memory_pool_nonheap"}
jvm_memory_max_bytes{instance="$instance", application="$application", id="$memory_pool_nonheap"}
Query で使用されている Variable $memory_pool_nonheap
の定義を見ると以下のようになっていました。「Preview of values」に値が複数表示されています。
Query で参照している Variable $memory_pool_nonheap
が復数の値を返すのに、Query で単一の値が返る想定の記述がされているのが原因でした。 id="$memory_pool_nonheap"
→ id=~"$memory_pool_nonheap"
のように変更することにします。
Classes Loaded、Classes Unloaded
Edit 画面で参照している metrics を確認すると以下の Query が記述されていました。
irate(jvm_classes_unloaded_total{instance="$instance", application="$application"}[5m])
jvm_classes_loaded{instance="$instance", application="$application"}
Prometheus の画面で確認すると jvm_classes_unloaded_total
→ jvm_classes_unloaded_classes_total
、jvm_classes_loaded
→ jvm_classes_loaded_classes
に変更されていました。
Edit 画面で参照している metrics を修正します。
Threads
Edit 画面で参照している metrics を確認すると以下の Query が記述されていました。
jvm_threads_daemon{instance="$instance", application="$application"}
jvm_threads_live{instance="$instance", application="$application"}
jvm_threads_peak{instance="$instance", application="$application"}
Prometheus の画面で確認すると jvm_threads_daemon
→ jvm_threads_daemon_threads
、jvm_threads_live
→ jvm_threads_live_threads
、jvm_threads_peak
→ jvm_threads_peak_threads
に変更されていました。
Edit 画面で参照している metrics を修正します。
「HikariCP Statistics」の下の全ての Panel
今見たら表示されていました。IntelliJ IDEA から Web アプリを起動している時は表示されず、jar ファイルから起動している時は表示される metrics でした(Windows でも Linux でも表示されました)。
「HTTP Statistics」の下の全ての Panel
こちらも今見たら表示されていました。IntelliJ IDEA から Web アプリを起動している時は表示されず、jar ファイルから起動している時は表示される metrics でした(Windows でも Linux でも表示されました)。
「Tomcat Statistics」の下の全ての Panel
Edit 画面で参照している metrics を確認すると以下の Query が記述されていました。
- Total Error Count
tomcat_global_error_total{instance="$instance", application="$application"}
- Thread Config Max
tomcat_threads_config_max{instance="$instance", application="$application"}
- Active Sessions
tomcat_sessions_active_current{instance="$instance", application="$application"}
- Sent & Recieved Bytes
irate(tomcat_global_sent_bytes_total{instance="$instance", application="$application"}[5m])
irate(tomcat_global_received_bytes_total{instance="$instance", application="$application"}[5m])
- Threads
tomcat_threads_current{instance="$instance", application="$application"}
tomcat_threads_busy{instance="$instance", application="$application"}
Prometheus の画面で確認すると tomcat_sessions_active_current
は tomcat_sessions_active_current_sessions
に変更すれば良いのですが、それ以外の metrics はそもそも出力されていませんでした。
Web で検索すると Disable Tomcat's MBean Registry by default and provide a property to enable it の Issue が見つかり、Spring Boot の Manual の Common Application properties の 11. Server Properties に server.tomcat.mbeanregistry.enabled
が見つかりました。default は false なので true にすれば良いようです。
src/main/resources/application.properties に server.tomcat.mbeanregistry.enabled=true
を追加します。
.......... management.endpoints.web.exposure.include=health,info,loggers,prometheus,metrics management.metrics.tags.application=lending management.endpoint.health.show-details=always management.endpoint.health.probes.enabled=true management.endpoint.health.group.liveness.include=livenessStateProbeIndicator,cacheCheck management.endpoint.health.group.readiness.include=readinessStateProbeIndicator,cacheCheck server.tomcat.mbeanregistry.enabled=true ..........
Gradle の build タスクを実行して jar ファイルを作成し直した後、docker-compose -f docker-compose.app.yml --compatibility down
、docker-compose -f docker-compose.app.yml --compatibility up -d
コマンドを実行して app コンテナを再起動します。
最後に Grafana の Edit 画面で参照する metrics を以下のように変更すると表示されるようになりました。
- Total Error Count
tomcat_global_error_total{instance="$instance", application="$application"}
- Thread Config Max
tomcat_threads_config_max_threads{instance="$instance", application="$application"}
- Active Sessions
tomcat_sessions_active_current_sessions{instance="$instance", application="$application"}
- Sent & Recieved Bytes
irate(tomcat_global_sent_bytes_total{instance="$instance", application="$application"}[5m])
irate(tomcat_global_received_bytes_total{instance="$instance", application="$application"}[5m])
- Threads
tomcat_threads_current_threads{instance="$instance", application="$application"}
tomcat_threads_busy_threads{instance="$instance", application="$application"}
Dashboard に JVM (Micrometer) を追加する
「Import」画面で「Import via grafana.com」に 4701
を入力して import します。
JVM (Micrometer) の画面が表示されます(面倒なので画面キャプチャは1画面目のみ)。
履歴
2020/12/20
初版発行。
Spring Boot 2.2.x の Web アプリを 2.3.x へバージョンアップする ( その13 )( Docker コンテナの image をバージョンアップする、Grafana の RabbitMQ 用の Dashboard を RabbitMQ Monitoring → RabbitMQ-Overview に切り替える )
概要
記事一覧はこちらです。
- 今回の手順で確認できるのは以下の内容です。
- Grafana の RabbitMQ 用の Dashboard を RabbitMQ Monitoring → RabbitMQ-Overview に切り替えます。
- RabbitMQ 3.8 から support された Monitoring with Prometheus & Grafana の機能を利用して metrics を収集する方式に変更します。rabbitmq_exporter を削除します。
参照したサイト・書籍
- Monitoring with Prometheus & Grafana
https://www.rabbitmq.com/prometheus.html
目次
- rabbitmq_prometheus plugin が有効になっていることを確認する
rabbitmq-diagnostics -q cluster_status
コマンドで Cluster Name を確認する- docker/prometheus/prometheus.yml を変更する
- docker-compose.yml を変更する
docker-compose up -d
コマンドを実行する- RabbitMQ Monitoring → RabbitMQ-Overview に切り替える
- kbudde/rabbitmq-exporter の docker image を削除する
手順
rabbitmq_prometheus plugin が有効になっていることを確認する
RabbitMQ は起動時のログに有効になっている plugin 一覧を出力してくれるので、docker-compose up -d
コマンドで起動して確認してみます。
確かに rabbitmq_prometheus が出力されていました。4つ出力されているのは前から気づいていたのですが、prometheus の文字が入った plugin があることに全く気づいていなかったですね。。。
rabbitmq-diagnostics -q cluster_status
コマンドで Cluster Name を確認する
https://www.rabbitmq.com/prometheus.html#installation を見ると rabbitmq-diagnostics -q cluster_status
コマンドで Cluster Name を確認できるようなので確認してみます。
docker exec -it rabbitmq1 /bin/sh
コマンドで rabbitmq1 コンテナに接続してから rabbitmq-diagnostics -q cluster_status
コマンドを実行すると Cluster Name は rabbit@rabbitmq1
でした。これは変更せずにこのまま進めます。
docker/prometheus/prometheus.yml を変更する
Prometheus の RabbitMQ の metrics 取得先を rabbitmq_exporter コンテナから rabbitmq1~3 コンテナに変更します。
https://www.rabbitmq.com/prometheus.html#installation に Notice that RabbitMQ exposes the metrics on a dedicated TCP port, 15692 by default.
と記述されていますので、docker/prometheus/prometheus.yml を以下のように変更します。
.......... - job_name: 'rabbitmq' static_configs: - targets: - rabbitmq1:15692 - rabbitmq2:15692 - rabbitmq3:15692 ..........
job_name: 'rabbitmq_exporter'
→job_name: 'rabbitmq'
に変更します。- targets は
['rabbitmq_exporter:9419']
の記述を削除し、以下の3行を追加します。rabbitmq1:15692
rabbitmq2:15692
rabbitmq3:15692
docker-compose.yml を変更する
rabbitmq_exporter コンテナの記述を削除します。
docker-compose up -d
コマンドを実行する
docker-compose up -d
コマンドを実行してコンテナを起動します。
RabbitMQ Monitoring → RabbitMQ-Overview に切り替える
「Import」画面で「Import via grafana.com」に 10991
を入力して import します。
RabbitMQ-Overview の画面が表示されます。
rabbitmq3 コンテナを停止すると Nodes の数が 3 → 2 に変わり、NODES の一覧から rabbitmq3 が消えました。
「Dashboards」-「Manage」の画面で「RabbitMQ Monitoring」を削除します。
kbudde/rabbitmq-exporter の docker image を削除する
以下の docker image を削除します。
- kbudde/rabbitmq-exporter:latest
履歴
2020/12/20
初版発行。
Spring Boot 2.2.x の Web アプリを 2.3.x へバージョンアップする ( その12 )( Docker コンテナの image をバージョンアップする、prometheus・grafana 編 )
概要
記事一覧はこちらです。
- 今回の手順で確認できるのは以下の内容です。
- 今回は以下の Docker コンテナの image をバージョンアップします。
- prom/prometheus
- grafana/grafana
- 今回は以下の Docker コンテナの image をバージョンアップします。
参照したサイト・書籍
目次
- docker-compose.yml を変更する
docker-compose up -d
コマンドを実行する- Grafana の各 dashboard を確認する
- PostgreSQL Statistics → PostgreSQL Database に切り替える
- Redis Dashboard for Prometheus Redis Exporter 1.x → Redis Dashboard for Prometheus Redis Exporter (helm stable/redis-ha) に切り替える
- 変更前の docker image を削除する
- 続く。。。
手順
docker-compose.yml を変更する
prometheus: image: prom/prometheus:v2.23.0 container_name: prometheus ports: - "9090:9090" # TZ=Asia/Tokyo を設定してみたが日本時間に変わらなかったのでコメントアウトしておく # environment: # - TZ=Asia/Tokyo volumes: - ./docker/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml - ./docker/prometheus/storage:/prometheus extra_hosts: - "app:${HOST_IP_ADDRESS}" grafana: image: grafana/grafana:7.3.6 container_name: grafana ports: - "3000:3000" environment: - TZ=Asia/Tokyo volumes: - ./docker/grafana/storage:/var/lib/grafana
image: prom/prometheus:v2.15.1
→image: prom/prometheus:v2.23.0
に変更します。image: grafana/grafana:6.5.2
→image: grafana/grafana:7.3.6
に変更します。
docker-compose up -d
コマンドを実行する
以下のコマンドを実行して docker image を更新・ダウンロードします(画面キャプチャはなし)。
docker-compose up -d
コマンドを実行してコンテナ一式(メールサーバ・rainloop を除く)を起動します。
Grafana の各 dashboard を確認する
PostgreSQL Statistics
- データを表示できていない Panel はありませんでした。
- 使用しているのは PostgreSQL Statistics、https://grafana.com/grafana/dashboards/6742
- 最新は Revision 1、Created July 1st 2018, 1:15 pm
- https://grafana.com/grafana/dashboards で
PostgreSQL
で検索して、ヒットした中で一番 Downloads が多いものを確認すると(AWS や Azure が付くものは除く)、PostgreSQL Database、https://grafana.com/grafana/dashboards/9628 - PostgreSQL Database の最新は Revision 6、Created December 3rd 2020, 6:02 am
- 今回は PostgreSQL Statistics を削除して PostgreSQL Database に切り替えることにします。
Prometheus Redis
- 以下の問題がありました。
- 画面上部の Variables の addr に何も表示されていませんでした。
- 以下の Panel にデータが表示されていませんでした。
- Uptime
- Clients
- Command Calls / sec
- 使用しているのは Redis Dashboard for Prometheus Redis Exporter 1.x、https://grafana.com/grafana/dashboards/763
- 最新は Revision 3、Created July 3rd 2019, 2:07 am
- https://grafana.com/grafana/dashboards で
Redis
で検索して、ヒットした中で一番 Downloads が多いものを確認すると(AWS や Azure が付くものは除く)、Redis Dashboard for Prometheus Redis Exporter (helm stable/redis-ha)、https://grafana.com/grafana/dashboards/11835 - Redis Dashboard for Prometheus Redis Exporter (helm stable/redis-ha) の最新は Revision 1、Created March 2nd 2020, 7:37 pm
- 今回は Redis Dashboard for Prometheus Redis Exporter 1.x を削除して Redis Dashboard for Prometheus Redis Exporter (helm stable/redis-ha) に切り替えることにします。
RabbitMQ Monitoring
- 以下の問題がありました。
- 以下の Panel にデータが表示されていませんでした。
- Connections, channels and consumers
- 画面上部の rabbit@rabbitmq1、rabbit@rabbitmq2、rabbit@rabbitmq3 の Panel はデータが表示されたりされなかったりします。
- 以下の Panel にデータが表示されていませんでした。
- 使用しているのは RabbitMQ Monitoring、https://grafana.com/grafana/dashboards/4279
- 最新は Revision 4、Created January 18th 2020, 12:22 am
- https://grafana.com/grafana/dashboards で
RabbitMQ
で検索して、ヒットした中で一番 Downloads が多いものを確認すると(AWS や Azure が付くものは除く)、RabbitMQ-Overview、https://grafana.com/grafana/dashboards/10991 - RabbitMQ-Overview の最新は Revision 7、Created November 13th 2020, 9:57 pm
- RabbitMQ-Overview の説明を読むと RabbitMQ 3.8 から Prometheus & Grafana がサポートされていて(Monitoring with Prometheus & Grafana に記述があります)、rabbitmq-prometheus を有効にする必要があるとのこと。
- 今回は RabbitMQ Monitoring を削除して RabbitMQ-Overview に切り替えることにします。
Spring Boot Statistics
- 以下の問題がありました。
- 以下の Panel にデータが表示されていませんでした。
- Process Open Files
- $memory_pool_nonheap (non-heap)
- Classes Loaded
- Classes Unloaded
- Threads
- 「HikariCP Statistics」の下の全ての Panel
- 「HTTP Statistics」の下の全ての Panel
- 「Tomcat Statistics」の下の全ての Panel
- 以下の Panel にデータが表示されていませんでした。
- 使用しているのは Spring Boot Statistics、https://grafana.com/grafana/dashboards/6756
- 最新は Revision 2、Created July 2nd 2018, 5:53 pm
- https://grafana.com/grafana/dashboards で
Spring Boot
で検索して、ヒットした中で一番 Downloads が多いものを確認すると(AWS や Azure が付くものは除く)、JVM (Micrometer)、https://grafana.com/grafana/dashboards/4701 - JVM (Micrometer) の最新は Revision 9、Created November 4th 2019, 1:59 am
- ただしこれは JVM の情報のみです。
- また検索結果を見ると Spring Boot Statistics、https://grafana.com/grafana/dashboards/12464 があり、
This is a fork of dashboard 6756, fixed for Spring Boot 2.3 and support for Jetty instead of Tomcat.
という記述がありました。使用しているのは Tomcat なので、これは選択できませんね。 - 今回は Spring Boot Statistics は残してデータが表示されていない Panel を修正しつつ、JVM (Micrometer) を追加してみることにします。
PostgreSQL Statistics → PostgreSQL Database に切り替える
最初に PostgreSQL Database を Dashboard に追加します。
画面左側のメニューから「Dashboards」-「Manage」をクリックします。
下の画面が表示されるので、「Import」ボタンをクリックします。
「Import」画面が表示されるので「Import via grafana.com」に 9628
を入力後「Load」ボタンをクリックします。
「DS_PROMETHEUS」で「spring-actuator」を選択した後、「Import」ボタンをクリックします。
PostgreSQL Database の画面が表示されます。画面右上を「Last 6 hours」「10s」→「Last 15 minutes」「5s」に変更しています。
次に PostgreSQL Statistics を削除します。
「Dashboards」-「Manage」の画面で「PostgreSQL Statistics」をチェックした後、「Delete」ボタンをクリックして削除します。
Redis Dashboard for Prometheus Redis Exporter 1.x → Redis Dashboard for Prometheus Redis Exporter (helm stable/redis-ha) に切り替える
「Import」画面で「Import via grafana.com」に 9628
を入力して import します。
Redis Dashboard for Prometheus Redis Exporter (helm stable/redis-ha) の画面が表示されます。画面右上を「Last 24 hours」「30s」→「Last 15 minutes」「5s」に変更しています。
「Dashboards」-「Manage」の画面で「Prometheus Redis」を削除します。
変更前の docker image を削除する
以下の docker image を削除します。
- prom/prometheus:v2.15.1
- grafana/grafana:6.5.2
続く。。。
RabbitMQ Monitoring → RabbitMQ-Overview 切替、Spring Boot Statistics のデータが表示されていない Panel の修正+JVM (Micrometer) 追加、の2つは次回以降に記載します。
履歴
2020/12/19
初版発行。
2020/12/20
変更前の docker image を削除する を追加しました。
Spring Boot 2.2.x の Web アプリを 2.3.x へバージョンアップする ( その11 )( Docker コンテナの image をバージョンアップする、rabbitmq・haproxy・rabbitmq_exporter 編 )
概要
記事一覧はこちらです。
- 今回の手順で確認できるのは以下の内容です。
- 今回は以下の Docker コンテナの image をバージョンアップします。
- rabbitmq
- haproxy
- kbudde/rabbitmq-exporter
- 今回は以下の Docker コンテナの image をバージョンアップします。
参照したサイト・書籍
chmod not working correctly in Docker
https://serverfault.com/questions/772227/chmod-not-working-correctly-in-dockerClustering Guide
https://www.rabbitmq.com/clustering.htmldocker-library / rabbitmq
https://github.com/docker-library/rabbitmqCentOS7 RabbitMQ 3.7.4 cluster installation and use
https://www.programmersought.com/article/13654537027/Authentication, Authorisation, Access Control
https://www.rabbitmq.com/access-control.htmlConfiguration
https://www.rabbitmq.com/configure.htmlrabbitmqctl(8)
https://www.rabbitmq.com/rabbitmqctl.8.html#forget_cluster_nodeRabbitMQ cluster maintenance
https://docs.openstack.org/openstack-ansible/pike/admin/maintenance-tasks/rabbitmq-maintain.html
目次
- .env を変更する
- docker-compose.yml を変更する
docker-compose up -d
コマンドを実行する- rabbitmq が起動しない。。。
- 環境変数 RABBITMQ_ERLANG_COOKIE をやめて .erlang.cookie file に変更する
HTTP access denied: user 'rabbitmq' - invalid credentials
が出力されないようにする+管理画面からログインできるようにする- clean タスク実行 → Rebuild Project 実行 → build タスクを実行する
- 変更前の docker image を削除する
手順
.env を変更する
.......... RABBITMQ_VERSION=3.8.9-management RABBITMQ_ERLANG_COOKIE=Uzkm93w5e1Lz8AcP RABBITMQ_DEFAULT_USER=rabbitmq RABBITMQ_DEFAULT_PASS=12345678 RABBITMQ_DEFAULT_VHOST=/ ..........
RABBITMQ_VERSION=3.8.2-management
→RABBITMQ_VERSION=3.8.9-management
に変更します。
docker-compose.yml を変更する
.......... # http://localhost:1936/haproxy?stats haproxy: image: haproxy:2.3.2-alpine container_name: haproxy ports: - "1936:1936" - "5672:5672" - "15672:15672" environment: - TZ=Asia/Tokyo volumes: - ./docker/rabbitmq/haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg:ro depends_on: - rabbitmq1 - rabbitmq2 - rabbitmq3 ..........
image: haproxy:2.1.2-alpine
→image: haproxy:2.3.2-alpine
に変更します。
docker-compose up -d
コマンドを実行する
以下のコマンドを実行して docker image を更新・ダウンロードします(画面キャプチャはなし)。
docker-compose build --no-cache
コマンドを実行し、Dockerfile で作成している image を更新します。- kbudde/rabbitmq-exporter は latest の docker image をダウンロードしているので、ローカルの docker image を削除します。
docker-compose up -d
コマンドを実行してコンテナ一式(メールサーバ・rainloop を除く)を起動します。
rabbitmq が起動しない。。。
docker-compose up -d
コマンドを実行した後、haproxy の画面で rabbitmq が起動するのを待っても rabbitmq2、rabbitmq3 がいつまでたっても起動しません。
IntelliJ IDEA でコンテナの状況を確認すると rabbitmq2、rabbitmq3 は停止しており、
RABBITMQ_ERLANG_COOKIE env variable support is deprecated and will be REMOVED in a future version. Use the $HOME/.erlang.cookie file or the --erlang-cookie switch instead.
というログが出力されていました。ただし、あくまでも deprecated なので起動しない原因ではないようです。- 起動しない理由は以下3つのいずれかのようです。
Target node is unreachable (e.g. due to hostname resolution, TCP connection or firewall issues)
CLI tool fails to authenticate with the server (e.g. due to CLI tool's Erlang cookie not matching that of the server)
Target node is not running
環境変数 RABBITMQ_ERLANG_COOKIE をやめて .erlang.cookie file に変更する
deprecated のメッセージが出ているので、先に環境変数 RABBITMQ_ERLANG_COOKIE をやめて .erlang.cookie file に変更します。
docker/rabbitmq の下に .erlang.cookie を新規作成し、以下の内容を記述します。
Uzkm93w5e1Lz8AcP
.env から RABBITMQ_ERLANG_COOKIE=Uzkm93w5e1Lz8AcP
を削除します。
RABBITMQ_VERSION=3.8.9-management RABBITMQ_DEFAULT_USER=rabbitmq RABBITMQ_DEFAULT_PASS=12345678 RABBITMQ_DEFAULT_VHOST=/
docker-compose.yml の rabbitmq1、rabbitmq2、rabbitmq3 の environment から - RABBITMQ_ERLANG_COOKIE
を削除します。
# RabbitMQ Clustering rabbitmq1: build: context: ./docker/rabbitmq args: - RABBITMQ_VERSION=${RABBITMQ_VERSION} image: rabbitmq:${RABBITMQ_VERSION}-alpine-custom container_name: rabbitmq1 hostname: rabbitmq1 environment: - TZ=Asia/Tokyo - RABBITMQ_DEFAULT_USER - RABBITMQ_DEFAULT_PASS - RABBITMQ_DEFAULT_VHOST rabbitmq2: image: rabbitmq:${RABBITMQ_VERSION}-alpine-custom container_name: rabbitmq2 hostname: rabbitmq2 environment: - TZ=Asia/Tokyo volumes: - ./docker/rabbitmq/cluster-entrypoint.sh:/usr/local/bin/cluster-entrypoint.sh entrypoint: /bin/sh -c /usr/local/bin/cluster-entrypoint.sh depends_on: - rabbitmq1 rabbitmq3: image: rabbitmq:${RABBITMQ_VERSION}-alpine-custom container_name: rabbitmq3 hostname: rabbitmq3 environment: - TZ=Asia/Tokyo volumes: - ./docker/rabbitmq/cluster-entrypoint.sh:/usr/local/bin/cluster-entrypoint.sh entrypoint: /usr/local/bin/cluster-entrypoint.sh depends_on: - rabbitmq1
https://www.rabbitmq.com/clustering.html#cookie-file-locations を見ると .erlang.cookie は /var/lib/rabbitmq/.erlang.cookie に配置すると記述されているので、docker/rabbitmq/Dockerfile を以下のように変更します。
ARG RABBITMQ_VERSION FROM rabbitmq:${RABBITMQ_VERSION}-alpine RUN apk add --no-cache tzdata COPY .erlang.cookie /var/lib/rabbitmq/
COPY .erlang.cookie /var/lib/rabbitmq/
を追加します。
docker-compose build --no-cache
コマンドを実行してから docker-compose up -d
コマンドを実行します。。。が、Cookie file /var/lib/rabbitmq/.erlang.cookie must be accessible by owner only
というメッセージが表示されて rabbitmq が起動しません。
docker/rabbitmq/Dockerfile の最後に RUN ls -al /var/lib/rabbitmq/
を追加して .erlang.cookie の owner、permission を確認すると -rwxr-xr-x 1 root root
でした。
owner/group は https://github.com/docker-library/rabbitmq/blob/master/3.8/alpine/Dockerfile を見ると addgroup、adduser コマンドで rabbitmq
が指定されており、permission は -rw-------
にすれば良いはずなので、docker/rabbitmq/Dockerfile を以下のように変更してみます。
ARG RABBITMQ_VERSION FROM rabbitmq:${RABBITMQ_VERSION}-alpine RUN apk add --no-cache tzdata COPY --chown=rabbitmq:rabbitmq .erlang.cookie /var/lib/rabbitmq/ RUN chmod 600 /var/lib/rabbitmq/.erlang.cookie RUN ls -al /var/lib/rabbitmq/
- COPY コマンドに
--chown=rabbitmq:rabbitmq
オプションを追加します。 RUN chmod 600 /var/lib/rabbitmq/.erlang.cookie
を追加します。
docker-compose build --no-cache
コマンドを実行すると owner、group は rabbitmq
に変更されましたが、permission は -rwxr-xr-x
のままでした。。。
この permission を変更する方法が最初全然分からなかったのですが、いろいろ検索してみた結果、以下の方法で解消できました。
- chmod not working correctly in Docker を読むと
VOLUME /var/lib/rabbitmq
が指定されているから RUN コマンドで chmod できないらしい。VOLUME コマンドで指定していないディレクトリで chmod してからコピーすればよいとのこと。VOLUME /var/lib/rabbitmq
が指定されているのは https://github.com/docker-library/rabbitmq/blob/master/3.8/alpine/Dockerfile 参照。
ただし Dockerfile 内で
COPY --chown=rabbitmq:rabbitmq .erlang.cookie /tmp/
、RUN chmod 600 /tmp/.erlang.cookie
の後にRUN cp -p /tmp/.erlang.cookie /var/lib/rabbitmq/
を実行してもコピーされませんでした。これは Dockerfile ではなくコンテナ起動時に command あるいは entrypoint で実行するシェルスクリプトでやればコピーできます。
最終的に以下のようになりました。
■docker/rabbitmq/Dockerfile
ARG RABBITMQ_VERSION FROM rabbitmq:${RABBITMQ_VERSION}-alpine RUN apk add --no-cache tzdata COPY --chown=rabbitmq:rabbitmq .erlang.cookie /tmp/ RUN chmod 600 /tmp/.erlang.cookie
- 以下の2行を追加しました。.erlang.cookie を /tmp にコピー後、owner を rabbitmq:rabbitmq へ、permission を
-rw-------
へ変更します。COPY --chown=rabbitmq:rabbitmq .erlang.cookie /tmp/
RUN chmod 600 /tmp/.erlang.cookie
■docker-compose.yml
# RabbitMQ Clustering rabbitmq1: build: context: ./docker/rabbitmq args: - RABBITMQ_VERSION=${RABBITMQ_VERSION} image: rabbitmq:${RABBITMQ_VERSION}-alpine-custom container_name: rabbitmq1 hostname: rabbitmq1 environment: - TZ=Asia/Tokyo - RABBITMQ_DEFAULT_USER - RABBITMQ_DEFAULT_PASS - RABBITMQ_DEFAULT_VHOST command: - /bin/sh - -c - | cp -p /tmp/.erlang.cookie /var/lib/rabbitmq/ ls -al /var/lib/rabbitmq/ rabbitmq-server rabbitmq2: image: rabbitmq:${RABBITMQ_VERSION}-alpine-custom container_name: rabbitmq2 hostname: rabbitmq2 environment: - TZ=Asia/Tokyo volumes: - ./docker/rabbitmq/cluster-entrypoint.sh:/usr/local/bin/cluster-entrypoint.sh entrypoint: /usr/local/bin/cluster-entrypoint.sh depends_on: - rabbitmq1 rabbitmq3: image: rabbitmq:${RABBITMQ_VERSION}-alpine-custom container_name: rabbitmq3 hostname: rabbitmq3 environment: - TZ=Asia/Tokyo volumes: - ./docker/rabbitmq/cluster-entrypoint.sh:/usr/local/bin/cluster-entrypoint.sh entrypoint: /usr/local/bin/cluster-entrypoint.sh depends_on: - rabbitmq1
- rabbitmq1 に command を追加しました。ここで /tmp/.erlang.cookie を /var/lib/rabbitmq/ の下へコピーした後、rabbitmq-server を起動します。
- rabbitmq2 の entrypoint を
/bin/sh -c /usr/local/bin/cluster-entrypoint.sh
→/usr/local/bin/cluster-entrypoint.sh
に修正しました(rabbitmq3 と違っていたのと /bin/sh -c があるとなぜかうまく動作しなかったためです)。
■docker/rabbitmq/cluster-entrypoint.sh
#!/bin/bash set -e cp -p /tmp/.erlang.cookie /var/lib/rabbitmq/ ls -al /var/lib/rabbitmq/ rabbitmq-diagnostics erlang_cookie_sources # Start RMQ from entry point. # This will ensure that environment variables passed # will be honored rabbitmq-server -detached # Wait a while for rabbitmq1 to start sleep 15s # Do the cluster dance rabbitmqctl stop_app rabbitmqctl reset rabbitmqctl join_cluster rabbit@rabbitmq1 # Stop the entire RMQ server. This is done so that we # can attach to it again, but without the -detached flag # making it run in the forground rabbitmqctl stop # Wait a while for the app to really stop sleep 3s # Start it rabbitmq-server
- 以下の3行を追加しました。/tmp/.erlang.cookie を /var/lib/rabbitmq/ の下へコピーします。また https://www.rabbitmq.com/clustering.html#cookie-file-troubleshooting に .erlang.cookie をチェックするコマンドが記載されていたのでそれも追加します。
cp -p /tmp/.erlang.cookie /var/lib/rabbitmq/
ls -al /var/lib/rabbitmq/
rabbitmq-diagnostics erlang_cookie_sources
/usr/local/bin/docker-entrypoint.sh rabbitmq-server -detached
→rabbitmq-server -detached
に変更します(/usr/local/bin/docker-entrypoint.sh
がなくても動いたので削除しました)。また rabbitmq1 の起動が完了するまで時間がかかるためsleep 15s
を追加しました。- https://www.rabbitmq.com/clustering.html#creating に記載があったので
rabbitmqctl reset
を追加しました。 rabbitmqctl stop
の後の待機時間をsleep 2s
→sleep 3s
に変更しました。
docker-compose build --no-cache
コマンドを実行してから docker-compose up -d
コマンドを実行すると無事 rabbitmq1、rabbitmq2、rabbitmq3 の全てが起動しました。
rabbitmq2 のログを見ると RABBITMQ_ERLANG_COOKIE env variable support is deprecated ...
のメッセージは出力されておらずサーバが問題なく起動していますが、今度は HTTP access denied: user 'rabbitmq' - invalid credentials
という warning が延々と出力されていました(この warning は rabbitmq1、rabbitmq3 にも出力されています)。
rabbitmq の管理画面から rabbitmq / 12345678 でログインしようしてもログインできませんでした。
HTTP access denied: user 'rabbitmq' - invalid credentials
が出力されないようにする+管理画面からログインできるようにする
使っている RabbitMQ のバージョンは違いますが、CentOS7 RabbitMQ 3.7.4 cluster installation and use の記事を見つけました。「Report an error」のところに記述があり、rabbitmqctl add_user
コマンドで rabbitmq ユーザを作成すればよいみたいです。
docker-compose.yml の rabbitmq1 コンテナの command で rabbitmqctl add_user
コマンドを実行してもエラーが出て登録できなかったので、rabbitmqctl add_user
コマンド実行用のコンテナを作成して対応することにします。
docker/rabbitmq の下に create-user-entrypoint.sh を新規作成し、以下の内容を記述します。sleep の時間は 15s だと rabbitmq1 が起動完了する前に rabbitmqctl add_user
コマンドを実行する時があったのでここでは 30s にしました。
#!/bin/bash set -e cp -p /tmp/.erlang.cookie /var/lib/rabbitmq/ ls -al /var/lib/rabbitmq/ rabbitmq-diagnostics erlang_cookie_sources # Wait a while for rabbitmq1 to start sleep 30s rabbitmqctl -n rabbit@rabbitmq1 add_user ${RABBITMQ_DEFAULT_USER} ${RABBITMQ_DEFAULT_PASS} rabbitmqctl -n rabbit@rabbitmq1 set_user_tags ${RABBITMQ_DEFAULT_USER} administrator rabbitmqctl -n rabbit@rabbitmq1 set_permissions -p / ${RABBITMQ_DEFAULT_USER} ".*" ".*" ".*"
docker-compose.yml に rabbitmq-create-user コンテナの記述を追加します。
# RabbitMQ Clustering rabbitmq1: build: context: ./docker/rabbitmq args: - RABBITMQ_VERSION=${RABBITMQ_VERSION} image: rabbitmq:${RABBITMQ_VERSION}-alpine-custom container_name: rabbitmq1 hostname: rabbitmq1 environment: - TZ=Asia/Tokyo - RABBITMQ_DEFAULT_USER - RABBITMQ_DEFAULT_PASS - RABBITMQ_DEFAULT_VHOST command: - /bin/sh - -c - | cp -p /tmp/.erlang.cookie /var/lib/rabbitmq/ ls -al /var/lib/rabbitmq/ rabbitmq-server rabbitmq-create-user: image: rabbitmq:${RABBITMQ_VERSION}-alpine-custom container_name: rabbitmq-create-user hostname: rabbitmq-create-user environment: - TZ=Asia/Tokyo - RABBITMQ_DEFAULT_USER - RABBITMQ_DEFAULT_PASS volumes: - ./docker/rabbitmq/create-user-entrypoint.sh:/usr/local/bin/create-user-entrypoint.sh entrypoint: /usr/local/bin/create-user-entrypoint.sh depends_on: - rabbitmq1 rabbitmq2: ..........
- 作成するユーザ名、パスワードは環境変数 RABBITMQ_DEFAULT_USER、RABBITMQ_DEFAULT_PASS の設定をそのまま使っています。
- rabbitmq1 コンテナの environment の RABBITMQ_DEFAULT_USER、RABBITMQ_DEFAULT_PASS は不要なのでは?と思って削除したらエラーが出たので残しています。
動作確認します。docker-compose up -d
コマンドを実行して起動した後、
rabbitmq-create-user コンテナのログを確認すると rabbitmqctl add_user
コマンド等は全て正常に実行できており、
rabbitmq1、rabbitmq2 コンテナのログを見ると HTTP access denied: user 'rabbitmq' - invalid credentials
は出力されていません。
http://localhost:15672/ にアクセスして rabbitmq / 12345678 でログインすると無事ログインできました。
rabbitmq_exporter の方は、Grafana で RabbitMQ の情報を表示させてみると問題なさそうです。
clean タスク実行 → Rebuild Project 実行 → build タスクを実行する
clean タスク実行 → Rebuild Project 実行 → build タスクを実行すると無事 "BUILD SUCCESSFUL" のメッセージが出力されました。
変更前の docker image を削除する
以下の docker image を削除します。
- rabbitmq:3.8.2-management-alpine
- rabbitmq:3.8.2-management-alpine-custom
履歴
2020/12/18
初版発行。
2020/12/19
ユーザを作成できない場合があったため、docker/rabbitmq/create-user-entrypoint.sh 内の rabbitmq1 の起動待機時間を sleep 20s
→ sleep 30s
に変更しました。
Spring Boot 2.2.x の Web アプリを 2.3.x へバージョンアップする ( その10 )( Spring Boot を 2.3.2 → 2.3.7 へバージョンアップする+Docker コンテナの image をバージョンアップする、redis・redis_exporter 編 )
概要
記事一覧はこちらです。
- 今回の手順で確認できるのは以下の内容です。
- Spring Boot を 2.3.2 → 2.3.7 へバージョンアップします。
- 今回は以下の Docker コンテナの image をバージョンアップします。
- redis
- oliver006/redis_exporter
- Redis を 5 → 6 にバージョンアップしますが、spring-boot-starter-data-redis が利用している lettuce-core の release notes を見ると
Lettuce 6 supports Redis 2.6+ up to Redis 6.x.
の記述が出てくるのは 5.3.5.RELEASE からでした。現時点では spring-boot-starter-data-reids が 2.3.2.RELEASE、lettuce-core が 5.3.2-RELEASE であり、lettuce-core が 5.3.5-RELEASE になるのは spring-boot-starter-data-reids:2.3.5.RELEASE 以降です。 - Redis のバージョンアップの前に Spring Boot を 2.3.2 → 2.3.7 へバージョンアップすることにします。
- Redis 6.0.0 GA アップデート内容紹介 を読むと Redis 6 でかなり大きな機能追加が行われているとのことですが、この追加機能が利用できるようになるのが lettuce-core の 6.0.0 以降でした。lettuce-core が 6.0.0 以降になるのは Spring Boot 2.4 からなので、2.4 系にバージョンアップした時に新機能を試してみようと思います。
参照したサイト・書籍
Redis 6.0 release notes - GitHub
https://www.google.com/search?q=redis+6&oq=redis+6&aqs=chrome..69i57j35i39j0i457j0l2j69i60l3.1648j0j7&sourceid=chrome&ie=UTF-8Redis 6.0.0 GA アップデート内容紹介
https://qiita.com/maruloop/items/d1638fbf78afc95f0ad5Releases · lettuce-io/lettuce-core · GitHub
https://github.com/lettuce-io/lettuce-core/releases
目次
- Spring Boot を 2.3.2 → 2.3.7 へバージョンアップする
- .env を変更する
- docker-compose.yml を変更する
docker-compose up -d
コマンドを実行する- clean タスク実行 → Rebuild Project 実行 → build タスクを実行する
- 変更前の docker image を削除する
手順
Spring Boot を 2.3.2 → 2.3.7 へバージョンアップする
build.gradle の以下の点を変更します。
buildscript { ext { group "ksbysample" version "2.3.7-RELEASE" } repositories { mavenCentral() maven { url "https://repo.spring.io/release/" } gradlePluginPortal() } } plugins { id "java" id "eclipse" id "idea" id "org.springframework.boot" version "2.3.7.RELEASE" id "io.spring.dependency-management" version "1.0.10.RELEASE" id "groovy" id "checkstyle" id "com.github.spotbugs" version "4.5.0" id "pmd" id "net.ltgt.errorprone" version "1.2.1" id "com.gorylenko.gradle-git-properties" version "2.2.3" } ..........
- buildscript block の以下の点を変更します。
version "2.3.2-RELEASE"
→version "2.3.7-RELEASE"
- plugins block の以下の点を変更します。
id "org.springframework.boot" version "2.3.2.RELEASE"
→id "org.springframework.boot" version "2.3.7.RELEASE"
id "io.spring.dependency-management" version "1.0.9.RELEASE"
→id "io.spring.dependency-management" version "1.0.10.RELEASE"
Gradle Tool Window の左上にある「Refresh all Gradle projects」ボタンをクリックして更新した後、clean タスク実行 → Rebuild Project 実行 → build タスクを実行すると "BUILD SUCCESSFUL" のメッセージが出力されました。
gradlew dependencies
を実行すると io.lettuce:lettuce-core:5.3.5.RELEASE
が依存関係に追加されていることが確認できます。
+--- org.springframework.boot:spring-boot-starter-data-redis -> 2.3.7.RELEASE | +--- org.springframework.boot:spring-boot-starter:2.3.7.RELEASE (*) | +--- org.springframework.data:spring-data-redis:2.3.6.RELEASE | | +--- org.springframework.data:spring-data-keyvalue:2.3.6.RELEASE | | | +--- org.springframework.data:spring-data-commons:2.3.6.RELEASE (*) | | | +--- org.springframework:spring-context:5.2.12.RELEASE (*) | | | +--- org.springframework:spring-tx:5.2.12.RELEASE (*) | | | \--- org.slf4j:slf4j-api:1.7.26 -> 1.7.30 | | +--- org.springframework:spring-tx:5.2.12.RELEASE (*) | | +--- org.springframework:spring-oxm:5.2.12.RELEASE | | | +--- org.springframework:spring-beans:5.2.12.RELEASE (*) | | | \--- org.springframework:spring-core:5.2.12.RELEASE (*) | | +--- org.springframework:spring-aop:5.2.12.RELEASE (*) | | +--- org.springframework:spring-context-support:5.2.12.RELEASE (*) | | \--- org.slf4j:slf4j-api:1.7.26 -> 1.7.30 | \--- io.lettuce:lettuce-core:5.3.5.RELEASE | +--- io.netty:netty-common:4.1.53.Final -> 4.1.55.Final | +--- io.netty:netty-handler:4.1.53.Final -> 4.1.55.Final | | +--- io.netty:netty-common:4.1.55.Final | | +--- io.netty:netty-resolver:4.1.55.Final | | | \--- io.netty:netty-common:4.1.55.Final | | +--- io.netty:netty-buffer:4.1.55.Final | | | \--- io.netty:netty-common:4.1.55.Final | | +--- io.netty:netty-transport:4.1.55.Final | | | +--- io.netty:netty-common:4.1.55.Final | | | +--- io.netty:netty-buffer:4.1.55.Final (*) | | | \--- io.netty:netty-resolver:4.1.55.Final (*) | | \--- io.netty:netty-codec:4.1.55.Final | | +--- io.netty:netty-common:4.1.55.Final | | +--- io.netty:netty-buffer:4.1.55.Final (*) | | \--- io.netty:netty-transport:4.1.55.Final (*) | +--- io.netty:netty-transport:4.1.53.Final -> 4.1.55.Final (*) | \--- io.projectreactor:reactor-core:3.3.11.RELEASE -> 3.3.12.RELEASE | \--- org.reactivestreams:reactive-streams:1.0.3
.env を変更する
.......... REDIS_VERSION=6.0.9 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 ..........
REDIS_VERSION=5.0.7
→REDIS_VERSION=6.0.9
に変更します。
docker-compose.yml を変更する
redis_exporter: image: oliver006/redis_exporter:v1.14.0-alpine container_name: redis_exporter ports: - "9121:9121"
image: oliver006/redis_exporter:v1.3.5-alpine
→image: oliver006/redis_exporter:v1.14.0-alpine
に変更します。
docker-compose up -d
コマンドを実行する
以下のコマンドを実行して docker image をダウンロード+Redis Cluster を起動します(画面キャプチャはなし)。
docker-compose up -d
コマンドを実行してコンテナ一式(メールサーバ・rainloop を除く)を起動します。
redis-cluster-6379 ~ 6384 のコンテナは起動したままになっており、redis-cluster-make コンテナのログを確認すると問題なく Redis Cluster が構成できているようです。
Spring Boot 1.5.x の Web アプリを 2.0.x へバージョンアップする ( その19 )( Docker で Redis の環境を構築する2(Redis Cluster 構成)) を参考に docker exec -it redis-cluster-6379 redis-cli
コマンドで redis-cli を起動してから cluster nodes
コマンドを実行すると master が3台、slave が3台あることが確認できます。
Spring Boot のアプリケーションを起動してから Endpoints - Health の redis の情報を確認すると cluster_size に 3 と表示されていました。
redis_exporter の方は、Grafana で Redis の情報を表示させてみると metrics は取得できているようですが、一部エラーが出ていました。今はこのままにして prometheus・grafana をバージョンアップする時に修正します。
clean タスク実行 → Rebuild Project 実行 → build タスクを実行する
clean タスク実行 → Rebuild Project 実行 → build タスクを実行すると無事 "BUILD SUCCESSFUL" のメッセージが出力されました。
変更前の docker image を削除する
以下の docker image を削除します。
- redis:5.0.7-alpine
- redis:5.0.7-custom
- oliver006/redis_exporter:v1.3.5-alpine
履歴
2020/12/14
初版発行。
Spring Boot 2.2.x の Web アプリを 2.3.x へバージョンアップする ( その9 )( Docker コンテナの image をバージョンアップする、postgres・pgadmin4・flyway・docker-mailserver 編 )
概要
記事一覧はこちらです。
Spring Boot 2.2.x の Web アプリを 2.3.x へバージョンアップする ( その8 )( SpotBugs を 4.0.0-beta4 → 4.1.1 へバージョンアップする ) の続きです。
- 今回の手順で確認できるのは以下の内容です。
- Docker コンテナの image を1度にバージョンアップしようとしたらいろいろうまく動かないものがあったので、何回かに分割してバージョンアップします。
- 今回は以下の Docker コンテナの image をバージョンアップします。
- postgres
- dpage/pgadmin4
- flyway/flyway
- tvial/docker-mailserver
参照したサイト・書籍
目次
- .env を変更する
docker-compose up -d
コマンドを実行する- pgadmin4 にログインできない問題を解消する
- clean タスク実行 → Rebuild Project 実行 → build タスクを実行する
- 変更前の docker image を削除する
手順
.env を変更する
.......... POSTGRESQL_VERSION=12.5 PGADMIN4_VERSION=4.29 FLYWAY_VERSION=7.3.1 FLYWAY_URL=jdbc:postgresql://postgresql/ksbylending FLYWAY_USER=ksbylending_user FLYWAY_PASSWORD=xxxxxxxx .......... MAILSERVER_VERSION=release-v7.2.0
POSTGRESQL_VERSION=12.1
→POSTGRESQL_VERSION=12.5
に変更します。PGADMIN4_VERSION=4.16
→PGADMIN4_VERSION=4.29
に変更します。FLYWAY_VERSION=6.1.3
→FLYWAY_VERSION=7.3.1
に変更します。MAILSERVER_VERSION=release-v6.2.1
→MAILSERVER_VERSION=release-v7.2.0
に変更します。
docker-compose up -d
コマンドを実行する
以下のコマンドを実行して docker image をダウンロードします(画面キャプチャはなし)。
docker-compose up -d
コマンドを実行してコンテナ一式(メールサーバ・rainloop を除く)を起動します。docker-compose -f docker-compose.mail.yml up -d
コマンドを実行してメールサーバ・rainloop のコンテナを起動します。docker-compose -f docker-compose.mail.yml down
コマンドを実行してメールサーバ・rainloop のコンテナを停止・削除します。
pgadmin4 にログインできない問題を解消する
バージョンアップ後に動作確認をしてみたところ、pgAdmin 4 でログインができません。Email/Username is not valid
というメッセージが表示されます。
4.16 → 4.29 へ一気にバージョンアップしていたので 4.17, 4.18, ..... と1つずつバージョンアップして確認したところ、4.25 までは PGADMIN_DEFAULT_EMAIL、PGADMIN_DEFAULT_PASSWORD に設定した postgres / yyyyyyyy でログインできましたが、4.26 でログインできなくなりました。
https://github.com/postgres/pgadmin4/blob/master/web/pgadmin/authenticate/internal.py を見ると validate_email 関数から False が返ってくるからで、https://github.com/postgres/pgadmin4/blob/c79614786f7250f4ddb14fd63c42d4cc87198b32/web/pgadmin/utils/validation_utils.py#L13 を見ると validate_email 関数でメールアドレスのフォーマットチェックを行っていました。postgres ではログインできないはずです。。。
あと pgAdmin 4 が Flask で作成されていることを初めて知りました。
docker-compose.yml で PGADMIN_DEFAULT_EMAIL=postgres
→ PGADMIN_DEFAULT_EMAIL=postgres@example.com
に変更して再度ログインを試してみると、今度は Incorrect username or password.
のメッセージが表示されてまだログインできません。
docker/pgadmin4/data/pgadmin4.db に pgAdmin 4 のデータベースがあるので IntelliJ IDEA の Database Tools で開いて中を確認してみます。
Database Tool Window で Data Source に SQLite を選択した後、「File」に docker/pgadmin4/data/pgadmin4.db を指定してから「OK」ボタンをクリックします。
Database Tool Window に pgadmin4.db が表示されてテーブル一覧の中に user テーブルがあるので開いてみると、
username も email も postgres
のままで postgres@example.com
に変更されていませんでした。
email を postgres
→ postgres@example.com
に変更してみます。
今度は無事ログインできました。
clean タスク実行 → Rebuild Project 実行 → build タスクを実行する
clean タスク実行 → Rebuild Project 実行 → build タスクを実行すると無事 "BUILD SUCCESSFUL" のメッセージが出力されました。
docker-compose -f docker-compose.mail.yml up -d
コマンドを実行してメールサーバを起動した後、Spring Boot 2.1.x の Web アプリを 2.2.x へバージョンアップする ( その14 )( Docker で複数の Tomcat を起動して動作確認する ) に記載してある手順で動作確認しても問題ありませんでした。
変更前の docker image を削除する
以下の docker image を削除します。
- postgres:12.1-alpine
- dpage/pgadmin4:4.16
- flyway/flyway:6.1.3-alpine
- tvial/docker-mailserver:release-v6.2.1
履歴
2020/12/13
初版発行。
AdoptOpenJDK を 11.0.8+10 → 11.0.9.1+1 へ、IntelliJ IDEA を 2020.2.2 → 2020.2.4 へ、Git for Windows を 2.28.0 → 2.29.2.2 へバージョンアップ
AdoptOpenJDK を 11.0.8+10 → 11.0.9.1+1 へバージョンアップする
※ksbysample-webapp-lending プロジェクトを開いた状態でバージョンアップしています。
https://adoptopenjdk.net/ を見ると 11.0.9.1+1 がダウンロードできるようになっていましたので、11.0.9.1+1 へバージョンアップします。
インストール時に削除されるかもしれないので D:\Java\jdk-11.0.8.10-hotspot → D:\Java\jdk-11.0.8.10-hotspotx にリネームします。
OpenJDK11U-jdk_x64_windows_hotspot_11.0.9.1_1.msi をダウンロードして D:\Java\jdk-11.0.9.101-hotspot へインストールした後、環境変数 JAVA_HOME のパスを D:\Java\jdk-11.0.9.101-hotspot へ変更します。
コマンドプロンプトから
java -version
を実行し、11.0.9.1
に変更されていることを確認します。D:\Java\jdk-11.0.8.10-hotspotx → D:\Java\jdk-11.0.8.10-hotspot に戻します。
ダイアログ下部の「Configure」-「Structure for New Projects」を選択します。
「Project Structure for New Projects」ダイアログが表示されます。画面左側で「Project Settings」-「Project」を選択後、画面右側の「Project SDK」のドロップダウンリストで D:\Java\jdk-11.0.9.101-hotspot を選択します。
「Project SDK」の「Edit」ボタンをクリックします。
画面左側で「Platform Settings」-「SDKs」が選択された状態になるので、画面右上の入力フィールドで "11" → "11.0.9.101" へ変更します。
次に中央のリストから「11.0.8.10」を選択した後、リストの上の「-」ボタンをクリックして削除します。
「OK」ボタンをクリックして「Project Structure for New Projects」ダイアログを閉じます。
「Welcome to IntelliJ IDEA」ダイアログに戻ったら、ksbysample-webapp-lending プロジェクトを開きます。
IntelliJ IDEA のメイン画面が開いたら、メニューから「File」-「Project Structure...」を選択します。
「Project Structure」ダイアログが表示されます。以下の画像の状態になっているので、
「Project SDK」を選択し直します。「Project SDK」を「11.0.9.101」に変更すると「Project language level」も自動で「SDK default (11 - Local variable syntax for lambda param」が選択されました。
「OK」ボタンをクリックして「Project Structure」ダイアログを閉じます。
メイン画面に戻ると画面右下に「Indexing...」の表示が出るので。。。と思ったのですが、何かすぐに終わりました。
Gradle Tool Window の左上にある「Refresh all Gradle projects」ボタンをクリックして更新します。
clean タスク実行 → Rebuild Project 実行 → build タスクを実行して、"BUILD SUCCESSFUL" のメッセージが出力されることを確認します。
Project Tool Window で src/test でコンテキストメニューを表示して「Run 'All Tests' with Coverage」を選択すると、テストが全て失敗しました。
エラーが出ていたのは以下の3種類でした。
java.lang.NoClassDefFoundError: org/junit/rules/TestWatcher
java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0
java.lang.NoClassDefFoundError: org/junit/rules/ExternalResource
IntelliJ IDEA を 2020.1.4 → 2020.2.2 へバージョンアップ の時は成功していたのと、JDK のバージョンも 11 のままなので、IntelliJ IDEA のメインメニューから「File」-「Invalidate Caches / Restart...」を選択して「Invalidate Caches」ダイアログを表示した後「Invalidate and Restart」ボタンを押して Cache をクリアしてみます。
再度「Run 'All Tests' with Coverage」を選択すると、テストが全て成功しました。
特に問題は発生しませんでした。11.0.9+101 で開発を進めます。
IntelliJ IDEA を 2020.2.2 → 2020.2.4 へバージョンアップする
IntelliJ IDEA の 2020.2.4 がリリースされているのでバージョンアップします。
- IntelliJ IDEA 2020.2.3 Is Available
https://blog.jetbrains.com/idea/2020/10/intellij-idea-2020-2-3-is-available/ - IntelliJ IDEA 2020.2.4 is Available
https://blog.jetbrains.com/idea/2020/11/intellij-idea-2020-2-4/
※ksbysample-webapp-lending プロジェクトを開いた状態でバージョンアップしています。
IntelliJ IDEA のメインメニューから「Help」-「Check for Updates...」を選択します。
「IDE and Plugin Updates」ダイアログが表示されます。右下に「Update and Restart」ボタンが表示されていますので、「Update and Restart」ボタンをクリックします。
Plugin の update も表示されました。このまま「Update and Restart」ボタンをクリックします。
Patch がダウンロードされて IntelliJ IDEA が再起動します。
IntelliJ IDEA が起動すると画面下部に「Indexing」のメッセージが表示されますので、終了するまで待機します。
IntelliJ IDEA のメインメニューから「Help」-「About」を選択し、2020.2.4 へバージョンアップされていることを確認します。
clean タスク実行 → Rebuild Project 実行 → build タスクを実行して、"BUILD SUCCESSFUL" のメッセージが出力されることを確認します。
Project Tool Window で src/test でコンテキストメニューを表示して「Run 'All Tests' with Coverage」を選択し、テストが全て成功することを確認します。
Git for Windows を 2.28.0 → 2.29.2.2 へバージョンアップする
Git for Windows の 2.29.2.2 がリリースされていたのでバージョンアップします。
https://gitforwindows.org/ の「Download」ボタンをクリックして Git-2.29.2.2-64-bit.exe をダウンロードします。
Git-2.29.2.2-64-bit.exe を実行します。
「Git 2.29.2.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 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.29.2.windows.2
になっていることを確認します。特に問題はないようですので、2.29.2.2 で作業を進めたいと思います。