Nous avons des remontés d'utilisateurs concernant les erreurs 503 qui surviennent régulièrement sur certains sites hébergés sur les instances Simple Hosting. Cette erreur est bien souvent traduite par les utilisateurs comme un dysfonctionnement de notre infrastructure, une mauvaise configuration de l'instance ou autre, laissant penser à des incidents du coté de Gandi. Or, dans la plupart des cas relevés par le support et l'équipe technique, l'erreur se trouve du coté des applicatifs installés sur les instances et de leur configuration.

Pour expliquer cette erreur, il est nécessaire de regarder de plus près l'infrastructure de notre offre PaaS. L'explication est simplifiée, afin de ne pas perdre les personnes non techniques et se limite aux éléments principaux de l'infrastructure.

Voici un schéma du fonctionnement de notre offre Simple Hosting :

Tout d'abord, se trouve un serveur de cache, Varnish, qui est présent afin de soulager les instances en conservant en cache des éléments pendant une durée limitée (ce n'est pas sa seule fonction mais pour des raisons de lisibilité). Lorsque vous demandez une page qui se trouve sur une instance Simple Hosting, c'est donc le serveur de cache qui recevra en premier la requête, puis il la retransmettra au serveur Web installé sur l'instance.

Le serveur Web qui reçoit la requête va alors chercher le contenu sur l'instance, puis le renvoyer au serveur de cache qui le renverra ensuite vers le visiteur ayant demandé la page. Dans le cas de fichiers HTML, la page est envoyée directement puisque le contenu n'est pas dynamique. Si vous utilisez un langage pour générer vos pages, tel que php, Python, node.js ou autre, celle-ci est générée par l'interpréteur du langage puis transmise au serveur Web qui renvoi la requête.

C'est exactement à cette étape que l'erreur 503 surviendra si tout ne se passe pas correctement. Le serveur de cache qui a transmis une requête à l'instance attend une réponse: la page que le visiteur a demandé. Si l'instance ne répond pas, quelque soit la raison, alors cela provoquera la fameuse erreur 503.

Les raisons de la non réponse peuvent être multiples, il faut alors analysée ce qu'il se passe sur l'instance afin de comprendre pourquoi elle n'a pas répondue. Nous avons relevé plusieurs erreurs très fréquentes :

• Les instances sous dimensionnée : Ce sont des instances qui ne sont pas correctement dimensionnées par rapport aux besoins. Par exemple, un trop grand nombre de visiteurs, des plugins à foison ou très lourd occupant trop de processus ou de ressources.

• Les 'timeout' (temps maximum d'exécution d'un script avant de renvoyer une erreur) : Lorsqu'un script s'exécute depuis plus de 180 secondes, alors celui-ci s'arrête. Ce fonctionnement est normal et permet d'éviter la consommation de ressource dans le cas d'un script contenant un bug.

• L'espace disque de l'instance plein : Le disque de donnée de l'instance est rempli à 100%. Dans ce cas, les services présents sur l'instance ne pourront pas fonctionner correctement et les requêtes ne pourront pas être renvoyée au serveur de cache Varnish

Ce sont les cas les plus courants sur lesquels nous avons des retours, ils ne sont cependant pas exhaustifs. Les erreurs peuvent provenir d'un incident de notre coté, d'un bug de l'interpréteur du langage, d'un bug sur l'un des plugins du CMS, etc., etc.

Ainsi, il ne faut pas nécessairement remettre en question la stabilité de notre plateforme lorsque cette erreur survient, elle se situe peut-être au niveau des applicatifs utilisés. Par la même occasion, nous vous conseillons d'utiliser le serveur de cache mis à disposition afin d'exploiter au maximum la puissance de Simple Hosting. Si vous ne vous sentez pas de configurer vous même la gestion du cache, des plugins existent pour la plupart des CMS facilitant l'installation et la configuration.

Certains d'entre vous ont peut être contacté notre support afin de comprendre l'origine des erreurs. Lorsque nous analysons les demandes et les problématiques, nous devons prendre en compte les erreurs applicatives et effectuer les corrélations afin de comprendre la source du problème et de pouvoir vous guider dans leur résolution. Cela passe par l'analyse des logs de l'instance. Nous ne pouvons cependant pas aller au delà, il nous est impossible de regarder le code source de centaines de sites Web et de suggérer les corrections. Lorsque vous contactez le support, nous vous conseillons de décrire votre problème de manière détaillée afin que votre demande soit analyser le plus efficacement possible.

Nous utilisons les instances Simple Hosting pour certains sites tel que lebardegandienvrai.net, cestquoi.gandi.net ainsi que le projet RAVIR (http://ravir.io/).

NB : Cet article n'est pas complètement juste techniquement, il omet certains détails et simplifie les interactions entre les divers éléments. Il s'adresse au grand public et a donc été simplifié, mais pas à outrance :) Pour ceux que cela intéresse, il existe un article plus technique à l'adresse suivante : lacuisinedegandi.net/post/2012/02/17/La-plate-forme-PAAS-du-SimpleHosting

Bonus : La preuve par 503

Afin d'illustrer l'exemple ci-dessus, voici une manière simple de générer une 503 sur une instance PHP.

Exécutons une boucle infinie (la boucle ne se terminera jamais car la condition est toujours remplie, et l'interpréteur arrêtera alors l'exécution du script au bout de X secondes)

<?php
while (True)  { }
?>

Maintenant exécutons le script dans un navigateur (si ça mouline, vous êtes sur la bonne voie) :

Nous pouvons voir l'erreur PHP à l'origine de l'erreur 503 dans les logs de l'instance. Précisément dans le fichier de log 'fpm.log' car c'est le processus FPM qui s'est arrêté:

[22-Jul-2016 10:53:01] WARNING: [pool www] server reached max_children setting (2), consider raising it

Dans cet exemple, vous pouvez voir que l'erreur 503 n'est pas lié à un dysfonctionnement de la plateforme mais à une erreur de code (ici volontaire, mais qui pourrait survenir sur des applicatifs).