SynologyのDockerが起動しなくなった対処法
Dockerコンテナが起動できなくなった
前提
Docker非対応のSynologyに、Dockerを無理やり入れた環境で
Dockerのコンテナが起動できなくなった話です。
docker-compose up時にエラー
コンテナの設定を変更したので、一度リセットしようと
コンテナ関係をすべて削除し、起動しようとしました。
docker-compose down --rmi all --volumes --remove-orphans
docker-compose up -d
[+] Running 11/11
! mariadb Warning 4.4s
? tomcat 8 layers [????????] 0B/0B Pulled 155.2s
? 6476cb406b24 Pull complete 17.4s
? 96565d527970 Pull complete 27.5s
? aa8c15f93136 Pull complete 37.2s
? ee42e24e52cb Pull complete 55.8s
? 009bf5207e45 Pull complete 73.0s
? 2a517ac56b5c Pull complete 107.3s
? fb5422477bab Pull complete 126.4s
? 11054144e0da Pull complete 147.0s
! httpd Warning 4.4s
[+] Building 50.3s (11/11) FINISHED
=> [mariadb internal] load .dockerignore 0.2s
=> => transferring context: 2B 0.0s
=> [mariadb internal] load build definition from Dockerfile 0.3s
=> => transferring dockerfile: 98B 0.0s
=> [mariadb internal] load metadata for docker.io/library/mariadb:10.7.3 2.4s
=> [mariadb 1/2] FROM docker.io/library/mariadb:10.7.3@sha256:07e06f2e7ae9dfc63707a83130a62e00167c827f08fcac7a9aa33f4b6dc34e0e 0.0s
=> CACHED [mariadb 2/2] RUN apt-get update 0.0s
=> [mariadb] exporting to image 0.1s
=> => exporting layers 0.0s
=> => writing image sha256:13830bd6443e791953eda56392a4112dc9f59b05b4baf9bb9019d7eb3ef21f67 0.0s
=> => naming to docker.io/library/mariadb:10.7.3 0.0s
=> [httpd internal] load .dockerignore 0.1s
=> => transferring context: 2B 0.0s
=> [httpd internal] load build definition from Dockerfile 0.2s
=> => transferring dockerfile: 119B 0.2s
=> [httpd internal] load metadata for docker.io/library/httpd:2.4.53 2.8s
=> [httpd 1/2] FROM docker.io/library/httpd:2.4.53@sha256:c479bec894c5a7f8878b28e52d03cc95b1e784612ecd01ac7c7394fc5fa2e6e2 35.3s
=> => resolve docker.io/library/httpd:2.4.53@sha256:c479bec894c5a7f8878b28e52d03cc95b1e784612ecd01ac7c7394fc5fa2e6e2 0.1s
=> => sha256:dc1f00a5d701e86e2cd2568b860c61b393d66be1341e7267d07e6e57448ceeba 30.07MB / 30.07MB 0.9s
=> => sha256:d46382fc5dfc3e35e11331125a5354380d7be6d73d233044b9c95a5d13704d0b 706.12kB / 706.12kB 1.0s
=> => sha256:c479bec894c5a7f8878b28e52d03cc95b1e784612ecd01ac7c7394fc5fa2e6e2 1.86kB / 1.86kB 0.0s
=> => sha256:179bd4864065624e037abe44e92127d4e82b8cd732b7c5a8ebcc877cf3b77d69 1.36kB / 1.36kB 0.0s
=> => sha256:b2571db538ea8305b5a3b517f56fb9894b5585005d989b3eaa9ec3c9134c027b 9.06kB / 9.06kB 0.0s
=> => sha256:2b176a2e8708c9216da93cd20a1e762330488b0e6a6f05b7850ee22e99100c09 145B / 145B 0.7s
=> => sha256:f4ea98d10fd7d468025d4c44ff250cc924a938ba14b78bb06f46024d9a9ca1af 24.06MB / 24.06MB 2.7s
=> => sha256:c136df57375394eacd47c66b58913bd0616d988b6c98e73dd17b880a674af416 297B / 297B 2.1s
=> => extracting sha256:dc1f00a5d701e86e2cd2568b860c61b393d66be1341e7267d07e6e57448ceeba 6.3s
=> => extracting sha256:2b176a2e8708c9216da93cd20a1e762330488b0e6a6f05b7850ee22e99100c09 5.8s
=> => extracting sha256:d46382fc5dfc3e35e11331125a5354380d7be6d73d233044b9c95a5d13704d0b 4.1s
=> => extracting sha256:f4ea98d10fd7d468025d4c44ff250cc924a938ba14b78bb06f46024d9a9ca1af 3.6s
=> => extracting sha256:c136df57375394eacd47c66b58913bd0616d988b6c98e73dd17b880a674af416 6.1s
=> ERROR [httpd 2/2] RUN apt-get update 6.0s
------
> [httpd 2/2] RUN apt-get update:
------
failed to solve: process "/bin/sh -c apt-get update" did not complete successfully: network bridge not found
docker network ls
NETWORK ID NAME DRIVER SCOPE
52000a2b138a host host local
6e84036fad42 none null local
対処法
デーモン設定の「bridge」設定を、「"none"」にしていたので
「""」を指定しdockerdを再起動すると、直りました。
修正前
cat /etc/docker/daemon.json
{
"data-root": "/volume1/@docker/lib",
"registry-mirrors": [],
"storage-driver": "vfs",
"bridge": "none"
}
修正後
vim /etc/docker/daemon.json
{
"data-root": "/volume1/@docker/lib",
"registry-mirrors": [],
"storage-driver": "vfs",
"bridge": ""
}
原因
原因はネットワーク設定でした。
エラーの通り、bridgeネットワークとやらが無い、という原因です。
本来デフォルトで存在しているはずのbridgeネットワークが、
なぜ存在しなかったのか…？
というところでハマっていました。
bridgeネットワークとは？
厳密にいうとややこしいので、簡単に言うと
外部に通信するためのネットワークです。
本来Dockerは仮想環境のため、コンテナから外部には通信できません。
そのため、一度ホストを経由して通信を行います。
ホストを経由して外部と通信するための設定が、
「bridgeネットワーク」と言います。
ホストを介することで、外部と通信が可能になります。
コンテナ作成時の使用ネットワーク
「docker-compose up」は、
イメージ作成→コンテナ作成の順になります。
「Dockerfile」によるイメージ作成時
使用されるネットワークは「bridge」ネットワークです。
※詳細は「docker network inspect bridge」で、確認することができます。
イメージ作成時のため、通信が行われるタイミングは、
主に「apt-get update」等のコマンドが多いかと思われます。
※今回もそれが原因
「docker-compose.yml」によるコンテナ作成時
まず、docker-compose.ymlに定義されている
「networks」の設定により、ネットワークを作成します。
その後、順々にコンテナを作成していきます。
逆を言えば、docker-compose.ymlに定義されたネットワークで、
外部と通信ができるようになるのは、イメージ作成後という事です。
なぜbridgeネットワークがなかったのか？
それはシンプルで、対処法にある通り、
デーモンの設定が間違えていたからでした。
何も知らずに「bridge」ネットワークを、「none」（使用しない）
という設定をしていたのが問題でした。
空白にすると、自動的に名前を付けて、作成してくれます。
※独自で作成し、名前を指定しても問題なし（ホスト側設定）
ビルドキャッシュは関係なし
理由がわかれば、無理なことはわかりますが、
「docker builder prune」
でビルドキャッシュ消したりもしましたが、無意味でした。
※「docker-compose build --no-cache」でも同じエラーでした
参考リンク
- QUARTETCOM TECH BLOG
まとめ
Docker非対応のSynologyにDockerをぶち込んでいるので、
変なことが起きるのは承知の上でしたが、
今回は思ったよりハマってしまいました…。
Dockerネットワークの知識が深まったので、
非常にいい経験になりました。
以上、ここまで見ていただきありがとうございます。
皆さまの快適な開発ライフに、ほんの少しでもお役に立てれば幸いです。