Переносим сайты на HTTPS с помощью Nginx, Varnish и Apache | Блог про WordPress

Переносим сайты на HTTPS с помощью Nginx, Varnish и Apache | Блог про WordPress Хостинг
Содержание
  1. Что такое varnish?
  2. Что такое демон?
  3. 1: подготовка веб-сервера к запуску varnish
  4. 3: настройка varnish
  5. 4: проверка состояния приложения
  6. Cache hit в varnish’е
  7. Drupal 8 cache api
  8. Varnish cache и nginx cache: сравнение производительности
  9. Varnish hosting — fastest nvme servers | rosehosting
  10. Varnish или nginx?
  11. Varnish: бесплатный кэш-сервер, повышающий производительность вашего веб-сайта
  12. Где научиться работать с виртуальными хостами apache?
  13. Гибкость
  14. Дебаггинг информация в drupal watchdog
  15. Еще раз о cache api в drupal 8
  16. Как выбрать порт?
  17. Как узнать дистрибутив linux и его версию?
  18. Канал коммуникации drupal → varnish
  19. Который лучший?
  20. Связанные статьи:
  21. Масштабирование
  22. Моя тестовая среда
  23. Настраиваем ssl для сайтов в nginx
  24. Настройка drupal 8
  25. Настройка varnish
  26. Продвинутые настройки
  27. Размер очереди на инвалидацию
  28. Расширяем cache api на varnish
  29. Редирект к ssl с помощью varnish
  30. Создаем или устанавливаем ssl-сертификат
  31. Сравнение varnish cache и nginx cache
  32. Управление varnish
  33. Управление статическим контентом
  34. Установка nginx
  35. Вывод
  36. Подводя итоги

Что такое varnish?

Varnish Cache обслуживает статический или квазистатический контент напрямую, без передачи запроса на веб-сервер (то есть Apache). Поскольку большое количество контента необходимо вычислить и сгенерировать только один раз, сохранение и последующее обслуживание из памяти быстрого доступа значительно уменьшает нагрузку на веб-сервер и увеличивает количество запросов, которые может одновременно обрабатывать система.

Varnish может увеличить скорость (в зависимости от архитектуры) и надежность практически любого сайта. Это делает сайт более дружественным к пользователям.

: Если вы не используете отдельный экземпляр сервера приложений для Varnish (что настоятельно рекомендуется сделать), технически это не будет масштабированием, но положительно повлияет на системную архитектуру. Конечно, это можно назвать в некотором роде масштабированием, так как это увеличит общую производительность системы и нагрузку, которую может обработать сервер, в результате получается системная архитектура, которая готова к масштабированию.

Что такое демон?

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

Tags:

1: подготовка веб-сервера к запуску varnish

Varnish должен быстро обслуживать страницы прямо из памяти. Этот процесс называется кэшированием. Для того, чтобы это сработало, Varnish должен обрабатывать входящие запросы. Учитывая, что веб-сервер (например, Apache) делает то же самое (обрабатывает входящие запросы), нужно внести некоторые изменения для того, чтобы Varnish смог занять его место. Для этого нужно изменить порт, который он прослушивает (т. е. порт 80).

По умолчанию Apache слушает порт 80.

Отредактируйте параметры в файле ports.conf в каталоге /etc/apache2/.

Откройте файл в редакторе:

sudo nano /etc/apache2/ports.conf

В файле содержатся примерно такие строки:

NameVirtualHost *:80Listen 80<IfModule mod_ssl.c># If you add NameVirtualHost *:443 here, you will also have to change# the VirtualHost statement in /etc/apache2/sites-available/default-ssl# to <VirtualHost *:443>

Измените первые две строки, где указан номер порта. Вместо стандартного порта 80 можно использовать, скажем, 8000 (запомните этот номер):

NameVirtualHost *:8000Listen 8000

Сохраните и закройте файл (CTRL X, Y и enter).

Если ваш сервер обслуживает несколько сайтов или на нем установлены индивидуальные параметры домена, у вас, вероятно, есть виртуальные хосты. Эти файлы тоже нужно обновить.

Откройте файл виртуального хоста в редакторе:

sudo nano /etc/apache2/sites-availbable/my-domain-dot-com

Примечание: Вместо my-domain-dot-com укажите имя своего сайта. Если у вас нет пользовательского виртуального хоста, откройте файл по умолчанию, /etc/apache2/sites-available/default.

В зависимости от текущих настроек вы увидите документ, который начинается так:

Здесь нужно указать новый порт:

Сохраните и закройте файл.

Чтобы обновить настройки, перезапустите Apache:

sudo service apache2 reload

Теперь веб-сервер принимает входящие соединения по порту 8000.

3: настройка varnish

По умолчанию Varnish не работает по порту 80, и это нужно изменить.

Конфигурационный файл в Debian и Ubuntu находится в /etc/default/varnish.

Откройте файл в редакторе:

nano /etc/default/varnish

После этого на экране вы увидите довольно длинный, но очень простой документ. Найдите блок DAEMON_OPTS, который определяет параметры демона Varnish:

DAEMON_OPTS=»-a :6081 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m»

Измените порт 6081 на 80:

DAEMON_OPTS=»-a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m»

Varnish использует файл .vcl (по умолчанию он находится в /etc/varnish/), который содержит инструкции по запуску программы, написанные на языке VCL. Этот файл определяет, как Varnish будет обрабатывать запросы и как должна работать система кэширования документов.

Файлы VCL сначала могут показаться сложными, поскольку они позволяют определить большое количество задач. К счастью, сайт проекта предоставляет много полезных примеров.

Для Drupal можно использовать следующие параметры. Скопируйте и вставьте строки, представленные ниже, в файл .vcl.

nano /etc/varnish/default.vcl

Открыв файл, вы увидите длинный документ с параметрами по умолчанию.

Для начала нужно определить параметры веб-сервера и настроить его взаимодействие с Varnish. Отредактируйте раздел backend default:

backend default {.host = «127.0.0.1»;.port = «8000»;.max_connections = 250;.connect_timeout = 300s;.first_byte_timeout = 300s;.between_bytes_timeout = 300s;}

Примечание: Ниже вы найдете большой закомментированный блок стандартного кода конфигураций VCL. Будьте внимательны, не раскомментируйте его по ошибке, иначе при компиляции возникнут ошибки.

Затем добавьте белый список адресов:

4: проверка состояния приложения

Запустите следующие команды, чтобы убедиться, что Apache и Varnish привязаны к правильным портам.

# Apache:netstat -lp | grep apache2# Varnish:netstat -lp | grep varnish

Вы получите примерно такой вывод:

Cache hit в varnish’е

Не нужно верить теории. После проделанной работы, лучше перепроверить на практике факт, что Varnish правильно кеширует анонимные HTML страницы! Если ваш Varnish изначально не вставляет заголовки о cache hit в свои ответы, то достаточно добавить в

vcl_deliver

Drupal 8 cache api

К счастью, дела обстоят куда лучше в Drupal 8, где была добавлена система гибкого кеширования через мета-информацию. Я настоятельно рекомендую любопытным почитать

Varnish cache и nginx cache: сравнение производительности

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

Применяя различные методы, такие как оптимизация изображений, интеграция сети доставки контента (CDN), использование правильного кэширующего сервера и т. д., владельцы сайтов постоянно стремятся увеличить время загрузки страниц своих сайтов. Хотя все эти меры в совокупности полезны, цель обсуждения в этой статьи — уделить особое внимание кешированию.

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

Varnish hosting — fastest nvme servers | rosehosting

Whether your website is growing in popularity and needs to accommodate more visitors at a single time, or you have a lot of content on your pages that take a while to load, our Managed Varnish Hosting services will provide you with the speed and responsiveness that you’ve been looking for from your websites. While having a properly configured and optimized caching system is important in improving the speeds of your websites, the server hardware itself also plays an important part in general performance. That’s why we use the latest-generation Intel Xeon processors, paired with the fastest enterprise-grade NVMe and DDR4 memory — our hardware allows for your server to perform at its peak performance at all times.

Speed is important, but a fast website is pointless if the uptime is unreliable. To combat this, all of our hardware is fully redundant, including the power, storage, and networking. This allows us to provide our 99.99 % uptime guarantee. That’s only the tip of the iceberg, too — we look after the hardware meticulously, but that’s only part of what we do. We make sure that your OS and all of the software running with it stays online 100% of the time, no matter what.

Our in-depth tech support doesn’t stop there, either. We can actually help optimize your Varnish setup and make your website as fast as possible. We can also help troubleshoot any problems that you may be having — if you need help with upgrading the Varnish version, modifying Varnish rules, applying new rules, clearing Varnish cache or purging specific objects from the Varnish cache, we can do all of that and so much more. In a nutshell, we make sure that everything is running as perfectly as it can, 24/7.

Even though our support is one of the best in the hosting industry, that doesn’t mean that we will force you to give us complete control over anything on your server. In fact, we provide full root access on all of our servers. This provides you with the power and flexibility of a complete Linux server, complete with full administrative access to everything. And if anything breaks for any reason — don’t worry, we’re here to fix it whenever you need us to. We’re one of the only hosting providers in the industry that does this, if not the only hosting provider that gives you complete access with fully-managed support.

The no-upsell policy that we strictly follow as a hosting provider ensures that you are always paying one amount for as long as you keep your Varnish VPS hosting plan with us. We don’t hide our true prices on tricky web pages and fine print, and we don’t show promotional prices as if they are our real prices. We show you the real price you will be paying every month for the plan you choose. That’s transparent pricing done right.

Varnish или nginx?

На практике трудно провести сравнение Varnish и NGINX. Потому что основы Varnish и NGINX очень похожи; оба могут использоваться в качестве обратного прокси и балансировщика нагрузки для вашего сервера. Однако, если мы углубимся в их технологии, есть несколько конкретных аспектов производительности Varnish по сравнению с NGINX Cache, которые можно сопоставить друг с другом.

Varnish: бесплатный кэш-сервер, повышающий производительность вашего веб-сайта

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

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

Varnish легко установить, и использовать даже при стандартной конфигурации

Varnish может напомнить вам о мощном моющем средстве, но на самом деле это невероятно эффективный инструмент кэширования данных. Если задуматься, то varnish (пер. – полировка) – это именно то, что с нашими сайтами делают инструменты кэширования. Разработчики обещают увеличение скорости работы от 300 до 1000 раз. Varnish нацелен на, в отличие от других похожих инструментов, HTTP, и именно такие изменения может почувствовать средний посетитель. Многим может показаться, что использовать Varnish невероятно просто.

На самом деле, чтобы использовать Varnish, вам потребуется веб-сервер (а как иначе?), который работает на базе Linux. Корневая папка понадобится только в процессе установки. Так как Varnish хранит весь кэш в памяти, вам потребуется довольно много памяти – чем больше, тем лучше. Здесь нет какого-либо технического минимума, но мы бы рекомендовали вам как минимум иметь 2гб ОЗУ (даже для небольших проектов).

Проект предлагает вам готовые к установке дистрибутивы.

Ubuntu

curl http://repo.varnish-cache.org/debian/GPG-key.txt | sudo apt-key add -
echo "deb http://repo.varnish-cache.org/ubuntu/ precise varnish-3.0" | sudo tee -a /etc/apt/sources.list
sudo apt-get update
sudo apt-get install varnish

CentOS/Fedora

rpm --nosignature -i http://repo.varnish-cache.org/redhat/varnish-3.0/el5/noarch/varnish-release-3.0-1.noarch.rpm
yum install varnish

Кэш-сервер должен пройти установку без каких-либо ошибок и сообщений. На данный момент он пока не функционирует. Представление контента до сих пор производится при помощи Apache или другого веб-сервера, который вы используете. Нам нужно немного изменить конфигурацию, чтобы удостовериться в том, что Varnish играет главную роль.

К счастью, изменений не так и много. Основной файл конфигурации Varnish хранится в /etc/default/varnish. Единственное необходимое изменение заключается в устранении знаков цитирования из “DAEMON_OPTS”. После этого файл должен выглядеть следующим образом:

DAEMON_OPTS="-a :80 
-T localhost:6082
-f /etc/varnish/default.vcl
-S /etc/varnish/secret
-s malloc,256m"

Второй этап заключается в том, что мы, посредством файла default.vcl в /etc/varnish/default.vcl, сообщаем кэш-серверу о том, где запущен наш веб-сервер. Веб-сервер может быть запущен как на той же машине, так и на внешнем источнике. Рекомендуем вам задуматься о том, чтобы запускать кэш-сервер на отдельном сервере.

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

Веб-мастера заметят, что мы поменяли порт веб-сервера на 8080, и зачастую это не вызывает никаких проблем. По крайней мере, если используются стандартные настройки. Чтобы запустить сервер, используя уже новую конфигурацию, нам нужно проделать еще кое-что – сообщить веб-серверу, что он с этого момента должен работать на порте 8080. Это можно сделать при помощи файла конфигурации сервера. В Apache этот файл находится в /etc/apache2/ports.conf.

NameVirtualHost 127.0.0.1:8080
Listen 127.0.0.1:8080

Важно:

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

Еще кое-что: после перезагрузки как Varnish, так и вашего Apache или любого другого веб-сервера, который вы используете, все должно заработать так, как надо. Вскоре вы заметите скоростное чудо Varnish. Так как этот кэш-сервер невероятно быстрый, мы осмеливаемся рекомендовать использовать его даже на самых крупных веб-проектах. Перед тем, как вложить финансы в апгрейд аппаратного оснащения, мы рекомендуем вам попробовать Varnish. Он может исключить необходимость покупки нового оборудования. Если вам нужна более детальная документация, то мы приглашаем вас пройти на страницу разработчиков, и ознакомиться с представленной там документацией.

Где научиться работать с виртуальными хостами apache?

Больше информации о виртуальных хостах можно найти в следующих мануалах:

Гибкость

Самое главное, на что обращают внимание при использовании определённого технологического решения, — это его гибкость. Одна из ключевых особенностей, которые дают Varnish Cache преимущество перед NGINX, — это гибкость, которую он предлагает с помощью своего языка конфигурации.

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

Дебаггинг информация в drupal watchdog


На странице

Еще раз о cache api в drupal 8

Описанное в статье — это лишь малая часть того, как используется cache API в Drupal 8. Я лично считаю Cache API главным новведением по сравнению с Drupal 7. Если у читателей есть интерес, то я могу написать следующую статью, где рассмотрю глубже вопросы внутреннего устройства cache API; как кеширование переплетается с рендерингом в Drupal 8.

Как выбрать порт?

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

Чтобы узнать о портах больше, обратитесь к Википедии.

Как узнать дистрибутив linux и его версию?

Чтобы узнать, какой дистрибутив и версию использует ваша машина, запустите команду:

cat /etc/*-release

Канал коммуникации drupal → varnish

С хоста, где находится Drupal, сделайте

Который лучший?


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

Связанные статьи:

Масштабирование

Существует два подхода – вертикальное и горизонтальное масштабирование.

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

Горизонтальное масштабирование – это увеличение количества серверов (за счет чего увеличивается и вычислительная мощность). К примеру, когда вы покупаете несколько недорогих серверов и объединяете их в одну систему – это и есть горизонтальное масштабирование.

Моя тестовая среда

Я буду работать с Vagrant, используя Ubuntu Trusty. Как уже было сказано выше, Apache у меня привязан к порту 8080, а Varnish 4 – к порту 80.

Вы можете загрузить мою тестовую среду с GitHub. Инструкции по ее установке находятся в файле readme.

У меня есть два сконфигурированных сайта. Если я посещу эти сайты в браузере, то Varnish обработает запрос в порте 80, либо поставив файл из кэша, либо обратившись к Apache.

В данный момент полезно проверить, какие порты у нас используются. Подключаемся по SSH к Vagrant:

vagrant ssh

Затем выполняем netstat:

sudo netstat -taupen

Мы получим список портов, а также информацию о том, какие процессы их используют. Вы должны отметить, что Varnish работает с портом 80, а Apache – с 8080.

Вы также можете убедиться в том, что Varnish работает в обычном режиме и выдает страницы из кэша:

varnishstat

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

Если вы используете мой VCL с GitHub, то вы можете видеть, что я добавил к конфигурации Varnish некоторый код, который передает браузеру заголовок HIT или MISS. Это означает, что вы можете видеть, какой заголовок был отправлен. Вы должны увидеть X-Cache: HIT, если страница была получена из кэша Varnish, и X-Cache: MISS, если страница поступила от Apache.

Настраиваем ssl для сайтов в nginx

Как только вы поместите в папку на сервере ваш самоподписанный или приобретенный SSL-сертификат, вы можете заняться настройкой ваших сайтов в Nginx.

Во-первых, удалите стандартный конфигурационный файл из /etc/nginx/sites-enabled. Вы можете удалить файл default или переместить его в другую папку.

Нам нужно настроить только те сайты, которые будут выводиться через SSL; все остальные сайты продолжат выводиться через Varnish, запущенный на порте 80. В моем случае я буду настраивать smashing_ssl_one.tutorials.eoms. Везде, где вы далее увидите этот домен, вам нужно будет его заменить на свой домен (локальный или онлайн). Исключение: тот случай, если вы используете мою рабочую среду, которая была приведена по ссылке выше.

Настройка drupal 8

Нужно объяснить Drupal’у, где находится Varnish и как частично инвалидировать его кеш. После установки вышеперечисленных модулей, перейдите на страницу

Настройка varnish

Теперь перейдем к подготовке Varnish’a. В ваш VCL необходимо добавить следующее.

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

Это самый прос­той при­мер, и, как видим, зас­тавить Varnish кеширо­вать зап­росы очень лег­ко, но он пока не «раз­бира­ется» и не вме­шива­ется в тра­фик. Поз­накомив­шись с VCL, мож­но рас­ширить базовые воз­можнос­ти. Парамет­ров, которые мож­но нас­тро­ить, очень мно­го и, что­бы их опи­сать, пот­ребу­ется кни­га.

VCL — это язык прог­рамми­рова­ния, в котором най­дем все, что положе­но: перемен­ные, фун­кции, ком­мента­рии и про­чее. Вари­антов исполь­зования мно­го, и с ходу их осво­ить не получит­ся. В качес­тве отправ­ной точ­ки мож­но рекомен­довать докумен­тацию про­екта, в час­тнос­ти Varnish Book.

Размер очереди на инвалидацию

На странице

Расширяем cache api на varnish


Этот туториал считает, что вы уже успешно установили и настроили Varnish для статических ресурсов (графика, css, javascript). Для покрытия кешем еще и анонимных HTML страниц нам потребуется 3 шага:

  1. Объяснить Varnish’у какая страница зависит от каких кеш тегов. Drupal уже имеет это знание, его просто нужно передать Varnish’у.
  2. В момент, когда какой-то кеш тег инвалидируется в Drupal’е, нужно также инвалидировать все страницы в кеше Varnish’a, которые зависят от этого кеш тега.
  3. Подготовить Varnish ко всем этим нововведениям.

Все эти вещи уже реализованы в виде модулей в экосистеме Drupal’а. Нам потребуется:

Если вы используете composer, то:

composer require "drupal/purge:^3.0"
composer require "drupal/varnish_purge:^1.0"

Включите следующие модули:

Редирект к ssl с помощью varnish

Как показывает моя практика, вы можете захотеть выполнить некоторые улучшения.

Создаем или устанавливаем ssl-сертификат

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

Чтобы создать самоподписанный сертификат для тестирования, выберите или создайте директорию, в которой он будет находиться. Я создал директорию nginx в /etc/ssl. Затем выполните следующую команду для генерации ключа и сертификата.

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/nginx/smashing_ssl_one.tutorials.eoms.key -out /etc/ssl/nginx/smashing_ssl_one.tutorials.eoms.crt

Когда вы выполните эту команду, вам будет задана серия вопросов. Вы можете написать любую ерунду в качестве ответов; однако, когда у вас спросят «Common Name», используйте домен, который вы обычно вводите в строку URL для доступа к вашему сайту в Vagrant. В моем случае это smashing_ssl_one.tutorials.eoms:

Если вы теперь заглянете в папку, которую вы создали, вы должны увидеть в ней два файла: один с расширением .key и другой с расширением .crt.

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

Рекомендую приобретать SSL-сертификаты для сайтов (Comodo, Symantec и др.) в проверенной компании ЛидерТелеком. ЛидерТелеком – стратегический партнер Comodo. Цены на сертификаты ниже, чем у официальных центров регистрации, да и поддержка имеется на русском языке. Можно будет легко решить все вопросы, если они возникнут.

Сравнение varnish cache и nginx cache

  • Varnish Cache поддерживает ESI, а Nginx — нет; Nginx поддерживает SSL, а Varnish Cache — нет.
  • Varnish Cache — это чистый веб-кеш, который имеет более продвинутые функции, связанные с кешем, чем Nginx; однако Nginx может действовать как «настоящий» кеш-сервер, когда размещается перед сервером/серверами приложений.
  • Varnish Cache обладает большой гибкостью, позволяя разработчикам создавать более сложную структуру кеширования, чем Nginx.
  • Varnish Cache имеет встроенный механизм, который позволяет очищать контент, в то время как Nginx OSS не поддерживает это изначально (однако Nginx Plus поддерживает)
  • Nginx известен своей высокоэффективной службой статического контента, особенно когда статические файлы находятся на том же сервере, что и Nginx. Если вы хотите избежать дополнительных накладных расходов за счёт внедрения новых технологий, Nginx может быть лучше.

Управление varnish

Ра­ботой Varnish мож­но управлять и отсле­живать резуль­тат. Для это­го в пос­тавке идет нес­коль­ко ути­лит, начина­ющих­ся с varnish*. Все они опи­саны в раз­деле «Appendix A: Varnish Programs» Varnish Book. Основной ути­литой явля­ется varnishadm.

Пос­ле чего появит­ся приг­лашение Varnish CLI. Что­бы получить спи­сок команд, сле­дует ввес­ти help.

Список команд varnishadm
Спи­сок команд varnishadm

Ко­манд нем­ного (23), зна­чение боль­шинс­тва понят­но из наз­вания. Под­робнос­ти по каж­дой мож­но получить, вве­дя «help коман­да». Нап­ример, груп­па команд vcl.* поз­воля­ет прос­матри­вать модули и управлять их заг­рузкой‑выг­рузкой. Смот­рим спи­сок модулей:

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

Пер­вая ути­лита выводит их в виде top, вто­рая как гис­тограм­му. При зап­росе мож­но исполь­зовать регуляр­ные выраже­ния, поэто­му потерять­ся в боль­шом количес­тве стра­ниц невоз­можно. Нап­ример, прос­мотрим спи­сок наибо­лее зап­рашива­емых URL и заголов­ки:

Управление статическим контентом

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

Но когда дело доходит до очистки контента, роли каждого из этих решений для кэширования меняются. NGINX, будучи сервером с открытым исходным кодом, имеет свои ограничения. Вот почему базовый NGINX-OSS не предлагает опции очистки контента. Вы всегда можете выбрать план NGINX Plus и воспользоваться функцией Fast CGI Cache Purge.

Установка nginx

Теперь мы установим Nginx. В системе с Ubuntu это сделать очень просто:

sudo apt-get install nginx

Документация Nginx содержит в себе информацию об установке Nginx на разных системах, а также пакеты для систем, которые не входят в их систему управления пакетами. Помните, что мы используем Nginx только в качестве прокси, т.е. нам не понадобится заниматься настройкой поддержки PHP или MySQL.

Вывод

Varnish — это очень гиб­кая прог­рамма, поз­воля­ющая управлять кеширо­вани­ем тра­фика с веб‑ресур­сов. Боль­шие воз­можнос­ти под­разуме­вают боль­шое количес­тво нас­тро­ек. Поэто­му некото­рое вре­мя при­дет­ся зат­ратить на их изу­чение и под­гонку под кон­крет­ные усло­вия. Но резуль­тат того сто­ит.

Подводя итоги

Глядя на приведённое выше подробное описание Varnish и NGINX, становится совершенно ясно, что Varnish предлагает более продвинутые функции, специфичные для функций кэширования, в то время как NGINX может использоваться в качестве кэширующего сервера.

Однако каждое из этих решений для кеширования имеет свои преимущества и пригодность в определённых ситуациях и сценариях. Например, если вы обеспечиваете работу веб-сайта электронной коммерции или веб-сайта СМИ, который работает с тяжёлым контентом, с высоким трафиком и ищете высокую производительность, Varnish Cache более подойдёт вам. В противном случае вам подойдёт веб-сервер с открытым исходным кодом, такой как NGINX.

Оцените статью
Хостинги