В описании хостинга есть PHP, база данных и достаточно места на диске. Кажется, для приложения на Laravel всё подходит. Но после переноса выясняется: команды запускать нельзя, задания выполняются только раз в 15 минут, а отправка писем через очередь вообще остановилась. При этом главная страница может исправно открываться.
Так происходит, когда при выборе тарифа проверяют только самые заметные характеристики. Приложению нужны определённые условия работы, и они не всегда помещаются в короткую карточку хостинга.
Это похоже на аренду помещения под мастерскую. Площадь подходит, цена устраивает, электричество есть. Но потом оказывается, что нужный станок подключить нельзя, а работать разрешено только в определённые часы. Помещение может быть хорошим — просто условия не подходят вашей работе.
Laravel — основа для разработки веб-приложений: личных кабинетов, магазинов, систем обучения и других сервисов. В зависимости от проекта ему нужны не только обработка страниц и база данных, но и выполнение команд, работа по расписанию, фоновые процессы. Filament, который часто используют вместе с Laravel, помогает создавать административные панели и тоже имеет свои требования к окружению.
Поэтому вопрос «У вас работает Laravel?» лучше сразу дополнить описанием конкретного приложения.
Начать стоит с версии PHP и установленных расширений. Требования определяются версией Laravel, Filament и остальных пакетов проекта. Самая новая версия PHP не обязательно подходит существующему приложению: совместимость нужно проверять по его зависимостям.
Разработчик может сверить требования через Composer — инструмент, который устанавливает PHP-библиотеки. Команда composer check-platform-reqs --no-dev проверяет соответствие текущего PHP и расширений требованиям установленных рабочих пакетов. Это полезная проверка окружения командной строки, но она не заменяет проверку PHP, который обслуживает сайт.
Следующий пункт — способ выполнения PHP. Веб-сервер принимает запрос посетителя и передаёт работу обработчику PHP. PHP-FPM управляет процессами, которые выполняют такие запросы. В инфраструктуре LiteSpeed для взаимодействия с PHP может использоваться LSAPI.
Эти названия часто встречаются в требованиях к хостингу, но по одной надписи в панели нельзя оценить скорость приложения. Более того, PHP-FPM сам использует FastCGI. Поэтому слово FastCGI в диагностике ещё не означает, что сервер настроен неправильно.
Отдельно проверяют OPcache. Он сохраняет подготовленный к выполнению PHP-код в памяти, чтобы при следующих запросах не повторять часть работы по его обработке. Для приложения с большим количеством PHP-файлов это может заметно снизить накладные расходы. При этом OPcache не хранит готовые ответы базы данных и не устраняет задержки внешних сервисов.
Проверять его работу нужно в окружении конкретного сайта. Настройки PHP для браузерных запросов и командной строки могут различаться. Результат команды, выполненной по SSH, не всегда описывает то, как PHP работает при открытии страницы.
Если страница открывается 20 секунд, сначала нужно выяснить, где проходит это время. Причиной могут быть медленные запросы к базе данных, ожидание стороннего API, нехватка доступных PHP-процессов, ограничения ресурсов или настройки самого приложения. Иногда задерживается уже загрузка ресурсов в браузере.
Полезнее передать разработчику или поддержке конкретный адрес страницы, действие, точное время проверки и условия появления задержки. Например: список заказов открывается быстро, а поиск по нему зависает; проблема возникает постоянно или только вечером. Затем сопоставляют время ответа сервера, журналы приложения, запросы к базе и расход ресурсов.
Если приложение большую часть времени ждёт ответ внешнего сервиса, смена обработчика PHP не уберёт это ожидание. А если задержку создаёт ограничение текущего тарифа, перенос или увеличение соответствующего ресурса действительно могут помочь.
SSH нужен для подключения к командной строке сервера. Через него разработчик может устанавливать зависимости, выполнять команды Laravel, проверять состояние приложения и обновлять его. Для этих действий часто достаточно доступа к своему аккаунту; полные административные права на сервер требуются далеко не всегда.
Важно уточнить, какие команды разрешены и какая версия PHP запускается из терминала. На сайте может быть выбран подходящий PHP, а команда php будет обращаться к другой установленной версии. Если SSH отсутствует, заранее выясните, какой способ развёртывания предусмотрен: автоматическая сборка, инструменты панели или выполнение необходимых действий поддержкой.
Отдельного внимания заслуживает cron — системный механизм запуска команд по расписанию. Его можно представить как будильник: в назначенное время он запускает указанную команду.
В стандартной схеме Laravel cron каждую минуту вызывает php artisan schedule:run. Планировщик приложения проверяет, какие задачи пора выполнить. Это не означает, что все задачи выполняются каждую минуту: одна может запускаться ежедневно, другая — раз в час.
Если хостинг разрешает cron только раз в 15 минут, некоторые запланированные запуски могут быть пропущены. Например, задача назначена на 12:07, а планировщик проверили в 12:00 и следующий раз запустили в 12:15. Поэтому формулировки «cron поддерживается» недостаточно. Нужны минимальный интервал, ограничения длительности команды и доступ к журналу её выполнения.
С cron часто путают обработчик очереди. Очередь хранит задания, которые приложение передало на последующее выполнение: отправить письмо, обработать импорт, сформировать отчёт. Обработчик, или worker, забирает эти задания и выполняет их.
Будильник и сотрудник, выполняющий работу, решают разные задачи. Наличие минутного cron само по себе не подтверждает, что очередь будет работать. Для обычного постоянно работающего обработчика нужно разрешение на длительный процесс и механизм его автоматического перезапуска после остановки — например, Supervisor или другая служба управления процессами.
На виртуальном хостинге такие процессы могут быть ограничены. Поэтому, если приложение использует очередь, этот пункт проверяют отдельно. Redis нужен только тогда, когда он предусмотрен выбранной схемой приложения: Laravel поддерживает разные способы хранения очередей.
Есть и требования к размещению файлов. Корень сайта должен указывать на каталог public, а служебные файлы проекта должны оставаться недоступными через браузер. Приложению также нужны права записи в предусмотренные для этого каталоги. Эти условия стоит проверить до загрузки проекта на новый аккаунт.
Nginx подходит для Laravel. Но если на прежнем сервере правила переадресации или заголовки безопасности были записаны в .htaccess, при переходе на Nginx их нужно перенести в его конфигурацию: сам файл .htaccess он не обрабатывает. Это часть настройки нового окружения.
У приложений с Filament дополнительно проверяют подготовку панели к рабочему запуску: настройку доступа пользователей, актуальность её ресурсов и предусмотренное используемой версией кэширование компонентов. Если проект собирает JavaScript и CSS, нужно заранее определить, где выполняется сборка. Node.js не обязательно должен быть установлен на самом хостинге, если туда поступают уже собранные файлы.
Перед оплатой удобно отправить поддержке короткий список требований:
- версии Laravel, Filament, PHP и базы данных, необходимые PHP-расширения;
- способ запуска PHP и возможность проверить OPcache для выбранного сайта;
- доступ по SSH либо другой согласованный способ установки зависимостей и выполнения команд;
- cron каждую минуту, ограничения времени выполнения заданий;
- используемая очередь, возможность запуска обработчика и необходимые дополнительные сервисы;
- настройка каталога
public, права записи и необходимые исходящие подключения; - ограничения CPU, общей памяти аккаунта, памяти PHP, числа процессов, диска и количества файлов.
Если эти условия выполняются и ресурсов хватает, виртуальный хостинг может быть достаточным. VPS имеет смысл, когда нужны собственные службы, постоянные процессы или настройки, недоступные на выбранном хостинге. При сравнении стоимости учитывайте, кто будет обновлять сервер, следить за его состоянием и настраивать резервное копирование.
Перенос приложения нужно принимать по его работе. Помимо копирования файлов и базы данных, в согласованный объём работ стоит включить настройку окружения и проверку основных действий.
- Зафиксировать исходное состояние. Подготовить проверенную резервную копию файлов, базы и пользовательских загрузок. Сохранить сведения о расписании, очередях и подключённых сервисах.
- Подготовить новое окружение. Установить совместимые версии ПО и зависимости проекта. Согласовать конфигурацию сайта, подключения к базе, почте и хранилищам. При обычном переносе сохранить действующий
APP_KEY: его произвольная замена может сделать ранее зашифрованные данные недоступными. - Проверить приложение до переключения пользователей. Пройти вход в кабинет, основные формы, загрузку файлов и работу панели Filament. Контролируемо выполнить тестовую задачу очереди и проверить расписание. Тестовая копия не должна параллельно отправлять рабочие рассылки или выполнять другие реальные операции.
- Согласовать переключение. Определить порядок остановки записи и фоновых задач на старой площадке, окончательной синхронизации данных и запуска новой. Это помогает избежать потерянных изменений и повторного выполнения заданий.
- Проверить результат после переноса. Повторить рабочие действия, убедиться в выполнении фоновых задач и сравнить скорость проблемных страниц на сопоставимых данных. Проверить журналы ошибок и сохранить возможность согласованного возврата при неисправности.
Перед переносом в QCKL отправьте в поддержку описание приложения и его требования. Если есть проблема со скоростью, добавьте конкретный пример и результаты доступных измерений. Заранее согласуйте подходящую услугу, настройку окружения, стоимость работ и порядок проверки после переноса.
Так у переноса появляется понятная цель: приложение запускается в совместимом окружении, выполняет фоновые задачи, обновляется предусмотренным способом, а его основные функции проверены в работе.
