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: |

The SSE was the first modern stock exchange to open in China, with trading commencing in 1990. It has now grown to become the largest stock exchange in Asia and the third-largest in the world by market capitalization, which stood at RMB 50.6 trillion (US$7.8 trillion) as of September 2021. Stocks (both A-shares and B-shares), bonds, funds, and derivatives are traded on the exchange. The SEE has two trading boards, the Main Board and the Science and Technology Innovation Board, the latter more commonly known as the STAR Market. The Main Board mainly hosts large, well-established Chinese companies and lists both A-shares and B-shares.

Can I mute a Telegram group?

In recent times, Telegram has gained a lot of popularity because of the controversy over WhatsApp’s new privacy policy. In January 2021, Telegram was the most downloaded app worldwide and crossed 500 million monthly active users. And with so many active users on the app, people might get messages in bulk from a group or a channel that can be a little irritating. So to get rid of the same, you can mute groups, chats, and channels on Telegram just like WhatsApp. You can mute notifications for one hour, eight hours, or two days, or you can disable notifications forever.

DevOps from sa


Telegram DevOps
FROM USA