Configurar múltiples sitios con Varnish

Question

Tenemos un servidor que necesita servir varios dominios a través de barniz, p. example1.com, example2.com y example3.com

Nuestro archivo .vcl actual se parece a esto:

sub vcl_recv { 
    set req.http.Host = "example1.com";  
    lookup; 
} 

¿Cómo se configura el req.http.Host correcto para la petición de entrada correcta?

Answer 1

Puede soportar múltiples dominios frontend de esta manera:

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); 
    } 
} 

Answer 2

estoy usando configuración similar a Cristian, pero en si las cláusulas que coincida req.http.host contra la expresión regular:

¡No te olvides de configurar los backends de forma adecuada!

Answer 3

me gustaría añadir un poco más de detalle tanto Cristian Vidmar y mensajes de msurovcak

Los "(req.http.host == "example1.com")" Patrón:

Hemos utilizado el patrón descrito para alojar decenas a cientos de sitios por servidor.

Puede continuar con reglas personalizadas específicas del sitio a través de toda su configuración (vcl_fetch/vcl_backend_response, vcl_hash etc.) utilizando el

if (req.http.host == "example1.com") {

ejemplo, siempre que sea necesario.

Combine esto con un motor de plantillas para permitir que las configuraciones específicas del cliente se administren a través de archivos individuales que contienen su propia lógica (todo envuelto con su sitio específico si los bloques para aislar el código).

A continuación, incluyen cada bloque sitio individual en el default.vcl usando:

include "/etc/varnish/www.example1.com.vcl";

Una mejora opcional a backends totalmente divididas:

Si aloja totalmente diferentes sitios web a continuación, dividida backends (y caché dividida) es una buena forma de hacerlo.

Si los sitios son similares (mismas bases de código/js/css/images) puede ser interesante ejecutar un dominio de recursos ej. resources.example.com que usan todos los sitios.

Puede tener un único caché (y una tasa de aciertos muy alta) en cada uno de los elementos comunes de varios sitios y aún así mantener las diferencias en los sitios www individuales.

Otra alternativa al uso de división de vuelta termina:

Otra opción es la de dividir los casos de barniz a través de contenedores. Cada uno entonces se convierte en su propio mundo aislado que es administrado (y vive y muere) individualmente. Esta puede ser una buena opción de seguridad y la sobrecarga de múltiples procesos es mínima en la infraestructura moderna.

Algunas ventajas de esto es que puede soportar diferentes versiones de Varnish y diferentes parámetros de inicio de Varnish por instancia.

Esto puede ser ideal para el registro individual, aprovechando los diferentes modos de ESI por instancia y la configuración individual de memoria/ajuste.

Hacemos esto en www.section.io y también nos da la capacidad de ejecutar diferentes contenedores en diferentes ubicaciones geográficas o los mismos contenedores en diferentes ubicaciones para acercarnos lo más posible a las bases de usuarios geográficamente dispersas.

Answer 4

incapaces para añadir comentarios así que aquí vamos

ligera modificación para el barniz 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); 
} 

reemplazar backend con backend_hint