コンテナの診断手順
Docker コンテナで利用のリソース状況の確認
Docker コンテナのリソース状況（CPU・メモリ・PID 数）を確認してください。クラスタ構成の場合は全てのノードを確認してください。
$ docker stats --no-stream
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
b2bf672eee1e ke2_jobmngrd.3... 0.20% 36.84MiB / 7.504GiB 0.48% 6.98kB / 6.99kB 0B / 0B 8
6f1befa797c4 ke2_kengine.2... 3.04% 392.7MiB / 7.504GiB 5.11% 264kB / 236kB 16.4kB / 0B 43
31d90be86621 ke2_kompira.2... 1.57% 220.6MiB / 7.504GiB 2.87% 458kB / 520kB 328kB / 0B 16
-
いずれかのコンテナの CPU・メモリ・I/O 使用率が高い（例えば 95% 超）場合、KE2 APP の動作が非常に遅いか異常になっている可能性があります。その場合は特定のコンテナを再起動し、KE2 APP の状況を確認してください。
$ docker restart <CONTAINER_ID> -
複数コンテナで使用率が高い場合は、KE2 APP を再起動するを実施してください。
Docker コンテナの正常性の確認
Docker コンテナはさまざまな理由で異常になる可能性があります（高負荷による停止、内部エラーによる停止、外部 DB アクセス問題による停止・再起動の繰り返しなど）。
構成によって VM 上で動作するコンテナ数が異なります。
- 標準シングル構成（1 VM・7 コンテナ）: nginx / redis / kompira / kengine / postgres / rabbitmq / jobmngrd
- 外部DBシングル構成（1 VM・6 コンテナ）: nginx / redis / kompira / kengine / rabbitmq / jobmngrd
- Swarmクラスタ構成（3 VM）: 各ノードで nginx / kompira / kengine / rabbitmq / jobmngrd、いずれか 1 ノードで redis
シングル構成での確認
実行中コンテナの一覧を確認します（標準シングル構成の例）。
$ docker container ls
CONTAINER ID IMAGE COMMAND CREATED STATUS ... NAMES
32fe4cedfab3 registry.hub.docker.com/library/nginx:1.27-alpine "/docker-entrypoint.…" 6 days ago Up 6 days ke2-nginx-1
6d63244c268c kompira.azurecr.io/kompira-enterprise:latest "docker-entrypoint.s…" 6 days ago Up 6 days ke2-kompira-1
5a8808b6f97b kompira.azurecr.io/kompira-enterprise:latest "docker-entrypoint.s…" 6 days ago Up 6 days ke2-kengine-1
c2a13a549267 kompira.azurecr.io/kompira-enterprise:latest "docker-entrypoint.s…" 6 days ago Up 6 days ke2-jobmngrd-1
9af8671ec4b8 registry.hub.docker.com/library/rabbitmq:3.13-alpine "docker-entrypoint.s…" 6 days ago Up 6 days ke2-rabbitmq-1
c53e47ff9826 registry.hub.docker.com/library/redis:7.2-alpine "docker-entrypoint.s…" 6 days ago Up 6 days ke2-redis-1
35f1ae144b49 registry.hub.docker.com/library/postgres:16.3-alpine "docker-entrypoint.s…" 6 days ago Up 6 days ke2-postgres-1
各コンテナのステータスが Up であるべきです。手動で再起動していないのに、作成からの経過時間（CREATED 列）と Up の稼働時間が大きく異なる場合は、途中で問題が発生し再起動された可能性があります。再起動回数は次で確認できます。
$ docker inspect --format='{{.RestartCount}}' <CONTAINER_ID>
Up 期間が短く頻繁に変わる場合は
コンテナが異常・再起動を繰り返す、コンテナが一覧にない（停止している）場合は
コンテナが停止している を参照してください。
クラスタ構成での確認
サービスの状態を確認します。5 つのサービスは REPLICAS が 3/3、redis サービスは 1/1 であるべきです。
$ docker service ls
ID NAME MODE REPLICAS IMAGE PORTS
rurnpyfpcktj ke2_jobmngrd replicated 3/3 (max 1 per node) kompira.azurecr.io/kompira-enterprise:latest
tnu0hcrabygs ke2_kengine replicated 3/3 (max 1 per node) kompira.azurecr.io/kompira-enterprise:latest
sdbpxueuch8b ke2_kompira replicated 3/3 (max 1 per node) kompira.azurecr.io/kompira-enterprise:latest
k5oo0qcki35j ke2_nginx replicated 3/3 (max 1 per node) registry.hub.docker.com/library/nginx:1.27-alpine *:80->80/tcp, *:443->443/tcp
0hcwtac3ode7 ke2_rabbitmq replicated 3/3 (max 1 per node) registry.hub.docker.com/library/rabbitmq:3.13-alpine *:5671->5671/tcp
ccind6pgdon6 ke2_redis replicated 1/1 registry.hub.docker.com/library/redis:7.2-alpine
# 特定サービスの詳細（CURRENT STATE が Shutdown/Failed を繰り返していないか確認）
$ docker service ps <SERVICE_NAME>
CURRENT STATE が Running でも短期間で Shutdown / Failed を繰り返す場合は
コンテナが異常・再起動を繰り返す、Running でない場合は
コンテナが停止している を参照してください。
KE2 APP を再起動する
さまざまな調査でも KE2 APP が正常に戻らない場合、以下の方法で再起動してください。
標準シングル構成
$ systemctl restart docker.service
その後 KE2 APP の全体ステータス を確認してください。まだ戻らない場合は ホストサーバを再起動 してみてください。
外部DBシングル構成
$ systemctl restart docker.service
その後 KE2 APP の全体ステータス を確認してください。まだ戻らない場合はホストサーバを再起動してみてください。
Swarmクラスタ構成
3 台のうち 1 台で KE2 APP の操作が停止した場合: エラーが発生している VM で docker
サービスを再起動します（systemctl restart docker.service）。起動後
ノードの KE2 APP のステータス
を確認してください。戻らない場合はその VM を再起動
してみてください。
KE2 APP の操作が全体的に停止した場合: 各 VM で docker サービスを再起動し、KE2 APP の全体ステータス を確認します。戻らない場合は全 VM を再起動、それでも戻らない場合はクラスタを再デプロイしてください。
[いずれかのノード]$ docker stack rm ke2
[いずれかのノード]$ cd ke2/cluster/swarm
[いずれかのノード]$ docker stack deploy -c docker-swarm.yml ke2
rabbitmq のボリュームを削除する手順
推奨がない場合は、この手順を実行しないでください。
RabbitMQ のボリュームが破損し、KE2 APP の操作が全体的に異常になる場合があります。クラスタ構成の障害回復手順のひとつとして、rabbitmq が利用しているボリュームを削除してからクラスタを再デプロイする方法があります。
まずクラスタを削除します。
[いずれかのノード]$ docker stack rm ke2
ボリューム名を確認し、全てのノードで rabbitmq ボリュームを削除します。
[いずれかのノード]$ docker volume ls
[すべてのノード]$ docker volume rm swarm_kompira_rmq
その後、KE2 APP を再デプロイします。
[いずれかのノード]$ cd ke2/cluster/swarm
[いずれかのノード]$ docker stack deploy -c docker-swarm.yml ke2