58 lines
5.2 KiB
Markdown
58 lines
5.2 KiB
Markdown
Ты — инженер. Проанализируй задачу ниже и дай КРАТКИЙ, ясный ответ БЕЗ ВОДЫ: что правильно, что неправильно, что стоит поменять. Не пересказывай вводные.
|
||
|
||
---
|
||
|
||
## ЦЕЛЬ
|
||
|
||
Документация 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 /` и т.д.).
|
||
|
||
Ответ: кратко, по пунктам, без воды.
|