fix(deploy): Caddy пересоздаётся только когда правка иначе не доедет (#3443) #3506

Merged

bot-backend merged 2 commits from fix/3443-caddy-selfdowntime into main 2026-09-12 16:16:04 +00:00

Conversation 0 Commits 2 Files changed 4 +639 -19

2 commits

Author	SHA1	Message	Date
bot-backend	d5f0557ca8	fix(deploy): сверка маунтов Caddy не может провалиться втихую (#3443, ревью) ... Две дыры из deep-ревью PR #3506 — обе про «отказ выглядит как успех». M1. `stale=$(docker inspect … | while …)` под `set -eu` без `pipefail` (в POSIX-sh его нет) отдаёт статус `while`, то есть всегда 0. Провал `docker inspect` или пустой вывод давали пустой список → ветка «всё доехало» → `caddy reload` → зелёная джоба с надписью «окна недоступности нет» при прокси, работающем по СТАРОМУ конфигу. Ровно тот беззвучный отказ, ради которого написан скрипт. Теперь список читается отдельной командой, провал и пустой вывод считаются расхождением (fail-safe в прежнее поведение), число сверенных файлов печатается — «сверили пять» и «сверили ноль» в логе больше не выглядят одинаково. Ноль пофайловых маунтов (например, если Caddyfile переведут на именованный том) — тоже расхождение, а не тавтологически успешная сверка. M2. В фильтре `backend` (ci.yml) не было `ops/**`, а все содержательные регрессии живут в самом ops/caddy-apply.sh: гейт его ИСПОЛНЯЕТ. PR, правящий только скрипт, давал backend=false — джоба пропускается, гейт не исполняется, «пересоздавать всегда» уезжает в main зелёным. Тот же класс, что уже осуждён комментариями рядом (#2950/#3448/#3467). Мелочи оттуда же: * `[ -d "$src" ] && continue` вместо `[ -f "$src" ] || continue` — пропуск по `-f` склеивал «это каталог» (пропустить верно) и «файла на хосте нет», для которого в контейнере как раз живёт старый инод; * сообщение об отказе `caddy validate` больше не называет причиной битый конфиг, когда упасть мог и сам запуск проверочного контейнера; * в комментарии к проверке записана её граница: в полном деплое общий `up -d $UP_SERVICES` (deploy.yml:959) поднимает и caddy за ~110 строк до вызова скрипта, поэтому правка, которая одновременно ломает Caddyfile и меняет блок caddy в compose, пересоздаст контейнер раньше проверки. Гейт дорос с 16 до 22 проверок: `docker inspect` не ответил → пересоздание, ноль пофайловых маунтов → пересоздание, исчезнувший файл на хосте → пересоздание, число сверенных маунтов печатается, `caddy reload`/вызов скрипта не проглочены `|| true`, ci.yml-фильтр покрывает ops/**. Все 11 мутантов (7 новых + 4 прежних) краснеют, контроль зелёный. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-12 20:49:34 +05:00
bot-backend	9fedaa4582	fix(deploy): Caddy пересоздаётся только когда правка иначе не доедет (#3443) ... Полный деплой ПТИЦЫ каждый раз делал `up -d --force-recreate --no-deps caddy` и сносил единственный процесс, слушающий 80/443: замер 05.09 (#3274) — 67 с `code=000` на ВСЕХ доменах хоста, включая публичный лендинг МЕРЫ. Заглушка окна деплоя здесь бессильна по построению: её отдаёт тот же Caddy. Что установлено, а не принято на веру: * Безусловный флаг появился 17.05 (11e78d73) ради нового bind-маунта `./preview` — «иначе новые volume mounts не появляются». Довод неверен: `docker compose up -d` БЕЗ `--force-recreate` пересоздаёт контейнер сам при смене описания сервиса или образа. Проверено на живом демоне (docker 28.4): добавлен volume → новый id; тег переставлен на другой образ → новый id; не менялось ничего → `Container … Running`, id тот же. * Compose не видит только одного: СОДЕРЖИМОГО пофайлового bind-маунта. `git reset --hard` пишет новый инод, контейнер держит прежний, и `caddy reload` перечитывает старый текст (тот же механизм — Alertmanager 27.08 и Alloy #3380). У Caddy так смонтированы пять путей: Caddyfile и четыре сниппета; каталоги (caddy/sites, caddy/local, preview) этим не страдают — самый частый случай, caddy/sites/apps.caddy, пересоздания НЕ требует. * Отсюда же второй, беззвучный дефект: быстрый путь `deploy-caddy` делал голый `exec caddy reload` после `git reset --hard`, то есть правка Caddyfile или сниппета до контейнера не доезжала вовсе, а джоба уходила зелёной. Оба пути деплоя теперь зовут ops/caddy-apply.sh: `caddy validate` одноразовым контейнером по файлам С ХОСТА (битый конфиг не применяется и прокси не трогает) → `up -d` без `--force-recreate` → если контейнер тот же, сверка sha256 каждого пофайлового маунта с тем, что видит контейнер → пересоздание ТОЛЬКО при расхождении, иначе `caddy reload` без разрыва соединений. Не прочиталось — считаем расхождением: fail-safe в сторону прежнего поведения. Гейт backend/tests/ops/test_3443_caddy_reload_not_recreate.py исполняет скрипт с подставным `docker` и смотрит на совершённые действия, а не на его текст: ничего не менялось → reload без пересоздания; правлен Caddyfile или любой из сниппетов → пересоздание; правка в каталоге → без пересоздания; битый конфиг → не тронуто ничего; compose пересоздал сам → второго пересоздания нет. Отдельно — проводка в deploy.yml и запрет безусловного `--force-recreate` для Caddy в полном деплое. Приёмка (#3443) снимается ПОСЛЕ мержа, на живом деплое: непрерывная проба `scripts/probe-deploy-window.sh` с хоста — максимальная серия `000` меньше 2 с против нынешних 67 с. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-12 19:38:48 +05:00