portal/docs/deploy/test-server-runbook.md

Лидерра — тест-сервер (Yandex Cloud) — runbook

Создан: 2026-05-21. Тестовое окружение для ручной проверки (заказчик + Claude). Не продакшен. Спека: docs/superpowers/specs/2026-05-21-test-deploy-yandex-cloud-design.md. План: docs/superpowers/plans/2026-05-21-test-deploy-yandex-cloud.md.

Доступ

• URL (HTTP, временно): http://111.88.246.137 — статический IP YC.
• HTTPS / домен: добавляется после покупки домена (см. «Включить HTTPS»).
• Дверь сайта (HTTP Basic Auth): логин liderra — пароль в /home/ubuntu/liderra-secrets.txt на сервере (ключ basic_auth).
• Демо-вход в портал: admin@demo.local / password (tenant demo, 3 проекта, демо-сделки).
• SSH: ssh -i ~/.ssh/liderra_deploy ubuntu@111.88.246.137 (ключ на dev-машине; пароль входа отключён).
• YC: облако cloud-sasha261185, каталог default, VM liderra-test (ru-central1-a, 2vCPU/2GB/20%), SG liderra-test-sg (22/80/443).

Состав

• Ubuntu 24.04: nginx (Basic Auth, webhook /api/webhook/* без auth) → PHP-FPM 8.3 → Laravel.
• PostgreSQL 16 (БД liderra), Redis (sessions+cache+queue, predis).
• Код в /var/www/liderra/app; фронтенд public/build (собирается на dev, заливается scp).
• Службы: liderra-queue.service (queue worker, systemd, enabled) + cron /etc/cron.d/liderra-scheduler (schedule:run). Все автозапускаются после ребута.

Важные отклонения от прод-дизайна (на решение позже)

• DB-роль приложения = crm_app_user (RLS включена) — изоляция бизнес-данных между клиентами работает (deals/projects/billing/… строгие политики). Чтобы вход работал под строгой ролью, RLS-политики на таблицах users + auth_log сделаны «дружелюбными ко входу»: пропускают запрос, когда tenant-контекст ещё не установлен (auth/login), и фильтруют по тенанту после. Это server-only правка политик (не в schema.sql); для прода — кандидат в нормативную схему.
• Админка SaaS /admin/* под crm_app_user НЕ работает (нет доступа к saas-таблицам — REVOKE). Для теста «от лица клиентов» не нужна. Понадобится — переключать admin-запросы на crm_admin_user (connection-switch в middleware EnsureSaasAdmin) — отдельная доработка.
• SAAS_ADMIN_TEST_BYPASS=true — временный флаг (для будущей админки). Убрать после Yandex SSO (Б-1).
• Почта = log (письма в файл). APP_DEBUG=false, APP_ENV=production.
• Установлены dev-зависимости (faker нужен для сидов).

Тестовые клиенты

Логин	Пароль	Компания
admin@demo.local	password	Demo (3 проекта + демо-сделки)
client1@liderra.test	password	Компания 1 (2 проекта)
client2@liderra.test	password	Компания 2 (2 проекта)
client3@liderra.test	password	Компания 3 (2 проекта)
client4@liderra.test	password	Компания 4 (2 проекта)

Изоляция проверена вживую: каждый видит только свои проекты (HTTP-логин + /api/projects).

Каналы миграции с поставщиком (настроены 2026-05-21)

Все 3 канала с crm.bp-gr.ru подняты и проверены вживую на тест-сервере.

Предпосылки (доустановлены сверх базового деплоя — в исходном runbook их не было)

• Node.js 20 (NodeSource) + Playwright (app/playwright/node_modules, npm install) + Chromium в /var/www/.cache/ms-playwright/ (HOME у www-data = /var/www; ставить через sudo HOME=/var/www .../playwright install chromium затем chown -R www-data:www-data /var/www/.cache, иначе artisan от www-data не находит браузер). Без них логин к поставщику (Yii2-форма, JS) не работает → CSV-сверка и экспорт мертвы (PlaywrightBridge exit code 127: node: not found).
• PlaywrightBridge::TIMEOUT_SECONDS поднят 75 → 180 (app/app/Services/Supplier/PlaywrightBridge.php): на 2 ГБ VM холодный старт Chromium ~65 c, в 75 не укладывался. Бэкап *.bak.20260521.
• .env: SUPPLIER_LOGIN / SUPPLIER_PASSWORD (те же, что на dev). Бэкап .env.bak.20260521-*.
• system_settings.supplier_webhook_secret — 48-hex (DemoSeeder ставит короткий → guard <32 → webhook молча 404). Копия в /home/ubuntu/liderra-secrets.txt.
• system_settings.supplier_ip_allowlist = ["0.0.0.0/0"] — на APP_ENV=production пустой массив fail-closed (404 всем). TODO: сузить до IP поставщика (в логе видели 92.53.65.242).

Канал 1 — приём webhook'а (вход, основной)

• POST http://111.88.246.137/api/webhook/supplier/<secret> (nginx ^~ /api/webhook/ без Basic Auth).
• Проверено: правильный secret → 202, дубль vid → 200 already_processed, битый secret → 404.

Канал 2 — CSV-дочерпывание (вход, резерв)

• CsvReconcileJob, scheduler каждые 30 мин (cron schedule:run ежеминутно). Прогон вживую: 185 строк, status ok, drift 0.
• Ручной запуск: sudo -u www-data php artisan tinker --execute='App\Jobs\Supplier\CsvReconcileJob::dispatchSync()'.

Канал 3 — экспорт проектов (выход)

• SupplierProjectChannel::createProject / SupplierPortalClient::deleteProject. Проверено: create+delete тестового проекта (external_id=12764235), сверка listProjects — следов у поставщика нет.

Supplier-портал

• crm.bp-gr.ru → /admin/user/api: «Апи ссылка» = http://111.88.246.137/api/webhook/supplier/<secret>, «Апи протокол» = HTTP, «Апи статус» = Активный. Поставщик HTTP-URL принимает.
• ⚠️ Поле URL одно → после переключения на тест-сервер dev-машина живых лидов не получает.
• Сессия логина: Redis DB 1, ключ liderra-database-liderra-cache-supplier:session (TTL 6h, refresh-крон/supplier:session:refresh).

Сделать позже

• Привязать client1..4 к реальным каналам поставщика через pivot project_supplier_links (иначе лиды = ghost без сделок).
• HTTPS после покупки домена → URL у поставщика на https.
• Сузить supplier_ip_allowlist.

Обновить версию

На dev-машине:

npm --prefix app run build
git -C <repo> archive --format=tar HEAD app db -o $env:TEMP\liderra.tar
scp -i ~/.ssh/liderra_deploy $env:TEMP\liderra.tar ubuntu@111.88.246.137:/tmp/
scp -i ~/.ssh/liderra_deploy -r app\public\build ubuntu@111.88.246.137:/tmp/build

На сервере:

tar -xf /tmp/liderra.tar -C /var/www/liderra
rm -rf /var/www/liderra/app/public/build && cp -r /tmp/build /var/www/liderra/app/public/build
bash /var/www/liderra/redeploy.sh

Включить HTTPS (после покупки домена)

1. DNS: A-запись test.<домен> (и/или demo.<домен> для subdomain-tenant) → 111.88.246.137.
2. На сервере: в /etc/nginx/sites-available/liderra заменить server_name _; на домен, nginx -t && systemctl reload nginx.
3. sudo certbot --nginx -d test.<домен> --non-interactive --agree-tos -m <email> --redirect.
4. В .env обновить APP_URL=https://test.<домен>, затем php artisan optimize.

Остановить / удалить (прекратить оплату)

• Остановить VM: yc compute instance stop liderra-test (диск/IP сохраняются, мелкая плата).
• Удалить совсем: yc compute instance delete liderra-test + yc vpc address delete <id>.

После теста — обязательно

• Отозвать OAuth-токен Yandex Cloud (Яндекс ID → Безопасность → сторонние приложения).
• При переходе к прод-конфигу: убрать SAAS_ADMIN_TEST_BYPASS, вернуть crm_app_user (после auth-rework).