私たちのチームでは、現在、Dockerに移行してサーバーにすべてを展開しています。
Docker Swarmと、多数(20以上)のサービスを定義する複数(10以上)の構成ファイルを使用しています。 docker stack rm <name>
を使用してスタックを停止する(およびdocker stack deploy <options> <name>
を使用して再デプロイする)場合を除き、これまでのところすべてが正常に機能します。約2回ごとに、次のエラーが発生します。
Failed to remove network <id>: Error response from daemon: network <id> not foundFailed to remove some resources from stack: <name>
docker network ls
を使用する場合、ネットワークは実際には削除されませんが、docker network rm <id>
は常に次の結果になります。
Error response from daemon: network <id> not found
さらに奇妙なのは、docker network inspect <id>
が通常の出力を返すという事実です。ネットワークは常に、スタックをデプロイするために使用される構成ファイルで作成されるoverlay
ネットワークです。現在、Swarmには1つのノードしかありません。
現在の「回避策」はDockerを再起動することです(これにより問題が解決します)が、実稼働環境では実行可能なソリューションではありません。群れを離れて再び参加しても、問題は解決しません。
最初は、この問題はMac用のDockerのみに関連すると考えました(ローカルマシンで最初に問題が発生したため)が、Debian Stretchでも同じ問題が発生します。どちらの場合も、利用可能な最新のDockerディストリビューションを使用します。
私は本当に助けていただければ幸いです!
いつでもdocker system Prune -a
を使用して古いネットワークを取り除くことができます。これはボリュームを削除しません。
次回はdocker-compose up --build -d
に時間がかかりますが、現在の問題を乗り越えることができます。
この問題 のように聞こえます。
スタックrmは、スタックの展開が「速すぎる」に従って、ネットワーク、おそらく他のスタックリソースの作成/削除を競います。
この問題は今日でも未解決のままです( docker/cli )が、提案された回避策を試すことができます。
until [ -z "$(docker service ls --filter label=com.docker.stack.namespace=$COMPOSE_PROJECT_NAME -q)" ] || [ "$limit" -lt 0 ]; do
sleep 1;
done
until [ -z "$(docker network ls --filter label=com.docker.stack.namespace=$COMPOSE_PROJECT_NAME -q)" ] || [ "$limit" -lt 0 ]; do
sleep 1;
done
存在しない既存のネットワークにコンテナを追加しようとしている場合は、docker-compose up --force-recreate
を使用できます。私はこれを見つけました GitHubがコメントを発行します 役に立つ概要です。