Das deutsche Python-Forum

Hallo,

@MrNiceTry: Beschäftige dich mal mit dem Grundprinzip von CGI. Das heißt vereinfacht gesagt nichts anderes als das der Webserver ein Skript ausführt. Mit den Rechten des Webservers. Und auf der IP und dem Port, auf dem der Webserver läuft. Den in Bottle integrierten Server brauchst du gar nicht.

Wenn da mit FastCGI zu schwierig ist, kannst du auch erstmal "normales" CGI nehmen. Dann brauchst du in lighttpd nur .py Dateien registrieren (ist in der Doku von lighthttpd erklärt) und den Bottle-Skript an CGI binden (ist in der Bottle Dokue erklärt).

Gruß, noisefloor

MrNiceTry hat geschrieben:Kann Bottle seine Rechte abgeben?
Oder kann man das mit Bottle machen?

Irgend etwas muß es doch geben Bottle zu benutzen, oder ?

Nein, das kann Bottle in der "offiziellen" Version nicht. Ich habe einen Patch dazu geschrieben, der genau das ermöglicht [1], weil ich die selben Anforderungen hatte. (Möglichst leicht, nicht besonders performant auf Port 80 laufend). Der Patch wurde nicht übernommen und mein Repository ist nicht gepflegt. Ich würde dir davon abraten einfach die dortige Bottle Version zu übernehmen. Du könntest aber den Patch auf die aktuelle Bottle Version portieren. Für mehr Infos gibt es einen Thread [2] dazu.

Wenn man möglichst leichtgewichtig und performant sein will, kann man statt dem WSGIRefServer den Tornado Adapter benutzen, dann ist die ganze Geschichte auch multithreaded. Damit funktioniert mein Patch aber (noch) nicht.

Alternativ kann ich dir cherokee empfehlen, den kann man ohne Einarbeitungszeit innerhalb weniger Minuten über ein Webfrontend konfigurieren und ist sehr leichtgewichtig, aber trotzdem vielseitig (uwsgi und fastCGI fähig). Das Webfrontend startet man nur zum Zweck der Konfiguration und wird anschließend beendet. Es gibt dort Assistenten für die gängigsten Aufgaben. Alles ziemlich selbsterklärend, aber halt doch wieder ein eigener Server vor dem Python-Prozess, wie bei nginx, Apache, lighttpd.

Ansonsten, wenn es ohne den Patch auskommen soll und ohne vorgeschalteten "ausgewachsenen" Webserver, habe ich sehr gute Erfahrungen mit Pound gemacht. Der macht nichts anderes als auf Port 80 zu laufen, die Anfragen entgegenzunehmen und lokal an Port 8080 (oder einen beliebigen anderen unpriviligierten Port) weiter zu reichen. Nennt sich dann http-proxy / load balancer. Da hast du dann zusätzlich zum Bottle Python Prozess noch <1 MiB im Speicher. Wenn du dann noch Bottle mit Tornado nutzt, hast du eine superschnelle und leichtgewichtige Kombi. Pound gibts im Ubuntu Repo und Tornado sind nur ein paar .py Dateien, die du in das Verzeichnis mit der bottly.py wirfst.



[1] http://github.com/uKev/bottle/commit/5c ... b3156db759
[2] http://www.python-forum.de/viewtopic.php?t=21221

uKev hat geschrieben:Alternativ kann ich dir cherokee empfehlen, den kann man ohne Einarbeitungszeit innerhalb weniger Minuten über ein Webfrontend konfigurieren und ist sehr leichtgewichtig, aber trotzdem vielseitig (uwsgi und fastCGI fähig). Das Webfrontend startet man nur zum Zweck der Konfiguration und wird anschließend beendet. Es gibt dort Assistenten für die gängigsten Aufgaben. Alles ziemlich selbsterklärend, aber halt doch wieder ein eigener Server vor dem Python-Prozess, wie bei nginx, Apache, lighttpd.

Das Problem ist, dass im Gegensatz zu Apaches mod_fastcgi/mod_fcgid sich Cherokee nicht um die FastCGI-Prozessverwaltung kümmert. Somit muss man immer selbst drauf achten dass der Prozess immer läuft. Bei Apache wird der FastCGI-Prozess mitverwaltet, so dass man dieses Problem nicht hat und Apache sich darum kümmert ihn zu starten bevor ein Request fehlschlägt.

Leonidas hat geschrieben: Das Problem ist, dass [...] sich Cherokee nicht um die FastCGI-Prozessverwaltung kümmert. Somit muss man immer selbst drauf achten dass der Prozess immer läuft. [...]

Äh, nicht ganz, das ist nur die halbe Wahrheit. Cherokee kennt zwei Modi: Entfernter Host und lokaler Interpreter. Der erste Modi entspricht deiner Beschreibung, ist aber eigentlich für entfernte Server gedacht. Wenn man lokaler Interpreter auswählt, gibt man den Befehl an, der ausgeführt werden soll, wenn der Prozess nicht läuft. Cherokee kümmert sich also um alles selbstständig. Läuft bei mir schon ne ganze weile sehr zuverlässig mit FastCGI.

Ich zitiere mal aus der Doku[1]:

Interpreter: command to spawn a new source in case it were not accessible[...]
Note that you will have to manually launch the spawner if you use a Remote host as Information source instead of a Local interpreter.

Das gilt so ziemlich für alle Arten von Interpreter Anbindung, egal ob fastCGI, uwsgi, scgi... in der Doku[1] findest du sogar Screenshots, die die Konfiguration am Beispiel von scgi und Django zeigen.

[1] http://www.cherokee-project.com/doc/coo ... jango.html

Hallo,

nach einigen Überlegungen bezüglich der Ansteuerung von Bottle (auch hier im Forum - Danke) habe ich mich jetzt für die klassische Variante mit Apache und WSGI entschieden.

Aber auch das bringt mir im Moment Probleme.

Ubuntu 10.4 Server
Apache
mod-wsgi

In: /var/www/todo
todo.py
bottle.py
adapter.wsgi - alles nach Bottle-Anleitung. (so glaube ich)

Folgender Fehler: adapter.wsgi (nach Anleitung)

bottle.py ist im gleichen Verzeichnis: /var/www/todo/bottle.py


Danke für jede Unterstützung.

MrNiceTry

Du solltest natürlich erst in das richtige Verzeichnis wechseln und dann importieren.

Was meinst Du mit "Du solltest natürlich erst in das richtige Verzeichnis wechseln".

Es ist alles im gleichen Verzeichnis: /var/www/todo

Na schau dir mal deinen Code an. Du wechselt ja mit os.chdir in dein Verzeichnis. Nur vorher versuchst du bottle zu importieren - und das kann er einfach nicht finden. Importierst du bottle nach dem os.chdir, sollte es eigentlich klappen.

Danke.

Habe wie folgt geändert:

Funktioniert.
Sieht zumindest so aus. Bin morgen sicher.


Danke nochmal und gute Nacht.


MrNiceTry

Wie muß ein Decorator aussehen, der mir ALLE Unterverzeichnisse durchreicht.
Also in jeder Tiefe.

Danke

MrNiceTry

Hallo,

du meinst, dass z.B.

/meine_app
/meine_app/foo
/mein_app/foo/bar/irgend/was

alle von der gleichen Route abgefangen werden?

Das sollte mit einer RegEx funktionieren.
Gruß, noisefloor

(Wie) kann man ermitteln, wie Python/Bottle aufgerufen worden ist ?

Erfolgte der Aufruf von der Konsole oder durch Apache/WSGI ?


Danke.

MrNiceTry

Es läuft immer ein WSGI-Server; wenn du Bottle-Anwendungen "aus der Konsole" startest, dann wird eben ein WSGI-Server in der Konsole gestartet :-)

Ja, aber meine Frage ist: Kann man ermitteln WIE Python/Bottle gestartet wurde.

MrNiceTry hat geschrieben:Ja, aber meine Frage ist: Kann man ermitteln WIE Python/Bottle gestartet wurde.

Wozu? Vielleicht hilft es uns, Dein eigentliches Problem zu verstehen...

Meine Anwendung soll sich anders verhalten, wenn sie vom Apache aufgerufen wird, als wenn der Aufruf manuell von der Konsole gemacht wird.

MrNiceTry hat geschrieben:Meine Anwendung soll sich anders verhalten, wenn sie vom Apache aufgerufen wird, als wenn der Aufruf manuell von der Konsole gemacht wird.

Naja das ist schon klar, aber inwiefern denn? Sind es inhaltlich wirklich andere Dinge oder geht es eher in Richtung Debug-Modus an / aus?

Sorry,

aber was soll das an meiner Frage ändern?

Ich kann gerne den Sinn und die Struktur meiner Anwendung erläutern.

Aber meine Frage ist doch einfach und klar formuliert, oder?

"Kann man ermitteln WIE die (Bottle-)Anwendung aufgerufen wurde."
(Entschuldigung. Aber falls das nicht klar verständlich ist, lasst es mich bitte wissen!)

Sind zum Beispiel Port oder Host unterschiedlich für die beiden Server? Dann könntest du dir einfach das `environ` angucken.

'environ' hat mich nicht weiter gebracht.

Über host und port kann ich das nicht differenzieren. Die können durchaus gleich sein.
Irgendwie kann ich das schon rausfinden. Ich könnte z.B. Startparameter verwenden.

Ich hatte nur gehofft, es gäbe eine elegantere Methode, möglicherweise aus dem System oder aus Python die Info zu bekommen.


MrNiceTry