Небольшой квест про запуск демки через docker compose

У меня настроена ежедневная сборка демки приложения и выкладывание демки на опубликованный сайт. Все стабильно работало полгода, но сегодня вместо моего сайта я увидел сообщение браузера "Hmmm… can't reach this page" - браузер не получил ответ от сервера.

Как так получилось?

Для начала я попробовал

ping хх.хх.хх.хх

Pinging хх.хх.хх.хх with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for хх.хх.хх.хх:

    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

По ip ответа нет, возможно есть какая-то ошибка: базовый тестовый сервис не отвечает на сетевой запрос. Ошибка критическая на уровне операционки (windows), комп не мой, это арендованная виртуалка, прямого полного доступа у меня нет, надо просить  админа посмотреть почему на ping нет ответа. Написал/попросил/жду ответа.

Пока жду ответа, решил посмотреть как отработали таски выкладывания приложения:

Каждая pipeline запускает скрипты именно на нужной мне виртуалке.
Из списка видно что часть прошла успешно: виртуалка на момент выполнения этого кода точно была живая и на ней точно работали сетевые подключения (сервак azure успешно подключился и запустил несколько pipeline на этой виртуалке).
Т.е. "пару часов назад все работало".

И видно что в последней pipeline возникла ошибка. Логи запуска этого pipeline:

Время совпадает с отказом доступа к демке и надо покопаться в этих логах, ведь там тоже "только что все работало" и возможно именно на этом этапе что-то в моем коде сломало базовый сервис тестирования сетевых подключений (пока что я подозреваю, что все сломал именно мой код).

Детальный просмотр pipeline и его логов показал:

1.  В упавшей pipeline не сработала таска с запуском образов в докере:

2. Внутри в логах упавшей таски есть сообщение об ошибке на запуске одного docker контейнера:

Container demo_initialize  Starting
Container demo_initialize  Started
Container demo_initialize  Waiting
Container demo_initialize  service "demo_initialize" didn't complete successfully: exit 1

3. Детали запуска команд в контейнере можно посмотреть только в логах этого контейнера и эти логи сразу выводятся в следующем succeededOrFailed шаге в этом pipeline (такие логи я сделал для каждого контейнера что бы иметь к ним доступ в один клик):

В этом описании ошибки видно, что не сработал RESTORE DATABASE, потому что "уже есть файл c:\ххх.mdf". По логике работы моих скриптов этого файла не должно быть, а каталог должен быть пустой. В хх.ps1 не выводится контент этого каталога на момент запуска скрипта и я добавил в скрипт новую команду 'Get-ChildItem -Path $ххх' : мне все таки интересно посмотреть на все файлы именно в этом и в других рабочих каталогах скрипта.

Нужный мне каталог декларируется внутри докеровского compose для db_server контейнера как volume:

services:
  db_server:
    image: mssql-express-2022
    container_name: db_server
    volumes:
      - db_volume:c:/_ххх

В нем действительно должны лежать mdf/ldf, я сделал его именно для этого.
Но в этом compose все volume временные, скрипт их целиком пересоздает и на момент запуска compose в них не должно быть файлов.

Однако технически такой volume в докере может сохраняться после завершения compose, данные в нем хранятся в файлах докера и подключаются в любое окружение по имени volume и будет возникать ошибка "file already exists".

Именно эту техническую ситуацию я сразу могу проверить: в моем скрипте есть вывод существующих container/volume в docker. По логам на момент запуска в докере нет ни одного контейнера, есть нужные докер образы, нет ни одного volume:

DEBUG:    5+  >>>> docker ps -a --no-trunc

CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

DEBUG:    7+  >>>> docker images

ххх   web-app                    eefa106326c9   2 hours ago

ххх   demo-initialize            7c041f283871   2 hours ago

ххх   mssql-express-2022   8bd475ced514   4 months ago

DEBUG:    9+  >>>> docker volume ls

DRIVER    VOLUME NAME

DEBUG:   11+  >>>> $PSVersionTable

Т.е. все работает корректно (я надеялся на подвисший volume, но его нет).
Опять не понятно откуда появилась ошибка на существующий файл "c:\_ххх\ххх.mdf"

В этот момент я решил подробно посмотреть логи от каждого предыдущего запуска.

Пока копался в истории запусков и вроде бы уже нашел подозреваемого (кто-то захапал все свободное место на диске) пришли новые логи с ошибкой, только уже на этапе скачивания образов:

failed to register layer: re-exec error: exit status 1: output: hcsshim::ImportLayer failed in Win32: There is not enough space on the disk. (0x70)

В приложениях я часто видел "cannot override file" в ситуации "There is not enough space", возможно для sqlserver внутри докера оказалась именно такая ситуация и поэтому мне был показан текст "cannot override file". А когда свободное место совсем закончилось, то до sqlserver дело не дошло и ошибка возникла на одном из предыдущих шагов.

По истории запусков pipeline я увидел динамику свободного места на диске C:

• вчера - Used 97.06 (GB)     Free 2.40(GB)
• 10 дней назад - Used 92.65 (GB)     Free 6.81(GB)
• 20 дней назад - Used 90.23 (GB)     Free 9.23(GB)
• 30 дней назад - Used 87.82 (GB)     Free 11.64(GB)

По этим записям видно, что кто-то отъедает 300 метров на диске каждый день.

После дополнительных изучений других сервисов на виртуалке виновник был найден и ограничен в своих аппетитах, занятое место освобождено и опубликованная демка успешно заработала.