docs: sonnet analysis + critique; sync nginx conf with VM (301)
This commit is contained in:
“Naeel”
@@ -0,0 +1,53 @@
|
|||||||
|
# 2026-09-02 — Анализ Соннета по tf_docs + критическое мнение
|
||||||
|
|
||||||
|
## Вопрос (что отдавали Соннету)
|
||||||
|
|
||||||
|
Анализ финальной архитектуры отдачи MkDocs-документации через «вечный» бесплатный
|
||||||
|
домен `tf-docs.nodejsk8s.dev.nubes.ru`: браузер → под nodejsk8s (reverse-proxy) →
|
||||||
|
ВМ 5.172.178.213 (nginx/статика). Просили: правильна ли схема, можно ли ускорить
|
||||||
|
международный маршрут без платных доменов, скрытые риски.
|
||||||
|
|
||||||
|
## Ответ Соннета (суть)
|
||||||
|
|
||||||
|
1. Архитектура верна, но есть **конфигурационный дрейф**: в репо
|
||||||
|
`deploy-vm/nginx-ip-5.172.178.213.conf` всё ещё `location / { proxy_pass
|
||||||
|
http://127.0.0.1:8888/; }` (на остановленный llmui), хотя на ВМ уже `return 301`.
|
||||||
|
2. Обрывы ~16–36 КБ — похожи на инцидент tf_registry (там виноват локальный
|
||||||
|
прокси), но у нас Германия без прокси тоже режет + ВМ напрямую режет → маршрут
|
||||||
|
в РФ фильтруется на границе. Предложил **включить gzip**, чтобы «сжать страницу
|
||||||
|
ниже порога обрыва».
|
||||||
|
3. Риски: SPOF на ВМ, ВМ не выделенный хост, `location /` открыт по IP, timeout
|
||||||
|
30с (idle), TLS только на ingress.
|
||||||
|
|
||||||
|
## Моё критическое мнение
|
||||||
|
|
||||||
|
**Главное: рекомендация gzip — ошибочна.** Порог обрыва — СЕТЕВОЙ (~16.7 КБ), а не
|
||||||
|
«по объёму контента». Доказательство из замеров этой же сессии:
|
||||||
|
|
||||||
|
- файл `.test_20k.bin` (ровно 20000 байт) обрывается на 16775 байт;
|
||||||
|
- файлы 50/100/200 КБ — тоже ровно на 16773–16775;
|
||||||
|
- favicon 1017 байт — проходит полностью.
|
||||||
|
|
||||||
|
То есть обрыв наступает на ~16.7 КБ **независимо от content-length**. Сжать HTML
|
||||||
|
133 КБ gzip до <16.7 КБ нереально (текст жмётся до ~25–40 КБ) — ответ всё равно
|
||||||
|
упрётся в сетевой порог. gzip меняет размер контента, но не лимит маршрута. Гипотеза
|
||||||
|
«сжать ниже порога» не сработает. Вывод: для страниц 133–200 КБ gzip проблему не
|
||||||
|
решает.
|
||||||
|
|
||||||
|
**Остальные пункты** — валидные, но в основном уже известные/принятые trade-off'ы:
|
||||||
|
- дрейф 8888 в репо — подтверждён, реальный риск при повторном применении файла из
|
||||||
|
git (файл стоит синхронизировать с ВМ);
|
||||||
|
- SPOF на ВМ, timeout 30с, TLS-только-ingress — верно, но «ВМ-буфер» и есть
|
||||||
|
осознанное решение (весь код на ВМ);
|
||||||
|
- «location / открыт по IP» — натянуто: ВМ и так публична по IP, новой дыры нет.
|
||||||
|
|
||||||
|
**Итог:** анализ полезен, но ключевая рекомендация (gzip) технически неверна;
|
||||||
|
реально ценное — пункт про дрейф 8888 (нужно синхронизировать файл в репо).
|
||||||
|
|
||||||
|
## Статус
|
||||||
|
|
||||||
|
- Дрейф `deploy-vm/nginx-ip-5.172.178.213.conf` (8888) — ИСПРАВЛЕН: файл синхронизирован
|
||||||
|
с ВМ (`return 301 /nubes-test/` + `absolute_redirect off`). Файл gitignored, в git не
|
||||||
|
входит — риск «применения из git» не подтвердился, это локальная справочная копия.
|
||||||
|
- gzip — НЕ делать (не решает).
|
||||||
|
- Range-проброс в `server.js` — НЕ делать (для MkDocs-статики не критично).
|
||||||
@@ -0,0 +1,57 @@
|
|||||||
|
Ты — инженер. Проанализируй задачу ниже и дай КРАТКИЙ, ясный ответ БЕЗ ВОДЫ: что правильно, что неправильно, что стоит поменять. Не пересказывай вводные.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ЦЕЛЬ
|
||||||
|
|
||||||
|
Документация Terraform-провайдера Nubes (статический MkDocs-сайт, страницы 133–200 КБ, поисковый индекс ~1.3 МБ) должна открываться по БЕСПЛАТНОМУ «вечному» домену:
|
||||||
|
`https://tf-docs.nodejsk8s.dev.nubes.ru`
|
||||||
|
Без IP в адресной строке, без платных доменов (продление домена стоит денег — не вариант). Домен даёт облако Nubes бесплатно как managed-сервис.
|
||||||
|
|
||||||
|
## АРХИТЕКТУРА (текущая)
|
||||||
|
|
||||||
|
```
|
||||||
|
Браузер
|
||||||
|
→ tf-docs.nodejsk8s.dev.nubes.ru (managed-кластер nodejsk8s, ingress-шлюз 185.247.187.151)
|
||||||
|
→ под tf_docs (Node.js, reverse-proxy, 0.0.5)
|
||||||
|
→ ВМ 5.172.178.213 (nginx, статика из /var/www/tf-docs/)
|
||||||
|
→ MkDocs HTML
|
||||||
|
```
|
||||||
|
|
||||||
|
`tf_docs/server.js`: reverse-proxy. `/health` → 200. `/` → 301 на `/nubes-test/`. `/:stand/...` → `${VM_DOCS_BASE_URL}/:stand/...`. Форвардит content-type/content-length/cache-control/content-encoding/location. На ВМ nginx: `location /nubes-test/` отдаёт статику, `location /` = `return 301 /nubes-test/` + `absolute_redirect off`.
|
||||||
|
|
||||||
|
## ЧТО ПРОБОВАЛИ И ЧТО НЕ ПОЛУЧАЛОСЬ (хронология)
|
||||||
|
|
||||||
|
1. **Стриминг docs из S3 через под** → упиралось в ~273 Б/с (шлюз резал). Отказались.
|
||||||
|
2. **Redirect 302 с пода на ВМ** → браузер уходил на `http://5.172.178.213/...` — IP в адресе, домен терялся. Не подходит.
|
||||||
|
3. **Reverse-proxy (текущее)** → URL остаётся на домене. Принято как финальное.
|
||||||
|
4. **502 на корне `/`** → баг на ВМ: `location /` проксировал на `127.0.0.1:8888` (Docker `llmui`, остановлен по соображениям безопасности). Починено: `return 301 /nubes-test/`.
|
||||||
|
5. **301 терял заголовок `Location`** → в прокси не был в списке форвардящихся заголовков. Добавили `location`. Плюс `absolute_redirect off` на ВМ, чтобы Location был относительным (`/nubes-test/`), а не `http://5.172.178.213/...`.
|
||||||
|
|
||||||
|
## ГЛАВНАЯ ПРОБЛЕМА — СКОРОСТЬ/ОБРЫВЫ (диагностировано)
|
||||||
|
|
||||||
|
Симптом: большие ответы «замирали» ровно на ~16–20 КБ.
|
||||||
|
|
||||||
|
Замеры:
|
||||||
|
- ВМ напрямую из РФ: **5 МБ/с** (133 КБ за 0.026 с).
|
||||||
|
- Домен из РФ без прокси: **133 КБ за ~5 с, 1.3 МБ за ~5 с** — работает полностью.
|
||||||
|
- Домен через локальный v2ray-прокси (`HTTPS_PROXY=172.17.192.1:10808`): **стоп на 16788 байт**.
|
||||||
|
- Сервер в Германии (Vultr 95.179.252.111), чистый, без прокси:
|
||||||
|
- шлюз `185.247.187.151`: стоп на 16788 байт;
|
||||||
|
- ВМ `5.172.178.213` напрямую: стоп на 35912 байт (~1 КБ/с);
|
||||||
|
- контроль (google.com, не-РФ): 83 КБ за 0.48 с — канал Германии хороший.
|
||||||
|
- iotdash22.nodejsk8s.dev.nubes.ru (другой шлюз 91.214.116.216) отдаёт 17.7 КБ полностью.
|
||||||
|
|
||||||
|
Вывод, к которому пришли: режется **международный маршрут → российские IP**, а не наша архитектура. Из РФ напрямую всё быстро.
|
||||||
|
|
||||||
|
## ТЕКУЩЕЕ СОСТОЯНИЕ
|
||||||
|
|
||||||
|
Всё работает из РФ напрямую (браузер открывает страницы быстро, это подтверждено пользователем). Проверено в браузере: `/` → 301 → `/nubes-test/` (домен сохраняется), getting-started-страница (197 КБ) грузится полностью. ВМ отдаёт поду все байты (access log nginx: 133525, 200000 и т.д.).
|
||||||
|
|
||||||
|
## ЧТО ОТ ТЕБЯ НУЖНО
|
||||||
|
|
||||||
|
1. Правильна ли текущая архитектура для поставленной цели (бесплатный вечный домен + быстрая отдача из РФ)? Есть ли фундаментальные изъяны?
|
||||||
|
2. Есть ли способ ускорить/сделать надёжнее отдачу для трафика, который идёт через зарубежный маршрут (прокси/Германия), не вводя платных доменов? (или это физически нерешаемо на этом хостинге)
|
||||||
|
3. Скрытые риски/узкие места текущего решения (single point of failure на ВМ, TLS, кэш, безопасность `location /` и т.д.).
|
||||||
|
|
||||||
|
Ответ: кратко, по пунктам, без воды.
|
||||||
Reference in New Issue
Block a user