Linux, Nginx et Cloud : déployer une application que l'on peut suivre
Reverse proxy, HTTPS, logs et sauvegardes : les éléments à penser autour du code lors d'un déploiement.
Le déploiement dépasse le démarrage du processus
Une application qui répond sur un port local n'est pas encore un service fiable. Sur un serveur Linux, je distingue le processus applicatif, le reverse proxy, le nom de domaine, le certificat TLS et la base de données. Nginx peut recevoir les requêtes publiques et les transmettre au service applicatif ; chaque couche doit avoir une configuration compréhensible.
Les contrôles qui comptent
- Limiter l'exposition réseau aux ports nécessaires.
- Servir le trafic public en HTTPS et prévoir le renouvellement des certificats.
- Vérifier les variables d'environnement et les permissions des fichiers.
- Centraliser des journaux utiles sans y enregistrer de secrets.
- Prévoir des sauvegardes et tester leur restauration.
- Ajouter une vérification de santé et surveiller erreurs, latence et saturation.
Je documente enfin le chemin du retour arrière : quelle version était en service, comment y revenir et quelles migrations rendent ce retour délicat. L'objectif est de pouvoir diagnostiquer un incident sans improviser sous pression.
À retenir : un déploiement est terminé quand l'application est accessible, observable et récupérable, pas seulement quand le build passe.
Pour aller plus loin : guide Nginx sur le reverse proxy.