Деплой релизами: симлинк, каталог данных снаружи и одна ошибка, которая стоит контента
Схема выкладки, где каждый релиз — отдельный каталог, а данные живут вне них. И почему DATA_DIR внутри релиза — потеря контента, а не неудобство.
Выкладка устроена так: сборка складывается в каталог с именем коммита, симлинк current переставляется на него, сервис перезапускается. Старые релизы какое-то время лежат рядом. Схема известная — интереснее то, что рядом с ней должно лежать, а что не должно ни в коем случае.
Раскладка
На сервере три вещи: каталог releases с релизами по коммитам, симлинк current на используемый, и каталог data. Сервис запускается с рабочим каталогом current и читает данные по абсолютному пути в переменной окружения.
Откат при такой схеме — это переставить симлинк обратно. Не пересборка, не git revert с ожиданием, а одна операция, которая либо прошла, либо нет.
1[Service]
2WorkingDirectory=/var/www/allgenl-portfolio/current
3Environment=DATA_DIR=/var/www/allgenl-portfolio/data
4User=www-data
5Group=www-data
6ExecStart=/usr/bin/node deploy/server.mjs
| Что | Владелец | Почему так |
|---|---|---|
| releases/ | пользователь деплоя | их создаёт выкладка |
| current | пользователь деплоя | это симлинк, его переставляет выкладка |
| data/ | пользователь сервиса | в него пишет панель |
Две проверки, которые спасают прод
Перед перезагрузкой nginx — обязательно nginx -t. Битый конфиг уронит не только новый сайт, но и все остальные на машине.
Перед пушем в ветку, с которой идёт выкладка — сборка и тесты локально. Раннер соберёт то же самое, но узнать об ошибке до того, как симлинк переставлен, дешевле.
