Un guide du développeur open source sur la méthodologie des applications à 12 facteurs
Comment 12 principes de base peuvent aider les équipes à créer des applications hautement évolutives rapidement et efficacement.
La méthodologie 12-Factor App fournit des lignes directrices pour créer des applications dans un court laps de temps et pour les rendre évolutives. Il a été créé par les développeurs de Heroku pour être utilisé avec des applications Software-as-a-Service (SaaS), des applications Web et potentiellement une plate-forme de communication en tant que service (CPaaS) applications. Pour organiser efficacement des projets et gérer des applications évolutives, la méthodologie 12-Factor App présente de puissants avantages pour le développement open source.
Les principes de la méthodologie 12-Factor App
Les principes de la méthodologie 12-Factor App sont des règles strictes qui servent de éléments de base pour le développement et le déploiement d'applications SaaS, et ils ne sont limités à aucun langage de programmation ou base de données.
1 : Une base de code suivie dans le contrôle des révisions, de nombreux déploiements
Seth Kenlon CC-0
Chaque application doit avoir une base de code avec plusieurs environnements/déploiements différents.
Les développeurs ne doivent pas développer une autre base de code uniquement pour des raisons de configuration dans différents environnements. Différents environnements représentent différents états, mais ces différents environnements doivent partager la même base de code.
Un environnement peut être considéré comme une branche dans le contexte des systèmes de contrôle Subversion comme GitLab, où sont stockés de nombreux projets open source. Par exemple, vous pouvez créer un référentiel unique pour une application VoIP cloud nommé VoIP-app dans n'importe quel système central de contrôle de version, puis créer deux branches, développement et staging, avec "master" comme branche de publication.
2 : Déclarer et isoler explicitement les dépendances
Toutes les dépendances doivent être déclarées. Votre application peut dépendre d'outils ou de bibliothèques système externes, mais il ne doit y avoir aucune dépendance implicite à l'égard d'outils ou de bibliothèques système. Votre application doit toujours déclarer explicitement toutes les dépendances et leurs versions correctes.
L'inclusion de dépendances dans la base de code peut créer des problèmes, en particulier dans les projets open source où une modification dans une bibliothèque externe peut introduire des erreurs dans la base de code. Par exemple, une base de code peut utiliser une bibliothèque externe sans déclarer explicitement cette dépendance ni quelle version. Si la bibliothèque externe est mise à jour vers une version plus récente et non testée, cela pourrait créer des problèmes de compatibilité avec votre code. Votre base de code est protégée de ce problème grâce à une déclaration explicite de la dépendance et de sa version correcte.
En fonction de la pile technologique, il est préférable d'utiliser un gestionnaire de packages pour télécharger les dépendances sur votre système respectif en lisant un manifeste de déclaration de dépendance représentant les noms et versions des dépendances.
3 : Stocker la configuration dans l'environnement
Lorsque vous devez prendre en charge plusieurs environnements ou clients, les configurations deviennent un élément essentiel d'une application. Une configuration qui varie selon les déploiements doit être stockée dans les variables d'environnement. Cela facilite le changement entre les déploiements sans avoir à modifier le code.
Pour les applications fermées, ce principe est avantageux, car vous ne voudriez pas que des informations sensibles telles que les informations de connexion à une base de données ou d'autres données secrètes soient divulguées publiquement. Cependant, dans le développement open source, ces détails sont ouverts. Dans ce cas, l’avantage est que vous n’avez pas besoin de modifier le code à plusieurs reprises. Vous définissez simplement les variables de telle manière qu'il vous suffit de modifier l'environnement pour que votre base de code fonctionne parfaitement.
4 : Traitez les services de support comme des ressources attachées
Tous les services de support (tels que les bases de données, le stockage externe ou les files d'attente de messages) sont traités comme des ressources attachées et sont attachés et détachés par l'environnement d'exécution. Avec ce principe, si la localisation ou les détails de connexion de ces services changent, vous n'avez toujours pas besoin de changer le code. Les détails sont disponibles dans la configuration à la place.
Les services de support peuvent être rapidement attachés ou détachés des déploiements. Par exemple, si la base de données de votre ERP basé sur le cloud ne fonctionne pas correctement, le développeur devrait pouvoir créer un nouveau serveur de base de données restauré à partir d'une sauvegarde récente, sans aucune modification de la base de code.
5 : étapes de construction et d'exécution strictement séparées
Une application à 12 facteurs nécessite une séparation stricte entre les étapes de construction, de publication et d'exécution.
La première étape est la phase deconstruction . Au cours de cette phase, le code source est assemblé ou compilé dans un exécutable tout en chargeant les dépendances et en créant des actifs. Chaque fois qu'un nouveau code doit être déployé, la phase de construction démarre.
-
La deuxième étape est la phase release . Dans cette phase, le code produit lors de la phase de construction est combiné avec la configuration actuelle du déploiement. La version résultante contient à la fois la version et la configuration et est prête pour une exécution immédiate dans l'environnement d'exécution.
La troisième étape est la phase d'exécution et constitue l'étape finale : l'application est exécutée dans l'environnement d'exécution. Elle ne doit être interrompue par aucune autre étape.
En séparant strictement ces étapes, nous évitons les ruptures de code et rendons la maintenance du système beaucoup plus gérable.
6 : Exécuter l'application en tant que ou plusieurs processus sans état
Une application est exécutée dans un environnement d'exécution sous la forme d'un ensemble d'un ou plusieurs processus. Ces processus sont sans état et les données persistantes sont stockées sur un service de support, tel qu'une base de données.
Ceci est utile pour l'open source, car un développeur utilisant une version de l'application peut créer des déploiements multi-nœuds sur sa plate-forme cloud pour plus d'évolutivité. Les données n'y sont pas conservées, car elles seraient perdues si l'un de ces nœuds tombait en panne.
7 : Exporter des services via la liaison de port
Votre application doit agir comme un service autonome, indépendant des applications supplémentaires. Il doit être accessible à d'autres services via une URL, agissant comme un service. De cette façon, votre application peut servir de ressource pour d’autres applications si nécessaire. En utilisant ce concept, vous pouvez créer des API REST.
8 : Scale-out via le modèle de processus
Également connu sous le nom de principe de concurrence, ce principe indique que chaque processus de votre application doit pouvoir évoluer, redémarrer ou se cloner.
Au lieu d'agrandir un processus, un développeur peut créer plusieurs processus et répartir la charge de ses applications entre ces processus. Cette approche vous permet de créer votre application pour gérer diverses charges de travail en attribuant chaque charge de travail à un type de processus.
9 : Maximisez la robustesse avec un démarrage rapide et un arrêt progressif
Votre application doit être construite sur des processus simples, afin que les développeurs puissent faire évoluer les processus tout en leur permettant de les redémarrer en cas de problème. Cela rend les processus de l'application jetables.
Construire une application sur ce principe signifie un déploiement rapide du code, une mise à l'échelle élastique rapide, plus d'agilité pour le processus de publication et des déploiements de production robustes. Tous ces éléments sont très utiles dans un environnement de développement open source.
10 : Gardez le développement, la mise en scène et la production aussi similaires que possible
Les équipes travaillant sur un projet doivent utiliser les mêmes systèmes d'exploitation, services de support et dépendances. Cela réduit la probabilité que des bogues apparaissent et moins de temps est nécessaire pour le développement.
Mettre ce principe en pratique pourrait être un défi pour les projets open source en raison de la nature dispersée de ses développeurs, qui peuvent ne pas être en mesure de pour communiquer sur les systèmes, les services et les dépendances qu'ils utilisent. Une possibilité de réduire ces différences consiste à élaborer des lignes directrices de développement suggérant le système d'exploitation, les services et les dépendances à utiliser.
11 : Traitez les journaux comme des flux d'événements
Les journaux sont essentiels pour résoudre les problèmes de production ou comprendre le comportement des utilisateurs. Cependant, une application 12-Factor ne devrait pas se soucier de la gestion des journaux.
Au lieu de cela, il doit acheminer les entrées du journal sous forme de flux d’événements, écrits en tant que sorties standard, vers un service distinct à des fins d’analyse et d’archivage. Les technologies d'automatisation des processus robotiques (RPA) pourraient être utiles en tant que service tiers pour traiter et analyser les journaux. L'environnement d'exécution décidera comment traiter ce flux. Cela offre une plus grande flexibilité et puissance pour introspecter le comportement de l’application.
12 : Exécuter des tâches d'administration/de gestion en tant que processus ponctuels
Ce principe n’est pas vraiment lié au développement mais plutôt à la gestion des applications. Les processus d'administration doivent être exécutés dans un environnement identique aux processus réguliers de longue durée de l'application. Dans un déploiement local, les développeurs peuvent utiliser une commande shell directe dans le répertoire de paiement de l'application pour effectuer des processus d'administration ponctuels.
Conclusion
En développant votre application à l’aide de la méthodologie 12-Factor App, vous pouvez augmenter l’efficacité et accélérer le déploiement. Il peut être judicieux de s'écarter de certaines directives en matière de développement open source, mais il est préférable d'essayer de suivre ces directives aussi strictement que possible.
Des applications open source à 12 facteurs sont possibles. Un bon exemple est Jitsi, une plate-forme de vidéoconférence open source, qui a été multipliée par 100 pendant la pandémie avec beaucoup de succès, et a été construite avec la méthodologie 12-Factor App.