Tout le monde a l'habitude de configurer plus ou moins correctement le s de HTTPs. Ce s, c'est le chiffrement SSL/TLS basé sur une paire de certificats x509. On le retrouve aussi sur d'autres protocoles communs, mais HTTPs est le cas le plus simple :

• il n'y a que SSL/TLS sur le port 443, pas de STARTTLS sur le 80;
• le client annonce dans sa requête le nom de domaine sur lequel il se connecte. Le serveur peut donc s'adapter en fonction, c'est le système des virtualhost.

Qu'en est-il des serveurs mail ? SMTP, IMAP4 et POP3 sont des protocoles fonctionnant différemment de HTTP. Dans ces protocoles, le client n'annonce pas le nom de domaine sur lequel il se connecte. Impossible pour le serveur de procéder comme en HTTP et disposer d'une configuration différente en fonction du domaine, autrement dit de gérer des vhost.

Mais alors comment gérer les certificats x509 pour chaque nom de domaine géré ?

Dans l'article précédent, nous avons vu comment déployer une application web Python avec Nginx et uWSGI, en prenant l'exemple de l'application 0bin. En conclusion, nous avions cependant noté que cette application était livrée avec toutes les bibliothèques nécessaires, ce qui est rarement le cas. En général, les applications sont plutôt livrées avec un fichier requirements.txt contenant la liste des dépendances à installer avec pip.

L'une des grandes forces de Python, c'est de permettre d'installer ces dépendances dans un environnement limité à l'application, pour que chaque application ait exactement la bonne version de chaque bibliothèque dont elle a besoin. Cet environnement est nommé virtualenv. Voyons comment le mettre en place et l'utiliser dans uWSGI.

Trop souvent, la supervision se limite à retourner des alertes quand certaines valeurs dépassent certains seuils. Classiquement, on retrouve toujours des sondes qui représentent des indicateurs de pannes proches voire déjà en cours : Ping, Load Average, Disk Usage, Memory Usage, etc.

Mais au delà de ces marqueurs universels, un système de supervision doit aussi permettre de détecter les problèmes avant qu'ils ne surviennent, et d'aider à résoudre les problèmes une fois qu'ils sont survenus. C'est notamment dans ce deuxième rôle qu'interviennent les graphes, en aidant à cibler les causes du problème le plus rapidement possible.

Dans cet article, nous allons voir comment superviser une métrique trop souvent ignorée, le niveau d'utilisation du serveur web. Si votre site web commence à ralentir, c'est à peu près la seule valeur qui permettra de savoir si le problème vient d'un nombre de visites mal estimé par le client, ou d'un besoin en ressources mal estimé par l'administrateur. Ça vous aidera aussi à isoler rapidement la source du problème.

Ce début d'année 2014 annonce de grandes avancées pour notre projet. Alors que nous sommes entrain de finaliser les statuts et les prévisionnels comptables avec notre cabinet d'avocats et notre cabinet comptable, nous venons d'intégrer nos bureaux au sein de la pépinière d'entreprise Pulseo à Dax, juste à coté de la gare SNCF.

Chez Sysnove, on adore Python. Parce qu'il est installé partout, parce qu'il n'a pas besoin d'IDE, parce qu'il est là depuis longtemps et pour encore longtemps, parce qu'il force la lisibilité, parce qu'il est hackable, parce qu'il y a une excellente doc, et surtout parce qu'il sert à tout, du petit script à la grosse application, du système au web et passant par le desktop et le traitement de données, du synchrone à l'asynchrone, etc. C'est le seul langage que je connaisse qui soit aussi complet et assez polyvalent pour se substituer efficacement à une bonne partie des DSL. Bref, quand on est administrateur système, c'est la clé du bonheur.

Mais rien n'est parfait, loin de là, et s'il y a un point sur lequel PHP n'a pas à rougir, c'est la simplicité d'héberger des applications web, que ce soit avec Apache ou derrière Nginx. En Python, c'est une tout autre histoire, mais ça a l'avantage de permettre de comprendre ce que l'on fait, et d'en profiter pour le faire bien.