コンテナの診断手順

DIAG-C1: Docker コンテナで利用のリソース状況の確認

Docker コンテナのリソース状況を確認してください。 クラスタ構成の場合は全てのノードの状態を確認するようにしてください。

  • CPU 使用率
  • メモリ使用率
  • PID 処理が多くすぎて

以下のコマンド Docker で操作中コンテナご利用のリソース状況を見ることができます。

$ docker stats --no-stream

CONTAINER ID   NAME                                       CPU %     MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O         PIDS
b2bf672eee1e   ke2_jobmngrd.3.0h8v6lwpw3oh87wg07n09jrvc   0.20%     36.84MiB / 7.504GiB   0.48%     6.98kB / 6.99kB   0B / 0B           8
3da2cfa36197   ke2_rabbitmq.3.y8sg4tdm469ik51w2kw915psm   0.36%     130.7MiB / 7.504GiB   1.70%     19.4MB / 20.5MB   0B / 9.08MB       33
6f1befa797c4   ke2_kengine.2.dt80bscpolhaa2t4fk8x3410l    3.04%     392.7MiB / 7.504GiB   5.11%     264kB / 236kB     16.4kB / 0B       43
dfc85d84573f   ke2_nginx.2.3q62nqjhlkz6jnmudx0dk6vsv      0.00%     5.406MiB / 7.504GiB   0.07%     437kB / 1.44MB    8.19kB / 55.3kB   5
31d90be86621   ke2_kompira.2.ocsgjfl315v3yrkjqcr1tg2uo    1.57%     220.6MiB / 7.504GiB   2.87%     458kB / 520kB     328kB / 0B        16

  1. いずれかのコンテナのCPU、メモリ、またはI/O使用率がたとえば95％を超えている場合、KE2 APP ご利用時に、速度が非常に遅いか異常の可能性があります。その時に特定のコンテナを再起動し、また KE2 APP の状況をご確認ください。

    $ docker restart <コンテナ ID>

  2. 複数コンテナのCPU、メモリ、またはI/O使用率がたとえば95％を超えている場合、KE2 APP ご利用時に、速度が非常に遅いか異常の可能性があります。その時に KE2 APP を再起動してください。

DIAG-C2: Docker コンテナの正常性の確認

Dockerコンテナはさまざまな理由で異常になる可能性があります。

  • 高いリソース利用率により、時々コンテナが停止してしまうことがありますが、正常化してもコンテナが復旧しない場合があります。
  • コンテナ内部でエラーが発生し、停止してしまった可能性があります。
  • 外部データベースを使用している場合、DBアクセスの問題でもコンテナが停止・再起動を繰り返す可能性があります。

シングル構成におけるコンテナの正常性の確認

シングル構成では、1台のVM上のDockerで以下の7個のコンテナが動かします。

  • nginx
  • redis
  • kompira
  • kengine
  • postgresql
  • rabbitmq
  • jobmngrd

実行中コンテナの確認

実行中コンテナの一覧以下のコマンドで確認ことができます。

$ docker container ls

CONTAINER ID   IMAGE                                                  COMMAND                  CREATED      STATUS               PORTS                                                                                       NAMES
32fe4cedfab3   registry.hub.docker.com/library/nginx:1.27-alpine      "/docker-entrypoint.…"   6 days ago   Up 6 days            0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp                    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            4369/tcp, 5672/tcp, 15691-15692/tcp, 25672/tcp, 0.0.0.0:5671->5671/tcp, :::5671->5671/tcp   ke2-rabbitmq-1
c53e47ff9826   registry.hub.docker.com/library/redis:7.2-alpine       "docker-entrypoint.s…"   6 days ago   Up 6 days            6379/tcp                                                                                    ke2-redis-1
35f1ae144b49   registry.hub.docker.com/library/postgres:16.3-alpine   "docker-entrypoint.s…"   6 days ago   Up 6 days            5432/tcp                                                                                    ke2-postgres-1

上の結果見ると7個コンテナのステータスは UP になるべきです。さらに 手動で再起動されていない場合、 CREATED と UP 期間が大体同じであるべきです。

手動で再起動していないにもかかわらず、UP と CREATED の期間が大体同じでない場合は、途中で何か問題が発生し、再起動された可能性があります。その場合、UP 期間が長い場合は、特定のコンテナが再起動されたものの、安定して実行中であることを意味します。以下のコマンドを使用して再起動回数を確認できます。

# コマンド形式: docker inspect --format='{{.RestartCount}}' <コンテナ ID>
# 例
$ docker inspect --format='{{.RestartCount}}' 060dca0960a9

3

このような場合は、サポートまでお問い合わせください。

UP 期間が短い場合は、docker container ls コマンドを定期的に実行して、UP 期間が頻繁に変わっているかどうかを確認してください。頻繁に変わっている場合は、以下の調査を進めてください。

一覧で7個コンテナがない場合、以下の調査を進んでください。

外部 DB シングル構成におけるコンテナの正常性の確認

外部 DB シングル構成では、1台のVM上のDockerで以下の6個のコンテナが動かします。

  • nginx
  • redis
  • kompira
  • kengine
  • rabbitmq
  • jobmngrd

実行中コンテナの確認

実行中コンテナの一覧以下のコマンドで確認ことができます。

$ docker container ls

CONTAINER ID   IMAGE                                                  COMMAND                  CREATED      STATUS               PORTS                                                                                       NAMES
32fe4cedfab3   registry.hub.docker.com/library/nginx:1.27-alpine      "/docker-entrypoint.…"   6 days ago   Up 6 days            0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp                    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            4369/tcp, 5672/tcp, 15691-15692/tcp, 25672/tcp, 0.0.0.0:5671->5671/tcp, :::5671->5671/tcp   ke2-rabbitmq-1
c53e47ff9826   registry.hub.docker.com/library/redis:7.2-alpine       "docker-entrypoint.s…"   6 days ago   Up 6 days            6379/tcp                                                                                    ke2-redis-1

上の結果見ると6個コンテナのステータスは UP になるべきです。さらに 手動で再起動されていない場合、 CREATED と UP 期間が大体同じであるべきです。

手動で再起動していないにもかかわらず、UP と CREATED の期間が大体同じでない場合は、途中で何か問題が発生し、再起動された可能性があります。その場合、UP 期間が長い場合は、特定のコンテナが再起動されたものの、安定して実行中であることを意味します。以下のコマンドを使用して再起動回数を確認できます。

# コマンド形式: docker inspect --format='{{.RestartCount}}' <コンテナ ID>
# 例
$ docker inspect --format='{{.RestartCount}}' 060dca0960a9

3

このような場合は、サポートまでお問い合わせください。

UP 期間が短い場合は、docker container ls コマンドを定期的に実行して、UP 期間が頻繁に変わっているかどうかを確認してください。頻繁に変わっている場合は、以下の調査を進めてください。

一覧で6個コンテナがない場合、以下の調査を進んでください。

クラスタ構成におけるコンテナの正常性の確認

クラスタ構成では、3台のVM上にそれぞれ1つのDockerが動かします。各 Docker で以下の5個のコンテナが動かします。

  • nginx
  • kompira
  • kengine
  • rabbitmq
  • jobmngrd

そして、いずれかの Docker で redis コンテナが動かします。

まとめると、2つの Docker で5個のコンテナが動かし、いずれかの1つの Docker で6個のコンテナが動かします。

次のコマンドを使用して要約を確認できます。

$ 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

上の結果見ると、5個のコンテナに対して5個サービスの REPLICAS は 3/3 であり、redis サービスの REPLICAS は 1/1 であるべきです。

特定のサービスの REPLICAS は上の通りではないと以下のコマンドで特定のサービスの詳細を見てください。

# コマンドの形式: docker service ps <サービス名>
# 例
$ docker service ps ke2_kengine

ID             NAME                IMAGE                                          NODE                 DESIRED STATE   CURRENT STATE          ERROR                         PORTS
w9qmsxko0tax   ke2_kengine.1       kompira.azurecr.io/kompira-enterprise:latest   ke2-rhel89-swarm-3   Running         Running 2 weeks ago                                  
rclffpisgc4z    \_ ke2_kengine.1   kompira.azurecr.io/kompira-enterprise:latest   ke2-rhel89-swarm-3   Shutdown        Shutdown 2 weeks ago                                 
24rkaui1m3n4    \_ ke2_kengine.1   kompira.azurecr.io/kompira-enterprise:latest   ke2-rhel89-swarm-3   Shutdown        Failed 2 weeks ago     "task: non-zero exit (143)"   
bkx5pswzwzf3    \_ ke2_kengine.1   kompira.azurecr.io/kompira-enterprise:latest   ke2-rhel89-swarm-3   Shutdown        Failed 2 weeks ago     "task: non-zero exit (143)"   
s60vnnmd81jq    \_ ke2_kengine.1   kompira.azurecr.io/kompira-enterprise:latest   ke2-rhel89-swarm-3   Shutdown        Failed 2 weeks ago     "task: non-zero exit (143)"   
ybtuiii4nfuu   ke2_kengine.2       kompira.azurecr.io/kompira-enterprise:latest   ke2-rhel89-swarm-1   Running         Running 2 weeks ago                                  
lf9am9v6ekus    \_ ke2_kengine.2   kompira.azurecr.io/kompira-enterprise:latest   ke2-rhel89-swarm-1   Shutdown        Failed 2 weeks ago     "task: non-zero exit (143)"   
l42bxx6bj6oy    \_ ke2_kengine.2   kompira.azurecr.io/kompira-enterprise:latest   ke2-rhel89-swarm-1   Shutdown        Failed 2 weeks ago     "task: non-zero exit (143)"   
wtbtanje9kxd    \_ ke2_kengine.2   kompira.azurecr.io/kompira-enterprise:latest   ke2-rhel89-swarm-1   Shutdown        Failed 2 weeks ago     "task: non-zero exit (143)"   
v8qlsqyy2fpi    \_ ke2_kengine.2   kompira.azurecr.io/kompira-enterprise:latest   ke2-rhel89-swarm-1   Shutdown        Failed 2 weeks ago     "task: non-zero exit (143)"   
vi28sw06hx55   ke2_kengine.3       kompira.azurecr.io/kompira-enterprise:latest   ke2-rhel89-swarm-2   Running         Running 2 weeks ago                                  
yld6w5fljlp4    \_ ke2_kengine.3   kompira.azurecr.io/kompira-enterprise:latest   ke2-rhel89-swarm-2   Shutdown        Shutdown 2 weeks ago                                 
yp1ckgfg4we6    \_ ke2_kengine.3   kompira.azurecr.io/kompira-enterprise:latest   ke2-rhel89-swarm-2   Shutdown        Shutdown 2 weeks ago                                 
0mywy77r4b29    \_ ke2_kengine.3   kompira.azurecr.io/kompira-enterprise:latest   ke2-rhel89-swarm-2   Shutdown        Failed 2 weeks ago     "task: non-zero exit (143)"   
pdwyb8o5wrvx    \_ ke2_kengine.3   kompira.azurecr.io/kompira-enterprise:latest   ke2-rhel89-swarm-2   Shutdown        Failed 2 weeks ago     "task: non-zero exit (143)"

特定のノード上のコンテナの CURRENT STATE が Running であっても、実行中の期間が短く、さらに Running 以外のステータス（例えば、Shutdown や Failed など）が多いと期間が短く場合、そのコンテナは不安定な状態にあると言えます。この場合、特定のノードで以下の調査を進めてください。

特定のノード上のコンテナの CURRENT STATE が Running ではない場合、特定のノードで以下の調査を進めてください。

KE2 APP を再起動する

様々な調査でも KE2 APP が正常に戻らないの可能性があります。その時に以下の方法で再起動してください。

シングル構成場合

まずは、以下のコマンで docker サービスを再起動して KE2 APP の状況をみてください。

$ systemctl restart docker.service

そして、KE2 APP の全体ステータスをご確認ください。

まだ、KE2 APP が正常に戻らない場合、ホストサーバを再起動してみてください。

外部 DB シングル構成場合

まずは、以下のコマンで docker サービスを再起動して KE2 APP の状況をみてください。

$ systemctl restart docker.service

そして、KE2 APP の全体ステータスご確認ください。

まだ、KE2 APP が正常に戻らない場合、ホストサーバを再起動してみてください。

クラスタ構成場合

3台の VM のうち1台で KE2 APP の操作が停止

まずは、エラーが発生されている VM の上以下のコマンドを実行して docker サービスを再起動します。

$ systemctl restart docker.service

Docker が起動できたら、ノードの KE2 APP のステータスをご確認ください。

KE2 APP が正常に戻らない場合、エラーが発生されている特定の VM を再起動してみてください。

docker と glusterfs 自動起動設定があれば特定のノードと関係があるコンテナが自動回復になります。

VM が起動できたら、ノードの KE2 APP のステータスをご確認ください。

KE2 APP 操作が全体的に停止

まずは、一つ術各 VM の上以下のコマンを実行して docker サービスを再起動して KE2 APP の全体ステータスをみてください。

$ systemctl restart docker.service

まだ、KE2 APP が正常に戻らない場合、一つ術すべての VM を再起動してみてください。

docker と glusterfs 自動起動設定があれば再起動されたノードと関係があるコンテナが自動回復になります。

それでも、KE2 APP が正常に戻らない場合、クラスタを再起動しててみてください。以下の手順に従ってください。

[いずれかのノード]$ docker stack rm ke2
[いずれかのノード]$ cd ke2/cluster/swarm
[いずれかのノード]$ docker stack deploy -c docker-swarm.yml ke2

そして、KE2 APP の全体ステータスをみてください。

RabbitMQのボリュームが破損し、KE2 APPの操作が全体的に異常になる場合があります。 クラスタ構成における障害を回復させる手順のひとつとして、rabbitmq が利用しているボリュームを削除してからクラスタを再デプロイさせるというものがあります。

ここでは rabbitmq のボリュームを削除する手順について示します。

rabbitmq のボリュームを削除する手順

推奨がない場合は、この手順を実行しないでください

rabbitmq のボリュームを削除する前に、いったんクラスタを削除する必要があります。クラスタを削除しない場合は、Swarmクラスタのいずれかのノード上で以下のコマンドを実行してください

[いずれかのノード]$ docker stack rm ke2

docker ボリューム削除時にボリュームの名前必要です。以下のコマンドで docker ボリューム一覧を見てください。

[いずれかのノード]$ docker volume ls

DRIVER    VOLUME NAME
local     swarm_kompira_rmq

そして、全てのノードで以下のコマンド実行して rabbitmq ボリュームを削除してください。

[すべてのノード]$ docker volume rm swarm_kompira_rmq

そして、以下の手順で KE2 APP を再デプロイしてください。

[いずれかのノード]$ cd ke2/cluster/swarm
[いずれかのノード]$ docker stack deploy -c docker-swarm.yml ke2