Telegram Group & Telegram Channel
🚨 Задача: «Исчезающий файл Docker-контейнера»
У вас есть Docker-контейнер, который запускается с помощью следующей команды:


docker run -d --name tricky_container -v /opt/app/logs:/app/logs my-app-image

Приложение внутри контейнера ежедневно генерирует важный лог-файл:


/app/logs/important.log


В течение дня файл корректно пишется и виден в директории на хосте:



/opt/app/logs/important.log


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

🎯 Задача для специалиста:
Выяснить причину исчезновения файла ровно в 3:00 ночи.

Объяснить, почему приложение продолжает успешно писать лог, хотя на хосте он не виден.

Предложить решение, которое предотвращает исчезновение файла.

🔍 Подсказки и ограничения (подвохи):
На хосте нет видимых cron-задач и systemd-таймеров, удаляющих файл.

Контейнер запускается без рестартов и остается активным круглосуточно.

Внутри контейнера тоже нет cron-задач.

Docker-контейнеры не пересоздаются автоматически.

Подсказка: хостовая папка /opt/app/logs монтируется на сетевой диск (NFS), и у неё есть внешнее резервное копирование с моментальными снимками (snapshots), которые делаются каждую ночь в 3:00.

🔧 Команды и подходы для расследования:

Шаг 1: Проверить состояние контейнера


docker ps
docker inspect tricky_container
docker logs tricky_container


Шаг 2: Проверить, есть ли файл внутри контейнера



docker exec -it tricky_container ls -l /app/logs/
docker exec -it tricky_container tail /app/logs/important.log


Шаг 3: Проверить монтирование томов и слои файловой системы


docker inspect tricky_container --format '{{json .Mounts}}' | jq


Шаг 4: Исследовать NFS-папку и поведение в момент создания snapshot


df -hT /opt/app/logs
mount | grep nfs


Шаг 5: Проверить inode-файл внутри контейнера и на хосте



docker exec tricky_container ls -li /app/logs/important.log
ls -li /opt/app/logs/important.log


🎲 Ответ :
Файл исчезает, потому что каждую ночь в 3:00 NFS-сервер создает snapshot папки /opt/app/logs, который включает операцию очистки или пересоздания директории.

В результате на хосте директория монтирования получает новый inode, и предыдущий файл перестаёт быть доступен через старый inode, хотя внутри контейнера файл с прежним inode остаётся открыт приложением и продолжает записываться, пока не закрыт.

То есть файл есть (открыт процессом приложения в контейнере), но на хосте его inode больше не соответствует новому inode директории, и файл становится «невидимым».

Решение проблемы:
Приложению необходимо после каждой операции snapshot заново открывать файлы логов, либо перезапускать контейнер после snapshot.

Либо использовать локальное монтирование (local volume) вместо NFS с snapshot, либо настроить snapshot так, чтобы он не менял inode директории.


@DevopsDocker



tg-me.com/DevOPSitsec/1466
Create:
Last Update:

🚨 Задача: «Исчезающий файл Docker-контейнера»
У вас есть Docker-контейнер, который запускается с помощью следующей команды:


docker run -d --name tricky_container -v /opt/app/logs:/app/logs my-app-image

Приложение внутри контейнера ежедневно генерирует важный лог-файл:


/app/logs/important.log


В течение дня файл корректно пишется и виден в директории на хосте:



/opt/app/logs/important.log


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

🎯 Задача для специалиста:
Выяснить причину исчезновения файла ровно в 3:00 ночи.

Объяснить, почему приложение продолжает успешно писать лог, хотя на хосте он не виден.

Предложить решение, которое предотвращает исчезновение файла.

🔍 Подсказки и ограничения (подвохи):
На хосте нет видимых cron-задач и systemd-таймеров, удаляющих файл.

Контейнер запускается без рестартов и остается активным круглосуточно.

Внутри контейнера тоже нет cron-задач.

Docker-контейнеры не пересоздаются автоматически.

Подсказка: хостовая папка /opt/app/logs монтируется на сетевой диск (NFS), и у неё есть внешнее резервное копирование с моментальными снимками (snapshots), которые делаются каждую ночь в 3:00.

🔧 Команды и подходы для расследования:

Шаг 1: Проверить состояние контейнера


docker ps
docker inspect tricky_container
docker logs tricky_container


Шаг 2: Проверить, есть ли файл внутри контейнера



docker exec -it tricky_container ls -l /app/logs/
docker exec -it tricky_container tail /app/logs/important.log


Шаг 3: Проверить монтирование томов и слои файловой системы


docker inspect tricky_container --format '{{json .Mounts}}' | jq


Шаг 4: Исследовать NFS-папку и поведение в момент создания snapshot


df -hT /opt/app/logs
mount | grep nfs


Шаг 5: Проверить inode-файл внутри контейнера и на хосте



docker exec tricky_container ls -li /app/logs/important.log
ls -li /opt/app/logs/important.log


🎲 Ответ :
Файл исчезает, потому что каждую ночь в 3:00 NFS-сервер создает snapshot папки /opt/app/logs, который включает операцию очистки или пересоздания директории.

В результате на хосте директория монтирования получает новый inode, и предыдущий файл перестаёт быть доступен через старый inode, хотя внутри контейнера файл с прежним inode остаётся открыт приложением и продолжает записываться, пока не закрыт.

То есть файл есть (открыт процессом приложения в контейнере), но на хосте его inode больше не соответствует новому inode директории, и файл становится «невидимым».

Решение проблемы:
Приложению необходимо после каждой операции snapshot заново открывать файлы логов, либо перезапускать контейнер после snapshot.

Либо использовать локальное монтирование (local volume) вместо NFS с snapshot, либо настроить snapshot так, чтобы он не менял inode директории.


@DevopsDocker

BY DevOps


Warning: Undefined variable $i in /var/www/tg-me/post.php on line 283

Share with your friend now:
tg-me.com/DevOPSitsec/1466

View MORE
Open in Telegram


DevOps Telegram | DID YOU KNOW?

Date: |

The global forecast for the Asian markets is murky following recent volatility, with crude oil prices providing support in what has been an otherwise tough month. The European markets were down and the U.S. bourses were mixed and flat and the Asian markets figure to split the difference.The TSE finished modestly lower on Friday following losses from the financial shares and property stocks.For the day, the index sank 15.09 points or 0.49 percent to finish at 3,061.35 after trading between 3,057.84 and 3,089.78. Volume was 1.39 billion shares worth 1.30 billion Singapore dollars. There were 285 decliners and 184 gainers.

Telegram has exploded as a hub for cybercriminals looking to buy, sell and share stolen data and hacking tools, new research shows, as the messaging app emerges as an alternative to the dark web.An investigation by cyber intelligence group Cyberint, together with the Financial Times, found a ballooning network of hackers sharing data leaks on the popular messaging platform, sometimes in channels with tens of thousands of subscribers, lured by its ease of use and light-touch moderation.DevOps from br


Telegram DevOps
FROM USA