oau a écrit 316 commentaires

C'est surtout que les jeunes ont été éduqués par les vieux.

la on tombe sur le cœur du problème, la formation et dans mon cas le recrutement. Je ne dirais pas que les jeunes ont été mal éduqués par les vieux, je dirais plutôt que les jeunes n'ont pas été éduqué tout cours sur l'histoire de leur métier. En terme d'informatique je parle. Et puis l’adage qui dis "quand on sait faire on fait, quand on sait pas faire on enseigne" marche pas mal :) (blague tout ça, enseigner c'est avant tout la pédagogie. Pédagogie qu'un expert dans un domaine n'aura pas forcément etc etc)

Ayant énormément de mal à recruter je prend maintenant des jeunes en stage pendant leurs études et je les forme. J'en garde moins d'un quart chaque année. Et certaines années aucun.

Entre ceux qui sont là sans savoir pourquoi ils sont la, ceux qui veulent "devenir riche", ceux qui veulent pas parler aux clients, ceux qui ne veulent pas parler tout court, ceux qui veulent pas faire d'astreintes, ceux qui partent en vacances sans prévenir. C'est vraiment pas simple.

Ensuite j'entends tout à fait que aujourd'hui la relation au travail "des jeunes" est différentes de la mienne. Je n'ai pas de problème avec ça.

Bref le sujet c'était les backups :) par les jeunes c'était mieux avant, moi de mon temps etc.

Qu'il y ait des gens qui innovent c'est super et c'est tant mieux. Par contre moi qui dois faire tenir de la prod de plus en plus grosse avec des coûts de maintenance de plus en plus faible je préfère me reposer sur des technos stable, très stable. Par exemple debian et postgres.

Pour ceph j'ai attendu 5ans avant de le passer en prod. Pour kubernetes, 3 ans. Pour le framework js front pratiquement 10ans et pour celui que j'ai choisi (vuejs) 5ans.

Bref l'innovation c'est nécessaire. Passer en prod des produits hype et pas terminé c'est dangereux.

Apprendre du passé bien sûr, être persuadé que les difficultés d’hier sont exactement
les mêmes que celle d’aujourd’hui c’est vraiment être vieux con et ignorant.

Et me faire dire ce que je ne dis pas c'est … ?

Je ne dis pas que tout était mieux avant, que uniquement les anciennes technos sont bonnes. Sinon je n'aurais pas dans ma stack kubernetes, ceph ou kafka. Jamais de la vie.

Je dis simplement que pour faire des choix et surtout pour ne pas ré inventer cette satanée roue il est pertinent de regarder ce qui a été fait avant et qui fonctionne pour éviter de faire des mauvais choix. Par mauvais choix j'entends des choix basés sur des technos hype propulsé par une tonne de communique qui sont très souvent difficiles et donc très couteuses à maintenir en prod et rarement pertinente. Genre mongodb.

bonjour,

je suis surpris de voir que ce mot n'apparait pas dans les commentaires. En tant que responsable de la prod de plusieurs boites c'est la première chose à laquelle on réfléchit avant de choisir un produit.

Comment on le backup, on le restaure, on le monitore, on le réplique. Est-il possible de faire du PITR ? Il est nécessaire de pouvoir faire tout ça facilement.

Par exemple ces derniers temps je récupère des clients avec mongodb et microservice en js.

Question : comment on backup mongodb. Eh bien on peut pas de ce que j'en comprends, enfin si on peut mais c'est pas consistant. Alors la nuit on passe le base en read only, on snapshot les fs, on repasse en read write et on copie les données sur le serveur de backup. Et au lieu d'avoir un seul fichier, j'en ai autant que de noeud de la base. J'ai l'impression de retourner en 2004 avec mysql …

Mais alors, pourquoi mongodb ? Qui y a-t-il comme données dans cette base pour nécessiter un mongodb ? Une simple base utilisateur qui permet l'authentification à l'application en question. Les dev de cette application ont donc réécrit ldap en js.

Point vieux con : les jeunes n'ont plus aucune culture en informatique, ils ne connaissent que la surface et les trucs à la mode. Jamais il ne se disent que avant eux on a déjà résolu tout ces problèmes. L'arrivée de chatgp n'ajoute rien de bon à tout ca.

Bref pour terminer : le bon outil pour le bon besoin. C'est primordial. Quiconque a déjà bricolé avec un couteau suisse comprendra.

hello

je rebondis sur la partie IA et notebooks Jupyter. Depuis 2015 je bosse avec des "data scientist". Leur principal point commun c'est d'utiliser et donc de livrer leur code sous forme de notebooks Jupyter. J'avais donc, à priori, deux voie pour passer leurs livrables en production. Soit apprendre à des ds à coder correctement et à livrer du code que l'on peut directement mettre en prod (ils adorent les csv avec des chemins en dur …).

On ne peut pas dire que ça a échoué, on dira que ça n'a pas marché. Alors on a décidé de prendre des dev pyton  pour faire de la datascience. Ça a marché un temps. Mais depuis deux ans on fabrique nos propres algo de traitement du langage et là ça coince. Un dev python ne sait plus faire.

Résultat des courses j'ai deux équipes une de ds qui nous livre du code pas vraiment utilisable et une équipe de dev python qui ré-écris toute ou partie du code pour la faire rentrer sur la plateforme.

Pour limiter les réécritures on essaie de packager un maximum de chose. En particulier nos structures de données et l'accès aux dites données, pour enfin ne plus voir de chemin en dur vers un csv …

Et je termine donc : nous utilisons pyenv, pdm et docker pour le dev, comme ça on isole bien notre env dans docker. Et gitlab pour la publication de nos packages.

Je code avec vi depuis 1997. Aujourd'hui c'est même mon métier et ça marche très bien. Python/Django/vuejs/k8s.

Je ne manque de rien 🤗

hello,

je ne crois pas l'avoir vu mais :b string avec string étant tout ou partie d'un nom de fichier permet facilement de circuler entre les buffers. Ajouter :vs :sp pour cinder l'affichage et je n'ai besoin de rien de plus. A oui :e file pour ouvrir un fichier.

vim c'est bien pour coder mangez en :)

C'est une question difficile. Et encore mon fils est petit. Il n'a que 9ans. Dès le collège ça deviendra encore plus compliqué parce que pour le moment il n'y a pas dans son école d'interaction sociale via les réseaux.

Pour le moment j'ai réussi à faire en sorte que l'écran, quel qu'il soit (tv, console, pc, téléphone) soit une activité que l'on fait ensemble. On choisit un film, une série, un jeu vidéo et on le fait ensemble. On joue à ingress ou à pokémon go sur le téléphone mais dehors.

De mon point de vue le problème n'est pas l'écran en lui-même mais plutôt ce que l'on en fait. Si c'est pour les mettre devant loft story, tfou ou jouer à gta à 10ans parce que comme ca ils sont tranquilles c'est non. Si c'est pour faire un truc ensemble et de leur âge (it takes two sur ps4, porco rosso ou astérix et cléopatre) c'est oui.

Quand il joue seul il fait du lego, du découpage, il invente des jeux, crée des labyrinthes bref, quand il est seul il n'y a pas d'écran.

Seule entorse, une fois la table mise il a 20min pour regarder un épisode de pokémon pendant que le repas cuit.

Pour la découverte, ici on utilise knative et Kafka pour faire ça. J'avoue ça juste marche parfaitement. Mais je vais quand même regarder ça. Merci.

Vim c'est bien

et on teste les backup

c'était le sens de ces mots :)

• on backup
• on réplique
• on redonde
• on monitore

et on teste les backup

• backup qu'on réplique
• qu'on redonde
• qu'on monitore

ceph + borg

Ceph , cephfs et S3 c'est excellent pour faire ça. J'ai le même genre de problèmatique que j'ai résolu avec une stack ceph + k8s + kafka.

Effectivement ça demande des compétences mais quand il faut passer en production un pipeline de traitement de données il faut des compétences.

des bisous des bisous des bisous :)

Pas sûr 3 DC dans 3 zones différentes. Si ta baie cramé tu perds tout.

Certes mais ton disque que tu exposes en iscsi est sur une machine. Si cette machine disparait tu perds ton disque.

L'avantage de ceph est que ton disque (rbd, nfs, iscsi, samba, whatever) et toujours disponible tant que ton cluster fonctionne.

Avec le setup qu'on fait on peut perdre les deux tiers des serveurs sans perdre de données. Chaque block est répliqué trois fois.

hello

je n'aime pas trop faire ma pub ici, ou ailleurs d'ailleurs. On est pas particulièrement en recherche de client en ce moment. Et surtout on cherche d'abord des gens sympas avec qui bosser. Mais on peut discuter sur oau[at]nmlq.fr

Bonjour,

c'est très exactement ce nous faisons :)

oau

c'est ce que je faisais avant avec des baies de disques. Et bien c'est un boulot à plein temps et à part entière. Sans compte le prix du hardware et l'impossibilité de vraiment savoir ce qu'il se passe dans la baie.

depuis que je fais du ceph le storage j'y pense plus.

• la couche base de données avec N instances permet de basculer un master vers un réplica en cas de perte du master plus rapidement que de démonter un fs et le remonter ailleurs puis de relancer la base de données. Ca permet aussi de répartir les lectures sur plusieurs instances de la db

• la couche ceph permet d'avoir une solidité plus importante qu'un simple fs et permet de remonter un disque d'une machine à une autre.

Donc :

• si je perd un master db je bascule sur un réplica. C'est rapide, pratiquement pas de coupure

• je peux répartir mes lectures sur plusieurs machine

• quoi qu'il arrive je retrouve toujours mes données sur le disque tenu par ceph, modulo le temps de démonter le fs puis de le remonter ailleurs et de relancer la db.

Tu as raison. Mais avec k8s c'est plus simple. Je ne ne gère pas l'allocation des noeuds du cluster pg sur les nodes du cluster k8s, ni la création des lv et des fs. Je n'ai pas besoin de savoir quelle instance est où ni sur quel fs etc.

Si k8s à besoin de bouger un noeud de la base sur un autre noeud du cluster k8s c'est possible. Que ce soit pour pg ou n'importe quoi d'autre d'ailleurs.

D'autres part toute la conf de pg est dans un yaml dans ma cicd. Nombre de noeud du cluster pg, user, db, config de la base, la taille des disques, le backup, le streaming des wal dans S3, le type de réplication que je veux pour chaque noeud. Je peux créer une base à partir d'une autre, à un instant t juste avec un yaml. Parfait pour tester une version de dev avec des vraies données.

Bref pour pg, comme pour tout le reste j'ai de l'infrastructure as code. En vrai techniquement ça change rien. Mais en standardisant et en automatisant à outrance on peut gérer énormément de service.

La plupart de nos clients sont des applications en SaaS ou des algorithmes de traitement de données. J'ai une stack redis, dB, front www JS et serveur d'applications backend genre python,ruby ou java. J'injecte l'id du client et le type de plateforme que je veux. Production, staging, dev, une branche en particulier etc. Et je déploy via la cicd.

Que j'ai 10 fois l'application, ou 10 000 fois ça change rien. K8s se débrouille pour tout déployer en fonction des contraintes que je lui donne. Essentiellement de ne pas démarrer deux noeuds de base pg dans la même zone.

Quand c'est des algorithmes de traitement de données je peux avoir 10 algorithmes différents qui tournent en parallèle sur les mêmes données (merci Kafka) et qui remplissent 10 cluster pg différents. Juste en me basant dans ce cas là sur le nom de la branche git. En vrai on fait l'administration pratiquement uniquement avec git. Et c'est la cicd qui gère.

Enfin quand je n'ai plus de place ou plus de ressources sur le cluster, j'ajoute des serveurs.

Oui ceph tient très bien la charge et oui j'ai des pg et des MySQL dessus. Environ 900 pg et 150 MySQL. Par contre attention la différence de performance entre un nvme et ceph est énorme. Il faut donc bien configurer pg, ceph et bien faire attention aux requêtes que l'on fait.

Dans les cas extrêmes on peut repasser directement sur les disques locaux. Tout en gardant le tout dans k8s. On perd juste un peu de flexibilité. Les pods étant fixés sur un node particulier.

Ceph fournit aussi un fs de type S3 très utile pour le traitement de données.

Un post de fichiers dans S3 trigger une notification dans Kafka. Ensuite les données sont traités. Le gros avantage c'est que tout se fait via k8s par l'intermédiaire de knative et donc de config yaml directement dans la cicd.

Oui effectivement c'est aussi notre métier. Mais il ne faut pas croire que pour gérer ton infra, gafam ou pas, k8s ou pas, tu n'as pas besoin de compétences. La prod c'est un métier.

Ensuite oui les gafams sont intéressants quand tu ne t'en sers pas tout le temps.

Mais c'est un piège. Parce que si au début tu ne t'en sers pas tout le temps ça finira par arriver avec la croissance de ta production et c'est la que les coûts explose.

En avant vente on présente notre modèle comme un log. Plus cher au début mais dont la croissance sera un log. Là où chez un gafam c'est au mieux linéaire. Le plus souvent exponentiel. Surtout si on utilise beaucoup de leurs services à la demande.

Le monitoring c'est mon métier depuis plus de 20ans et j'ai mes outils. Effectivement monitorer k8s avec les outils officiel est une plaie.

Pour les mises à jour franchement j'ai connu bien, bien pire. Websphere, oracle et même redhat c'était bien pénible. Avec le temps c'est devenu une routine de faire les maj. Et ça se passe plutôt bien.

Concernant les mises à jour des versions de l'API des ressources, kubernetes te préviens longtemps avant que ça va changer et vraiment tu as tout le temps d'anticiper. Et c'est souvent pas grand choses.

Je fais de l'administration de serveur Linux depuis la fin des années 90 et de la prod depuis le début des années 2000. On a aujourd'hui des outils qui marchent tellement bien et tellement simple d'utilisation que c'est devenu anecdotique de faire l'administration. Je pense à postgres ou à ceph par exemple. Un vrai bonheur. En plus de k8s bien sûr.

On installe tout avec l'API d'ovh puis avec des playbook ansible. Il faut moins d'une heure pour ajouter un noeud avec tout le confort moderne. Monitoring, sssd, LDAP pour k8s, conf réseau (vlan k8s, ceph, adm, monitoring, backup, vpn vive le vrack) et ajouter le nouveau noeud dans ceph. En vrai le plus long c'est d'attendre la disponibilité des serveurs et la synchronisation de ceph. Sur les grosses machines il faut des fois plusieurs mois pour les avoir.

Surtout pour le client le coût est connu à l'avance. J'ai migré des clients de chez gcp avec des factures qui pouvait varier de 50% d'un mois sur l'autre. Et chez les gafams il y a aucun support malgré les tarifs exorbitants. T'es planté ? débrouille toi.

Alors qu'est chez nous, avec le prix de la machine plus notre coût d'administration on reste moins cher d'environ 50% par rapport à gcp ou aws. On ne fait pas de azure.

Je pense sincèrement être arrivé sur un plateau qui devait tenir un moment. Je n'ai besoin de rien de plus. OVH, Debian, k8s, ceph, vrack, Kafka, gitlab, python, nuxtjs et les quelques outils de glue autour de ça et je dors très tranquillement.

Le client qui prend toute ses machines sur sbg alors qu'on lui dit d'en prendre une sur Roubaix une sur Gravelines et une sur sbg.