У нас есть сервер, который должен обслуживать несколько доменов, хотя лак, например. example1.com, example2.com и example3.com
Наш текущий .vcl файл выглядит следующим образом:
sub vcl_recv {
set req.http.Host = "example1.com";
lookup;
}
Как установить правильный req.http.Host для правильного входящего запроса?
Вы можете поддерживать несколько интерфейсных доменов таким образом:
backend example1 {
.host = "backend.example1.com";
.port = "8080";
}
backend example2 {
.host = "backend.example2.com";
.port = "8080";
}
sub vcl_recv {
if (req.http.host == "example1.com") {
#You will need the following line only if your backend has multiple virtual host names
set req.http.host = "backend.example1.com";
set req.backend = example1;
return (lookup);
}
if (req.http.host == "example2.com") {
#You will need the following line only if your backend has multiple virtual host names
set req.http.host = "backend.example2.com";
set req.backend = example2;
return (lookup);
}
}
Я использую настройку, похожую на Cristian's, но в случаях, когда я сопоставляю req.http.host против регулярного выражения:
#for www.example.com or example.com
if (req.http.host ~ "^(www\.)?example\.com$") {
set req.backend = example_com;
return (lookup);
}
#with any subdomain support
if (req.http.host ~ "^(.*\.)?example2\.com$") {
set req.backend = example2_com;
return (lookup);
}
Не забудьте правильно установить серверы.
не удалось добавить комментарий, так что мы идем
незначительная модификация для лака 4
#for www.example.com or example.com
if (req.http.host ~ "^(www\.)?example\.com$") {
set req.backend_hint = example_com;
return (lookup);
}
#with any subdomain support
if (req.http.host ~ "^(.*\.)?example2\.com$") {
set req.backend_hint = example2_com;
return (lookup);
}
заменить бэкенд с backend_hint
Я хотел бы добавить немного больше подробностей как к Cristian Vidmar, так и к сообщениям msurovcak
"(req.http.host ==" example1.com ")" Шаблон:
Мы использовали описанный шаблон для размещения от десятков до сотен сайтов на сервер.
Вы можете продолжить настраиваемые правила для конкретных сайтов на всей вашей конфигурации (vcl_fetch/vcl_backend_response, vcl_hash и т.д.) с помощью
if (req.http.host == "example1.com") {
пример везде, где это необходимо.
Объедините это с механизмом шаблонов, чтобы разрешить управление конкретными клиентами с помощью отдельных файлов, которые содержат свою собственную логику (все они привязаны к конкретному сайту, если блоки изолируют код).
Затем вы включаете каждый отдельный блок сайта в файл default.vcl, используя:
include "/etc/varnish/www.example1.com.vcl";
Дополнительное расширение для полного разделения бэкэндов:
Если вы размещаете совершенно разные веб-сайты, то разделить бэкэнд (и разделить кеш) - это хороший способ.
Если сайты похожи (одинаковая кодовая база /js/css/images ), может быть интересно запустить домен ресурсов, например. resources.example.com, что все сайты используют.
Затем у вас может быть один кеш (и очень высокий уровень попадания) по каждому из общих элементов нескольких сайтов и по-прежнему поддерживать различия на отдельных сайтах www.
Другая альтернатива использованию разделенных задних концов:
Другой вариант - разделить экземпляры Varnish через контейнеры. Каждый из них становится его собственным изолированным миром, который управляется (и живет и умирает) индивидуально. Это может быть хорошим вариантом безопасности, и накладные расходы нескольких процессов минимальны для современной инфраструктуры.
Некоторые преимущества этого в том, что вы можете поддерживать различные версии лаков и различные параметры запуска лака на каждый экземпляр.
Это может быть полезно для индивидуального ведения журнала, использования разных режимов ESI для каждого экземпляра и индивидуальных настроек конфигурации памяти/настройки.
Мы делаем это в www.section.io, а также дает возможность запускать различные контейнеры в разных географических точках или в тех же контейнерах в в разных местах, чтобы как можно ближе подойти к географически разбросанным базам пользователей.