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

Spiking bond yields driving sharp losses in tech stocks

A spike in interest rates since the start of the year has accelerated a rotation out of high-growth technology stocks and into value stocks poised to benefit from a reopening of the economy. The Nasdaq has fallen more than 10% over the past month as the Dow has soared to record highs, with a spike in the 10-year US Treasury yield acting as the main catalyst. It recently surged to a cycle high of more than 1.60% after starting the year below 1%. But according to Jim Paulsen, the Leuthold Group's chief investment strategist, rising interest rates do not represent a long-term threat to the stock market. Paulsen expects the 10-year yield to cross 2% by the end of the year. A spike in interest rates and its impact on the stock market depends on the economic backdrop, according to Paulsen. Rising interest rates amid a strengthening economy "may prove no challenge at all for stocks," Paulsen said.

For some time, Mr. Durov and a few dozen staffers had no fixed headquarters, but rather traveled the world, setting up shop in one city after another, he told the Journal in 2016. The company now has its operational base in Dubai, though it says it doesn’t keep servers there.Mr. Durov maintains a yearslong friendship from his VK days with actor and tech investor Jared Leto, with whom he shares an ascetic lifestyle that eschews meat and alcohol.

DevOps from tr


Telegram DevOps
FROM USA