barmic 🦦 a écrit 5924 commentaires

Les commentaires juste au dessus du tiens pointent des algos de mariages stables et décrivent les propriétés des résultats.

Comme indiqué par rewind, ils ne peuvent plus être utilisés par choix politique.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Il me semble que toutes les solutions « modernes » sont surtout moins fortes. Elles nécessites de faire confiance à une entité sur la quelle tu n'a aucun contrôle. Que ce soit utile pourquoi pas, mais il est nécessaire d'avoir une solution qui ne porte pas ces problèmes.

De plus il faut remettre en contexte. Cette technologie que vous jugez désuète, vous vous appuyez probablement dessus. C'est un outil de travail nécessaire pour signer ses commits git et c'est ce que les gestionnaires de paquets utilisent pour vérifier les paquets avant installation par exemple. En parler comme d'un truc inutile, je trouve ça un peu rude.

Je ne vois pas en quoi le fait que vous n'en voyez pas l'usage et que vous ne savez pas vous en servir en fait une technologie désuète ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Avoir un postgresql géré à coté, c'est un peu l'inverse des préconisations microservices, non ? Tu ne peux pas avoir un soft qui se créait sa propre base de donnée et l'utilise (par exemple avec helm).

Ça se discute, mais en principe tu ne va pas laisser un service manipuler helm ou même manipuler ton cluster comme ça, ne serais-ce parce que ça pose des problèmes d'un point de vu sécurité. L'idée dans les microservices c'est qu'un service soit seul maitre de sa données. Le fait qu'il crée dynamiquement sa base ne me semble pas être une nécessité et il n'est pas obligé d'avoir sa propre instance de base de données, je ne vois personnellement pas de problème majeure à ce que plusieurs services utilisent des bases de données différentes au sein du même postgres. Bien sûr il y a un niveau de couplage du coup (si tu as des configurations transverse à tes bases postgre elles impactes tout le monde, la charge n'est pas forcément segmentée,…) c'est un choix à arbitrer.

Si tu veux complètement découper, tu va utiliser un controller. C'est un type de container particulier qui est là pour manager des pod. Au déploiement ton service va aller demander une base à ton controller qui va créer la base si nécessaire et te répondre avec les accès qui vont bien. Tu peux même jouer à donner un utilisateur différent à chacun des pods de ton service. Ce qui est particulièrement cool d'un point de vu sécurité. Ça peut te donner des possibilités sympas comme le fait d'utiliser effectivement des instances différentes en prod, mais d'utiliser un seul cluster dans des environnements de dev/test qui sont généralement moins gros.

En tout cas, je note que l'on est loin d'avoir une solution pérenne et performante pour gérer les données persistantes dans k8s.

C'est un gros, vieux et long débat :)

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C'est vrai. Mais je suis très stressé sur la pérennité des données que je reçois.

Effectivement ça a l'air assez complexe. Nous les stockage qu'on veut fiables sont hors k8s et je pousse pour qu'on fasse quelque chose d'assez simple là dessus : quand les données arrivent on les prends et on les envoie dans un cassandra tel quel. Ensuite on en fait les calculs qu'on veut et on peut reconstruire les données calculées à partir de leur sources (je n'aurais pas la prétention de dire que c'est de l'event sourcing parce que ça ne respect pas tous les concepts qui y sont associés, mais ça s'en approche).

Celui dans ceph permet de faire des snapshots de postgres pour démarrer une stack de dev avec les même données que dans la prod et alimenté par le kafka. Stack qui est démarré automatiquement quand je pousse une nouvelle branche dans gitlab.

Ça c'est cool ! Nous on l'a pas et ce serait difficile à mettre en place (il faut une étape de changement des données pour ne pas faire n'importe quoi d'une part et être respectueux des données utilisateurs d'autre part). On est en mesure de rediriger le flux de prod (avec justement les filtres qui vont bien, vers l'environnement que l'on souhaite).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

On utilise la réplication d'es pour ça chez nous.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ceph c'est plus pour les disques de elastiksearch, prometheus, pour notre owncloud et comme object storage.

Je ne connais pas les autres ('fin non je connais owncloud et je vois très bien l'intérêt), mais elasticsearch gère sa propre réplication ça n'est pas dommage d'avoir un cluster es sur un cluster ceph ? Ça réplique de la réplication avec des logiques très différentes et des niveaux de garanties très différents.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ceph n'est pas une obligation mais avoir un stockage partagé oui.

Nous on en utilise pas. En quoi c'est une obligation ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

j'ai juste vu passé le nom "Helm"

helm c'est l'un des outils qui est là pour générer des configurations k8s et les appliquer. Il permet de faire des templates et de les versionner (et donc de les rollback par exemple). C'est probablement le plus sophistiqué (il gère son propre versionnement, permet d'envoyer ça dans des dépôts,…). Mais il y a un paquet d'alternatives kustomize, pulumi, crossplane, kompose,…

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ensuite il faut aussi installer et donc maintenir un cluster Ceph pour le stockage ce qui rajoute de la complexité et du temps pour faire l’exploitation.

C'est pas une obligation. Nous on ne déploiement pas nos bases de données sur kubernetes. L'intérêt est très faible pour nous, on a très peu de mouvement sur nos config de db, ce sont des machines spécifiquement taillées pour des bases. Les mettre dans un k8s apporterait quelques trucs, mais pas suffisamment pour qu'on ai envi d'aller se battre avec les volumes et déployer un service comme ceph ou autre. On s'appuie sur les mécanismes natifs des bases pour avoir une haute disponibilité.

Par contre on a un déploiement kubernetes en multimaster ce qui demande un peu de travail en plus de config et de test (ne serais-ce que pour voir comment ça se comporte).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

En plus de ce genre de communication (qui n'existe pas que pour krita), il y a aussi je pense un coté grégaire : si tu n'utilise pas le même outil que moi il faut que je t'explique pourquoi le miens est meilleur. C'est très dommage, ça crée des clivages artificiels. Je comprends qu'on veuille valider et faire valider nos choix et aussi qu'on crée un affect avec les logiciels que l'on utilise, mais c'est dommage d'aller jusqu'à faire de l'entrisme ou au dénigrement.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je ne dis pas le contraire (c'est je trouve très bien expliqué dans le lien que je donne dans un autre commentaire), je dis que la distinction entre un algorithme classique et un algorithme d'apprentissage est totalement ignoré par le béotien. On médiatise beaucoup sur les dangers des algorithmes et de la gouvernance par les algorithmes. C'est normal de faire le cheminement pour parcourtsup. Il aurait était probablement mieux d'expliquer plutôt que d'acquiescer.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Le côté « programmable » des fichiers de configuration est apporté avec jinja dans ansible, et complètement dissocié du langage dudit fichier.

Et c'est bien daubé. Ansible utilise jinja, helm utile gotemplate c'est un enfert à lire à écrire, à parser,… Parce que tu as justement 2 langages complètement dissocié. Ils ont un typage différent, ta coloration syntaxique est aux fraises selon les outils que tu utilise,…

Définir séparément les langages de description et de template pourquoi pas ne pas regarder l'un quand tu utilise l'autre ça amène pas mal de problème. On vit avec, mais ça n'a vraiment pas le goût de « la bonne solution ».

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Le ministère a voulu «remettre de l'humain dans la procédure» mais au final, on a introduit la sélection et le bouzin met des plombes à converger et les critères sont devenus totalement opaques et on n'a plus aucune garantie que l'affectation est optimale.

Pas que le ministère c'est aussi une pression publique. De ne pas vouloir de gouvernance par les algorithmes sans distinguer (ce qui est véritablement complexe pour le non initié) des algo de mariage stable d'un réseau de neurones profond.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

je ne leur jete pas trop la pierre, si c'est une boite privée qui l'avais pondu, ca aurait couté plus chère ET ca ne fonctionnerais pas.

Bien sûr on montre les exemples qui marchent le moins, mais les logiciels de l'état ne se limite pas à quelques exemples comme louvois. service-public.fr et ces prédécesseurs fonctionnent bien par exemple.

peut etre faire un logiciel libre sur gitlab avec des domaines attribué au université informatique/ministère + les contributeurs bénévole, un peu comme linux.

1. ce serait bien de rétribuer les développeurs seul l'état en a un intérêt donc ça se rapprocherait beaucoup de l'existant
2. c'est quoi le modèle de gouvernance du projet ? il peut y avoir des pressions fortes de la part de contributeurs pour pousser des idées dans le code (ça existe potentiellement déjà, mais c'est exacerbé en acceptant des contributions extérieures)

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Du point de vu dev oui, c'est la stack de déploiement qui me donne l'impression de se chercher. Éventuellement la configuration (ce qui est fait avec helm ou kustomize par exemple). L'état de l'art de la manière d'empiler orchestrateur + runtime + dépôt + configurateur évolue évolue pas mal (je dis pas qu'il n'a pas à évoluer, je dis que se tenir à jour demande un travail conséquent et une compréhension relativement approfondie). Et il faut séparer les annonces des réalités, beaucoup d'entreprises font des annonces ou des gens publient des articles, mais sans forcément qu'il y ai quelque chose derrière ou que ça prenne (kubernetes pour des machines virtuelles, il y a plus de gens qui en parlent que de gens qui en utilisent par exemple, IBM annonce des fois des outils pour orchestrer des orchestrateurs,…).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

swarm en prod

On utilisait ça pendant pas mal de temps, le passage à un orchestrateur plus complet est assez salvateur. En tout cas quand tu déploie sur plusieurs machines. Rien que la répartition des instances sur les serveurs n'est pas folles avec swarm. Le passage à docker stack ou une alternative, ça demande un effort de s'y mettre mais le retour sur investissement et plutôt pas mal je trouve.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Pour en ajouter une couche :)

Le paradigme "tout est fichier" commun aux unix est une base sur la quelle les différents unix ce sont construit.

La base c'est de considérer toutes les entrées/sorties des programmes comme des fichiers (donc la sortie standard aussi, les pipes, les sockets,…).

Du coup je suis allé vérifier les pseudo systèmes de fichiers sont apparu dans unix himself et là il s'agit d’interagir avec un programme au travers d'un système de fichier. On utilise le fait de voir des dossiers/fichiers et lire le contenu d'un fichier comme les sorties d'un programme et le déplacement dans un dossier, la création de dossier/fichier et l'écriture dans un fichier comme les entrées du programme.

L'intérêt est évident pour les programme qui ne peuvent que difficilement avoir des interfaces comme le noyau, mais c'est aussi très intéressant car les gestionnaires de fichiers et éditeur de texte peuvent naturellement interagir avec ce type de programme.

Sur linux tu trouvera 3 pseudo systèmes de fichiers classiques : udev (monté sur /dev et qui représente le hardware de la machine), procfs (monté sur /proc qui représente tous les processus de la machine (c'est une mine d'or d'aller s'y balader quand on ne connait pas)) et cgroup de plus en plus qui représente des limitations et quotas données aux processus. Mais fuse en possède pleins pour faire pleins de choses rigolotes : liste de filesystem de fuse.

Dernier point hurd avait un concept de translator pour faire ça qui a l'air plutôt cool.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tu n'a même pas forcément besoin de remplaçant tu peut juste utiliser containerd si tu le souhaite (ça évite d'avoir le deamon docker que certains n'aiment pas).

J'ai l'impression que l'écosystème docker/k8s n'est pas encore arrivé à son niveau de maturité pour être stable (dans le sens ne pas changer l'état de l'art architectural tous les 2~3 ans).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C’est un problème qui s’apparente au problème des mariages stables qui s’attaque relativement bien vu comme un problème de satisfaction de contraintes, donc dans un cadre ensembliste.

Pour ceux qui préfèrent une vidéo explicative il y en a une sympa sur la chaine de ScienceEtonnante (j'ai découvert en recherchant cette vidéo, qu'il y a un mouvement de vidéos « réaction aux résultats ParcourtSup' »)

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Les ERP utilisent pas mal de requêtes complexes comme les requêtes OLAP. Je n'ai pas rencontré d'ORM qui savaient en faire.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Le jour ou tu dois ajouter un champs ou gérer une liaison supplémentaire tu comprends très vite que d'avoir des INSERT en dur c'est une très grosse connerie.

Tu peut avoir des problèmes similaire avec des données structurée. Si ta modification est simple et qu'il s'agit d'ajouter une colonne ou une liaison sur du SQL correctement formaté ça n'est pas très compliqué à faire. C'est moins souple, moins performant, etc

En plus ça peut être tout à fait être ce que tu dis sauf qu'ils n'ont pas intégré l'outil à leur build pour de bonnes ou de mauvaises raisons même si c'est une bonne pratique qu'il soit intégré.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ça ne va pas de poser des problèmes pour la relecture ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

J’espère qu'il y a des droits plus fin, genre --allow-net:domain.net

Tu gère comment la transitivité ? Tu as une bibliothèque sur un domaine A qui tire une dépendance sur le domaine B (et pour le fun dans la version suivante cette dernière passer sur le domaine C ou A).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je suis entièrement d'accord avec toi sur ce point.

Donc pourquoi être aussi catégorique au dessus pour dire qu'il faut proposer un SGBDR uniquement et que ça n'a pas de sens de parler des NoSQL?

Mais comment sais-tu comment je travaille ? Tu proposes MongoDB en remplacement de MySQL, je te dis que proposer une BD NoSQL pour remplacer un SGBD ne marche pas à tous les coups et que cela dépend fortement des cas d'usage (besoins !), et tu es capable de me dire l'âge du capitaine ? Niveau "supposition", je pense que tu fais fort !

Tu t'es lancé dans une tirade avant même d'avoir véritablement lu mon premier commentaire. J'ai bien dis que ça dépendait des cas. Je l'ai dis clairement dès mon premier commentaire. Tu t'es lancé dans un long commentaire pour t'en offusquer sans chercher à comprendre ma phrase. Ce genre de réaction donne forcément des impressions.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je critique aussi ton choix de proposer MongoDB en tant que remplacement pour MySQL car ils ne répondent pas au même besoin. Mais à aucun moment, je n'ai dénigré (pour reprendre tes propos) MongoDB.

Ce n'est pas comme ça que je travaille. Le besoin pour moi lorsque l'on construit un logiciel ce n'est pas "avoir une base de données SQL" (sauf bien sûr dans des certains contexte), mais "j'ai besoin de stocker de la donnée" et il y a une pluralité de réponse à cette question. Quand on se pose la question de cette façon sans présupposé sur la réponse technique, on ne segmente pas autant que ce que tu semble faire. Et moins on a de contraintes plus le champs des possibles est ouvert. Au contraire que plus tu as de contrainte moins tu aura de solution.

Pg et mongo sont pour moi les 2 bases qui sont les meilleures solutions quand tu es peu contraint. Ils ballaient un très large champs de besoin fonctionnel. Pg allant jusqu'à marcher sur les platebandes de ce qu'on appellerait NoSQL (le type json n'est pas 3NF) et mongo allant lui aussi taquiner des choses que l'on trouve d'habitude chez les SQL (avec des transactions).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll