Приклад конфігураційного файлу Varnish, Ромко! eu
Як обіцяв у доповіді, викладаю приклад і опис робочого конфігу для Варніша. Щоб дізнатися докладніше про те, що таке Варніш і для чого він потрібен, ознайомтеся з розділом Pressflow + Varnish.
У цьому прикладі розглядається конфіг для Варніша третьої версії (зараз це остання стабільна версія). Зверніть увагу, у Варніша з версії 2.1.0 змінився двигун обробки регулярних виразів, тому деякі приклади конфігів, доступні в інтернеті, можуть працювати некоректно. Лулаботи, наприклад, оновили свій туторіал та пропонують відразу кілька варіантів конфігу для різних версій Варніша.
Завантажити мій конфіг можна тут, нижче опис найцікавіших і важливих його частин.
Вказуємо Варнішу, з яким веб-сервером потрібно працювати. Параметри в блоці probe означають, що кожні 5 секунд на бекенд потрібно смикати файл status.php. Якщо протягом 1 секунди від бекенда не буде отримано відповідь з кодом 200, то перевірка буде вважатися такою, що провалилася. Якщо провалено 3 перевірки з 5, бекенд позначається "упалим".
Таким чином, вже через 15 секунд після виникнення проблем на бекенді, Варніш помітить його впалим і, залежно від налаштувань, або почне передавати запити іншому бекенду, або обслуговувати запити зареєстрованих користувачів зі свого кешу.
Декілька бекендів можуть бути об'єднані в логічну групу - director, у разі використання директорів при виході з ладу одного з бекендів запити будуть автоматично перенаправлені на живі бекенди з поточного директора. У нашому випадку балансування робиться на рівні nginx, і ця можливість Варніша не використовується.
Status.php ми запозичили у Лулаботів, завантажити його можна тут. У цьому файліздійснюється перевірка доступності серверів БД та Мемкешу.
Створюємо списки айпішників, на основі яких пізніше задамо обмеження доступу до cron.php та очищення кешу Варніша:
Процедура vcl_recv містить інструкції, які будуть виконуватися Варнішем під час отримання запиту від клієнта. У ній міститься основна магія. В основному ця процедура повинна повертати одне з двох значень: pass — передати запит бекенду або lookup — спробувати знайти версію сторінки в кеші, що закешує, у разі відсутності кеша, запит буде переданий бекенду, а відповідь закешована. Повний список можливих значень можна знайти тут: https://www.varnish-cache.org/docs/3.0/reference/vcl.html#subroutines, а тут: https://www.varnish-cache.org/docs/3.0 /faq/configuration.html дано опис відмінностей значень pass та pipe.
Код вище вимагає певного пояснення.
Куки являють собою текстовий рядок виду "ключ = значення" розділені точкою з комою. Наприклад розглянемо рядок "name1=val1; name2=val2; name3=val3;". Припустимо, ми хочемо пропустити далі тільки куку name2. Наведений вище код робить таке:
Accept-Encoding
Далі наводимо до загального вигляду заголовок "Accept-Encoding". Цей заголовок використовується браузером, щоб повідомити серверу, які типи стиснення він підтримує. Веб-сервер, отримавши такий заголовок, може (і, по-доброму, повинен) заархівувати дані, що віддаються тим алгоритмом, який підтримується браузером.
Якщо одна і та ж сторінка запитується різними браузерами, що передають різний заголовок "Accept-Encoding" Варніш повинен у своєму кеші створити кілька копій однієї і тієї ж сторінки, інакше, якщо, наприклад, браузер підтримує лише алгоритм стиснення deflate, а дані в кеші Варніша стиснуті алгоритмом gzip, браузер,отримавши такі дані, не зможе їх розпакувати.
Проблема в тому, що різні браузери, що підтримують той самий алгоритм стиснення, повідомляють про нього серверу по-різному, наприклад, Хром це робить так: "Accept-Encoding:gzip,deflate,sdch", а Firefox так: "Accept-Encoding : gzip, deflate". За умовчанням, для цих двох заголовків Варніш створив би різні копії кеша однієї сторінки. Код нижче, наводить подібні заголовки до універсального вигляду і запобігає зайвому витраті пам'яті під кеш.
От і все. Конфіг містить більше налаштувань, ніж я описав у цьому тексті, але інші не такі цікаві і, гадаю, їхній зміст має бути інтуїтивно зрозумілим.