Konfigurera Nginx och Varnish

I mitt lilla projekt om att sätta upp ett eget CDN, Content Delivery Network så har jag nu konfigurerat om Nginx samt installerat Varnish. Det funkar så att Varnish ligger som gateway på port 80 och går igenom alla inkommande requests, om någon request matchar konfigurationen i Varnish så hanterar den det enligt gällande regler. För att uppnå det måste Nginx konfigureras om för att lyssna på en annan port, jag valde för enkelhetens skull port 8080.

 Om du inte redan har installerat Nginx, så finns en guide här

Konfiguration av Nginx, ändra nedan i alla dina vhostar:

Listen 8080

Det gör att Nginx kommer att lyssna på port 8080 istället för 80, det är viktigt att ställa om det på alla vhostar, annars kommer nginx eller varnish inte starta om ordentligt. vill du kan du även skriva 127.0.0.1:8080 så kommer Nginx att bara lyssna på requests som kommer internt på maskinen och inte externt, jag väljer att inte skriva det då jag vill kunna komma åt webbservern direkt externt också, i testsyften.

Installation av Varnish

Varnish finns i Debian stabels paketförråd och installeras med:

apt-get install varnish

Sedan så är det mer eller mindre klart, varnish startas med /etc/init.d/varnish och loggdemonen med /etc/varnishlog start, med största sannolikhet är de redan startade. 

Nu börjar det roliga, men samtidigt besvärliga, vad är det jag vill cacha? Jag har ett enkelt exempel där jag bara cachar statiska filer på en viss domän:

backend default {
        set backend.host = “127.0.0.1″;
        set backend.port = “8080″;
}

sub vcl_recv {
           if (req.http.host ~ “http://cdn.sngw.se“) {
             pass;
           } else {
             if (req.request != “GET” && req.request != “HEAD”) {
                 pipe;
             }
             if (req.request == “POST”) {
                 pass;
             }
             if (req.request == “GET” && req.url ~ “\.(jpg|jpeg|gif|ico|png)$”) {
                 lookup;
             }
             if (req.request == “GET” && req.url ~ “\.(css|js)$”) {

 lookup;
             }

             if (req.request == “GET”) {
                 lookup;
             }
             lookup;
          }
        }
         sub vcl_pipe {
             pipe;
         }

         sub vcl_pass {
             pass;
         }

         sub vcl_hit {
             if (!obj.cacheable) {
                 pass;
             }
             if (req.http.Cookie) {
                pass;
             }
             deliver;
         }

         sub vcl_miss {

fetch;
         }

         sub vcl_fetch {
             if (!obj.valid) {
                 error;
             }
             if (!obj.cacheable) {
                 pass;
             }
             insert;
         }

         sub vcl_deliver {
             deliver;
         }

         sub vcl_timeout {
             discard;
         }

         sub vcl_discard {

     discard;

         }

 

De här reglerna  cache:ar bara statiska filer och gör ingenting konstigt med dem. Nu är du redo att fortsätta upptäcka mer fantastiska grejer med Varnish ocg nginx, lycka till!

CodeIgniter och Nginx

I sitt blogginläggCmsDirekt skriver David V. Wallin lite kort om hur man får ramverket CodeIgniter att lira på Nginx: Det är egentligen bara en rewriteregel och en liten förändring på hur man skickar sidor till php-fpm. Såhär ser  konfigurationen ut som du kompletterar din vhost med:

location /{
if (!-f $request_filename) {
rewrite ^(.*) /index.php?$1 last;
}
}
 
location ~ \.php$ {
fastcgi_pass   127.0.0.1:9000;
fastcgi_index  index.php;
include /etc/nginx/fastcgi_params;
fastcgi_param  SCRIPT_FILENAME  /var/www/example.org/index.php;
}
 

Notera att efter SCRIPT_FILENAME så skickar vi inte med variablen $FASTCGI som vi gör när vi konfigurerar för vanligt php, utan vi skickar explicit med index.php eller vilken sida man nu har som förstasida.

Kontrollera Vhostar och Redirects med Icinga

Vi har en webbserver med ett antal vhostar som vi vill övervaka, dock så kommer standardkonfigurationen till Icinga med en servicecheck som kontrollerar HTTP med hjälp av IP:t, så för att få den att kontrollera det jag vill så skriver jag om service checken till:

check_http -H $HOSTADRESS$

Det gör att check_http tar emot www.test.se istället för bara en ip, nu vill jag också kolla så att jag får den HTTP-status jag förväntar mig, detta då check_http tycker att både 200 och 301 är OK, men efter som min site inte ska redirecta(301) så vill jag att den bara ska tycka att 200 är ok, det åstadkommer jag med:

check_http -H $HOSTADDRESS$ -e 200

Där -e betyder “expect”, alltså förväntar sig checken HTTP-status 200. För att hålla koll på mina redirects så använder jag samma kontroll fast med 301 istället för 200.

För att underlätta för mig själv har jag definierat upp ett nytt kommando som heter just HTTP-redir och som bara accepterar 301 som http-status, sedan styr jag med hostgroups vilken sida som kontrolleras på vilket sätt.

Såhär ser det ut på en maskin som både har en HTTP-adress och en HTTP-redir: