Varnish - настройка и эксплуатация

apt-get install varnish

После установки появится список доступных утилит:

varnishadm — для администрирования varnishd-демона;
varnishhist — гистограмма запросов;
varnishlog — журнал работы;
varnishncsa — отражает логи в Apache / NCSA формате;
varnishstat — статистика использования кэша;
varnishtest — тестовая утилита;
varnishtop — топовая статистика по использованию кэша.

Настройка Varnish

Установки параметров запуска демона производится в файле /etc/default/varnish. Первоначально он сконфигурирован с некоторыми параметрами. Если открыть файл, то увидим внутри три готовые настройки: minimal, c VCL и advanced.

По умолчанию активирован второй режим. При этом сервер принимает подключения на порт 6081, для администрирования используется localhost:6082, а бэкэнд определяются в VCL. Для кэширования выделяется 256 Мб памяти. Настроим так чтобы Varnish слушал 80 порт, кэшируя запросы HTTP сервера расположенного на этой же машине. Комментируем настройки 2 варианта и в качестве шаблона будем использовать Advanced, как более наглядный.

# Запускать демон varnishd при загрузке системы.
START=yes
# Максимальное количество открытых файлов (для ulimit -n)
NFILES=131072
# Максимальное количество залоченной памяти (for ulimit -l) для блокировки разделяемой памяти лога
# при необходимости следует увеличить размер
MEMLOCK=86000
# По умолчанию экземпляр сервера получает имя текущего узла. При запуске нескольких экземпляров  его можно переопределить при помощи -n или 
# INSTANCE=$(uname -n)

# по умолчанию слушаются все интерфейсы, но можем указать IP
# VARNISH_LISTEN_ADDRESS=
# порт на котором принимаются подключения
VARNISH_LISTEN_PORT=80

# Админ интерфейс IP и порт
VARNISH_ADMIN_LISTEN_ADDRESS=127.0.0.1
VARNISH_ADMIN_LISTEN_PORT=6082
# VCL файл 
VARNISH_VCL_CONF=/etc/varnish/default.vcl

DAEMON_OPTS="\
-a ${VARNISH_LISTEN_ADDRESS}:${VARNISH_LISTEN_PORT} \
-f ${VARNISH_VCL_CONF} \
-T ${VARNISH_ADMIN_LISTEN_ADDRESS}:$	{VARNISH_ADMIN_LISTEN_PORT} \

Это основные установки. С остальными можно познакомиться в файле или в документации проекта.

Теперь осталось указать Varnish, где находится HTTP-сервер. В /etc/default/varnish это можно сделать при помощи ключа -b (-b localhost:8080), но удобнее для этого использовать VCL файл, который указан в переменной VARNISH_VCL_CONF (в сырцах есть пример example.vcl). Открываем и смотрим, чтобы внутри была инструкция:

$ sudo nano /etc/varnish/default.vcl

backend apache {
	.host = "127.0.0.1";
	.port = "8080";
}

Минимальные установки готовы. Перезапускаем Varnish: sudo service varnish start

Продвинутые настройки Varnish

Это самый простой пример и как видим заставить Varnish кэшировать запросы очень легко, но он пока не «разбирается» и не вмешивается в трафик. Познакомившись с VCL можно расширить базовые возможности. Параметров которые можно настроить очень много и чтобы их описать потребуется книга. VCL это язык программирования в котором найдем все что присуще — переменные, функции, комментарии и т.п. Вариантов использования много и сходу их освоить не получится. В качестве отправной точки можно рекомендовать документацию проекта, в частности Varnish Book. Также в Сети уже есть достаточно шаблонов под разные ситуации подготовленных самими пользователями. Они являются хорошим подспорьем по изучению возможностей VCL.
Varnish способен работать с несколькими HTTP-серверами (бэкендами). Каждый определяется аналогично примеру выше:

backend server1 {
    .host = "10.0.0.11";
}
backend server2 {
	.host = "10.0.0.12";
}

После чего можно строить правила указывая сервера по имени. Если бэкенды равнозначны и используются только для распределения нагрузки, то достаточно сообщить об этом Varnish с помощью директивы “director”:

director balanced_servers round-robin {
    {
        .backend = server1;
    }
    {
        .backend = server2;
    }
}

Можно также использовать случайный выбор – для этого вместо “round-robin” необходимо прописываем “random”.
Возможна реализация и более сложных алгоритмов. Но для этого нужно познакомиться с возможностями VCL файлов.
В default.vcl мы увидим несколько именованных блоков (функций). По умолчанию параметры внутри отсутствуют, вот именно с их помощью и производится тонкая настройка кэширования. Кое-что можно установить не вникая в работу приложений на веб-сервере, в более сложных случаях потребуется глубокий анализ выдаваемых страниц (проект предоставляет некоторые утилиты о которых дальше).
Разберем некоторые из них. Порядок вызова функций наглядно показан в разделе VCL Basics, некоторые вопросы конфигурирования есть в документации.
Списки ACL позволяют управлять доступом к определенным URL или вручную распределять или обрабатывать запросы некоторых клиентов. Создадим правило которое включает все локальные узлы.

acl local {
	"localhost";
	"192.168.1.0"/24;
	! "192.168.1.10"; 
}

Как видим разрешается инвертирование при помощи «!» т.е. 192.168.1.10 не попадает под правило. Теперь к этому списку можем обратиться при помощи конструкции (client.ip ~ local)
Функция vcl_recv вызывается при получении запроса и перед проверкой данных в кэше. Именно здесь можно модифицировать запрос, удалить Cookie, произвести нормализацию, выбрать бэкэнд в зависимости от запроса и т.д.
По умолчанию Varnish не кэширует запросы с установленными Cookie. Для статических страниц, лучше активировать такую возможность, для этого просто вырезаем Cookie. Также для примера запретим доступ к файлам cron.php и install.php для всех узлов кроме локальных и скажем Varnish, чтобы он перенаправлял все запросы к update.php сразу на бэкэнд.

sub vcl_recv {
	set req.backend = apache
	if (req.url ~ "\.(css|js|png|gif|jp(e)?g)")
	{ 
		unset req.http.cookie; 
	}
	return (lookup); 
	if (req.url ~ "^/(cron|install)\.php$" && !client.ip ~ 	local) 
	{
		error 404 "Page not found.";
	}
    if (req.url ~ "^/update\.php$"
    	return (pass);
    }
}

Это конечно не все что можно сделать. Используя req.http.User-Agent можем распределять бэкенды в зависимости от браузера/устройства клиента.
Функция return в случае с vcl_recv может принимать аргументы: lookup — указывает на необходимость поиска в кэше, pass — сразу отправляет запрос на бэкэнд. Последнее как видим позволяет избежать кэширования определенных типов файлов, например медиа или постоянно обновляющегося контента.
Некоторые функции вызывают пустыми, просто чтобы пропустить определенную проверку указав нужный код возврата. Кроме указанных выше возможны варианты — deliver, fetch, hash, pipe, error, restart, retry.
Функция vcl_hash позволяет определить уникальность запроса, который будет кэшироваться. По умолчанию хэш формируется на основании URL и IP/имени сервера. В большинстве случаев этого достаточно, но в некоторых ситуациях этого не хватает и возможно потребуется изменение правил. Например, для определения уникальности используют Сookie.
Функция vcl_error позволяет генерировать контент не обращаясь к веб-серверу, используется для выдачи сообщений об ошибках и редиректа.
Далее в зависимости от ситуации запрос обрабатывается vcl_fetch, vcl_pass и vcl_miss. В 4.0 они заменены более удобные функции vcl_backend_fetch и vcl_backend_response, которые вызываются перед передачей запроса серверу и после получения ответа, соответственно.
В следующем примере мы убираем выставление cookie для файлов изображений, а также задаем время жизни кэшированного содержимого для этих файлов в 1 час.

sub vcl_backend_response {
	if (bereq.url ~ "\.(png|gif|jpg)$") {
		unset beresp.http.set-cookie;
		set beresp.ttl = 1h;
	}
}

И перед отправкой полученных от бэкэнда данных вызывается функция vcl_deliver. В простейшем случае она пустует, то есть ответ передается без изменений. Но здесь можно при желании модифицировать заголовки. Для примера просто удалим все упоминания о Varnish:

sub vcl_deliver {
	remove resp.http.X-Varnish;
	remove resp.http.X-Powered-By;
}

Это конечно далеко не все возможности, но нужно идти дальше.

Управление Varnish

Работой Varnish можно управлять и отслеживать результат. Для этого в поставке идет несколько утилит начинающихся с varnish*. Все они описаны в разделе «Appendix A: Varnish Programs» Varnish Book. Основной утилитой является varnishadm. Именно с ее помощью производится администрирование, просмотр статуса и ошибок, загрузка модулей «на лету». Принцип работы очень прост. Вызываем: sudo varnishadm После чего появится приглашение Varnish CLI. Чтобы получить список команд следует ввести «help». Команд не много (23), значение большинства понятно из названия. Подробности по каждой можно получить введя «help команда«. Например, группа команд vcl.* позволяют просматривать и управлять загрузкой, выгрузкой модулей. Смотрим список модулей: varnish> vcl.list

Команды param.show и param.set позволяют просматривать и изменять параметры сервиса, panic.show и panic.clear — отображать и очищать ошибки, ban и ban.list — указывать страницы не подлежащие кэшированию. И так далее.
Две команды varnishtop и varnishhist очень помогают при первоначальной настройки т.к. позволяют просмотреть список наиболее часто встречающихся параметров (URL, идентификаторы, статус и т.д.). Первая утилита выводит их в виде top, вторая как гистограмму. При запросе можно использовать регулярные выражения, поэтому потеряться в большом количестве страниц невозможно. Например, просмотрим список наиболее запрашиваемых URL и заголовки:

$ varnishtop -i RxUrl
$ varnishtop -i RxHeader

Еще три очень полезных утилиты позволяющие просмотреть статистику (varnishstat), и информацию в журналах (varnishlog и varnishncsa). Скрипт varnishtest дает возможность проверить работу кэша Varnish.
Для тех кто не хочет разбираться с командной строкой разработчик предлагают веб-интерфейс Varnish Administration Console (varnish-software.com/resources/vac-demo) — очень удобный инструмент предлагающий произвести все описанные операции и получать статистику в наглядном виде.

Правда есть минус — доступен он только в коммерческой версии Varnish Plus.
Бесплатное ПО пока не богато вариантами. Плагины поддерживающие Varnish есть в системах мониторинга Collectd, Nagios, Cacti и других. Список известных проектов можно найти на сайте.

Полезные ссылки:

FOSHttpCacheBundle

К сожалению следующее описание со страницы не раскрывает смысл и вообще потребность в этом бандле мне непонятна, т.к. сам Symfony уже вроде как поддерживает ESI но разве что для мгновенной инвалидации кэша.

Клиент запрашивает /foo
Прокси-сервер получает запрос и удерживает его. Сначала он отправляет хэш запрос контекстному хеш-маршруту.
Приложение получает хэш запрос. UserContextListener прерывает запрос сразу после применения брандмауэра Symfony. Приложение вычисляет хэш ( HashGenerator), а затем отправляет ответ с хешем в пользовательском заголовке ( X-User-Context-Hash по умолчанию).
Кэширующий прокси-сервер получает хеш-ответ, копирует хеш-заголовок в исходный запрос клиента /foo и снова отправляет этот запрос.
Если ответ /foo должен отличаться в зависимости от пользовательского контекста, приложение устанавливает заголовок. Затем клиенту будет возвращено соответствующее представление, зависящее от пользовательского контекста .Vary: X-User-Context-Hash/foo

Как работает User Context :

выполняется предварительный запрос — это запрос, который отправляется до реального запроса. Посмотрите, например, как работают запросы CORS . Результатом предварительного запроса является X-User-Context-Hash заголовок, который добавляется к реальному запросу.

Эту концепцию можно обобщить, чтобы обрабатывать больше, чем сценарий пользовательского контекста. Terminal42/header-replay-bundle строится поверх FOSHttpCacheBundle для добавления поддержки более сложных вариантов использования. Посмотрите документацию HeaderReplayBundle , если пользовательский контекст недостаточно гибок для ваших нужд.

11.09.2021 07:08

Varnish - настройка и эксплуатация

Настройка Varnish

Продвинутые настройки Varnish

Управление Varnish

FOSHttpCacheBundle

Комментарии