時間のかかるDockerエラーのトラブルシューティングプロセス記録

起源

顧客は CentOS をベースにしたカスタマイズされたシステムを Sangfor に注文しました。長い調査の結果、問題は実際には Docker の問題ではなく、ファイルの破損であることがわかりました。

環境情報

Docker情報:

$ docker情報
コンテナ: 0
 ランニング: 0
 一時停止: 0
 停止: 0
画像: 2
サーバーバージョン: 18.09.3
ストレージ ドライバー: overlay2
 バックアップファイルシステム: xfs
 d_type をサポート: true
 ネイティブオーバーレイ差分: true
ログドライバー: json-file
cgroup ドライバー: cgroupfs
プラグイン:
 ボリューム: ローカル
 ネットワーク: ブリッジ ホスト macvlan null オーバーレイ
 ログ: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
群れ: 非アクティブ
ランタイム: runc
デフォルトのランタイム: runc
初期化バイナリ: docker-init
コンテナバージョン: e6b3f5632f50dbc4e9cb6288d911bf4f5e95b18e
runc バージョン: 6635b4f0c6af3810594d2770f662f34ddc15b40d
初期化バージョン: fec3683
セキュリティ オプション:
 seccomp
 プロフィール: デフォルト
カーネルバージョン: 3.10.0
オペレーティング システム: CentOS Linux 7 (コア)
OSタイプ: Linux
アーキテクチャ: x86_64
CPU: 20
合計メモリ: 125.3 GiB
名前: eds-1f21a854
ID: VZLV:26PU:ZUN6:QQEJ:GW3I:YETT:HMEU:CK6J:SIPL:CHKV:6ASN:5NDF
Docker ルートディレクトリ: /data/kube/docker
デバッグモード（クライアント）: false
デバッグモード（サーバー）: false
レジストリ: https://index.docker.io/v1/
ラベル:
実験的: 偽
安全でないレジストリ:
 登録番号:5000
 treg.yun.wps.cn
 127.0.0.0/8
レジストリミラー:
 レジストリ
 https://docker.mirrors.ustc.edu.cn/
ライブリストアが有効: false
製品ライセンス: コミュニティ エンジン

システム情報

$ uname -a
Linux eds-1f21a854 3.10.0 #1 SMP 2020年9月28日月曜日12:00:30 CST x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/os-release
名前="CentOS Linux"
バージョン="7 (コア)"
ID = "centos"
ID_LIKE="rhel フェドーラ"
バージョンID = "7"
PRETTY_NAME="CentOS Linux 7 (コア)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

サーバー情報:

$ 猫製品名
スゴン-60G16
$ cat sys_vendor
サンフォール
$ cat 製品バージョン
1.2

トラブルシューティングのプロセス

Dockerサーバーのインストールがハングする

時刻 2020 10/29 19:51:

実装: お客様がデプロイした際に、docker のインストール時にサーバーがクラッシュしました。私: 起動後に /var/log/message に何か情報がありますか? 実装: スナップショットを復元して入るだけで、サーバーに入ることもできず、情報も見られません。私: スナップショットを復元しないと起動できないのですか? 実装: はい

この時点で、何らかのカーネルバグがトリガーされ、カーネルがパニックになり、サーバーを起動できなくなったと思いました。

時間 2020 10/30 9:07:

私: 起動できなかったとき、コンソールにアクセスして起動できなかった理由を確認しましたか? 実装: 確認できないのはクライアントサーバーですか? 私: クライアントは確認しませんでしたか?

その後、実装は直接 Sunflower リモート接続を送信しました。確認してみると、通常のオペレーティングシステムではなく、CentOS をベースに修正されたものであることがわかりました。 /var/log/message が見つからなかったため、Docker インストールスクリプトを手動で実行しました。

bash -x インストール-docker.sh

すると、出力情報が特定のステップで停止し、「ハング」しているはずです。スクリプトによって出力された最後のデバッグ情報を調べたところ、Docker の起動が続いており、これは Docker の起動によってトリガーされるはずであることがわかりました。その後、時間が経ってもまだ接続やpingが通らなかったため、実装スタッフに依頼して、ハードウェアサーバーかどうか、idrac、iloなどがあるかどうか、ttyコンソールの情報を確認するために現場で確認してもらいました。

現場の担当者がサーバーをチェックしたところ、「正常に起動しています」と表示されました。試してみましたが、それでも接続できませんでした。ルートが変更されたかどうか尋ねられました。現場で systemctl を使用して確認したところ、docker が起動していることがわかりました。サイトからゲートウェイに ping を実行することはできません。突然、もしかしたら全然掛けられていなかったのかもしれない、と気づきました。。。

前回の起動時間を確認するために uptime -s を実行するように依頼しましたが、まったく再起動していなかったことが判明しました。。。

その後、現場でそれが iptables の問題であることがわかりました。docker を起動すると、ルールがフラッシュされました。その後、いくつか変更を加えてすべてリリースしました。そのため、Docker 起動時にマシンがハングしたのは、実は iptables の影響でネットワークが切断され、マシンがまったく再起動されなかったことが原因であることがわかりました。

コンテナを起動するとクラッシュする

その後、続けて実装すると、以前他のマシンにdockerをインストールした時は上記問題は発生しなかったが、起動時に上記問題が発生したとのこと。手動でデプロイを実行したところ、エラーが報告されました。スクリプトは -x デバッグを開き、デプロイメントイメージの読み込み時にエラーが報告されることを確認します。

接続中にエラーが発生しました: http://%2Fvar%2Frun%2Fdocker.sock/v1.39/images/load?quiet=0 を投稿: unix @->/var/run/docker.sock を読み取り: EOF

手動実行:

$ docker load -i ./kube/images/deploy.tar
接続中にエラーが発生しました: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.39/images/load?quiet=0: read unix @->/var/run/docker.sock: read: connection reset by peer

jounalctl をチェックしましたが、docker デーモンに関連するログは見つかりませんでした。このエラーを検索したところ、/var/run/docker.sock の docker グループが存在しないという人もいれば、chmod 777 を直接使用して解決した人もいました。試してみましたが、まだ動作しません。フロントデスクで docker をデバッグして、役立つ情報があるかどうかを確認します。

systemctl ドッカーを停止する
pkillドッカー
ドッカー -D

別のターミナルを開き、イメージのロード操作を実行します。

$ docker load -i ./kube/images/deploy.tar
ab6425526dab: レイヤーを読み込んでいます [===========================================================>] 126.3MB/126.3MB
c7fe3ea715ef: レイヤーを読み込んでいます [============================================================>] 340.3MB/340.3MB
7f7eae7934f7: レイヤーを読み込んでいます [===========================================================>] 3.584kB/3.584kB
e99a66706b50: レイヤーを読み込んでいます [=============================================================>] 2.105MB/2.105MB
245b79de6bb7: レイヤーを読み込んでいます [============================================================>] 283.5MB/283.5MB
2a56a4432cef: レイヤーを読み込んでいます [============================================================>] 93.18kB/93.18kB
0c2ea71066ab: レイヤーを読み込んでいます [===========================================================>] 276.5kB/276.5kB
bb3f6df0f87c: レイヤーを読み込んでいます [===========================================================>] 82.94kB/82.94kB
6f34ead3cef7: レイヤーを読み込んでいます [===========================================================>] 946.7kB/946.7kB
c21422dd15f6: レイヤーを読み込んでいます [=============================================================>] 1.97MB/1.97MB
940288517f4c: レイヤーを読み込んでいます [============================================================>] 458.2kB/458.2kB
0c52f1af61f4: レイヤーを読み込んでいます [============================================================>] 5.12kB/5.12kB
049e7edd48bc: レイヤーを読み込んでいます [============================================================>] 1.57MB/1.57MB
73307245d702: レイヤーを読み込んでいます [============================================================>] 5.632kB/5.632kB
f109309d8ffc: レイヤーを読み込んでいます [============================================================>] 2.175MB/2.175MB
読み込まれたイメージ: xxxxxxxxxxxx.cn/platform/deploy-amd64:ubuntu.16.04
$ docker イメージ
リポジトリ タグ イメージ ID 作成 サイズ
xxxxxxxxxxxx.cn/platform/deploy-amd64 ubuntu.16.04 3ad94a76af5d 3か月前 734MB

デバッグ側ではフロントエンドのログ出力は正常です

...
DEBU[2020-10-30T14:48:39.955963986+08:00] tar sha256:049e7edd48bc46e3dd5edf89c9caa8f0f7efbb41af403c5a54dd4f1008f604a7 を d58edd0d97bb672ef40e82e45c1603ca3ceaad847d9b9fc7c9b0588087019649 に適用しました。サイズ: 1518278
DEBU[2020-10-30T14:48:39.960091040+08:00] /data/kube/docker/overlay2/b044bd592ae800ed071208c6b2f650c5cbdc7452702f56a23b9b4ffe4236ac18/diff storage-driver=overlay2 に tar を適用しています
DEBU[2020-10-30T14:48:40.059510528+08:00] tar sha256:73307245d7021f9627ca0b2cbfeab3aac0b65abfd476f6ec26bb92c75892d7e2 を b044bd592ae800ed071208c6b2f650c5cbdc7452702f56a23b9b4ffe4236ac18 に適用しました。サイズ: 3284
DEBU[2020-10-30T14:48:40.063040538+08:00] /data/kube/docker/overlay2/03918b1d275aa284532b8b9c59ca158409416f904e13cc7084c598ed343e844f/diff storage-driver=overlay2 に tar を適用しています
DEBU[2020-10-30T14:48:40.148209852+08:00] tar sha256:f109309d8ffcb76589ad6389e80335d986b411c80122d990ab00a02a3a916e3e を 03918b1d275aa284532b8b9c59ca158409416f904e13cc7084c598ed343e844f に適用しました。サイズ: 2072803
^CINFO[2020-10-30T14:48:55.593523177+08:00] 信号「割り込み」を処理中
DEBU[2020-10-30T14:48:55.593617229+08:00] デーモンは最小 15 秒のシャットダウン タイムアウトが設定されています
DEBU[2020-10-30T14:48:55.593638628+08:00] 15秒のタイムアウトですべてのコンテナのクリーンシャットダウンを開始します...
DEBU[2020-10-30T14:48:55.594074457+08:00] Unixソケット/run/docker/libnetwork/ebd15186e86385c48c4c5508d5f30eb83d5d74e56f09af5c82b6d6d9d63ec8b8.sockが存在しません。クライアント接続を受け入れることができません
DEBU[2020-10-30T14:48:55.594106623+08:00] 古いマウントIDのクリーンアップ：開始。
INFO[2020-10-30T14:48:55.594157536+08:00] 正常なシャットダウン後にイベント ストリームを停止しています error="<nil>" module=libcontainerd namespace=moby
DEBU[2020-10-30T14:48:55.594343122+08:00] 古いマウントIDのクリーンアップ：完了。
DEBU[2020-10-30T14:48:55.594501828+08:00] クリーンシャットダウンに成功しました
INFO[2020-10-30T14:48:55.594520918+08:00] 正常なシャットダウンに続いてヘルスチェックを停止します module=libcontainerd
INFO[2020-10-30T14:48:55.594531978+08:00] 正常なシャットダウン後にイベント ストリームを停止しています エラー = "コンテキストがキャンセルされました" モジュール = libcontainerd 名前空間 = plugins.moby
DEBU[2020-10-30T14:48:55.594603119+08:00] 信号を受信しました signal=終了しました
INFO[2020-10-30T14:48:55.594739890+08:00] pickfirstBalancer: HandleSubConnStateChange: 0xc4201a61b0、TRANSIENT_FAILURE モジュール=grpc
INFO[2020-10-30T14:48:55.594751465+08:00] pickfirstBalancer: HandleSubConnStateChange: 0xc4201a61b0、接続中 module=grpc

systemd の設定を確認しましたが、特に何も見つかりませんでした。フォアグラウンドで実行しているときにインポートできる理由がわかりませんでした。トラブルシューティング方法が思いつかなかったので、ソケットの問題ではないかと考えました。socat を使用して tcp に転送しようとしましたが、それでもうまくいきませんでした (ここでは、ソケット経由ではなくデーモンに tcp listen 127 を追加してみてください。そうすると、socat は最終的にソケットを通過しました)

$ socat -d -d TCP-LISTEN:2375、フォーク、バインド=127.0.0.1 UNIX:/var/run/docker.sock
2020/10/30 17:39:58 socat[5201] N は AF=2 127.0.0.1:2375 でリッスンしています
^[[C2020/10/30 17:42:06 socat[5201] N は AF=2 127.0.0.1:35370 から AF=2 127.0.0.1:2375 への接続を受け入れています
2020/10/30 17:42:06 socat[5201] N 子プロセス 11501 をフォークしました
2020/10/30 17:42:06 socat[5201] N は AF=2 127.0.0.1:2375 でリッスンしています
2020/10/30 17:42:06 socat[11501] N AF=1 "/var/run/docker.sock" への接続を開始
2020/10/30 17:42:06 socat[11501] N はローカルアドレス AF=1 "\0\0\0\0\0\0 \x0D\x@7\xE9\xEC\x7E\0\0\0\x01\0\0\0\0" から正常に接続されました
2020/10/30 17:42:06 socat[11501] NはFD [6,6]と[5,5]でデータ転送ループを開始します
2020/10/30 17:42:12 socat[11501] E write(5, 0x55f098349920, 8192): パイプが壊れました
2020/10/30 17:42:12 socat[11501] N出口(1)
2020/10/30 17:42:12 socat[5201] N childdied(): シグナル17の処理

$ docker --log-level デバッグ -H tcp://127.0.0.1:2375 ロード -i kube/images/deploy.tar
c7fe3ea715ef: レイヤーを読み込んでいます [===================================================> ] 286.9MB/340.3MB
予期しないEOF

結局、かなり時間がかかりました。その時は忙しかったので、別のお客様の問題を調べに行きました。その後、ここに戻ってきて、思いつきで他の画像を読み込もうとしました。うまくいきました。。。

$ docker load -i kube/images/pause_3.1.tar
e17133b79956: レイヤーを読み込んでいます [============================================================>] 744.4kB/744.4kB
読み込まれたイメージ: mirrorgooglecontainers/pause-amd64:3.1
$ docker load -i kube/images/tiller_v2.16.1.tar
77cae8ab23bf: レイヤーを読み込んでいます [============================================================>] 5.815MB/5.815MB
679105aa33fb: レイヤーを読み込んでいます [============================================================>] 6.184MB/6.184MB
639eab5d05b1: レイヤーを読み込んでいます [============================================================>] 40.46MB/40.46MB
87e5687e03f2: レイヤーを読み込んでいます [============================================================>] 41.13MB/41.13MB
読み込まれたイメージ: gcr.io/kubernetes-helm/tiller:v2.16.1
$ docker load -i kube/images/calico_v3.1.3.tar
cd7100a72410: レイヤーを読み込んでいます [============================================================>] 4.403MB/4.403MB
ddc4cb8dae60: レイヤーを読み込んでいます [==========================================================>] 7.84MB/7.84MB
77087b8943a2: レイヤーを読み込んでいます [===========================================================>] 249.3kB/249.3kB
c7227c83afaf: レイヤーを読み込んでいます [============================================================>] 4.801MB/4.801MB
2e0e333a66b6: レイヤーを読み込んでいます [==========================================================>] 231.8MB/231.8MB
読み込まれたイメージ: calico/node:v3.1.3
2580685bfb60: レイヤーを読み込んでいます [============================================================>] 50.84MB/50.84MB
読み込まれたイメージ: calico/kube-controllers:v3.1.3
0314be9edf00: レイヤーを読み込んでいます [============================================================>] 1.36MB/1.36MB
15db169413e5: レイヤーを読み込んでいます [==========================================================>] 28.05MB/28.05MB
4252efcc5013: レイヤーを読み込んでいます [=============================================================>] 2.818MB/2.818MB
76cf2496cf36: レイヤーを読み込んでいます [===========================================================>] 3.03MB/3.03MB
91d3d3a16862: レイヤーを読み込んでいます [============================================================>] 2.995MB/2.995MB
18a58488ba3b: レイヤーを読み込んでいます [============================================================>] 3.474MB/3.474MB
8d8197f49da2: レイヤーを読み込んでいます [============================================================>] 27.34MB/27.34MB
7520364e0845: レイヤーを読み込んでいます [===========================================================>] 9.216kB/9.216kB
b9d064622bd6: レイヤーを読み込んでいます [==========================================================>] 2.56kB/2.56kB
読み込まれたイメージ: calico/cni:v3.1.3

これをインポートするときにのみエラーが発生します

$ docker load -i kube/images/deploy.tar
接続中にエラーが発生しました: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.39/images/load?quiet=0: read unix @->/var/run/docker.sock: read: connection reset by peer

次に、パッケージを作成したマシン上でファイルのチェックサムを比較したところ、正しくないことが判明しました。。。。

要約する

1 つの疑問は、フロントエンドがなぜそれを実行できるのかということです。2 つ目は、ファイルが破損してインポートされた場合、docker デーモンはログをフラッシュせず、接続を直接リセットします。新しいバージョンでは、この状況はテストされていません。

これで、時間のかかる docker エラーのトラブルシューティングプロセスに関するこの記事は終了です。時間のかかる docker エラーのトラブルシューティングに関するより関連性の高いコンテンツについては、123WORDPRESS.COM の以前の記事を検索するか、次の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。

以下もご興味があるかもしれません: