Некоторые задачи сайт должен выполнять сам, даже когда владелец спит, администратор не открывает панель управления, а посетители вообще ничего не нажимают. Интернет-магазину нужно обновить остатки, скрипту очистить временные файлы, сайту получить свежие данные из внешней системы, а служебной программе сформировать отчет. Запускать все это вручную каждый день было бы странно.
Для автоматического выполнения таких операций на сервере используется Cron. Это планировщик, которому можно указать, какую команду запустить и когда это сделать. Например, каждый день ночью, раз в час, по понедельникам или первого числа каждого месяца.
На многих виртуальных хостингах пользователю даже не приходится работать с командной строкой. В панели управления есть раздел с заданиями по расписанию, где достаточно выбрать время и указать команду или путь к скрипту. Но прежде чем создавать первое задание, полезно разобраться, что именно делает Cron. Ошибка в расписании иногда приводит не к автоматизации, а к совершенно автоматической перегрузке сайта.
Зачем сайту нужен Cron
Самый простой пример можно представить без программирования. Допустим, на сайте каждый вечер должен формироваться файл со статистикой за прошедший день. Можно зайти в панель управления и запускать создание отчета вручную. Но тогда человек становится частью технического процесса: забыл, уехал, заболел, выключил компьютер, и отчет не появился.
Гораздо логичнее один раз создать задание, которое будет запускать нужный скрипт каждый вечер. Именно эту роль выполняет Cron.
Применений у него много. Интернет-магазин может по расписанию синхронизировать товары с учетной системой. Скрипт способен периодически удалять устаревшие временные файлы. Сайт объявлений может снимать с публикации просроченные записи. Сервис может отправлять запланированные уведомления, обновлять данные через API или формировать отчеты.
Cron не является отдельной программой сайта и не зависит от того, открыт ли он сейчас в браузере. Это серверный механизм запуска команд по расписанию.
Здесь важно различать два похожих понятия. Есть системный Cron на сервере, а есть внутренние планировщики отдельных CMS. Самый известный пример второго варианта — WP-Cron в WordPress.
WP-Cron используется самой системой и плагинами для публикации запланированных записей, обновлений и других фоновых операций. Однако работает он не совсем так же, как обычный серверный Cron. Его выполнение связано с обращениями к сайту. Если посещаемость маленькая, запланированное событие может фактически выполниться позднее назначенного времени.
Поэтому для задач, которым действительно важно запускаться регулярно, на подходящем хостинге может использоваться системный планировщик.
Как устроено расписание Cron
Классическая запись Cron сначала кажется набором непонятных цифр и звездочек:
0 3 * * * команда
На самом деле принцип довольно простой. Перед командой находятся пять полей. Они последовательно задают минуту, час, день месяца, месяц и день недели.
Звездочка означает любое допустимое значение. Поэтому запись выше можно прочитать как: выполнить команду в нулевую минуту третьего часа каждого дня.
Например:
0 3 * * *— каждый день в 03:00;0 * * * *— в начале каждого часа;30 8 * * *— ежедневно в 08:30;0 12 * * 1— по понедельникам в 12:00;0 2 1 * *— первого числа каждого месяца в 02:00.
В реальной работе владельцу обычного сайта необязательно запоминать этот синтаксис. Панели многих хостингов позволяют составить расписание через обычные поля и списки. Вы выбираете периодичность, время запуска и указываете, что необходимо выполнить.
Гораздо важнее правильно определить саму команду.
Если нужно запустить PHP-скрипт, одного имени файла может оказаться недостаточно. Серверу требуется понимать, каким интерпретатором его выполнять и где находится сам файл. Конкретная команда зависит от устройства хостинга, версии PHP и расположения сайта.
Поэтому не стоит копировать команду из случайной инструкции и просто менять в ней название домена. На одном сервере PHP может находиться по одному пути, на другом по другому. Некоторые панели самостоятельно формируют правильную команду после выбора нужного сайта и версии PHP.
Есть и другой способ запуска, когда Cron обращается к определенному URL. Он бывает удобен для веб-скриптов, рассчитанных именно на HTTP-запрос. Но открывать служебный скрипт всему интернету только ради периодического запуска не всегда разумно. Если задачу можно безопасно выполнять непосредственно на сервере, такой вариант обычно предпочтительнее.
Как настроить Cron на обычном хостинге
Сначала найдите в панели управления раздел, который может называться Cron, CronTab, Планировщик заданий или Задания по расписанию. Названия отличаются, но назначение одно.
Перед созданием задания нужно точно знать, какой скрипт или команду вы хотите запускать. Это кажется очевидным, однако именно здесь возникает множество ошибок. Cron не способен догадаться, что именно требуется сайту.
Допустим, разработчик сделал скрипт, который обновляет каталог интернет-магазина, и сообщил его путь и необходимую команду запуска. В панели создается новое задание, указывается команда, после чего задается расписание.
Не начинайте сразу с редкого запуска раз в сутки. При первой настройке удобнее временно выбрать короткий интервал, дождаться выполнения и проверить результат. Если задача работает правильно, установите постоянное расписание.
Обязательно учитывайте время сервера. Если в панели указано 03:00, это не всегда означает три часа ночи именно по вашему местному времени. Сервер может использовать другой часовой пояс. Удобные панели показывают его явно, но если такой информации нет, лучше уточнить ее в документации или поддержке.
После запуска проверьте не только сам сайт, но и результат работы задачи. Если скрипт должен импортировать товары, убедитесь, что товары действительно обновились. Если он формирует файл, проверьте дату изменения файла. Если отправляет отчет, убедитесь, что отчет появился.
Для диагностики полезно сохранять вывод и ошибки выполнения в журнал. Ситуация, когда команда прекрасно работает при ручном запуске, но не работает через Cron, вполне реальна. Причиной может быть другой путь к PHP, недостаток прав, неверная рабочая директория, отсутствие необходимых переменных окружения или ошибка внутри самого скрипта.
Еще одна распространенная проблема связана с относительными путями. Скрипт предполагает, что запускается из определенной директории, а Cron запускает его в другом окружении. В результате программа не может найти подключаемый файл или каталог. Использование корректных абсолютных путей часто решает такую проблему.
На VPS возможностей больше. Там пользователь с соответствующими правами может работать непосредственно с crontab, просматривать существующие задания и редактировать расписание через командную строку. На обычном виртуальном хостинге удобнее пользоваться инструментами, которые предоставляет провайдер.
Почему Cron может перегружать хостинг
Автоматическая задача не становится бесплатной для сервера только потому, что ее никто не запускает руками. Скрипт использует процессор, память, диск и базу данных точно так же, как при обычном выполнении.
Представим импорт каталога, который обрабатывает несколько тысяч товаров. Один запуск занимает семь минут. Владелец решает получать максимально свежие данные и ставит задание каждые пять минут.
Первый процесс еще работает, когда запускается второй. Через несколько минут появляется третий. Если скрипт не защищен от параллельного выполнения, сервер получает несколько тяжелых процессов одновременно.
На виртуальном хостинге это способно быстро привести к превышению лимитов CPU, памяти или количества процессов. Сам сайт при этом начинает медленно открываться, хотя посетителей больше не стало.
Поэтому частота запуска должна соответствовать реальной задаче. Если остатки товаров достаточно обновлять раз в час, запуск каждую минуту не сделает магазин заметно полезнее для покупателя.
Стоит учитывать и время выполнения. Задание раз в десять минут выглядит вполне умеренным, пока не выясняется, что каждый запуск работает пятнадцать минут.
Тяжелые операции лучше по возможности переносить на часы небольшой посещаемости. Например, формирование большого отчета, обработку изображений или масштабный импорт каталога разумнее выполнять ночью, если бизнес-процесс позволяет это сделать.
Особого внимания требует резервное копирование. Cron действительно можно использовать для автоматического создания копий, но плохо настроенный сценарий способен постепенно заполнить весь диск. Скрипт каждую ночь создает новый архив, старые файлы никто не удаляет, и через несколько недель свободное пространство заканчивается. Поэтому автоматизация должна предусматривать не только создание данных, но и управление их жизненным циклом.
Для WordPress есть еще одна особенность. У CMS собственный механизм WP-Cron, который проверяет запланированные события при обращениях к сайту. На небольшом ресурсе этого часто достаточно. Но если выполнение задач должно происходить предсказуемее, системный планировщик может периодически запускать механизм WordPress самостоятельно. В такой конфигурации встроенный запуск WP-Cron при обычных посещениях можно отключить, но делать это следует только после того, как серверное задание действительно настроено и проверено.
Не нужно переводить WordPress на системный Cron просто потому, что такой совет встретился в инструкции. Если сайт работает нормально, задачи выполняются вовремя и проблем с нагрузкой нет, усложнение конфигурации может ничего не дать.
Cron полезен именно как инструмент автоматизации. Он позволяет серверу самостоятельно выполнять повторяющуюся работу: обновлять данные, запускать служебные скрипты, формировать отчеты, синхронизировать системы и обслуживать сайт без постоянного участия человека.
При выборе хостинга наличие планировщика особенно важно для проектов, которым нужны фоновые операции. Но одной галочки Cron в описании тарифа недостаточно. Полезно узнать минимальный разрешенный интервал запуска, ограничения времени выполнения и ресурсов, доступные версии интерпретаторов и возможность посмотреть ошибки задания.
Хорошо настроенный Cron почти незаметен. Нужная работа просто выполняется в нужное время. Плохо настроенный тоже может долго оставаться незаметным, пока однажды не выяснится, что десятки автоматических процессов одновременно пытаются сделать одну и ту же работу.
