Apprendre à utiliser le Framework CherryPy pour Python


Télécharger Apprendre à utiliser le Framework CherryPy pour Python

★★★★★★★★★★3.5 étoiles sur 5 basé sur 1 votes.
Votez ce document:

Télécharger aussi :


Apprendre à utiliser le Framework CherryPy pour Python

CherryPy a un serveur Web intégré que vous pouvez utiliser pendant le développement et pour exécuter réellement l'application. Cependant, j'avais déjà un Apache avec d'anciens programmes PHP, je ne pouvais donc pas servir l'application Web Python à l'aide du serveur Web intégré de CherryPy, car je ne voulais pas le servir sur un port autre que le port 80. Heureusement, CherryPy Les applications peuvent également être servies avec Apache avec mod_python.

Le paramétrage pour l'exécuter à travers mod_python s'est avéré être un peu pénible cependant. Il m'a fallu un total d'environ 4 heures pour le mettre au travail. Les informations sur mod_python sur le site CherryPy se révèlent incorrectes, incomplètes et un peu datées.

Dans cet article, je vais donc décrire comment j'ai finalement réussi à configurer mon application pour qu'elle fonctionne à la fois avec le serveur intégré et avec Apache v2, ainsi que les pièges à surveiller.

  1. Installer et activer mod_python

Tout d’abord, vous devrez installer mod_python pour Apache2. Pour les systèmes Debian et Ubuntu, ceci est aussi simple que:

~ # apt-get install libapache2-mod-python

Si vous avez compilé Apache2 à partir du paquet source, vous devrez probablement recompiler ou quelque chose du genre.

Veuillez consulter le manuel Apache2 ou le type de votre choix pour plus d'informations.

Ensuite, vous devez activer le module mod_python dans Apache. Cela signifie que vous devez créer un lien symbolique vers

/etc/apache2/mods-available/mod_python.load dans / etc / apache2 / activé par mods comme ceci:

~ # ln -s / etc / apache2 /etc/apache2/mods-available/mod_python.load / etc / apache2 / activé par mods

~ # /etc/init.d/apache2 restart

Les utilisateurs de Debian peuvent utiliser la commande suivante à la place:

~ # a2enmod mod_python

~ # /etc/init.d/apache2 restart

  1. Configurez Apache

Après avoir activé le module mod_python, nous devrons configurer un répertoire pour servir un programme Python au lieu du contenu "normal". Tout d’abord, je vais vous montrer ma configuration personnelle pour que vous sachiez ce que vous devez changer.

La racine Web que j'ai choisie pour l'application est /var/www/dvd.dev.local/htdocs. Le répertoire /var/www/dvd.dev.local contient deux répertoires: logs et htdocs. L'application vivra dans le répertoire htdocs. L'application sera desservie par son propre hôte virtuel: dvd.dev.local. L'application elle-même est un simple DVD de gestion front-end, avec quelques tables dans une base de données SQLite. L'application est dvd.py.

Comme dit, l'application vivra dans /var/www/dvd.dev.local/htdocs. Voici à quoi ressemble ce répertoire:

www-data @ jib: ~ / dvd.dev.local / htdocs $ ls –Fl total 20

-rw-r - r-- 1 www-data www-data 2048 10 oct. 11 h 10 dvd.db

-rw-r - r-- 1 www-data www-data 429 le 11 octobre à 13h50 dvd.ini

-rwxr-xr-x 1 www-data www-data 3817 13 oct. 12 h 15 dvd.py *

drwxr-xr-x 2 www-data www-data 4096 6 oct 12 12:08 images /

drwxr-xr-x 2 www-data www-data 4096 7 octobre 15:55 templates /

Maintenant, nous devons configurer l'hôte virtuel et le répertoire htdocs afin qu'il héberge correctement l'application. Pour cela, nous créons une nouvelle configuration d’hôte virtuel dans

/etc/apache2/sites-available/dvd.dev.local. C'est la manière par défaut de gérer les configurations d'hôte virtuel sous Debian.

Nous plaçons ce qui suit dans le fichier:

<VirtualHost *: 80>

ServerAdmin webmaster@dvd.dev.local

Nom du serveur dvd.dev.local

DocumentRoot /var/www/dvd.dev.local/htdocs/

<Lieu />

PythonPath "sys.path + [’ / var / www / dvd.dev.local / htdocs ’]"

SetHandler programme python

PythonHandler cherrypy._cpmodpy :: gestionnaire

PythonOption cherrypy.setup dvd :: start_modpython

PythonDebug On

</ Location>

LogLevel avertir

ErrorLog /var/www/dvd.dev.local/logs/error.log

CustomLog /var/www/dvd.dev.local/logs/access.log combinés

</ VirtualHost>

Je n’expliquerai que la partie <Location />, car le reste est un élément de base d’Apache et devrait être évident. Nous spécifions d’abord la directive <Location />. Ceci fait référence à l'option DocumentRoot, donc elle affecte toutes les requêtes faites sous /var/www/dvd.dev.local/htdocs. Passons maintenant aux options individuelles de la directive Location:



  • PythonPath: indique à mod_python qu'il doit ajouter le répertoire /var/www/dvd.dev.local/htdocs au chemin sys.path de l'interpréteur Python. Cela est nécessaire car mod_python essaiera d'importer votre application en tant que module. Le répertoire contenant l'application doit donc se trouver dans le chemin.
  • SetHandler: indique à Apache qu'elle doit utiliser mod_python pour répondre aux demandes d'URL à cet emplacement. * PythonHandler: indique à mod_python ce qu'il doit exécuter pour chaque demande. Dans ce cas, vous devez exécuter la fonction handler () dans le fichier _cpmodpy du module cherrypy. C’est une méthode spéciale qui fait partie du framework CherryPy et qui vous permet d’exécuter votre application CherryPy avec mod_python.
  • PythonOption: PythonOption vous permet de définir des paires clé / valeur arbitraires pouvant être lues par le

Programme Python en cours d'exécution. C’est un peu comme une configuration. Ici, nous définissons l'option cherrypy.setup sur la fonction start_modpython dans le module dvd, qui est notre application. CherryPy’s

_cpmodpy.handler () lira cette option et exécutera la fonction qui y est définie pour chaque requête effectuée.

  • PythonDebug: cette directive est définie sur On, afin que mod_python affiche les erreurs, bien que cela ne semble pas fonctionner correctement.

Activez le nouvel hôte virtuel en créant un lien symbolique entre /etc/apache2/sites-available/dvd.dev.local et

/etc/apache2/sites-enabled/001-dvd.dev.local (les utilisateurs de Debian / Ubuntu peuvent utiliser la commande suivante:

a2ensite dvd.dev.local).

  1. Comment ça marche

Lorsque vous démarrez Apache, voici ce qui se passe:

  1. Apache est redémarré.
  2. Apache charge le module mod_python.
  3. Pour chaque enfant Apache, mod_python démarre un interpréteur Python.

Voici ce qui se passe pour chaque demande qui arrive:

  1. Une demande arrive pour, disons, http: //dvd.dev.local/.
  2. mod_python exécute la méthode cherrypy._cpmodpy.handler ().
  3. S'il s'agit de la première demande, les événements suivants se produisent. (Ceci n'est effectué qu'une fois pour chaque processus enfant Apache, car l'interpréteur reste en mémoire).

une. CherryPy configure le framework CherryPy.

  1. Votre application (dvd.py dans ce cas) est importée.
  2. La fonction définie dans l'option cherrypy.setup PythonOption est lue et exécutée.
  3. cherrypy._cpmodpy.handler () exécute la requête via le framework CherryPy comme à l’habitude.
  4. La sortie est envoyée à Apache, qui la renvoie au client.
  5. Faire fonctionner votre application

Bon, alors il est temps que votre application fonctionne avec mod_python. Tout ce dont vous avez besoin est de mettre le framework CherryPy du blocage en mode non bloquant, et vous avez terminé.

Remarque: Philip Stark mentionne que depuis CherryPy 3.1, vous n'avez plus besoin de mettre CherryPy en mode non bloquant. L'option "blocking = false" est obsolète et générera une erreur dans votre fichier journal. Continuez à lire, cependant, car il reste encore beaucoup à faire.

Du moins, c’est la théorie. En pratique, il reste encore beaucoup à faire. Il existe de nombreux pièges qui pourraient empêcher votre application de fonctionner correctement et leur débogage peut être une vraie saloperie.

5.1. Les pièges

Voici quelques points à garder à l'esprit lorsque vous essayez de faire fonctionner votre application avec mod_python:

  • Le répertoire de travail de l’application est /! Cela signifie que toute référence à des fichiers tels que des configurations ou des bases de données doit être absolue et non relative. Vous devez toujours spécifier le chemin d'accès complet au fichier.
  • mod_python et CherryPy mettent en cache toutes sortes de choses. Vous devrez donc recharger votre Apache pour chaque modification apportée au code source. Un rechargement /etc/init.d/apache fera généralement le travail. La meilleure chose à faire est d’abord de vérifier que votre application fonctionne avec le serveur Web intégré en indiquant à l’utilisateur sous lequel le serveur Web est exécuté, en modifiant le répertoire de travail en cours en /, puis en exécutant l’application à partir de cet emplacement (/ var / www / dvd.dev.local / htdocs / dvd.py).
  • La journalisation et l'affichage des erreurs échoueront à moins que tout soit configuré correctement. Poursuivez votre lecture pour apprendre à minimiser le nombre de problèmes que vous rencontrerez et à faire en sorte que les erreurs apparaissent le mieux possible.
  • Essayez de faire en sorte que votre application fonctionne dans le répertoire racine de l'hôte virtuel avant d'essayer de la faire fonctionner également dans un sous-répertoire. Les sous-répertoires nécessitent une configuration supplémentaire, ce qui signifie davantage de problèmes potentiels.

5.2. Erreur de journalisation

La principale chose à faire lorsque vous essayez de faire fonctionner votre application sous mod_python est le signalement des erreurs. Sans cela, vous serez perdu. Fondamentalement, tout ce qui provoque une erreur montrera le redouté

Erreur irrécupérable sur le serveur. Voici quelques conseils de base que vous pouvez suivre pour vous assurer de recevoir les erreurs ou comment les éviter:



  • Les erreurs lors du démarrage de l’application, telles que les erreurs de syntaxe, ne sont pas affichées dans les journaux, peu importe ce que vous essayez, il est donc impératif que vous obteniez ce droit. Si vous obtenez l’erreur irrécupérable et que vous ne voyez aucune trace en arrière, vérifiez le programme en l’exécutant sur la ligne de commande!
  • Assurez-vous que les journaux d'erreur que vous spécifiez partout sont accessibles en écriture à l'utilisateur Web.
  • Commencez l’enregistrement des erreurs de CherryPy dès que possible. (voir ci-dessous)
  • Recherchez dans tous les journaux les erreurs Python. Ci-dessous, je vais vous montrer comment configurer la journalisation de CherryPy. Vous devriez vérifier le fichier journal spécifié ici. Consultez également le journal des erreurs Apache par défaut pour vhost. Sinon, recherchez dans le fichier journal l'hôte virtuel par défaut (c'est celui que vous voyez lorsque vous faites une demande d'adresse IP de votre ordinateur dans votre navigateur Web). Consultez également le journal des erreurs Apache global (/var/log/apache2/error.log sous Debian). Des erreurs peuvent apparaître dans l'un de ces fichiers!
  • Assurez-vous que votre application fonctionne également correctement lorsque vous ne l'exécutez pas à partir du répertoire dans lequel elle se trouve. Exécutez-la en tant qu'utilisateur du serveur Web à partir du répertoire racine comme suit: su - www-data; cd /; /var/www/dvd.dev.local/htdocs/dvd.py et voyez ce qui se passe. Résolvez tous les problèmes avant d'essayer de l'exécuter via mod_python.

Maintenant, il est important de démarrer le traitement des erreurs de CherryPy dès que possible dans votre application, en particulier si vous obtenez une erreur irrécupérable. Pour ce faire, procédez comme suit dès que possible dans votre application: import cherrypy cherrypy.config [’log.error_file’] = ’/var/www/dvd.dev.local/logs/py_error.log’

Assurez-vous que le fichier journal existe et qu'il est accessible en écriture à l'utilisateur du serveur Web. Ne présumez pas que c’est parce que les autorisations sont correctes! Ne supposez jamais, vérifiez toujours: [root @ jib] /var/www/dvd.dev.local/logs# su - www-data

5.3. Modification de votre programme pour supporter mod_python

D'accord, vous devez maintenant modifier votre application pour qu'elle puisse être exécutée à la fois via mod_python et

avec le serveur intégré de CherryPy. Vous trouverez ci-dessous un petit modèle standard basé sur mon application.

#! / usr / bin / python

importation os

importer cherrypy

importer mako.template, mako.lookup

importer sqlalchemy.orm

#

# Spécifiez un fichier de log dès que possible pour augmenter les chances de journalisation

# les erreurs. Cela pourrait être commenté une fois que l'application fonctionne sur le live

# serveur sous mod_python

#

cherrypy.config [’log.error_file’] = ’/var/www/dvd.dev.local/logs/py_error.log’

#

# Notre application web (factice) actuelle

#

DVD de classe:

index def (self, sort = None, edit_id = None):

return (’Hello world!’)

index.exposed = True

#

# Configurez cherrypy pour qu’il soit indépendant du chemin d’exécution et chargez le

# configuration.

#

path_base = os.path.dirname (__ file__)

path_config = os.path.join (path_base, ’dvd.ini’)

path_db = os.path.join (path_base, ’dvd.db’)

# cherrypy.config.update (path_config)

#

# Configurer des éléments pour notre application à utiliser.

#

metadata = sqlalchemy.BoundMetaData (’sqlite: //% s’% (path_db))

#

# Ces méthodes s’occupent de lancer l’application via mod_python ou

# autonome en utilisant le serveur intégré CherryPy.

#



1