Old-Site, Работа, Drupal, Varnish 25 июня 2012

Пример конфигурационного файла Varnish

Как обещал в докладе выкладываю пример и описание рабочего конфига для Варниша. Чтобы узнать подробнее о том, что такое Варниш и для чего он нужен ознакомьтесь с разделом Pressflow + Varnish.

Сразу сделаю важный комментарий. Прежде чем запускать Варниш на боевом сервере разработчик должен детально изучить его документацию, понять основные принципы его работы и настройки. Слепое копирование чужих конфигов, без понимания того, что делает та или иная инструкция, может привести к плачевным результатам.

В этом примере рассматривается конфиг для Варниша третьей версии (на данный момент это последняя стабильная версия). Обратите внимание, у Варниша с версии 2.1.0 поменялся движок обработки регулярных выражений, по этому некоторые примеры конфигов, доступные в интернете, могут работать некорректно. Луллаботы, например, обновили свой туториал и предлагают сразу несколько вариантов конфига для разных версий Варниша.

Задача

Варниш должен отдавать анонимам данные из своего кеша, а запросы от авторизованных пользователей передавать бэкенду. Отличать анонимного пользователя от зарегистрированного Варниш будет по наличию/отсутствию куки SESS*. В случае падения бэкенда Варниш должен отдавать кеш в том числе и для авторизованных пользователей.

Скачать мой конфиг вы можете здесь, ниже описание самых интересных и важных его частей.

Бэкенд

Указываем Варнишу с каким веб-сервером нужно работать. Параметры в блоке probe означают, что каждые 5 секунд на бэкенде нужно дергать файл status.php. Если в течение 1 секунды от бэкенда не будет получен ответ с кодом 200, то проверка будет считаться провалившейся. Если провалено 3 проверки из 5, бэкенд помечается “упавшим”.

backend web1 {
    .host = "10.10.10.10";
    .port = "80";
    .probe = {
    .url = "/status.php";
    .interval = 5s;
    .timeout = 1s;
    .window = 5;
    .threshold = 3;
}

Таким образом, уже через 15 секунд после возникновения проблем на бэкенде, Варниш пометит его упавшим и, в зависимости от настроек, либо начнет передавать запросы другому бэкенду, либо начнет обслуживать запросы зарегистрированных пользователей из своего кеша.

Несколько бэкендов могут быть объединены в логическую группу — director, в случае использования директоров при выходе из строя одного из бэкендов запросы будут автоматически перенаправлены на живые бэкенды из текущего директора. В нашем случае балансировка делается на уровне nginx и эта возможность Варниша не используется.

Status.php мы позаимствовали у Луллаботов, скачать его можно тут. В этом файле осуществляется проверка доступности серверов БД и Мемкеша.

ACL

Создаем списки айпишников, на основе которых позже зададим ограничение доступа к cron.php и очистке кеша Варниша:

# ACL for purging cache
acl purge {
    "127.0.0.1";
    "localhost";
    "10.1.0.0"/16;
}

# ACL for access to cron.php
acl internal {
    "127.0.0.1";
    "localhost";
    "10.10.0.0"/16;
}

vcl_recv

Процедура 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.

Для начала отключаем обработку Варнишем некоторых служебных адресов Друпала:

// list of URLS which shouldn't be cached
if (req.url ~ "^/status\.php$" ||
    req.url ~ "^/update\.php$" ||
    req.url ~ "^/info/.*$" ||
    req.url ~ "^/flag/.*$" ||
    req.url ~ "^.*/ajax/.*$" ||
    req.url ~ "^.*/ahah/.*$") {
        return (pass);
}

Доступ

Далее, ограничиваем доступ к операции очистки кеша и cron.php на основе ранее определенных списков ip-адресов.

# Clear cache entry
if (req.request == "PURGE") {
    if (!client.ip ~ purge) {
        error 405 "Not allowed.";
    }
    return (lookup);
}

# Do not allow outside access to cron.php or install.php.
if (req.url ~ "^/(cron|install)\.php$" && !client.ip ~ internal) {
    # Have Varnish throw the error directly.
    error 404 "Page not found.";
    # Use a custom error page that you've defined in Drupal at the path "404".
    #set req.url = "/404.html";
}

Задаем максимальное время жизни кеша 6 часов, а также указываем, что если сервер помечен как “упавший” (опция probe в настройках бэкенда), то у пользователя нужно отрезать все куки. В дальнейшем, для пользователей без кук мы будем отдавать кеш и эта настройка позволит Варнишу отдавать кеш авторизованным юзерам.

set req.grace = 6h;

if (!req.backend.healthy) {
    unset req.http.Cookie;
}

cookies

Далее анализируем куки, полученные от пользователя, и удаляем ненужные. Дело в том, что куки могут быть установлены как серверным софтом, так и клиентским, через java-script. Разного рода счетчики и коды баннеров ставят куки для своих целей и эти куки совершенно не интересны серверу, кроме того они мешают нам отличить анонимного посетителя от зарегистрированного. Мы удаляем все куки кроме SESS*, если после такого удаления у нас осталась пустая строка, значит куки SESS* нет и мы считаем пользователя анонимным и можем отдать ему данные из кеша. Если кука SESS* существует, то мы передаем запрос бэкенду.

// clean cookies. Pass only cookies SESS[a-z0-9], xyz
if (req.http.Cookie) {
set req.http.Cookie = regsub(req.http.Cookie, "^(.*)$", "; \1");
set req.http.Cookie = regsuball(req.http.Cookie, "; +", ";");
set req.http.Cookie = regsuball(req.http.Cookie, ";(SESS[a-z0-9]|xyz+)=", "; \1=");
set req.http.Cookie = regsuball(req.http.Cookie, ";[^ ][^;]*", "");
set req.http.Cookie = regsuball(req.http.Cookie, "^[; ]+|[; ]+$", "");

    if (req.http.Cookie == "") {
      unset req.http.Cookie;
    }
    else {
      return (pass);
    }
}

Код выше требует некоторого пояснения.

Куки представляют из себя текстовую строку вида “ключ=значение” разделенные точкой с запятой. Для примера рассмотрм строку name1=val1; name2=val2; name3=val3;. Предположим, мы хотим пропустить далее только куку name2. Приведенный выше код делает следующее:

  • сначала, для служебных целей, добавляет точку с запятой перед этой строкой. Наша тестовая строка примет вид ;name1=val1; name2=val2; name3=val3;.
  • Затем удаляет пробелы после всех точек с запятой (; заменяет на ;). Тестовая строка примет вид: ;name1=val1;name2=val2;name3=val3;.
  • Далее перед разрешенными куками добавляет пробел. Если быть точнее, то пробел добавляется между именем разрешенной куки и точкой с запятой идущей перед ним, именно для этого на первом шаге в начало строки добавлена точка с запятой, чтобы если разрешенная кука идет на первом месте, чтобы можно было перед ней воткнуть пробел. Теперь вся строка имеет вид ;name1=val1; name2=val2;name3=val3; (перед разрешенной кукой name2 добавлен пробел).
  • Теперь удаляются все записи, которые начинаются не с ; . Вот это регулярное выражение: ;[^ ][^;]* можно словами озвучить так: все строки первый символ в которых “точка с запятой”, второй символ не пробел, затем идет любое число символов кроме точек с запятой нужно заменить на ``.
  • Последняя строка удаляет лидирующую точку с запятой, добавленную на первом шаге.

В итоге, если после таких преобразований у нас осталась не пустая строка, то значит кука SESS* у пользователя есть и его запрос надо передать бэкенду. Как я уже говорил выше, в случае, если бэкенд отмечен как упавший, мы удаляем из запроса пользователя информацию о куках и любой запрос, даже от авторизованного юзера, будет обслуживаться как анонимный.

Accept-Encoding

Далее приводим к общему виду заголовок Accept-Encoding. Этот заголовок используется браузером, для того чтобы сообщить серверу какие типы сжатия он поддерживает. Веб-сервер, получив такой заголовок, может (и, по хорошему, должен) заархивировать отдаваемые данные тем алгоритмом, который поддерживается браузером.

Если одна и та же страница запрашивается разными браузерами, передающими разный заголовок “Accept-Encoding” Варниш должен в своем кеше создать несколько копий одной и той же страницы, иначе, если, например, браузер поддерживает только алгоритм сжатия deflate, а данные в кеше Варниша сжаты алгоритмом gzip, браузер, получив такие данные, не сможет их распаковать.

Проблема в том, что разные браузеры, поддерживающие один и тот же алгоритм сжатия, сообщают о нем серверу по разному, например, Хром это делает так: Accept-Encoding:gzip,deflate,sdch, а Firefox так: Accept-Encoding: gzip, deflate. По умолчанию, для этих двух заголовков Варниш создал бы разные копии кеша одной и той же страницы. Код ниже, приводит подобные заголовки к универсальному виду и предотвращает излишний расход памяти под кеш.

if (req.http.Accept-Encoding) {
    if (req.http.Accept-Encoding ~ "gzip") {
        # If the browser supports it, we'll use gzip.
        set req.http.Accept-Encoding = "gzip";
    }
    else if (req.http.Accept-Encoding ~ "deflate") {
        # Next, try deflate if it is supported.
        set req.http.Accept-Encoding = "deflate";
    }
    else {
        # Unknown algorithm. Remove it and send unencoded.
        unset req.http.Accept-Encoding;
    }
}

Вот и всё. Конфиг содержит больше настроек, чем я описал в этом тексте, но остальные не такие интересные и, думаю, их смысл должен быть интуитивно понятен.