chore: git локально, после пуша синк на ВМ

2026-08-13 21:51:36 +04:00
parent 5c1c021bb4
commit 35a2bfa719
5 changed files with 8 additions and 1956 deletions
@@ -16,5 +16,5 @@
 - Без додумывания, без «логичных следующих шагов».
 ## ЕСЛИ ПРАВИШЬ КОД
- Сначала прочитай /home/naeel/nubes/SQS-service/.github/pravila.md (там: rsync на ВМ, git, docker, ssh, деплой).
+- Сначала прочитай /home/naeel/nubes/SQS-service/.github/pravila.md (там: git локально + после пуша синк на ВМ, docker/ssh на ВМ, деплой).
@@ -38,7 +38,7 @@
     /home/naeel/nubes/SQS-service/ \
     naeel@5.172.178.213:~/terra/SQS-service/
-3. Git (add/commit/push) выполнять ТОЛЬКО НА ВМ (через SSH) ПОСЛЕ синхронизации
+3. Git (add/commit/push) выполнять ЛОКАЛЬНО. После пуша — ОБЯЗАТЕЛЬНО синк на ВМ (rsync).
 4. Docker, kubectl и другие инфраструктурные команды — только через SSH на ВМ
 5. Перед запуском любой команды на ВМ обязательно убедиться, что синхронизация (rsync) выполнена
 6. SCP, sshfs, remote_dev и маунты больше НЕ используются
@@ -46,8 +46,9 @@
 Пример:
 1. Редактируешь локально
-2. rsync на ВМ
+2. git add/commit/push ЛОКАЛЬНО
-3. Выполняешь команды через SSH на ВМ
+3. rsync на ВМ (после пуша)
 4. Выполняешь команды через SSH на ВМ
 ## SSH
@@ -57,7 +58,7 @@
 ssh -i ~/.ssh/naeel_vm_id_ed25519 -o StrictHostKeyChecking=no -o ConnectTimeout=10 naeel@5.172.178.213 'КОМАНДА'
 ```
-Запрещено локально: `go`, `docker`, `kubectl`, `helm`, `terraform`, `curl/wget`, `git push/pull`, любые скрипты проекта.
+Запрещено локально: `go`, `docker`, `kubectl`, `helm`, `terraform`, `curl/wget`, любые скрипты проекта. (git — разрешён локально)
 ## Документация
@@ -68,8 +69,8 @@ ssh -i ~/.ssh/naeel_vm_id_ed25519 -o StrictHostKeyChecking=no -o ConnectTimeout=
 ## Git
 ⛔⛔⛔ АБСОЛЮТНОЕ ПРАВИЛО:
- Git — ТОЛЬКО НА ВМ (через SSH) ПОСЛЕ синхронизации rsync. НИКОГДА локально.
+- Git — ЛОКАЛЬНО в /home/naeel/nubes/SQS-service. После push — синк на ВМ (rsync).
- Разрешены ТОЛЬКО операции: `git add`, `git commit`, `git push` (на ВМ).
+- Разрешены операции: `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 самостоятельно.
@@ -1,88 +0,0 @@
 # Сравнительный анализ 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-операции быстрые, а в общей рабочей зоне сервис показывает уверенные результаты.
@@ -1,168 +0,0 @@
 # 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. Обновлять при значимых изменениях.*