Utiliser Cherrypy (serveur web léger) avec Bottle (Framework léger) 21


Pour les sites/app qu’on developpe en une journée, Bottle et Cherrypy sont deux larons en foire qui s’accouplent parfaitement…

Rappel:

Bottle: Framework python light, allez voir “Créer un site avec bottle en 5 minutes”
Cherrypy: Framework python light + serveur web


Une bonne Pip pour commencer:

monsieur@fion:~# pip install cherrypy

Dans votre fichier start.py:

run(host='0.0.0.0', port=80, server='cherrypy')

Note: le 0.0.0.0 permet d’acceder à votre site depuis l’extérieur.

Pour lancer en daemon vous pouvez utiliser supervisord ou faire un script dans le répertoire où se trouve start.py de votre projet et y coller:

#! /bin/sh
 
### Run server in daemon mode
nohup python start.py &

Plusieurs serveurs web sur la même machine:
Si vous avez un autre serveur web qui tourne sur votre machine et qui vous empêche de lancer cherrypy sur le port 80 vous pouvez utiliser nginx en proxy. Pour ce faire modifiez le port de cherrypy dans votre fichier start.py (voir plus haut) et réglez-le sur 7777 par exemple avec un host 127.0.0.1.
Ouvrez un fichier de conf nginx et copiez ceci:

upstream monsite_cherrypy {
    server 127.0.0.1:7777;
}
 
server {
        listen       80;
        server_name monsite.com www.monsite.com ;
 
        location /favicon.ico {
            root  /home/monsite/static/img;
        }
 
        location / {
            proxy_pass http://monsite_cherrypy; 
        }
 
}

Relancez Nginx (service nginx restart). Et votre site est en place. C’est ce qu’on utilise pour multiboards par exemple.

C’est rapide et simple et ça peut tenir pas mal de visiteurs. ça évite d’installer des trucs lourds avec 3 tonnes de config.

21 thoughts on “Utiliser Cherrypy (serveur web léger) avec Bottle (Framework léger)

  • cdsl

    Simple et rapide :) ,
    quelle est la meilleurs méthode selon vous pour gérer de façon plus “surveillé” les sessions uWsgi ? ( restart en cas de plantage de l’un d’entre eux par exemple, ou en cas de consommation excessive de temps CPU, pour ne pas bloquer les nouvelles connexions ).

    Supervisor ?

    Ch.

  • Sam

    Je ne sais pas si il y a une “meilleure”, mais effectivement on utilise supervisor parce que:

    – ça marche
    – c’est en python
    – c’est assez standard et bien foutu
    – c’est documenté

    Après, on a besoin de supervisor parcequ’on a pas mal de truc dedans: celery, solr, gunicorn, etc. Si tu as juste uwsgi, un simple script dans /dev/init.d suffit généralement. Gérer la consommation et la relance de daemon, c’est déjà super advanced comme usage.

    En ce moment je joues avec l’idée de passer à circus, un produit de chez mozilla qui doit remplacer supervisor et faire le café en plus…

  • Laurent

    Cherrypy c’est aussi un frameworks ? par rapport à Bottle il se situe ou ?

  • Sam

    Un poil plus gros que flask, beaucoup plus petit que Django.

    CherryPy est globalement un très beau logiciel.

    Par contre il n’emparque ni ORM, ni lib de tempmlate.

  • pfroot

    J’utilise également bottle, cherrypy en mode wsgi avec mod_wsgi mais j’ai toujours du mal à trouver un framework d’authentification efficace. J’ai déjà essayé repoze.who mais il y a peu de doc et je trouve cela assez lourd. J’ai testé également bottle-cork mais c’est un module en plein dev et il est assez mouvant actuellement ! Qu’utilisez-vous dès qu’il s’agit d’authentification ? Utilisez-vous les authentifications disponibles à travers Apache ?

  • Sam

    On ne fait pas de sites avec authentification avec Bottle. Si il y a authentification, c’est que le site est suffisamment compliqué pour passer à Django.

    Je ne dis pas qu’on ne peut pas faire de l’authentification avec Bottle ou cherrypy (il y a des moddle wsgi pour ça), mais je suis partisan d’utiliser le bon outil pour le bon travail. A partir d’une certaine taille de site, un micro framework n’est plus un bon outil pour moi: génération de formulaire, admin, cache, sessions, tags, écosystème d’applis tièces. Toutes ces choses qu’offrent Django économisent des semaines de travail.

  • pfroot

    @Sam c’est bien ce que je me disais…je vais devoir me mettre à Django pour de vrai, espérons que je ne ressente pas la sensation de vomi que j’avais eu avec Zope ;) mais je sais que c’est un produit différent…

  • pfroot

    Je dis cela car j’ai déjà pas mal vomi avec :
    – Zope
    – Twisted
    – Web2py

  • Sam

    Moi aussi. La première fois que j’ai bossé sur du Zope/Plone, un ancien m’a dit “la courbe d’apprentissage, c’est pas une courbe, c’est un mur”. Je confirme.

    Twisted n’est pas si compliqué que ça quand on comprend l’asynchrone. Le problème c’est qu’on le comprend rarement avant d’avoir au moins joué avec un framework asynchrone. Tornado et Nodejs sont plus simples pour ça.

    Web2py est simple, mais la doc est juste à chiée.

    Django est largement plus facile à aborder et il y a pas mal de ressources en français (http://forum.django-fr.org/viewtopic.php?id=874) sans compter le tuto du site du zéro (http://www.siteduzero.com/tutoriel-3-329045-developpez-vos-applications-web-avec-django.html).

    C’est pas encoure complètement noob friendly (faudrait qu’on fasse notre propre tuto :-)). Mais ca commence à se démocratiser.

    La mauvaise nouvelle, c’est qu’une fois que tu auras appris Django, quelqu’un viendra te dire qu’il faut aussi apprendre nodejs/tornado, l’erlang, scala et reimplementer toutes tes libs en python 3. Ca n’arrête jamais.

  • pfroot

    Merci pour tes orientations, je te rejoins sur tes analyses :

    – Zope, complexe et obscure, genre usine à caca,
    – Web2py, la doc en mousse façon PDF ;),
    – twisted pas beaucoup de doc, des conflits de version…

    Je considère d’ailleurs Twisted davantage comme un framework réseau qu’un framework web.

    L’asynchrone, je connais , j’ai déjà joué avec gevent et les websockets…que je ne conseille d’ailleurs pas du tout, sauf si vous aimez coder 10 fois plus et vous dégoûter du JS ;), j’avais fait une application de tchat temps réel multi-utilisateurs. Je me suis rendu compte que authentification et websocket c’était pas la joie ! J’aurais dû partir aussi directement avec ZeroMQ pour m’aider….

    Allez je vais m’occuper de ce django ! Je vais commencer avec une bête appli RSS que je vais agrémenter d’un peu de sauce à base de filtre bayésien et de networkx pour faire une application geek rss qui arrachent les sacs des mamies (c’est rien, ce ne sera que ma 5e application de flux RSS que j’écris :))

  • pfroot

    “qu’il faut aussi apprendre nodejs/tornado, l’erlang, scala et reimplementer toutes tes libs en python 3″

    – nodejs, je n’aime pas coder en javascript, j’y suis de plus en plus obligé à cause des gars vachement cools du web 2.0 ;)
    – tornado, dev mouvant, disons trop pour moi, pas satisfait par l’authentification openID…
    – erlang, scala ok si je bosse dans une fac ou dans un centre de recherche, quid des hébergements…
    – python3 j’attends encore, j’ai encore besoin de modules non dispo encore pour la version 3.

    Ca fait un peu 15 ans que je fais du dev web : asp, php, asp.net, cgi, zope, python…donc les modes, j’ai appris à les observer parfois avec du recul ! J’ai jamais osé faire du web avec Java ;) parce-que j’ai plus un rond pour de la DDR ;)

  • nahoy

    Question peut être stupide, mais qu’apporte Cherrypy en plus ? Parce que juste avec bottle, je peux servir mon app sur le port que je souhaite.

  • Max Post author

    j’ai posé la même question à Sam quand on a commencé à s’en servir ;)

    Comme le dit la Doc de bottle :

    Bottle runs on the built-in wsgiref WSGIServer by default. This non-threading HTTP server is perfectly fine for development and early production, but may become a performance bottleneck when server load increases.

    The easiest way to increase performance is to install a multi-threaded server library like paste or cherrypy and tell Bottle to use that instead of the single-threaded server.

    Pour résumé le serveur fourni avec Bottle est un petit serveur de dev qui ne tiendra pas la charge si il y a plusieurs personnes connectées à ton site. D’ailleurs ils conseillent d’utiliser cherrypy.

    Pour plus de détails voir ici

  • anthony

    Je pensais utiliser Eventlet avec Bottle, la différence avec Cherrypy se situe juste au niveau multithreaded vs async, ou y a t’il d’autres subtilités ?

  • Sam

    Cherrypy est en pure Python, donc il n’a pas de compilation, on peut même la fournir en copiant / collant le code source.

  • anthony

    Ah effectivement c’est une différence importante, merci. En asynchrone pure Python a t’on qqch qui tient la route ?

  • anthony

    Petit retour, j’ai testé Bottle + Cherrypy sous Android, ça marche super. J’ai aussi essayé à la place de Cherrypy Eventlet+Greenlet, là boom (seg fault), pourtant Greenlet compile bien sans modif du C, pas debuggé plus que ça, Cherrypy me suffit.

  • Max Post author

    Pourquoi se compliquer la vie quand on peut faire simple ;)

Leave a comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <pre> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Des questions Python sans rapport avec l'article ? Posez-les sur IndexError.