Introduktion till Nginx

Om den duger Ät Facebook, Instagram, Dropbox, Netflix, WordPress.com och NASA sÄ duger den troligtvis Àven Ät dig. Nginx Àr webbservern som driver 15% av vÀrldens hemsidor (och ökande) och dÀribland flera av vÀrldens mest trafikerade sÄdana.

I den hÀr artikeln kommer jag att berÀtta om vad Nginx Àr, hur den fungerar, hur man installerar den pÄ Debian och till slut hur den konfigureras för att helt ersÀtta Apache.

Vad Àr Nginx?

Nginx Ă€r — precis som Apache — en Linux-baserad webbserver, men som uttalas “Engine X” och inget annat (jag gick tyvĂ€rr runt i nĂ€stan en vecka och sade “En-Ginks” innan jag upptĂ€ckte detta). Om du Ă€r osĂ€ker pĂ„ vilken webbserver du anvĂ€nder sĂ„ Ă€r det troligast Apache, som Ă€r vanligast till 65%.

Det som skiljer Nginx frÄn de flesta andra webbservrar Àr dess prestanda och effektivitet. Tester visar att den kan prestera 46% snabbare och 177% effektivare, men nÀr det kommer till att skicka statiska filer till webblÀsare visar tester pÄ hela 65% bÀttre prestanda.

Nginx kan Àven fungera som en omvÀnd proxy-server och belastningsutjÀmnare som tar emot alla anrop och delar upp dem till en eller flera andra servrar. Detta kommer jag dock inte gÄ igenom i den hÀr artikeln.

Hur fungerar Nginx?

Den största anledningen till att Nginx presterar sÄ mycket bÀttre Àn Apache och de flesta andra webbservrar Àr hur det Àr uppbyggt i grunden. Apache Àr en sÄ kallad processdriven webbserver (ibland trÄddriven beroende pÄ konfiguration), vilket innebÀr att det skapas en ny process för varje anrop. Processerna Àr oberoende av varandra och har en egen del av minnet pÄ servern, och pÄ sÄ vis krÀver Apache mycket minne för att kunna prestera bra.

Ifall det maximala antalet processer Àr uppnÄtt, eller om minnet inte rÀcker till, blockerar Apache nya anrop tills det finns resurser att hantera dem. Apache blockerar Àven upp nÀr den vÀntar pÄ resultat frÄn exempelvis ett PHP-skript. Dessa avbrott rör sig oftast bara om millisekunder, men med mÄnga bÀckar smÄ kan servern bli lÄngsam under hög trafik.

Nginx Ă€r dock uppbyggt pĂ„ ett annorlunda sĂ€tt dĂ€r i princip allting Ă€r hĂ€ndelsebaserat. Det finns en eller flera sĂ„ kallade “workers” som delar pĂ„ minnet (som dĂ€rmed kan vara minimalt) och kan ta hand om flera tusen besökare var. IstĂ€llet för att göra som Apache?s processer och vĂ€nta pĂ„ att nĂ„gonting ska hĂ€nda (till exempel pĂ„ att ett skript ska köras klart) sĂ„ ber workern istĂ€llet skriptet att sĂ€ga till nĂ€r det finns ett resultat — under tiden tar workern hand om nĂ„gon annan. DĂ€rmed Ă€r Nginx icke-blockerande.

Observera att en besökare oftast gör flera anrop i följd; först för HTML-dokumentet, sedan ett anrop för varje bild, stilmall, JavaScript-fil och speciella typsnitt. Det Àr inte ovanligt att det tillsammans blir 50 anrop per besökare och sida, pÄ vissa webbplatser Ànnu fler.

UngefÀr sÄ hÀr kan det gÄ till nÀr Apache tar hand om sina besökare:

1. En besökare anlÀnder och gör ett anrop mot servern.
2. Apache skapar en process för besökaren.
3. Processen plockar fram det dokument som har blivit anropat.
4. Dokumentet innehÄller PHP-kod som körs. Processen vÀntar pÄ att koden ska köras klart och skickar sedan resultatet till besökaren, dÀrefter dör processen.
5. Dokumentet innehÄller en bild som mÄste hÀmtas. Denna gÄng finns det ingen ledig plats för en ny process. Anropet fÄr vÀnta pÄ sin tur, dÀrefter plockas bilden fram och skickas till besökaren.

HÀr Àr samma exempel fast med Nginx som webbserver som har blivit konfigurerad att bara anvÀnda en worker:

1. En besökare anlÀnder och gör ett anrop mot servern.
2. Nginx ger anropet till sin worker.
3. Workern plockar fram det dokument som har blivit anropat.
4. Dokumentet innehÄller PHP-kod som körs. Under tiden tar workern hand om nÀsta besökare. NÀr koden Àr klar skickas resultatet till workern och sedan till besökaren.
5. Eftersom workern aldrig vÀntar pÄ nÄgot sÄ har den tid med att plocka fram en bild och skicka till besökaren trots att den samtidigt tar hand om flera andra besökare.

Det kan vara mycket information att ta till sig, sÄ titta gÀrna pÄ illustrationerna ovan och jÀmför det som pÄgÄr. Illustrationerna Àr vÀldigt förenklade, om du vill fördjupa dig mer i hur Nginx fungerar rekommenderar jag den hÀr artikeln.

Kort sagt kan man beskriva Nginx som en multi-tasker som hÄller flera bollar i luften samtidigt, medan Apache gÀrna gör en sak i taget.

Hur man installerar Nginx

Installationen av Nginx Ă€r ganska enkel. Detta förutsĂ€tter att du kör Debian pĂ„ din server och kan nĂ„ den via SSH — jag anvĂ€nder personligen Putty för detta Ă€ndamĂ„l, och en textredigerare med SFTP-Ă„tkomst för att Ă€ndra i konfigurationsfiler.

Om du har Apache bör du inaktivera det och/eller avinstallera det innan du börjar installationen av Nginx.

1. Ändring av sources.list

Öppna upp filen /etc/apt/sources.list och lĂ€gg till följande rader:

deb https://nginx.org/packages/debian/ squeeze nginx
deb-src https://nginx.org/packages/debian/ squeeze nginx

Detta gör sÄ att du kommer ladda hem rÀtt version av Nginx i det tredje steget.

2. Uppdatera alla paket

Det Àr en god vana att uppdatera alla paket pÄ din server till den senaste versionen innan du installerar nÄgot nytt. Det gör du med dessa tvÄ kommandon:

apt-get update
apt-get upgrade

3. Installation

Beroende pĂ„ vilka moduler du behöver sĂ„ finns det tre olika paket att vĂ€lja mellan; nginx-light, nginx-full och nginx-extras. VĂ€lj mittenvarianten om du inte har nĂ„gra speciella behov:

apt-get install nginx-full

4. Starta Nginx

Webbservern startar inte automatiskt efter installationen. För att starta Nginx sÄ kör du följande kommando:

service nginx start

Vid behov kan du Ă€ven stoppa och starta om webbservern med service nginx stop respektive service nginx restart.

5. Titta sÄ att det fungerar

Öppna din favoritwebblĂ€sare och surfa in pĂ„ din IP-adress. DĂ€r bör du fĂ„ ett varmt vĂ€lkomnande av din nya webbserver.

PHP dÄ?

Nginx stödjer inte PHP frÄn grunden (vilket Apache inte heller gör för den delen) och mÄste installeras Àven det. Det finns olika sÀtt och paket att installera för att fÄ stöd för PHP, min favorit Àr PHP-FPM som Àr snabbt och dÀrför gÄr vÀldigt bra ihop med Nginx. Observera att detta paket inte finns i Debian Squeeze, dÀrför behöver du ha Debian Wheezy installerat.

apt-get install php5-fpm

DÀrefter behöver du lÀgga in en kodsnutt i konfigurationen för din webbplats som skickar PHP-filer till PHP-FPM. Hur du gör detta förklarar jag nedan.

Konfiguration av Nginx

Enligt mig Ă€r det bĂ€sta med Nginx, bortsett frĂ„n prestandan, konfigurationen — den Ă€r mycket enklare och överskĂ„dligare Ă€n Apache?s. Och .htaccess-filerna? Glöm dem — inte bara Ă€r de onödigt lĂ„nga och fula, utan de stjĂ€l Ă€ven prestanda frĂ„n servern nĂ€r den tvingas leta efter .htaccess-filer i hela sökvĂ€gens mappar för varje anrop.

HÀr kommer jag bara gÄ igenom det nödvÀndigaste i Nginx?s konfiguration, resten finns vÀl dokumenterat.

Huvudkonfigurationen

Konfigurationen för Nginx ligger i /etc/nginx/nginx.conf. Det enda vi ska titta pĂ„ Ă€r de hĂ€r raderna i början:

worker_processes 4;
pid /var/run/nginx.pid;

events {
    worker_connections 768;
}

Den första raden, worker_processes, bestĂ€mmer hur mĂ„nga workers Nginx ska anvĂ€nda sig av. Man brukar sĂ€ga att detta vĂ€rde ska vara lika med antalet kĂ€rnor serverns processor har. Om du Ă€r osĂ€ker kan du lĂ€mna det som det Ă€r.

Den andra raden anger vart processens ID ska sparas, den raden behöver du inte röra.

Sedan kommer vi till worker_connections som ligger inom events. Det hĂ€r vĂ€rdet avgör hur mĂ„nga anrop en worker ska kunna hantera samtidigt. Att öka vĂ€rdet gör inte Nginx automatiskt snabbare, utan det fungerar som ett skydd sĂ„ att servern inte ska hantera fler anrop Ă€n vad den klarar av. Vi kan enkelt rĂ€kna ut hur mĂ„nga anrop Nginx ska klara av samtidigt genom att multiplicera det hĂ€r vĂ€rdet med antalet workers — i det hĂ€r fallet blir det 3072 anrop. Ifall du inte rĂ€knar med att ha fler samtida anrop Ă€n sĂ„ behöver du inte öka vĂ€rdet för worker_connections.

Nginx behöver inte startas om för att konfigurationen ska börjar gĂ€lla — man kan istĂ€llet blixtsnabbt ladda om konfigurationen.

nginx -t
service nginx reload

Det första kommandot kontrollerar din konfiguration sĂ„ att inget Ă€r fel — kör alltid den innan du laddar om konfigurationen med det andra kommandot.

Konfiguration av webbplatser

Nginx hanterar flera sajter pÄ ett vÀldigt snyggt sÀtt, och det Àr denna del som ersÀtter Apache?s .htaccess-filer.

I mappen /etc/nginx/sites-available lĂ€gger man konfigurationsfiler för olika sajter. I mitt fall kan jag ha en fil dĂ€r som heter webbmekanikern.se.conf med följande innehĂ„ll:

server {

    # Definiera domÀnnamn
    server_name www.webbmekanikern.se;

    # Definiera loggar
    access_log off;
    error_log /var/log/webbmekanikern.se.error.log crit;

    # Definiera root-katalog
    root /var/www/webbmekanikern.se;

    # Prioritera index-filer i följande ordning
    index index.php index.html index.htm;

    # Skicka PHP-filer till PHP-FPM
    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_index  index.php;
        fastcgi_pass   unix:/var/run/php5-fpm.sock;
        include        fastcgi_params;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        fastcgi_param  SCRIPT_NAME      $fastcgi_script_name;
    }

}

Som du ser Ă€r det vĂ€ldigt överskĂ„dligt och ganska enkelt att förstĂ„. Först definierar jag mitt domĂ€nnamn “www.webbmekanikern.se” som gör att just denna konfiguration endast gĂ€ller för denna domĂ€n. DĂ€refter stĂ€nger jag av Ă„tkomst-loggen (som annars loggar en textstrĂ€ng för varje anrop) och berĂ€ttar var loggen för felmeddelanden ska ligga.

Hela webbplatsens innehĂ„ll kommer ligga i /var/www/webbmekanikern.se, sĂ„ det sĂ€tter jag som root-katalog. NĂ€r nĂ„gon gĂ„r in pĂ„ webbplatsen (eller gĂ„r in i en mapp) sĂ„ ska index.php laddas i första hand, om inte den finns sĂ„ laddas index.html eller index.htm.

Sedan kommer den kod som skickar alla PHP-filer till PHP-FPM. Kodsnutten location ~ \.php$ gör en matchning av ett reguljĂ€rt uttryck, i det hĂ€r fallet \.php$ som betyder allt som slutar pĂ„ “.php”. Med andra ord kommer alla filer som slutar pĂ„ .php att skickas till PHP-FPM.

Nu Ă€r det dags att hoppa till server-rooten (cd /) och aktivera konfigurationen med följande kommando (en rad):

ln -s /etc/nginx/sites-available/webbmekanikern.se.conf /etc/nginx/sites-enabled/webbmekanikern.se.conf

Detta kommer att skapa en symbolisk lĂ€nk i mappen /etc/nginx/sites-enabled, vilket aktiverar konfigurationen. Om du nĂ„gon gĂ„ng i framtiden vill inaktivera konfigurationen sĂ„ gĂ„r du bara till mappen och plockar bort lĂ€nken — sjĂ€lva filen kommer ligga kvar i /etc/nginx/sites-available.

Ladda om konfigurationen och du har en fungerande webbplats (förutsatt att du har lagt nĂ„gra filer i /var/www/webbmekanikern.se).

Observera att denna konfiguration inte kommer gĂ€lla för besökare som har skrivit “webbmekanikern.se” i webblĂ€saren (alltsĂ„ utan “www”). Detta Ă€r en miss som mĂ„nga webbutvecklare gör som dock Ă€r vĂ€ldigt enkel att lösa. Jag ska i samma veva Ă€ven lösa problemet med att vissa stavar webb med ett B istĂ€llet för tvĂ„, vilket egentligen Ă€r en olĂ€mplig stavning, men för att inte förvirra besökare har jag Ă€ven köpt domĂ€nen “webmekanikern.se” och pekat den mot samma server.

LĂ€gg nedanstĂ„ende kod högst upp i filen och ladda sedan om konfigurationen med nginx -t följt av service nginx reload. Observera att server-blocket Ă€r ett eget block och ska inte förvĂ€xlas med det tidigare server-blocket i den hĂ€r artikeln.

server {

    # Skicka besökare till rÀtt domÀn
    server_name webbmekanikern.se webmekanikern.se www.webmekanikern.se;
    return 301 https://www.webbmekanikern.se$request_uri;

}

Mycket snyggt. JÀmför det med hur det skulle ha sett ut i Apache?s .htaccess-fil:

RewriteEngine On

RewriteCond %{HTTP_HOST} ^webbmekanikern\.se$ [OR]
RewriteCond %{HTTP_HOST} ^webmekanikern\.se$ [OR]
RewriteCond %{HTTP_HOST} ^www\.webmekanikern\.se$
RewriteRule ^(.*)$ https://www.webbmekanikern.se/$1 [R=301,L]

Inte alls lika snyggt enligt min mening, men det fungerar.

Slutord

Sedan jag gick över till Nginx kommer jag att vÀlja det framför Apache sÄ ofta jag kan. Jag rekommenderar det Àven till mina kunder som har egna servrar. Webbhotell anvÀnder sig dock oftast av Apache, och sÄ kommer det troligtvis vara ett tag till.

Vad tycker du om Nginx?