Files

vitya f3ded74674 docs(.wiki): iis-migration rollback + post-mortem + xml-escape concept

Phase 9 — rollback миграции на host-IIS из-за Docker port-loop
(host.docker.internal:80 от traefik container резолвится обратно
в сам traefik через NAT, https.yml http-catchall middleware
отдавал 301 -> TOO_MANY_REDIRECTS). Prod снова через VM.

- iis-migration-2026-05-19-postmortem: 10 ошибок миграции +
  recipe для следующей попытки (backend port НЕ :80, smoke с
  MaximumRedirection 0, тест из НЕ-LAN, parallel VM x N часов,
  atomic revert plan)
- webconfig-password-xml-escape: новая gotcha — & в conn-string
  пароле требует &amp; в Web.config (XML reserved char)
- iis-host-migration-2026-05-19: Phase 9 rollback chronology +
  что осталось на хосте inert
- snolla-recovery-vm: статус -> active prod (обратно)
- windows-recovery-host: host IIS sites -> inert artifacts
- recovery-architecture-snapshot: chain снова через VM,
  traefik backends восстановлены из .bak-phase3

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-19 15:08:07 +03:00

7.8 KiB

Raw Blame History

title, type, tags, sources, updated

title

type

Snolla Recovery VM

VirtualBox-VM на windows-recovery-host, в которой работает CMS-стек (IIS + .NET + код CMS). Импортирован из OVA-снапшота 2024-10-27, который лежал в Hyper Backup репо.

Статус (вечер 2026-05-19 после revert): VM снова active prod. Был attempt мигрировать на host-IIS в течение дня, через ~10 минут после "done"-объявления пользователь увидел 502 Bad Gateway → TOO_MANY_REDIRECTS → revert (см. iis-migration-2026-05-19-postmortem). VM поднята из savestate командой VBoxManage startvm "snolla-recovery", потребовался ipconfig /release /renew через guestcontrol для оживления network adapter (recipe из vbox-windows-stability-tuning). Traefik backends восстановлены из *.bak-phase3-2026-05-19 → trafic снова идёт через VM. Всё, что наработано на хосте для миграции, осталось inert на хосте для следующей попытки.

Параметры

VBox name: snolla-recovery
UUID: 66aac8bb-fe70-4ced-87f6-2291cd0e8b74
Расположение: C:\Users\vitya\VirtualBox VMs\snolla-recovery\
OS внутри: Windows (вероятно Server 2016/2019, hostname SNOLLA)
RAM: 4096 MB
vCPU: 2 (после оптимизации vbox-windows-stability-tuning — было 4)
Disk: snolla-disk1.vmdk, max 120 GB, реально ~92 GB на хосте
Storage controller: SATA AHCI (после миграции с SCSI LsiLogic, см. vbox-windows-stability-tuning)
Network: NAT (после миграции с bridged WiFi из-за нестабильности)
Paravirt: kvm (matching исходному гипервизору Synology VMM)
OS type: Windows10_64 (исходно был Other_64, поправили для оптимальных дефолтов)
Guest Additions: 7.2.8 r173730, RunLevel=3 (полностью активны)

NAT Port Forwards

Host port	VM port	Назначение
13389	(console)	VRDE (VBox Remote Display) — для отладки, не зависит от Windows RDP
23389	3389	RDP внутри VM (Windows Remote Desktop)
8022	22	SSH (OpenSSH Server в VM)
18080	80	IIS Default — основной HTTP CMS
18180	8080	IIS site `stostayer`
18181	8081	IIS site `stostayer.old`
18189	8089	(запасной)

Учётка

Admin: vitya (домен SNOLLA)
Default shell для sshd: PowerShell (зарегистрирован в HKLM:\SOFTWARE\OpenSSH → DefaultShell)
Authorized SSH key для admin-users: C:\ProgramData\ssh\administrators_authorized_keys (особое место для admin Windows OpenSSH; permissions через icacls, group Администраторы:F + СИСТЕМА:F)

IIS-сайты

Site	Path	Bindings	Прим.
MoreThenCms.Web	`C:\inetpub\wwwroot\MoreThenCms.Web`	`*:80`	active prod — catch-all для 11 главных доменов; traefik backend `host.docker.internal:18080`
Snolla.IdentityManager	`C:\inetpub\wwwroot\Snolla.IdentityManager`	`*:8089`	публично не используется
stostayer	`C:\stayer\MoreThenCms.Web`	`*:8080`	active prod — traefik backend `host.docker.internal:18180`; conn → внешний `89.253.219.2,1433` (но user в session 2026-05-19 поменял на `www.stostayer.ru,1433` для host-копии; в VM остался старый)
stostayer.old	`C:\stayer\stostayer.old`	`*:8081`	active prod — traefik backend `host.docker.internal:18181`
stostayer.old/calc	`C:\stayer\Mis.StoStayer.Calculator.Web`	(sub-app под `:8081`)	существует, sub-app pool `calc`
stostayer.old/price	`C:\stayer\Mis.StoStayer.Price.Api`	(sub-app под `:8081`)	существует, sub-app pool `price`
stostayer.old/price/tireService	`C:\stayer\Mis.StoStayer.TireService.Api`	(sub-app под `:8081`)	существует, sub-app pool `tireService`

CMS распознаёт клиента по Host header — все 11 клиентских доменов идут на :80 и роутятся внутри CMS-кода.

Важно для следующей попытки миграции: stostayer Web.config в VM указывает на старый 89.253.219.2,1433, а на host-копии (C:\sites\stostayer\Web.config) уже patched на www.stostayer.ru,1433 с XML-escape & в password. Если когда-то будем сводить эти конфиги — host-копия правильнее (старый сервер мёртв).

Web.config — критичные настройки (после recovery patch)

Connection string: Data Source=10.0.2.2;Initial Catalog=MoreThenCms;User Id=snolla;Password=fXkH4@8O%3pc;...
- 10.0.2.2 = NAT gateway в VBox = адрес хоста windows-recovery-host изнутри VM
- До патча было Data Source=192.168.1.10 (старая мёртвая синка)
- Тот же пароль fXkH4@8O%3pc совпадает с SA-паролем MSSQL контейнера (production password из старого compose)
Encoding файла: UTF-8 with BOM (важно — см. cms-config-rewrite-pattern)
4 файла пропатчены аналогично: MoreThenCms.Web/Web.config, Snolla.IdentityManager/Web.config, stostayer.old/web.config, и stayer-проектов (если применимо)

Связь со внешним миром

VM в NAT-режиме → не имеет LAN-IP
Из traefik (на хосте) достижима по host.docker.internal:18080 → NAT-форвард в Windows → VM:80
Раньше (когда было bridged) — VM имела IP 192.168.1.15 с MAC 02:11:32:2A:7C:B9. snolla.yml в traefik/data/custom/ исходно ссылался на http://192.168.1.15/ — пропатчен на host.docker.internal:18080/.

Стабильность

Нестабильна на bridged-WiFi → переведена в NAT (стало лучше, но всё равно требует осторожности).
Один случай (после нескольких часов uptime): network adapter в VM "повис" — все TCP-handshake проходили, но через них трафик не шёл. Лечится ipconfig /release && /renew внутри VM через VBoxManage guestcontrol.
Долгосрочно: пора планировать scheduled task внутри VM, который при детекции downtime автоматически перезагружает network adapter / iisreset. Или вообще переезд на Hyper-V — рекомендация Microsoft для Windows-гостей.

Известные баги в текущей конфигурации

X-Forwarded-Proto/Host headers не передаются с traefik в IIS → CMS делает redirect на http://www.<domain>:4443/ (mixing HTTP scheme with HTTPS port). Не критично, но требует фикса.
*Логи в C:\inetpub\logs* растут (~6 GB на момент recovery) — нужна ротация.

7.8 KiB Raw Blame History Unescape Escape