Warning: mkdir(): No space left on device in /var/www/tg-me/post.php on line 37

Warning: file_put_contents(aCache/aDaily/post/DevOPSitsec/--): Failed to open stream: No such file or directory in /var/www/tg-me/post.php on line 50
DevOps | Telegram Webview: DevOPSitsec/1466 -
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: |

Dump Scam in Leaked Telegram Chat

A leaked Telegram discussion by 50 so-called crypto influencers has exposed the extraordinary steps they take in order to profit on the back off unsuspecting defi investors. According to a leaked screenshot of the chat, an elaborate plan to defraud defi investors using the worthless “$Few” tokens had been hatched. $Few tokens would be airdropped to some of the influencers who in turn promoted these to unsuspecting followers on Twitter.

In many cases, the content resembled that of the marketplaces found on the dark web, a group of hidden websites that are popular among hackers and accessed using specific anonymising software.“We have recently been witnessing a 100 per cent-plus rise in Telegram usage by cybercriminals,” said Tal Samra, cyber threat analyst at Cyberint.The rise in nefarious activity comes as users flocked to the encrypted chat app earlier this year after changes to the privacy policy of Facebook-owned rival WhatsApp prompted many to seek out alternatives.DevOps from sg


Telegram DevOps
FROM USA