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 ! Aujourd’hui intéressons nous à la base de données !
Les solutions logicielles sur un kimsufi (partie 4)
Le cas du reverse proxy
Un reverse proxy est un serveur mandataire qui se charge de publier visiblement sur internet des sites et applications dont il ne détient pas le contenu. Pour l’utilisateur c’est ce serveur qui sert le texte et les images alors qu’il s’agit en fait souvent d’un agrégat de contenus sur d’autres serveurs. Vu que nous ne possédons qu’un seul serveur dans cet exemple, il irait donc chercher les informations à afficher sur d’autres serveurs logiciels écoutant sur des ports différents. Quel peut donc en être l’intérêt ?
Cas classique d’utilisation d’un reverse proxy dans un cadre mono-serveur
Il est assez classique de rencontrer ce genre de setup et cela présente plusieurs avantages:
Agrégation de contenu & d’applications
Imaginez que vous ayez développé plusieurs applications qui constituent un tout logiciel, un reverse proxy vous permettra de les regrouper sous un ensemble homogène d’urls (ex: monsite.fr/register, monsite.fr/newsletter, monsite.fr/blog, etc…) au lieu d’utiliser des sous domaines et des virtual hosts différents.
Performances
Dans ce contexte on rencontre souvent des reverse proxies configurés en mode cache, qui sont capable de servir directement les statiques de votre site sans faire d’allers-retours avec les “vrais” serveurs logiciels derrières. Il en résulte logiquement un gain de performance non négligeable.
Sécurité
Le reverse proxy étant le seul élément visible depuis l’extérieur, il est aussi la cible première des attaques (Scans, DDOS, url escaping & co). Il peut tomber, mais cela ne met pas en cause la sécurité de vos serveurs derrière ou du moins moins facilement. Surtout que vous pouvez y ajouter des règles de sécurisation maison ou prédéfinies afin de protéger vos serveurs web. On parle alors de Pare Feu Applicatif ou WAF (web application firewall).
Alors il nous en faut un ?
D’après les tests que j’ai pu faire, un reverse proxy même si c’est quelque chose d’intéressant, n’est pas pertinent sur un serveur kimsufi qui héberge un site simple. La concurrence pour le nombre de threads CPU est déjà très élevée entre le serveur web, PHP & la base de données pour rajouter un autre worker qui n’aura pas assez de slots CPU libres pour servir les requêtes rapidement et le gain de performance n’est pas évident du tout. Par contre le gain en terme de sécurité et d’agrégation de contenu est bien présent. Il faut toutefois avoir en tête que vous vous rajoutez un logiciel en plus a maintenir et configurer, et que donc le mal peut être pire que le bien si vous n’en avez pas vraiment besoin.
Conclusion Reverse Proxy
Mon conseil dans le cadre qui nous occupe est de se passer d’un reverse proxy sauf si vous avez besoin d’agrerger plusieurs sous site de manière homogène. Votre serveur web déja en place peut tout à fait faire cela (nginx & apache proposent des modules reverse proxy) et il n’est donc pas nécessaire d’en installer un en plus. Par contre dès que vous avez plsuieurs serveurs derrière vous pouvez vous pencher sur Varnish ou Squis, 2 reverse proxies aux performances incroyables. Dans le prochain article nous discuterons de divers points d’optimisations de votre plateforme qui commence à prendre forme sur le papier !