Пример за конфигурационен файл на Varnish, Romka! ЕС
Както обещах в доклада, публикувам пример и описание на работещата конфигурация за Varnish. За да научите повече за това какво е Varnish и защо имате нужда от него, вижте секцията Pressflow + Varnish.
Този пример разглежда конфигурацията за Varnish версия 3 (в момента най-новата стабилна версия). Моля, обърнете внимание, че след версия 2.1.0 Varnish промени двигателя за обработка на регулярни изрази, така че някои примери за конфигурации, налични в Интернет, може да не работят правилно. Lullabots, например, актуализираха своя урок и предлагат няколко опции за конфигурация за различни версии на Varnish наведнъж.
Можете да изтеглите моята конфигурация тук, по-долу е описание на най-интересните и важни части.
Указваме на Varnish с кой уеб сървър да работи. Параметрите в блока за сонда означават, че на всеки 5 секунди в бекенда трябва да изтеглите файла status.php. Ако в рамките на 1 секунда от бекенда не бъде получен отговор с код 200, тогава проверката ще се счита за неуспешна. Ако 3 от 5 проверки са неуспешни, бекендът се маркира като „неактивен“.
По този начин, в рамките на 15 секунди след възникване на проблеми в бекенда, Varnish ще го маркира като паднал и в зависимост от настройките или ще започне да прехвърля заявки към друг бекенд, или ще започне да обслужва заявки от регистрирани потребители от своя кеш.
Няколко бекенда могат да бъдат комбинирани в логическа група - директор, ако се използват директори, ако един от бекендовете не успее, заявките автоматично ще бъдат пренасочени към живи бекендове от текущия директор. В нашия случай балансирането се извършва на ниво nginx и тази функция Varnish не се използва.
Взехме назаем Status.php от Lullabots, можете да го изтеглите тук. В този файлпроверява се наличността на DB и Memkesh сървърите.
Създаваме IP списъци, въз основа на които по-късно ще зададем ограничения за достъп до cron.php и ще изчистим Varnish кеша:
Процедурата vcl_recv съдържа инструкции, които Varnish ще изпълни при получаване на заявка от клиент. Той съдържа основната магия. По принцип тази процедура трябва да върне една от двете стойности: pass – предаване на заявката към бекенда или търсене – опит за намиране на кешираната версия на страницата в кеша, ако няма кеш, заявката ще бъде предадена на бекенда и отговорът ще бъде кеширан. Пълен списък с възможни стойности можете да намерите тук: https://www.varnish-cache.org/docs/3.0/reference/vcl.html#subroutines, а тук: https://www.varnish-cache.org/docs/3.0/faq/configuration.html е дадено описание на разликата между стойностите на пропускане и канала.
Кодът по-горе се нуждае от известно обяснение.
Бисквитките са текстов низ във формата "ключ=стойност", разделени с точка и запетая. Например, разгледайте низа "name1=val1; name2=val2; name3=val3;". Да кажем, че искаме да пропуснем само името на бисквитката2. Горният код прави следното:
Приемане на кодиране
След това пренасяме в общата форма заглавката „Приемане-кодиране“. Този хедър се използва от браузъра, за да каже на сървъра какви видове компресия поддържа. Уеб сървърът, след като получи такъв хедър, може (и, за добро, трябва) да архивира дадените данни с алгоритъма, който се поддържа от браузъра.
Ако една и съща страница е поискана от различни браузъри, предавайки различна заглавка "Accept-Encoding", Warnish трябва да създаде множество копия на същата страница в своя кеш, в противен случай, ако например браузърът поддържа само алгоритъма за компресиране на deflate и данните в кеша на Warnish са компресирани с gzip, браузърът,след като получи такива данни, той няма да може да ги разопакова.
Проблемът е, че различните браузъри, които поддържат един и същ алгоритъм за компресиране, го докладват на сървъра по различни начини, например Chrome го прави така: „Accept-Encoding: gzip, deflate, sdch“, а Firefox така: „Accept-Encoding: gzip, deflate“. По подразбиране за тези две заглавки Warnish ще създаде различни кеширани копия на една и съща страница. Кодът по-долу привежда такива заглавки в универсална форма и предотвратява ненужното потребление на памет за кеша.
Това е всичко. Конфигурацията съдържа повече настройки, отколкото описах в този текст, но останалите не са толкова интересни и мисля, че значението им трябва да е интуитивно.