binaires, je fais un changement de lib, revue de code, fusion, ça part dans le package manager, puis je mets à jour les dépendances de mes binaires en un coup (puisque monorepo)
Il n'est pas inconcevable de lister dans le package.json (ou équivalent) file:../some_other_dep
Le problème de faire comme ça et que tu créé un couplage fort, un bug dans la dépendance impacte directement tout ceux qui en dépendent de cette manière. Et le rollback devient plus compliqué.
Encore du mal à vraiment voir ce que ça m'apporte de séparer plus.
De la robustesse et de la reproductibilité. Tu n'es pas obligé de mettre à jour tes 25 services d'un coup. Chacun peut dépendre d'une version différente.
Disons que ton service A est impacté par un bug dans ta dépendance. Mais le service B n'utilise pas la fonction buguée de cette même dépendance. Tu peux donc en parfaite isolation corriger le bug dans la dépendance, mettre a jour le service A, et redéployer uniquement le service A.
Ou alors, Jean Michel qui est le mainteneur de la dépendance est en vacance. On peut rollback aisément, il suffit de corriger le package.json/pom.xml/pyproject.toml, et on n'impacte pas les autres services.
Avec ElasticSearch, c'est possible?
Avec Kibana oui. La stack ELK c'est :
ElasticSearch pour indexer
Logstash pour récupérer les logs et les transmettre dans un format unifié à ElasticSearch
Kibana pour aller grep dans le ElasticSearch
Ici le point important c'est que Logstash va transformer tes logs:
level=debug time="some iso datetime" Something happened!!!
Sera transformé par logstash (suivant ta configuration de ce dernier) en:
{"level":"debug","time":"some iso datetime","message":"Something happened!!!"}
Si tu as un second service qui log cependant :
[debug] [some iso datetime] Something happened!!!
Le document qui sera indexé dans ElasticSearch sera le même. Ainsi, l'ops n'a plus à se préoccuper du format des logs lorsqu'il va composer son grep/sed/sort, il va simplement filtrer en fonction des champs du document indexé dans ElasticSearch.
Pour ton exemple:
[info] [some iso datetime] User alice is connected
Pourrait être transformé en :
{"source":"application-foobar","level":"info","time":"some iso datetime","user":"alice","event":"connected"}
En gros, c'est comme si tu configurais le grep/sed/awk/whatever au niveau du logstash. Ainsi les données que ElasticSearch ingère sont déjà structurée, ce qui facilite le querying.
C'est overkill pour des petits setups, mais quand tu commences a compter tes services par centaines, la centralisation c'est plutôt pas mal. L'ops n'a même pas à forcément connaitre l'application, il peut directement mettre en place du monitoring de log et automatiser la notification des équipes le tout de manière dynamique.
Cette stack répond a des besoins très précis, de niche je dirais même, car tout le monde n'est pas Google.
Il faut aussi se rendre compte que l'architecture microservice répond à un besoin organisationnel, et non technique. Quand tu as 20 équipes de 4 personnes qui doivent travailler sur des aspects différents d'un même projet, le monolithe (même modulaire) ralenti tout le monde. Dans une précédente mission, l'entreprise était en cours de réécriture d'un monolithe en Java (bien modularisé) vers les microservices. Les 10 équipes sont passés de "attendre 30min après chaque commit que la CI/CD du monolithe fasse son job" à "attendre 5min après chaque commit que la CI/CD de son service fasse son job".
Et je parle pas du workflow de PR sur le monolithe avec des phrases du genre "on merge quelles PR aujourd'hui ? que je sache si je vais me prendre un café ou si je travaille".
Je ne comprends absolument pas en quoi séparer les dépôts aide à quoi que ce soit.
Tu ne sépare pas les dépôts, mais les codebases.
Que tu sois en monorepo ou pas, chaque libraire a son propre dossier, avec son propre package.json/pom.xml/pyproject.toml/…
Que tu sois en monorepo ou pas, chaque application liste la dépendance dans son package.json/pom.xml/pyproject.toml/…
L'idée est de passer par le gestionnaire de paquet du langage pour gérer la dépendance.
Je cite, de 12factor:
If there are multiple codebases, it’s not an app – it’s a distributed system. Each component in a distributed system is an app, and each can individually comply with twelve-factor.
Donc un monorepo pour gérer un système distribuer, cela s'entend parfaitement. Et c'est ce que beaucoup font.
c'est logique de sortir les logs sur la sortie standard, et de laisser Kubernetes balancer tout ça vers un Elastic Search ou équivalent.
SystemD est capable de rediriger stdout/stderr dans un fichier, ainsi ton application print sur stdout/stderr, et tu laisse l'environnement d'exécution gérer le reste (rotation de logs, compression de log, redirection vers un service centralisé ou non, stockage dans un NFS, etc…)
Je me demande d'ailleurs si il serait possible d'avoir un volume NFS rien que pour les logs, et d'avoir l'application qui monte ce volume et qui logge dessus
C'est pas à ton application de monter ce volume. C'est à SystemD, ou a Kubernetes, ou tout autre environnement d'exécution.
1 - One Codebase tracked in revision control, many deploys
Je ne l'interprète pas comme "une application = un dépôt", mais plutôt comme "on déploie a partir de ce qui est dans le dépôt".
Si tu as un mono-dépôt, contenant l'ensemble de tes services/applications, tu déploies à partir de ce dépôt. Si tu as un dépôt par application, tu déploies à partir de chacun d'eux. Si tu as une application découpée en plusieurs dépôt (plusieurs modules par exemple), tu as un dépôt parmi eux qui décrit ton déploiement, et tu déploies à partir de ce dernier.
L'idée ici suggère simplement que le dépôt est la source de vérité.
2 - Explicitly declare and isolate dependencies
On ne veut pas qu'un service/application impacte une autre. Pour Python, cela veut dire des virtualenv pour chaque application, pour NodeJS c'est le node_modules, pour Go et Rust c'est un binaire statique. On oublie pas non plus de lock les dépendances pour un max de reproductibilité.
3 - Store config in the environment
Tu ne sais pas comment ton application va être déployée, via un unit systemd ? via un conteneur docker ? via Kubernetes ? via une plateforme Function-as-a-Service (AWS Lambda ou autre) ? via Heroku ?
Les variables d'environnement sont le dénominateur commun de toutes ces plateformes, il est donc logique de les utiliser pour donner le plus de flexibilité à l'Ops qui se chargera de mettre ton code en prod.
Note que j'ai déjà vu des applications simplement configurer via les variables d'environment les accès à un Vault (hashicorp) et allait ensuite chercher sa configuration dedans. C'est parfaitement viable, l'Ops sait que la conf est dans le Vault, et sais comment configurer (via l'env) les accès Vault de l'application.
4 - Treat backing services as attached resources
Il s'agit simplement de considérer chaque service (local ou remote) qu'utilise l'application (base de données, serveur mail, API, etc…) comme remplaçable. Il ne faut pas hard-coder ce genre de service dans le code mais le rendre configurable pour que chaque déploiement puisse adapter l'infrastructure selon ses besoins.
Bref, on mets l'accent sur le déploiement
5 - Strictly separate build and run stages
C'est simplement une bonne pratique de CI/CD. Tu ne veux pas installer les outils de dev pour build ton application sur le serveur de prod. Tu veux aussi pouvoir rollback aisément.
Cela veut donc dire que tu dois avoir un endroit ou tu stockes tes releases après chaque build (Nexus? Docker Registry? Dépôt PyPI/Maven/whatever privé? un simple FTP/NFS/whatever?). L'Ops ensuite déploiera une release, et il a l'historique pour rollback.
Sans cette séparation, il faudrait faire quelques git revert sur la branche main pour pouvoir rollback, c'est source d'erreur, et en général les gens ne connaissent que git commit/git push, donc ça va pas passer non plus.
6 - Execute the app as one or more stateless processes
L'idée ici est encore une fois de simplifier la vie lors des déploiements. Si tu as besoin de persister des données, tu délègues ça a un "backing service". On ne sait pas ou est déployée ton application, donc ça se trouve le système de fichier ne va pas persister entre 2 exécutions du service/application.
De plus, avoir un backing service (même si c'est toi l'auteur) pour la persistance, permet de le réutiliser/mutualiser/etc… pour l'ensemble des services.
Ce backing service, cela peut être : un GlusterFS, un FTP, une base de données, un PersistantVolume dans Kubernetes, etc…
7 - Export services via port binding
En gros, on fait du "proxy pass" dans notre gateway. Cela simplifie drastiquement le déploiement, peu importe ou et comment on déploie.
Que ce soit aller modifier un NginX/Apache pour ajouter le vhost, ajouter un Ingress dans notre Kubernetes, ou aller ajouter un CNAME sur notre DNS, ou une règle de redirection dans iptables/pf, cela revient au même.
8 - Scale out via the process model
Un service devrait être découpé en plusieurs processus qui font une seule chose (web, worker, …). Ainsi lors du déploiement, on peut configurer combien de replicas pour chaque workloads (je veux 4 process web pour gérer les requêtes HTTP, 16 process worker pour gérer les tâches de fond, etc…).
Encore une fois, l'idée est de donner plus de flexibilité au déploiement.
9 - Maximize robustness with fast startup and graceful shutdown
Gère SIGTERM correctement. Et spécifie quand ton service/application est ready.
Pour Kubernetes, on va configurer des healthcheck. Cela peut être une commande qui fait une requête HTTP au service et s'assure qu'elle reçoit un 200 OK. Ou alors vérifier si un fichier /var/run/myservice.ready existe, ou tout ce que tu peux imaginer.
L'idée est de permettre à la plateforme ou on déploie de s'assurer que le service s'est bien lancé. Ensuite, si on a de l'autoscaling, il se peut que notre instance se voit décommissionnée, il faut donc libérer les ressources proprement pour éviter toute corruption (si un upload de fichier est en cours, on attend qu'il soit fini par exemple avant de quitter).
10 - Keep development, staging and production as similar as possible
Bah oui, on veut éviter le "ça marche sur ma machine pourtant". Si le développeur est capable de tester en condition de production, c'est pas mal de bug trouvés à la source.
11 - Treat logs as event streams
En gros, oui l'idée c'est d'envoyer tout sur stdout et stderr.
SystemD permet de rediriger stdout/stderr dans un fichier et de gérer la rotation/compression de logs.
Je peux configurer une stack ELK ou autre pour récupérer les logs depuis /var/log (rempli par SystemD), depuis Docker, depuis Kubernetes, etc…
Mon application elle? Elle print sur stdout et s'en fou de tout ça.
Si chaque application fait comme elle sent, c'est d'autant plus de complexité pour le déploiement, car autant de cas spécifique à gérer. Cela a aussi au passage l'effet de simplifier le code de l'application qui n'a pas besoin de se préoccuper de cela.
12 - Run admin/management tasks as one-off processes
Que cela soit fait par des tâches ansible, par un rundeck, par un jenkins, par un init container dans Kubernetes, etc.. On s'en fout. Ce n'est tout simplement pas à l'application lors de son lancement de faire ce genre de chose.
Idéalement, ton application ne tourne pas en tant que root. Donc il se peut en plus qu'elle n'ait pas les permissions pour faire telle ou telle tâche d'admin.
Ensuite, sur https://12factor.net chaque point est un lien vers un article plus détaillé, expliquant le point de vu.
Je conclurai tout simplement pour dire que cette philosophie, que tu es libre de ne pas suivre et d'adapter a ton besoin, mets l'accent sur le déploiement.
Après des gens qui voient ça comme une religion a ne surtout pas blasphémer, c'est parce que l'humain est un stupide singe overclocké. Ce n'est pas la faute de 12factor.
Docsify a pas mal de fonctionnalité, comme la sidebar, les table of contents, un système de plugin, une navbar, etc…
De plus, cela a l'air de faire le rendu du markdown côté client.
Ici, les documents markdown sont générés à la volée, ce n'est donc pas du fichier statique. Il sont générés côté serveur, donc pas besoin de JS côté client.
easymd ne fait qu'une seule chose : servir des documents markdown, rien d'autre.
Le but n'est pas de faire un générateur de site web, juste partager des documents markdown avec des gens, pour pas avoir a sortir du Google Docs, ou autre bazooka.
Un autre objectif, c'était aussi d'avoir un binaire statique que je pouvais scp sur un serveur et lancer tel quel en tant qu'utilisateur non-root. C, C++, Rust auraient aussi fait l'affaire, mais c'était infiniment plus rapide à faire avec Go.
J'ai fait ce petit outil en 30min le temps de chercher les libs qui vont bien sur google. J'ai pas pris le temps d'aller voir l'état de l'art.
Pour l'install ça se limite à npm install
Il faut donc sur ton serveur :
NodeJS
NPM
de l'espace disque pour les 437 dépendances dans le node_modules (je troll)
Ici, je scp un binaire et le lance sur un serveur ou j'ai pas forcément accès à root (seul ma pipeline de CI/CD a accès root en général).
Je sais bien que quand on montre un projet, il faut s'attendre à ce que les gens le comparent avec d'autres. Mais ici c'est comme comparer cat et vim.
Vois ça comme un python -m http.server qui fait le rendu des markdowns.
Les documents markdowns sont rendu à la volée lors de la requête HTTP, quasiment rien n'est personnalisable, c'est juste un binaire statique que tu dépose et lance.
Oui, j'ai pas mal de site fait avec Hugo, mais c'est toute une pipeline a mettre en place, la je voulais juste scp le binaire sur mon serveur et partager des fichiers markdown, un genre de python -m http.server quoi.
Oui la doc (comme le projet) a été fait à la va-vite, le but était de partager vite fait une longue discussion sur IRC sans devoir sortir Google Docs ou une connerie du genre.
Pour les fichiers statiques j'y ai pensé aussi, rajouter une option -s, --static qui pointe vers un dossier statique, et servi sur /static/* me semble sympathique. Je verrai si je peux faire ça ce soir ou ce weekend.
Created VSCode and made it the best and open-source IDE that everyone would jump to first.
Et moi qui utilise encore Visual Studio Community 2019 pour C#/Unity, Sublime Text sous Linux pour éditer vite fait des fichiers par-ci par-là (le startup time est juste incomparable, mais sous Windows je me contente de notepad qui fait le taf). Sur des serveurs je continue d'utiliser le très vénérable arbre mojo vim (où vi quand je peux pas l'installer).
Oui bon ok, j'utilise VS Code pour tout le reste.
Après, histoire de pinailler. Le seul IDE dans le lot que j'ai cité, c'est Visual Studio 2019. Le reste c'est des éditeurs de texte (oui parce que j'utilise pas le débugger de VSCode, ni sont système de build/tâches). En fait, c'est ptet le terminal avec bash (ou git bash sous Windows) mon IDE, tout simplement.
Tu peux faire du business autour du libre assez facilement sans argent : tu fais de la prestation.
Le "business development" qui comprend l'acquisition de client, l'entretien de la relation client, éventuellement du marketing, etc… Ca coûte de l'argent. Plus t'en as a investir dedans, plus tu sera efficace.
"sans argent" ça insinue que Gérard dans son garage peut le faire et peut en vivre. C'est faux.
Tu parles de grosses boîtes qui font de l'argent avec du libre, mais ce n'est pas ça qu'ils vendent.
Oui c'est pour ça que j'ai dit :
C'est pas pour rien que les plus gros contributeurs à l'écosystème libre c'est les GAFAM, les Red Hat, etc… qui ont d'autres revenus conséquent qui leur permet d'investir dans le libre.
Donc on est bien d'accord.
Si tu veux vraiment tirer ton épingle du jeu avec du libre, il me semble que la seule solution est que le libre soit un moyen et non une finalité.
Sauf que si tu es éditeur de logiciel libre, tu consacre une grosse partie de ton budget (payer les ingénieurs, le marketing, l'avant vente, etc…) sur quelque chose qui ne rapportera pas (car ce n'est pas le logiciel que tu vends). Que cela soit un moyen ou un finalité, c'est un investissement qui est plus facile a faire quand tu as d'autres revenus.
A noter toutefois que pour "Amazon qui forke ElasticSearch" tout est libre la dedans
C'était justement pour appuyer mon point que si on a les moyens financier d'Amazon, on peut se permettre de faire du libre sans se soucier de la compétition.
Bizarrement je ne vois pas votre empathie quand c'est les GAFAM qui font exactement pareil pour exactement la même raison.
2 poids, 2 mesures.
Pour ma part, à partir du moment ou l'auteur est une compagnie privée, faire du non-libre, c'est fair game.
Amazon qui forke ElasticSearch ? Fair game.
Google qui garde jalousement ses algos privés et qui après bien les avoir exploité en sort une version avec moins de fonctionnalités (BigTable, Kubernetes, …) ? Fair game.
Une PME comme Sentry qui fait du proprio et libère après 3 ans ? Fair game.
Le terme exact quand c'était libre dès le début et que cela ne l'est plus c'est "devient", pas "redevient".
La ça sous-entend une girouette "on a fait du proprio, on a essayé le libre, et en fait nan".
De plus, comme d'autres commentaires l'ont déjà dit, la phase propriétaire est temporaire. Et je trouve que cela est une excellente idée pour continuer de contribuer à l'opensource et garder un certain avantage en tant que business, un parfait juste milieu.
Parce que au bout d'un moment, il faut être réaliste.
T'es un business, ton but c'est d'être viable, de générer du revenu, de payer tes employers, de payer ta direction. Bref, le but d'un business c'est de faire de la thune.
Avec le temps, je me suis rendu compte pour faire de l'argent avec du libre, il faut…. de l'argent, beaucoup d'argent.
C'est pas pour rien que les plus gros contributeurs à l'écosystème libre c'est les GAFAM, les Red Hat, etc… qui ont d'autres revenus conséquent qui leur permet d'investir dans le libre.
Mais quand t'es un trou du cul avec ta petite PME, t'as pas assez d'argent pour faire du libre efficacement.
Le business a peut être commencé avec des techos qui aiment réellement le libre, qui se sont rendus compte tristement dans une grande désillusion qu'ils ne sont ni Google, ni Amazon, et qu'ils doivent manger, et ont décidé à contre cœur une des options suivantes :
faire du proprio
faire de l'opencore
faire du dual-licensing
faire du faux libre (comme avec la BSL)
Cela a été le choix d'ElasticSearch, de MongoDB, de Qt, de Sentry, et de bien d'autres.
J'aimerais bien moi faire du libre 100% du temps, et avoir de quoi payer mon loyer et ma bouffe, et mettre même un peu de côté pourquoi pas ?
le libre c'est bien tant que les autres n'utilisent pas les libertés du libre, la compétition à armes égales c'est chiant en fait.
Bref, c'est vrai, mais c'est extrêmement réducteur et manque d'empathie.
En Lua tu as des tables. L'opérateur # retourne le nombre d'éléments dans la table. Une table ne peut pas contenir nil (et donc assigner nil a un élément de la table le supprime de la table). Les clés d'une tables peuvent être des nombres, des strings, des fonctions (oui oui), etc…
Lorsque l'on créé une table sans préciser les clés, c'est comme si on utiliser des nombres en partant de 1:
Lua n'a donc pas vraiment de "liste" / "tableau". Que des dictionnaires, donc utiliser les indices pour parcourir une table n'est vraiment pas la bonne pratique.
[^] # Re: Moui… mais…
Posté par David Delassus (site web personnel) . En réponse au journal Douze facteurs dans ta tronche. Évalué à 4.
Le principe des 12 factor c'est que tu sais pas comment va être déployé ton application.
En suivant ces principes, tu peux déployer via systemd, via openrc, via sysvinit, via docker compose, via kubernetes, via nomad, via …
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Moui… mais…
Posté par David Delassus (site web personnel) . En réponse au journal Douze facteurs dans ta tronche. Évalué à 5.
Il n'est pas inconcevable de lister dans le package.json (ou équivalent)
file:../some_other_depLe problème de faire comme ça et que tu créé un couplage fort, un bug dans la dépendance impacte directement tout ceux qui en dépendent de cette manière. Et le rollback devient plus compliqué.
De la robustesse et de la reproductibilité. Tu n'es pas obligé de mettre à jour tes 25 services d'un coup. Chacun peut dépendre d'une version différente.
Disons que ton service A est impacté par un bug dans ta dépendance. Mais le service B n'utilise pas la fonction buguée de cette même dépendance. Tu peux donc en parfaite isolation corriger le bug dans la dépendance, mettre a jour le service A, et redéployer uniquement le service A.
Ou alors, Jean Michel qui est le mainteneur de la dépendance est en vacance. On peut rollback aisément, il suffit de corriger le package.json/pom.xml/pyproject.toml, et on n'impacte pas les autres services.
Avec Kibana oui. La stack ELK c'est :
Ici le point important c'est que Logstash va transformer tes logs:
Sera transformé par logstash (suivant ta configuration de ce dernier) en:
Si tu as un second service qui log cependant :
Le document qui sera indexé dans ElasticSearch sera le même. Ainsi, l'ops n'a plus à se préoccuper du format des logs lorsqu'il va composer son grep/sed/sort, il va simplement filtrer en fonction des champs du document indexé dans ElasticSearch.
Pour ton exemple:
Pourrait être transformé en :
En gros, c'est comme si tu configurais le grep/sed/awk/whatever au niveau du logstash. Ainsi les données que ElasticSearch ingère sont déjà structurée, ce qui facilite le querying.
C'est overkill pour des petits setups, mais quand tu commences a compter tes services par centaines, la centralisation c'est plutôt pas mal. L'ops n'a même pas à forcément connaitre l'application, il peut directement mettre en place du monitoring de log et automatiser la notification des équipes le tout de manière dynamique.
Cette stack répond a des besoins très précis, de niche je dirais même, car tout le monde n'est pas Google.
Il faut aussi se rendre compte que l'architecture microservice répond à un besoin organisationnel, et non technique. Quand tu as 20 équipes de 4 personnes qui doivent travailler sur des aspects différents d'un même projet, le monolithe (même modulaire) ralenti tout le monde. Dans une précédente mission, l'entreprise était en cours de réécriture d'un monolithe en Java (bien modularisé) vers les microservices. Les 10 équipes sont passés de "attendre 30min après chaque commit que la CI/CD du monolithe fasse son job" à "attendre 5min après chaque commit que la CI/CD de son service fasse son job".
Et je parle pas du workflow de PR sur le monolithe avec des phrases du genre "on merge quelles PR aujourd'hui ? que je sache si je vais me prendre un café ou si je travaille".
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Moui… mais…
Posté par David Delassus (site web personnel) . En réponse au journal Douze facteurs dans ta tronche. Évalué à 10.
Tu ne sépare pas les dépôts, mais les codebases.
Que tu sois en monorepo ou pas, chaque libraire a son propre dossier, avec son propre package.json/pom.xml/pyproject.toml/…
Que tu sois en monorepo ou pas, chaque application liste la dépendance dans son package.json/pom.xml/pyproject.toml/…
L'idée est de passer par le gestionnaire de paquet du langage pour gérer la dépendance.
Je cite, de 12factor:
Donc un monorepo pour gérer un système distribuer, cela s'entend parfaitement. Et c'est ce que beaucoup font.
SystemD est capable de rediriger stdout/stderr dans un fichier, ainsi ton application print sur stdout/stderr, et tu laisse l'environnement d'exécution gérer le reste (rotation de logs, compression de log, redirection vers un service centralisé ou non, stockage dans un NFS, etc…)
C'est pas à ton application de monter ce volume. C'est à SystemD, ou a Kubernetes, ou tout autre environnement d'exécution.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# Explication
Posté par David Delassus (site web personnel) . En réponse au journal Douze facteurs dans ta tronche. Évalué à 10.
Je ne l'interprète pas comme "une application = un dépôt", mais plutôt comme "on déploie a partir de ce qui est dans le dépôt".
Si tu as un mono-dépôt, contenant l'ensemble de tes services/applications, tu déploies à partir de ce dépôt. Si tu as un dépôt par application, tu déploies à partir de chacun d'eux. Si tu as une application découpée en plusieurs dépôt (plusieurs modules par exemple), tu as un dépôt parmi eux qui décrit ton déploiement, et tu déploies à partir de ce dernier.
L'idée ici suggère simplement que le dépôt est la source de vérité.
On ne veut pas qu'un service/application impacte une autre. Pour Python, cela veut dire des virtualenv pour chaque application, pour NodeJS c'est le
node_modules, pour Go et Rust c'est un binaire statique. On oublie pas non plus de lock les dépendances pour un max de reproductibilité.Tu ne sais pas comment ton application va être déployée, via un unit systemd ? via un conteneur docker ? via Kubernetes ? via une plateforme Function-as-a-Service (AWS Lambda ou autre) ? via Heroku ?
Les variables d'environnement sont le dénominateur commun de toutes ces plateformes, il est donc logique de les utiliser pour donner le plus de flexibilité à l'Ops qui se chargera de mettre ton code en prod.
Note que j'ai déjà vu des applications simplement configurer via les variables d'environment les accès à un Vault (hashicorp) et allait ensuite chercher sa configuration dedans. C'est parfaitement viable, l'Ops sait que la conf est dans le Vault, et sais comment configurer (via l'env) les accès Vault de l'application.
Il s'agit simplement de considérer chaque service (local ou remote) qu'utilise l'application (base de données, serveur mail, API, etc…) comme remplaçable. Il ne faut pas hard-coder ce genre de service dans le code mais le rendre configurable pour que chaque déploiement puisse adapter l'infrastructure selon ses besoins.
Bref, on mets l'accent sur le déploiement
C'est simplement une bonne pratique de CI/CD. Tu ne veux pas installer les outils de dev pour build ton application sur le serveur de prod. Tu veux aussi pouvoir rollback aisément.
Cela veut donc dire que tu dois avoir un endroit ou tu stockes tes releases après chaque build (Nexus? Docker Registry? Dépôt PyPI/Maven/whatever privé? un simple FTP/NFS/whatever?). L'Ops ensuite déploiera une release, et il a l'historique pour rollback.
Sans cette séparation, il faudrait faire quelques git revert sur la branche main pour pouvoir rollback, c'est source d'erreur, et en général les gens ne connaissent que git commit/git push, donc ça va pas passer non plus.
L'idée ici est encore une fois de simplifier la vie lors des déploiements. Si tu as besoin de persister des données, tu délègues ça a un "backing service". On ne sait pas ou est déployée ton application, donc ça se trouve le système de fichier ne va pas persister entre 2 exécutions du service/application.
De plus, avoir un backing service (même si c'est toi l'auteur) pour la persistance, permet de le réutiliser/mutualiser/etc… pour l'ensemble des services.
Ce backing service, cela peut être : un GlusterFS, un FTP, une base de données, un PersistantVolume dans Kubernetes, etc…
En gros, on fait du "proxy pass" dans notre gateway. Cela simplifie drastiquement le déploiement, peu importe ou et comment on déploie.
Que ce soit aller modifier un NginX/Apache pour ajouter le vhost, ajouter un Ingress dans notre Kubernetes, ou aller ajouter un CNAME sur notre DNS, ou une règle de redirection dans iptables/pf, cela revient au même.
Un service devrait être découpé en plusieurs processus qui font une seule chose (web, worker, …). Ainsi lors du déploiement, on peut configurer combien de replicas pour chaque workloads (je veux 4 process web pour gérer les requêtes HTTP, 16 process worker pour gérer les tâches de fond, etc…).
Encore une fois, l'idée est de donner plus de flexibilité au déploiement.
Gère SIGTERM correctement. Et spécifie quand ton service/application est ready.
Pour Kubernetes, on va configurer des healthcheck. Cela peut être une commande qui fait une requête HTTP au service et s'assure qu'elle reçoit un 200 OK. Ou alors vérifier si un fichier /var/run/myservice.ready existe, ou tout ce que tu peux imaginer.
L'idée est de permettre à la plateforme ou on déploie de s'assurer que le service s'est bien lancé. Ensuite, si on a de l'autoscaling, il se peut que notre instance se voit décommissionnée, il faut donc libérer les ressources proprement pour éviter toute corruption (si un upload de fichier est en cours, on attend qu'il soit fini par exemple avant de quitter).
Bah oui, on veut éviter le "ça marche sur ma machine pourtant". Si le développeur est capable de tester en condition de production, c'est pas mal de bug trouvés à la source.
En gros, oui l'idée c'est d'envoyer tout sur
stdoutetstderr.SystemD permet de rediriger stdout/stderr dans un fichier et de gérer la rotation/compression de logs.
Je peux configurer une stack ELK ou autre pour récupérer les logs depuis /var/log (rempli par SystemD), depuis Docker, depuis Kubernetes, etc…
Mon application elle? Elle print sur stdout et s'en fou de tout ça.
Si chaque application fait comme elle sent, c'est d'autant plus de complexité pour le déploiement, car autant de cas spécifique à gérer. Cela a aussi au passage l'effet de simplifier le code de l'application qui n'a pas besoin de se préoccuper de cela.
Que cela soit fait par des tâches ansible, par un rundeck, par un jenkins, par un init container dans Kubernetes, etc.. On s'en fout. Ce n'est tout simplement pas à l'application lors de son lancement de faire ce genre de chose.
Idéalement, ton application ne tourne pas en tant que root. Donc il se peut en plus qu'elle n'ait pas les permissions pour faire telle ou telle tâche d'admin.
Ensuite, sur https://12factor.net chaque point est un lien vers un article plus détaillé, expliquant le point de vu.
Je conclurai tout simplement pour dire que cette philosophie, que tu es libre de ne pas suivre et d'adapter a ton besoin, mets l'accent sur le déploiement.
Après des gens qui voient ça comme une religion a ne surtout pas blasphémer, c'est parce que l'humain est un stupide singe overclocké. Ce n'est pas la faute de 12factor.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Feedback
Posté par David Delassus (site web personnel) . En réponse au lien Mini serveur HTTP en Go pour le rendu de documents Markdown. Évalué à 3.
J'arrive pas a reproduire :(
Et non, go build devrait bien te filer la bonne version, un ptit git log pour être sur?
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Feedback
Posté par David Delassus (site web personnel) . En réponse au lien Mini serveur HTTP en Go pour le rendu de documents Markdown. Évalué à 2.
Quelle est la commande que tu utilises pour lancer le serveur ? Et quelle est ta structure de dossier ? Je n'arrive pas à reproduire l'erreur.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Docsify
Posté par David Delassus (site web personnel) . En réponse au lien Mini serveur HTTP en Go pour le rendu de documents Markdown. Évalué à 8. Dernière modification le 02 novembre 2022 à 20:13.
Docsify a pas mal de fonctionnalité, comme la sidebar, les table of contents, un système de plugin, une navbar, etc…
De plus, cela a l'air de faire le rendu du markdown côté client.
Ici, les documents markdown sont générés à la volée, ce n'est donc pas du fichier statique. Il sont générés côté serveur, donc pas besoin de JS côté client.
easymdne fait qu'une seule chose : servir des documents markdown, rien d'autre.Le but n'est pas de faire un générateur de site web, juste partager des documents markdown avec des gens, pour pas avoir a sortir du Google Docs, ou autre bazooka.
Un autre objectif, c'était aussi d'avoir un binaire statique que je pouvais scp sur un serveur et lancer tel quel en tant qu'utilisateur non-root. C, C++, Rust auraient aussi fait l'affaire, mais c'était infiniment plus rapide à faire avec Go.
J'ai fait ce petit outil en 30min le temps de chercher les libs qui vont bien sur google. J'ai pas pris le temps d'aller voir l'état de l'art.
Il faut donc sur ton serveur :
Ici, je scp un binaire et le lance sur un serveur ou j'ai pas forcément accès à root (seul ma pipeline de CI/CD a accès root en général).
Je sais bien que quand on montre un projet, il faut s'attendre à ce que les gens le comparent avec d'autres. Mais ici c'est comme comparer
catetvim.https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Feedback
Posté par David Delassus (site web personnel) . En réponse au lien Mini serveur HTTP en Go pour le rendu de documents Markdown. Évalué à 5.
Tu sera content de voir que cela a été implémenté :)
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Docsify
Posté par David Delassus (site web personnel) . En réponse au lien Mini serveur HTTP en Go pour le rendu de documents Markdown. Évalué à 5.
Vois ça comme un
python -m http.serverqui fait le rendu des markdowns.Les documents markdowns sont rendu à la volée lors de la requête HTTP, quasiment rien n'est personnalisable, c'est juste un binaire statique que tu dépose et lance.
Tout le contraire d'un couteau suisse quoi.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Feedback
Posté par David Delassus (site web personnel) . En réponse au lien Mini serveur HTTP en Go pour le rendu de documents Markdown. Évalué à 3.
C'est une solution aussi. Je vais y réfléchir un peu avant :) Merci!
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Et par rapport à Hugo ?
Posté par David Delassus (site web personnel) . En réponse au lien Mini serveur HTTP en Go pour le rendu de documents Markdown. Évalué à 8.
Oui, j'ai pas mal de site fait avec Hugo, mais c'est toute une pipeline a mettre en place, la je voulais juste
scple binaire sur mon serveur et partager des fichiers markdown, un genre depython -m http.serverquoi.https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Feedback
Posté par David Delassus (site web personnel) . En réponse au lien Mini serveur HTTP en Go pour le rendu de documents Markdown. Évalué à 2.
Merci pour ton retour!
Oui la doc (comme le projet) a été fait à la va-vite, le but était de partager vite fait une longue discussion sur IRC sans devoir sortir Google Docs ou une connerie du genre.
Pour les fichiers statiques j'y ai pensé aussi, rajouter une option
-s, --staticqui pointe vers un dossier statique, et servi sur/static/*me semble sympathique. Je verrai si je peux faire ça ce soir ou ce weekend.https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Conclusion de l'article
Posté par David Delassus (site web personnel) . En réponse au lien Visual Studio Code is designed to fracture. Évalué à 5.
Et moi qui utilise encore Visual Studio Community 2019 pour C#/Unity, Sublime Text sous Linux pour éditer vite fait des fichiers par-ci par-là (le startup time est juste incomparable, mais sous Windows je me contente de notepad qui fait le taf). Sur des serveurs je continue d'utiliser le très vénérable
arbre mojovim (où vi quand je peux pas l'installer).Oui bon ok, j'utilise VS Code pour tout le reste.
Après, histoire de pinailler. Le seul IDE dans le lot que j'ai cité, c'est Visual Studio 2019. Le reste c'est des éditeurs de texte (oui parce que j'utilise pas le débugger de VSCode, ni sont système de build/tâches). En fait, c'est ptet le terminal avec bash (ou git bash sous Windows) mon IDE, tout simplement.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Conclusion de l'article
Posté par David Delassus (site web personnel) . En réponse au lien Visual Studio Code is designed to fracture. Évalué à 9.
Voilà, c'est corrigé :)
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# Appels aux modérateurs
Posté par David Delassus (site web personnel) . En réponse au journal Python 3.11 est disponible. Évalué à 2.
Je me suis foiré dans le copy/paste. Il y a 4 espaces en trop dans la ligne
~~~~~~~~~~~^^^^^ce qui aligne pas correctement l'erreur.Si vous pouvez corriger, ça serait chou <3
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: BSL
Posté par David Delassus (site web personnel) . En réponse au lien Sentry redevient privateur. Évalué à 2.
Le "business development" qui comprend l'acquisition de client, l'entretien de la relation client, éventuellement du marketing, etc… Ca coûte de l'argent. Plus t'en as a investir dedans, plus tu sera efficace.
"sans argent" ça insinue que Gérard dans son garage peut le faire et peut en vivre. C'est faux.
Oui c'est pour ça que j'ai dit :
Donc on est bien d'accord.
Sauf que si tu es éditeur de logiciel libre, tu consacre une grosse partie de ton budget (payer les ingénieurs, le marketing, l'avant vente, etc…) sur quelque chose qui ne rapportera pas (car ce n'est pas le logiciel que tu vends). Que cela soit un moyen ou un finalité, c'est un investissement qui est plus facile a faire quand tu as d'autres revenus.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: BSL
Posté par David Delassus (site web personnel) . En réponse au lien Sentry redevient privateur. Évalué à 4.
C'était justement pour appuyer mon point que si on a les moyens financier d'Amazon, on peut se permettre de faire du libre sans se soucier de la compétition.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: BSL
Posté par David Delassus (site web personnel) . En réponse au lien Sentry redevient privateur. Évalué à 5.
Pour ma part, à partir du moment ou l'auteur est une compagnie privée, faire du non-libre, c'est fair game.
Amazon qui forke ElasticSearch ? Fair game.
Google qui garde jalousement ses algos privés et qui après bien les avoir exploité en sort une version avec moins de fonctionnalités (BigTable, Kubernetes, …) ? Fair game.
Une PME comme Sentry qui fait du proprio et libère après 3 ans ? Fair game.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# "redevient"
Posté par David Delassus (site web personnel) . En réponse au lien Sentry redevient privateur. Évalué à 6. Dernière modification le 28 septembre 2022 à 21:05.
Le terme exact quand c'était libre dès le début et que cela ne l'est plus c'est "devient", pas "redevient".
La ça sous-entend une girouette "on a fait du proprio, on a essayé le libre, et en fait nan".
De plus, comme d'autres commentaires l'ont déjà dit, la phase propriétaire est temporaire. Et je trouve que cela est une excellente idée pour continuer de contribuer à l'opensource et garder un certain avantage en tant que business, un parfait juste milieu.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: BSL
Posté par David Delassus (site web personnel) . En réponse au lien Sentry redevient privateur. Évalué à 6.
J'aime bien la BSL.
Parce que au bout d'un moment, il faut être réaliste.
T'es un business, ton but c'est d'être viable, de générer du revenu, de payer tes employers, de payer ta direction. Bref, le but d'un business c'est de faire de la thune.
Avec le temps, je me suis rendu compte pour faire de l'argent avec du libre, il faut…. de l'argent, beaucoup d'argent.
C'est pas pour rien que les plus gros contributeurs à l'écosystème libre c'est les GAFAM, les Red Hat, etc… qui ont d'autres revenus conséquent qui leur permet d'investir dans le libre.
Mais quand t'es un trou du cul avec ta petite PME, t'as pas assez d'argent pour faire du libre efficacement.
Le business a peut être commencé avec des techos qui aiment réellement le libre, qui se sont rendus compte tristement dans une grande désillusion qu'ils ne sont ni Google, ni Amazon, et qu'ils doivent manger, et ont décidé à contre cœur une des options suivantes :
Cela a été le choix d'ElasticSearch, de MongoDB, de Qt, de Sentry, et de bien d'autres.
J'aimerais bien moi faire du libre 100% du temps, et avoir de quoi payer mon loyer et ma bouffe, et mettre même un peu de côté pourquoi pas ?
Bref, c'est vrai, mais c'est extrêmement réducteur et manque d'empathie.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Et hare, alors?
Posté par David Delassus (site web personnel) . En réponse au journal Ces langages avec lesquels il faut tout réécrire. Évalué à 2.
La vrai question c'est : es-tu prêt a ignorer la majorité des utilisateurs potentiels de ton appli ?
Il me semble que les Linux et *BSD c'est même pas 5% des parts de marché.
C'est bien d'être libriste, mais à un moment il faut être réaliste.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: V is for vapoware ?
Posté par David Delassus (site web personnel) . En réponse au journal Ces langages avec lesquels il faut tout réécrire. Évalué à 4.
En Lua tu as des tables. L'opérateur
#retourne le nombre d'éléments dans la table. Une table ne peut pas contenirnil(et donc assignernila un élément de la table le supprime de la table). Les clés d'une tables peuvent être des nombres, des strings, des fonctions (oui oui), etc…Lorsque l'on créé une table sans préciser les clés, c'est comme si on utiliser des nombres en partant de 1:
Pour parcourir une table on utilise:
Lua n'a donc pas vraiment de "liste" / "tableau". Que des dictionnaires, donc utiliser les indices pour parcourir une table n'est vraiment pas la bonne pratique.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Letlang évidemment
Posté par David Delassus (site web personnel) . En réponse au journal Ces langages avec lesquels il faut tout réécrire. Évalué à 7.
Héhé ça fait plaisir de voir ce commentaire :)
En plus en ce moment ça avance pas mal, de grosse news arrivent au moins avant la fin d'année !
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: V is for vapoware ?
Posté par David Delassus (site web personnel) . En réponse au journal Ces langages avec lesquels il faut tout réécrire. Évalué à 8.
Je ne classerai pas ça comme une boulette (ni grosse ni petite).
C'est un choix subversif certes, mais rappelons que du point de vue des maths (point de vue que prend Julia), c'est l'index 0 qui est bizarre.
Aussi, l'argument souvent avancé pour l'index 1 vs l'index 0 c'est le "off by one error" qui est censé ne pas arriver avec l'index 0.
Oui bon la je peux plus les défendre…
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Est-ce que c'est pas un peu tôt?
Posté par David Delassus (site web personnel) . En réponse au lien It's time to stop using C and C++ for new projects, says Microsoft Azure CTO. Évalué à 6.
Avec ce 1/4 bien encapsulé dans une API safe, on a donc 3/4 du code qui est garanti safe par le compilateur.
Aussi : https://os.phil-opp.com/
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg