Вчора на stackoverflow зауважив питання про те, як передати скрипту через крон адреса сайту, якщо скрипт може виконуватися «під різними сайтами». Це досить цікаве питання, і є багато варіантів вирішення. Сам вирішував його не так давно, а саме тема интерисует і інших, вирішив про це написати.
Трохи докладніше про сам питанні. Найчастіше зустрічаються сайти, що працюють на одній кодової базі на одному сервері, але, при цьому, на різних доменах. При схожому зовнішньому вигляді на цих сайтах міститься різна інформація в різному дизайні.
Найпростіший приклад таких сайтів - це локалізовані версії одного сайту на різних мовах. У мене в практиці - це тематичні форуми для різних груп.
Поділ цих сайтів зазвичай відбувається через конфіги. Саме конфиг визначає всі деталі, унікальні для кожного сайту.
При запуску обробки користувальницького HTTP-запиту скриптів необхідно визначити, якого саме домену призначений запит, і вибрати відповідний конфиг. В PHP це досить просто зробити: заглянути в змінну $ _SERVER [ 'SERVER_NAME']. В інших мовах програмування під веб, думаю, приблизно так само просто.
На ім'я Серевера визначається потрібний конфіг і звідти беруться всі необхідні настройки. Все просто.
Але коли справа доходить до виклику скриптів з cron-а (або іншого планувальника), то змінна $ _SERVER [ 'SERVER_NAME'] буде порожня. Воно-то й зрозуміло: ніякого сервера немає, скрипт запускається безпосередньо через CLI . І дізнатися, для якого сайту викликається скрипт, без явної передачі домену скрипту неможливо.
Найпростіший спосіб вказати домен - це прописати його аргументом командного рядка. Коли Ви телефонуєте з cron-а після імені скрипта просто пишемо домен, а в коді отримуємо його з змінної $ argv глобальному контексті.
Але цей спосіб не відрізняється елегантністю, тому що доведеться визначати, як запускався сайт: через веб або CLI, і в залежності від цього шукати адресу сайту в різних місцях.
Другий великий мінус такого способу в тому, що прив'язка відбувається безпосередньо по домену, тобто немає гнучкості. Якщо однаковий сайт крутиться на різних доменах, то доведеться каламутити якусь систему алиасов. А це ще зменшує елегантність.
Таким чином шукаємо більш зручний спосіб передати «покажчик» на сайт. І знаходимо: це змінні оточення . Середу оточення інтерпретатор PHP отримує звідти, звідки він був запущений. Якщо скрипт запущений веб-сервером, то змінні будуть отримані від сервера. Якщо запускається скрипт через CLI, то середовище буде отримана від shell-а, в якому проводився запуск. Повторю: запуск скриптів з cron-а - це звичайний запуск виконуваного файлу в режимі CLI.
Тепер до конкретики. Щоб змінна середовища оточення потрапила з веб-сервера в PHP-скрипт (або скрипт / програму, написану на інших мовах), її треба встановити (прописати). Для Апача встановити змінну можна в файлі .htaccess, або в конфігах сервера (httpd.conf або конфіги віртуальних хостів). В ідеалі бажано останнім. Але досить і мінімального рівня доступу до .htaccess. Домагаючись у відповідний конфиг рядок:
SetEnv SITE_NAME site1
Щоб визначити змінну середовища при запуску в режимі CLI (php / filename), потрібно її оголосити і екпортіровать:
export SITE_NAME = site1;
При запуску скрипта вручну за допомогою такої команди можна запускати сам PHP. Якщо запуск проводиться cron-му, то варто створити скрипт, на який посилатися з crontab:
#! / Bin / bash
export SITE_NAME = site1;
php / path
Для інших сайтів замість site1 підставляються інші імена.
Залишається прочитати змінну в скрипті:
echo getenv ( 'SITE_NAME');
Ну а далі, в залежності від значення змінної, довантажувати потрібний конфіг.
* Варто відзначити, що в разі різних «установок» 1 одного і того ж сайту (development, testing, production) прийнято це значення передавати сайту у вигляді теж же змінної оточення. Як правило, конфиг в цьому випадку містить дуже багато інформації, однаковою для всіх «установок», а відрізнятися, наприклад, можуть тільки параметри доступу до БД. Тоді має сенс все установки вважати за один сайт (хоч домени і різні), а відрізняються параметри винести в окремий конфіг, залежний від «установки».
1 - Я наміряв в останньому абзаці замінив термін «оточення додатки» (application environment: тестове, робоче) на «установку», щоб не було плутанини з тим оточенням, де встановлюють змінним.