Pourquoi supervisord et pas runit ?

Après l’avoir utilisé sans aucun soucis depuis quelques temps sur le serveur de secours de notre site web, je trouve que supervisord est plus convivial à utiliser, et plus « clair » à mettre en place.

Plus convivial à utiliser parce qu’il a un client CLI qui permet d’interagir directement avec les processus monitorés, mais il y a aussi les mêmes fonctionnalités par le biais d’une interface web fort pratique.

Plus « clair » à mettre en place parce qu’il se lance grâce à un simple script d’init, et qu’on peut faire la configuration de tous ses processus à monitorer dans un seul et même fichier de configuration, au lieu d’avoir un répertoire et des liens symboliques à gérer (certains préfèrent peut-être cette modularité, mais personnellement je trouve ça beaucoup plus pénible à maintenir).

Installer supervisord

Etant donné que supervisord est en python, il est possible de l’installer avec un simple

$ pip install supervisor

Pour les old-school qui ne profitent pas encore de la puissance et de l’ergonomie de ce magnifique outil de Ian Bicking, il est possible de remplacer pip par easy_install (même si je vous conseille plutôt de faire un easy_install pip puis de vous passer de easy_install par la suite!).

Configurer supervisord

On le configure en deux temps : une première configuration de supervisord lui-même, puis l’ajout des processus qu’on veut qu’il monitore.

Dans le fichier /etc/supervisord.conf :

; configuration de supervisord lui-meme
[unix_http_server]
file=/tmp/supervisor.sock   ; chemin vers le fichier socket

[inet_http_server]
port=192.168.0.21:9001      ; adresse ip _LOCALE_ de la machine pour la connection web

[supervisord]
logfile=/var/log/supervisord.log ; fichier de log principal de supervisord

[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface

[supervisorctl]
serverurl=unix:///tmp/supervisor.sock ; connection pour le client CLI

; liste des processus qu'on veut confier a supervisord
[program:gu-www]
command=/path/to/venv/bin/python /path/to/venv/bin/gunicorn_django -b localhost:8080 --log-file=/path/to/log/gunicorn_gu-www.log --workers=3
directory=/folder/containing/settings/file/
user=www-data
autostart=true
autorestart=true
startsecs=10
redirect_stderr=true
stdout_logfile=/path/to/log/supervisor_gu-www.log

Bien entendu, faites en sortes que l’utilisateur www-data ai accès en écriture aux fichiers de log gunicorn_gu-www.log configuré où le processus échouera lors de son lancement.

ATTENTION: comme indiqué dans le commentaire pour la ligne de configuration inet_http_server il faut absolument faire en sorte que l’adresse ne soit pas accessible à tout le monde! En effet il est possible de redémarrer ou tout simplement stopper les processus par cette interface! Vous pouvez désactiver complètement cette possibilité en supprimant ces deux lignes, il n’y aura alors pas de moyen de contrôler supervisord par une page web.

La commande indiquée pour information lance gunicorn_django avec dans un environnement virtuel (ce que vous devriez faire vous aussi!). Il n’est pas nécessaire d’indiquer le chemin vers le fichier settings.py dans les options de gunicorn_django étant donné que le processus sera lancé directement dans le répertoire le contenant (si vous le configurez correctement avec le paramètre directory comme indiqué ci-dessus).

ATTENTION: il faut absolument que gunicorn_django soit lancé en foreground (en tâche principale, pas en arrière-plan/background/démon/daemon), ce qui est le cas par défaut si vous n’avez pas explicitement dit le contraire dans votre fichier de configuration (ou en paramètre de la commande) de gunicorn_django.
En effet c’est supervisord qui se charge de le faire : si le processus est lancé en arrière-plan, supervisord ne peut pas prendre la main dessus et le contrôler ni le monitorer, et va essayer de le lancer plusieurs fois d’affilée pensant qu’il échoue à chaque fois.

Lancer supervisord et le relancer à chaque reboot

Il suffit pour cela de créer un script de démarrage dans /etc/init.d/ et de le faire se  lancer à chaque démarrage.

Dans /etc/init.d/supervisord :

#! /bin/sh
### BEGIN INIT INFO
# Provides:          supervisord
# Required-Start:    $remote_fs
# Required-Stop:     $remote_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Example initscript
# Description:       This file should be used to construct scripts to be
#                    placed in /etc/init.d.
### END INIT INFO

# Author: Dan MacKinlay
# Based on instructions by Bertrand Mathieu
# http://zebert.blogspot.com/2009/05/installing-django-solr-varnish-and.html

# Do NOT "set -e"

# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin
DESC="supervisord"
NAME=supervisord
DAEMON=supervisord
MANAGE=supervisorctl
DAEMON_ARGS=""
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME

# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions

case "$1" in
  start)
    $DAEMON
        ;;
  stop)
    $MANAGE shutdown
        ;;
  reload|force-reload)
    $MANAGE reload
    ;;
  restart)
    $MANAGE restart
        ;;
  *)
        echo "Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload}" >&2
        exit 3
        ;;
esac

Ce script contient des commentaires en début de fichier qui permettent de le faire se lancer automatiquement à chaque démarrage :

$ chmod a+x /etc/init.d/supervisord
$ update-rc.d supervisord defaults

Cette commande devrait indiquer qu’elle a créé tous les liens symbolique nécessaire pour lancer ce script à chaque démarrage du serveur.
Il ne reste plus qu’à lancer supervisord maintenant et vérifier que notre site est accessible :

$ /etc/init.d/supervisord start

Monitorer et contrôler ses processus

Soit en utilisant le client CLI :

$ supervisorctl

Soit en accédant à la page web dont on a configuré l’adresse dans le paramètre inet_http_server dans le fichier de configuration de supervisord. De là vous pouvez redémarrer vos processus, les arrêter, visualiser le contenu du fichier de log…

Un soucis?

• Pensez à regarder dans les fichiers de log indiqués dans les paramètres pour voir si il y a des indications sur le problème
• Vérifiez que la commande configuré dans /etc/supervisord.conf se lance correctement manuellement, et que le processus est bien en foreground
• Faites un tour sur l’excellente documentation du projet supervisord

Et comme l’année dernière, j’ai apporté ma maigre contribution à l’organisation sur place, aux côté des super-motivés de l’Association Francophone PYthon (liste non exhaustive : Christophe Combelles, Michael Scherrer, Gaël Pasgrimaud, Jean-Philippe Camguilhem, Olivier Grisel).

Le cadre

Nous avons été encore une fois super bien accueillis par la CyberBase. A disposition, un amphitéatre et une « base technique » (salle équipée de nombreux ordinateurs, idéale pour les mises en applications et les travaux pratiques). Les deux salles ont tout l’équipement nécessaire pour la rétro-projection des présentations, et avaient cette année encore la couverture vidéo de Ubicast.

Les sponsors

Vous trouverez la liste des généreux sponsors sur le site de PyCon.fr 2010. C’est en très grande partie grâce à eux qu’une telle conférence peut être organisée, en restant gratuite, j’en profite donc pour les remercier à nouveau (et les encourager à recommencer l’année prochaine bien évidemment .

Nous avons entre autres eu des présentations de plusieurs produits libres et open-source des sponsors Logilab (avec leur solution Cubic Web qui fait tourner le site de pycon.fr) et Itaapy.

Les présentations

Vous trouverez là aussi la liste sur le site de pycon.fr, et je vais lister ici les présentations auxquelles j’ai pu assister et qui m’ont marqué (les autres je les verrais en vidéo, grâce à Ubicast, dès qu’elles seront en ligne) :

• plusieurs lightning talks, en particulier sur Pyaler, le GSoC sur distutils 2 (vivement que ça sorte!), pysandbox, restkit
• Optimisation d’applications Django de Bruno Renié (mon co-champion « planet » pour django-fr : plein d’astuces pour limiter le nombre de requêtes, utiliser le cache de manière intelligente …
• MongoKit de Nicolas Clairon : comment utiliser une base NoSQL MongoDB facilement et efficacement avec MongoKit
• Analyse statistique et classification automatique de texte de Olivier Grisel : ça m’a replongé dans mon mémoire de DEA sur l’apprentissage automatique
• l’incontournabl)e Gunicorn de Benoit Chesneau : à mon avis, l’un des plus grands pas en avant pour rendre python (et Django) très facilement déployable
• Construire un CMS sur mesure avec Django de Yann Malet : il faut arriver à vendre non pas du forfait (trop risqué pour le développeur, trop cher pour le client, et risque d’effet tunnel), mais des cycles de développement (par exemple de deux semaines, avec review + paiement à chaque cycle, puis décision sur le cycle suivant). Voilà quelque chose qui me plait, mais qui est très difficile à vendre à des clients qui veulent surtout pouvoir chiffrer de manière très précise leur budget
• Programmation en Flux de Jonathan Schemoul : présentation de PyF qui permet de traiter de très nombreuses données en limitant la mémoire utilisée (grâce aux « flux »). Très intéressant, et un outil graphique en ligne qui m’a l’air très simple et pratique d’utilisation

Les rencontres

J’ai pu revoir nombre de personnes déjà rencontrées à l’édition de l’année précédent de PyCon.fr, ainsi qu’à Djangocong, personnes que je connaissais déjà auparavant par internet (irc, twitter, mailing lists de l’afpy et de django-fr …). Revoir « en vrai » des personnes qu’on côtoie très souvent de manière électronique est pour moi toujours une joie et un enrichissement, car l’échange est bien plus facile, et on tisse des liens bien plus étroits autour d’une bière que par internet!

Et comme je l’ai déjà twitté, j’ai par ailleurs été ravi de faire de nouvelles connaissances, que j’espère pouvoir revoir bientôt (un an entre chaque pycon.fr, ça fait long!). Il paraît qu’il devrait y avoir d’ici peu un autre afpyro national organisé, il faudra essayer de rassembler les troupes sur Sophia/Nice à cette occasion! Peut-être une occasion de tester le pastis magique de Jean-Philippe (il m’a promis qu’il ferait un article là-dessus, que je lierai ici

Les bonus

Comme si cela ne suffisait pas, il y a eu quelques bonus très sympathiques :

• un écran géant et tactile dans la CyberBase qui affichait en boucle isparade.jp sur le mot clé #pyconfr
• j’ai découvert aspirator de Bruno Renié, un news reader fait en django, et qui à l’air vraiment génial… ce gars est vraiment doué, ça en est limite énervant . Il travaille aussi sur wombat, un projet de client mail
• j’ai revu une bonne partie de mon ex équipe de badminton qui prenait le même avion que moi! (ils étaient aux championnats du monde qui avait lieu ce même week-end sur Paris)
• Alexis Métaireau (@ametaireau) nous a parlé de son travail pour le GSoC avec Tarek Ziadé sur distutils 2 : vivement que ce soit dans la stdlib!
• Rémi Ubscher (@natim) est Eclaireur lui aussi! Salut Fennec
• Benoit Calvez (@_dzen) m’a parlé de fabulator et de vineolia : énorme potentiel (et il a d’autres projets dans les cartons

Conclusion

Vivement la prochaine édition (peut-être sur Pau? ping Jean-Philippe et d’ici là, peut-être une nouvelle édition d’une rencontre Django en france!

Encore un énorme merci aux organisateurs, sponsors, présentateurs, et aux participants, qui font de cet évènement un moment agréable et enrichissant!

Excellent !

Après cette entrée en matière fort peu cavalière, permettez-moi de développer en deux points :

Ce que j’ai retenu de ma conférence

Ma présentation portait sur toutes les astuces et raccourcis à la disposition des développeurs web, et s’intitulait Django Pour Les Fainéants.

Les points positifs :

1. le format « interactif » : faire participer le public le plus possible permet de le garder attentif, éveillé et intéressé
2. les « bons points » : un autre moyen de captiver l’attention, en récompensant par un bon point (humoristique) les participants
   • bon point « glue » : le participant m’a posé une colle, à laquelle je ne sais répondre
   • bon point « fainéant » : le participant a proposé une astuce/raccourcis/outil que je ne connaissais pas, ou n’ai pas présenté dans la présentation
   • bon point « django pony » : le participant a partagé une bonne pratique django, ou parlé d’une astuce/raccourci/outil que je présentais dans une diapo suivante
   • bon point « casse nouilles » : donné à un complice, ou quelqu’un dont on est sûr qu’il le prendra à la rigolade, et qui a fait une remarque sur une typo, une parenthèse manquante…
3. les diapos « concises » ne contenant pas de phrases, mais des mots clé ou listes de points : permet de garder l’attention du public sur ce que l’on dit, en ne se servant des diapos que comme un support visuel (pour pointer du doigt)

Les points négatifs :

1. le format « interactif » : difficulté à prévoir le temps de parole pour la présentation. Si il y a beaucoup de participation, le temps de parole prévu empiètera sur le temps consacré (25mn de présentation + 10mn de participation > 30mn). A contrario, si il n’y a pas assez (pas du tout!) de participation, le temps de parole prévu sera trop court (25mn < 30mn).
2. le format « interactif » et les « bons points » : applicable pour des salles plus grandes, avec un public plus nombreux? Avec 50 personnes, je me demande si on atteignait pas la limite pour ce genre de format…
3. les diapos « concises » l’étaient peut-être trop : rajouter des photos comme par exemple pour les présentations de Olivier Meunier pour que ce soit plus agréable visuellement (ou comme pour celles de Cyril Baÿ, private joke inside

Dans l’ensemble, je pense que la présentation s’est bien passée, et a été bien reçue d’après les retours que j’en ai eu (merci à tous ceux qui sont venus me complimenter, ça fait chaud au coeur!). N’hésitez pas à me faire vos retours (positifs ET négatifs) dans les commentaires!

Ce que j’ai retenu des autres conférences

Il y a déjà plusieurs comptes rendus très complets sur la toile (liste exhaustive faite par Nicolas Ferrari sur le blog d’AlwaysData), je vais donc essayer de résumer ce que j’ai retenu de chaque présentation :

1. Django 1.2 : un point de nouveautés, par Nicolas Ferrari : lire les releases notes n’est pas suffisant! pour connaître toutes les excellentes améliorations de la 1.2, il faut soit lire la conf de Nicolas, soit suivre DjangoAdvent
2. Boîte à outils Django, par Eric Veiras Galisson : de multiples outils pour vraiment être un fainéant (cf ma présentation) et se simplifier la vie !
3. Cours de géo, par Samuel Adam : c’est pas si compliqué finalement, et LA TERRE N’EST PAS RONDE! présentation très claire sur les outils disponibles et leur puissance
4. Une authentification pour les « contrôler » tous, par Olivier Meunier : une « fail story », au moins aussi importante que la « success story » aussi présentée, sur comment adapter l’authentification django à sa sauce
5. Tester son projet Django, par Bruno Renié : on ne le dit jamais assez, il faut tester ses applications. Non seulement un garde-fou, c’est aussi un gage de la qualité du code final! (et chapeau pour la présentation faite au pied levé pour remplacer un conférencier qui n’a pu venir, et ce moins de trois jours avant la conférence!)
6. Les dessous d’alwaysdata, par Cyril : on a pas vu beaucoup de dessous, mais on en a appris énormément sur AlwaysData, leur sérieux, leur compétence, et leur boulot au quotidien pour nous simplifier la vie (et nous permettre d’être fainéants!)
7. Django pour les développeurs Symfony, par Nicolas Perriault : superbe présentation, donnée de main de maître (et hilarante), qui donne un regard nouveau sur ce qu’il est possible de faire avec un langage comme PHP. Au final, Symfony à l’air d’être une bonne alternative à Django quand le client ne veut pas entendre parler d’autre chose que PHP.
8. Beer over IP, par Bruno Bord : retour d’expérience sur un site reconnu (par moi en tout cas d’utilité publique.
9. Django et XMPP, par Jean-Michel Armand : quand utiliser XMPP, et surtout quand ne pas l’utiliser! Un retour d’expérience donné par notre cher Jean-Michel préféré!
10. Gunicorn, Django et WSGI, par Benoît Chesneau : présentation d’un outil que j’utilise en production depuis bientôt un mois sans jamais avoir eu le moindre soucis.
11. Des lapins et des poneys, quand AMPQ rencontre Django, par Olivier Meunier : explication d’une mise en oeuvre de AMPQ comme moyen de communication entre différents processus, très instructif
12. Introduction à Pinax, par David Paccoud : boîte à outil pleine d’applications réutilisables qui permet d’arriver à un produit fini avec moins d’efforts et plus rapidement. La question étant, comment faire la part entre un projet « fait main » qu’on maîtrise, et une boîte à outil qu’on ne maîtrise pas forcément. Qu’en est-il de la courbe d’apprentissage?
13. « ‘Tain cong’, Django speaks marseillais« , par Stéphane Raimbault : il y a plusieurs formes plurielles dans certains langages (Polonais par exemple), et beaucoup plus de spécificités que je ne m’en doutais! Il va falloir que je reprenne ma copie…
14. Internationalisation de contenus avec Django, par Benoît Bryon : présentation très claire des limites (et de certaines solutions) de Django pour tout ce qui à trait à la traduction et localisation de sites
15. CouchDB et Django, l’utilisation de CouchDBKit, par Benoît Chesneau : pas forcément évident à prendre en main, CouchDB est sensé être le choix incontournable quand on tient à ses données (multiples mécanismes comme l’écriture régulière sur le disque pour éviter les pertes de données lors d’un crash)
16. Les limites de Django, par David Larlet : qui n’a pas été confronté à certaines de ces limites? Un regard réaliste sur ce qu’on ne peut tout simplement pas faire (à l’heure actuelle) avec Django.

Ce que j’ai retenu de l’orga

Un immense merci à David et Jean-Michel, sans qui nous n’aurions tout simplement pas eu cette occasion de se rencontrer entre passionnés de Django (et d’autres! dédicace à Jérémy Lecour), et de voir en chair et en os des personnes (oserai-je dire amis?) qu’on cotoie parfois tous les jours sur internet, certains depuis des années! Merci aussi à Johan Charpentier pour l’impression des TShirts!

J’ai été vraiment impressionné par la ponctualité (malgré les aléas de la restauration et ses délais imprévus), le contenu très fourni et divers de toutes les présentations, le professionnalisme et en même temps l’accessibilité de chacun. Pouvoir discuter et échanger des expériences avec des collègues (comme on dit dans le sud est vraiment enrichissant.

Plus que tout, je tiens encore une fois à remercier Jean-Michel, qui s’est occupé d’une (très) grande partie de la logistique, de nous avoir trouvé les salles, chouchoutés (combien d’aller/retours il a fait pour remplir la cafetière? et de trajets en voiture pour amener/chercher des gens au métro/restau?), et de s’être autant appliqué à nous apporter tout le confort possible.

Vivement la prochaine rencontre!

Ce code est un mélange de deux méthodes complémentaires, une sur les mails HTML par Ross Poulton, et l’autre venant d’un djangosnippet par sleytr.

Pour en faciliter l’utilisation et la maintenance, j’ai mis ce petit module django-nice-emails sur bitbucket.

Plutôt que de copier le code ici, je vais plutôt en décrire les grandes étapes:

1. Utiliser le setting DEFAULT_FROM_EMAIL si l’expéditeur n’est pas fourni
2. Créer un django.template.Context à partir du dictionnaire fourni (permet de remplacer les {{ var }} dans les templates)
3. Utiliser le contexte créé pour initialiser le contenu texte, HTML ainsi que le sujet
4. Transformer le destinataire fourni en liste (si ce n’est pas déjà une liste de destinataires)
5. Créer un django.core.mail.EmailMultiAlternatives qui est la base de notre email (basé sur le contenu texte)
6. Rajouter la partie HTML
7. Rajouter les images en inline si nécéssaire
8. Envoyer le mail

Rien de compliqué donc dans ce code qui fait moins de 20 lignes « utiles ».

Voyons maintenant un exemple d’utilisation avec de la traduction et de l’héritage de templates:

Les templates

On utilise ici la méthode de Ross Poulton qui consiste à ne fournir en paramètre template_name que la base du nom de fichier, sans l’extension. On fournit ensuite au django.template.loader ce template_name avec l’extension .txt et .html, ces templates doivent donc exister tous les deux.

templates/test_email.txt

{% load i18n %}
{% trans "Bonjour" %} {{ nom }},

{% blocktrans %}Ceci est un exemple de "nice-email" que je vous fait parvenir,
à titre d'exemple, et bien que vous vous en fichiez{% endblocktrans %}.

{% trans "Cordialement" %}

Mathieu Agopian

templates/test_email.html

{% extends "base_email.html" %}
{% load i18n %}
{% block email_content %}
<p>{% trans "Bonjour" %} {{ nom }},</p>

<p>
{% blocktrans %}Ceci est un exemple de "nice-email" que je vous fait parvenir,
à titre d'exemple, et bien que vous vous en fichiez{% endblocktrans %}.
</p>

<p>{% trans "Cordialement" %}</p>

<p><em>Mathieu Agopian</em></p>
<img src="cid:signature" />
{% endblock email_content %}

templates/base_email.html

<table width="600">
<tr><td><img src="cid:logo" /></td></tr>
<tr><td>
    {% block email_content %}{% endblock email_content %}
</td></tr>
</table>

Le contexte

Un simple dictionnaire python pour chaque tag utilisé dans les templates:

context = {'nom': 'Johnny Biboul'}

Les images

Elles doivent être passées en paramètres dans un tuple de tuples, sous la forme ((‘/chemin/vers/image.png’, ‘tagimage’), ‘/chemin/vers/image2.png’, ‘tagimage2′), …). Si les images sont dans le répertoire images du MEDIA_ROOT:

images = (
    (path.join(settings.MEDIA_ROOT, 'images', 'signature.png'), 'signature'),
    (path.join(settings.MEDIA_ROOT, 'image', 'logo.png'), 'logo'))

Dans les templates, on utilisera les images sous la forme <img src=’cid:tagimage’ />.

Le code

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from os import path
from django.conf import settings
from django.utils.translation import ugettext
from utils.nicemails import send_nice_email

context = {'nom': 'Johnny Biboul'}

images = (
    (path.join(settings.MEDIA_ROOT, 'images', 'signature.png'), 'signature'),
    (path.join(settings.MEDIA_ROOT, 'images', 'logo.png'), 'logo'))

subject = ugettext(u"Test de mail pour %(nom)s") % {'nom': '{{ nom }}'}

send_nice_email(
        template_name='test_email',
        email_context=context,
        subject=subject,
        recipients='johnny@biboul.com',
        sender='foo bar ',
        images=images)

Conclusion

Il vous suffit de mettre ce code dans une de vos vues pour pouvoir faire de jolis mails de confirmation d’inscription, des newsletters, ou voir même (bouh! c’est mal!) du mass-mailing. Veillez néanmoins à ne pas forcer la dose sur le html, ou les images inlines!

Pour les malheureux qui ont fait les frais de la première version de ce billet (demandant d’installer runit-run), je ne peux que m’excuser platement, et vous fournir la méthode « au secours rescue moi! »: récuperer une installation avec un cd ubuntu. Une fois chrooté sur la partition root, il vous restera à désinstaller le paquet fautif et redémarrer:
        $ aptitude purge runit-run

Edité le 2010/02/10 à 20:58

Pourquoi runit et pas sysvinit, inittab, upstart, …

Je vous laisse consulter la page benefits sur le site officiel pour vous faire une idée. Pour les personnes ne parlant pas anglais, voici un bref résumé:

1. Un répertoire par service, contenant un script run
2. Un environnement d’exécution propre et prédictible pour chaque processus
3. Service de logging (optionnel) qui sera lancé en même temps que le processus, et en couvrira toute la durée de vie (redémarrages compris!)
4. Très peu encombrant, efficace… et peut complètement remplacer le système d’initialisation de votre linux

Utiliser runit avec le système d’initialisation actuel

Pour nous faciliter la vie, et ne pas avoir à modifier/importer de nombreux scripts de démarrage pour tous les démons et services déjà installés, nous allons utiliser runit « avec » le système d’initialisation actuel.

Installer runit

$ aptitude install runit

ATTENTION: Si vous installez aussi runit-run, il vous faut absolument configurer votre système (How to replace init), et ce, avant de rebooter (sinon votre système ne démarrera pas, et vous serez contraint à utiliser une méthode de récupération, comme celle présentée en tête de ce billet).

Créer un répertoire pour le service gunicorn et son script de lancement

$ mkdir /etc/sv/gu-monprojet
$ vi /etc/sv/gu-monprojet/run

Et voici le contenu du script run

#!/bin/bash
source /path/to/venv/bin/activate # activer le virtualenv
cd /path/to/django/project
exec gunicorn_django -b localhost:8080 --workers=3

Avec la version de gunicorn utilisée pour l’écriture de cet article, il est nécessaire d’être dans le répertoire du projet django (là ou se situe le fichier settings.py) pour lancer gunicorn_django.

Dans une future version (la modification est dans le trunk à l’heure de l’écriture) il suffira d’indiquer le chemin vers le fichier settings.py comme paramètre à la commande gunicorn_django.

Enfin, ne pas oublier de rajouter les droits d’exécution sur le script qu’on vient de créer:

$ chmod a+x /etc/sv/gu-monprojet

Indiquer à runit qu’il doit lancer le script

Pour celà, un simple lien symbolique, et dans les secondes qui suivent le script sera lancé:

$ ln -s /etc/sv/gu-monprojet /etc/service/

Et c’est tout!

Il suffit maintenant d’en profiter en allant sur http://localhost:8080, en configurant apache pour proxiser les requêtes directement dessus (cf le billet gunicorn: un server wsgi ultra simple à utiliser et configurer), ou encore en utilisant la commande sv pour gérer le service gunicorn:

$ sv status gu-monprojet
$ sv check gu-monprojet
$ sv up gu-monprojet
$ sv down gu-monprojet
$ sv restart gu-monprojet
$ sv hup gu-monprojet
...

Voici une recette simple pour installer, configurer et utiliser gunicorn avec apache et django.

Installer gunicorn

Pour installer gunicorn dans son environnement virtuel:

$ pip install -E /path/to/venv install gunicorn

Configurer Apache en proxy

Apache servira les fichiers statiques, et « proxisera » toutes les autres requêtes directement à gunicorn qui sera lancé en local sur le port 8080:

<VirtualHost *:80>
ServerName example.com
ServerAlias www.example.com

DocumentRoot /path/to/django/project

<Proxy *>
    Order deny,allow
    Allow from all
</Proxy>

# laisser apache servir les fichiers statiques
ProxyPass /robots.txt !
ProxyPass /favicon.ico !
ProxyPass /static/ !

# proxiser toutes les autres requêtes vers gunicorn
ProxyPass / http://localhost:8080/

# robots.txt et favicon.ico sont dans /path/to/django/project/static/
Alias /robots.txt /path/to/django/project/static/robots.txt
Alias /favicon.ico /path/to/django/project/static/favicon.ico

<Directory /path/to/django/project>
    Order deny,allow
    Allow from all
    Options -Indexes
</Directory>
</VirtualHost>

Pour que le tout fonctionne correctement, il faut activer les modules mod_proxy et mod_proxy_html (et en option mod_cache):

$ a2enmod proxy proxy_http cache

Puis de redémarrer le server Apache:

$ /etc/init.d/apache2 restart

Lancer gunicorn

Il suffit de se placer dans le répertoire du projet django (avec le virtualenv activé), puis de taper:

$ gunicorn_django -b localhost:8080 --workers=2

Un ordre d’idée pour le calcul des workers: un de plus que le nombre de CPUs de la machine.

Conclusion

On peut alors se créer un script (a placer dans /etc/init.d) et l’activer pour qu’il se lance automatiquement au démarrage avec la commande update-rc.d (sous Debian), ou utiliser runit (jamais testé, peut-être un futur billet?).

Encore mieux, remplacer Apache par Nginx! (jamais testé non plus, et sûrement un futur billet ).

On peut difficilement faire plus simple!

Le contexte

Utilisation de SQLite pour un projet django déployé sur mod_wsgi:

# settings.py
DATABASE_ENGINE = 'sqlite3'
DATABASE_NAME = '/opt/mysite/mysite.db'

Et voici les permissions sur le système de fichier:

-rw-rw-rw- 1 ohan ohan 29696 2009-03-14 13:30 mysite.db

Tous les répertoires parents sont eux en 755 (lecture et exécution), ce qui ne devrait donc poser aucun problème, même pour l’utilisateur utilisé par les processus apache/mod_wsgi.

Le problème

Lors de la première tentative d’accès à la base de donnée (par exemple en accédant à l’administration django), une erreur 500 INTERNAL SERVER ERROR est renvoyée, et dans le fichier de log d’apache:

OperationalError: unable to open database file

La solution

Lors de l’accès à un fichier de base de données, SQLite va créer un fichier journal qui lui servira (entre autres) à gérer les accès à cette base. Plus d’informations sur la page expliquant les méthodes de vérouillage: locking in sqlite v3.

Pour créer ce fichier, il faut donc que l’utilisateur puisse écrire dans le répertoire parent.

chmod a+rw /opt/mysite

Ce problème ne devrait se présenter que lors d’un déploiement en environnement de production pour un projet qui utilise SQLite, ou sur un environnement de test si, comme moi, vous préférez tester sur apache directement, et non sur le runserver.

Création des tables à partir des modèles Django

Lorsqu’on utilise python manage.py syncdb, les tables créées dans la base de données

1. N’auront aucun commentaire, que ce soit sur les champs ou les tables, qu’il y ai ou non des help_text et des docstrings
2. N’auront aucun champ ENUM: les champs possédant une liste de choix sont représentés par un VARCHAR de longueur égale à la taille du plus long des choix
3. Les valeurs par défaut indiquées dans les modèles ne sont pas transmises dans les scripts de création des tables
4. Les BooleanField sont représentés par des TINYINT de 1bit
5. Un DateTimeField avec le paramètre auto_add_now ne sera pas représenté par un TIMESTAMP avec la valeur par défaut CURRENT_TIMESTAMP

Inspection des tables dans Django

Par ailleurs, si la base de donnée existe déjà, et que les modèles sont créés automatiquement par l’utilisation de la commande python manage.py inspectdb, il faudra garder à l’esprit que:

1. Les commentaires sur les champs et tables ne sont pas traduits en help_text ou docstrings, il faudra donc les dupliquer manuellement
2. Un champ ENUM sera représenté par un CharField
3. Les tailles de champ ne sont pas respectées. Par exemple, un Charfield sera avec un max_length de 135 par défaut
4. Les champs TIMESTAMP avec une valeur par défaut de CURRENT_TIMESTAMP ne seront pas importés en champ avec une valeur par défaut auto_add_now
5. Les valeurs par défaut ne sont pas importées

Il y a deux derniers points à noter:

1. Le script d’inspection va importer les champs primary_key pour chaque table, alors qu’ils peuvent être automatiquement générés de manière transparente: un modèle sans primary_key explicite en aura un de manière implicite
2. Le script d’inspection va créer un modèle pour les tables utilisées pour les relations ManyToMany alors que là aussi, Django peut les générer de manière implicite dans la plupart des cas (lorsque cette table ne contient pas d‘information supplémentaire)

Je trouve préférable de laisser la gestion implicite des primary_key et des tables ManyToMany quand c’est possible, dans un soucis de concision et de lisibilité.

Néanmoins, celà introduit une inconsistance entre les modèles et leur représentation dans la base de donnée, inconsistance qui peut porter à confusion.

Plus de cohérence entre les modèles et la base de donnée

Plusieurs possibilités:

• créer un script python qui va introspecter les modèles, et automatiquement rajouter les help_text comme commentaires aux champs, et les docstrings comme commentaires aux tables, ou vice-versa
• Utiliser des Custom SQL
• Créer des Custom fields
• Pour le type ENUM, il existe un django snippet qui vise à apporter une meilleure cohérence dans son utilisation

Partagez vos astuces et faites part d’autres incohérences dans les commentaires!

D’un côté, une base de donnée MySQL maintenue par MySQLWorkbench. De l’autre, Django et ses modèles.

Entre les deux… pas grand chose.

Les acquis

MySQL et MySQLWorkbench

MySQLWorkbench est un outil excellent pour pouvoir maintenir une base de donnée:

1. Gestion des commentaires sur les tables et champs
2. Affichage des relations entre les tables d’une base de données sous forme d’un schéma
3. Facilité de modification d’une base de donnée en production par l’export de scripts SQL

Django et les modèles

Django, de son côté, nécéssite une représentation de la base de donnée par des modèles. Ces modèles sont des classes codées en Python:

1. Facilité de suivi des modifications d’un modèle par le biais d’un contrôle de version (Git, Mercurial, SVN …) accompagné de commentaires pour chaque commit
2. Facilité de documentation: un paramètre help_text pour chaque champ, un docstring pour chaque modèle
3. Abstraction de certaines tables et champs générés automatiquement (comme les primary key ou les tables ManyToMany)

Les outils

Comme indiqué plus haut, MySQLWorkbench permet d’exporter des scripts SQL de création et/ou de modification. Il est aussi possible de reverse engineer le dump SQL d’une base de donnée, et ainsi créer toutes les tables dans l’interface graphique, et y visualiser les relations sous forme de schéma.

Django permet l’export de scripts SQL de création, mais aussi l’inspection d’une base de données (par la commande python manage.py inspectdb), ou encore l’exécution de scripts SQL custom à chaque création/modification d’une table (par la commande python manage.py syncdb).

Les méthodes

La méthode basique

… qui casse complètement le principe DRY (Don’t Repeat Yourself): maintenir les deux parties en parallèle.

Lorsqu’il faut rajouter une table dans la base, ou y apporter une modification, faire la modification dans MySQLWorkbench, puis répliquer l’ajout/la modification dans les modèles Django.

Pour: Méthode simple, pas de procédure ou méthode à mettre en place.
Contre: Méthode manuelle, sujette à l’erreur humaine (faute de typo, oubli…).

MySQLWorkbench => Django

1. Maintenance dans l’outil MySQLWorkbench, puis export des scripts de création/modification.
2. Execution de ce script sur la base de données pour la mettre à jour
3. Utilisation de inspectdb avec Django pour mettre à jour les modèles

Pour: Méthode automatique, donc pas de risque de typo ou d’oubli
Contre: Méthode très complexe à mettre en place. En effet, inspectdb est loin de créer des modèles fidèles, et il manque de nombreuses informations (un futur billet sera écrit sur ce sujet).

Django => MySQLWorkbench

1. Ajout ou modification d’un modèle dans Django
2. Mise à jour de la base de donnée en utilisant python manage.py syncdb (et des scripts custom si nécéssaire)
3. Utilisation de MySQLWorkbench pour reverse engineer les scripts de création de la base de donnée

Pour: Méthode automatique, donc pas de risque de typo ou d’oubli. De plus, contrairement à la méthode précédente, la représentation des tables est 100% fidèle à la structure de la base de donnée créée par les Django.
Contre: Toutes les informations de commentaires (et d’autres, comme nous le verrons dans un futur billet) sont perdues à chaque modification.

Conclusion

Je n’ai malheureusement pas trouvé à l’heure actuelle de méthode miracle. Il y a des pistes, mais il semble qu’il n’y ai rien de concret pour le moment.

Pour certains cas particuliers, l’une ou l’autre méthode sera préférée:

1. Création d’une nouvelle table: la méthode Django => MySQLWorkbench sera facile à mettre en place, et il n’y aura rien de perdu vu qu’il n’y a pas d’existant
2. Modification d’une table par le rajout d’un nouveau champ: l’une des deux méthodes automatique peuvent faire l’affaire
3. Modification d’un champ d’une table: la méthode manuelle sera en général la plus rapide et la plus simple à mettre en place
4. Modifications complexes, multiples, perte de donnée possible…: dans ce cas, point de salut, il ne reste que la méthode manuelle, et une grande concentration!

Et vous, quelle est votre méthode?

Le champ upload_to permet d’indiquer où sauver un fichier de type django.core.files.File par rapport au MEDIA_ROOT spécifié dans les settings.

Ce champ peut être une chaîne de caractères, ou un callable.

Chaîne de caractères pour upload_to

Pour notre example, prenons le modèle suivant:

class MonModele(models.Model):
    fichier = models.FileField(upload_to="chemin")

Dans ce cas simple, tous les fichiers seronts sauvés dans le répertoire <MEDIA_ROOT>/chemin/.

Si on upload un fichier nommé MonFichier.txt, le chemin complet (sans le MEDIA_ROOT) sera chemin/MonFichier.txt.

Il est par ailleurs possible d’utiliser une syntaxe strftime comme indiqué dans la documentation du module time.

Pour stocker un fichier avec la date et l’heure:

class MonModele(models.Model):
    fichier = models.FileField(upload_to="chemin/%Y%m%d_%H%M%S")

Et le résultat sera chemin/2009-02-19_18:40:03/MonFichier.txt, ce qui n’est pas vraiment ce à quoi on s’attendait.

En effet, cela créera un répertoire par fichier, au lieu de stocker la date et l’heure dans le nom du fichier.

Pour arriver à nos fins, il nous faut utiliser une fonction pour le calcul du chemin de stockage du fichier.

Fonction pour upload_to

Utiliser une fonction pour le calcul du chemin de stockage permet:

1. de modifier le nom du fichier lui-même, et pas seulement son répertoire de stockage
2. d’utiliser des informations spécifiques à l’instance du modèle pour lequel on stocke le fichier

Il nous faut par contre respecter les contraintes suivantes:

1. la fonction aura deux paramètres: self, l’instance, et filename, le nom du fichier uploadé
2. il n’est plus possible d’utiliser directement la syntaxe strftime

Voici le code qui va stocker un fichier avec la date et l’heure (et prendra la date et l’heure automatiquement ajoutée au champ DateTimeField avec le paramètre auto_add_now):

class MonModele(models.Model):
    date = models.DateTimeField(auto_now_add=True)
    def upload_path(self, filename):
        return 'chemin/%s_%s' % (self.date.strftime("%Y%m%d_%H%M%S"), filename)
    fichier = models.FileField(upload_to=upload_path)

Ce coup-ci, on obtient bien un fichier chemin/2009-02-19_18:40:03_MonFichier.txt, comme prévu.

Tester un modèle avec FileField dans l’interpréteur Python

Pour pouvoir tester un modèle avec un FileField dans un intepréteur Python (python manage.py shell), il y a quelques précautions à prendre, comme commencer par « sauver » le File, comme indiqué sur la page suivante.

En effet, pour que le modèle soit correctement instancié, il faut:

1. créer une instance du modèle
2. la sauver (dans notre cas, afin que la date soit automatiquement stockée, et devienne accessible dans upload_path)
3. ouvrir le fichier à « uploader »
4. créer un django.core.files.File à partir de ce fichier
5. sauver ce fichier pour pouvoir ensuite le tester

>>> from mysite.models import *
>>> mm = MonModele()
>>> mm.save()
>>> mm.date
datetime.datetime(2009, 2, 19, 19, 4, 49, 538465)
>>> from django.core.files import File
>>> f = File(open("MonFichier.txt"))
>>> mm.fichier.save(f.name, f, save=False)
>>> mm.fichier
<FieldFile: chemin/20090219_190449_settings.py>

Pour « sauver » le fichier, il faut fournir à la méthode save le nom du fichier (f.name), le fichier lui-même (f), et un paramètre spécifiant si on veut sauvegarder le fichier dans la base de donnée ou pas.

Si nous ne voulions pas accéder à date qui est stockée automatiquement, il aurait été inutile de sauvegarder l’instance de MonModele (mm), et il aurait alors fallut remplacer le code de upload_path de la sorte

def upload_path(self, filename):
    return 'chemin/%s_%s' % (self.date.strftime("%Y%m%d_%H%M%S"), filename)

par

def upload_path(self, filename):
    import time
    return 'chemin/%s_%s' % (time.strftime("%Y%m%d_%H%M%S"), filename)