Hallo,
ich versuche gerade Werkzeug mit meinem Apache zum Laufen zu bekommen und finde leider nirgendwo eine Anleitung, die mir beschreibt, wie das geht (egal ob mod_wsgi, mod_fcgi oder mod_python).
Gibt es hierzu eine Anleitung oder eine Beispielkonfiguration für den Apache (prefork)?
Danke!
Anleitung für Werkzeug und Apache
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Ja, in der Dokumentation.SchneiderWeisse hat geschrieben:Gibt es hierzu eine Anleitung oder eine Beispielkonfiguration für den Apache (prefork)?
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
- veers
- User
- Beiträge: 1219
- Registriert: Mittwoch 28. Februar 2007, 20:01
- Wohnort: Zürich (CH)
- Kontaktdaten:
Bin ich eigentlich der Einzige welcher seine Applikationen mit einem internen Webserver betreibt (Cherrypy's wsgi server) und dann den Apache einfach als Proxy verwendet? Bin mit dem deployment bisher am besten gefahren
[url=http://29a.ch/]My Website - 29a.ch[/url]
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Bei mir wird der FCGI-Daemon von mod_fcgid automatisch getstartet etc, das scheint mir wartungsärmer zu sein und ih fahre damit seit mehreren Jahren recht anständig.veers hat geschrieben:Bin ich eigentlich der Einzige welcher seine Applikationen mit einem internen Webserver betreibt (Cherrypy's wsgi server) und dann den Apache einfach als Proxy verwendet?
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
- veers
- User
- Beiträge: 1219
- Registriert: Mittwoch 28. Februar 2007, 20:01
- Wohnort: Zürich (CH)
- Kontaktdaten:
Weil sie verschiedene Aufgaben haben?lunar hat geschrieben:Warum zwei Deamons starten und überwachen, wenn es auch einer tut?
Und was fcgi angeht, hat zumindest mit lighty immer wieder zu komischen Problemen geführt und ich seh nicht ganz ein warum man noch ein weiteres Protokol braucht wo http doch die Funktionalität auch bietet.
[url=http://29a.ch/]My Website - 29a.ch[/url]
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
Das hängt von der Definition der Aufgaben ab.veers hat geschrieben:Weil sie verschiedene Aufgaben haben?lunar hat geschrieben:Warum zwei Deamons starten und überwachen, wenn es auch einer tut?
FCGI ist binär, so dass Header und ähnliches schneller übertragen werden und nicht nochmal auf der Gegenseite geparst werden müssen. Außerdem filtert FCGI gemäß der CGI-Spezifikation, und lässt z.B. HTTP-Authentication-Header nicht durch. In Shared-Hosting-Umgebungen, die nicht über separate Domains repräsentiert werden, kann es ansonsten nämlich zu ungewollten Information Leaks kommen. HTTP kann das nicht, und ich bin mir nicht sicher, ob der Apache HTTP-Header aus Anfragen filtern kann.Und was fcgi angeht, hat zumindest mit lighty immer wieder zu komischen Problemen geführt und ich seh nicht ganz ein warum man noch ein weiteres Protokol braucht wo http doch die Funktionalität auch bietet.
Zu Paste-/Prä-Werkzeug-Zeiten habe ich meine Apps zeitweise hinter Apache über FastCGI und SCGI als auch über den Paste-HTTPd betrieben. Mittlerweile nutze ich seit vielen Monaten mod_wsgi.
Bei mod_wsgi und mod_fcgid/mod_fastcgi(?) gefällt mir, dass die Prozesse automatisch gestartet werden. Wenn der Server mal abraucht und neu gestartet wird, ist alles wieder da.
Separat per SCGI oder Paste betrieben hat wiederum den kleinen Vorteil, dass die Applikation nicht bei einem (etwa konfigurationsbedingten) Neustart ebenfalls neu hochgezogen werden muss. Da die ohne den Apachen in der Zeit allerdings sowieso nicht von Außen erreichbar sind, fällt das wohl noch weniger ins Gewicht
Bei mod_wsgi und mod_fcgid/mod_fastcgi(?) gefällt mir, dass die Prozesse automatisch gestartet werden. Wenn der Server mal abraucht und neu gestartet wird, ist alles wieder da.
Separat per SCGI oder Paste betrieben hat wiederum den kleinen Vorteil, dass die Applikation nicht bei einem (etwa konfigurationsbedingten) Neustart ebenfalls neu hochgezogen werden muss. Da die ohne den Apachen in der Zeit allerdings sowieso nicht von Außen erreichbar sind, fällt das wohl noch weniger ins Gewicht
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Ja, noch dazu ist Lightys suEXEC, execwrap nocht etwas broken und hat sich nicht für meine Aufgaben geeignet. Habe dann den Server durch Apache ersetzt und muss sagen, dass ich seitdem zufriedener bin (zudem noch später eine Recht seltsame Konfiguration gefahren werden musste bei der ich nicht weiß ob Lighty das überhaupt unterstützt hätte).veers hat geschrieben:Und was fcgi angeht, hat zumindest mit lighty immer wieder zu komischen Problemen geführt
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Die wollte ich auch mal probieren, aber bisher läuft der gute alte Apache zu gut. Vielleicht in einer anderen VMY0Gi hat geschrieben:Bleiben noch nginx und Cherokee.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
- veers
- User
- Beiträge: 1219
- Registriert: Mittwoch 28. Februar 2007, 20:01
- Wohnort: Zürich (CH)
- Kontaktdaten:
Ja, nginx soll auch wsgi support haben. Wäre evtl echt einen Versuch Wert. Wobei ich im Moment einfach keinen Grund dazu sehe. Die Performance reicht bei weitem, die Sache ist stabil und relativ einfach zu Konfigurieren.
[url=http://29a.ch/]My Website - 29a.ch[/url]
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
Jop, nginx hat auch ein mod_wsgi. Wie Lighty soll er bei statischen Dateien äußerst flott sein. Ich komme allerdings auch nicht von Apache weg, weil alles 1a läuft. Ungenutze Module sollte man vorzugsweise auskommentieren, sich die Config mal genau vornehmen und - wenn man auf mod_php verzichten kann (*hust* Threadsicherheit *hust*) - den apache2-mpm-worker anstatt -prefork verwenden.