Nail/SQS-service
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore: миграция на Nubes Managed — правила, README, registry Gitea, легаси помечено

Browse Source
This commit is contained in:
Naeel
2026-08-13 20:42:18 +03:00
parent 6af635afee
commit 5c1c021bb4
15 changed files with 2125 additions and 87 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.github/copilot-instructions.md
+13 -56
View File
@@ -1,63 +1,20 @@
# Правила # Правила (кратко)
## ⛔ ОТВЕЧАТЬ КРАТКО — АБСОЛЮТНОЕ ПРАВИЛО ## ⛔⛔⛔ НИКАКИХ ПРЕДПОЛОЖЕНИЙ — ТОЛЬКО ФАКТЫ
- Вопрос → короткий ответ → СТОП. - Только проверенные факты. Не проверено — писать «не проверено».
- Ничего лишнего.
- Код — только по запросу. ## ⛔ ОТВЕЧАТЬ КРАТКО
- Вопрос → короткий ответ → СТОП. Код — только по запросу.
## ⛔⛔⛔ ВОПРОС = СТОП ## ⛔⛔⛔ ВОПРОС = СТОП
- Любой вопрос → только ответить, ждать «делай». Не начинать работу без команды.
**Если в сообщении есть вопрос в ЛЮБОЙ форме** ("так ?", "верно ?", "почему ?", "как ?", "так же ?" и т.д.): ## ⛔⛔⛔ НЕ ТРОГАТЬ РАБОЧИЙ КОД
1. ТОЛЬКО ответить на вопрос - Никаких изменений кода/инфраструктуры без явного «делай».
2. ОСТАНОВИТЬСЯ
3. ЖДАТЬ следующей команды
**ЗАПРЕЩЕНО** начинать работу, писать код, запускать команды — без явного "делай".
## ⛔⛔⛔ НЕ ТРОГАТЬ РАБОЧИЙ КОД — АБСОЛЮТНЫЙ ЗАПРЕТ НАВСЕГДА ## ⛔⛔⛔ ДЕЛАТЬ ТОЛЬКО ЧТО ПРИКАЗАНО
- Без додумывания, без «логичных следующих шагов».
**НИКАКИХ самодеятельных изменений рабочего кода:** ## ЕСЛИ ПРАВИШЬ КОД
- Никаких "оптимизаций", "улучшений", "рефакторинга" без команды - Сначала прочитай /home/naeel/nubes/SQS-service/.github/pravila.md (там: rsync на ВМ, git, docker, ssh, деплой).
- Никаких новых фич без явного разрешения
- Никаких docker/kubectl/helm команд и прочих инфраструктурных изменений без команды
- Перед ЛЮБЫМ изменением рабочего кода — объяснить ЗАЧЕМ и ждать "делай"
1. Не трогать рабочий код без явного указания.
2. Файлы редактируются локально:
~/SQS-service
После ЛЮБЫХ изменений ОБЯЗАТЕЛЬНО синхронизировать на ВМ командой:
rsync -az \
-e "ssh -i ~/.ssh/naeel_vm_id_ed25519 -o StrictHostKeyChecking=no -o ConnectTimeout=10" \
~/SQS-service/ \
naeel@5.172.178.213:~/terra/SQS-service/
3. Git (add/commit/push) выполнять ЛОКАЛЬНО в ~/SQS-service
4. Docker, kubectl и другие инфраструктурные команды — только через SSH на ВМ:
ssh -i ~/.ssh/naeel_vm_id_ed25519 -o StrictHostKeyChecking=no -o ConnectTimeout=10 naeel@5.172.178.213 'КОМАНДА'
- не выполнять инфраструктурные команды локально
- не открывать интерактивные сессии
- не делать цепочки без необходимости
4. Перед запуском команд ОБЯЗАТЕЛЬНО убедиться, что синхронизация выполнена.
5. ЗАПРЕЩЕНО:
- откатывать код
- менять версии
- ломать рабочее состояние
6. После каждого исправления:
- git add/commit ЛОКАЛЬНО
- затем синхронизация (rsync) на ВМ
## ⛔⛔⛔ ДЕЛАТЬ ТОЛЬКО ЧТО ПРЯМО ПРИКАЗАНО
**АБСОЛЮТНЫЙ ЗАПРЕТ на додумывание:**
- Не расширять масштаб работы
- Не выполнять "логичные следующие шаги"
- Не инициировать дополнительные операции
- Не делать ничего кроме того что сказано
**Исключение:** только если приказ явно включает цепочку ("собери И залей И тесты")
.github/pravila.md
+25 -7
View File
@@ -1,7 +1,25 @@
# Правила работы агента # Правила работы агента
## ⛔⛔⛔ НИКАКИХ ПРЕДПОЛОЖЕНИЙ — ТОЛЬКО ФАКТЫ
**АБСОЛЮТНОЕ ПРАВИЛО:**
- Не выдавать предположения/допущения за факты.
- Говорить только то, что ПРОВЕРЕНО (прочитано, выполнено, подтверждено).
- Если не проверено — прямо писать «не проверено», не додумывать.
- Не строить выводы о реальном состоянии системы на основе манифестов/доков.
## ⛔⛔⛔ ВОПРОС = СТОП
**Если в сообщении есть вопрос в ЛЮБОЙ форме:**
1. ТОЛЬКО ответить на вопрос
2. ОСТАНОВИТЬСЯ
3. ЖДАТЬ следующей команды
**ЗАПРЕЩЕНО** начинать работу, писать код, запускать команды — без явного "делай".
## ⛔⛔⛔ DOCKER — ОБЯЗАТЕЛЬНЫЙ ПОРЯДОК ПЕРЕД КАЖДЫМ BUILD ## ⛔⛔⛔ DOCKER — ОБЯЗАТЕЛЬНЫЙ ПОРЯДОК ПЕРЕД КАЖДЫМ BUILD
> ⚠️ ЛЕГАСИ — старый k8s-деплой (kubectl apply). Уходим на Nubes Managed. ЭТИМ НЕ РУКОВОДСТВОВАТЬСЯ.
1. УВЕЛИЧИТЬ ТЕГ в `deployments/k8s/deployment.yaml` (vX.Y.Z → vX.Y.Z+1) 1. УВЕЛИЧИТЬ ТЕГ в `deployments/k8s/deployment.yaml` (vX.Y.Z → vX.Y.Z+1)
2. rsync на ВМ 2. rsync на ВМ
3. ПРОВЕРИТЬ что файлы на ВМ новые (grep ключевой строки) 3. ПРОВЕРИТЬ что файлы на ВМ новые (grep ключевой строки)
@@ -13,14 +31,14 @@
## Файловая система (актуально) ## Файловая система (актуально)
1. Все файлы редактируются локально: `~/SQS-service` 1. Все файлы редактируются локально: `/home/naeel/nubes/SQS-service`
2. После любых изменений — обязательно rsync на ВМ: 2. После любых изменений — обязательно rsync на ВМ:
rsync -az \ rsync -az \
-e "ssh -i ~/.ssh/naeel_vm_id_ed25519 -o StrictHostKeyChecking=no -o ConnectTimeout=10" \ -e "ssh -i ~/.ssh/naeel_vm_id_ed25519 -o StrictHostKeyChecking=no -o ConnectTimeout=10" \
~/SQS-service/ \ /home/naeel/nubes/SQS-service/ \
naeel@5.172.178.213:~/terra/SQS-service/ naeel@5.172.178.213:~/terra/SQS-service/
3. Git (add/commit/push) выполнять ЛОКАЛЬНО в ~/SQS-service 3. Git (add/commit/push) выполнять ТОЛЬКО НА ВМ (через SSH) ПОСЛЕ синхронизации
4. Docker, kubectl и другие инфраструктурные команды — только через SSH на ВМ 4. Docker, kubectl и другие инфраструктурные команды — только через SSH на ВМ
5. Перед запуском любой команды на ВМ обязательно убедиться, что синхронизация (rsync) выполнена 5. Перед запуском любой команды на ВМ обязательно убедиться, что синхронизация (rsync) выполнена
6. SCP, sshfs, remote_dev и маунты больше НЕ используются 6. SCP, sshfs, remote_dev и маунты больше НЕ используются
@@ -50,9 +68,9 @@ ssh -i ~/.ssh/naeel_vm_id_ed25519 -o StrictHostKeyChecking=no -o ConnectTimeout=
## Git ## Git
⛔⛔⛔ АБСОЛЮТНОЕ ПРАВИЛО: ⛔⛔⛔ АБСОЛЮТНОЕ ПРАВИЛО:
- Git — ТОЛЬКО ЛОКАЛЬНО в `~/SQS-service`. НИКОГДА через SSH на VM. - Git — ТОЛЬКО НА ВМ (через SSH) ПОСЛЕ синхронизации rsync. НИКОГДА локально.
- Разрешены ТОЛЬКО две операции: `git commit` и `git push`. - Разрешены ТОЛЬКО операции: `git add`, `git commit`, `git push` (на ВМ).
- ЗАПРЕЩЕНО: git pull, git fetch, git rebase, git merge, git reset, git stash, git checkout — что угодно кроме commit и push. - ЗАПРЕЩЕНО: git pull, git fetch, git rebase, git merge, git reset, git stash, git checkout — что угодно кроме add/commit/push.
- Если push отклонён — СТОП, доложить пользователю. Не лезть в pull/merge/rebase самостоятельно. - Если push отклонён — СТОП, доложить пользователю. Не лезть в pull/merge/rebase самостоятельно.
Версионирование тагами: `vMAJOR.MINOR.PATCH` Версионирование тагами: `vMAJOR.MINOR.PATCH`
@@ -86,7 +104,7 @@ LOG="tests/results/$(date +%Y-%m-%d_%H-%M).log"
ssh -i ~/.ssh/naeel_vm_id_ed25519 -o StrictHostKeyChecking=no naeel@5.172.178.213 \ ssh -i ~/.ssh/naeel_vm_id_ed25519 -o StrictHostKeyChecking=no naeel@5.172.178.213 \
"bash ~/terra/SQS-service/tests/run_tests.sh 2>&1 | tee ~/terra/SQS-service/${LOG}" "bash ~/terra/SQS-service/tests/run_tests.sh 2>&1 | tee ~/terra/SQS-service/${LOG}"
rsync -az -e "ssh -i ~/.ssh/naeel_vm_id_ed25519 -o StrictHostKeyChecking=no" \ rsync -az -e "ssh -i ~/.ssh/naeel_vm_id_ed25519 -o StrictHostKeyChecking=no" \
naeel@5.172.178.213:~/terra/SQS-service/tests/results/ ~/SQS-service/tests/results/ naeel@5.172.178.213:~/terra/SQS-service/tests/results/ /home/naeel/nubes/SQS-service/tests/results/
``` ```
**Никогда не разбираться с результатами по памяти / буферу / чату. Только лог.** **Никогда не разбираться с результатами по памяти / буферу / чату. Только лог.**
HISTORY/2026-08-13-session-log.md
+64
View File
@@ -0,0 +1,64 @@
# Журнал сессии — 2026-08-13 (миграция shared-sqs → Nubes Managed)
**Рабочая папка:** /home/naeel/nubes/SQS-service
---
## Ключевые факты (проверено, актуально)
### Docker-образ — Gitea registry (НЕ Docker Hub!)
- **Namespace (владелец):** `nail` (владелец репо `Nail` в git remote, в registry — lowercase)
- **Логин для docker login:** `ntazetdinov`
- **Токен:** проверен, работает (ванг: `/v2/` с `ntazetdinov:token` → 200; без auth / неверный → 401)
- **Имя образа:** `gitea.services.ngcloud.ru/nail/shared-sqs:v0.1.25`
### Команды пуша в Gitea registry (на ВМ, через SSH)
```bash
docker login gitea.services.ngcloud.ru -u ntazetdinov -p <токен>
docker build -t gitea.services.ngcloud.ru/nail/shared-sqs:v0.1.25 .
docker push gitea.services.ngcloud.ru/nail/shared-sqs:v0.1.25
```
### Managed Redis (уже создан, рабочий)
- instanceUid: `4ff5678b-b683-4aef-91da-22d89dec8a25`
- resourceRealm: `iot-naeel`
- internal master: `redisk8s.4ff5678b-b683-4aef-91da-22d89dec8a25.svc.cluster.local:6379`
- user: `default`, пароль в `redis.md`
### Целевой деплой
- deck-UI → «Простой HTTP контейнер» (nubes_http), realm `iot-naeel`
- Всё в одном кластере, без внешнего доступа к Redis
- env vars контейнера (СРАЗУ, потом не меняются): `SHARED_SQS_ADMIN_TOKEN`, `REDIS_PASSWORD`
- Нечувствительное — в Dockerfile `ENV`: `REDIS_ADDR`, `REDIS_USER`, `NUBES_ENDPOINT`, `SHARED_SQS_SEED_DEMO=false`
---
## Хронология действий
1. Сохранён план миграции IoT (`doc/2026-08-13-migration-to-managed.md`).
2. Изучен репозиторий SQS-service: Go 1.23, порт 4100, Redis write-through (без TLS), billing опционально.
3. Выяснено: Managed Redis на Nubes есть; «Простой HTTP контейнер» запускает docker-образы.
4. Сохранён план миграции (`doc/2026-08-13-migration-to-nubes.md`).
5. Коммит + push в gitea (обновлены git-креды для `gitea.services.ngcloud.ru`, логин `ntazetdinov`).
6. Поиск «кто создал poc-redis» — локальных следов нет, создано не с этой машины.
7. Проверка утечки кредов в терраформ-репах (JWT, HAR, tfvars) — по требованию пользователя прекращено лезть в чужие репы.
8. `redis.md` приведён в структурированный вид.
9. Промпт для Claude Sonnet v1 — Соннет лазил по всем файлам (слабое ограничение), начитался легаси pearlharbor.
10. Промпт v2 с жёсткими ограничениями (16 файлов, без поиска) — Соннет отработал чисто, план через deck-UI.
11. Создана архивная ветка `archive/2026-08-13-migration-planning`, закоммичены доки + HISTORY, запушено, возврат в main.
12. Правила проекта прочитаны (`.github/copilot-instructions.md`, `.github/pravila.md`, `shared-SQS/AGENTS.md`).
13. Исправлены правила: путь `~/SQS-service` → `/home/naeel/nubes/SQS-service`; git add/commit/push — ТОЛЬКО на ВМ после rsync.
14. Удалены бинарники `goaws` и `cmd` (не в git, уже в .gitignore).
15. Легаси-доки `PLAN.md`, `ONBOARDING.md`, `BENCHMARK-COMPARISON.md` перемещены в `doc/legacy/` с пометкой «ЛЕГАСИ».
16. Определён registry для образа: Gitea (не Docker Hub). Логин `ntazetdinov`, namespace `nail`.
---
## Ошибки сессии (не повторять)
1. Сначала сохранил в память AI вместо файла, когда просили «в файл».
2. Промпт агенту должен ЖЁСТКО ограничивать файлы и запрещать поиск.
3. Не лезть в чужие репозитории без явной команды.
4. Не упоминать терраформ — деплой только через deck-UI.
5. Ответы агентов проверять на легаси (pearlharbor, kafka, старые планы).
6. Не хардкодить секреты в Dockerfile — только env контейнера.
Makefile
+2 -2
View File
@@ -1,8 +1,8 @@
# Makefile — shared-sqs # Makefile — shared-sqs
# Created: 2026-04-09 # Created: 2026-04-09
# Registry: Docker Hub (naeel/shared-sqs) — pearlharbor не используется (нестабилен) # Registry: Gitea container registry (gitea.services.ngcloud.ru) — НЕ Docker Hub
IMAGE_REPO=naeel/shared-sqs IMAGE_REPO=gitea.services.ngcloud.ru/nail/shared-sqs
VERSION=v0.1.0 VERSION=v0.1.0
BINARY=shared-sqs BINARY=shared-sqs
README.md
+29 -22
View File
@@ -8,29 +8,34 @@
- **Многотенантность** — каждый тенант имеет отдельный Access Key и Secret Key - **Многотенантность** — каждый тенант имеет отдельный Access Key и Secret Key
- **Redis persistence** — очереди и сообщения сохраняются при перезапуске сервиса - **Redis persistence** — очереди и сообщения сохраняются при перезапуске сервиса
- **Web UI Console** — управление тенантами и просмотр сообщений - **Web UI Console** — управление тенантами и просмотр сообщений
- **Kubernetes-ready** — Helm/манифесты, TLS Ingress, здоровье-checks - **Managed-ready** — деплой Docker-образом через Nubes («Простой HTTP контейнер»), health-check /health
- **Admin API** — управление тенантами программно - **Admin API** — управление тенантами программно
## Быстрый старт ## Деплой (Nubes Managed)
### Локально Сервис деплоится как Docker-образ через «Простой HTTP контейнер» (deck-UI) + Managed Redis.
Никакого Kubernetes/VPS.
### 1. Собрать и запушить образ в Gitea registry
```bash ```bash
docker run -d -p 9090:9090 naeel/shared-sqs:latest docker build -t gitea.services.ngcloud.ru/nail/shared-sqs:v0.1.25 .
# Откройте http://localhost:9090 docker login gitea.services.ngcloud.ru -u ntazetdinov -p <токен>
docker push gitea.services.ngcloud.ru/nail/shared-sqs:v0.1.25
``` ```
### На Kubernetes ### 2. Создать контейнер в deck-UI
```bash - Сервис: «Простой HTTP контейнер»
kubectl apply -k deployments/k8s/ - Образ: `gitea.services.ngcloud.ru/nail/shared-sqs:v0.1.25`
``` - Realm: `iot-naeel`
- Env (СРАЗУ, потом не меняются): `SHARED_SQS_ADMIN_TOKEN`, `REDIS_PASSWORD`
### Сборка локально ### Локальный запуск
```bash ```bash
go build -o shared-sqs ./app/cmd go build -o shared-sqs ./app/cmd
./shared-sqs --port 9090 ./shared-sqs --port 4100
``` ```
## Архитектура ## Архитектура
@@ -47,26 +52,28 @@ app/
├── router/ — HTTP маршруты ├── router/ — HTTP маршруты
└── ui/ — Web Console (HTML/JS) └── ui/ — Web Console (HTML/JS)
deployments/k8s/ deployments/k8s/ — ЛЕГАСИ (старый k8s-деплой, не использовать)
├── deployment.yaml — Deployment с Redis sidecar deployments/helm/ — ЛЕГАСИ (helm chart, не использовать)
├── ingress.yaml — TLS, qu.kube5s.ru
└── redis.yaml — Redis Persistent Volume
``` ```
## Окружение ## Окружение
| Переменная | Значение | Описание | | Переменная | Значение | Описание |
|-----------|---------|---------| |-----------|---------|---------|
| `PORT` | 9090 | Порт HTTP сервера | | `PORT` (--port) | 4100 | Порт HTTP сервера |
| `REDIS_URL` | localhost:6379 | Redis для persistence | | `REDIS_ADDR` | host:6379 | Redis для persistence |
| `REDIS_USER` | default | Redis username |
| `REDIS_PASSWORD` | — | Redis password (секрет) |
| `SHARED_SQS_ADMIN_TOKEN` | — | Admin API bearer token (обязательный) |
| `SHARED_SQS_SEED_DEMO` | true/false | Загрузить demo данные на старте | | `SHARED_SQS_SEED_DEMO` | true/false | Загрузить demo данные на старте |
| `NUBES_ENDPOINT` | https://deck-api.ngcloud.ru/api/v1 | JWT-валидация UI |
## API примеры ## API примеры
### Создать очередь (как тенант) ### Создать очередь (как тенант)
```bash ```bash
curl -X POST "http://localhost:9090/" \ curl -X POST "http://localhost:4100/" \
-H "Authorization: AWS4-HMAC-SHA256 Credential=SSAK-demo-shared-sqs/20260410/us-east-1/sqs/aws4_request" \ -H "Authorization: AWS4-HMAC-SHA256 Credential=SSAK-demo-shared-sqs/20260410/us-east-1/sqs/aws4_request" \
-d "Action=CreateQueue&QueueName=myqueue&Version=2012-11-05" -d "Action=CreateQueue&QueueName=myqueue&Version=2012-11-05"
``` ```
@@ -75,8 +82,8 @@ curl -X POST "http://localhost:9090/" \
```bash ```bash
aws sqs send-message \ aws sqs send-message \
--endpoint-url http://localhost:9090 \ --endpoint-url http://localhost:4100 \
--queue-url http://localhost:9090/demo-shared-sqs/myqueue \ --queue-url http://localhost:4100/demo-shared-sqs/myqueue \
--message-body "Hello World" --message-body "Hello World"
``` ```
@@ -88,12 +95,12 @@ aws sqs send-message \
## Документация ## Документация
- [PLAN.md](PLAN.md) — детальный план разработки - [PLAN.md](doc/legacy/PLAN.md) — ЛЕГАСИ, исторический план разработки
- [doc/billing-and-metrics.md](doc/billing-and-metrics.md) — биллинг и Prometheus-метрики - [doc/billing-and-metrics.md](doc/billing-and-metrics.md) — биллинг и Prometheus-метрики
- [doc/byoc-credentials.md](doc/byoc-credentials.md) — BYOC интеграция - [doc/byoc-credentials.md](doc/byoc-credentials.md) — BYOC интеграция
## Ссылки ## Ссылки
- Репо: https://gitea.services.ngcloud.ru/Nail/SQS-service - Репо: https://gitea.services.ngcloud.ru/Nail/SQS-service
- Demo (dev): https://qu.kube5s.ru - Registry: https://gitea.services.ngcloud.ru/nail/shared-sqs
- Основана на: [GoAws](https://github.com/Admiral-Piett/goaws) - Основана на: [GoAws](https://github.com/Admiral-Piett/goaws)
deployments/helm/LEGACY.md
+5
View File
@@ -0,0 +1,5 @@
# ⚠️ ЛЕГАСИ — НЕ ИСПОЛЬЗОВАТЬ
Все файлы в этой папке — устаревший Helm chart (до миграции на Nubes Managed).
**ЭТИМ НЕ РУКОВОДСТВОВАТЬСЯ.** Только для истории.
Помечено: 2026-08-13.
deployments/k8s/LEGACY.md
+5
View File
@@ -0,0 +1,5 @@
# ⚠️ ЛЕГАСИ — НЕ ИСПОЛЬЗОВАТЬ
Все файлы в этой папке — устаревший k8s-деплой (до миграции на Nubes Managed).
**ЭТИМ НЕ РУКОВОДСТВОВАТЬСЯ.** Только для истории.
Помечено: 2026-08-13.
doc/decisions/LEGACY.md
+5
View File
@@ -0,0 +1,5 @@
# ⚠️ ЛЕГАСИ — НЕ ИСПОЛЬЗОВАТЬ
Исторические решения этапа разработки (апрель 2026).
**ЭТИМ НЕ РУКОВОДСТВОВАТЬСЯ.** Только для истории.
Помечено: 2026-08-13.
doc/errors/LEGACY.md
+5
View File
@@ -0,0 +1,5 @@
# ⚠️ ЛЕГАСИ — НЕ ИСПОЛЬЗОВАТЬ
Исторические инциденты/ошибки этапа разработки.
**ЭТИМ НЕ РУКОВОДСТВОВАТЬСЯ.** Только для истории.
Помечено: 2026-08-13.
doc/legacy/BENCHMARK-COMPARISON.md
+93
View File
@@ -0,0 +1,93 @@
<!-- ⚠️ ЛЕГАСИ — НЕ ИСПОЛЬЗОВАТЬ КАК РУКОВОДСТВО.
Исторические сравнительные тесты vs Yandex MQ (апрель 2026).
Перенесён из корня репозитория в doc/legacy 2026-08-13.
Замеры устарели, только для справки. -->
# Сравнительный анализ shared-sqs vs Yandex MQ
**Дата:** 2026-04-12 06:05 UTC
Итог сравнительных тестов shared-sqs и Yandex MQ.
## Главное
- shared-sqs показал конкурентоспособные результаты относительно Yandex MQ.
- На основных API-операциях shared-sqs в текущем прогоне быстрее или на уровне Yandex MQ.
- На batch-операциях shared-sqs также выглядит сильно.
- Проверкой охвачены все 17 поддерживаемых SQS-операций.
## Короткий вывод
Если смотреть на практические сценарии отправки, чтения и batch-обработки сообщений, shared-sqs уже выглядит как сильная реализация с хорошей latency и без явного проигрыша managed-сервису.
## Самые важные цифры
Формат: `min / avg / max / p95`, миллисекунды.
| Операция | Yandex MQ | shared-sqs | Что это значит |
|---|---:|---:|---|
| GetQueueUrl | 766 / 1346 / 2266 / 2060 | 739 / 752 / 770 / 760 | shared-sqs намного стабильнее |
| GetQueueAttributes | 804 / 820 / 847 / 828 | 738 / 752 / 768 / 765 | shared-sqs быстрее |
| SendMessage 1KB | 804 / 811 / 824 / 823 | 748 / 760 / 770 / 767 | shared-sqs быстрее |
| SendMessage 10KB | 916 / 967 / 996 / 987 | 880 / 913 / 965 / 951 | shared-sqs быстрее |
| SendMessage 32KB | 905 / 930 / 948 / 947 | 883 / 904 / 939 / 928 | shared-sqs быстрее |
| SendMessageBatch 10 | 784 / 803 / 827 / 820 | 718 / 746 / 782 / 759 | shared-sqs быстрее |
| ReceiveMessage | 782 / 826 / 869 / 864 | 738 / 748 / 777 / 751 | shared-sqs быстрее |
| DeleteMessage | 783 / 800 / 823 / 814 | 727 / 742 / 757 / 755 | shared-sqs быстрее |
| DeleteMessageBatch 10 | 818 / 845 / 872 / 864 | 742 / 783 / 821 / 810 | shared-sqs быстрее |
| ChangeMessageVisibilityBatch 10 | 806 / 829 / 848 / 841 | 803 / 824 / 838 / 836 | почти паритет, но shared-sqs чуть быстрее |
## Покрытие тестов по всем операциям
Ниже показано покрытие по каждой из 17 операций.
Обозначения:
- `Сравнение latency` — операция вошла в прямое сравнение shared-sqs и Yandex MQ.
- `Функциональная проверка` — операция отдельно проверялась на корректную работу.
- `Функционально проверено` — операция подтверждена в shared-sqs, без отдельной публичной latency-таблицы.
| Операция | Статус проверки | Комментарий |
|---|---|---|
| CreateQueue | Функциональная проверка | Использовалась в setup и проверялась как часть queue lifecycle |
| DeleteQueue | Функциональная проверка | Проверялась как часть queue lifecycle |
| GetQueueAttributes | Сравнение latency | Полноценное сравнение с Yandex MQ |
| GetQueueUrl | Сравнение latency | Полноценное сравнение с Yandex MQ |
| ListQueues | Сравнение latency | Полноценное сравнение с Yandex MQ |
| PurgeQueue | Сравнение latency | Контрольный замер, без многократного цикла |
| SetQueueAttributes | Сравнение latency | Полноценное сравнение с Yandex MQ |
| SendMessage | Сравнение latency | Сравнение для 1KB, 10KB и 32KB |
| SendMessageBatch | Сравнение latency | Batch из 10 сообщений |
| ReceiveMessage | Сравнение latency | Полноценное сравнение с Yandex MQ |
| DeleteMessage | Сравнение latency | Полноценное сравнение с Yandex MQ |
| DeleteMessageBatch | Сравнение latency | Batch delete на 10 сообщений |
| ChangeMessageVisibility | Сравнение latency | Полноценное сравнение с Yandex MQ |
| ChangeMessageVisibilityBatch | Сравнение latency | Batch visibility на 10 сообщений |
| TagQueue | Функционально проверено | Операция поддерживается и отдельно проверена |
| UntagQueue | Функционально проверено | Операция поддерживается и отдельно проверена |
| ListQueueTags | Функционально проверено | Операция поддерживается и отдельно проверена |
Итог по покрытию:
- `10` операций вошли в прямое latency-сравнение.
- `4` queue/control-plane операции дополнительно подтверждены функциональными сценариями.
- `3` tag-операции отдельно подтверждены функционально.
## Throughput
Тест: `SendMessage 1KB`, `5` воркеров по `10` сообщений.
| Провайдер | Успешно | Общее время | Грубая оценка |
|---|---:|---:|---:|
| Yandex MQ | 50 / 50 | 9116 ms | ~5 msg/s |
| shared-sqs | 50 / 50 | 8580 ms | ~5 msg/s |
Практический смысл:
- По грубой оценке `msg/s` здесь паритет.
- По общему времени shared-sqs завершает тест немного быстрее.
- Основное ограничение этого сценария задаётся AWS CLI, а не backend обоих сервисов.
## Финальный вывод для пользователя
shared-sqs уже выглядит достаточно сильным решением: latency на уровне или ниже Yandex MQ, batch-операции быстрые, а в общей рабочей зоне сервис показывает уверенные результаты.
doc/legacy/ONBOARDING.md
+173
View File
@@ -0,0 +1,173 @@
<!-- ⚠️ ЛЕГАСИ — НЕ ИСПОЛЬЗОВАТЬ КАК РУКОВОДСТВО.
Старая памятка для агента/нового чата (апрель 2026).
Перенесена из корня репозитория в doc/legacy 2026-08-13.
Описывает устаревший k8s-деплой и порядок работы. -->
# ONBOARDING.md — Памятка для нового чата / агента
# Дата: 2026-04-10
# Автор: GitHub Copilot (Claude Opus 4.6)
---
## Что это за проект
**SQS-service** — multi-tenant сервис очередей сообщений, совместимый с AWS SQS API.
Единственный в open source проект такого рода (подтверждено поиском по GitHub: 0 результатов по `multi-tenant sqs compatible`).
Ближайшие аналоги — ElasticMQ (Scala) и GoAws (Go), но оба **single-tenant** и предназначены только для local dev/testing.
---
## Откуда взялся код
Основан на **GoAws** (https://github.com/Admiral-Piett/goaws).
Первый коммит в `sless`: `shared-sqs: Этап 1 — клон GoAWS, удаление SNS, go build OK`
Затем поверх GoAws построены: мультитенантность, auth, admin API, WebUI, Redis persistence.
---
## Текущая версия
**v0.1.14** — работает в кластере iot-naeel
| Параметр | Значение |
|----------|---------|
| Endpoint | `https://qu.kube5s.ru` |
| IP | `185.247.187.151` |
| Admin token | `sqs-admin-7a7d8bd0c060a75c198d48680f34077a` |
| Demo Access Key | `SSAK-demo-shared-sqs` |
| Demo Secret Key | `demo-secret-key-shared-sqs-ngcloud-2026` |
| Docker image | `naeel/shared-sqs:v0.1.14` |
| Redis | `rfrm-redisk8s.54467f74-67f5-4ca7-9b4a-bdd50e8c23d6.svc.cluster.local:6379` |
| Kubeconfig | `/home/naeel/.kube/iot-naeel.yaml` (на ВМ) |
| Namespace | `shared-sqs` |
---
## Инфраструктура — ВАЖНО
### ВМ и монтирование
- **ВМ**: `naeel@5.172.178.213`
- **SSH-ключ**: `~/.ssh/naeel_vm_id_ed25519`
- **Реальный путь на ВМ**: `/home/naeel/terra/SQS-service`
- **Смонтировано как**: `/home/naeel/remote_dev/SQS-service` (sshfs)
### ⛔ КРИТИЧЕСКОЕ ПРАВИЛО
`/home/naeel/remote_dev/SQS-service` — это **СМОНТИРОВАННАЯ ПАПКА**.
Физически файлы на ВМ. **ВСЕ команды выполнять ТОЛЬКО через SSH на ВМ:**
```bash
ssh -i ~/.ssh/naeel_vm_id_ed25519 -o StrictHostKeyChecking=no -o ConnectTimeout=10 \
naeel@5.172.178.213 'cd /home/naeel/terra/SQS-service && <КОМАНДА>'
```
Через IDE — ТОЛЬКО редактирование файлов. Терминальные команды — ТОЛЬКО SSH.
---
## Архитектура кода
```
app/
├── cmd/goaws.go — точка входа, HTTP сервер
├── cmd/seed.go — загрузка демо-данных
├── models/ — Queue, Message, Tenant, SyncQueues (глобальный мьютекс!)
├── gosqs/ — реализация SQS API (CreateQueue, SendMessage, ReceiveMessage и т.д.)
├── admin/admin.go — Admin API: создание/получение тенантов
├── tenant/tenant_store.go — хранилище тенантов (access key → tenant)
├── auth/auth_middleware.go — AWS Signature V4 парсинг credential
├── persistence/redis.go — Redis write-through adapter
├── router/router.go — маршруты HTTP
├── ui/index.html — WebUI (встроен через embed.go)
└── utils/, interfaces/ — утилиты
```
---
## Известные проблемы (не трогать пока не попросят)
1. **Глобальный мьютекс** `models.SyncQueues` — Lock/Unlock на ВСЕ операции. Bottleneck при нагрузке.
2. **Нет DLQ** (Dead Letter Queue)
3. **Long Polling naïve** — sleep loop вместо push
4. **Нет rate limiting** per tenant
5. **Нет метрик** (Prometheus)
6. **Single pod** — нет горизонтального масштабирования
---
## Что делать дальше (от пользователя)
### 1. Статистика для биллинга
Нужен сбор метрик по каждому тенанту:
- Количество отправленных/полученных сообщений
- Количество созданных очередей
- Объём данных (bytes in/out)
- Время жизни сообщений
**Где встраивать**: `app/gosqs/send_message.go`, `app/gosqs/receive_message.go`, `app/gosqs/create_queue.go`
**Где хранить**: Новый пакет `app/billing/` или расширить `app/persistence/redis.go`
**Формат**: Redis HINCRBY per tenant per day, или отдельная таблица в PostgreSQL
### 2. Защита конфиденциальности
- Тела сообщений не должны логироваться
- Admin API должен быть доступен только из внутренней сети (или по отдельному порту)
- Тенанты не должны видеть друг друга (уже реализовано на уровне auth)
- Рассмотреть шифрование тел сообщений at rest (в Redis)
- Audit log: кто, когда, что делал
**Где встраивать**: middleware в `app/router/router.go`, новый пакет `app/audit/`
### 3. Рекомендации по порядку
1. Сначала **биллинг** — простой счётчик в Redis, можно сделать за 1 сессию
2. Затем **audit log** — middleware логирует tenant_id + action + timestamp
3. Затем **encryption at rest** — обёртка над Redis get/set
4. В последнюю очередь — rate limiting (зависит от биллинга)
---
## Тесты
| Скрипт | Описание | Как запускать |
|--------|----------|--------------|
| `tests/quick_test.sh` | 6 базовых тестов | `bash tests/quick_test.sh` |
| `tests/hardcore_test.sh` | Суровые тесты | `bash tests/hardcore_test.sh` |
| `tests/shared_sqs_test.sh` | E2E тесты | `bash tests/shared_sqs_test.sh` |
**ВАЖНО**: В `tests/quick_test.sh` используются demo credentials (`SSAK-demo-shared-sqs`).
В `tests/hardcore_test.sh` может быть admin token — НЕ КОММИТИТЬ в публичные репы!
---
## Git workflow
- Репо: `https://gitea.services.ngcloud.ru/Nail/SQS-service`
- Ветка: `main`
- Коммитить и пушить после каждого завершённого этапа (правило из copilot-instructions)
- Все команды git — через SSH на ВМ
---
## Сборка и деплой
```bash
# На ВМ:
cd /home/naeel/terra/SQS-service
# Сборка
docker build -t naeel/shared-sqs:v0.1.15 .
docker push naeel/shared-sqs:v0.1.15
# Деплой
export KUBECONFIG=/home/naeel/.kube/iot-naeel.yaml
kubectl set image deployment/shared-sqs shared-sqs=naeel/shared-sqs:v0.1.15 -n shared-sqs
kubectl rollout status deployment/shared-sqs -n shared-sqs
```
---
*Создано: 2026-04-10. Обновлять при значимых изменениях.*
doc/legacy/PLAN.md
+1693
View File
File diff suppressed because it is too large Load Diff
doc/progress.md
+3
View File
@@ -1,3 +1,6 @@
<!-- ⚠️ ЛЕГАСИ — история версий разработки (апрель 2026).
ЭТИМ НЕ РУКОВОДСТВОВАТЬСЯ. Только для истории. Помечено 2026-08-13. -->
# SQS-service Progress # SQS-service Progress
## Версия v0.1.x ## Версия v0.1.x
doc/thinking/LEGACY.md
+5
View File
@@ -0,0 +1,5 @@
# ⚠️ ЛЕГАСИ — НЕ ИСПОЛЬЗОВАТЬ
Исторические размышления/заметки этапа разработки.
**ЭТИМ НЕ РУКОВОДСТВОВАТЬСЯ.** Только для истории.
Помечено: 2026-08-13.
tests/LEGACY.md
+5
View File
@@ -0,0 +1,5 @@
# ⚠️ ЛЕГАСИ — НЕ ИСПОЛЬЗОВАТЬ
Старые тестовые скрипты (этап k8s-деплоя, домен qu.kube5s.ru).
**ЭТИМ НЕ РУКОВОДСТВОВАТЬСЯ.** Только для истории.
Помечено: 2026-08-13.