Let’s encrypt for varnish?

Do you have a site that’s accelerated with varnish but noticed that there is no native SSL support for Varnish?

No problems!
You can use a bunch of different methods to terminate SSL .
In this post I’m not going to be posting a bunch of configuration or setup steps. But discuss the caveats of terminating SSL .

Let’s say you are using drupal or wordpress.
Your current setup probably looks something like this:

varnish –> apache OR nginx backend -> application (wordpress/drupal) .

With Let’s encrypt you’re going to want to setup an SSL terminator. In the past I’ve recommended using ”pound” as an SSL terminator, but due to the slow development cycles I’ve moved towards nginx or haproxy.

Of the two I’d setup nginx SSL terminator in most cases as the Let’s encrypt certbot supports nginx natively for issuing and renewing SSL certificates.

Haproxy is awesome if you plan to use multiple backends or caches. If you use haproxy you probably know what you are doing but the problem with Let’s encrypt is that you have to run certbot in standalone mode with the ”certonly” variable on the commandline .

Haproxy will be configured to pass the acme-challenge to the standalone daemon that certbot launches. The renewal process will also use the forwarded requests .

With nginx it’s as simple as just creating the cert using certbot and configuring SSL proxy onwards to varnish.

We assume that you have previously managed to configure apache mod_rpaf , mod_remoteip or nginx to handle x-forwarded-for to provide the right IP to the web application.

One big issue that we’ve seen on customer installations when adding let’s encrypt support to already running setups is the fact that the backend application has no clue about https protocol. This sometimes causes forwarding loops or problems with loading http:// resources over a https:// connection (modern webrowsers raises alerts and refuses to load resources outside the https:// connection if it’s properly configured).

It’s important that the x-forwarded-for and protocol is passed on in all steps of the chain.

With haproxy you use option forwardfor and x-forwarded-proto.
Nginx needs to do the same.

On the backend side you can force SSL in a number of different ways.
The easiest way in php is to force https. Drupal and WordPress have a number of plugins to do so, you can also edit the php config files to force SSL.

For example in wp-config.php :
define(’FORCE_SSL_ADMIN’, true);
// in some setups HTTP_X_FORWARDED_PROTO might contain
// a comma-separated list e.g. http,https
// so check for https existence
if (strpos($_SERVER[’HTTP_X_FORWARDED_PROTO’], ’https’) !== false)
$_SERVER[’HTTPS’]=’on’;

Do you need help to add SSL and let’s encrypt for your current varnish setups? Feel free to contact us 

Adminor also offers ready-made VM images with Let’s encrypt varnish proxies for our VPS customers.

Supersnabb WordPress installation på Adminor SSDVPS

Det första du behöver är en SSDVPS från Adminor (även om det går bra med andra leverantörer också så rekommenderar vi våra tjänster)

SSDVPS:en ska köra Ubuntu 14.04 LTS för att denna guide ska vara kompatibelt.
Vi kommer använda oss utav Zach Adams guide för att installera en miljö med följande komponenter:

Percona DB (MySQL) (Looking for MariaDB? Try this)
HHVM (Default PHP Parser)
PHP-FPM (Backup PHP Parser)
Nginx
Varnish (Running by default)
Memcached and APC
Clean WordPress Install (Latest Version)
WP-CLI

 

Installation

  1. SSH:a till din nyligen skapade server, lägg till nödväntiga apt paket om dessa redan inte är installerade:
    sudo apt-get install software-properties-common
  2. Lägg till Ansible med sudo add-apt-repository ppa:ansible/ansible
  3. Uppdatera Apt med sudo apt-get update && sudo apt-get upgrade
  4. Installera Git oc Ansible med sudo apt-get install ansible git
  5. Klona detta repository med git clone https://github.com/zach-adams/hgv-deploy-full/
  6. Flytta in till  cd hgv-deploy-full
  7. Editera hosts filen och ändra yourhostname.com till ditt eget hostname. Om du har fler siter på denna server så lägg till varje domän på en ny rad.
  8. Editera yourhostname.com filen in host_vars katalogen till ditt eget hostname. Om du vill installera fler siter på denna server så ska du kopiera den nuvarande och byta namn på den till den andra sitens domän .
  9. Ändra site specifik information inklusive lösenord innuti hostname filen i host_vars katalogen
  10. Kör Ansible med sudo ansible-playbook -i hosts playbook.yml -c local. Får du några fel så kontakta oss så kanske vi kan hjälpa till.
  11. Ta bort den klonade git katalogen från din server med rm -rf hgv-deploy-full/
  12. Kör /usr/bin/mysql_secure_installation för att installera MySQL och säkra det. Ditt root-lösenord är tomt från början.
  13. Starta om Varnish och Nginx med: sudo service varnish restart && sudo service nginx restart
  14. Du bör nu vara klar! En ny WordPress installation som kör HHVM och Varnish bör nu vara klar i hostname/s!

 

Hur man installerar en Ny Site / Hostname

Dessa steg funkar bara om du installerat med metoden ovan. Ta alltid en backup på din server innan du gör ändringar!

  1. Ta en backup
  2. Följ steg 1-6 ovan
  3. När du kommer till din hosts fil följ samma steg MEN dinkludera inga tidigare installationer av WordPress eller hostnames, bara de nya du vill installera.
  4. Upprepa detta för din host_var katalog
  5. Följ steg  9-12 och får du några problem så kan du kontakta oss så kanske vi kan hjälpa till.

Hur man stänger av Varnish (använd bara Nginx)

Om du får problem att ändra eller får problem med backend när du använder Varnish så kan du stänga av det och bara använda Nginx. Du bör fortfarande få relativt god prestanda. Så här gör du det:

  1. Öppna varje konfiguration i Nginx för siter du har installerat på din server med kommandot: sudo nano /etc/nginx/sites-available/your-hostname.com
  2. Ändra listen = 8080; till listen = 80;
  3. Gör detta för alla siter som är installerade på servern
  4. Stoppa Varnish och Starta om Nginx med sudo service varnish stop && sudo service nginx restart
  5. Du bör nu vara klar! Har du ingen cache plugin för wordpress installerat så rekommenderar vi att du skaffar en.

Växla från HHVM tillbaka till PHP-FPM

Din Nginx konfiguration bör växla automatiskt till PHP-FPM om det uppstår problem med HHVM, du kan däremot växla manuellt om du behöver göra det:

  1. Öppna din Nginx konfigurationsfil med  vim|emacs|nano /etc/nginx/sites-available/( Your Hostname )
  2. Ändra följande sektion i slutet av filen:
    location ~ \.php$ {
        proxy_intercept_errors on;
        error_page 500 501 502 503 = @fallback;
        fastcgi_buffers 8 256k;
        fastcgi_buffer_size 128k;
        fastcgi_intercept_errors on;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass hhvm;
    }
  1. Ändra fastcgi_pass hhvm; till fastcgi_pass php;
  2. Starta om Nginx med sudo service nginx restart
  3. Du bör nu köra PHP-FPM! Kontrollera med phpinfo(); i en php fil

Vill du att vi installerar åt dig så erbjuder vi konfigurationstjänst. Kontakta oss på [email protected] för offert!

 

Varnish cache – en case-studie

En kväll blev Adminor uppringd av en webbportal som hade ett akut problem.

Problemet
Deras sida hade legat nere under halva dagen och mesta delen av kvällen. När sidan väl var uppe tog det över 10 sekunder för sidan att ladda.
Mesta dels var problemet självförvållat genom ökande popularitet av deras webbsida.

De var i akut behov av att lösa problemen men hade inte möjlighet att byta server snabbt på grund av budgetbegränsningar och intern miljö.
På mjukvarusidan fanns en vanlig WordPress installation på en Apache webbserver och MySQL-databas. Utöver det hade dom själva redan försökt lösa problemet genom att köra wordpress cache plugin.

En till synes omöjlig uppgift när budget begränsar och det inte fanns mycket man kan göra på mjukvarusidan.

Förberedelser

Det första vi tittade på var serverinställningarna på Apache och MySQL. Vi kunde dock inte se några underligheter utan inställningarna var rätt hyffsade. Det var helt enkelt så att de måste frigöra resurser på något vis, antingen genom att köpa in ny  hårdvara eller förbättra applikationen.
Vi kom då med ett tredje förslaget att istället implementera Varnish som en caching proxy framför deras webbportal. På så vis skulle man kunna cacha de dynamiska förfrågningarna.

Felåtgärd

Ofta måste man göra en fullständig undersökning av kundens miljö eftersom man inte vill orsaka problem med att ändra inställningar för server.
I detta fall var det ganska enkelt när servern bara har en site som körs och sidan ändå var nere mera än den var uppe pga det höga trycket.

Vi körde därför igång på direkten. Det första vi gjorde var att göra en snabbanalys. Detta gjorde vi genom att installera grafverktyg och statistikinsamling på det systemet som var berört.

Adminor identifierade det material som MÅSTE vara dynamiskt och vilket material som kunde cachas. Det visar sig att allt förstasidematerial och dess undersidor med enkelhet kunde cachas i åtminstone 10 minuter. Restererande material som publikationsdel och administrationssidor fick inte cachas.
Sen diskuterade vi med kunden om detta verkade överenstämma. Att installera Varnish är rätt enkelt så 2h efter att kunden först tog kontakt så var en lösning färdigimplementerad.

Resultat

Graferna nedan visar de första 20 minutrarna då vi precis installerat övervakningen och sen den kraftiga resursminskning efteråt när Varnish aktiverats.


Datapunkterna på CPU-grafen visar iowait, user och system CPU-utnyttjande som låg långt över det rekommenderade. Minnesanvändningen låg över det som fanns fysiskt installerat så att server var tvungen att swappa (läsa / skriva från långsammare diskminne).
Efter Varnish-installationen så har CPU användningen minskat från >100%  till endast en 1/4 del utav de tillgängliga resurserna som högsta nivå under dagarna. Minnesgrafer är nu jämn under dagarna med avtagande ökning (normalt och hälsosamt) istället för den kaotiska höga commit nivån (5.96GB!) som låg ovanför den fysiska gränsen i början av datapunkterna.

Det ska nämnas att innan Varnish implemeterades kunde portalen endast ta emot ett tjugotal samtidiga besökare. Efter förändringen så gjorde vi ett lasttest som visade att det nu var serverns bandbreddsanslutning som kommer begränsa – men det är långt tills dess. Detta ger nu portalen en hel del utrymme att växa i utan att öka sina serverkostnader!
Efter Varnish togs i bruk laddades 100% av besökarna under 0.5sekunder enligt apache benchmark statistik.

Kommando: ab -n 1000 -c 5 http://www.domain.se/

This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.domain.se (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software:        Apache/2.2.9
Server Hostname:        www.domain.se
Server Port:            80

Document Path:          /
Document Length:        71552 bytes

Concurrency Level:      5
Time taken for tests:   57.714 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      72030893 bytes
HTML transferred:       71552000 bytes
Requests per second:    17.33 [#/sec] (mean)
Time per request:       288.570 [ms] (mean)
Time per request:       57.714 [ms] (mean, across all concurrent requests)
Transfer rate:          1218.82 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       39   40   0.6     40      51
Processing:   202  248  77.6    204     447
Waiting:       40   41   2.7     41     112
Total:        241  288  77.6    244     487

Percentage of the requests served within a certain time (ms)
  50%    244
  66%    245
  75%    256
  80%    407
  90%    444
  95%    446
  98%    447
  99%    448
 100%    487 (longest request)

I nästa blogg-inlägg kommer jag gå igenom vilka Varnish konfigurations & VCL-regler vi fick definera – vad man måste göra för att få en cache att fungera och vilka undantag som måste göras för respektive del för att dynamiskt material ska fungera korrekt.

Kompetens – HTTP, server- och webboptimering

Adminor erbjuder redan idag expertis inom cache- och reverseproxy lösningar så som nginx, Varnish och Squid. Därför är det inte mer än rätt att vi snart kommer publicera våra första blogg-artiklar om olika cache- och reverseproxies.

Först ut kommer vi vara med att gå igenom varnish, dess funktion, hur vcl:erna fungerar och hur exempel på vart det används. Vi kommer steg för steg gå igenom hur man kan förbättra prestanda på webbsidor och på så vis minska belastningen på servrar, förbättra upplevelsen för besökare samt göra bakomliggande infrastrukturer mer kostnadseffektiva.

Senare kommer vi även beröra hur nginx och mindre kända lösningar som POUND – REVERSE-PROXY AND LOAD-BALANCER kan användas för att utöka funktionaliteten av de olika programmen.
T.ex. kommer vi gå igenom hur man får Varnish att fungera bakom SSL-siter (https) genom att använda antingen nginx eller Pound , för och nackdelar med endera lösning.

I en senare bloggartikel kommer vi även belysa på vilket sätt proxylösningar kan förbättra säkerheten för webbsidan och dess besökare.