Обновления и перенос
Symfony работает в dev, но возвращает 500 в prod
Symfony работает в dev, но отвечает 500 в prod. Объясняем, какие различия окружения нужно проверить и почему включение отладки не является исправлением.
Что происходит и с чего начать
Режим разработки и рабочий режим отличаются настройками, зависимостями, кешем и способом запуска. Поэтому успех локальной страницы не доказывает готовность производственного окружения. Сначала воспроизведите точный сценарий в prod и найдите соответствующее сообщение журнала. Не включайте публичную отладку ради удобства: подробная ошибка может раскрыть внутренние сведения посетителям. Для диагностики достаточно контролируемого доступа к журналам и понимания, какие параметры отличаются от работающей конфигурации разработчика.
Что можно проверить самостоятельно
- Запишите адрес, действие и время ошибки в prod. Проверьте, затронуты все страницы или только функции, использующие конкретную интеграцию, шаблон либо запись данных.
- Сравните версии PHP, установленные зависимости и необходимые параметры окружения. Передавайте имена отсутствующих настроек и безопасные ошибки, не содержимое секретов подключения.
- Уточните, от каких пользователей выполняются веб-запросы и команды публикации. Сохраните результат подготовки кеша и других шагов развёртывания, если они завершались предупреждением или ошибкой.
Как понять результаты проверки
Специалист проверяет рабочую конфигурацию контейнера сервисов, кеш, права и доступность зависимостей. Контейнер здесь означает механизм приложения для связывания сервисов, не обязательно Docker. Важно различать ошибку сборки и ошибку конкретного запроса. Устранение должно работать с выключенной отладкой и штатным набором производственных зависимостей. Если приложение требует переменную только локально заданную в терминале, её нужно правильно включить в окружение запуска, а не рассчитывать на сохранённую сессию разработчика.
Что проверяет разработчик
Для этой части понадобятся доступ к настройкам, журналам ошибок или коду. Её можно передать специалисту вместе с результатами предыдущих шагов.
- Проверьте настроенный журнал production и фактическое окружение веб-процесса. Успешная консольная команда в dev не проверяет рабочую конфигурацию.
- Сверьте секреты, параметры сервисов и доступ к базе. Проверьте, не используется ли в prod пакет, установленный только для разработки.
- Проверьте права на каталоги кеша и журналов, а также результат прогрева кеша для нужного релиза.
На что обратить внимание
Кеш, созданный администратором, может оказаться недоступным пользователю PHP. Также сборка контейнера сервисов в prod способна обнаружить проблему, которая не проявлялась на локальном наборе настроек.
Как исправляют причину
Исправьте конфигурацию и права, затем пересоберите кеш штатной процедурой для production. Не включайте публичный debug как способ оставить сайт работающим: диагностика должна оставаться закрытой.
Как убедиться, что проблема решена
Проверьте ключевые маршруты и консольные задачи в prod на тестовой копии. После публикации убедитесь, что новый релиз использует собственные актуальные настройки и не пишет ошибки доступа.
После исправления проверьте чистую подготовку рабочего окружения и нужные сценарии без debug-режима. Затем убедитесь, что фоновая обработка использует те же согласованные параметры, если она есть. Журналы контрольных запросов не должны содержать прежнего отказа. Приёмка подтверждает нормальный способ публикации и запуска, а не только одну сессию, где временные ручные настройки сделали страницу доступной.