docs(history): раскладка HISTORY по тематическим папкам (75 файлов)

Было: 41 файл в корне HISTORY/ + авторские папки OPUS/ и SONNET/ (34 файла).
Стало — тематическая нумерация в стиле NOTES/ (10_, 20_, …):

  10_reviews/    ревью кода и разборы от LLM (2)
  20_releases/   заливки версий в реестр, чистки реестра, нумерация версий (8)
  30_provider/   ядро провайдера: архитектура, модификаторы, UUID, nested (6)
  40_generator/  генератор YAML/спеки, формат MAN (3)
  50_docs/       пайплайн документации, навигация, публикация, хостинг S3 (9)
  60_stands/     стенды и примеры: CRUD, FullPipe, Штурвал, TEST_STAND (7)
  70_infra/      реестр, API Gateway, DDoS-Guard, VPN/213, зеркала (4)
  90_llm/        диалоги и промпты с LLM вне тематики: OPUS/, SONNET/, gemini/ (34)

OPUS/ и SONNET/ перенесены как есть в 90_llm/ — чтобы не рвать пары
«бриф → ответ» внутри диалогов. Все переносы — через git mv (история сохранена).
Перед правкой: TMP/backup_2026-10-02/HISTORY_before_restructure.tar.gz.
Перекрёстные ссылки обновляются следующим коммитом.
This commit is contained in:
Repinoid
2026-10-02 07:35:32 +03:00
parent 9cc7b3f260
commit 2c196e8cc8
75 changed files with 0 additions and 0 deletions
@@ -0,0 +1,14 @@
# Registry Getting Started URL Fix — 2026-08-31
## Проблема
В примере `required_providers` на странице `30_registry/guides/getting-started` значение `source` содержало старый адрес `registry.kube5s.ru` и вложенные HTML-комментарии `LEGACY`. Из-за этого пример Terraform был синтаксически и семантически неверным.
В этом же файле старый адрес с HTML-комментарием присутствовал в ссылке на пример Postgres.
## Решение
- `source` заменён на `tf-registry.containerk8s.services.ngcloud.ru/nubes/nubes`.
- Ссылка на пример Postgres переведена на `tf-registry.containerk8s.services.ngcloud.ru`.
- Все вставки `LEGACY` и упоминания `registry.kube5s.ru` удалены из страницы.
- Версии профилей повышены: DEV `3.0.7`, TEST `5.0.6`, PROD `2.0.7`.
@@ -0,0 +1,29 @@
# Анализ полного pipeline документации и публикации
Дата: 2026-09-02
Проверен полный маршрут `tf_provider`:
```text
Nubes API
-> TOOLS/scripts/01_generate_yamls.sh
-> generated/<stand>/resources_yaml/*.yaml
-> TOOLS/scripts/02_generate_resources_and_docs_v2.sh
-> generated/<stand>/go/*.go
-> generated/<stand>/docs/*.md + _nav_fragment.yml
-> TOOLS/scripts/05_generate_docs_llm.py (опционально)
-> TOOLS/scripts/04_build_and_publish_docs.sh
-> .mkdocs.tmp.yml
-> site/
-> S3 terraform-registry/docs/<namespace>/<name>/<version>/
```
Параллельно релиз провайдера идёт через `03_build_and_upload_provider.sh` и `build-provider.sh`: временная копия provider собирается под linux/windows/darwin, подписывается GPG и загружается в `nubes-terraform-registry/<host>/<namespace>/<name>/<version>/`.
Ключевые реализации: `TOOLS/yaml-generator/main.go`, `TOOLS/resource-generator/main.go`, `TOOLS/docs-generator/main.go`, их `internal/**`, `mkdocs.yml`, профильные конфиги `TOOLS/config/<stand>/*`, `.github/workflows/publish-docs.yml` и серверные файлы `/home/naeel/TF/tf_registry/server/{main.go,handlers.go,router_versions.go,proxy.go}`.
Обнаружен фактический разрыв: `TOOLS/scripts/04_build_and_publish_docs.sh` и CI вызывают `./scripts/publish-docs.sh`, но такого файла в `tf_provider/scripts/` нет. Справочная рабочая копия находится в `DOCS_PIPELINE/publish-docs.sh`. Поэтому генерация `site/` возможна, а штатная финальная загрузка из текущего репозитория завершается ошибкой отсутствующего файла.
Подробный пользовательский отчёт сохранён в:
`/home/naeel/TF/TMP/tf_provider_full_docs_pipeline_2026-09-02.md`
@@ -0,0 +1,17 @@
# Fix cross-stand links publication
## Cause
The source change was present in `TOOLS/docs-generator/internal/writers/writers.go`, but `TOOLS/bin/docs-generator` was an older compiled binary. TEST generation therefore continued to produce an index without the links. The build validator also incorrectly treated intentional links to other documentation roots as contamination.
## Fix and verification
- Rebuilt `TOOLS/bin/docs-generator` from the current Go source.
- Updated the validator to allow links to the DEV, TEST, and PROD documentation roots while still rejecting foreign API, dashboard, and provider values.
- Regenerated and built DEV, TEST, and PROD sequentially.
- Published one `index.html` to each active VM mirror and verified the `Другие стенды` block remotely:
- `/var/www/tf-docs/nubes-dev/index.html`
- `/var/www/tf-docs/nubes-test/index.html`
- `/var/www/tf-docs/nubes/index.html`
The S3 mirror still reports `unexpected EOF`; direct VM transfer was used for the verified publication.
@@ -0,0 +1,15 @@
# Cross-stand links on documentation index pages
## Change
The generated resource index now includes a short "Other environments" section with links to the DEV, TEST, and PROD documentation home pages. The links are added in `TOOLS/docs-generator/internal/writers/writers.go`, the actual source of `generated/<stand>/docs/index.md`.
## Publication
All three profiles were regenerated and built sequentially. Only the resulting `index.html` was transferred to the corresponding active VM mirror:
- `/var/www/tf-docs/nubes-dev/index.html`
- `/var/www/tf-docs/nubes-test/index.html`
- `/var/www/tf-docs/nubes/index.html`
Each remote file was checked for the three cross-stand links. The regular S3 mirror continued to report `unexpected EOF`, so direct VM transfer was used again.
@@ -0,0 +1,11 @@
# Current stand in documentation index
The generated resource index now shows the current environment explicitly:
- `Текущий стенд: DEV`
- `Текущий стенд: TEST`
- `Текущий стенд: PROD`
Each index lists only the two other environments with short usage comments. The namespace is passed explicitly to `docs-generator`, so the label is generated from the selected profile rather than inferred in the HTML build.
DEV, TEST, and PROD were regenerated and their individual `index.html` files were published and verified on the VM. The S3 mirror still reports `unexpected EOF`; direct VM transfer was used.
@@ -0,0 +1,67 @@
# 2026-09-03 — Устранение хардкодов документации и публикация DEV
## Найденная причина
Общие материалы `docs/30_registry/` и `docs/curated/` копировались в каждый `generated/<stand>/docs/`, но подстановка выполнялась только для части `getting-started.md`. Поэтому в DEV попадали TEST-значения:
- TEST provider source;
- `5.0.5`;
- TEST API endpoint;
- `deck-test.ngcloud.ru`.
Дополнительно `02_generate_resources_and_docs_v2.sh` не очищал старые generated-файлы. Ресурс, отсутствующий в текущем `services_list.txt`, мог остаться от предыдущей генерации.
## Изменения
- Общие документы используют placeholders:
- `{{NAMESPACE}}`;
- `{{VERSION}}`;
- `{{PROVIDER_SOURCE}}`;
- `{{NUBES_API_ENDPOINT}}`;
- `{{DASHBOARD_URL}}`.
- `04_build_and_publish_docs.sh` подставляет значения рекурсивно во все скопированные Markdown-файлы.
- Добавлена проверка чужих namespace, API/dashboard host и старого `registry.kube5s.ru` до сборки.
- Профиль стал обязательным; обязательные значения не берутся из PROD fallback.
- `02_generate_resources_and_docs_v2.sh` очищает только собственный `generated/<stand>/docs` перед генерацией.
- `docs-generator` больше не содержит DEV default для API/provider source.
- Базовый `mkdocs.yml` больше не содержит versioned URL.
## Проверки
- `bash -n` для обоих docs scripts — PASS.
- `go test ./...` и `go build ./...` в `TOOLS/docs-generator` — PASS.
- DEV regeneration — PASS.
- DEV MkDocs build — PASS; contamination check — PASS.
- В DEV отсутствуют `5.0.5`, TEST API, `deck-test.ngcloud.ru` и `registry.kube5s.ru`.
- Legacy generated `vc_vm_v2` удалён чистой генерацией, так как отсутствует в актуальном `services_list.txt`.
## Публикация
Локальный рекурсивный S3 mirror завершался `unexpected EOF`, поэтому exit code штатного скрипта нельзя считать достаточным подтверждением загрузки. Проверенный артефакт `site/` был передан на ВМ `5.172.178.213` по SSH и атомарно установлен в:
```text
/var/www/tf-docs/nubes-dev/
```
На ВМ проверены страницы getting-started и curated PostgreSQL:
- namespace `nubes-dev`;
- provider version `2.0.0`;
- DEV API endpoint;
- DEV dashboard URL;
- отсутствие TEST-значений.
Legacy versioned каталоги TEST ранее удалены и после публикации отсутствуют:
```text
/var/www/tf-docs/nubes-test/5.0.5
/var/www/tf-docs/nubes-test/5.0.57
```
Публичный путь документации:
```text
https://tf-docs.nodejsk8s.dev.nubes.ru/nubes-dev/
```
Публичный `curl` завершался timeout на большом HTML; содержимое активного зеркала ВМ проверено напрямую.
@@ -0,0 +1,170 @@
# 2026-09-03 — Проверенный pipeline публикации документации
## Цель
Зафиксировать фактический pipeline публикации заново сгенерированной документации провайдера, чтобы не восстанавливать его заново по догадкам.
## Источник документации
Для стенда `<stand>` используются только сгенерированные страницы:
```text
generated/<stand>/docs/
```
Ручной каталог `docs/` не используется как основной `docs_dir`. Скрипт `04_build_and_publish_docs.sh` перед сборкой копирует в сгенерированный каталог только общие материалы:
```text
docs/30_registry/
docs/curated/
```
После копирования в `30_registry/guides/getting-started.md` подставляются параметры конкретного стенда:
- namespace;
- версия провайдера;
- API endpoint.
## Актуальные скрипты
Генерация Markdown выполняется так:
```text
TOOLS/scripts/01_generate_yamls.sh
-> generated/<stand>/resources_yaml/
TOOLS/scripts/02_generate_resources_and_docs_v2.sh
-> generated/<stand>/docs/
```
Сборка сайта выполняется скриптом:
```text
TOOLS/scripts/04_build_and_publish_docs.sh --profile TOOLS/config/<stand>
```
Он создаёт временный `.mkdocs.tmp.yml`, задаёт `site_url` с namespace стенда, запускает MkDocs и создаёт:
```text
site/
```
В конце этот скрипт вызывает актуальный:
```text
./scripts/publish-docs.sh site "$REGISTRY_HOST" "$NAMESPACE" "$PROVIDER_NAME" "$VERSION"
```
## Фактическое хранилище документации
Документация хранится не в bucket бинарников провайдера. Используется отдельный bucket:
```text
terraform-registry
```
Публикация выполняется без версии. Для любого стенда целевой S3 prefix:
```text
terraform-registry/docs/<namespace>/nubes/
```
Актуальный `scripts/publish-docs.sh` использует:
```text
mc mirror --overwrite --remove site/ registry/terraform-registry/docs/<namespace>/nubes/
```
Следствие: в URL документации нет версии `2.0.0`, `3.0.0` или `1.0.0`.
## Где выполнять S3 upload
История commit `9e02b69` зафиксировала, что из локальной сети большие рекурсивные операции S3 нестабильны. Поэтому `mc mirror` для документации выполняется на ВМ:
```text
5.172.178.213
```
Проверенный порядок:
```text
1. Собрать site/ локально.
2. Передать site/ на ВМ в ~/tmp-docs-site/.
3. На ВМ выполнить:
mc mirror --overwrite --remove \
~/tmp-docs-site/ \
registry/terraform-registry/docs/<namespace>/nubes/
4. На ВМ обновить локальное зеркало:
mc mirror --overwrite --remove \
registry/terraform-registry/docs/<namespace>/nubes/ \
/var/www/tf-docs/<namespace>/
```
S3 upload и обновление зеркала — два отдельных действия. Одной загрузки в S3 недостаточно, если публичный proxy читает локальное зеркало ВМ.
## Публичная доставка
На ВМ nginx использует корень:
```text
/var/www/tf-docs/
```
Сервис `tf_docs` проксирует публичный домен на ВМ. Для любого стенда итоговый путь:
```text
/var/www/tf-docs/<namespace>/
```
Итоговый URL любого стенда:
```text
https://tf-docs.nodejsk8s.dev.nubes.ru/<namespace>/
```
Например, для DEV `<namespace>` равен `nubes-dev`, но это только значение профиля, а не отдельная логика pipeline.
Путь с версией не используется для любого стенда:
```text
https://tf-docs.nodejsk8s.dev.nubes.ru/<namespace>/<version>/
```
не является корректным URL документации.
## Важное различие с публикацией бинарников
Бинарники Terraform-провайдера публикуются в другом bucket и с версионным prefix:
```text
nubes-terraform-registry/
tf-registry.containerk8s.services.ngcloud.ru/
<namespace>/nubes/<version>/
```
Документация публикуется отдельно:
```text
terraform-registry/docs/<namespace>/nubes/
```
Не смешивать эти два pipeline.
## Legacy, который не использовать
```text
DOCS_PIPELINE/publish-docs.sh
```
Это справочная legacy-копия старого скрипта. Она использует старую схему `mc cp`, старую структуру и версионный путь. Для текущей публикации использовать:
```text
scripts/publish-docs.sh
```
## История изменений, подтверждающая схему
- `dc469c6` — публикация docs без версии, `mc mirror`, `site_url` по стенду.
- `72a8a49` — актуализация README и новый docs host; старый скрипт помечен legacy.
- `9e02b69` — зафиксирована загрузка S3 с ВМ и обновление зеркала `/var/www/tf-docs/`.
- `02b7d7b` — подстановка namespace, версии и API endpoint выполняется после копирования `30_registry` в стендовый generated docs каталог.
@@ -0,0 +1,20 @@
# TEST and PROD documentation publication
## Result
- TEST documentation was regenerated from `TOOLS/config/test` with version `3.0.0`.
- PROD documentation was regenerated from `TOOLS/config/prod` with version `1.0.0`.
- TEST and PROD builds were executed sequentially because both use the shared local `site/` directory.
- TEST active mirror was replaced on the VM at `/var/www/tf-docs/nubes-test/`.
- PROD active mirror was replaced on the VM at `/var/www/tf-docs/nubes/`.
## Verification
- TEST active mirror contains `714` files and its `index.html` is present.
- PROD active mirror contains `344` files and its `index.html` is present.
- TEST HTML contains the TEST dashboard/API/provider values.
- PROD HTML contains the PROD dashboard/API/provider values.
## Infrastructure note
The S3 mirror command reported `unexpected EOF` while listing the registry. Its exit status was not treated as proof of publication. Each generated site was transferred directly to the VM, validated there, and atomically installed into its corresponding active mirror.
@@ -0,0 +1,167 @@
# 2026-10-02 — Хостинг документации: S3 static website на RGW (находки и версии развития)
> Команда владельца: «**То е ТАК ПРОВЕРЬ !**» → «документируй всё это как находки
> и версии развития, для дальнейших изменений».
Документ фиксирует **результат живой проверки** S3-эндпоинтов Nubes и **варианты развития**
схемы публикации документации. Ничего, кроме явно указанного в разделе «Изменения состояния»,
не менялось.
## Итог в одном абзаце
У Nubes **включён режим S3 static website** на объектном хранилище (Ceph RGW, релиз **Squid**),
и сайт документации **уже полностью работает прямо из S3** — без ВМ, без nginx, без зеркал и без
костылей с URL. Проверено анонимными запросами: каталог отдаётся как `index.html` байт в байт.
Единственный незакрытый элемент — **домен и TLS на нём** (`tf-docs.nodejsk8s.dev.nubes.ru`),
которые принадлежат Nubes, а не нам.
---
## 1. Изменения состояния (единственное, что я сделал)
| Что | Команда | Результат |
|---|---|---|
| Включён `IndexDocument` на бакете `terraform-registry` | `aws s3api put-bucket-website --bucket terraform-registry --website-configuration file:///tmp/ws.json` где `{"IndexDocument":{"Suffix":"index.html"}}` | HTTP **200**, пустое тело |
Проверка после:
```bash
aws --endpoint-url https://s3.msk-1.ngcloud.ru s3api get-bucket-website --bucket terraform-registry
```
```json
{
"IndexDocument": {
"Suffix": "index.html"
}
}
```
**Откат (одна команда):**
```bash
aws --endpoint-url https://s3.msk-1.ngcloud.ru s3api delete-bucket-website --bucket terraform-registry
```
> ⚠️ Статус на 2026-10-02: `IndexDocument` **оставлен** (владелец ещё не давал команду ни оставить,
> ни откатить — см. последний вопрос в диалоге). Содержимое бакета не изменялось.
## 2. Находки: что уже настроено у Nubes (не нами)
| Находка | Доказательство |
|---|---|
| Static website **реализован** в RGW | `get-bucket-website` до нашего PUT отвечал `404` с телом `<?xml…><Error><Code>NoSuchWebsiteConfiguration</Code>` — это ответ «фича есть, конфига нет», а не `NotImplemented` |
| Служба — **Ceph Object Gateway (squid)** | заголовок `server: Ceph Object Gateway (squid)` в ответах |
| **DNS wildcard для website-эндпоинта существует** | `terraform-registry.s3-website.msk-1.ngcloud.ru` → `89.169.61.167`; `terraform-registry.website.s3.msk-1.ngcloud.ru` → `89.169.61.166`; `s3-website.msk-1.ngcloud.ru` → `89.169.61.167` |
| **TLS на website-эндпоинте валиден** | `curl https://terraform-registry.s3-website.msk-1.ngcloud.ru/…` отдаёт HTTP-код, а не ошибку сертификата |
| На **порту 80** website-эндпоинт не отвечает | `curl http://…` → код `000` (соединение не устанавливается); работает только `https://` |
| Публичное чтение **уже разрешено политикой бакета** | `get-bucket-policy` → `{"Sid":"PublicReadGetObject","Effect":"Allow","Principal":"*","Action":["s3:GetObject","s3:GetObjectVersion"],"Resource":"arn:aws:s3:::terraform-registry/*"}` |
| ACL бакета — только владелец | `get-bucket-acl` → один грант `CanonicalUser … FULL_CONTROL` |
| Объектный эндпоинт каталоги **не умеет** | `/…/docs/nubes-dev/nubes/30_registry/` на `s3.msk-1.ngcloud.ru` → `403`; index-резолвинг делает **только** website-эндпоинт |
| Ключи бакета видны шире нашего тенанта | `list-buckets` нашими кредами вернул также `backup-mongo`, `karta`, `trino`, `technicals3backup-*`, `bucket2406`… — **требует уточнения у Nubes** (либо так настроен RGW, либо креды с расширенными правами) |
| `secrets/.s3cfg_registry` содержит **чужие** ключи | в файле, помимо `[default]`, лежат блоки `tazet@narod.ru PROD` и `ntazetdinov@nubes.ru PROD` (значения не приводим). Файл — рабочий, но его содержимое стоит разделить/почистить |
## 3. Проверки (воспроизводимые)
Подготовка окружения (ключи — из `secrets/.s3cfg_registry`, раздел `[default]`; секреты в команду не пишем):
```bash
set -a
eval "$(awk -F' = ' '/^access_key = /{print "AWS_ACCESS_KEY_ID="$2} \
/^secret_key = /{print "AWS_SECRET_ACCESS_KEY="$2}' secrets/.s3cfg_registry)"
set +a
export AWS_DEFAULT_REGION=us-east-1 EP=https://s3.msk-1.ngcloud.ru
```
### 3.1 Фактическая раскладка документации в бакете
```bash
aws --endpoint-url $EP s3api list-objects-v2 --bucket terraform-registry \
--prefix docs/ --delimiter "/" --query 'CommonPrefixes[].Prefix' --output text
```
```
docs/nubes-dev/
docs/nubes-test/
docs/nubes/
```
Внутри — ещё сегмент `nubes/`, например:
```
docs/nubes-dev/nubes/index.html 148758
docs/nubes-dev/nubes/30_registry/index.html 139835
docs/nubes-dev/nubes/30_registry/guides/glossary/index.html 150021
docs/nubes-dev/nubes/30_registry/assets/extra.css 13999
```
Полный путь сайта стенда: **`docs/<namespace>/nubes/…`**, где `<namespace>` ∈ {`nubes`, `nubes-dev`, `nubes-test`}.
Сегмента версии в ключах **нет** (это расходится с текстом справочного `DOCS_PIPELINE/publish-docs.sh:27`,
где в TARGET есть `${VERSION}` — на практике грузит `TOOLS/scripts/04_build_and_publish_docs.sh`).
### 3.2 Работа website-эндпоинта (анонимно, без авторизации)
```bash
W=https://terraform-registry.s3-website.msk-1.ngcloud.ru
for p in "/docs/nubes-dev/nubes/" \
"/docs/nubes-dev/nubes/30_registry/" \
"/docs/nubes-dev/nubes/30_registry/guides/glossary/"; do
echo -n "$p -> "; curl -s -o /dev/null -w '%{http_code} %{size_download}\n' --max-time 15 "$W$p"
done
```
| URL (каталог) | Код | Размер | Совпадает с `index.html` каталога |
|---|---|---|---|
| `/docs/nubes-dev/nubes/` | **200** | 148758 | ✅ |
| `/docs/nubes-dev/nubes/30_registry/` | **200** | 139835 | ✅ |
| `/docs/nubes-dev/nubes/30_registry/guides/glossary/` | **200** | 150021 | ✅ |
Для сравнения — тот же каталог на объектном эндпоинте: `403`; анонимный GET **существующего**
объекта `https://s3.msk-1.ngcloud.ru/terraform-registry/docs/nubes-dev/nubes/index.html` → `200` 148758.
## 4. Моя ошибка в ходе проверки (фиксирую)
На предыдущем шаге я утверждал, что бакет «отдаёт `index.html` → 200, а каталоги → 403»,
проверяя URL `…/docs/nubes/index.html`. **Такого ключа не существует** — реальная раскладка
`docs/<ns>/nubes/…`. Все «403» в той серии были ответом на **несуществующие** ключи,
а не отказом в доступе.
Уроки (для дальнейших проверок S3/RGW):
1. Перед выводами о 403/404 **сначала** получить фактический список ключей
(`list-objects-v2 --delimiter "/"`), а уже потом пробовать URL.
2. `403 AccessDenied` у RGW может означать «нет политики **или** ключа», а `400`/`403` на каталоге
объектного эндпоинта — норма, index-резолвинг живёт на website-эндпоинте.
3. Проверять двумя независимыми способами: анонимный `curl` **и** подписанный `aws s3api`
(через `--aws-sigv4` / `aws --endpoint-url`), и **сверять размеры** с `index.html`.
## 5. Версии развития схемы хостинга документации
| Версия | Схема | Статус | Что требуется |
|---|---|---|---|
| **V0** (текущая эксплуатация) | Публикация в S3 + **ВМ 213**: `nginx` :80/:443 → `/var/www/tf-docs/{nubes,nubes-dev,nubes-test}`, плюс зеркало `~/TF` на 213; внешний фронт `tf-docs.nodejsk8s.dev.nubes.ru` → `185.247.187.151` → `http://5.172.178.213/…` | работает, **но избыточна** | — |
| **V1** (проверена 2026-10-02, рабочая) | S3 website-эндпоинт как **единственный** источник: `https://terraform-registry.s3-website.msk-1.ngcloud.ru/docs/<ns>/nubes/…` | ✅ проверено анонимно (200, размеры совпадают) | `IndexDocument` (поставлен) + публичная политика (уже есть). ВМ, nginx, зеркало, `fix-slash.js`, `use_directory_urls: false` — **не нужны** |
| **V2** (целевая, «красивый домен») | Их фронт-прокси ставит origin на `terraform-registry.s3-website.msk-1.ngcloud.ru`; домен и TLS остаются их | ⏳ требует решения Nubes | запрос в Nubes: разрешить upstream на website-эндпоинт (порт HTTPS). Сохраняет текущий URL `https://tf-docs.nodejsk8s.dev.nubes.ru/…` |
| **V3a** (отклонён как ненужный) | `use_directory_urls: false` — плоские `*.html` | не требуется | при V1/V2 pretty-URL работает штатно; правка `mkdocs.yml` не нужна |
| **V3b** (отклонён как ненужный) | Ключи-«каталоги»: копия тела под ключом `…/foo/` | не требуется | RGW сам резолвит каталог в `index.html` на website-эндпоинте |
| **V3c** (невозможен) | Свой домен напрямую на S3 | — | домен и сертификат принадлежат Nubes, а не нам |
## 6. Чек-лист для дальнейших изменений
- [ ] Решить судьбу `IndexDocument` на `terraform-registry`: **оставить** (нужен для V1/V2) или откатить.
- [ ] При желании — добавить `ErrorDocument` (например, `404.html`), чтобы не отдавать стандартную
HTML-страницу RGW `NoSuchKey`.
- [ ] Запросить у Nubes (V2): upstream их фронта на `terraform-registry.s3-website.msk-1.ngcloud.ru`.
- [ ] Уточнить у Nubes: почему `list-buckets` нашими кредами показывает бакеты других тенантов.
- [ ] Разделить/почистить `secrets/.s3cfg_registry` (чужие ключи `tazet@narod.ru`, `ntazetdinov@nubes.ru`).
- [ ] Зафиксировать в `TOOLS/scripts/04_build_and_publish_docs.sh` целевую схему пути `docs/<ns>/nubes/`
и сверить с текстом `DOCS_PIPELINE/publish-docs.sh` (там есть `${VERSION}`, на практике его нет).
- [ ] При переходе на V1/V2 — отдельной командой вывести из эксплуатации: публикацию docs через nginx
на 213, зеркало `~/TF` (если оно нужно только для docs), костыль `docs/30_registry/javascripts/fix-slash.js`.
- [ ] Если 213 остаётся публичной — ограничить доступ (`allow <IP фронта>; deny all;`) на :80.
## 7. Связанные документы
- `HISTORY/2026-10-01_sync_tf_to_213_mirror.md` — зеркалирование `~/TF` на 213 (схема V0);
- `HISTORY/2026-09-30_yaml_pipeline_hardening.md` — пайплайн генерации YAML;
- `DOCS_PIPELINE/publish-docs.sh` — справочная копия заливки сайта в S3;
- `TOOLS/scripts/04_build_and_publish_docs.sh` — рабочий сборщик и публикатор документации.