Docker «мережу не знайдено»: відновлення мереж без руйнувань

Що насправді означає «мережу не знайдено»

Мережі Docker — це переважно облік. Коли ви створюєте мережу, Docker зберігає запис (ім’я, ID, драйвер, налаштування IPAM) у локальному стані. Коли контейнер стартує, Docker питає: «підключити цей кінцевий пункт контейнера до мережі X». Якщо Docker не може знайти X за ID, ви отримуєте «мережу не знайдено».

Складність у тому, що видиме ім’я — не справжній ключ. Docker використовує ID мережі, а Compose зберігає/використовує цей ID у фоні. Якщо запис мережі видалено, пошкоджено або стан демона скинуто, Compose все ще може намагатися підключити контейнери до тепер неіснуючого ID. Так ви опиняєтеся з мережею, яка «існує» в YAML, «існує» у вашій уяві, але не в реальному стані Docker.

Де з’являється помилка

• docker run: Error response from daemon: network <id> not found
• docker compose up: збій під час створення контейнера або підключення
• Swarm: завдання зависли з помилками при підключенні до мережі
• Після перезавантаження: демон перезапускається й «забуває» мережі через пошкоджений каталог стану або часткове відновлення

Важливо: «мережу не знайдено» — це не те саме, що «неможливо дістатися до сервісу». Останнє зазвичай пов’язане з маршрутизацією, iptables/nftables, MTU, DNS або конфігурацією застосунку. «Мережу не знайдено» майже завжди — це проблема контрольної площини стану: Docker не може знайти об’єкт мережі, до якого ви звертаєтеся.

Сухо-жартівлива правда: мережі Docker — як організаційні діаграми. Ви можете видалити коробку, але всі все одно намагаються їй підпорядковуватись.

План швидкої діагностики (перевірте це спочатку)

Це послідовність, яка мінімізує побічні збитки і швидко переводить вас від «текст помилки» до «виправлення». Мета — не бути креативним; мета — бути швидким і точним.

1) Визначте, що саме падає і якої мережі воно потребує

Схопіть точну помилку. Чи вказується там ім’я мережі, чи шестнадцятковий ID? ID видають, що щось зберегло застаріле посилання.

2) Підтвердьте, чи вважає Docker, що мережа існує

Якщо docker network ls її не показує, то ви маєте справу не з проблемою пакетів, а з відсутнім станом.

3) Перевірте, чи створював Compose мережу і чи є мітки проекту

Мережі Compose мають мітки на кшталт com.docker.compose.project. Якщо цих міток уже немає, ви відновлюєте, а не налагоджуєте.

4) Перевірте здоров’я демона і логи перед тим, як «виправляти» щось

Стан мережі зникає з причин: диск заповнений, корупція файлової системи, падіння демона або надмірне прибирання. Ставте це як симптом більшої проблеми, доки не доведете зворотнє.

5) Визначте радіус ураження: один проект чи весь хост

Якщо постраждав лише один проект Compose, не підпалюйте весь хост. Відновіть мережу проекту і підключіть повторно. Якщо зникли кілька мереж, підозрюйте пошкодження стану демона; може знадобитися контрольований скидання.

Цікаві факти та трохи історії (бо це допомагає)

1. Мереження «bridge» у Docker з’явилося раніше за сучасні робочі процеси Compose. Ранній Docker за замовчуванням використовував міст docker0 і NAT через iptables; користувацькі bridge-мережі з’явилися пізніше, щоб покращити DNS і ізоляцію.
2. Користувацькі bridge-мережі мають вбудований DNS за іменами. Вбудований DNS-сервер (зазвичай на 127.0.0.11 у контейнерах) дозволяє контейнерам вирішувати імена сервісів без додаткових інструментів.
3. Compose v2 — це плагін CLI Docker. Перехід від окремого інструмента на Python до плагіна змінив спосіб появи помилок і спосіб обробки контекстів.
4. ID мереж — як непрозорі ідентифікатори за вмістом. Люди оперують іменами; демон оперує ID. Втрата відповідності — ось чому «але в YAML написано…» втрачає сенс.
5. iptables vs nftables — постійне джерело проблем. Docker історично програмував iptables напряму; на деяких дистрибутивах бекенд nftables змінює поведінку й дивує людей.
6. Локальний стан Docker живе в /var/lib/docker. Якщо цей каталог видалено, частково відновлено або змонтовано по-іншому, мережі «зникають» разом із усім іншим.
7. Overlay-мережі створені для мультихостового сценарію Swarm. Навіть якщо ви ніколи не використовуєте Swarm, модель мережі все одно проявляється в рядках помилок і драйверах.
8. Існують драйвери MACVLAN/IPVLAN, щоб обходити міст. Вони чудові — поки ваша команда мереж не дізнається про них і не запитає, чому хост не може спілкуватися зі своїми контейнерами.
9. Деякі інструменти «прибирання» видаляють мережі агресивніше, ніж ви думаєте. Все, що робить prune «невикористовуваних» об’єктів, може входити в гонку зі рестартами або помилково класифікувати ресурси як невикористані.

Одна переказана думка, яка варта паперу на вашому столі, часто приписують Werner Vogels: все ламається постійно — проектуйте і експлуатуйте, припускаючи, що компоненти будуть падати (парафраз).

Типові причини відмов і режими збоїв

1) Мережу видалили (іноді «допоміжно»)

Хтось виконав docker network rm для «невикористовуваних» мереж. Або робота з прибиранням виконала prune. Або CI-агент на спільному хості прибрав за собою, і «після себе» включало ваші мережі.

2) Дрейф або корупція стану демона Docker

Нечисте завершення роботи + проблеми з диском + навантажена файлова система можуть призвести до часткового стану. Docker стартує, але деякі об’єкти відсутні. Мережі часто перші жертви, бо це метадані й вони посилаються ID в багатьох об’єктах.

3) Перейменування проекту Compose або переміщення директорії

Compose використовує ім’я проекту (часто похідне від директорії) для найменування ресурсів. Перемістіть директорію або змініть COMPOSE_PROJECT_NAME, і ви отримаєте контейнери, які очікують мережі, створені під старим ім’ям проекту.

4) Кілька контекстів Docker або неправильний хост

Ви думаєте, що на продакшні, але ваш CLI вказує на інший Docker-контекст. Мережа «відсутня», бо ви дивитеся на інший демон. Це трапляється частіше, ніж люди зізнаються.

5) Swarm і overlay-мережі в напівналаштованому стані

Overlay-мережі залежать від кластерного стану. Якщо вузол більше не у кластері, або стан менеджера неконсистентний, завдання можуть падати при підключенні до мережі.

6) Блокування брандмауером/iptables/nftables (але це інша помилка)

Це поширена відволікаюча проблема. Зламані правила NAT зазвичай призводять до проблем доступності, а не до «мережу не знайдено». Проте: перезапуск демона може перепрограмувати правила і стикнутися зі змінами дистрибутиву.

Практичні завдання: команди, очікуваний вивід і рішення

Це реальні операційні дії. Кожне завдання включає: команду, що означає вивід, і яке рішення приймати далі. Не копіюйте сліпо на спільному хості. Читайте, що робите, а потім робіть.

Завдання 1: Підтвердьте, що ви говорите з правильним демоном Docker

cr0x@server:~$ docker context show
default

Що це означає: Ви використовуєте контекст default (локальний демон). Якщо показано інше, можливо, ви налагоджуєте не ту машину.

Рішення: Якщо несподівано, виконайте docker context ls, перемкніться на правильний контекст і ще раз перевірте проблему перед тим, як чіпати мережі.

Завдання 2: Перевірте, чи демон здоровий і відповідає

cr0x@server:~$ docker info --format '{{.ServerVersion}} {{.OperatingSystem}}'
27.2.0 Ubuntu 24.04.1 LTS

Що це означає: CLI може поговорити з демоном і отримати структуровану інформацію. Якщо це зависає або помилка, ваша проблема мережі може бути проблемою демона.

Рішення: Якщо не відповідає, перевірте systemd і логи спочатку. Не крутить мережі, поки демон хворий.

Завдання 3: Перелічте мережі і подивіться, що зараз існує

cr0x@server:~$ docker network ls
NETWORK ID     NAME              DRIVER    SCOPE
1f3a2c1a9e2d   bridge            bridge    local
a9b7b5d41c1f   host              host      local
c3d6f2d51c9a   none              null      local

Що це означає: Існують лише мережі за замовчуванням. Якщо ваша мережа Compose відсутня, це сильно вказує на «видалення мережі» або «втрата стану».

Рішення: Якщо цільова мережа відсутня, припиніть спроби «підключити» до неї контейнери. Плануйте її створення заново.

Завдання 4: Знайдіть посилання на мережу з проблемного контейнера

cr0x@server:~$ docker inspect -f '{{json .NetworkSettings.Networks}}' api_1
null

Що це означає: Контейнер не приєднаний до жодної мережі (або не існує). Якщо контейнер не вдалося створити, inspect може взагалі не виконатися.

Рішення: Якщо контейнера немає, подивіться події/логи Compose; посилання на мережу ймовірно буде в помилці під час створення.

Завдання 5: Інспектуйте мережу за іменем (якщо ви думаєте, що вона існує)

cr0x@server:~$ docker network inspect app_default
[]
Error response from daemon: network app_default not found

Що це означає: Docker підтверджує, що об’єкт мережі відсутній.

Рішення: Пересоздайте мережу (зазвичай через Compose), замість спроби ремонту підключень.

Завдання 6: Перевірте, як Compose бачить проект

cr0x@server:~$ docker compose ls
NAME            STATUS              CONFIG FILES
app             running(3)          /srv/app/docker-compose.yml

Що це означає: Docker Compose вважає, що проект існує. Він може все ще працювати частково.

Рішення: Якщо статус несумісний з реальністю, можливо є сирітські контейнери або відсутні мережі. Наступний крок: docker compose ps.

Завдання 7: Подивіться, що Compose вважає запущеним і які мережі він очікує

cr0x@server:~$ docker compose -p app ps
NAME      IMAGE          COMMAND               SERVICE   STATUS
app-db-1  postgres:16    "docker-entrypoint…"  db        Up 2 hours
app-api-1 app-api:latest "/bin/api"            api       Exit 1

Що це означає: Деякі сервіси запущені, деякі падають. Це часто відбувається, коли підмножина контейнерів підключена до тепер відсутньої мережі або мережа зникла після рестартів.

Рішення: Перевірте логи і події для сервісу, що падає; підтвердьте, що «мережу не знайдено» — це причина, а не крах додатка.

Завдання 8: Дістаньте реальну причину падіння з подій

cr0x@server:~$ docker events --since 10m --filter type=container --filter event=start --filter event=die
2026-01-03T09:11:26.321615241Z container start 5a8c0e3f8b2b (name=app-api-1, image=app-api:latest)
2026-01-03T09:11:26.412992531Z container die 5a8c0e3f8b2b (exitCode=1, name=app-api-1, image=app-api:latest)

Що це означає: Контейнер стартував, а потім помер (exit 1). Це не «мережу не знайдено». Це помилка на рівні застосунку.

Рішення: Якщо події показують помилки при створенні контейнера (збої при приєднанні до мережі часто з’являються там), фокусуйтеся на відновленні мережі. Якщо контейнер помирає після старту — налагоджуйте логи застосунку.

Завдання 9: Перевірте логи демона на помилки зберігання мереж або libnetwork

cr0x@server:~$ sudo journalctl -u docker --since "1 hour ago" | tail -n 20
Jan 03 09:03:10 server dockerd[1123]: time="2026-01-03T09:03:10.991132145Z" level=error msg="network sandbox join failed" error="network app_default not found"
Jan 03 09:03:10 server dockerd[1123]: time="2026-01-03T09:03:10.991264223Z" level=error msg="Handler for POST /v1.46/containers/create returned error: network app_default not found"

Що це означає: Демон явно не може створити контейнер через відсутню мережу. Це підручниковий випадок.

Рішення: Пересоздайте app_default (краще через docker compose up, який також правильно проставить мітки). Уникайте ручного створення, якщо вам не потрібно точно співпадати з налаштуваннями IPAM.

Завдання 10: Знайдіть, хто «володіє» мережею (мітки важливі)

cr0x@server:~$ docker network inspect -f '{{json .Labels}}' app_default
Error response from daemon: network app_default not found

Що це означає: Не знайдено, тому міток інспектувати нема. Коли мережа існує, мітки скажуть, чи створив її Compose і який проект.

Рішення: Якщо ви пересоздаєте вручну, ви втрачаєте метадані власності Compose, якщо не відновите мітки (що не рекомендовано). Краще: дайте це зробити Compose.

Завдання 11: Пересоздайте мережу правильним, нудним шляхом (Compose)

cr0x@server:~$ cd /srv/app
cr0x@server:/srv/app$ docker compose -p app up -d
[+] Running 4/4
 ✔ Network app_default  Created
 ✔ Container app-db-1   Started
 ✔ Container app-api-1  Started
 ✔ Container app-web-1  Started

Що це означає: Compose створив відсутню мережу і запустив контейнери. Зазвичай це найчистіше виправлення.

Рішення: Перевірте з’єднання та DNS. Якщо контейнери все ще падають з «мережу не знайдено», можливо є кілька проектів або застарілі посилання; переходьте до глибшого прибирання.

Завдання 12: Перевірте драйвер мережі і підмережу (щоб упіймати тихі відмінності)

cr0x@server:~$ docker network inspect -f 'Driver={{.Driver}} Subnet={{(index .IPAM.Config 0).Subnet}}' app_default
Driver=bridge Subnet=172.22.0.0/16

Що це означає: Підтверджує драйвер і конфігурацію IPAM. Якщо підмережа відрізняється від очікувань ваших правил брандмауера або allowlist, ви отримаєте ситуацію «він стартує, але нічого не бачить».

Рішення: Якщо підмережа має бути стабільною, фіксуйте її в Compose через ipam і відтворюйте навмисно, а не випадково.

Завдання 13: Перевірте resolv.conf контейнера і поведінку вбудованого DNS

cr0x@server:~$ docker exec app-api-1 cat /etc/resolv.conf
nameserver 127.0.0.11
options ndots:0

Що це означає: Вбудований DNS використовується. Якщо DNS не працює, часто причина — контейнер на неправильній мережі або мережа зламано.

Рішення: Якщо бачите DNS-хост замість вбудованого, можливо використовується network_mode: host або кастомні налаштування. Це змінює підхід до налагодження.

Завдання 14: Підтвердьте резолюцію імен між сервісами в мережі

cr0x@server:~$ docker exec app-api-1 getent hosts db
172.22.0.2      app-db-1

Що це означає: DNS працює і db резолюється в очікувану IP-адресу контейнера.

Рішення: Якщо не резолюється, перевірте, що обидва контейнери в одній мережі і що ви використовуєте правильне ім’я сервісу.

Завдання 15: Покажіть, до яких мереж приєднаний контейнер (уникнути гадань)

cr0x@server:~$ docker inspect -f '{{range $k,$v := .NetworkSettings.Networks}}{{$k}} {{end}}' app-api-1
app_default 

Що це означає: Контейнер приєднаний до app_default.

Рішення: Якщо контейнер приєднаний до іншої мережі, ніж очікується (наприклад, bridge), виправте Compose-файл або пересоздайте контейнер.

Завдання 16: Виявлення сирітських кінцевих точок та мереж «використовується» перед видаленням

cr0x@server:~$ docker network inspect -f 'Containers={{len .Containers}}' app_default
Containers=3

Що це означає: Три кінцеві точки контейнерів приєднані. Якщо ви спробуєте видалити цю мережу, Docker відмовить, доки не відключите або не видалите контейнери.

Рішення: Якщо треба перебудувати мережу, плануйте контрольовану зупинку/пересоздання стеку.

Завдання 17: Безпечно зупинити проект і видалити лише його мережу

cr0x@server:~$ cd /srv/app
cr0x@server:/srv/app$ docker compose -p app down
[+] Running 4/4
 ✔ Container app-web-1  Removed
 ✔ Container app-api-1  Removed
 ✔ Container app-db-1   Removed
 ✔ Network app_default  Removed

Що це означає: Контейнери проекту і його мережа за замовчуванням видалені. Томики залишаються, якщо ви не використовували -v.

Рішення: Це безпечний метод перебудови, коли мережа пошкоджена або неправильно налаштована. Далі: docker compose up -d для пересоздання.

Завдання 18: Перевірте, чи iptables/nftables не були мовчки зруйновані

cr0x@server:~$ sudo iptables -S DOCKER | head -n 5
-N DOCKER
-A DOCKER -i docker0 -j RETURN
-A DOCKER ! -i docker0 -p tcp -m tcp --dport 5432 -j DNAT --to-destination 172.22.0.2:5432

Що це означає: Ланцюги iptables Docker існують. Якщо ланцюг DOCKER відсутній або порожній на хості, що покладається на опубліковані порти, доступність впаде, навіть якщо мережа існує.

Рішення: Якщо ланцюги відсутні після перезапуску демона, перевірте конфіг демона, менеджер брандмауера і чи використовує хост бекенд nftables з несумісними правилами.

Жарт #1: Якщо ви вирішили проблему мереж Docker перезавантаженням, ви її не вирішили — ви просто зіграли в рулетку і виграли цього разу.

Як відновити мережі, не поламавши все

Принцип 1: Віддавайте перевагу пересозданню мереж тим інструментом, який їх створив

Якщо мережу створив Compose — дайте Compose її пересоздати. Compose ставить мітки й іменування, які роблять майбутні операції передбачуваними. Ручне docker network create підходить для одноразових експериментів; у продакшн-стеках це спосіб створювати загадки.

Принцип 2: Обмежуйте радіус ураження

Є три масштаби втручання:

• Масштаб проекту: Пересоздайте app_default і лише контейнери проекту.
• Масштаб хоста: Ремонтуйте мережі за замовчуванням (bridge/docker0) і програмування iptables. Ризиковано.
• Скидання стану демона: Останній засіб; може знищити весь стан Docker на хості.

Перебудова в масштабі проекту: найпоширеніше безпечне виправлення

Якщо ви отримуєте «мережу не знайдено» для мережі, якою керує Compose, зробіть таке:

1. Підтвердьте ім’я мережі, яке очікує Compose (часто <project>_default).
2. Запустіть docker compose up -d у правильній директорії та з правильним ім’ям проекту. Це має пересоздати мережу, якщо вона відсутня.
3. Якщо контейнери зависли або частково створені — виконайте docker compose down, а потім up -d.

Коли docker compose up -d не виправляє проблему? Коли у вас є застарілі ресурси з конфліктними іменами, невідповідні імена проектів або зовнішні мережі, які посилаються, але не створені.

Зовнішні мережі: де люди самі собі ставлять пастки

Compose підтримує external: true. Це означає «Compose не створюватиме цю мережу». Якщо мережа відсутня — Compose впаде, і правильно зробить. Це сценарій, за який оператори лають Compose. На ділі він не зламався — ви сказали йому не створювати мережу.

Якщо ваш стек використовує зовнішні мережі, ваша задача — гарантувати, що вони існують і мають стабільну конфігурацію (підмережа, драйвер) при відновленнях хоста. Якщо ви не можете це гарантувати — припиніть використовувати зовнішні мережі без серйозної причини.

Ручне пересоздання (лише якщо треба)

Іноді ви не можете запустити Compose (CI-система впала, репо недоступне, або потрібно тимчасово підняти критичні сервіси). У такому випадку пересоздавайте вручну з обережністю:

• Підберіть драйвер (bridge, overlay, macvlan).
• Врахуйте налаштування IPAM, якщо щось залежить від фіксованих діапазонів.
• Знайте, що міток і власності Compose не буде — це вплине на майбутнє docker compose down.

cr0x@server:~$ docker network create --driver bridge --subnet 172.22.0.0/16 app_default
b9a1f1a2a3c4d5e6f7a8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8

Що це означає: Ви створили bridge-мережу з фіксованою підмережею.

Рішення: Використовуйте це лише як тимчасовий захід. Коли стан стабільний — поверніться до управління мережами через Compose, щоб уникнути дрейфу конфігурацій.

Відновлення мережі за замовчуванням (docker0) без хаосу

Якщо помилка стосується мережі bridge або docker0 відсутній/пошкоджений — ви в зоні втручання на рівні хоста. Симптоми: контейнери не стартують навіть з дефолтною мережею, або опубліковані порти перестали працювати після оновлень.

Дійте як доросла людина:

• Заплануйте вікно технічного обслуговування, якщо на хості є важливі сервіси.
• Обережно зупиніть робочі навантаження (Compose down, Swarm drain тощо).
• Перезапустіть Docker і перевірте docker0, маршрути і ланцюги iptables.

cr0x@server:~$ ip link show docker0
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
    link/ether 02:42:8f:aa:bb:cc brd ff:ff:ff:ff:ff:ff

Що це означає: Інтерфейс існує. Стан DOWN нормальний, якщо немає приєднаних контейнерів.

Рішення: Якщо docker0 не існує, підозрюйте конфіг демона, що вимикає створення bridge, або пошкоджений каталог стану.

Скидання стану демона: останній засіб, дуже гострий інструмент

Якщо мережі регулярно зникають або Docker відмовляється створювати нові — можливо, у вас пошкоджений /var/lib/docker (або проблеми зі сторедж-драйвером). Виправлення може полягати у очищенні стану Docker і повторному розгортанні робочих навантажень із джерела істини. Це не «пересоздати мережу». Це «перебудувати вузол».

Не імпровізуйте це на сервері, де є єдина копія ваших томів. Якщо не впевнені — зупиніться і перераховуйте, де у вас які дані лежать.

Жарт #2: «docker system prune -a» — це не план обслуговування; це тест характеру.

Три міні-історії з корпоративного світу (з болем)

Міні-історія 1: Інцидент через невірне припущення

Середня компанія запускала кілька внутрішніх додатків на одній великій ВМ. Команда користувалась Docker Compose, і все працювало настільки добре, що ніхто довго не чіпав секцію мережі. Потім інженер додав external: true мережу, бо хотів, щоб два проекти Compose ділили мережу з reverse proxy.

Вони припустили, що «external» означає «спільна між проектами», і що Compose все одно створить її, якщо її немає. Вони розгорнули нову ВМ з образу, виконали docker compose up -d і побачили негайний провал: «network proxy_net not found». На виклику інженер робив те, що роблять на виклику: повторював спроби, перезапускав Docker, знову пробував.

Аутейджом стало не саме повідомлення; ним була реакція. Під тиском вони створили мережу вручну — але використали іншу підмережу, ніж на старому хості. Reverse proxy встало, але внутрішні allowlist-правила і кілька хардкодних перевірок моніторингу очікували попередній діапазон. Половина трафіку тепер «таємниче» блокувалась брандмауером, що мав захищати базу даних.

Виправлення було простим і навчальним: створити зовнішню мережу явно і зафіксувати її підмережу в інфраструктурному коді, а не в чийомусь пам’яті. Потім відтворити хост контрольовано, щоб конфігурація мережі не залежала від того, хто її ввів у терміналі.

Міні-історія 2: Оптимізація, що відкотилась

Інша організація хотіла «швидших розгортань» і зменшити використання диска. Хтось додав щоденну задачу прибирання, яка виконувала prune для видалення невикористаних об’єктів Docker. Це звільнило простір — поки не перестало.

Задача запустилась у тихий період, коли стек Compose якраз перебудовувався. На короткий час контейнери були зупинені і мережі виглядали «невикористаними». Prune видалив користувацьку bridge-мережу, яка мала бути використана за секунду. Розгортання продовжилось, і контейнери не змогли стартувати: «мережу не знайдено». Алерт прилетів із затримкою, бо перевірки здоровʼя запускались раз на кілька хвилин. Чудовий таймінг.

«Підправили» це повторним запуском розгортання, що пересоздало мережу. Але справжня шкода була в тому, що задача prune залишилась. Через тижні такий же сценарій спрацював знову, але вже під час більшого вікна змін. Другий інцидент тривав довше, бо інженери гналися за привидами iptables і DNS, які не були коренем проблеми.

Підсумок був нудний: виконувати prune лише з явними фільтрами, ніколи не на спільних хостах і ніколи без перевірки наявних розгортань. Також перемістили робочі навантаження на систему з епhemeral-ноду, де прибирання стало неважливе. Швидкість зросла — не тому, що prune був розумним, а тому, що платформа перестала бути крихкою.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Одна команда в фінансовому секторі мала правило: кожен проект Compose повинен оголошувати свої мережі з явними іменами і IPAM-діапазонами, і кожна зовнішня мережа має створюватись кроком провізії перед запуском будь-якого додатку. Правило дратувало розробників, що зазвичай означає — воно корисне.

Одного дня хост втратив стан Docker після інциденту з диском. Мережі зникли. Контейнери зникли. У всіх був поганий вечір. Але runbook для відновлення не передбачав домислів: створити зовнішні мережі, розгорнути стек Compose, перевірити з’єднання. Оскільки підмережі були закріплені, правила брандмауера і моніторинг не потребували аварійних правок.

Відновлення не було магічним; воно було передбачуваним. У runbook також був пункт «перевірте, що ви в правильному Docker-контексті» і «збережіть docker info і journalctl у тикеті інциденту». Це означало менше фольклору і більше доказів.

Інцидент все одно стався. Але не було другого, самостійно спричиненого інциденту зверху. В операціях виграш виглядає саме так.

Типові помилки: симптом → корінь проблеми → виправлення

1) Симптом: «network <hex> not found» після переміщення директорії проекту Compose

Корінь проблеми: Змiнилося ім’я проекту, старі ресурси, до яких посилаються за ID, більше не існують, або ви викликаєте Compose з іншим значенням -p.

Виправлення: Запустіть Compose з початковим ім’ям проекту, якщо хочете повторно використати ресурси, або виконайте docker compose -p <name> down (якщо можливо) і перерозгорніть із новим ім’ям послідовно.

2) Симптом: Compose падає лише на мережі, позначеній як external

Корінь проблеми: Зовнішня мережа не створена (за дизайном Compose її не створює).

Виправлення: Створіть її явно (найкраще через провізію/автоматизацію) і зафіксуйте підмережу/драйвер, щоб відповідало очікуванням.

3) Симптом: «мережу не знайдено» з’являється після роботи прибирання або через тиск на диск

Корінь проблеми: Автоматичний prune видалив мережі або стан Docker частково загубився через заповненість диска/корупцію.

Виправлення: Приберіть/обмежте роботи прибирання; перебудуйте мережі через Compose; дослідіть стан хосту і надійність диска та стану Docker.

4) Симптом: Мережа існує, але нові контейнери не можуть приєднатись; помилки згадують sandbox/join

Корінь проблеми: Застарілі кінцеві точки, залишкові veth-пари або внутрішня неконсистентність демона/libnetwork після падінь.

Виправлення: Контрольований рестарт проекту (compose down/up). Якщо проблема постійна між проектами — перезапустіть Docker у вікні обслуговування; якщо й далі ламається — плануйте перебудову вузла.

5) Симптом: Опубліковані порти перестали працювати, але немає «мережу не знайдено»

Корінь проблеми: Програмування iptables/nftables зламалось; менеджер брандмауера перезаписав ланцюги Docker.

Виправлення: Виправте інтеграцію з брандмауером; перезапустіть Docker після корекції; перевірте ланцюги DOCKER та правила NAT.

6) Симптом: Ви не бачите мережу, але колеги бачать

Корінь проблеми: Неправильний Docker-контекст, неправильний хост або SSH-сесія у невідповідному середовищі.

Виправлення: Підтвердіть контекст і кінцеву точку; стандартизуйте підказки в шеллі; вимагайте явних індикаторів середовища в runbook’ах.

Чеклісти / покрокові плани

Чекліст A: Один стек Compose падає з «мережу не знайдено»

1. Підтвердьте Docker-контекст і ідентичність хоста (уникнете налагодження не того сервера).
2. Не виконуйте prune. Спочатку зберіть докази:
   • docker network ls
   • docker compose -p <proj> ps
   • sudo journalctl -u docker --since "1 hour ago"
3. Якщо відсутня мережа проекту за замовчуванням: запустіть docker compose up -d з правильної директорії.
4. Якщо досі падає: виконайте docker compose down (без томів), потім docker compose up -d.
5. Перевірте: docker network inspect (driver/subnet), docker exec ... getent hosts ....
6. Якщо повторюється: знайдіть і вбивайте процес, що видаляє мережі (завдання прибирання, звичка людини, CI-агент).

Чекліст B: Пошкоджені кілька проектів або відсутні мережі за замовчуванням

1. Підозрюйте проблему на рівні хоста, поки не доведено протилежне.
2. Перевірте логи демона на помилки зберігання/стану; перевірте вільне місце на диску і стан файлової системи.
3. Заплануйте вікно обслуговування (так, навіть якщо це «лише мережа»).
4. Обережно зупиніть робочі навантаження.
5. Перезапустіть Docker; підтвердіть, що docker0 існує і ланцюги iptables на місці.
6. Якщо стан явно пошкоджений: перебудуйте вузол з джерела істини, а не редагуйте вручну /var/lib/docker.

Чекліст C: Стратегія зовнішніх мереж, що не підведе згодом

1. Використовуйте зовнішні мережі лише коли справді потрібна крос-проектна комунікація.
2. Створюйте їх у коді провізії, а не в історії терміналу людини.
3. Закріплюйте підмережу і драйвер і документуйте причину.
4. Перевіряйте за допомогою тимчасового контейнера: приєднати, вирішити імена, доступити очікувані порти.
5. Аудитуйте роботи прибирання: зовнішні мережі ніколи не повинні автоматично prune-итись на спільних хостах.

Питання та відповіді

1) Чому Docker скаржиться на ID мережі замість імені?

Бо всередині Docker посилається на мережі за ID. Імена — для людей. Стек і контейнери часто зберігають ID, тому коли ID зникає — ви отримуєте шестнадцяткову підказку.

2) Чи можу я просто пересоздати мережу з тим самим ім’ям і все буде гаразд?

Іноді. Але якщо контейнер посилається на старий ID мережі, пересоздання по імені не допоможе, поки контейнер не пересоздамо або не перепідключено. Найбезпечніше — дати Compose пересоздати і мережу, і уражені контейнери.

3) Чи docker compose up -d автоматично пересоздає відсутні мережі?

Так, для мереж, якими він керує (не зовнішніх). Якщо мережа позначена external: true, Compose її не створюватиме і впаде, якщо вона відсутня.

4) Який найбезпечніший спосіб перебудувати зламану мережу Compose?

docker compose down (без -v, якщо ви цього не хочете), потім docker compose up -d. Це очищає контейнери і мережу проекту і пересоздає чисто.

5) Чи видалення мережі видалить мої дані?

Видалення мережі не видаляє томи. Але якщо ваші дані живуть у файловій системі контейнера (без томів), видалення контейнерів призведе до втрати цих даних. Зробіть інвентар томів перед «прибиранням».

6) Як дізнатись, чи причиною була робота прибирання?

Перевірте systemd timers/cron, CI-скрипти і shell-history. Також подивіться часові позначки в логах демона: раптове «network removed» або розрив, за яким йде відсутність мереж, — сильний знак.

7) Чи може «мережу не знайдено» спричинити iptables або брандмауер?

Зазвичай ні. Проблеми з брандмауером викликають проблеми доступності, а не помилки відсутності об’єкта. Якщо демон каже «не знайдено», він не може знайти об’єкт мережі у своєму стані.

8) Що робити, якщо це Swarm і overlay-мережі?

Тут треба підтвердити здоров’я кластера Swarm. Overlay-мережі залежать від стану менеджерів. Вузол, що покинув кластер, або зламана кворум-менеджерів може призвести до помилок при підключенні завдань. Виправте стан кластера, а потім повторно розгорніть сервіси.

9) Як запобігти цьому надалі?

Не запускайте агресивні prune-роботи на спільних хостах, фіксуйте конфігурацію мереж, коли потрібна стабільність, і ставтесь до /var/lib/docker як до важливого стану, який потребує справної дискової інфраструктури і моніторингу.

Наступні кроки, які варто зробити

Коли Docker каже «мережу не знайдено», повірте йому. Не витрачайте час на налагодження пакетів для об’єкта мережі, який не існує.

1. Виконайте швидку діагностику: підтвердьте контекст, підтвердьте, що мережа відсутня, перевірте логи демона.
2. Виправляйте в найменшому масштабі: пересоздайте через Compose для одного проекту; уникайте скидань рівня хоста.
3. Якщо це повторюється — розглядайте це як системну проблему: роботи прибирання, здоров’я диска, стабільність стану демона і повторювана провізія зовнішніх мереж.
4. Напишіть runbook, який вам сьогодні хотілося б мати: команди для перевірки стану і точна послідовність «down/up», яка безпечна для вашого стеку.

Відновлення мереж без руйнувань — це не про героїзм. Це про знання шару, що зламався, і відмову «оптимізувати» шлях до нових аутейджів.