Інструкції та туторіали по хостингу Практика

Cron-завдання на хостингу: як навчити сервер працювати, поки ви спите

Африканський дизайнер налаштовує cron на хостингу за комп'ютером

Уявіть: ви спите, а ваш сервер о третій ночі чистить старі логи, робить бекап бази, відправляє клієнтам email-нагадування і генерує свіжий sitemap. Вранці ви відкриваєте ноутбук - і все вже зроблено. Ніякої магії. Це cron - один з найстаріших і найнедооцінених інструментів Unix-систем, якому вже більше 45 років, але який досі працює як швейцарський годинник. Проблема в тому, що 70% власників сайтів навіть не підозрюють про його існування, а ті, хто знає - часто налаштовують так, що сервер починає задихатися від надмірного навантаження. Давайте це виправимо.

Що таке cron і чому він важливіший, ніж здається

Cron - це планувальник завдань у Linux. Якщо Windows має Task Scheduler з красивими вікнами та кнопками, то cron обходиться одним текстовим файлом - crontab. Кожен рядок у цьому файлі - це інструкція: "о такому-то часі, в такий-то день, запусти ось цю команду". Просто? Так. Потужно? Неймовірно.

Подумайте про cron як про ідеального асистента, який ніколи не забуває, не хворіє і не просить підвищення зарплати. Ви один раз пояснюєте, що і коли робити - і він виконує це роками. Буквально.

Головна перевага cron - передбачуваність. На відміну від ручних дій, автоматизовані завдання виконуються з точністю до хвилини, без людського фактора. Забули оновити кеш? Cron не забуде. Пропустили щоденний бекап? Cron зробить його навіть у неділю.

Домашній офіс з моніторами для автоматизації сервера та crontab налаштування
Домашній офіс з моніторами для автоматизації сервера та crontab налаштування

Синтаксис crontab: п'ять зірочок, які змінюють все

Ось рядок, який лякає новачків:

* * * * * /path/to/script.sh

П'ять зірочок - п'ять полів. Кожне відповідає за свій відрізок часу. Якщо розібратися один раз, ви більше ніколи не заплутаєтесь.

Поле Значення Допустимий діапазон Приклад
1 - Хвилина В яку хвилину 0-59 30 (о 30-й хвилині)
2 - Година В яку годину 0-23 3 (о 3 ночі)
3 - День місяця Якого числа 1-31 15 (15-го числа)
4 - Місяць В якому місяці 1-12 6 (червень)
5 - День тижня В який день 0-7 (0 і 7 = неділя) 1 (понеділок)

Зірочка (*) означає "кожен". Тобто * * * * * - це "кожну хвилину, кожну годину, кожного дня". Ось кілька реальних прикладів, які ви зможете використати прямо зараз:

  1. 0 3 * * * - щодня о 3:00 ночі (ідеально для бекапів)
  2. */15 * * * * - кожні 15 хвилин (перевірка статусу, черги email)
  3. 0 9 * * 1 - щопонеділка о 9:00 (тижневі звіти)
  4. 0 0 1 * * - першого числа кожного місяця опівночі (очищення старих даних)
  5. 30 */2 * * * - о 30-й хвилині кожні 2 години (оновлення кешу)

Порада для тих, хто не хоче запам'ятовувати: використовуйте сервіс crontab.guru. Вводите вираз - отримуєте пояснення людською мовою. Безкоштовно, без реєстрації, працює миттєво.

Як додати cron-завдання: три способи для різних ситуацій

Залежно від вашого хостингу і рівня доступу, є кілька шляхів. Розберемо кожен.

Спосіб 1: Через SSH (повний контроль)

Якщо у вас VPS або виділений сервер, підключіться через SSH і введіть:

crontab -e

Відкриється текстовий редактор (зазвичай nano або vi). Додайте свій рядок, збережіть, вийдіть. Готово. Перевірити поточні завдання - crontab -l. Видалити все - crontab -r (обережно з цим).

Спосіб 2: Через панель керування (без терміналу)

cPanel, Plesk і DirectAdmin мають графічний інтерфейс для cron. У cPanel шукайте розділ "Cron Jobs" в блоці "Advanced". Там ви обираєте періодичність з випадаючих списків і вставляєте команду. Ідеально для shared-хостингу, де SSH або взагалі недоступний, або обмежений.

Спосіб 3: Через wp-cron (для WordPress)

WordPress має вбудований псевдо-cron. Але ось нюанс: wp-cron спрацьовує лише коли хтось відвідує сайт. Якщо ваш сайт має 10 відвідувачів на добу, завдання можуть запускатися з величезними затримками. Рішення - вимкнути wp-cron і замінити його справжнім серверним cron:

Додайте у wp-config.php:
define('DISABLE_WP_CRON', true);

А в crontab:
*/15 * * * * wget -q -O /dev/null https://yoursite.com/wp-cron.php

Працівник перевіряє cron завдання на VPS з кавою за монітором
Працівник перевіряє cron завдання на VPS з кавою за монітором

10 завдань, які ваш cron повинен виконувати вже сьогодні

Більшість людей використовують cron для бекапів. Це правильно, але це лише верхівка айсберга. Ось список завдань, які реально економлять години щотижня:

  • Бекап бази даних - mysqldump щоночі з ротацією старих копій
  • Очищення тимчасових файлів - /tmp, кеш-директорії, старі сесії
  • Оновлення SSL-сертифікатів Let's Encrypt - certbot renew двічі на день
  • Відправка email-дайджестів - черга листів, яка не навантажує сервер у піковий час
  • Моніторинг дискового простору - скрипт, що надсилає alert, коли диск заповнений на 90%+

"Якщо ви виконуєте щось вручну більше двох разів - автоматизуйте це. Час адміністратора дорожчий за час процесора." - Tom Limoncelli, автор "The Practice of System and Network Administration"

А ще: генерація sitemap, ротація логів (logrotate теж працює через cron), перевірка доступності зовнішніх API, синхронізація файлів між серверами через rsync, перезапуск сервісів, що "зависли". Список обмежений лише вашою фантазією.

Пастки, в які потрапляють навіть досвідчені адміни

Cron простий у використанні, але має кілька неочевидних підводних каменів. Я бачив, як люди годинами дебажили скрипти, які прекрасно працювали в терміналі, але мовчки провалювалися в cron. Чому?

Пастка номер один - змінні середовища. Коли ви запускаєте скрипт через SSH, у вас завантажений повний профіль користувача з усіма PATH, HOME, LANG. Cron запускає команди в мінімальному оточенні. Якщо ваш скрипт використовує php без повного шляху - cron може його просто не знайти. Рішення: завжди прописуйте повний шлях - /usr/bin/php, /usr/local/bin/node.

Пастка номер два - відсутність логування. За замовчуванням cron відправляє вивід команди на email користувачу. Але якщо email не налаштований (а він зазвичай не налаштований), вивід зникає у нікуди. Додайте перенаправлення:

0 3 * * * /path/to/backup.sh >> /var/log/backup.log 2>&1

Частина 2>&1 означає "помилки теж пиши в лог". Без цього ви ніколи не дізнаєтесь, чому бекап зламався три тижні тому.

Пастка номер три - одночасний запуск. Уявіть: скрипт бекапу працює 20 хвилин, а cron запускає його кожні 15. Два процеси перекриваються, конкурують за ресурси, база блокується. Використовуйте flock для блокування:

*/15 * * * * /usr/bin/flock -n /tmp/backup.lock /path/to/backup.sh

І ще одна класика - права доступу. Скрипт має бути виконуваним (chmod +x script.sh), а crontab кожного користувача запускає завдання від його імені. Root-овий crontab і crontab звичайного юзера - це два різних файли з різними правами.

Ілюстрація автоматизації cron задач для WordPress хостингу
Ілюстрація автоматизації cron задач для WordPress хостингу

Альтернативи та еволюція: коли звичайного cron недостатньо

Cron чудовий для простих задач. Але що робити, коли ваш проєкт виріс?

Для складніших сценаріїв існують інструменти наступного рівня:

  • systemd timers - вбудовані в сучасні Linux-дистрибутиви, підтримують залежності між завданнями та точніший контроль
  • Celery Beat - для Python-проєктів, працює з чергами завдань Redis/RabbitMQ
  • Laravel Scheduler - елегантна обгортка над cron для PHP-фреймворку, де розклад описується прямо в коді
  • Healthchecks.io - безкоштовний сервіс моніторингу cron-завдань (сповіщає, якщо завдання НЕ запустилось вчасно)

Окрема порада: якщо ви працюєте з хмарними провайдерами (AWS, Google Cloud, Azure), зверніть увагу на їхні managed-рішення - AWS EventBridge, Cloud Scheduler, Azure Logic Apps. Вони вміють запускати не тільки скрипти, а й Lambda-функції, HTTP-запити, повідомлення в черги. Але для 95% задач на звичайному хостингу - класичний cron більш ніж достатній.

Ось що мене дивує: люди витрачають години на вибір ідеальної теми для WordPress, годинами полірують CSS-анімації, але повністю ігнорують автоматизацію серверних процесів. А потім дивуються, чому їхній сайт повільніший за черепаху з артритом, база важить 3 ГБ через старі ревізії, а логи з'їли весь диск.

Один рядок у crontab може замінити годину щоденної ручної роботи. За рік це 365 годин - більше 45 повних робочих днів. Скільки з них ви вже витратили даремно? І головне - який перший cron-завдання ви додасте сьогодні?