3 commits

Author	SHA1	Message	Date
bot-backend	09c815930a	chore(ops): снятие зависших job-контейнеров раннера + лимит journald + мёртвый Caddy-блок ... Три независимые правки инфраструктурной гигиены прод-VPS, замеренные живьём 2026-08-15 (ssh gendesign, read-only). 1. ops/docker-prune.sh: новая секция снимает зависшие (running, но брошенные) job-контейнеры Forgejo Actions раннера — три штуки Up 4-8 недель на проде, docker container prune их не видит (фильтрует только status=exited). Фильтр по имени — якорь ^FORGEJO-ACTIONS-TASK- (regex, не substring), сервисные контейнеры (forgejo/forgejo-runner*/gendesign-*/tradein-*/couchdb) под него не подпадают + explicit-skip как страховка. Возраст — из docker inspect .State.StartedAt, порог JOB_CONTAINER_MAX_AGE_HOURS (default 24 — CI job столько никогда не идёт). DRY_RUN уже существующий флаг, переиспользован. Идемпотентно на пустом списке (mapfile + `|| true`). 2. ops/journald-gendesign.conf.example: SystemMaxUse=500M для journald. Замер: journalctl --disk-usage без прав группы systemd-journal/adm недосчитывает (показал 174M) — реальный du -sh /var/log/journal = 2.5G, ~80% всех 3.1G /var/log. journald.conf на проде сейчас без лимита вообще. Установка — руками на сервере (systemd-конфиг вне /opt/gendesign, deploy.yml его не синкает): инструкция в шапке файла. 3. Caddyfile: убран мёртвый блок status.gendsgn.ru (указывал на несуществующий uptime-kuma, дёргал ACME раз в 6 часов на staging-эндпоинте). Заодно убрана dangling forward-ссылка "описан для status.gendsgn.ru ниже" в комментарии у meraocenka.ru. grep подтвердил: других ссылок на этот хост в Caddyfile/compose/скриптах не осталось (docker-compose.uptime.yml и README упоминают — вне scope, стек сам по себе не трогается). caddy validate через prod-контейнер (stdin, без записи файлов на диск) — конфиг валиден, как и baseline до правки.	2026-08-15 22:27:48 +03:00
bot-backend	31c8ac4c5f	chore(ops): выставить +x на docker-prune.sh и restore.sh ... Оба скрипта закоммичены как 100644, хотя соседние по каталогу backup.sh и uptime-healthcheck.sh — 100755. На прод-VM файлы лежат с +x, поэтому `git status` в /opt/gendesign постоянно показывает их как modified: M ops/docker-prune.sh M ops/restore.sh (old mode 100644 / new mode 100755, контент идентичен) Функционально это ничего не ломает: cron зовёт docker-prune.sh через `bash <путь>`, restore.sh запускают руками так же. Проблема в другом — постоянный M в прод-репозитории обесценивает единственный дешёвый сигнал, по которому видно ручную правку файла на проде. Шум надо убирать, а не привыкать к нему. Приводим режим к тому, что реально на диске и что уже стоит у соседей.	2026-08-15 17:17:58 +03:00
bot-backend	ddb76a137b	chore(ops): чинить корень утечки docker-томов + еженедельная уборка ... Диск был занят на 76% (110 из 145 ГБ). Разбор: 201 том-сирота на 12.6 ГБ — 125 анонимных (каталоги данных PostgreSQL от тестовых прогонов CI) и 76 окружений задач Forgejo Actions. Прод-данных среди них нет ни одного. Корневая причина: ci.yml и ci-tradein.yml поднимают свой postgres и снимают его через `docker rm -f` БЕЗ `-v`. Контейнер уходит, анонимный том с данными остаётся сиротой — по одному на каждый прогон CI. - ci.yml / ci-tradein.yml: `docker rm -f "$CI_PG"` → `docker rm -fv` (4 места). В deploy-*.yml тот же вызов применяется к БОЕВЫМ контейнерам — туда -v добавлять нельзя, снесло бы тома с данными прода. Не тронуто. - ops/docker-prune.sh — страховка на то, что runner не убрал за собой. Удаляет: остановленные контейнеры старше 24ч, висячие образы старше 7 суток и тома-сироты ТОЛЬКО двух известных форм (64-символьный hex и FORGEJO-ACTIONS-TASK-*). Именованные тома не трогаются никогда — голый `docker volume prune` такой разницы не делает, поэтому здесь не используется. Порядок важен: контейнеры → образы → тома, иначе освободившиеся после контейнеров тома останутся до следующего запуска (на этом я и споткнулся при ручной чистке — после prune осталось ещё 78 сирот). Проверено на проде: DRY_RUN, затем боевой прогон, затем повторный — no-op. Тома 220 → 15, все используются, освобождать нечего. Диск 76% → 67%. Cron поставлен: вс 04:00 UTC (свободный слот рядом с бэкапами).	2026-08-15 16:53:25 +03:00