Documenter le déploiement d'une application dynamique web ou web mobile
📚 Références
- REAC (mise à jour du 03/07/2024), page 29
- RE (mise à jour du 03/07/2024), page 12
📋 En résumé
Allez, on clos la dernière compétence professionnelle de ce millésime 2023 avec la documentation du déploiement !
Et heureusement, on n'attend pas de toi de maîtriser un serveur dans les détails, mais d'expliquer comment mettre en ligne ton projet.
Tu as le droit d'utiliser des plateformes de déploiement en ligne comme Vercel, Netlify, Heroku, etc.
Mais la compréhension, même basique, d'un serveur Linux est quelque chose d'extrêmement apprécié et enrichissant.
🤖 Les plateformes de déploiement en ligne
Selon la plateforme utilisée, la procédure de déploiement peut varier. Certaines plateformes peuvent déployer automatiquement ton projet à partir de ton dépôt Git, d'autres nécessitent de passer par la ligne de commande pour push une branche spécifique sur le serveur de la plateforme.
C'est à toi (et ton équipe) de choisir la plateforme qui vous convient le mieux et de documenter la procédure de déploiement afin que tout le monde puisse s'y retrouver.
🤝 Les serveurs mutualisés
Beaucoup d'hébergeurs proposent des serveurs mutualisés, c'est-à-dire que plusieurs sites web partagent les ressources d'un même serveur (même si tu n'es pas le responsable des autres sites hébergés sur le serveur).
Il s'agit d'une solution moins coûteuse que les serveurs dédiés ou les VPS, mais qui peut être moins performante en fonction de la qualité de l'hébergeur.
Cependant, pour un site web de petite ou moyenne envergure, un serveur mutualisé peut suffire et surtout : il est souvent plus simple à gérer.
Parenthèse éco-conception
On peut également considérer que l'utilisation de serveurs mutualisés est plus écologique, car elle permet de mutualiser les ressources et de limiter le nombre de serveurs physiques nécessaires pour héberger des sites web.
Moins de matériel physique = moins de consommation d'énergie = moins d'émissions de CO2.
Mais attention, les serveurs mutualisés ne permettent pas de configurer entièrement le serveur (par exemple, tu ne pourras pas installer un serveur Node.js sur un serveur mutualisé qui n'est pas prévu pour).
Il est donc important de bien se renseigner sur les fonctionnalités proposées par l'hébergeur avant de choisir un serveur mutualisé.
🔨 Les serveurs dédiés et VPS
Maintenant, le meilleur du meilleur : les serveurs dédiés et les VPS !
Ça peut faire peur sur le papier car on devient l'unique gestionnaire et responsable du serveur, mais c'est certainement la meilleure façon de comprendre comment fonctionne un serveur web.
La configuration la plus classique que l'on retrouvera sur un serveur dédié ou un VPS est la suivante :
- Un système d'exploitation headless (sans interface graphique, à l'ancienne ! 👴) comme Ubuntu Server, CentOS, Debian, etc.
- Un serveur web comme Apache, Nginx, ou Caddy
- Une ou plusieurs bases de données comme MySQL, PostgreSQL, MongoDB, etc.
- Un serveur de langage comme Node.js, PHP, Ruby, Python, etc.
- Un gestionnaire de processus comme PM2, Supervisor, etc.
- Un gestionnaire de paquets comme APT, YUM, etc.
- Un pare-feu comme UFW, iptables, etc.
Dernière parenthèse éco-conception
Les serveurs dédiés et les VPS sont souvent plus énergivores que les serveurs mutualisés, car ils sont allumés en permanence (sauf configuration spécifique) et consomment plus d'énergie pour fonctionner.
Sur le papier, ça sonne moins bien, mais dans le concret : un serveur dédié ou un VPS bien configuré peut être plus écologique qu'un serveur mutualisé mal configuré (qui consomme plus d'énergie pour moins de performance). Comme on dit souvent :
Si tu recherches un hébergeur qui se veut éco-responsable (bien plus que la moyenne) : Infomaniak est un excellent choix.
(Non, je ne détiens aucune part chez eux, mais j'apprécie leur démarche et leur qualité de service donc un peu de pub gratuite ne fait pas de mal !)
D'ailleurs, sur toute la partie RGPD : Infomaniak a une politique de confidentialité et de sécurité très sérieuse que tu peux retrouver juste ici.
Et promis : elle est lisible et compréhensible, pas comme certaines politiques de confidentialité qui sont plus longues que l'intégrale de la saga Harry Potter.
Avant d'arrêter de parler de serveurs à configurer soi-même, je me permets d'ouvrir une toute petite rubrique sur la mise en ligne d'applications tournant sur des ports autres que le 80 (ou 443 pour le HTTPS), comme on peut le faire avec un serveur Node.js.
🚪 Les reverse proxies
Un serveur web classique écoute sur les ports 80 et 443 pour les requêtes HTTP et HTTPS.
Sauf que ton application va probablement tourner sur d'autres ports, que ce soit 3000, 5000 ou je ne sais quel autre numéro.
Notre objectif avec les reverse proxies, c'est de lier un domaine (sur les ports 80 et 443) à un port interne spécifique de notre serveur.
C'est un peu comme une "pseudo-redirection", mais qui sera invisible pour l'utilisateur.
📦 Nginx
Nginx est un serveur web qui est souvent utilisé comme reverse proxy, notamment pour sa simplicité de configuration et sa syntaxe nettement moins verbeuse que celle d'Apache.
Prenons l'exemple d'un serveur Node.js qui tourne sur le port 5000.
# Ensemble de configurations pour un serveur Nginx
server {
listen 80; # Port 80 pour les requêtes HTTP
listen [::]:80; # Port 80 pour les requêtes HTTP en IPv6
server_name mon-domaine.com; # Ton domaine qui pointe vers ton serveur web qui fait tourner ton application Node.js
# Configuration pour le reverse proxy, qui va rediriger les requêtes vers le port 5000
location / {
proxy_pass http://0.0.0.0:5000; # Redirige les requêtes vers le port 5000 (interne au serveur)
proxy_set_header X-Forwarded-For $remote_addr; # Envoie l'adresse IP du client à l'application Node.js dans le header
proxy_set_header Host $http_host; # Envoie le nom de domaine à l'application Node.js dans le header
}
}
Oui, c'est aussi simple que ça ! Alors effectivement, il y a d'autres configurations possibles, mais pour un usage basique : c'est tout ce dont tu as besoin.
📦 Caddy
Caddy est un serveur web qui se veut simple à configurer et qui propose de nombreuses fonctionnalités "out-of-the-box", comme la gestion automatique des certificats SSL (gratuits) avec Let's Encrypt.
Pour le coup je n'ai pas encore eu l'occasion de faire des tests avec Caddy, mais je sais que la configuration pour un reverse proxy est extrêmement simple, voire plus simple que celle de Nginx.
📦 Apache
On ne le présente plus, Apache est certainement le serveur web le plus utilisé au monde.
Au delà d'être d'être installé par défaut avec toutes les solutions type Wamp, Xampp, Mamp, etc., on utilise régulièrement Apache sur de vrais serveurs.
Sa configuration est un peu plus verbeuse que celle de Nginx, mais si ça t'intéresse de découvrir Apache : je t'invite à consulter la documentation officielle.
❓ Les autres solutions
Il existe d'autres solutions pour déployer une application web, mais je pense que tu as déjà pas mal de lecture pour aujourd'hui.
Par contre, il y a une solution que je te recommande de ne jamais utiliser : les serveurs FTP.
Alors oui, c'est pratique, c'est simple, mais on attend de toi une approche de développeur !
Tu as de nombreux outils spécialement conçus pour le déploiement, l'automatisation, la gestion de versions, etc.
C'est ton rôle d'utiliser ces outils pour déployer ton projet, et non pas de faire du simple drag-n-drop de fichiers via FTP et attendre 45 minutes pour transférer un dossier de 10 Mo (oui, j'ai déjà vu ça et même bien pire que ça quand on se souvient qu'on a des node_modules ou les dépendances PHP dans le dossier vendor 🤡).
🎯 Critères d'évaluation
- La procédure de déploiement est rédigée ou mise à jour
- Les scripts de déploiement sont écrits et documentés
- Le système de veille permet de suivre les évolutions technologiques et les problématiques de sécurité liées au déploiement d'une application dynamique web ou web mobile, y compris dans le cadre d'une démarche DevOps