doc: инцидент 2026-09-01 — фикс proxy (302 presigned S3), DNS на ВМ

2026-09-01 17:32:07 +03:00
parent 422736f5fa
commit 33b694f5f5
1 changed files with 64 additions and 0 deletions
@@ -0,0 +1,64 @@
+# Инцидент 2026-09-01: обрыв скачивания провайдера + медленный DNS на ВМ
+
+## Симптом (исходный)
+
+- `GET /v1/proxy?key=...` отдавал `HTTP 200` + `Content-Length: 13083236`, но поток обрывался на ~18–23 KB (curl `(28) Operation timed out`).
+- `Range`-запросы игнорировались — сервер заново отдавал весь файл и зависал.
+- Гипотеза: кластерный ingress-шлюз режет исходящий streaming (по аналогии с drhider, где резались входящие тела >64 KB).
+
+## Диагностика
+
+- `s3.msk-1.ngcloud.ru` публично доступен: DNS `185.228.248.165/166/167`, `HTTP 200` (Ceph Object Gateway).
+- `gitea.services.ngcloud.ru` НЕ доступен с ВМ сборки `5.172.178.213`:
+  - публичный IP `194.31.9.41:443` — TCP таймаут;
+  - внутренний ClusterIP `10.96.52.11:443` (`gitea.mgmt.nubes.ru`) — TCP таймаут (подсеть `10.96.0.0/16` с ВМ не маршрутизируется);
+  - с локальной машины gitea доступен (`200` за 0.36s). → «в одном облаке» ≠ открыто: сети изолированы security-group/маршрутизацией.
+
+## Причина обрыва — НЕ кластер, а локальный прокси
+
+- На локальной машине задан `HTTP_PROXY/HTTPS_PROXY=http://172.17.192.1:10808` (v2ray/clash-тип).
+- Через прокси режется любой большой исходящий поток (~16–23 KB) — и старый стриминг через кластер, и прямое скачивание с S3.
+- Без прокси (`curl --noproxy '*'`) файл качается полностью: 13 083 236 байт за 6.3s, `unzip -t` — OK.
+- С ВМ (без прокси) тот же файл: 13 083 236 байт за 11.3s, `unzip -t` — OK.
+- **Вывод:** исходная гипотеза «кластерный шлюз режет» не подтвердилась.
+
+## Фикс registry: redirect на pre-signed S3 URL (выполнено)
+
+- `server/proxy.go`, `proxyHandler`: убраны `GetObject`/`Stat`/`io.Copy`; вместо этого
+  `PresignedGetObject(ctx, bucketName, key, 15*time.Minute, nil)` + `http.Redirect(w, r, ..., http.StatusFound)`.
+- Удалён неиспользуемый импорт `s3`.
+- `server/main.go`: `VERSION 0.0.2 → 0.0.3`.
+- Проверка: `go build ./...` — OK.
+- Коммит `422736f`, запушен в `master`.
+- Образ: `docker build` (локально, т.к. gitea недоступен с ВМ) → `gitea.services.ngcloud.ru/nail/tf_registry:latest` и `:0.0.3`.
+- Digest: `sha256:e3f8510d521025f4980c65226507f31aa9f4defe68e3bc50862591992792bda5`.
+- Инстанс пересоздан в UI Nubes с образом `:0.0.3`.
+
+### Проверка фикса
+
+- `GET /v1/proxy?key=...` → `HTTP 302` + `Location: https://s3.msk-1.ngcloud.ru/...?X-Amz-...` (presigned, креды reader `6DDP5...`).
+- `curl -L` — 13 083 236 байт за 6.3s (без прокси), архив валиден.
+
+## Проблема terraform init на ВМ: медленный DNS
+
+- `terraform init` на ВМ падал: `failed to retrieve authentication checksums ... context deadline exceeded` (2 попытки).
+- Причина: DNS на ВМ. `resolv.conf` = `8.8.8.8` + `1.1.1.1`, оба **недоступны** с ВМ
+  (`nslookup` → `communications error: timed out`).
+- Каждый резолв доменов Nubes висел ~10 сек: `dns=10.6s` (registry), `dns=10.0s` (s3).
+- Terraform делает много резолвов → суммарный таймаут. Сама передача файлов работала нормально.
+
+### Решение: статические записи в /etc/hosts на ВМ
+
+- Добавлено (бэкап: `/etc/hosts.bak`):
+  - `5.172.178.231 tf-registry.containerk8s.services.ngcloud.ru`
+  - `185.228.248.165 s3.msk-1.ngcloud.ru`
+- После правки резолв мгновенный: `dns=0.0003s`, registry `total=0.022s`.
+- `terraform init` в `~/tf_provider/TEST_STAND/PGwNewRegistry` — **успех**:
+  `Installed ... nubes v5.0.5 (self-signed, key ID CB3A0DF161ECC416)`, `Terraform has been successfully initialized!`.
+
+## Итоговые выводы
+
+1. Обрыв больших файлов на ~16–23 KB — локальный прокси на машине тестирования, НЕ кластер.
+2. Фикс registry (302 → presigned S3) корректен и полезен: registry больше не участвует в передаче файла.
+3. `terraform init` с ВМ ломался из-за недоступного внешнего DNS; лечится `/etc/hosts` (или рабочим внутренним DNS).
+4. Gitea с ВМ сборки недоступен по сети — для сборки образа использовать машину с доступом (локальную).