• Articles
• admin

strony o dużym ruchu muszą kilka razy podawać tę samą treść różnym użytkownikom. W zależności od aplikacji, przetwarzanie całej logiki aplikacji za każdym razem, gdy użytkownik żąda strony internetowej, może być naprawdę kosztowne (zasoby mówią). Oto, gdzie przychodzi buforowanie serwera, możesz po prostu zapisać tymczasową kopię zawartości w pamięci i udostępnić tę zawartość wszystkim użytkownikom.

Varnish świetnie nadaje się do buforowania zawartości po stronie serwera. Zasadniczo powinieneś buforować zawartość HTML, ale możesz również buforować pliki: CSS, JS, obrazy, dokumenty.

brzmi dobrze, ale prawda jest taka, że domyślnie lakier nic nie robi, a przynajmniej możesz marnować zalety tego oprogramowania, a dokumentacja nie pomaga, więc napisałem ten artykuł, więc możesz uzyskać jak najwięcej korzyści z lakieru. Wyjaśnię, gdzie i jak skonfigurować, przetestować i wdrożyć serwer Varnish cache dla Twojej aplikacji.

dla celów demonstracyjnych, Załóżmy, że mamy 2 instancje serwera dla naszej aplikacji i serwerów pamięci podręcznej z następującymi lokalnymi adresami IP:

• serwer aplikacji: 192.168.1.2
• Serwer Cache: 192.168.1.3

zainstaluj Varnish Cache Server

w tym celu zamierzamy zainstalować Ubuntu server 16.04 z Varnish 4.0. Aby zainstalować lakier, wystarczy uruchomić:

sudo apt install varnish

zainstaluję Varnish 4.0 i od teraz będziesz zwracał szczególną uwagę na 2 konkretne pliki:/etc/default/varnish i /etc/varnish/default.vcl

konfiguracja backendu

pierwszą rzeczą, którą musisz zrobić, to skonfigurować backend lub poinstruować Varnish, gdzie aplikacja internetowa będzie działać:

• Jaka jest nazwa hosta lub adres IP?
• co to jest port?

aby zdefiniować, że musisz przejść do aktualizacji pliku /etc/varnish/default.vcli znaleźć następującą sekcję, która zostanie skonfigurowana do naszego przykładowego celu, takiego jak ten:

backend default { .host = "192.168.1.2"; .port = "8080"; .first_byte_timeout = 60s; .connect_timeout = 300s;}

poinstruuje Varnish aby nasłuchał aplikację działającą pod adresem IP 192.168.1.2 oraz na porcie 8080.

Skonfiguruj demona lakieru

pierwszą rzeczą, którą musisz określić, gdzie będzie działał lakier. Zostawimy go na domyślnym porcie 6081. Bardzo często uruchamiamy tego demona na portach 80 i 443 dla SSL, ale wolimy umieścić NGINX z przodu i pozostawić go do udziału w ruchu.

jeśli chodzi o pamięć, instalacja pustego lakieru uruchomi się z 256 MB pamięci, co może wystarczyć dla niektórych aplikacji, ale dla aplikacji o dużym natężeniu ruchu może to nie wystarczyć, a nawet więcej, jeśli zarezerwowałeś dedykowany serwer tylko dla pamięci podręcznej.

możesz to zmienić na:

/etc/default/varnish

Znajdź następującą sekcję:

DAEMON_OPTS="-a :6081 \-T localhost:6082 \-f /etc/varnish/default.vcl \-S /etc/varnish/secret \-s malloc,256m"

aby zaktualizować ilość pamięci RAM, zmieniasz ostatnią linię, w której jest napisane 256m i aktualizuj wymaganą wartość, w moim przypadku chcę poświęcić 3GB PAMIĘCI RAM na lakier, więc blok będzie wyglądał tak:

DAEMON_OPTS="-a :6081 \-T localhost:6082 \-f /etc/varnish/default.vcl \-S /etc/varnish/secret \-s malloc,3G"

sprawdź, czy działa z odpowiednią konfiguracją

potwierdź, że działa zgodnie z oczekiwaniami, sprawdź proces ps aux | grep varnish i powinieneś zobaczyć coś takiego:

/usr/sbin/varnishd -j unix,user=vcache -F -a :6081 -T :6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,3G

napraw demona startowego Varnish w niektórych instalacjach Ubuntu

wykryliśmy błąd, w którym usługa nie postępuje zgodnie z instrukcjami zdefiniowanymi w pliku varnish i może być konieczna edycja usługi startowej.

aby to zrobić otwórz i edytuj plik

/lib/systemd/system/varnish.service

i zobaczysz coś takiego:

Description=Varnish HTTP acceleratorDocumentation=https://www.varnish-cache.org/docs/4.1/ man:varnishdType=simpleLimitNOFILE=131072LimitMEMLOCK=infinityExecStart=/usr/sbin/varnishd -j unix,user=vcache -F -a :6081 -T :6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256MExecReload=/usr/share/varnish/reload-vclProtectSystem=fullProtectHome=truePrivateTmp=truePrivateDevices=trueWantedBy=multi-user.target

aby to działało, musisz zaktualizować sekcję wewnątrz wiersza ExecStart i zastąpić ją dla wymaganej konfiguracji:

ExecStart=/usr/sbin/varnishd -j unix,user=vcache -F -a :6081 -T :6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,3G

po zakończeniu musisz ponownie załadować demona usługi: systemctl daemon-reload a następnie uruchom ponownie lakier.

jak skonfigurować czyszczenie pamięci podręcznej

istnieją 2 sposoby czyszczenia pamięci podręcznej lakieru:

• ponowne uruchomienie usługi lakierniczej.
• Wyślij prośbę o wyczyszczenie do serwera Varnish.

Restart lakier chodzi tylko o restart serwisu:

sudo service varnish restart

ale to, czego naprawdę potrzebujemy, to możliwość wysłania żądania czyszczenia z serwera aplikacji. Można to osiągnąć, zlecając serwerowi wyczyszczenie określonej ścieżki lub wszystkich z nich. Używając CURL, żądanie wyglądałoby tak:

curl -X PURGE http://192.168.1.3:6181

domyślnie lakier nie zezwala na żądanie czyszczenia z zewnętrznego serwera, więc musisz zezwolić na żądania z serwera aplikacji. Aby to zrobić, przejdź i edytuj /etc/varnish/default.vcli znajdź sekcję purge, w której musisz dodać adres IP serwera aplikacji:

acl purge { "localhost"; "127.0.0.1"; "192.168.1.2"/24;}

jak debugować czyszczenie

musisz sprawdzić, czy wszystko działa poprawnie. Aby to zrobić, możesz użyć następującego polecenia:

varnishlog -g request -q 'ReqMethod eq "PURGE"'

następnie możesz wysłać żądanie czyszczenia i powinieneś zobaczyć coś takiego, aby potwierdzić, że żądanie czyszczenia zostało odebrane:

* << Request >> 1179851- Begin req 1179850 rxreq- ReqStart 192.168.195.197 39700- ReqMethod PURGE- ReqURL /.*- ReqProtocol HTTP/1.1- ReqHeader Host: swapps.com- ReqHeader User-Agent: W3 Total Cache- ReqHeader Connection: close- ReqHeader X-Forwarded-For: 192.168.195.197- VCL_call RECV- Timestamp Process: 1531199642.768541 0.000094 0.000094- RespHeader Date: Tue, 10 Jul 2018 05:14:02 GMT- RespHeader Server: Varnish- RespHeader X-Varnish: 1179851- RespProtocol HTTP/1.1- RespStatus 200- RespReason OK- RespReason Purged- End

stan 200 OK oznacza, że wszystko poszło dobrze i Varnish wyczyścił pamięć podręczną dla żądanego adresu URL, i powinieneś mieć wszystko, czego potrzebujesz, aby rozpocząć buforowanie zawartości na serwerze.

następnym krokiem, jeśli tego nie zrobiłeś, jest skonfigurowanie reguł, które treści chcesz buforować, a które nie, ale to jest temat na inny post na blogu i będzie bardzo zależeć od rodzaju aplikacji, frameworka lub używanego CMS.