Python und Webserver

[Judge]

Hallo zusammen,

ich kann leider weder im Web, noch hier im Forum eine klare Antwort zu folgender Frage finden:

Wenn man mit Python Websites oder Web basierende Apps erstellen und betreiben möchte, wie findet die Integration in die beiden verbreitetsten Webserver (Apache HTTPd und Nginx) dann nach aktuellem Stand der Technik am besten statt? Was den Apache HTTPd angeht: Ich lese irgendwie ziemlich gleichberechtigt im Web alles, von mod_python über WSGI bis hin zum "ruby-quasi-Standard" Passenger.
Was Nginx angeht, da bin ich ehrlich gesagt noch nicht eingestiegen, da ich mich damit überhaupt noch nicht auskenne und ohne klare Empfehlung von Leuten, die wissen wovon sie reden, mich da auch nicht herantraue.

Mit "am besten" meine ich, das es nicht wichtig ist, wieviel Aufwand betreiben werden muss, damit die benannte Lösung läuft, sondern das das Ergebnis in erster Linie reif für den produktiven Einsatz ist. Bedeutet: Es muss stabil sein, weder durch DoS oder sonstige Attacken leicht in die Knie zu zwingen oder gar einzubrechen sein und die Performance sollte die gut sein.

Ich erwarte hier nicht, das man mich an die Hand nimmt und mir alles vorkaut, so das ich nur noch eine Config C&P muss. Ich erhoffe mir vielmehr, das mir die erfahrenen Pythonianer hier ein Stichwort geben, was Ihrer Erfahrung nach am besten funktioniert, so das ich dann in dieser Richtung selbstständig weiter recherchieren kann.

Vielen Dank schonmal für's lesen und ich freue mich auf Eure Antworten!

[BlackJack]

@Judge: *Die* Schnittstelle ist momentan WSGI. Also beim Apache zum Beispiel über `mod_wsgi`. `mod_python` ist tot, das wird nicht mehr weiterentwickelt und ist deshalb beim Apache-Project im sogenannten „attic” (dt. „Dachboden”) gelandet und verstaubt da vor sich hin. [1]

`mod_wsgi` ist auch relativ einfach zu benutzen und für die gängigen Webrahmenwerke findet sich jeweils eine Anleitung wie man das einbindet. In den meisten Fällen sogar direkt in der Dokumentation des Webrahmenwerkes, da muss man also nicht einmal lange nach suchen.

Typische Form wie ich (Bottle-)Anwendungen einbinde sind vier Zeilen in der Apache-Konfiguration:

Code: Alles auswählen

WSGIDaemonProcess project_name processes=1 threads=2 display-name=%{GROUP}
WSGIProcessGroup project_name
WSGIScriptAlias /project_name /var/www/project_name/app.wsgi
Alias /project_name/static/ /var/www/project_name/static/ 

Die letzte Zeile damit der Apache die statischen Inhalte direkt ausliefert statt den Umweg über die Webanwendung zu gehen.

[1] Der ursprüngliche Entwickler hat das zwar neulich mal „wiederentdeckt”, aber seine Aussagen dazu waren etwas merkwürdig. IMHO wird das nicht wieder auferstehen.

[seishin]

Mittlerweile gibt es da zum apache2 mit mod_wsgi noch folgende sehr gern genommen Konstellation: gunicorn mit nginx.

Gunicorn 'Green Unicorn' is a Python WSGI HTTP Server for UNIX. ... The Gunicorn server is broadly compatible with various web frameworks, simply implemented, light on server resources, and fairly speedy.

*

*http://gunicorn.org/

Hier mal ein kleines Tutorial: Setting up Django with gunicorn and nginx. http://michal.karzynski.pl/blog/2013/06 ... upervisor/

Selbst benutzte ich einige Zeit apache2 mit mod_wsgi. Wechselte aber vor kurzem (ca. 1 Monaten) komplett auf gunicorn mit nginx, fühlt sich um einiges performanter an. Deployment ist einmal Aufwand (Konfiguration siehe Tutorial) und dann nur noch git pull... virtualenv kommt hier ganz wunderbar zum tragen.

Der Performance-Unterschied, an sich so weit meine Recherchen nur zwischen apache2 und nginx...
Wobei auch zu beachten ist das nginx weniger Ressourcen verbraucht.

Hier mal eine allgemeine Frage von mir auf dem Board: http://www.python-forum.de/viewtopic.php?f=5&t=32254


Ist denke ich Geschmackssache.

[Judge]

Huch, seid ihr schnell! Vielen Dank erstmal für die ersten beiden Meinungen, auf die ich gerne eingehen würde:

@Judge: *Die* Schnittstelle ist momentan WSGI. Also beim Apache zum Beispiel über `mod_wsgi`. `mod_python` ist tot, das wird nicht mehr weiterentwickelt und ist deshalb beim Apache-Project im sogenannten „attic” (dt. „Dachboden”) gelandet und verstaubt da vor sich hin. [1]

...

[1] Der ursprüngliche Entwickler hat das zwar neulich mal „wiederentdeckt”, aber seine Aussagen dazu waren etwas merkwürdig. IMHO wird das nicht wieder auferstehen.

Ja, das Wissen dachte ich auch mal zu haben, vor ein paar Monaten. Halte ich auch nach wie vor nicht für 'ne alte Info, nur gerade heute sehe ich auf http://modpython.org/ das die am 25.10.2013 'ne neue Version rausgebracht haben. War mir dessen also nicht mehr so sicher, ob ich das richtig abgelegt hatte.
Wegen dem WSGI-Rest: Vielen Dank dafür! Bietet mir einen guten Ansatzpunkt!

Mittlerweile gibt es da zum apache2 mit mod_wsgi noch folgende sehr gern genommen Konstellation: gunicorn mit nginx.

Gunicorn 'Green Unicorn' is a Python WSGI HTTP Server for UNIX. ... The Gunicorn server is broadly compatible with various web frameworks, simply implemented, light on server resources, and fairly speedy.

*

Yo, genau da haben wir ein gutes Beispiel für etwas, was ich nicht verstehe: Nginx ist ja selber (auch) ein inzwischen nicht gerade wenig verbreiteter Webserver; ich glaube die letzten Zahlen zum Marktanteil liegen laut Netcraft in Sachen Apache:Nginx:IIS bei 52.30% Apache, 12.86% nginx und 10.62% IIS. Warum braucht man nun nochmal einen anderen HTTP Server wie gunicorn in Verbindung mit Nginx, der ja auch ein HTTP Server ist?
Die Inhalte auf der gunicorn Projektseite wüsste ich also z.B. garnicht so recht zu werten ... kann mir das jemand erklären?

[BlackJack]

@Judge: Wie gesagt `mod_python` wurde von seinem ersten Entwickler wiederentdeckt. Und soweit ich weiss nur von ihm. Warum er da jetzt von „we” spricht — vielleicht schizophren. Und in *der* Ankündigung steht jetzt das es für Webanwendungen ist, wo er doch eigentlich sagt für Webanwendungen war das eigentlich gar nicht gedacht und dafür hat er das jetzt auch gar nicht wiederbelebt. Wofür es eigentlich gedacht ist sagt er aber auch nicht so recht und gibt auch selber zu dass er das wohl auch nicht so recht erklären kann. Sehr merkwürdig das alles.

Den Code zum neuladen und cachen von Modulen wollte er wieder rauswerfen weil er den nicht versteht. Seiner Meinung nach muss man root-Rechte haben und den kompletten Apache neustarten wenn man mit `mod_python` arbeitet und Änderungen an dem Code macht der `mod_python` verwendet. Ich sehe nicht wie man damit vernünftig Webanwendungen entwickeln soll. Zumal es mit `mod_wsgi` ja eine Alternative gibt die dediziert für Webanwendungen gedacht ist.

Du kannst Gunicorn auch direkt verwenden, aber die Entwickler empfehlen einen Proxy und da speziell nginx. Der kann beispielsweise gegen bestimmte DOS-Attacken schützen, und man kann dann auch den statischen Inhalt, wie bei meinem Apache-Beispiel, von einem „normalen” Webserver ausliefern lassen. Zum Beispiel mit dem Vorteil dass sich dann nginx um so Sachen wie Cachen und on-the-fly komprimieren kümmern kann.

Letztendlich sieht es bei Apache und `mod_wsgi` ja nicht so viel anders aus. Der Apache reicht die Anfragen auch nur an `mod_wsgi` weiter und das generiert die komplette Antwort die dann über den Apache wieder ausgeliefert wird. Der Apache dient dort auch hauptsächlich als Proxy. Nur das `mod_wsgi` enger mit Apache verbandelt ist als Gunicorn mit nginx.

Was die traditionellen Webserver noch bieten ist die Möglichkeit als Server/Proxy für mehr als eine Anwendung zu dienen und auch noch andere Inhalte statischer und dynamischer Natur auszuliefern.

[Judge]

Ah, dann nimmt Nginx in dieser Kostellation "nur" die Rolle eines Proxys ein und nicht die eines Webservers; OK, kapiert.

Nagut, dann nehme ich folgendes mit:

* Vergiss mod_python
* WSGI ist was man möchte
* Schalte einen Proxy davor, der sich um statische Inhalte, DoS Attacken und Kompression kümmert

Vielen Dank an alle für die Impressionen!