Configureer meerdere sites met Varnish

We hebben een server die meerdere domeinen moet bedienen via vernis, b.v. voorbeeld1.com, voorbeeld2.com en voorbeeld3.com

Ons huidige .vcl-bestand ziet er als volgt uit:

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

Hoe stel ik de juiste req.http.Host in voor het juiste inkomende verzoek?

Antwoord 1, autoriteit 100%

Je kunt op deze manier meerdere frontend-domeinen ondersteunen:

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

Antwoord 2, autoriteit 30%

Ik gebruik een setup die vergelijkbaar is met die van Cristian, maar in if-clausules vergelijk ik req.http.host met reguliere expressie:

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

Vergeet niet om de backends op de juiste manier in te stellen!

Antwoord 3, autoriteit 12%

kan geen reactie toevoegen, dus hier gaan we

kleine wijziging voor vernis 4

#for www.example.com or example.com
if (req.http.host ~ "^(www\.)?example\.com$") {
        set req.backend_hint = example_com;
        return (hash);
}
#with any subdomain support
if (req.http.host ~ "^(.*\.)?example2\.com$") {
        set req.backend_hint = example2_com;
        return (hash);
}

vervangen
backend
met
backend_hint

Antwoord 4, autoriteit 8%

Ik wil graag wat meer details toevoegen aan de berichten van zowel Cristian Vidmar als msurovcak

Het “(req.http.host == “example1.com”) ” patroon:

We hebben het beschreven patroon gebruikt om tientallen tot honderden sites per server te hosten.

U kunt doorgaan met sitespecifieke aangepaste regels gedurende uw hele configuratie (vcl_fetch/vcl_backend_response, vcl_hash enz.) met behulp van de

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

voorbeeld waar nodig.

Combineer dit met een template-engine om klantspecifieke configuraties te beheren via individuele bestanden die hun eigen logica bevatten (allemaal verpakt met hun sitespecifieke if-blokken om de code te isoleren).

U neemt vervolgens elk afzonderlijk siteblok op in de standaard.vcl met:

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

Een optionele verbetering om backends volledig te splitsen:

Als je totaal verschillende websites host, dan is gesplitste backends (en gesplitste cache) een goede manier om te gaan.

Als de sites vergelijkbaar zijn (dezelfde codebase/js/css/images), kan het interessant zijn om een ​​resources-domein te gebruiken, bijv. resources.example.com die alle sites gebruiken.

Je kunt dan een enkele cache (en een zeer hoge hitrate) hebben voor elk van de gemeenschappelijke elementen van meerdere sites en toch verschillen behouden op de individuele www-sites.

Een ander alternatief voor het gebruik van gespleten achtereinden:

Een andere optie is om de Varnish-instanties op te splitsen via containers. Elk wordt dan zijn eigen geïsoleerde wereld die individueel wordt beheerd (en leeft en sterft). Dit kan een goede veiligheidsoptie zijn en de overhead van meerdere processen is minimaal op moderne infrastructuur.

Enkele voordelen hiervan zijn dat je dan verschillende versies van Varnish en verschillende Varnish opstartparameters per instantie kunt ondersteunen.

Dit kan geweldig zijn voor individuele logboekregistratie, waarbij gebruik wordt gemaakt van verschillende ESI-modi per instantie en individuele configuratie-instellingen voor geheugen/afstemming.

We doen dit op www.section.ioen het geeft ons ook de mogelijkheid om verschillende containers in verschillende geografische locaties of dezelfde containers op verschillende locaties om zo dicht mogelijk bij geografisch verspreide gebruikersbases te komen.