barmic 🦦 a écrit 5946 commentaires

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

Dès lors, proposer l'un pour l'autre sans connaitre le contexte d'utilisation derrière est juste… impossible.

L'objet de mon premier commentaire c'est que d'après ce que tu dis MySQL a du mal avec les propriétés ACID en particulier avec la durabilité. Il est donc logique de commencer à regarder du coté des bases qui sans se venter d'être ACID cherchent à s'en rapprocher. Mais surtout, dès le départ j'ai dis explicitement que ce n'était pas une règle générale.

Je vais le dire plus simplement du coup. Je en dis pas :

Mongo déboite MySQL

mais

Vu les souci que semble avec MySQL, Mongo est un concurrent serieux dans certains contexte.

J'ai bien indiqué dès le début que ça dépendait des cas.

Je suis désolé, mais s'adresser à des développeurs en les nommant "programmateur", c'est une énorme erreur qui peut faire perdre toute crédibilité (à noter qu'ici, le problème est uniquement dans la traduction française, mais j'ai trouvé ça "coquet").

Pointer ça tout en faisant une grosse faute de français est au moins aussi "coquet".

Ce que je comprends, c'est que le modèle "rangées et colonnes" est dépassé (et donc, de facto le modèle des SGBD) mais NOUS nous avons la solution ultime. Ben je suis désolé, c'est des conneries de "markéteux".

Il indique clairement que c'est leur point de vu. Les gens croient en leur projet c'est normal. Leur faire un procès d'intention pour cela c'est très dommageable. Regarde pijul tu peux difficilement les taxer de "markéteux", c'est juste leur point de vu. Tout point de vu est critiquable. C'est dommage de placer ça juste pour dénigrer. D'autant que leur job c'est de faire cette base, qu'ils croient une chose ou une autre sur les autres systèmes de stockage n'est pas très important par rapport au travail qu'ils font.

Je n'ai aucune raison de "baver" sur MongoDB. Tu noteras d'ailleurs que je n'ai rien dit du point de vue technique,[…]

Quel est l’objectif de les dénigrer du coup ?

[…] car, à ma connaissance, c'est une bonne techno (pas eu l'occasion de l'employer jusqu'à présent sur des projets, mais les retours que j'en ai sont plus que positifs).

Ouai il a tout de même un paquet de défauts quand tu le pousse un peu.

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

Ouai, je ne connais pas très bien MySQL, mais avec ce genre de descriptions, j'ai l'impression qu'un mongodb est probablement plus pertinent dans la plupart des cas.

Attention, les deux ne répondent pas aux mêmes besoins ! L'un est un SGBD (enfin prétend l'être, troll inside xD), l'autre est de la mouvance NoSQL (orienté document).

C'est une dichotomie, mais il y en a d'autres. Grosso modo l'impression que me donne ton commentaire c'est : quand tu as peu de contraintes MySQL peut faire le job, mais dans ce genre de cas ça peut être intéressant d'élargir son spectre. Et d'aller voir potentiellement vers ce qui n'est pas du SQL ou d'autres bases SQL.

En particulier une base de données qui est sujette à corruption des données comme le semble l'indiquer ton commentaire. Même si je me doute que c'est des cas rares pathologiques etc. Ça baisse fortement les chances que je me tourne vers elle :)

Mongo est une base extrêmement flexible qui supporte des transactions. Il est très agréable à utiliser. Ce qui va le distinguer de MySQL ça va être le fait qu'il est sans schéma. Mais si ton taff c'est d'utiliser un ORM et de pas faire de requêtes trop complexes, ce qui me semble être le cas d'usage que tu dépeins. Il peut être une très bonne alternative.

Ce qu'il ne faut pas lire :/ Tout dépend des usages ! Mais bon, la je disgresse xD

Je te trouve très rude.

1. C'est assez ironique de leur reprocher leur vocabulaire pour développeur dans une phrase dans la quelle tu utilise un verbe qui n'existe pas…
2. La citation que tu pointe est très humble ils expliquent que c'est leur point de vu. C'est plutôt pas mal de croire en ce qu'on fait en tant dans le développeur d'un projet. Je pense que leur présent est un présent de vérité général ils pensent qu'en général c'est le cas. C'est discutable bien sûr mais le tourner en ridicule, je ne pense pas que ça en vaille la peine.

Si tu veux baver sur mongo, des citations du patron de la boite qui est derrière seront bien plus pertinentes.

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

Après, est-ce que cela veut dire qu'il ne faut pas l'utiliser ? Non. L'avantage de MySQL est qu'il reste répandu et léger. Donc pour de simple besoin (blog, site, etc…) où les données ne sont pas crucial, il n'y a aucun problème à l'utiliser (PS : je l'utilise pour mon site xD)

Ouai, je ne connais pas très bien MySQL, mais avec ce genre de descriptions, j'ai l'impression qu'un mongodb est probablement plus pertinent dans la plupart des cas.

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