Une question qui me turlupine quand même, c'est comment intégrer efficacement un SceneGraph et un ECS.
Le but des ECS c'est de stocker les données de manière contigüe en mémoire, afin de gagner en performance lors de l'accès aux données.
On va donc avoir un tableau de "transform", un tableau de "shader", un tableau de "mesh", etc… (tableau dans le sens non-IT du terme, l'implémentation peut être un array, un sparse set, un vector, etc… ce n'est pas de ça que je parle ici quand je dis tableau)
Et on va ensuite avec une fonction "render" qui va itérer sur ces tableaux. Et les caches du CPU seront bien content.
Sauf que un SceneGraph, c'est un graphe acyclique. Donc des pointeurs vers des structures qui contiennent des pointeurs vers d'autres structures.
Je vois alors 2 solutions :
le composant "transform" contient une référence vers le noeud du SceneGraph : mince on doit faire un aller/retour entre le CPU et la RAM, le gain de perf est nullifié
les noeuds du SceneGraph ont une référence vers l'entité, chaque frame on doit vérifier si l'entité existe encore et synchroniser le SceneGraph, puis mettre à jour le composant "transform" de l'entité : aucune idée du coût en performance de faire ça a chaque frame
Quand tu fais du libre et qu'ensuite tu viens de plaindre "mince, les gens profitent des libertés que je leur ai donné, quelle ironie du sort", oui j'estime qu'il ne sait pas ce qu'implique le libre.
pour asséner des "il n'aime pas le libre, il aime l'argent".
Ou est le mal a aimer l'argent ? A vouloir générer un revenu et vivre de son travail ?
Ce que je critique n'est pas son "échec", c'est son incompréhension du libre et des libertés et des conséquences que cela a.
"Je fais du libre, mais que tant que ça rapporte des sous" c'est pas "aimer le libre".
Tu ne vois pas la violence du procédé ?
Aucune violence ici, juste un autre exemple (parmi tant d'autres) que faire un business model autour du libre c'est pas si facile. Beaucoup d'appelés, peu d'élus.
Quand tu veux passer à temps plein sur un projet, tu prends un risque, t'as donc intérêt à être prêt.
Je maintiens qu'il y a 2 ans, il aurait du ouvrir une discussion du style "je vais passer à temps plein sur ce projet, des idées de business model pour rendre le projet rentable histoire que j'y perde pas des plumes ?".
Il est parfaitement acceptable de changer la licence libre pour une licence commerciale, que ce soit maintenant ou il y a 2 ans. Mais il faut aussi se remettre en question sur ce qu'on attend du libre.
Faire du libre pour dire "hé moi je fais du libre t'as vu ?" c'est plus une histoire d'égo en fait.
Comme toujours on est bien plus prompte à tacler ceux qui échouent à maintenir leur projet libre qu'à soutenir et aider.
Je ne critique pas sa décision d'arrêter de faire du libre, je déplore qu'elle arrive si tard.
Je vais me prendre en exemple, lorsque je créé un nouveau projet, il est privé par défaut. Au moment ou se pose la question de le distribuer, je me pose les questions suivantes :
qui est la cible ?
est-ce que cette cible serait prête à payer pour ce projet ?
est-ce que je suis prêt à investir en communication/marketting/… pour tenter d'aller chercher cette cible sans attendre l'effet de bouche-à-oreille ?
est-ce que c'est une niche suffisamment développée pour être rentable ?
est-ce que j'ai des concurrents ? qui sont ils ? comment mon projet se compare à eux ?
si je rend le projet libre, est-ce que je me sens capable de le maintenir dans le temps ? en ai-je envie ? dois-je chercher des repreneurs ?
Et j'en passe bien d'autres. Le choix d'une licence libre est donc un choix conscient et réfléchi. C'est le résultat d'une réflexion, pas une option par défaut.
Ce que je critique, c'est que dans 90% des cas, les "développeurs open-source" n'ont en fait jamais réfléchi à ce que cela veut dire, à ce que leurs licences impliquent. Quand tu créé un dépôt Github, tu dois opt-ou de l'option "publique" et opt-in dans l'option "privé".
Les gens se servent de Github comme d'un port-folio, la ou moi je m'en sers de backup puis d'outil de collaboration. (Parenthèse, je ne comprends pas les gens qui forkent ton projet sans jamais faire de commit, c'est pour faire joli sur leurs profils ?).
Quand rendre publique un projet devient une action supplémentaire et manuelle, la réflexion sur le libre et ses enjeux devient automatique.
J'ai pas mal de "projet perso", certains que je ne finirai jamais, d'autres qui avancent lentement, beaucoup qui ne servent à rien, certains qui pourrait avoir un intérêt dans certaines niches mais dont je ne sais pas encore comme je me place face à la compétition. Ces projets ne sont pas encore opensource, et si je décide de les sortir sous MIT/GPL/… ce sera suite à une réflexion de la sorte.
TL;DR: Réfléchissez avant de faire du libre si vous avez vraiment envie d'en faire.
Le fait que son article parle de ça montre que c'est une de ses préoccupation principale, devant la philosophie du libre. Ce n'est pas un mal. Moi aussi j'aime l'argent.
Tu infères beaucoup de choses à partir de bribes de phrases.
J'infère une seule chose, à partir d'un article complet dont j'ai donné le lien : lorsqu'il a décidé de faire de son projet personnel le produit de sa startup (donc une entreprise dont le but est d'être rentable), il n'a pas réfléchi au business model.
Imagine qu'il ait dit :
J'ai essayé pendant 2 ans un business model, mais je n'ai pas réussi à lui faire tenir la route. Je dois donc, à contre coeur, changer de direction
Non, la ce qu'il a dit c'est :
Personne ne paye parce que j'ai fait un truc gratuit, et même des grosses entreprises en profite alors qu'elles ont beaucoup de sous
Une entreprise qui vient te voir pour me demander d'implémenter des fonctionnalités, tu te rends compte à quel point s'est rare ? Tu te rends compte de la chance, de l'opportunité en or ? C'est le moment parfait pour établir un contrat, et générer du revenue, l'entreprise en sera d'autant plus contente car elle pourra stipuler dans le contrat des garanties qui ne sont pas incluses dans la licence AGPL.
A la place, on présente ça comme une triste ironie du sort "les gens profitent de mon logiciel gratuitement, qui l'eu crut ?".
Je comprends aussi l'envie de changement. Mais cette envie aurait du arriver dès le moment ou il a considéré passer à temps plein sur le projet.
Croire que les gens ne vont pas utiliser les libertés que tu donnes via une licence open source et bien gentiment te financer, c'est au mieux naïf.
Quand tu démarres un business, il faut te poser plusieurs questions, qui seront tes clients ? qu'est-ce qui les motivera à acheter ton produit ? qu'est-ce qui les motivera au contraire à ne pas l'acheter ? etc…
Passer 2 ans à perdre de l'argent pour se rendre compte au final que "les gens ne veulent pas payer pour un truc que je leur donne gratuitement" prouve qu'il ne s'est ni posé les questions ci-dessus, ni n'a considéré les réelles implications de ce qu'est une licence libre/open source.
Le titre de mon commentaire n'a rien de péjoratif. Il n'y a aucun mal a aimer l'argent. Il n'y a aucun mal a vouloir générer un revenu.
Par contre, dire "je fais de l'open source" alors qu'en réalité on n'a pas réfléchi à la question, c'est navrant.
A noter que la bonne réponse à "quand est-ce que c'est dispo ?" de la part d'une entreprise c'est :
Dans 2 semaines à 4000€ par jour, payé d'avance
Chiffre à la noix à titre d'exemple, mais c'est comme ça qu'on génère du revenu.
Une entreprise qui te demande une fonctionnalité, c'est pas un utilisateur lambda qui ouvre un ticket sur Github. Faut négocier avec, faire un contrat, et cash in.
Faire une startup (open-source ou non) ça demande un peu de fibre entrepreneuriale.
I was optimistic when I started the mold linker project that I'd be able to earn a comfortable income in some way if it becomes popular.
J'étais optimiste quand j'ai commencé le projet mold linker que je serais capable de générer un revenu comfortable d'une manière ou d'une autre s'il devenait populaire.
Donc on confond "popularité" et "rentable", déjà c'est mal parti.
Ensuite :
It's even a bit ironic that I had been asked by several big-name companies when mold/macOS would become available, since they wanted to use it for their multi-billion-dollar businesses.
C'est même ironique que j'ai reçu des demandes de différentes grosses entreprises quand mold/macOS serait disponible, puisqu'ils voulaient les utiliser pour leur entreprise multi-milliardaire.
On confond maintenant "un dev d'une grosse entreprise" avec "la grosse entreprise elle même". Je pense pas que le CEO soit au courant, ou en ai quelque chose à faire.
Il est parfaitement acceptable de ne pas faire de l'open-source si on veut générer un revenu et vivre de son projet, rien à redire sur cela.
Mais l'incompréhension du concept "open source" et des libertés que tu es censé donner à tes utilisateurs est navrante…
Tu as un article entier sur une seule page ? La chance.
Sur mobile je tombe souvent sur des sites ou tu as un paragraphe par page avec un bouton "continuer a lire' sur chaque page pour générer un max de clic et de revenu d'annonce.
Donc quand il parle de l'environnement de développement, il parle plutôt d'un environnement d'intégration.
Imagine le workflow suivant :
la branche main est déployée en continu sur l'environnement de dev, le développeur teste son travail
on tag une vX.Y.Z, ce tag est déployé sur la staging, les QA testent l'ensemble de l'application
après validation par les QA, la staging est promu en production
Bien sûr qu'on ne va pas demander au développeur de faire tourner toute l'infra kubernetes sur sa machine. Le développeur est responsable de sa machine.
Dans mon "ça marche sur ma machine" il fallait comprendre "je comprends pas pourquoi ca fonctionne en staging et pas en prod". Si la prod utilise PHP 7.4, ben tu utilise PHP 7.4 partout.
Si un développeur se lance la mission de passer en PHP 8, il commence par sa machine, ensuite on upgrade la staging, puis on upgrade la prod. Avec de "l'Infrastructure as Code" ce process d'upgrade (et de rollback en cas de soucis) devient plus simple.
Comment tu gères tes variables d'environnement pour avoir des conflits ?
Comme je l'ai dit dans un autre commentaire, il te suffit de faire plusieurs unit systemd, ou plusieurs docker run, ou plusieurs k8s pods, ou … différents, même un bête script shell comme suit fait l'affaire :
mais c'est le seul moyen que je voie qui permette d'éviter les collisions.
Un unit systemd permet de définir les variables d'env du process. Docker permet de passer la valeur des variables d'env via l'option -e ou --env-file. Un Pod Kubernetes permet de passer la valeur des variables d'environnement and inline, via un ConfigMap, ou via un Secret. Les plateformes type Heroku, les fonctions Netlify ou AWS Lambda, toutes permettent de définir les valeurs des variables d'environnement.
Dans le cas de systemd, c'est simple : tu fais plusieurs units. Pour docker, c'est un docker run différent. Pour Kubernetes, c'est un Pod différent, etc…
Et c'est toujours la même application qu'on instancie de manière différente. Ou est le conflit ?
Ne pas stocker dans des fichiers parce que c'est local, préférer FTP & co? Idem, pas cohérent.
C'est pas ce que j'ai dit. Et ce n'est pas ce que 12 factors dit. Ce qui est dit c'est qu'il faut déléguer la persistance à un service tier, configurable, et ne pas le hard-coder dans l'application.
Dans le cas de docker, le système de fichier (si pas de volume), c'est un tmpfs (ou équivalent) qui disparaît entre 2 lancements.
Pour faire simple, lorsque tu écris ton application, considère qu'elle sera toujours exécuté sur un tmpfs, et rend paramétrable le lieu de stockage pour que l'ops puisse faire pointer ça vers un volume ou autre.
Je prend l'exemple de postgresql qui utilise la variable d'env PGDATA, que j'utilise avec docker pour le faire pointer vers un volume qui lui sera persisté (sur le disque local pour mon docker-compose de dev, sur un block storage dans le cloud pour kubernetes, etc…).
Dans l'ensemble, de ce que j'ai compris de ce que tu dis, ces 12 "règles" semblent être bien trop vagues pour être utilisables comme règles.
Nulle part sur le site il n'est dit que ce sont des "règles". C'est une philosophie, un ensemble de conseil que tu es libre d'adapter à ton besoin.
Par exemple, pour la numéro 8 (concurrency), j'ai pas de scrupule à utiliser supervisord dans une image docker pour lancer/gérer plusieurs process python (un worker celery, une webapp django), j'utilise le format %(ENV_CELERY_REPLICAS)s et %(ENV_DJANGO_REPLICAS)s pour la valeur de numprocs afin de rendre cela configurable quand même. Ici, 12factor conseille plutôt plusieurs image docker différentes, mais je m'en cogne.
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.
[^] # Re: Dans une précédente vidéo
Posté par David Delassus (site web personnel) . En réponse au lien Worlds hardest jigsaw vs. puzzle machine (all white). Évalué à 3.
Il a déjà un robot pour peindre ses murs.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# Dans une précédente vidéo
Posté par David Delassus (site web personnel) . En réponse au lien Worlds hardest jigsaw vs. puzzle machine (all white). Évalué à 2.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# Entity Component System
Posté par David Delassus (site web personnel) . En réponse à la dépêche Les graphes de scène. Évalué à 6.
Une question qui me turlupine quand même, c'est comment intégrer efficacement un SceneGraph et un ECS.
Le but des ECS c'est de stocker les données de manière contigüe en mémoire, afin de gagner en performance lors de l'accès aux données.
On va donc avoir un tableau de "transform", un tableau de "shader", un tableau de "mesh", etc… (tableau dans le sens non-IT du terme, l'implémentation peut être un array, un sparse set, un vector, etc… ce n'est pas de ça que je parle ici quand je dis tableau)
Et on va ensuite avec une fonction "render" qui va itérer sur ces tableaux. Et les caches du CPU seront bien content.
Sauf que un SceneGraph, c'est un graphe acyclique. Donc des pointeurs vers des structures qui contiennent des pointeurs vers d'autres structures.
Je vois alors 2 solutions :
Y-a-t-il d'autres solutions ?
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Comme toujours
Posté par David Delassus (site web personnel) . En réponse au lien mold linker pourrait changer de licence pour une licence non open-source. Évalué à 0.
Quand tu fais du libre et qu'ensuite tu viens de plaindre "mince, les gens profitent des libertés que je leur ai donné, quelle ironie du sort", oui j'estime qu'il ne sait pas ce qu'implique le libre.
Ou est le mal a aimer l'argent ? A vouloir générer un revenu et vivre de son travail ?
Ce que je critique n'est pas son "échec", c'est son incompréhension du libre et des libertés et des conséquences que cela a.
"Je fais du libre, mais que tant que ça rapporte des sous" c'est pas "aimer le libre".
Aucune violence ici, juste un autre exemple (parmi tant d'autres) que faire un business model autour du libre c'est pas si facile. Beaucoup d'appelés, peu d'élus.
Quand tu veux passer à temps plein sur un projet, tu prends un risque, t'as donc intérêt à être prêt.
Je maintiens qu'il y a 2 ans, il aurait du ouvrir une discussion du style "je vais passer à temps plein sur ce projet, des idées de business model pour rendre le projet rentable histoire que j'y perde pas des plumes ?".
Il est parfaitement acceptable de changer la licence libre pour une licence commerciale, que ce soit maintenant ou il y a 2 ans. Mais il faut aussi se remettre en question sur ce qu'on attend du libre.
Faire du libre pour dire "hé moi je fais du libre t'as vu ?" c'est plus une histoire d'égo en fait.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Comme toujours
Posté par David Delassus (site web personnel) . En réponse au lien mold linker pourrait changer de licence pour une licence non open-source. Évalué à 2.
Je ne critique pas sa décision d'arrêter de faire du libre, je déplore qu'elle arrive si tard.
Je vais me prendre en exemple, lorsque je créé un nouveau projet, il est privé par défaut. Au moment ou se pose la question de le distribuer, je me pose les questions suivantes :
Et j'en passe bien d'autres. Le choix d'une licence libre est donc un choix conscient et réfléchi. C'est le résultat d'une réflexion, pas une option par défaut.
Ce que je critique, c'est que dans 90% des cas, les "développeurs open-source" n'ont en fait jamais réfléchi à ce que cela veut dire, à ce que leurs licences impliquent. Quand tu créé un dépôt Github, tu dois opt-ou de l'option "publique" et opt-in dans l'option "privé".
Les gens se servent de Github comme d'un port-folio, la ou moi je m'en sers de backup puis d'outil de collaboration. (Parenthèse, je ne comprends pas les gens qui forkent ton projet sans jamais faire de commit, c'est pour faire joli sur leurs profils ?).
Quand rendre publique un projet devient une action supplémentaire et manuelle, la réflexion sur le libre et ses enjeux devient automatique.
J'ai pas mal de "projet perso", certains que je ne finirai jamais, d'autres qui avancent lentement, beaucoup qui ne servent à rien, certains qui pourrait avoir un intérêt dans certaines niches mais dont je ne sais pas encore comme je me place face à la compétition. Ces projets ne sont pas encore opensource, et si je décide de les sortir sous MIT/GPL/… ce sera suite à une réflexion de la sorte.
TL;DR: Réfléchissez avant de faire du libre si vous avez vraiment envie d'en faire.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Quand on croit aimer l'open source, mais qu'en fait on aime l'argent
Posté par David Delassus (site web personnel) . En réponse au lien mold linker pourrait changer de licence pour une licence non open-source. Évalué à 2.
Le fait que son article parle de ça montre que c'est une de ses préoccupation principale, devant la philosophie du libre. Ce n'est pas un mal. Moi aussi j'aime l'argent.
J'infère une seule chose, à partir d'un article complet dont j'ai donné le lien : lorsqu'il a décidé de faire de son projet personnel le produit de sa startup (donc une entreprise dont le but est d'être rentable), il n'a pas réfléchi au business model.
Imagine qu'il ait dit :
Non, la ce qu'il a dit c'est :
Une entreprise qui vient te voir pour me demander d'implémenter des fonctionnalités, tu te rends compte à quel point s'est rare ? Tu te rends compte de la chance, de l'opportunité en or ? C'est le moment parfait pour établir un contrat, et générer du revenue, l'entreprise en sera d'autant plus contente car elle pourra stipuler dans le contrat des garanties qui ne sont pas incluses dans la licence AGPL.
A la place, on présente ça comme une triste ironie du sort "les gens profitent de mon logiciel gratuitement, qui l'eu crut ?".
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Quand on croit aimer l'open source, mais qu'en fait on aime l'argent
Posté par David Delassus (site web personnel) . En réponse au lien mold linker pourrait changer de licence pour une licence non open-source. Évalué à 6.
Je comprends aussi l'envie de changement. Mais cette envie aurait du arriver dès le moment ou il a considéré passer à temps plein sur le projet.
Croire que les gens ne vont pas utiliser les libertés que tu donnes via une licence open source et bien gentiment te financer, c'est au mieux naïf.
Quand tu démarres un business, il faut te poser plusieurs questions, qui seront tes clients ? qu'est-ce qui les motivera à acheter ton produit ? qu'est-ce qui les motivera au contraire à ne pas l'acheter ? etc…
Passer 2 ans à perdre de l'argent pour se rendre compte au final que "les gens ne veulent pas payer pour un truc que je leur donne gratuitement" prouve qu'il ne s'est ni posé les questions ci-dessus, ni n'a considéré les réelles implications de ce qu'est une licence libre/open source.
Le titre de mon commentaire n'a rien de péjoratif. Il n'y a aucun mal a aimer l'argent. Il n'y a aucun mal a vouloir générer un revenu.
Par contre, dire "je fais de l'open source" alors qu'en réalité on n'a pas réfléchi à la question, c'est navrant.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Quand on croit aimer l'open source, mais qu'en fait on aime l'argent
Posté par David Delassus (site web personnel) . En réponse au lien mold linker pourrait changer de licence pour une licence non open-source. Évalué à 8. Dernière modification le 14 novembre 2022 à 05:36.
A noter que la bonne réponse à "quand est-ce que c'est dispo ?" de la part d'une entreprise c'est :
Chiffre à la noix à titre d'exemple, mais c'est comme ça qu'on génère du revenu.
Une entreprise qui te demande une fonctionnalité, c'est pas un utilisateur lambda qui ouvre un ticket sur Github. Faut négocier avec, faire un contrat, et cash in.
Faire une startup (open-source ou non) ça demande un peu de fibre entrepreneuriale.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# Quand on croit aimer l'open source, mais qu'en fait on aime l'argent
Posté par David Delassus (site web personnel) . En réponse au lien mold linker pourrait changer de licence pour une licence non open-source. Évalué à 6. Dernière modification le 14 novembre 2022 à 05:27.
Dans le texte de la release, on a un lien vers un Google Doc (parce que les blogs, c'est pour les hackers) : https://docs.google.com/document/d/1kiW9qmNlJ9oQZM6r5o4_N54sX5F8_ccwCy0zpGh3MXk/edit
Dedans on peut lire :
Donc on confond "popularité" et "rentable", déjà c'est mal parti.
Ensuite :
On confond maintenant "un dev d'une grosse entreprise" avec "la grosse entreprise elle même". Je pense pas que le CEO soit au courant, ou en ai quelque chose à faire.
Il est parfaitement acceptable de ne pas faire de l'open-source si on veut générer un revenu et vivre de son projet, rien à redire sur cela.
Mais l'incompréhension du concept "open source" et des libertés que tu es censé donner à tes utilisateurs est navrante…
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Triste réalité
Posté par David Delassus (site web personnel) . En réponse au lien Merci LinuxFR d'avoir gardé un design simple, clair, et efficace. Évalué à 9.
Tu as un article entier sur une seule page ? La chance.
Sur mobile je tombe souvent sur des sites ou tu as un paragraphe par page avec un bouton "continuer a lire' sur chaque page pour générer un max de clic et de revenu d'annonce.
Pire qu'un titre putaclic.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Explication
Posté par David Delassus (site web personnel) . En réponse au journal Douze facteurs dans ta tronche. Évalué à 2.
12factor parle de déploiement.
Donc quand il parle de l'environnement de développement, il parle plutôt d'un environnement d'intégration.
Imagine le workflow suivant :
Bien sûr qu'on ne va pas demander au développeur de faire tourner toute l'infra kubernetes sur sa machine. Le développeur est responsable de sa machine.
Dans mon "ça marche sur ma machine" il fallait comprendre "je comprends pas pourquoi ca fonctionne en staging et pas en prod". Si la prod utilise PHP 7.4, ben tu utilise PHP 7.4 partout.
Si un développeur se lance la mission de passer en PHP 8, il commence par sa machine, ensuite on upgrade la staging, puis on upgrade la prod. Avec de "l'Infrastructure as Code" ce process d'upgrade (et de rollback en cas de soucis) devient plus simple.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Explication
Posté par David Delassus (site web personnel) . En réponse au journal Douze facteurs dans ta tronche. Évalué à 2.
Comment tu gères tes variables d'environnement pour avoir des conflits ?
Comme je l'ai dit dans un autre commentaire, il te suffit de faire plusieurs unit systemd, ou plusieurs
docker run, ou plusieurs k8s pods, ou … différents, même un bête script shell comme suit fait l'affaire :A quel moment on a un conflit, vraiment ?
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Explication
Posté par David Delassus (site web personnel) . En réponse au journal Douze facteurs dans ta tronche. Évalué à 2.
Un unit systemd permet de définir les variables d'env du process. Docker permet de passer la valeur des variables d'env via l'option
-eou--env-file. Un Pod Kubernetes permet de passer la valeur des variables d'environnement and inline, via un ConfigMap, ou via un Secret. Les plateformes type Heroku, les fonctions Netlify ou AWS Lambda, toutes permettent de définir les valeurs des variables d'environnement.Dans le cas de systemd, c'est simple : tu fais plusieurs units. Pour docker, c'est un
docker rundifférent. Pour Kubernetes, c'est un Pod différent, etc…Et c'est toujours la même application qu'on instancie de manière différente. Ou est le conflit ?
C'est pas ce que j'ai dit. Et ce n'est pas ce que 12 factors dit. Ce qui est dit c'est qu'il faut déléguer la persistance à un service tier, configurable, et ne pas le hard-coder dans l'application.
Dans le cas de docker, le système de fichier (si pas de volume), c'est un tmpfs (ou équivalent) qui disparaît entre 2 lancements.
Pour faire simple, lorsque tu écris ton application, considère qu'elle sera toujours exécuté sur un tmpfs, et rend paramétrable le lieu de stockage pour que l'ops puisse faire pointer ça vers un volume ou autre.
Je prend l'exemple de postgresql qui utilise la variable d'env PGDATA, que j'utilise avec docker pour le faire pointer vers un volume qui lui sera persisté (sur le disque local pour mon docker-compose de dev, sur un block storage dans le cloud pour kubernetes, etc…).
Nulle part sur le site il n'est dit que ce sont des "règles". C'est une philosophie, un ensemble de conseil que tu es libre d'adapter à ton besoin.
Par exemple, pour la numéro 8 (concurrency), j'ai pas de scrupule à utiliser supervisord dans une image docker pour lancer/gérer plusieurs process python (un worker celery, une webapp django), j'utilise le format
%(ENV_CELERY_REPLICAS)set%(ENV_DJANGO_REPLICAS)spour la valeur denumprocsafin de rendre cela configurable quand même. Ici, 12factor conseille plutôt plusieurs image docker différentes, mais je m'en cogne.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é à 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