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

Что такое 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

Varnish или nginx?

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

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

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

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

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

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

NameVirtualHost 127.0.0.1:8080
Listen 127.0.0.1:8080

Где научиться работать с виртуальными хостами 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.

Ко­манд нем­ного (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.