Seite wählen

Nginx als lastverteilter Bild Konverter

von | Jul 12, 2011 | Linux

Der bekannte Webserver nginx, auf dem ca. 6% aller Webseiten des Internets laufen und der auch noch Reverse Proxy- und pop3/imap Proxyserver sein kann,  hat noch eine andere, oft wenig beachtete Möglichkeit. Mit Hilfe seines Image Filters ist es möglich, ihn als lastverteilten Lieferanten für Bilder zu benutzen, die er on-the-fly in andere Größen skalieren kann.

1. Lastverteilung

Nginx kann von Haus aus Anfragen an andere Webserver verteilen. Hierzu definiert man zuerst einen Upstream Server.

upstream cache_group {
server :8888 weight=100;
server 127.0.0.1:8888 weight=1;
}

Im vhost der die ersten Anfragen annimmt, definiert man dass der Webserver zuerst schaut, ob er das optimierte Bild schon hat, bzw. wenn das Original gefordert wird dieses sofort ausliefert.

server {
       listen   80;
       server_name mein_Server;
       location = /favicon.ico {
               #empty_gif;
               return 204;
       }
       location / {
               root                    /var/www/images;
               rewrite "^\/(50|100|150|200|250|300|350)\/(.*)\.(jpg|png)$" /$1/$2.$3 break;
               rewrite "^\/(.*)\.(jpg|png)" /$1.$2 break;
               error_page              404 = @cache;
       }
       location @cache {
               internal;
               proxy_pass              http://cache_group;
               proxy_store             on;
               proxy_store_access      user:rw  group:rw  all:r;
               proxy_temp_path         /var/www/temp;
               root                    /var/www/images;
       }
}

Falls der Server das Bild nicht findet schaut er, statt die error_page 404 auszugeben, in der cache_group nach. Hier greift die bei Upstream eingerichtete Gewichtung der Server. Nginx wird 100mal so oft auf dem zweiten Image Server suchen wie auf sich selbst. Wenn das Bild auch auf dem anderen Server nicht gefunden wird, wird es dort generiert. Das sorgt natürlich dafür, dass der erste Server entlastet wird. Das Verzeichnis /var/www sollte ein gemeinsames Share sein, damit das generierte Bild auch beiden Servern zur Verfügung steht.
Die im vhost eingestellten rewrite Regeln sind nötig, um unterscheiden zu können, welche Größe des Bildes angefordert wird, bzw. ob einfach das Original benutzt wird. Ruft der Client http://mein_Server/300/testbild.jpg ab bekommt er das Bild aus /var/www/images/300/testbild.jpg. Bei http://mein_Server/testbild.jpg greift die untere rewrite Regel und er kommt auf /var/www/images/testbild.jpg

2. Bildoptimierung

Der vhost für den Cache sieht folgendermaßen aus:

server {
        listen 8888;
        server_name mein_Server;
        location / {
                root                    /var/www/images/;
                error_page              404 = @local_image;
        }
        location @local_image {
                internal;
                proxy_pass              http://local_group_image;
                proxy_store             on;
                proxy_store_access      user:rw  group:rw  all:r;
                proxy_temp_path         /var/www/temp;
                root                    /var/www/images;
        }

Von hier aus springt er, falls das Bild dort nicht finden kann in den Image teil.
Hierfür muss man zunächst noch einen Upstream angeben:

upstream local_group_image {
        server 127.0.0.1:7777;
}

Und anschließend den vhost inklusive Imagefilter und Sicherheitscheck (es sollen nur die Größen erstellt werden, die wir vorher angeben) erstellen. Der Sicherheitscheck funktioniert durch den Regex in der Location Direktive.

server {
        listen 7777;
        server_name mein_Server;
        location ~ "\/(50|100|150|200|250|300|350)\/.*\.(png|jpg)$" {
                root    /var/www/images/;
                rewrite "^\/(50|100|150|200|250|300|350)\/(.*)\.(jpg|png)$" /$2.$3 break;
                image_filter resize $1 $1;
                image_filter_buffer 6M;
                image_filter_jpeg_quality 95;
        }
}

Jetzt sollte alles so funktionieren, wie wir uns das vorstellen. Das Konstrukt ist natürlich noch um weitere Server erweiterbar. Auch zusätzliche Aufgaben, wie z.B. SSL oder andere Bild Formate sind schnell integriert. Wen man so weit ist, wie hier beschrieben, hat man eine skalierbare, stabile und leicht gewichtige Lösung die mit ein wenig Mehrarbeit auch Ausfallsicher ist.

Christoph Niemann
Christoph Niemann
Senior Consultant

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

1 Kommentar

  1. someone

    „Bild Konverter“ – Deppenleerzeichen!

    Antworten

Trackbacks/Pingbacks

  1. Weekly Snap: Introducing CouchDB & Nginx, Offering Dev Job & NETWAYS Training « NETWAYS Blog - [...] put a spin on the popular Nginx for use as a load-balanced image converter. As the first step, he…

Einen Kommentar abschicken

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Mehr Beiträge zum Thema Linux

Kickstart your Laptop with Linux

Alle paar Jahre bekomme ich einen neuen Laptop bei Netways. Vor zwei Wochen war es wieder so weit und somit eine gute Gelegenheit mal wieder die Betriebssystem-Frage zu stellen. Die alte Frage also: "Welches Linux ist das Beste?". Also für mich ganz persönlich. Nicht...

Ansible – Testing roles with Molecule

Ansible is a widely used and a powerful open-source configuration and deployment management tool. It can be used for simple repetitive daily tasks or complex application deployments, therefore Ansible is able to cover mostly any situation. If used in complex or...

NETWAYS Support Collector Roadmap

Den Support Collector konnte ich bereits in meinem letzten Blogpost vorstellen. Für alle die den Beitrag verpasst haben, hier kurz umrissen was es ist: Bei dem Tool handelt es sich um einen von uns geschriebenen Datensammler, welche alle möglichen Support relevanten...