Вопрос или проблема
Это распространенная стратегия, когда веб-сервер ссылается на символическую ссылку и переключает символическую ссылку для развертывания новой версии
/var/www/current -> /var/www/build-1
Является ли это проблемой для запросов, выполняющихся во время переключения символической ссылки, для скриптов, которые ссылаются на другие файлы во время выполнения (в случае, если эти файлы были изменены в новой версии)?
Если да, то считаете ли вы, что это дисквалифицирует ее как стратегию для такого сервиса, который также требует высокой доступности?
Является ли лучшей стратегией обновление конфигурационных файлов Nginx, чтобы напрямую ссылаться на папку новой версии, и выполнение “service nginx reload”, так как (я предполагаю) это позволяет завершить выполняющиеся запросы на старой версии?
Если это уместно, меня в частности интересует PHP и Laravel.
Ответ или решение
Разворачивание приложений с использованием символических ссылок (symlink) — это распространенная и популярная стратегия, применяемая в веб-разработке для упрощения процесса обновления. Например, когда мы устанавливаем символическую ссылку /var/www/current, указывающую на версию сборки, такую как /var/www/build-1, это позволяет быстро переключаться на новые версии приложения. Однако такой подход вызывает ряд вопросов, особенно когда речь идет о высокодоступных приложениях, как, например, на PHP и Laravel.
Как изменение символической ссылки влияет на текущие запросы?
Когда вы меняете символическую ссылку, указывающую на новую сборку приложения, важно учитывать, что запросы, которые уже были запущены, продолжают выполнять код и обращаться к ресурсам по текущему пути. То есть если старой сборке были произведены изменения в файлах, используемых в рамках уже запущенных запросов, это может привести к некорректной работе приложения. Например, если в старой сборке выполняется скрипт, который получает доступ к файлам, изменённым в новой сборке, рост вероятности возникновения ошибок, таких как «файл не найден» или «метод не определён», существенно увеличивается.
Дискредитация стратегии?
Использование символических ссылок в качестве стратегии развертывания в условиях высоких требований к доступности становится небезопасным. Если ваши клиенты зависят от стабильности и предсказуемости работы приложения, эта стратегия может привести к непредсказуемым последствиям в случае, когда изменения в коде или ресурсах негативно сказываются на выполнении запросов.
Альтернативные стратегии
На практике более безопасной стратегией может стать обновление конфигурационных файлов Nginx, где можно указать новый путь к сборке, а затем перезапустить службу Nginx с помощью команды service nginx reload. Это позволяет текущим запросам завершиться, используя старую сборку, прежде чем новые запросы начнут обрабатываться уже с обновленным кодом. Таким образом, при использовании этого метода возможно избежать ситуаций, когда запущенные запросы начинают обращаться к новым версиям файлов, которые могут быть еще не завершены или находятся в неработоспособном состоянии.
Заключение
В конечном счёте, выбор стратегии развертывания зависит от специфики вашего приложения и задач, которые оно решает. Для PHP и Laravel, особенно в условиях высоких требований к доступности, можно рассмотреть метод, при котором старые запущенные процессы будут завершаться, прежде чем новая версия кода будет взята в работу. Это даст возможность обеспечить более плавный опыт для конечного пользователя и избежать неожиданных ошибок во время перехода на новую версию вашего приложения.