Дмитрий
ed94d0305e
Прежний reorder (optimize последним) владельца НЕ менял: optimize перезаписывает существующий config.php in-place (file_put_contents не трогает владельца) → оставался ubuntu:www-data 775 (читаемо, портал работал, но комментарий врал про www-data). Теперь rm config/routes/events перед optimize → www-data создаёт свежие как www-data:www-data 664. Синкнут на прод (sha совпал). Главное по квирку 107 — читаемость (валидатор П1 test -r), владелец вторичен. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
deploy/
Скрипты применения обновлений на боевом сервере liderra.ru.
redeploy.sh
Server-side половина деплоя. На боевом лежит в /var/www/liderra/redeploy.sh
(вне репозитория Laravel). Здесь — каноническая копия для версионирования
и аудита.
Workflow деплоя:
-
Локально — собрать архив кода + Vite-сборку:
git archive HEAD app/ db/ | gzip > /tmp/deploy-code.tgz tar czf /tmp/deploy-build.tgz -C app/public build/ -
scp обоих архивов на сервер.
-
На сервере — распаковать в
/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): таблицы, принадлежащие
crm_migrator (напр. saas_transactions), штатной .env-ролью НЕ альтерятся
(must be owner). Применять миграцию ВРУЧНУЮ под sudo -u postgres psql ДО запуска
redeploy.sh + INSERT INTO migrations (migration, batch) VALUES ('<имя_без_php>', <batch>).
Тогда php artisan migrate --force в скрипте = no-op. Иначе set -e порвёт деплой.
Расхождение с боевым: если правится этот файл — синкать на боевой (scp + проверка хеша). Боевой = source of truth для исполнения, репо = source of truth для рецепта.