URL: https://linuxfr.org/users/small_duck/journaux/douze-facteurs-dans-ta-tronche Title: Douze facteurs dans ta tronche Authors: small_duck Date: 2022年11月05日T20:43:34+01:00 License: CC By-SA Tags: architecture, devops, kubernetes et microservice Score: 24 Aujourd'hui, encore un journal qui dénonce grave. Je voudrais m'insurger contre un nouveau genre de [culte du cargo](https://fr.wikipedia.org/wiki/Culte_du_cargo), le [Twelve Factor App](https://12factor.net/). Ce sont des principes d'architecture logicielle qui seraient adaptés à l'écriture de micro-services et qui promettent performance, qualité, et retour de l'être aimé. Figurez-vous que j'ai au turbin quelques collègues qui ne jurent que par les 12 facteurs, et qui, en exégètes, font passer ces principes au dessus de tout, à toutes les sauces, et surtout sans réfléchir. Il ont l'impression qu'il leur suffit de déclamer que ce n'est pas 12 factors, et ils s'attendent à ce que je m'agenouille et demande pardon pour mes péchés et que j'aille immédiatement modifier le code scélérat. Alors, je dis pas, j'aime bien les aphorismes à l'emporte pièce, et je suis le premier à lancer un [KISS](https://fr.wikipedia.org/wiki/Principe_KISS) ou un [YAGNI](https://fr.wikipedia.org/wiki/YAGNI) voire un petit [DRY](https://fr.wikipedia.org/wiki/Ne_vous_r%C3%A9p%C3%A9tez_pas) des familles. Mais, moins que des principes, ce sont des idées, des philosophies, qui nous guident sans nous contraindre. Ces idées sont justifiées et confirmées par l'expérience, mais l'expérience nous apprend aussi quand les laisser de côté. Avec les 12 facteurs, ce qui m'interpelle tout d'abord, c'est généralement l'absence de justifications: ces principes sont énoncés, un poil développés, et c'est tout, demerden sie sich, comme on dit outre-Rhin. Alors, certains, c'est difficile de pas être d'accord, le [principe 2](https://12factor.net/dependencies) sur les dépendances qui doivent être explicites, par exemple, ça se tient. Mais le 1, qui dit qu'il faut une base de code par application ? Non mais il fume quoi? Et le 11, qui dit que les logs doivent être des événements ? Bah laissez moi vous raconter, alors. Il y a de cela 6 mois, mon collègue revoit mon code de logs, et ça lui plait pas : j'avais mis en place la possibilité de logger vers la sortie standard, vers un fichier, ou vers les deux. "Nan mais tu comprends, c'est pas 12 factors, ça va pas, faut enlever les logs vers les fichiers". Nonobstant le principe pourtant bien établi que qui peut le plus peut le moins, il me court sur le haricot et refuse de fusionner jusqu'à ce qu'on coupe la poire en deux : on garde le code de log vers les fichiers, mais on ne l'expose pas via l'application. Le temps passe. Mon collègue intègre l'application comme un service systemd. Mais tous les logs dans journalctl, c'est pas très pratique, alors plutôt que de démarrer le service directement, systemd démarre un script bash qui démarre l’application en redirigeant la sortie standard vers un fichier. Plusieurs semaines après, alors que je me plains que les fichiers générés par l'application ne sont pas finalisés correctement, il se rend compte que systemd envie un sigterm vers le script bash mais pas ses enfants, et le process ne reçoit pas le sigterm au bon moment. Parmi les différentes manières de corriger le problème, il se décide en maugréant à ressusciter le log vers les fichiers, permettant à SystemD de démarrer directement l’application. Et bien sûr, dans le message de commit, il s'est excusé de violer les 12 facteurs (mais mec, je m'en tamponne, de tes 12 facteurs !), et a expliqué que ce n'était que partie remise (puisque tout ça va se déplacer vers Kubernetes). Alors, on va s'intéresser à un autre principe bien connu, hein ? "Une taille unique ne convient pas à tous"