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

2026-08-10 19:33:24 +04:00
parent 5a718a3ec2
commit a21cbd9cd2
3 changed files with 1 additions and 83 deletions
@@ -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`.
@@ -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-конфигурации.