Классический способ публикации PHP проектов: имеем текущую версию кода в некоей директории директории /app/version1 и символическую ссылку /app/current -> /app/version1.
Настройки nginx таковы, что код запускается из /app/current (т.е. по символической ссылке).
Пришло время вложить новую версию: заливаем на сервер в директорию /app/version2 и после этого переключаем символическую ссылку /app/current -> /app/version2.
Атомарно? Не факт!
Есть несколько дополнительных факторов, которые нужно учитывать при деплое:
- OPCache
- realpath_cache
- А начиная с PHP 7.4 ещё и preload
И сразу возникают вопросы:
- Нужно ли делать сброс OPCache при такой схеме деплоя с двумя директориями и символической ссылкой? А если нужно, как это сделать правильно: php-fpm restart vs php-fpm reload vs gordalina/cachetool?
- Нужно ли сбрасывать realpath_cache или достаточно использовать $realpath_root в настройках nginx?
- Приводит ли php-fpm reload к сбросу realpath_cache?
- А если используем preload (PHP 7.4+), то выходит в любом случае придётся делать php-fpm reload? Или php-fpm restart?
Сознательно опускаю вопросы миграции базы данных и специфичные кеширующие механизмы тех или иных фреймворков.
Что рекомендую прочитать:
1. Не плохая статья-расследование с заголовком «Во всём виноват PHP OPCache?» https://habr.com/ru/company/mailru/blog/341912/
Спойлер: в этом случае OPCache не виноват, проблема была в realpath_cache
2. Подробности про работу realpath_cache: https://habr.com/ru/post/266909/
3. 5 способов деплоя PHP-кода в условиях хайлоада: https://habr.com/ru/company/oleg-bunin/blog/449916/
В этой статье специфика проекта, с которой вряд ли придётся столкнуться 99% разработчиков: «2 000 серверов, на которых 150 000 файлов объемом по 900 Мб PHP-кода и стейджинг-кластер на 50 машин». Однако написано хорошо и, безусловно, есть полезная информация и для разработчиков обычных, не столь нагруженных проектов.
После прочтения данной заметки, возможно, у вас появилось ещё больше вопросов, чем было! Будем разбираться дальше.
