gwift-book/source/part-1-workspace/12-factors.adoc

<<<<<<< Updated upstream == 12 facteurs

== Douze facteurs >>>>>>> Stashed changes

Pour la méthode de travail et de développement, on va se baser sur les The Twelve-factor App - ou plus simplement les 12 facteurs.

L’idée derrière cette méthode, et indépendamment des langages de développement utilisés, consiste à suivre un ensemble de douze concepts , afin de:

<<<<<<< Updated upstream . Faciliter la mise en place de phases d’automatisation; plus concrètement, de faciliter les mises à jour applicatives, simplifier la gestion de l’hôte, diminuer la divergence entre les différents environnements d’exécution et offrir la possibilité d’intégrer le projet dans un processus d’intégration continue/déploiement continu . Faciliter la mise à pied de nouveaux développeurs ou de personnes souhaitant rejoindre le projet . Minimiser les divergences entre les différents environnemens composant un projet . Augmenter l’agilité générale du projet, en permettant une meilleure évolutivité architecturale et une meilleure mise à l’échelle - Vous avez 5000 utilisateurs en plus? Ajoutez un serveur et on n’en parle plus ;-).

1. Faciliter la mise en place de phases d’automatisation; plus simplement, faciliter les mises à jour applicatives, simplifier la gestion de l’hôte, diminuer la divergence entre les différents environnements d’exécution, faciliter la maintenance et offrir la possibilité d’intégrer le projet dans un processus d’intégration continue/déploiement continu

2. Faciliter la mise à pied de nouveaux développeurs ou de personnes rejoignant le projet. A l’inverse, faciliter également le départ d’autres personnes et la communication générale.

3. Définir des bonnes pratiques à chaque étape de la chaîne.

4. Réduire les frictions entre les équipes de développement et les équipes d’opération.

5. Augmenter l’agilité générale du projet, en permettant une meilleure évolutivité architecturale et une meilleure mise à l’échelle - Vous avez 5000 utilisateurs en plus? Ajoutez un serveur et on n’en parle plus ;-). >>>>>>> Stashed changes

En pratique, les idées qui se trouvent derrière les points ci-dessus permettront de monter facilement un nouvel environnement - qu’il soit sur la machine du petit nouveau dans l’équipe, sur un serveur Azure/Heroku/Digital Ocean ou votre nouveau Raspberry Pi Zéro caché à la cave.

Pour reprendre de manière très brute les différentes idées derrière cette méthode, on a:

<<<<<<< Updated upstream . Une base de code unique, suivie par un système de contrôle de versions. Chaque déploiement de l’application se basera sur cette source, afin de minimiser les différences que l’on pourrait trouver entre deux environnements d’un même projet. On utilisera un dépôt Git - Github, Gitlab, Gitea, …​ Au choix.

1. Déclarez explicitement les dépendances nécessaires au projet, et les isoler du reste du système lors de leur installation. L’idée est que chaque installation ou configuration se fasse toujours de la même manière, et puisse être répétée quel que soit l’environnement cible. Cela permet également d’éviter que l’application n’utilise une dépendance qui soit déjà installée sur un des sytèmes de développement, et qu’elle soit difficile à répercuter sur un autre environnement. Dans notre cas, cela pourra être fait au travers de pip - Package Installer for Python. Dans tous les cas, chaque application doit disposer d’un environnement sain, qui lui est assigné, et vu le peu de ressources que cela coûte, il ne faut pas s’en priver.

2. Sauver la configuration directement au niveau de l’environnement. On veut par exemple éviter d’avoir à recompiler/redéployer l’application parce que l’adresse du serveur de messagerie a été modifiée, ou parce qu’un protocole a changé en cours de route. Concrètement, toute information susceptible de modifier le comportement intrinsèque de l’application doit se trouver dans un fichier ou dans une variable d’environnement. En allant un pas plus loin, cela permettra de paramétrer facilement un container, simplement en modifiant une variable de configuration, qui spécifiera la base de données sur laquelle l’application devra se connecter. Toute clé de configuration (nom du serveur de base de données, adresse d’un service Web externe, clé d’API pour l’interrogation d’une ressource, …​) sera définie directement au niveau de l’hôte - à aucun moment, on ne doit trouver un mot de passe en clair dans le dépôt source ou une valeur susceptible d’évoluer, écrite en dur dans le code.

3. Traiter les ressources externes comme des ressources attachées. On parle de bases de données, de services de mise en cache, d’API externes, …​ L’application doit également être capable d’effectuer des changements au niveau de ces ressources sans que le code intrinsèque ne soit modifié. On parle alors de ressources attachées, dont la présence est nécessaire au bon fonctionnement de l’application, mais pour lesquelles le type n’est pas obligatoirement défini. On veut par exemple "une base de données" et "une mémoire cache", et pas "une base MariaDB et une instance Memcached". De cette manière, les ressources peuvent être attachées et détachées d’un déploiement à la volée. Si une base de données ne fonctionne pas correctement (problème matériel?), l’administrateur pourrait simplement restaurer un nouveau serveur à partir d’une précédente sauvegarde, et l’attacher à l’application sans que le code source ne soit modifié. une solution consiste à passer toutes ces informations (nom du serveur et type de base de données, clé d’authentification, …​) directement via des variables d’environnement.

4. Séparer proprement les phases de construction, de mise à disposition et d’exécution. La construction (build) convertit un code source en un ensemble de fichiers exécutables, associé à une version et à une transaction dans le système de gestion de sources. La mise à disposition (release) associe cet ensemble à une configuration prête à être exécutée, tandis que la phase d'exécution (run) démarre les processus nécessaires au bon fonctionnement de l’application. On doit pouvoir se baser sur les releases de Gitea, sur un serveur d’artefacts ou sur Capistrano.

5. Les processus d’exécution ne doivent rien connaître ou conserver de l’état de l’application. On suppose donc que toute information stockée en mémoire ou sur disque n’altérera pas le comportement futur de l’application, par exemple après un redémarrage non souhaité. Si une réinitialisation devait être nécessaire, l’application ne devra pas compter sur la présence d’une information au niveau du système.

6. Autoriser la liaison d’un port de l’application à un port du système hôte. Les applications 12-factors sont auto-contenues et peuvent fonctionner en autonomie totale. L’idée ici est qu’elles puissent être joignables grâce à un mécanisme de pont, où l’hôte effectue la redirection vers l’un des ports ouverts par l’application, typiquement, en HTTP ou via un autre protocole.

7. Faites confiance aux processus systèmes pour l’exécution de l’application. Comme décrit plus haut, l’application doit utiliser des processus stateless (sans état). On peut donc facilement créer et utiliser des processus supplémentaires pour tenir plus facilement une lourde charge, ou dédier des processus particuliers pour certaines tâches: requêtes HTTP via des processus Web; long-running jobs pour des processys asynchrones, …​

8. Améliorer la robustesse de l’application grâce à des arrêts élégants et à des démarrages rapides. Par "arrêt élégant", on veut surtout éviter le kill -9 <pid> ou tout autre rechargement brutal du superviseur; de cette manière, on évite qu’une requête d’un utilisateur n’aboutisse sur un code d’erreur. Au contraire, les requêtes en cours doivent être terminées au mieux, tandis que le démarrage rapide de nouveaux processus limite les perturbations et améliore la balance du travail d’un processus en cours d’extinction vers des processus tout frais. L’intégration de ces mécanismes dès les premières étapes de développement limite les perturbations et facilite la prise en compte d’arrêts inopinés (problème matériel, redémarrage du système hôte, etc.).

9. Conserver les différents environnements aussi similaires que possible, et limiter les divergences entre un environnement de développement et de production. L’exemple donné est un développeur qui utilise macOS, NGinx et SQLite, tandis que l’environnement de production tourne sur une CentOS avec Apache2 et PostgreSQL. L’idée derrière ce concept limite les divergences entre environnements, facilite les déploiements et limite la casse et la découverte de modules non compatibles dès les premières phases de développement.

10. Gérer les journeaux d’évènements comme des flux. Une application ne doit jamais se soucier de l’endroit où ces évènements seront écrits, mais simplement de les envoyer sur la sortie stdout. De cette manière, qu’on soit en développement sur le poste d’un développeur avec une sortie console ou sur une machine de production avec un envoi vers une instance Greylog, le routage des journaux sera réalisé en fonction de sa nécessité et de sa criticité.

11. Isoler les tâches administratives du reste de l’application. Evitez qu’une migration puisse être démarrée depuis une URL de l’application, ou qu’un envoi massif de notifications ne soit accessible pour n’importe quel utilisateur: les tâches administratives ne doivent être accessibles qu’à un administrateur. Les applications 12facteurs favorisent les langages qui mettent un environnement REPL (pour Read, Eval, Print et Loop) à disposition (au hasad: Python).

Note	pensez à retravailler la partie ci-dessous; la version anglophone semble plus compréhensible…​ :-/

1. Une base de code suivie, avec un système de contrôle de versions, d’où démarreront chaque déploiement.

2. Déclarez explicitement et isolez les dépendances

3. Stockez la configuration dans des variables d’environnement

4. Traitez les services externes comme des ressources attachées (?)

5. Séparez strictement les étapes d’assemblage et d’exécution

6. Exécutez l’application comme un ou plusieurs processus sans état

7. Exportez les services via des associations de ports (?)

8. Grossissez à l’aide du modèle de processus (?)

9. Maximisez la robustesse et la disponibilité avec des démarrages rapides et des arrêts gracieux (la commande kill -9 est donc à proscrire)

10. Gardez le développement, la validation et la production aussi proches l’un de l’autre que possible

11. Traitez les logs comme des flux d’évènements (?)

12. Lancez les processus d’administration et de maintenance comme des one-off-processes (?)

Table 1. Concrètement

Concept	Concept	Outil	Description
1	Base de code suivie avec un système de contrôle de version	Git, Mercurial, SVN, …​	Chaque déploiement démarre à partir d’une base de code unique. Il n’y pas de dépôt "Prod", "Staging" ou "Dev". Il n’y en a qu’un et un seul.
2	Déclaration explicite et isolation des dépendances	Pyenv, environnements virtuels, RVM, …​	Afin de ne pas perturber les dépendances systèmes, chaque application doit disposer d’un environnement sain par défaut.
3	Configuration dans l’environnement	Fichiers .ENV	Toute clé de configuration (nom du serveur de base de données, adresse d’un service Web externe, clé d’API pour l’interrogation d’une ressource, …​) sera définie directement au niveau de l’hôte - à aucun moment, on ne doit trouver un mot de passe en clair dans le dépôt source ou une valeur susceptible d’évoluer, écrite en dur dans le code.
4	Services externes = ressources locales	Fichiers .ENV	Chaque ressource doit pouvoir être interchangeable avec une autre, sans modification du code source. La solution consiste à passer toutes ces informations (nom du serveur et type de base de données, clé d’authentification, …​) directement via des variables d’environnement.
5	Bien séparer les étapes de construction des étapes de mise à disposition	Capistrano, Gitea, un serveur d’artefacts, …​	L’idée est de pouvoir récupérer une version spécifique du code, sans que celle-ci ne puisse avoir été modifiée. Git permet bien de gérer des versions (au travers des tags), mais ces éléments peuvent sans doute être modifiés directement au travers de l’historique.

>>>>>>> Stashed changes