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. ЖДАТЬ следующей команды
**ЗАПРЕЩЕНО** начинать работу, писать код, запускать команды — без явного "делай".
## ⛔⛔⛔ НЕ ТРОГАТЬ РАБОЧИЙ КОД
- Никаких изменений кода/инфраструктуры без явного «делай».
## ⛔⛔⛔ НЕ ТРОГАТЬ РАБОЧИЙ КОД — АБСОЛЮТНЫЙ ЗАПРЕТ НАВСЕГДА
## ⛔⛔⛔ ДЕЛАТЬ ТОЛЬКО ЧТО ПРИКАЗАНО
- Без додумывания, без «логичных следующих шагов».
**НИКАКИХ самодеятельных изменений рабочего кода:**
- Никаких "оптимизаций", "улучшений", "рефакторинга" без команды
- Никаких новых фич без явного разрешения
- Никаких docker/kubectl/helm команд и прочих инфраструктурных изменений без команды
- Перед ЛЮБЫМ изменением рабочего кода — объяснить ЗАЧЕМ и ждать "делай"
## ЕСЛИ ПРАВИШЬ КОД
- Сначала прочитай /home/naeel/nubes/SQS-service/.github/pravila.md (там: rsync на ВМ, git, docker, ssh, деплой).
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
> ⚠️ ЛЕГАСИ — старый k8s-деплой (kubectl apply). Уходим на Nubes Managed. ЭТИМ НЕ РУКОВОДСТВОВАТЬСЯ.
1. УВЕЛИЧИТЬ ТЕГ в `deployments/k8s/deployment.yaml` (vX.Y.Z → vX.Y.Z+1)
2. rsync на ВМ
3. ПРОВЕРИТЬ что файлы на ВМ новые (grep ключевой строки)
@@ -13,14 +31,14 @@
## Файловая система (актуально)
1. Все файлы редактируются локально: `~/SQS-service`
1. Все файлы редактируются локально: `/home/naeel/nubes/SQS-service`
2. После любых изменений — обязательно rsync на ВМ:
rsync -az \
-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/
3. Git (add/commit/push) выполнять ЛОКАЛЬНО в ~/SQS-service
3. Git (add/commit/push) выполнять ТОЛЬКО НА ВМ (через SSH) ПОСЛЕ синхронизации
4. Docker, kubectl и другие инфраструктурные команды — только через SSH на ВМ
5. Перед запуском любой команды на ВМ обязательно убедиться, что синхронизация (rsync) выполнена
6. SCP, sshfs, remote_dev и маунты больше НЕ используются
@@ -50,9 +68,9 @@ ssh -i ~/.ssh/naeel_vm_id_ed25519 -o StrictHostKeyChecking=no -o ConnectTimeout=
## Git
⛔⛔⛔ АБСОЛЮТНОЕ ПРАВИЛО:
- Git — ТОЛЬКО ЛОКАЛЬНО в `~/SQS-service`. НИКОГДА через SSH на VM.
- Разрешены ТОЛЬКО две операции: `git commit` и `git push`.
- ЗАПРЕЩЕНО: git pull, git fetch, git rebase, git merge, git reset, git stash, git checkout — что угодно кроме commit и push.
- Git — ТОЛЬКО НА ВМ (через SSH) ПОСЛЕ синхронизации rsync. НИКОГДА локально.
- Разрешены ТОЛЬКО операции: `git add`, `git commit`, `git push` (на ВМ).
- ЗАПРЕЩЕНО: git pull, git fetch, git rebase, git merge, git reset, git stash, git checkout — что угодно кроме add/commit/push.
- Если push отклонён — СТОП, доложить пользователю. Не лезть в pull/merge/rebase самостоятельно.
Версионирование тагами: `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 \
"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" \
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
# 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
BINARY=shared-sqs
README.md
+29 -22
View File
@@ -8,29 +8,34 @@
- **Многотенантность** — каждый тенант имеет отдельный Access Key и Secret Key
- **Redis persistence** — очереди и сообщения сохраняются при перезапуске сервиса
- **Web UI Console** — управление тенантами и просмотр сообщений
- **Kubernetes-ready** — Helm/манифесты, TLS Ingress, здоровье-checks
- **Managed-ready** — деплой Docker-образом через Nubes («Простой HTTP контейнер»), health-check /health
- **Admin API** — управление тенантами программно
## Быстрый старт
## Деплой (Nubes Managed)
### Локально
Сервис деплоится как Docker-образ через «Простой HTTP контейнер» (deck-UI) + Managed Redis.
Никакого Kubernetes/VPS.
### 1. Собрать и запушить образ в Gitea registry
```bash
docker run -d -p 9090:9090 naeel/shared-sqs:latest
# Откройте http://localhost:9090
docker build -t gitea.services.ngcloud.ru/nail/shared-sqs:v0.1.25 .
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
kubectl apply -k deployments/k8s/
```
- Сервис: «Простой HTTP контейнер»
- Образ: `gitea.services.ngcloud.ru/nail/shared-sqs:v0.1.25`
- Realm: `iot-naeel`
- Env (СРАЗУ, потом не меняются): `SHARED_SQS_ADMIN_TOKEN`, `REDIS_PASSWORD`
### Сборка локально
### Локальный запуск
```bash
go build -o shared-sqs ./app/cmd
./shared-sqs --port 9090
./shared-sqs --port 4100
```
## Архитектура
@@ -47,26 +52,28 @@ app/
├── router/ — HTTP маршруты
└── ui/ — Web Console (HTML/JS)
deployments/k8s/
├── deployment.yaml — Deployment с Redis sidecar
├── ingress.yaml — TLS, qu.kube5s.ru
└── redis.yaml — Redis Persistent Volume
deployments/k8s/ — ЛЕГАСИ (старый k8s-деплой, не использовать)
deployments/helm/ — ЛЕГАСИ (helm chart, не использовать)
```
## Окружение
| Переменная | Значение | Описание |
|-----------|---------|---------|
| `PORT` | 9090 | Порт HTTP сервера |
| `REDIS_URL` | localhost:6379 | Redis для persistence |
| `PORT` (--port) | 4100 | Порт HTTP сервера |
| `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 данные на старте |
| `NUBES_ENDPOINT` | https://deck-api.ngcloud.ru/api/v1 | JWT-валидация UI |
## API примеры
### Создать очередь (как тенант)
```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" \
-d "Action=CreateQueue&QueueName=myqueue&Version=2012-11-05"
```
@@ -75,8 +82,8 @@ curl -X POST "http://localhost:9090/" \
```bash
aws sqs send-message \
--endpoint-url http://localhost:9090 \
--queue-url http://localhost:9090/demo-shared-sqs/myqueue \
--endpoint-url http://localhost:4100 \
--queue-url http://localhost:4100/demo-shared-sqs/myqueue \
--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/byoc-credentials.md](doc/byoc-credentials.md) — BYOC интеграция
## Ссылки
- Репо: 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)
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
## Версия 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.