Votre architecture réseau ne regarde pas vos correspondants, cependant vous avez donné aux plus curieux d’entre eux quelques bribes d’information à votre insu : ip interne, dns interne, chaîne de mta…
Nous allons voir un exemple récent, déterminer quels logiciels font les pies et finir par quelques réglages de ces derniers.
OpenVZ est un système de virtualisation particulier. Il permet de faire tourner de multiples machines virtuelles partageant un seul kernel patché spécialement pour l’occasion. Cette techniques est donc limités à des machines (hôte ou invité) tournant sous linux. En contrepartie les performances sont particulièrement élevés. Il est également très aisé de modifier les particularités physiques des machines virtuelles sans les redémarrer. Cette technique est souvent employée chez les hébergeurs pour les offres « VPS ».
En pratique, c’est utile à des fins de sécurité. On essaie de mettre un seul serveur par VPS (serveur web sur un VPS, MySQL sur un autre, mail encore sur un autre …). Si l’un des serveurs possède une faille de sécurité, les autres serveurs ne pourront alors pas être impactés. Il y a également la facilité à backuper une machine virtuelle et donc au besoin de la dupliquer ou la déplacer. Cependant, on ne peut pas faire de migration à chaud comme certains de ses concurrents.
La création d’une machine ne prend guère plus d’une minute sur une machine correcte, ce qui permet de s’en servir comme d’un moyen de tester des logiciels sans encombrer votre distro. Qui plus est, le lancement d’une machine est quasi instantané, ce qui peut parfois sauver des manchots…
Python est devenu assez à la mode, pour le développement web, ces dernières années avec l’arrivée de frameworks web comme Django, Pylons et web.py. On le voit souvent utilisé sur apache2, avec mod_python, ou sur des serveurs Python dediés à ça (CherryPy, etc)
Je cherche depuis longtemps un moyen de faire du Python sur HTTP. J’ai mis pas mal de temps mais je pense avoir trouvé une configuration sympa.
Je vous propose ici d’essayer nginx, un serveur HTTP (entre autres), très performant et beaucoup plus léger/rapide que apache2. Il est très efficace pour faire du reverse-proxy (c’est à dire être utilisé en frontal/load-balancer devant un serveur HTTP, et lui transmettre les requêtes en faisant du cache et le cas échéant du load-balancing).
