deploiement
Comment déployer une petite web app sur un VPS sans DevOps
Votre app tourne très bien sur votre ordinateur portable — le plus dur, c'est l'écart entre « ça marche sur ma machine » et « c'est en ligne sur internet ». Voici ce que déployer signifie vraiment, les quatre choses dont chaque app a besoin, et comment vous passer de toute la configuration.
Vous avez construit quelque chose. Ça tourne sur votre ordinateur portable — vous tapez une commande, vous ouvrez localhost, et c'est là. Maintenant vous voulez que d'autres personnes le voient, à une vraie adresse, sur internet. C'est à cette dernière étape qu'un nombre surprenant de projets personnels s'enlisent en silence.
Le code est prêt. Ce qu'il reste, c'est tout ce qu'il y a autour : amener votre app sur un serveur, la maintenir en marche même après avoir fermé votre portable, et la rendre accessible à une adresse digne de ce nom, avec un cadenas. Cet ensemble de corvées porte un nom — DevOps — et c'est la partie pour laquelle personne ne s'était inscrit.
Ce que « déployer » veut vraiment dire
Déployer, ce n'est rien d'autre que faire passer votre app de « ça tourne sur ma machine » à « ça tourne sur une machine que le monde entier peut atteindre ». Pour cela, trois choses doivent être vraies :
- le code doit être sur le serveur,
- il doit continuer de tourner — y compris après un plantage ou un redémarrage,
- et les visiteurs doivent pouvoir l'atteindre à un domaine, en HTTPS.
Sur votre portable, vous obtenez les deux premières presque gratuitement : vous lancez l'app et elle tourne jusqu'à ce que vous l'arrêtiez. Un serveur, c'est autre chose — et c'est précisément cette différence qui constitue tout le travail.
Le mur entre votre app et internet
Voici la pile de petits éléments peu familiers qui se met généralement en travers du chemin :
- Un gestionnaire de processus — votre app doit démarrer toute seule et se relancer après un plantage ou un redémarrage. Si vous la lancez à la main, elle meurt à l'instant où vous vous déconnectez.
- Un reverse proxy — votre app écoute sur un port interne comme le 3000, mais les visiteurs arrivent sur le 80 et le 443. Il faut quelque chose devant pour les aiguiller vers l'intérieur.
- HTTPS — le cadenas. Un certificat, émis et renouvelé, sans quoi les navigateurs étiquettent votre site comme « Non sécurisé ».
- Un domaine et une porte ouverte — le nom doit pointer vers le serveur, et le pare-feu doit laisser passer le trafic web.
Aucun de ces éléments n'est difficile pris isolément. Ensemble, pour un premier déploiement, ils forment un mur — quatre outils que vous n'avez jamais rencontrés, chacun avec son propre fichier de configuration et sa propre façon d'échouer en silence.
Ce dont votre app a vraiment besoin
Écartez les outils et les besoins deviennent simples. Votre app a besoin d'un endroit où tourner, d'un moyen de rester en marche, d'un chemin depuis l'adresse publique jusqu'à son port interne, et d'un certificat pour que la connexion soit privée. C'est toute la liste. Chaque outil dans la pile du DevOps existe pour répondre à l'un de ces quatre besoins.
Gardez cela en tête et déployer cesse de ressembler à de la magie. Ce sont quatre besoins — quelle que soit la manière dont vous choisissez d'y répondre.
Le raccourci
Vous pouvez assembler chaque pièce vous-même : choisir un gestionnaire de processus, configurer un reverse proxy, mettre en place les certificats, faire pointer le domaine, ouvrir le port. C'est une vraie école, et un vrai après-midi — ou trois. Ou bien vous pouvez laisser Server Manager s'en charger : vous lui dites que vous avez une web app et l'adresse à laquelle elle doit vivre, et il met votre app sur le serveur, la maintient en marche à travers les plantages et les redémarrages, achemine votre domaine vers elle et active le HTTPS — les quatre besoins, gérés, sans le moindre fichier de configuration en vue.
Le seul prérequis, c'est le domaine. Si vous ne l'avez pas encore fait, commencez par connecter un domaine à votre serveur — et le cadenas suit tout seul une fois que le nom se résout.
Votre app, votre serveur
L'écart entre « ça marche sur ma machine » et « c'est en ligne » est l'endroit où beaucoup de bonnes idées finissent par attendre pour toujours. Ça ne doit pas se passer comme ça. Le code était la partie difficile, et vous l'avez déjà faite — le mettre en ligne devrait être la partie facile, pas le mur qui vous arrête. Votre app, sur votre propre serveur, à votre propre adresse : c'est là toute la récompense.
Les guides d'aide vous accompagnent pas à pas dans le déploiement d'une app, dès que vous êtes prêt.