Dans l’article précédent nous nous demandions quelle est la meilleure configuration pour un serveur web hébergé chez OVH sur un serveur Kimsufi ? C’est une question que l’on peut rencontrer souvent sur les forums d’OVH (entre autre). webofmars vous propose une série d’articles pour y répondre. Cet article se veut collaboratif, postez vos commentaires et idées dans les commentaires ci-dessous, nous les intégrerons et proposeront à la fin une configuration globale (sur github par exemple) pour pouvoir déployer un serveur rapidement. La question ce pose en terme de solutions mais aussi en terme de fichiers de configuration. L’OS de référence est une debian wheezy (7.0) mais le contenu est surement adaptable à une autre distribution assez facilement. Les bases étant maintenant posées, il est temps de retrousser les manches et les ourlets de pantalons nous attaquer de pleins pieds au sujet !

Les solutions logicielles sur un kimsufi (partie 1)

Le serveur web

Parmi les serveurs web disponibles (à ce sujet écouter le dernier épisode de l’excellent podcast tuperweb.fr avec Seb et votre serviteur) seuls 2 noms ressortent et vont être compatibles avec toutes les solutions dont on a besoin :

  • Apache le vénérable ancêtre bourré d’expérience
  • Nginx le petit jeune bourré de tallent.

Apache

Apache est le plus utilisé des serveurs web au monde. Dès que l’on rentre dans le contexte avec un langage de développement derrière autre que le basique HTML/CSS/JS c’est encore plus vrai. Aujourd’hui une différence fondamentale existe entre Apache et Nginx, lors d’une requête le processus maître qui détient la réponse apache va devoir scanner tous ses processus fils pour trouver lequel était en charge de la requête à l’origine. Ceci est vrai avec les MPM (Modèles Multi-Processing) originaux (prefork et worker notamment). Par contre la version 2.4 a vu apparaitre le MPM events qui est proche de ce que fait Nginx dans le principe et qui économise cette étape en s’appuyant sur des mécanismes récents du noyau Linux. Un gros avantage d’apache en plus d’être hyper standard et de disposer de plein de modules permettant une intégration aisée de toute application est son support des fichiers de configuration déportés dans l’application à savoir les fameux ‘.htacess’. Beaucoup de solutions connues comme wordpress (et ses plugins), dotclear et autres reposent sur ce mécanisme pour sécuriser le site ou activer des fonctionnalités de réécriture. Si vous partez sur Nginx il faudra les “traduire” dans la configuration centrale Nginx. L’avantage est que tout est au même endroit.

Nginx

En contrepartie Nginx est réputée pour sa robustesse et sa vélocité à servir des fichiers simples dont les applications sont grandement composées (CSS, images, javascripts, html pur). Ce test montre d’ailleurs à quel point la différence est vrai. Le language de configuration y est plus simple mais vous devrait réécrire les fichiers déportés.

Résumé

Le tableau ci-dessous présente les pours et les contres que j’ai pu noter par rapport à mes propres besoins, n’hésitez pas à commenter si vous en voyez d’autres : [table id=1 /]

Conclusion serveurs web

Finalement c’est Nginx qui sera le serveur web de notre plateforme parfaite. Son abilité à servir des éléments statiques à la vitesse de la lumière et sa configuration centralisée et claire en font un serveur web de choix, même si cela demande un travail supplémentaire à chaque intégration d’une application. Généralement la documentation des solutions en question est suffisante pour y répondre, donc pas d’inquiétude.   Dans le prochain article nous nous intéresseront aux choix à faire au niveau de PHP