Varnish

All webtrafikk på Samfundet går gjennom Varnish, en cachende reversproxy, før den treffer Apache. (SSL-trafikk går gjennom Hitch før den treffer Varnish, siden Varnish i seg selv ikke snakker SSL/TLS. Hitch er en SSL-terminator vedlikeholdt av Varnish-teamet.)

Det å ha Varnish foran i stedet for å la Apache snakke med brukere direkte er mer effektivt, av to årsaker:

Varnish kan cache ressursene, dvs. ta en kopi av det Apache sender ut og så sende det samme rett fra RAM til de neste klientene som kommer uten at de må genereres helt på nytt. Ikke alle ressurser er cachebare, men man kan konfigurere Varnish gjennom et relativt fleksibelt scriptspråk kalt VCL til å overstyre backendens instruksjoner. På den måten kan man få til caching selv med ikke-samarbeidsvillige backends.
En Varnish-tråd er vesentlig mer lettvekts enn en full Apache-prosess (som gjerne også binder opp en Postgres-prosess og/eller en appserver-prosess). Dette betyr at om det tar 100 ms å generere en side og 400 ms å sende den til klienten (f.eks. om klienten er på mobil), vil man frigjøre 80% av Apache-barnet (mot en bitteliten kostnad på en Varnish-tråd) til å gjøre andre ting. Dette sparer minne.

I utgangspunktet står alle sider på Samfundet i «pass», slik at Varnish ikke prøver på noe caching overhodet. De store unntakene per september 2016 er uka.no og deler av samfundet.no (spesielt bilder). Imidlertid er det lett å sette opp caching om man plutselig får voldsom trafikk mot én side (f.eks. ved store billettslipp e.l.), siden alt allerede rutes gjennom Varnish. Husk å bruke reload og ikke restart om du endrer VCL; Varnish beholder ikke cachen sin på tvers av omstarter.

I utgangspunktet vil Varnish gjenbruke tilkoblinger til en backend (altså Apache), også på tvers av vhosts. Dette er et problem for oss siden vi bruker mpm-itk, hvor da Apache-barnet setter en uid på begynnelsen av tilkoblingen (og ikke får lov til å bytte tilbake). Derfor har vi noen små patcher i Varnish og vmod_gwist for å sikre at dette ikke skjer (det mest realistiske alternativet ville være å sette «Connection: close» på alle backend-requests, som er mulig men litt ineffektivt). Patchet versjon av vmod_gwist og patchen for varnish finner du i /home/cassarossa/itk/felles/git/libvmod-gwist/.

Sette opp ny vhost

Lag vhosten i /etc/apache2/sites-available/foo.conf. Den skal være av typen <VirtualHost localhost:80>. Ikke sett opp noe om SSL, det tar Hitch seg av. Enable vhosten med «a2ensite foo». Reload Apache («systemctl reload apache2»).
Om du vil ha HTTPS-redirect (mest sannsynlig vil du), legg til vhosten i den store if-en under «HTTPS redirect» i /etc/varnish/default.vcl. Reload Varnish («systemctl reload varnish»).
Pek DNS-innslaget i /etc/bind/pz slik at det er CNAME til cirkus.samfundet.no. Inkrementer seriellen og reload bind («systemctl reload bind9»). Vent på propagering. Done!

Flyt av forespørsler

En forespørsel til cirkus begir seg ut på litt av en reise, se bildet under.

Intern flyt av IP-adresser

Det skal bittelitt triksing til for å bevare IP-adressen hele veien nedover stacken. Slik ser det ut:

Browseren treffer hitch på port 443. hitch gjør kun TLS-terminering; den gjør ikke HTTP/2, men den gjør OCSP-stapling og andre ting du forventer fra en slik. hitch sitter på alle sertifikatene.
hitch snakker med Varnish på [::1]:6081, med PROXY, slik at Varnish får IP-adressen til klienten – eller klienten kommer rett inn med ukryptert HTTP på cirkus.samfundet.no:80. Varnish vet forskjellen på disse to og setter/unsetter litt backend-headere selv. Om det er behov for HTTPS-redirect, gjør Varnish det direkte.
Varnish sender requesten videre til [::1]:80. Det settes opp (via vmod_gwist) én backend per hostname, slik at ikke connections gjenbrukes på tvers av vhosts (se over).
Apache (som kun lytter på localhost:80 og ingenting annet for de gitte vhostene) behandler requesten, og mod_remoteip plukker opp klientens IP-adresse fra X-Forwarded-For-headeren (og bruker den i stedet for Varnish' IP-adresse, som alltid er ::1).

Debugging

Verifisere varnish config

Hvis du har endret på default.vcl og vil passe på at syntaxen er riktig kan du kjøre:

theodorc@cirkus: sudo varnishd -C -f /etc/varnish/default.vcl

Debugge en spesifikk side

Hvis du debugger Varnish for en spesifikk side er varnishlog din venn. F.eks jeg vil se alle cache MISS for hvorlengeerdettil.uka.no:

theodorc@cirkus: sudo varnishlog -q 'RespHeader:x-cache[1] eq MISS and ReqHeader:Host[1] eq hvorlengeerdettil.uka.no'

Du skjønner greia, det finnes mange gode ressurser der ute på hvordan vsl-query funker.

Lenker: Start, krisevarnish, letsencrypt, til nye itkere