pl  |  en

Varnish

Varnish jest zainstalowany na serwerach i możesz z niego korzystać na hostingu współdzielonym i VPSach. Uruchomisz go we własnym zakresie, na prawach Twojego konta – będzie pośredniczył pomiędzy Nginxem a Twoją aplikacją (patrz schemat).

schemat konfiguracji

Kiedy użyć Varnisha?

Wtedy kiedy potrzebujesz czyli

  • serwis nie radzi sobie z obciążeniem, działa wolno, generuje za duże obciążenie CPU
  • masz dużo cache’owalnej treści (zdecydowana większość to niezalogowani użytkownicy)

Ważna uwaga: odpowiedzi z ciastkiem nie są cache’owane. Serwowanie ciasteczek przy każdym wejściu na stronę sprawia, że strona staje się niecache’owalna. Sprawdź jakie nagłówki wysyła Twój serwis

curl --head https://mojwypasionyserwis.pl/

Możesz nie pamiętać, że zabezpieczyłeś wyszukiwarkę przed CSRF i każdemu serwujesz cookie.

Konfiguracja

Masz aplikację Django uruchomioną przez panel na Gunicornie na 3 procesach i to jest aplikacja, dla której chcsz skonfigurować Varnisha. Gunicorn jest uruchomiony na IP konta i portach przydzielonych przez nasze oprogramowanie. Dla przykładu są to porty  10100, 10101 i 10102. Poleceniem ps aux wylistujesz procesy na koncie i zobaczysz jakie porty zostały przydzielone do Twojej aplikacji.

Pierwszym krokiem do skonfigurowania Varnisha będzie dodanie proxy w panelu. Panel przydzieli port na którym uruchomisz Varnisha. Na potrzeby tego opisu przyjmijmy, że IP to 1.2.3.4 a przydzielony port dla proxy to 112233. Pamiętaj, że każda aplikacja musi mieć przypisaną domenę, bez tego nie konfigurujemy dla niej Nginxa, nie uruchamiamy jej. To samo dotyczy proxy. Na początku do proxy możesz dodać jakąś tymczasową domenę a gdy wszystko będzie działać przepnij tam swoją produkcyjną nazwę. Dodatkowo – to ważne – jakakolwiek domena musi być cały czas dodana do aplikacji Django.

Konfigurujemy Varnisha na serwerze: stwórz w swoim katalogu domowym folder np. ~/varnish

mkdir ~/varnish

i skopiuj tam przykładowy plik konfiguracyjny z instalacji Varnisha w systemie

cp -a /usr/local/varnish/etc/varnish/default.vcl ~/varnish

Wyedytuj go i ustaw własne wartości. Zawartość tego pliku może wyglądać tak:

backend default {
    .host = "1.2.3.4";
    .port = "10101";
}

backend django0 {
    .host = "1.2.3.4";
    .port = "10100";
    .connect_timeout = 900s;
    .first_byte_timeout = 600s;
    .between_bytes_timeout = 900s;
}

backend django1 {
    .host = "1.2.3.4";
    .port = "10101";
    .connect_timeout = 900s;
    .first_byte_timeout = 600s;
    .between_bytes_timeout = 900s;
}

backend django2 {
    .host = "1.2.3.4";
    .port = "10102";
    .connect_timeout = 900s;
    .first_byte_timeout = 600s;
    .between_bytes_timeout = 900s;
}

director django round-robin {
        {
                .backend = django0;
        }
        {
                .backend = django1;
        }
        {
                .backend = django2;
        }       
}

sub vcl_recv {
        set req.backend = django;
}

sub vcl_fetch {
    set beresp.ttl = 1h;
}

To jest uproszczona wersja pliku konfiguracyjnego – vcl to bardzo rozbudowany język konfiguracji i możesz zrobić w nim wiele ciekawych rzeczy. Celem tego opisu jest pokazanie jedynie jak uruchomić Varnisha w MegiTeam. Co dokładnie oznaczają kolejne wpisy?

backend default

jeżeli otrzymany request nie pasuje do żadnego ze skonfigurowanych vhostów, Varnish przekaże go do tego backendu. W naszej konfiguracji i tak wszystkie żądania, które już trafią do Varnisha (bez względu na domenę) przekazujemy do skonfigurowanych backendów, więc ten wpis nie ma sensu, ale Varnish wymaga ustawienia domyślnego backendu.

director django round-robin

Varnish musi wiedzieć, że ma rozdzielać przychodzące żądania HTTP pomiędzy backendy (load balancing). W naszej konfiguracji robi round robin czyli wybiera backendy po kolei.

sub vcl_recv {
        set req.backend = django;
}

tutaj mamy faktyczne przekazanie żądania do skonfigurowanych wcześniej backendów. My wszystkie żądania przychodzące do Varnisha przekazujemy do jednej aplikacji (o tym co ma iść do Varnisha decyduje Nginx na podstawie domeny, którą dopisałeś do proxy w panelu). Jeżeli chcesz użyć cache dla kilku aplikacji to musisz skonfigurować kilka backendów i rozdzielać ruch pomiędzy nimi na podstawie nagłówka HTTP Host:

sub vcl_recv {
    if (req.http.Host ~ "djangoapp.jasiu.megiteam.pl")
    {
        set req.backend = django;
    }
}

Ostatnia rzecz w naszej konfiguracji to

sub vcl_fetch {
    set beresp.ttl = 1h;
}

ustawiamy czas cache’owania danych na godzinę (domyślnie jest 2 min. – to za mało).

Mamy już skonfigurowanego Varnisha – czas go uruchomić.

/usr/local/varnish/sbin/varnishd -a 1.2.3.4:112233 -f /home/jasiu/www/varnish/default.vcl 
 -s malloc,256M -n /home/jasiu/www/varnish -w 2,50,120

Opcja malloc,256M ustawia Varnishowi 256MB pamięci (ustaw ją według własnej potrzeby i dostępnej pamięci na Twoim koncie).

Dobrym pomysłem będzie uruchomienie Varnisha przez Supervisord. W wolnej chwili dodam opis w Pomocy jak skonfigurować to narzędzie.

Czyszczenie cache

Jestem przekonana, że po pierwszych zmianach w serwisie będziesz zastanawiał się dlaczego nie widać ich na stronie 🙂 Z pytaniem jak wyczyścić cache odsyłam do dokumentacji – może zrobimy z tego osobny wpis na blogu.

Serwowanie plików statycznych

W konfiguracji proxy na poziomie serwera WWW wszystkie żądania przekazywane są do aplikacji, Nginx nie serwuje plików statycznych dla aplikacji typu „proxy”. Jednocześnie w konfiguracji z Varnishem nie ma sensu wykorzystywać go jako cache dla plików statycznych. Jeżeli chcesz, żeby static z Twojej aplikacji był serwowany przez Nginxa, musisz serwować go z osobnej domeny dla której w panelu ustawisz typ aplikacji na „stronę statyczną”.

Autor: Magda Zarych

  • Grzegorz

    „… a przydzielony port dla proxy to 112233 …”
    uint16_t overflow 😉