Проект агента (~tgclaude/imgbot) работал тремя голыми python-процессами,
запущенными руками из SSH-сессии: без юнита, без restart-политики, при
Linger=no. Держались только на KillUserProcesses=no и не пережили бы
перезагрузку, причём молча.
Один образ на базе playwright/python:v1.62.0-noble (версия пакета
playwright обязана совпадать с тегом, иначе разъезжается ревизия
chromium), два сервиса:
- imgbot-daemon — APScheduler: refresh 30 мин, analyze 5 мин
- imgbot-http — объединил прежние mcp-http (8765) и file-server
(8766): MCP как под-приложение Starlette плюс маршрут /photo/<id>
Неочевидное, из-за чего это ломается молча (в compose есть комментарии):
- данные монтируются в тот же путь, что на хосте: images.file_path в
SQLite абсолютный, и его читают обе стороны
- корней хранения может быть больше одного — проверять все префиксы
file_path, а не только data_dir
- HOME обязателен: collector.py вызывает Path.home(), а uid 1001 не
имеет записи в /etc/passwd образа
- у MCP своя защита от DNS-rebinding: без IMGBOT_ALLOWED_HOSTS отдаёт
421 на любой Host кроме localhost
Порт не публикуется на хост, сервис доступен из общей docker-сети с
claude-channels — агент наконец ходит по MCP, а не по SSH.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ipcam/FTPS-приёмник удалён с fr1 целиком: контейнер, образ, том, сеть,
каталоги /srv/ipcam и /srv/ftps, deploy-хук certbot и сертификат
cam.ruzzy.dev. Видео так и не начали складываться — на момент удаления
в /srv/ipcam было 0 файлов.
Пин образа Gitea в стеке держал 1.25.4, тогда как работает 1.27.3
(обновлён 2026-08-31). Любой `docker compose up -d` откатил бы сервис
на две минорные версии назад.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
housekeeping 30s, docker_only, отключены дорогие метрики,
init:true для reaping healthcheck-wget. На fr1 дало 231%→14% CPU.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
