fix: remove s3-bucket-notifications (unverified), clean deck-api from getting-started

docs/30_registry/guides/getting-started.md

@@ -31,7 +31,6 @@ terraform {
 }
 
 provider "nubes" {
-  # ⛔ LEGACY: deck-api.ngcloud.ru ЗАКРЫВАЕТСЯ. Использовать lk-api-gateway.
   api_endpoint = "https://lk-api-gateway.ngcloud.ru/api/v1/svc"
   api_token = var.api_token
 }
@@ -46,7 +45,7 @@ variable "api_token" {
   Эта документация относится к TEST стенду.
 
   - Личный кабинет: https://deck-test.ngcloud.ru/dashboard/
-  - API endpoint: https://deck-api-test.ngcloud.ru/api/v1
+  - API endpoint: https://lk-api-gateway-test.ngcloud.ru/api/v1/svc
 
 !!! tip "Безопасность"
     Никогда не храните токен прямо в файле `main.tf`, если планируете загружать код в систему контроля версий (git). Используйте `variables.tf` или файл `terraform.tfvars`.

docs/30_registry/guides/s3-bucket-notifications.md

@@ -1,80 +0,0 @@
-<!-- ⛔ LEGACY: deck-api.ngcloud.ru ЗАКРЫВАЕТСЯ. Актуальный API: lk-api-gateway.ngcloud.ru/api/v1/svc -->
-# S3 Bucket Notifications: изменения в бакете и вызов функции
-
-## Короткий ответ
-
-Да, для S3-совместимого хранилища можно вызывать обработчик при изменениях в бакете через стандартный механизм уведомлений:
-
-- событие в бакете (`ObjectCreated`, `ObjectRemoved`),
-- правило уведомления на бакете,
-- destination (webhook/queue/topic),
-- consumer/функция, которая принимает событие.
-
-## Что проверено в нашем контуре
-
-Проверка выполнялась удалённо (через SSH), не локально.
-
-- API `deck-api-test.ngcloud.ru`:
-  - есть общий endpoint `/notifications`,
-  - явных endpoint'ов вида `bucketNotifications`, `events`, `webhooks` в этом API не обнаружено.
-- Документация `docs.s3.msk-1.ngcloud.ru`:
-  - в публичных страницах не найден явный раздел про bucket notifications.
-- Прямая проверка S3-слоя:
-  - `mc event ls <alias>/<bucket>` отработал успешно (код возврата `0`),
-  - это подтверждает доступность стандартной S3 операции чтения notification-конфигурации;
-  - пустой вывод означает, что правила ещё не заданы.
-
-## Нужно ли задавать это при создании бакета
-
-Рекомендуется задавать сразу в том же Terraform apply, но это отдельная конфигурация относительно самого факта создания бакета.
-
-Практически правильно так:
-
-1. Создать (или использовать) `S3 Storage service`.
-2. Создать бакет.
-3. Создать destination для событий (webhook/queue/topic).
-4. Назначить notification rule на бакет.
-5. Поднять consumer/функцию, которая обрабатывает событие.
-
-## Как это выглядит архитектурно
-
-```text
-Bucket (ObjectCreated/ObjectRemoved)
-  -> Bucket Notification Rule
-    -> Destination (Webhook / Queue / Topic)
-      -> Function/Worker (business logic)
-```
-
-## Что это значит для Terraform
-
-Лучший путь: один модуль/стек, где декларативно описано сразу всё:
-
-- bucket,
-- destination,
-- notification rule,
-- function/consumer.
-
-Это даёт предсказуемый результат: после `apply` события бакета уже маршрутизируются в обработчик.
-
-## Если notifications недоступны в конкретном backend
-
-Fallback — polling:
-
-- периодический опрос бакета,
-- сравнение состояния (`key + etag/version_id + mtime`),
-- вызов функции только на diff.
-
-## Проверка и настройка через CLI
-
-Пример скрипта в репозитории:
-
-- `scripts/s3_notification_example.sh`
-
-Скрипт:
-
-- читает `.s3cfg`,
-- показывает текущие правила,
-- добавляет правило,
-- показывает итоговую конфигурацию.
-
-> Важно: для `event add` нужен существующий destination (`TARGET_ARN`) в S3/MinIO-конфигурации.

mkdocs.yml

@@ -56,7 +56,6 @@ nav:
     - Быстрый старт: 30_registry/guides/getting-started.md
     - Основы Terraform: 30_registry/guides/terraform-basics.md
     - Структура манифестов: 30_registry/guides/terraform-structure.md
-    - S3 Notifications: 30_registry/guides/s3-bucket-notifications.md
     - Глоссарий: 30_registry/guides/glossary.md
   - Проверенные примеры:
     - PostgreSQL: curated/postgres/pg_user_db.md