After NAS incident 2026-05-18 — план вынести инфраструктурные сервисы (gitea/verdaccio/seafile/registry/hermes) с kreknin Synology на облачный VDS Rusonyx 160 SSD (2500 ₽/мес, 6 vCPU / 8GB RAM / 160GB SSD). Размеры с kreknin /volume1/docker/*: gitea 2.6G, verdaccio 8.5G (prune до ~3G), owncloud → replace with seafile ~30-40G, registry 99G (GC до ~5-15G), hermes 10G (Nous Research agent self-host, LLM external). Tier-decision history записана в Decisions log: 160 → 80+addon → 160 final (user choice: operational simplicity over 6k₽/год экономии). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
6.3 KiB
Task Board
Updated: 2026-05-19
⚪ [vds-kzntsv-bootstrap] — поднять облачный VDS под gitea/verdaccio/seafile/registry/hermes
Status: ready (планирование 2026-05-19; tier финализирован user'ом — 160 SSD Rusonyx, 2500 ₽/мес, 6 vCPU / 8GB RAM / 160GB SSD)
Where I stopped: размеры сняты с kreknin, hermes-профиль уточнён, tier выбран 160 SSD. Detailed план в vds-kzntsv-bootstrap.md.
Open questions: owncloud дубль (docker/owncloud/ vs docker/personal/owncloud/) — какой live для миграции данных в seafile; DNS-cut стратегия; OS на VDS (Ubuntu 24.04 LTS recommended).
Next action: (1) registry GC + verdaccio prune на kreknin до миграции (write-op на kreknin, требует согласия user'а); (2) закупить 160 SSD у Rusonyx + получить IP; (3) DNS A-запись vds.kzntsv.site в REGRU.
Branch: master
🔴 [iis-on-host-migration] — attempt 2: 11 cms LIVE на host IIS:8089, 24h soak в процессе
Status: active (2026-05-19 вечер — 11 main cms routes мигрированы, smoke clean, 2 phone-tests passed; 2 stayer routes ещё на VM до отдельного решения; VM running parallel — НЕ savestate'ить).
Done: bak-серия .bak-pre-attempt2-2026-05-19 для 13 yml; IIS binding snolla *:8089 + Stop/Start Website; loop-detect через host.docker.internal:8089 ≠ NAT loop (resolves to 192.168.65.254 host gateway) ✅; 11 cms yml (snolla, rimiz, labtools, labtoolspro, pilorama98, tandemmebel, emspb, kupimknigi, maljarka, sestech, isc-artmaterials) patched :18080 → :8089; host-side smoke 20 hostnames → все Server: Microsoft-IIS/10.0 ✅; 📱 phone-tests (mobile internet): emspb.ru ✅, labtools.ru ✅; traefik logs clean (only known docker.sock noise); pre-existing CMS issues подтверждены и НЕ regression: rimiz.ru/ics-artmaterials.com 404 (CMS-routing); snolla.com 301 → on.snolla.com (canonical default subdomain), on/pilorama98/labtools/emspb.snolla.com 200 OK.
Done (stayer): stayer routes user'ом подтверждены «внутренние, наружу не светим» → stostayer.yml → stostayer.yml.disabled, oldstostayer.yml → oldstostayer.yml.disabled; docker restart traefik; verify: stostayer.snolla.com/old.stostayer.ru → 404 traefik no-route ✅; host IIS sites stostayer :8090/stostayer.old :8091 остаются live для прямого/локального доступа (CMS отвечает контент, headers stripped через WinHTTP proxy на curl, но изнутри traefik / production-path headers Microsoft-IIS/ASP.NET корректные).
My mistake to log: я некорректно интерпретировал «мигрировать» как «patch traefik backend stayer:18180 → :8090» (т.е. пускать через traefik наружу). User имел в виду «host IIS уже есть, traefik routes должны быть DISABLED». Сделал patch backend → user интервент-stop → revert + rename .disabled. Lesson — re-confirm semantics при low-traffic / internal services; не предполагать что «мигрировать» == «через traefik наружу».
Where I stopped: 14 cms hosts через host IIS:8089, stayer routes наружу выключены. Soak в процессе.
Next action: (a) phone-test 2-3 random cms domains; (b) wait 24h+ uptime; (c) docs: post-success wiki ingest + update recovery-architecture-snapshot.md (stayer = disabled, не migrated); (d) только после 24h+ + zero rollbacks → consider savestate VM.
Atomic full revert (paste-ready): Get-ChildItem C:\Users\vitya\projects\docker\diskstation\traefik\data\custom\*.yml.bak-pre-attempt2-2026-05-19 | %{ Copy-Item $_.FullName -Destination ($_.FullName -replace '\.bak-pre-attempt2-2026-05-19$','') -Force }; Move-Item C:\Users\vitya\projects\docker\diskstation\traefik\data\custom\stostayer.yml.disabled C:\Users\vitya\projects\docker\diskstation\traefik\data\custom\stostayer.yml -Force -EA SilentlyContinue; Move-Item C:\Users\vitya\projects\docker\diskstation\traefik\data\custom\oldstostayer.yml.disabled C:\Users\vitya\projects\docker\diskstation\traefik\data\custom\oldstostayer.yml -Force -EA SilentlyContinue; docker restart traefik
Branch: master
🟢 [nas-recovery] — клиентские сайты восстановлены, работают из публичного интернета
Status: done (2026-05-19 ~10:00 MSK — 15 часов работы) Final state: OpenWRT NAT → traefik 2.6.6 (host:8000/4443) → VirtualBox VM snolla-recovery (IIS + CMS) + docker-стек на хосте (MSSQL/MinIO/ES/imgproxy/nginx). 13 client routes, 40 LE certs валидны. Проверено: пользовательский клиент из публичного интернета открывает snolla.com, pilorama98.ru, labtools.ru/pro, tandemmebel.ru, emspb.ru. Backup pull: C:\nas-recovery\vm-sites\ (~11 GB inetpub/wwwroot + stayer/) — на случай если VM снова станет нестабильной. Open issues (минор):
- X-Forwarded-Proto/Host: CMS делает redirect с портом 4443 в URL — нужно добавить middleware в traefik или включить trust в IIS.
- MinIO/Azure storage — пользователь упомянул "не так всё", ждём пояснение.
- docker-сокет проброс в traefik — daemon connection error (некритично, file-provider routing работает).
- VM в bridged-WiFi была нестабильной → переехали на NAT + port forwards.
- acme.json renewal через HTTP-01 фейлится для доменов с DNS не на нашем IP — нужно переключить на DNS-01 через REGRU (creds в env уже). Branch: master