lekss361/gendesign

Fork 0

Полный деплой ПТИЦЫ роняет сам Caddy на 67 секунд — все домены отдают code=000, заглушка окна деплоя здесь бессильна по построению #3443

New issue

Closed

opened 2026-09-11 19:55:47 +00:00 by bot-backend · 1 comment

bot-backend commented

2026-09-11 19:55:47 +00:00

Collaborator

Выделено из #3274 после разбора (11.09).

Факт. Полный деплой ПТИЦЫ каждый раз пересоздаёт сам Caddy: .forgejo/workflows/deploy.yml:1005 — docker compose … up -d --force-recreate --no-deps caddy. Замер от 05.09, приведённый в #3274: 67 с code=000 на ВСЕХ доменах (не 502/503, а отсутствие ответа — принимающего процесса нет).

Почему это отдельная задача. Это тот же класс дефекта, что и #3274 («контейнер снесён раньше, чем поднят новый»), но:

цена выше: падают все домены разом — gendsgn.ru, meraocenka.ru и зеркала, публичный лендинг МЕРЫ в том числе;
лечится иначе: заглушка окна деплоя (caddy/sites/deploy-window.caddy.snippet) здесь бессильна по построению — её отдаёт сам Caddy, которого в этот момент нет;
не лечится и правкой #3274 (та про подмену фронта за обратным прокси).

Куда копать. caddy reload (уже используется на пути deploy-caddy в том же воркфлоу и не рвёт соединения) против force-recreate: понять, что именно требует пересоздания контейнера — изменение docker-compose*.yml, монтирования снипетов (см. single-file-bind-mount-inode: bind-mount одного файла держит инод, up -d его не перечитывает), или переменных окружения. Если пересоздание нужно только при смене compose/монтирований, то в остальных случаях достаточно reload; если нужно всегда — рассмотреть второй экземпляр Caddy с передачей сокета или systemd-socket activation.

Приёмка: непрерывная проба с хоста во время полного деплоя ПТИЦЫ (scripts/probe-deploy-window.sh из #3274, считает 000 отдельно) — максимальная серия 000 меньше 2 с против нынешних 67 с.

Refs #3274, #3231, #654.

Выделено из #3274 после разбора (11.09). **Факт.** Полный деплой ПТИЦЫ каждый раз пересоздаёт сам Caddy: `.forgejo/workflows/deploy.yml:1005` — `docker compose … up -d --force-recreate --no-deps caddy`. Замер от 05.09, приведённый в #3274: **67 с `code=000` на ВСЕХ доменах** (не 502/503, а отсутствие ответа — принимающего процесса нет). **Почему это отдельная задача.** Это тот же класс дефекта, что и #3274 («контейнер снесён раньше, чем поднят новый»), но: - цена выше: падают все домены разом — `gendsgn.ru`, `meraocenka.ru` и зеркала, публичный лендинг МЕРЫ в том числе; - лечится иначе: заглушка окна деплоя (`caddy/sites/deploy-window.caddy.snippet`) здесь бессильна по построению — её отдаёт сам Caddy, которого в этот момент нет; - не лечится и правкой #3274 (та про подмену фронта за обратным прокси). **Куда копать.** `caddy reload` (уже используется на пути `deploy-caddy` в том же воркфлоу и не рвёт соединения) против `force-recreate`: понять, что именно требует пересоздания контейнера — изменение `docker-compose*.yml`, монтирования снипетов (см. `single-file-bind-mount-inode`: bind-mount одного файла держит инод, `up -d` его не перечитывает), или переменных окружения. Если пересоздание нужно только при смене compose/монтирований, то в остальных случаях достаточно reload; если нужно всегда — рассмотреть второй экземпляр Caddy с передачей сокета или `systemd`-socket activation. **Приёмка:** непрерывная проба с хоста во время полного деплоя ПТИЦЫ (`scripts/probe-deploy-window.sh` из #3274, считает `000` отдельно) — максимальная серия `000` меньше 2 с против нынешних 67 с. Refs #3274, #3231, #654.

bot-backend referenced this issue

2026-09-11 20:25:59 +00:00

Публичный лендинг лежит 30–90 секунд при КАЖДОМ деплое: подмена контейнера всплывает как 502 #3274

bot-backend referenced this issue

2026-09-11 20:47:42 +00:00

Быстрый путь caddy_only не исполняется: мерж с единственным caddy-файлом пересоздал весь стек ПТИЦЫ, а пропущенная джоба показана как success #3448

Light1YT referenced this issue from a commit

2026-09-12 14:39:59 +00:00

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

bot-backend referenced this issue from a pull request that will close it,

2026-09-12 14:41:11 +00:00

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

Light1YT referenced this issue from a commit

2026-09-12 15:49:45 +00:00

fix(deploy): сверка маунтов Caddy не может провалиться втихую (#3443, ревью)

bot-backend referenced this issue from a commit

2026-09-12 16:16:04 +00:00

Merge pull request 'fix(deploy): Caddy пересоздаётся только когда правка иначе не доедет (#3443)' (#3506) from fix/3443-caddy-selfdowntime into main

bot-backend closed this issue

2026-09-12 16:16:04 +00:00

bot-backend commented

2026-09-12 16:21:54 +00:00

Author

Collaborator

Приёмка на живом деплое — 2026-09-12, 16:15–16:20 UTC

PR #3506 смержен (68495907), проба запущена до мержа и накрыла окно целиком. Запускал с самого хоста, как предписывает шапка scripts/probe-deploy-window.sh: снаружи периметр отбивает частые серии и это читается как простой.

Результат по meraocenka.ru

образцов: 1348, шаг ~0.24 с
  200: 1348
максимальная серия не-200: 0 образцов ≈ 0.0 с

Было 67 с code=000 (замер 05.09 из #3274) → стало 0,0 с. Критерий приёмки («серия меньше 2 с») выполнен.

Чем именно это достигнуто — проверено, а не предположено

docker inspect gendesign-caddy-1 → Created = 2026-09-12T14:11:19Z

То есть этот деплой контейнер не пересоздавал (14:11 — предыдущий деплой, окно правки было 16:15–16:20). А в логе самого Caddy видно, что вместо холодного старта прошла перезагрузка:

POST /load  Caddy-Config-Source-File: /etc/caddy/Caddyfile
"config is unchanged"
"load complete"

Ни одного serving initial configuration — то есть процесс не перезапускался. Скрипт доехал (/opt/gendesign/ops/caddy-apply.sh) и выбрал ветку reload, потому что sha256 всех пяти пофайловых маунтов совпали с тем, что видит контейнер.

Чего этот замер НЕ доказывает

Ветка пересоздания не проверена. Сегодняшний деплой не менял ни одного пофайлового маунта, поэтому сработал только быстрый путь. Сколько длится окно, когда пересоздание действительно нужно (правка Caddyfile или сниппета), замерить можно будет только на таком деплое. Ожидание — прежние ~67 с, и это осознанный размен: теперь такое окно платится только там, где иначе правка не доедет вовсе.
Второй домен замерен неверно, число выбрасываю. Я поставил пробу на https://gendsgn.ru/ и получил «максимальная серия не-200: 633 образца ≈ 145,7 с». Это не простой: корень gendsgn.ru закрыт basic_auth и штатно отдаёт 401 всегда, в том числе до и после деплоя. Проба считала не-200 и сложила в «серию» весь свой прогон. Правильный публично-200 адрес для ПТИЦЫ — /trade-in/login (проверил: 200). Для следующего замера брать его, а корень не брать.

Файлы проб с прода убраны, процессы остановлены.

Остаётся по теме

Ветка reload теперь работает и на быстром пути deploy-caddy — до #3506 он делал git reset --hard и голый caddy reload, и правка Caddyfile/сниппета из-за пиннинга инода не доезжала вовсе при зелёной джобе. Дыра открылась сегодня в 11:43Z вместе с мержем #3465 и ни разу не сработала: caddy-only мержей после неё не было. Закрыта тем же скриптом.

## Приёмка на живом деплое — 2026-09-12, 16:15–16:20 UTC PR #3506 смержен (`68495907`), проба запущена **до** мержа и накрыла окно целиком. Запускал с самого хоста, как предписывает шапка `scripts/probe-deploy-window.sh`: снаружи периметр отбивает частые серии и это читается как простой. ### Результат по meraocenka.ru ``` образцов: 1348, шаг ~0.24 с 200: 1348 максимальная серия не-200: 0 образцов ≈ 0.0 с ``` **Было 67 с `code=000` (замер 05.09 из #3274) → стало 0,0 с.** Критерий приёмки («серия меньше 2 с») выполнен. ### Чем именно это достигнуто — проверено, а не предположено ``` docker inspect gendesign-caddy-1 → Created = 2026-09-12T14:11:19Z ``` То есть **этот деплой контейнер не пересоздавал** (14:11 — предыдущий деплой, окно правки было 16:15–16:20). А в логе самого Caddy видно, что вместо холодного старта прошла перезагрузка: ``` POST /load Caddy-Config-Source-File: /etc/caddy/Caddyfile "config is unchanged" "load complete" ``` Ни одного `serving initial configuration` — то есть процесс не перезапускался. Скрипт доехал (`/opt/gendesign/ops/caddy-apply.sh`) и выбрал ветку reload, потому что sha256 всех пяти пофайловых маунтов совпали с тем, что видит контейнер. ### Чего этот замер НЕ доказывает 1. **Ветка пересоздания не проверена.** Сегодняшний деплой не менял ни одного пофайлового маунта, поэтому сработал только быстрый путь. Сколько длится окно, когда пересоздание действительно нужно (правка `Caddyfile` или сниппета), замерить можно будет только на таком деплое. Ожидание — прежние ~67 с, и это осознанный размен: теперь такое окно платится только там, где иначе правка не доедет вовсе. 2. **Второй домен замерен неверно, число выбрасываю.** Я поставил пробу на `https://gendsgn.ru/` и получил «максимальная серия не-200: 633 образца ≈ 145,7 с». Это **не простой**: корень `gendsgn.ru` закрыт `basic_auth` и штатно отдаёт 401 всегда, в том числе до и после деплоя. Проба считала не-200 и сложила в «серию» весь свой прогон. Правильный публично-200 адрес для ПТИЦЫ — `/trade-in/login` (проверил: 200). Для следующего замера брать его, а корень не брать. Файлы проб с прода убраны, процессы остановлены. ### Остаётся по теме Ветка reload теперь работает и на быстром пути `deploy-caddy` — до #3506 он делал `git reset --hard` и голый `caddy reload`, и правка `Caddyfile`/сниппета из-за пиннинга инода не доезжала вовсе при зелёной джобе. Дыра открылась сегодня в 11:43Z вместе с мержем #3465 и ни разу не сработала: caddy-only мержей после неё не было. Закрыта тем же скриптом.