Varnish – podstawy konfiguracji – cz. 3

W dzisiejszym wpisie rozpiszę Ci trochę odnośnie samej konfiguracji Varnisha. Będziesz przechodził przez konfigurację Varnisha krok po kroku na podstawie różnych scenariuszy.

Wpis ma na celu dać Ci wystarczająca wiedzę abyś umiał odczytać bez problemu większość konfiguracji na githubie, w pracy itd.

Całą użytą konfiguracje możesz znaleźć [TUTAJ].

Wpis jest częścią serii Varnish’u

VCL Subroutines

Gdy zobaczysz bardziej rozbudowaną konfiguracje niż tą w wpisie cz.2 nie unikniesz spotkania z VCL Subroutines. Są to podprogramy które służą m.in. do modyfikacji naszego requestu, ustawiania TTL, czyszczenia cache itd.

vcl_recv

Jest to pierwszy podprogram który jest wykonywany. Decyzje które tutaj podejmiesz będą miały wpływ na dalszą pracę Varnisha. Możesz tutaj m.in. fixować urle, dodawać nagłówki, wybierać czy Varnish ma nie cachować odpowiedzi czy ją cachować itd.

Przykład

Często każdy z nas potrzebuję na produkcji zobaczyć wersje live produktu, oferty itp. W podstawowej wersji Varnisha wystarczy dodać jakikolwiek query param ale to powoduję że wejście z reklamy, facebook, twittera itd. powoduję żądanie do aplikacji i zapisanie odpowiedzi w Varnishu.

Przykład poniżej daje nam możliwość zobaczenia takiej wersji dodając w adresie live_v1=0de080c_[YOUR_TEXT]. Dodatkowo pod sprawdzeniem parametru dodana została konfiguracja która kasuję różne parametry np. gclid, utm_source itd. Takie rozwiązanie daje nam wiele korzyści ale też wiele minusów. Jeżeli chcielibyśmy nagle z jakiegoś powodu dostać się do gclida będziemy musieli ingerować w konfiguracje Varnisha.

sub vcl_recv {
    set req.url = regsuball(req.url, "(gclid|fbclid|utm_[a-zA-Z0-9]+)=[%.-_A-z0-9]+&?", "");

    if (req.url ~ "(\?|&)live=0de080c_[a-zA-Z0-9]{1,}+&?") {
        set req.url = regsuball(req.url, "(\?|&)live=0de080c_[a-zA-Z0-9]{1,}+&?", "");

        return (pipe);
    }
}

Aby zobaczyć wynik tej konfiguracji wystarczy ze wejdziesz pod link localhost:5000/url?test=dsad&gclid=das&bla=321&live=0de080c_12. Każdorazowo po twoim wejściu lub odświeżeniu będziesz widział wersje live tej strony. W momencie gdy usuniesz parametr live zostanie Ci zaserwowana wersja z pamięci podręcznej Varnisha. Warto zauważyć że w każdym przypadku do aplikacji nie są przekazywane nagłówki wymienione w konfiguracji np. live, gclid, fbclid itd.

Innym przykładem którym mógłbym tutaj przedstawić jest decydowanie o długości cache na podstawie cookie. W ciasteczku mógłby być dodany UUID lub hash grupy usera, czy użytkownik jest zalogowany, czy użytkownik to pracownik firmy itd.

vcl_hash

Jest to kolejny najważniejszy subroutines po vcl_recv. Możliwość konfiguracjivcl_hash służy nam do definiowania danych które mają być wykorzystane do utworzenia id requestu. Dzięki temu hashowi varnish jest w stanie zidentyfikować czy żądany url ma zapisaną odpowiedź. Dzięki tej opcji konfiguracji varnisha możemy np. cachować odpowiedź per grupa użytkowników.

Przykład

Przykład poniżej przedstawia tworzenie request id na podstawie wartości cookie grupy użytkownika.

sub vcl_recv {
    if (req.http.Cookie) {
        return (hash);
    }
}

sub vcl_hash {
  if (req.http.cookie ~ "user_group=") {
    set req.http.USER-GROUP = regsub(req.http.cookie, "^.*?user_group=([^;]+);*.*$", "\1");

    if (req.http.USER-GROUP ~ "^(DELTA|BETA|ALPHA)$") {
        hash_data(req.http.USER-GROUP);
    }
    
    unset req.http.USER-GROUP;
  }
}

Wynik tej konfiguracji możesz znaleźć pod linkiem localhost:5000/group. Za każdym razem gdy ustawisz cookie user_group a następnie odświeżysz stronę, Varnish będzie zwracał Ci zapisaną odpowiedź dla konkretnej grupy.

vcl_pass

Jest wywoływany w momencie zwrócenia pass z vcl_recv, vcl_hit lub vcl_miss. I to w sumie tyle 🙂

vcl_pipe

W przypadku tego podprogramu jest tworzony full duplexowy pipe który wysyła po prostu request do aplikacji. Zawartość nie jest cachowana ani obrabiana przez inne podprogramy.

vcl_miss

Ta opcja konfiguracyjna Varnisha jest wywoływana gdy nie zostanie znaleziona odpowiedź serwera. Response jest wyszukiwany tak jak wspomniałem wcześniej na podstawie wyniku subroutines vcl_hash.

vcl_hit

Jak sama nazwa wskazuję ten podprogram jest wykonywany w momencie gdy zostanie znaleziona odpowiedź serwera w pamięci Varnisha. Jest ona wykonywana od razu po vcl_hash.

vcl_backend_fetch

Jest wywoływany po vcl_pass i vcl_miss. Najważniejszą informacją jest to że jeżeli zostanie wywołana z vcl_pass response nie zostanie zapisany zaś w momencie gdy zostanie wywołany z vcl_miss response zostanie zapisany w pamięci podręcznej Varnisha.

vcl_backend_response, vcl_backend_error

Odpowiedź wygenerowana przez vcl_backend_fetch jest przetwarzana przez powyższe podprogramy. W powyższych podprogramach możemy sterować dalszym zachowaniem response i tym co się ma zapisać w samej pamięci podręcznej.

Przykład

Idealnym przykładem może być zwrócenie zwykłego statycznego pliku np. css, js, png, svg etc. Możemy tym plikom na stałe ustawić cache na np. 2 dni.

sub vcl_recv {
    if (req.url ~ "^[^?]*\.(css|js|png|svg|webp)(\?.*)?$") {
        set req.http.X-Static-File = "true";
        unset req.http.Cookie;

        return(hash);
    }
}

sub vcl_backend_response {
     if (bereq.http.X-Static-File == "true") {
        set beresp.ttl = 60s;
     }
}

Gdy zrobisz jakąkolwiek zmianę w pliku app.js to nie będzie ona widoczna przez najbliższą 1 minutę. Przetestować to możesz pod linkiem

vcl_deliver

W większości sytuacji będzie to ostatni punkt w którym możemy coś skonfigurować. W tym miejscu najczęściej są usuwane i dodawana nagłówki które służyły do debugowania lub samego przekazania informacji dla Varnisha.

vcl_synth

Za pomocą tego podprogramu robimy custom strony błędu oraz wykonujemy przekierowania.

Podsumowanie

W tym wpisie za dużo nie było moich przemyśleń a więcej skrócania samych informacji z dokumentacji Varnisha (linki poniżej). Mam nadzieję że to streszczenie pozwoliło Ci lepiej zrozumieć podstawy konfiguracji. 🙂 Jeżeli nie jesteś pewien samego przepływu co kiedy jest wywoływane zobacz na ten img.

Źródła

Varnish – podstawy konfiguracji – cz. 3