Дмитрий
a402e146b6
Вторая живая деплой-инструкция с той же миной (после 06-18 runbook): §миграций велела sudo -u postgres на VM = мёртвая копия. Исправлено на crm_migrator/Managed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
59 lines
4.7 KiB
Markdown
59 lines
4.7 KiB
Markdown
# deploy/
|
||
|
||
Скрипты применения обновлений на боевом портале **lk.liderra.ru** (`liderra.ru` = лендинг).
|
||
|
||
> 🔴 **ОБНОВЛЕНО 09.07.2026:**
|
||
>
|
||
> - **Каноническая процедура выката** — [docs/superpowers/runbooks/2026-06-18-gitea-prod-deploy-pipeline.md](../docs/superpowers/runbooks/2026-06-18-gitea-prod-deploy-pipeline.md) (сборка из `main` на сервере, хирургический overlay). Этот файл — про серверный `redeploy.sh` (scp-эпоха), исторический контекст.
|
||
> - **Миграции — на ЖИВОЙ Managed PG кластер `c9q2cvtjpq3hgq6l0r96` как `crm_migrator`**, НЕ через `sudo -u postgres psql` на VM (= мёртвая rollback-копия). См. §6b канонического ранбука. `artisan migrate` тоже не годится (config закэширован, `crm_app_user` не владелец).
|
||
> - **Выкат — из ветки `main`** (с 09.07 `main` = боевой прод).
|
||
|
||
## redeploy.sh
|
||
|
||
Server-side половина деплоя. На боевом лежит в `/var/www/liderra/redeploy.sh`
|
||
(вне репозитория Laravel). Здесь — каноническая копия для версионирования
|
||
и аудита.
|
||
|
||
**Workflow деплоя:**
|
||
|
||
1. **Локально** — собрать архив кода + Vite-сборку:
|
||
|
||
```bash
|
||
git archive HEAD app/ db/ | gzip > /tmp/deploy-code.tgz
|
||
tar czf /tmp/deploy-build.tgz -C app/public build/
|
||
```
|
||
|
||
2. **scp** обоих архивов на сервер.
|
||
3. **На сервере** — распаковать в `/var/www/liderra/app/`, выставить владельца
|
||
`www-data:www-data`, запустить `bash /var/www/liderra/redeploy.sh`.
|
||
|
||
**NB:** `redeploy.sh` НЕ делает `git pull` — он рассчитан на то, что код
|
||
уже залит scp. Если запустить без предварительного scp — будет no-op
|
||
(composer install / migrate / optimize / restart на той же кодовой базе).
|
||
|
||
**Квирк 107 (фикс встроен):** строка `sudo -u www-data php artisan optimize`
|
||
обязательна. Без неё `optimize` запускался от `ubuntu` → `bootstrap/cache/config.php`
|
||
с владельцем `ubuntu` → php-fpm (под `www-data`) не мог прочитать → 503 на всём
|
||
портале. Инцидент 24.05.2026 03:46 UTC, портал лежал 18 минут.
|
||
|
||
**Грабли composer-прав (фикс встроен, инцидент 23.06.2026):** `vendor/` принадлежит
|
||
`www-data`, а `redeploy.sh` бежит от `ubuntu`. Голый `composer install` падал
|
||
`autoload_classmap.php: Permission denied`, и из-за `set -e` скрипт рвался ДО `optimize`
|
||
и рестарта → новый код на диске, classmap новых классов НЕ пересобран → **прод 500**.
|
||
Фикс: `sudo env COMPOSER_ALLOW_SUPERUSER=1 composer install …` + `sudo chown -R www-data:www-data vendor`.
|
||
**Также:** при ручном восстановлении кэши надо пересобирать ДО рестарта php-fpm —
|
||
opcache держит старые до перезапуска (затяжной 500, пока fpm не рестартнут ПОСЛЕ кэшей).
|
||
|
||
**Грабли миграций crm_migrator (инцидент 19.06 + 23.06; ОБНОВЛЕНО 09.07 под Managed PG):**
|
||
таблицы принадлежат `crm_migrator`, штатной `.env`-ролью `crm_app_user` НЕ альтерятся
|
||
(`must be owner`). **С переезда 26.06 живая база = Managed-кластер, НЕ VM.** Применять миграцию
|
||
ВРУЧНУЮ **под `crm_migrator` на rw-endpoint Managed-кластера** (точный host + пароль Lockbox +
|
||
`sslmode=require` — §6b канонического ранбука) ДО `redeploy.sh` + `INSERT INTO migrations (migration, batch)
|
||
VALUES ('<имя_без_php>', (SELECT COALESCE(MAX(batch),0)+1 FROM migrations))`. Тогда `artisan migrate
|
||
--force` в скрипте = no-op. ⚠️ **НЕ `sudo -u postgres psql` на VM** — это мёртвая копия, миграция
|
||
туда живую базу не меняет. Точный рецепт — §6b канонического ранбука.
|
||
|
||
**Расхождение с боевым:** если правится этот файл — синкать на боевой
|
||
(scp + проверка хеша). Боевой = source of truth для исполнения, репо =
|
||
source of truth для рецепта.
|