Comment créer un SaaS? Architecture du système back-end
🇨🇦Étude de cas entrepreneurial micro-SaaS Convertisseur AIFF à MP3 Partie 1
Book a callÉtude de cas entrepreneurial micro-SaaS Convertisseur AIFF à MP3 Partie 1
Book a callL'architecture du serveur web repose sur des technologies modernes et robustes, à savoir Node.js et Express.js. Ces outils sont largement utilisés dans le développement d'applications web en raison de leur efficacité et de leur capacité à gérer une large quantité de requêtes HTTP de manière fluide. Dans ce contexte, le serveur a pour rôle principal de gérer ces requêtes entrantes, tout en assurant l'exécution des processus nécessaires à la conversion de fichiers audio. Cette gestion inclut la réception des données, leur traitement et leur renvoi sous la forme appropriée, garantissant ainsi une expérience utilisateur optimale.
Afin de mettre en place ce serveur, j'ai opté pour un hébergement cloud avec Linode, une plateforme offrant une infrastructure flexible et scalable. Le plan d’hébergement choisi, intitulé "attribution dynamique de hardware", me permet de bénéficier d’une allocation de ressources adaptative en fonction des besoins du système. Ce choix assure une gestion efficace des ressources, garantissant une performance stable et un coût maîtrisé, notamment pour un projet dont les exigences peuvent évoluer au fil du temps. Grâce à ce plan, Linode m’a attribué une adresse IP publique, ce qui m'a permis d'accéder à ma machine virtuelle, ou conteneur Docker, hébergeant l'application.
Sur cette machine virtuelle, j'ai installé plusieurs applications essentielles au bon fonctionnement du serveur. Parmi celles-ci, on retrouve Nginx, un serveur web performant et léger, Node.js, l'environnement d'exécution JavaScript, MySQL pour la gestion des bases de données, PM2 pour la gestion des processus, Node.js, et Certbot, un outil utilisé pour la gestion des certificats SSL. Ces applications ont été choisies pour leur complémentarité et leur capacité à offrir une solution complète pour déployer et maintenir une application web sécurisée et performante.
La première étape dans le processus de mise en ligne de l'application fut l'acquisition du nom de domaine aiffamp3.com via Namecheap, un fournisseur réputé dans la gestion des noms de domaine. Cette démarche a permis de garantir une identité numérique propre à l’application et de faciliter son accès pour les utilisateurs finaux. Une fois le nom de domaine acquis, j'ai configuré le registre DNS (géré également par Namecheap) pour pointer vers les serveurs de Linode. Cela a permis de lier le domaine à l'infrastructure cloud, en facilitant l'accès à l'application à travers une URL simple et mémorisable.
Sur le serveur Linode, j'ai ensuite créé les enregistrements DNS nécessaires, tels que les enregistrements de type A et AAAA, afin de garantir une configuration correcte du nom de domaine avec l’infrastructure de Linode. Ces enregistrements sont indispensables pour que le nom de domaine pointe vers l’adresse IP publique du serveur, et ainsi permettre à l’application d’être accessible via Internet.
Le processus de déploiement a ensuite consisté à cloner la première version de l'application directement depuis GitHub, où le code source est hébergé. GitHub offre une gestion de version et une plateforme de collaboration très efficaces, ce qui facilite le suivi des modifications du code et le déploiement continu. Afin d’automatiser le déploiement de l’application, j'ai configuré GitHub Actions, un outil d’intégration continue permettant de connecter GitHub au serveur Linode. Ce processus a été sécurisé grâce à l’utilisation des "credentials" nécessaires sous forme de secrets, pour garantir que seules les actions autorisées puissent interagir avec le serveur de manière sécurisée. Grâce à cette configuration, le déploiement de nouvelles versions de l’application peut être automatisé, réduisant ainsi les risques d’erreurs humaines et permettant des mises à jour plus rapides et plus fiables. Un script de déploiement a été mis en place pour exécuter cette tâche (plus de détails à ce sujet sont fournis dans la section 4.3).
Une attention particulière a été portée à la configuration des variables d'environnement. Ces variables sont essentielles pour que l’application fonctionne correctement dans l’environnement de production, en assurant que les configurations nécessaires à la base de données, aux services externes, et aux autres parties intégrantes de l'application soient présentes et correctement définies.
Une fois les configurations préalables effectuées, j'ai utilisé PM2 pour lancer l’application sur le serveur. PM2 est un gestionnaire de processus pour Node.js qui permet de garder l’application en vie en permanence, même en cas de crash, et de faciliter la gestion de son état (démarrage, arrêt, redémarrage). Il offre ainsi une solution robuste pour garantir la stabilité de l’application sur le long terme.
L'étape suivante a consisté à configurer Nginx en tant que reverse proxy. Nginx permet de relayer les requêtes HTTP vers l'application Node.js tout en jouant un rôle de serveur web principal. En utilisant cette configuration, j'ai pu garantir que l’application locale, exécutée sur le serveur, soit accessible via Internet tout en assurant une meilleure gestion des performances, de la sécurité et de la scalabilité. Le « reverse proxy » permet également de séparer les différentes couches du système, ce qui rend l'architecture plus flexible et modulaire.
Sur le plan de la sécurité, une configuration adéquate du pare-feu sur le serveur Ubuntu 20.04 a été mise en place. Les règles du pare-feu ont été définies pour autoriser uniquement le trafic sur les ports HTTP et HTTPS, afin de garantir que les services essentiels puissent fonctionner normalement tout en empêchant l'accès non autorisé à d’autres ports. Cette étape est cruciale pour protéger le serveur contre les attaques potentielles et garantir un environnement sécurisé pour l'application.
Enfin, pour assurer la sécurité des échanges de données entre l’application et ses utilisateurs, j'ai utilisé Certbot pour générer des certificats SSL. Ces certificats permettent de sécuriser les communications via le protocole HTTPS, en garantissant la confidentialité des informations échangées entre le serveur et les utilisateurs. L'utilisation de HTTPS est désormais un standard de sécurité pour les applications web modernes et permet de renforcer la confiance des utilisateurs en l'application. Ce processus a été automatisé avec Certbot, facilitant ainsi la gestion et le renouvellement des certificats.
Ainsi, l'architecture mise en place garantit non seulement une performance optimale de l'application, mais aussi une sécurité accrue pour les utilisateurs, tout en permettant un déploiement fluide et automatisé des mises à jour.
Le processus de déploiement automatique est essentiel pour garantir une mise à jour continue et fiable de l’application, tout en réduisant les erreurs humaines. Pour ce faire, un système d'intégration et de déploiement continu (CI/CD) a été mis en place via GitHub Actions, ce qui permet de déployer automatiquement les modifications effectuées sur la branche master de notre dépôt GitHub vers le serveur de production. Ce mécanisme est d'autant plus sécurisé que GitHub utilise des identifiants secrets pour accéder de manière sécurisée à notre serveur et exécuter les commandes nécessaires sans intervention manuelle.
Le processus commence dès qu'une modification est poussée sur la branche master du dépôt. Ce déclencheur est configuré dans un fichier YAML qui définit le flux de travail dans GitHub Actions. Dès qu'un commit est effectué, ce flux de travail s'active automatiquement, garantissant que les changements apportés sont déployés sur le serveur de production sans retard ni intervention humaine.
Le premier job dans le flux de travail consiste à récupérer le code source de l’application depuis le dépôt GitHub. Ce processus est réalisé grâce à l'action actions/checkout@v2, qui permet de synchroniser le référentiel local avec la branche spécifiée. Ce mécanisme est essentiel pour garantir que la version la plus récente du code est utilisée pour la mise à jour de l’application.
Ensuite, l’action suivante de ce flux de travail consiste à synchroniser l’environnement de développement avec l’environnement de production. Cela se fait via l’utilisation de l’action appleboy/ssh-action@master, qui permet à GitHub Actions d’établir une connexion SSH sécurisée avec le serveur. Grâce à des identifiants secrets stockés dans les paramètres de GitHub (tels que le nom d'hôte du serveur, le nom d'utilisateur, le mot de passe, et le port d'accès), GitHub obtient les permissions nécessaires pour se connecter au serveur et exécuter le code à distance.
Voici les différentes étapes exécutées après la connexion au serveur :
Grâce à cette configuration CI/CD, le déploiement devient entièrement automatisé, garantissant que les mises à jour de l’application sont effectuées de manière rapide, sécurisée et sans interruption. En utilisant des identifiants secrets pour accéder au serveur, GitHub Actions a le droit d'exécuter des commandes sur le serveur à distance, assurant ainsi que le déploiement se déroule sans intervention manuelle, tout en maintenant un haut niveau de sécurité. Ce processus non seulement simplifie la gestion du code, mais assure également une expérience utilisateur continue et sans faille.
Copyright © 2024
| Powered by: Earnanswers
