🐳 ctop — этот инструмент предлагает наглядный мониторинг контейнеров прямо в терминале.

Ctop выводит метрики CPU, памяти и сети в реальном времени, подсвечивая проблемные контейнеры — например, те, что съели всю оперативку.

Интересно, что можно не только смотреть статистику, но и управлять контейнерами: останавливать, перезапускать или заходить внутрь через exec — всё через интуитивное TUI.

Под капотом — поддержка Docker и runC, а в планах добавление Kubernetes.

Установка занимает одну команду (есть варианты для Linux, macOS и даже Windows через scoop). Для тех, кто не хочет ничего ставить, есть Docker-образ — запускается за секунды.

🔗 GitHub

@DevopsDocker

🎮 Agones — Kubernetes для игровых серверов. Инструмент решает проблему масштабирования тысячи инстансов для многопользовательских игр , превращая Kubernetes в специализированную платформу для управления игровыми серверами.

Проект предлагает не просто деплой через YAML-манифесты, а полноценный жизненный цикл: от health-check до автоматического масштабирования флота серверов под нагрузку. Интеграция с Kubernetes API позволяет matchmaker-системам напрямую запрашивать новые игровые сессии — без кастомных решений.

🤖 GitHub

@devopsitsec

⚡️Легкий способ получать свежие обновления и следить за трендами в разработке на вашем языке. Находите свой стек и подписывайтесь:

Python: www.tgoop.com/pythonl
Linux: www.tgoop.com/linuxacademiya
Собеседования DS: www.tgoop.com/machinelearning_interview
Нерйросети www.tgoop.com/ai_machinelearning_big_data
C++ www.tgoop.com/cpluspluc
Docker: www.tgoop.com/DevopsDocker
Хакинг: www.tgoop.com/linuxkalii
Devops: www.tgoop.com/DevOPSitsec
Data Science: www.tgoop.com/data_analysis_ml
Javascript: www.tgoop.com/javascriptv
C#: www.tgoop.com/csharp_ci
Java: www.tgoop.com/javatg
Базы данных: www.tgoop.com/sqlhub
Python собеседования: www.tgoop.com/python_job_interview
Мобильная разработка: www.tgoop.com/mobdevelop
Golang: www.tgoop.com/Golang_google
React: www.tgoop.com/react_tg
Rust: www.tgoop.com/rust_code
ИИ: www.tgoop.com/vistehno
PHP: www.tgoop.com/phpshka
Android: www.tgoop.com/android_its
Frontend: www.tgoop.com/front
Big Data: www.tgoop.com/bigdatai
МАТЕМАТИКА: www.tgoop.com/data_math
Kubernets: www.tgoop.com/kubernetc
Разработка игр: https://www.tgoop.com/gamedev
Haskell: www.tgoop.com/haskell_tg
Физика: www.tgoop.com/fizmat

💼 Папка с вакансиями: www.tgoop.com/addlist/_zyy_jQ_QUsyM2Vi
Папка Go разработчика: www.tgoop.com/addlist/MUtJEeJSxeY2YTFi
Папка Python разработчика: www.tgoop.com/addlist/eEPya-HF6mkxMGIy
Папка ML: https://www.tgoop.com/addlist/2Ls-snqEeytkMDgy
Папка FRONTEND: https://www.tgoop.com/addlist/mzMMG3RPZhY2M2Iy

😆ИТ-Мемы: www.tgoop.com/memes_prog
🇬🇧Английский: www.tgoop.com/english_forprogrammers
🧠ИИ: www.tgoop.com/vistehno

🎓954ГБ ОПЕНСОРС КУРСОВ: @courses
📕Ит-книги бесплатно: https://www.tgoop.com/addlist/BkskQciUW_FhNjEy

🚨 Задача: «Исчезающий файл 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