Hébergement Node.js
Un processus qui ne s’arrête jamais demande autre chose qu’un mutualisé
Une application Node.js n’est pas un script appelé à chaque visite : c’est un programme qui tourne en permanence. Il lui faut une machine ou un conteneur — que nous exploitons, à Nantes.
- Serveur privé ou conteneur, selon le projet
- Processus supervisé, relancé s’il s’arrête
- Reverse proxy et certificat SSL automatique
- Sauvegarde, supervision et astreinte comprises
Le principe
Ce qui change par rapport à PHP
Pourquoi le mutualisé ne convient pas
Une plateforme mutualisée est faite pour exécuter un script à l’arrivée d’une requête, puis l’oublier. Une application Node.js fonctionne à l’inverse : elle démarre une fois et reste en mémoire, en attente de connexions.
Il lui faut donc un endroit où un programme a le droit de tourner en permanence : un serveur privé ou un conteneur. C’est le principal écart de coût avec une application PHP, et il vaut mieux l’avoir en tête au moment de choisir la technologie.
Ce qui doit être en place autour
Quatre choses, qu’on découvre rarement dans un tutoriel :
- Un superviseur. Un processus s’arrête toujours un jour — une exception non rattrapée, une mise à jour, un manque de mémoire. Il doit être relancé automatiquement, et l’incident doit être remonté.
- Un reverse proxy devant. L’application ne doit pas être exposée directement : le proxy porte le certificat SSL, le nom de domaine, la compression, et permet de basculer d’une version à l’autre sans coupure.
- Une limite de mémoire assumée. Node.js consomme jusqu’à ce qu’on lui dise d’arrêter ; sans plafond, une fuite finit par emporter la machine entière.
- Les journaux sortis du processus. Ils disparaissent avec lui, sinon — précisément au moment où l’on en a besoin.
Une ou plusieurs instances
Un processus Node.js n’utilise qu’un cœur. Sur une machine qui en a plusieurs, on fait donc tourner plusieurs instances de l’application derrière le proxy, qui répartit les requêtes entre elles. Cela multiplie la capacité et permet aussi de mettre à jour sans interruption : les instances sont remplacées l’une après l’autre.
Une condition, et elle vient du code : l’application ne doit rien garder en mémoire qui doive survivre à une requête. Les sessions vont dans un cache partagé — Redis, KeyDB ou Memcached — pas dans la mémoire d’un processus.
Serveur privé ou conteneur
Un serveur privé est le plus simple : la machine est à vous, l’application tourne dessus, nous l’exploitons. Un conteneur se justifie quand vous déployez souvent, quand plusieurs environnements doivent être identiques, ou quand plusieurs applications doivent cohabiter sans se marcher dessus.
Le socle
Ce que nous mettons en place
-
Processus supervisé
L’application est relancée automatiquement si elle s’arrête, et l’incident est remonté. C’est le minimum vital, et c’est ce qui manque le plus souvent.
-
Reverse proxy et SSL
Nginx, HAProxy ou Traefik devant l’application : certificat automatique, nom de domaine, compression, et bascule de version sans coupure.
-
Plusieurs instances
Un processus Node n’utilise qu’un cœur. Plusieurs instances derrière le proxy multiplient la capacité et permettent les mises à jour sans interruption.
-
Sessions et cache partagés
Redis, KeyDB ou Memcached : rien de ce qui doit survivre à une requête ne reste dans la mémoire d’un processus.
-
Journaux et métriques
Les journaux sortent du processus — ils disparaîtraient avec lui — et les métriques de la machine sont surveillées comme sur nos autres serveurs.
-
Exploitation complète
Mises à jour du système, sauvegarde répliquée hors site, correction automatique sur alerte et administrateur d’astreinte.
Questions fréquentes
Hébergement Node.js : vos questions
Une autre question ? Le support répond directement, sans intermédiaire, de 9h à 12h et de 14h à 17h.
Puis-je héberger du Node.js sur votre mutualisé ?
Non, et ce n’est pas une limite de notre offre mais la nature de la technologie : une plateforme mutualisée exécute un script à l’arrivée d’une requête puis l’oublie, alors qu’une application Node reste en mémoire en permanence. Il lui faut un serveur privé ou un conteneur.
Que se passe-t-il si l’application plante ?
Elle est relancée automatiquement par le superviseur, et l’incident remonte à nos outils : en cas d’alerte ils corrigent d’abord, puis préviennent un administrateur d’astreinte. Un processus qui redémarre en boucle sans que personne le sache est un incident en préparation, pas une solution.
Serveur privé ou conteneur ?
Le serveur privé est le plus simple, et suffit à la plupart des projets. Le conteneur se justifie quand vous déployez souvent, quand plusieurs environnements doivent être strictement identiques, ou quand plusieurs applications doivent cohabiter sans se gêner.
Comment déployer sans coupure ?
En faisant tourner plusieurs instances derrière le proxy et en les remplaçant l’une après l’autre. Deux conditions côté application : qu’elle ne garde rien en mémoire qui doive survivre à une requête, et qu’elle s’arrête proprement quand on le lui demande.
Développez-vous aussi l’application ?
Oui — nous employons Node.js principalement sur les projets qui doivent traiter un nombre important de requêtes simultanées. Avoir le développement et l’exploitation au même endroit évite de se renvoyer la balle quand quelque chose ralentit.
Votre application garde-t-elle quelque chose en mémoire ?
C’est la question qui décide de la possibilité de la dupliquer — et donc de tenir la charge et de déployer sans coupure.