Posté par oau .
En réponse à la dépêche Harbor 2.0.
Évalué à 1.
depuis 2014 les choses ont bien changé :
petit bench de mon cluster. 7 nodes avec des ssd de 1to et un lien de 2Gbps entre chaque. Sur chaque nodes tourne ceph mais aussi ma prod k8s
montage et formatage de l'image ceph.
rbd map kube/test
mkfs.ext4 /dev/rbd1
mount /dev/rbd1 /mnt/
Un petit dd dedans pour les perf en écriture :
dd if=/dev/zero of=test bs=8192k count=1000 oflag=direct
1000+0 records in
1000+0 records out
8388608000 bytes (8.4 GB, 7.8 GiB) copied, 71.8563 s, 117 MB/s
Les performances de ceph dépendent clairement du réseau. Plus gros sera le réseau plus ca ira vite. Il faut aussi bien faire attention au disques choisis.
Posté par oau .
En réponse à la dépêche Harbor 2.0.
Évalué à 1.
Je pense qu’on s’est mal compris. Le posgresql en sus qui tourne dans ceph et qui est un replica de la production qui tourne sur des disques en local n’est là que pour avoir la possibilité d’en faire un snapshot.
Mais tout est géré par k8s. Aussi bien le cluster de postgres de prod qui est géré par helm et qui a un Persistent Volume local géré aussi par k8s, et le postgres en sus qui est une image docker que j’ai faite mais qui est géré aussi par k8s (dans un statefulset) et qui a un Persistant Volume dans ceph et enfin les Snaphot de la base dans ceph sont eux aussi géré par k8s via la fonctionnalité de Snapshot de k8s. Je ne fais absolument rien hors de k8s.
Pour clarifier la gestion sur stockage dans k8s. Il y a plusieurs choses.
Le plus simple c’est le stockage éphèmere. Le container écrit sur le disque local du node qui le fait tourner. Quand le container s’arrête tout est perdu.
Ensuite on a la couche stockage persistant. On a d’abord un type storageclass. Dans mon cas j’en ai deux. Une locale et une pour ceph.
Pour la locale je dois créer à la main les lv et les assigner ensuite dans un Persistant Volume (PV), je ne crois pas qu’on puisse encore lui donner un vg et débrouille-toi pour créer les lv.
Pour ceph c’est plus simple. Je crée un Persistant Volume Claim (PVC) qui va créer automatiquement le PV avec la bonne taille.
Avec tout ça il y a un volumesnapshotclass et un volumespnashot qui vont me permettre de créer des snapshot de mes PVC et de les transformer en PV. Ça m’évite de copier 50G de base quand j’ai besoin d’une nouvelle pile pour tester une branche de notre dev.
Là je snapshot mon postgres qui tourne dans ceph et je démarre un nouveau postgres sur le PV créé à partir du snaphost. Merci à postgres d’être capable de se relancer proprement à partir d’un snapshot totalement inconsistant. J’ai vu qu’une commande fsfreeze existait mais pour le moment ça marche.
Donc maintenant j’ai mon pvc.
Si je l’utilise dans un déploiement tous mes pod vont pouvoir y accéder. J’ai donc un volume partagé entre tous mes pods.
Si je l’utilise dans un Statefulset un seul pod pourra utiliser mon pvc et le nom du pod sera fixe.
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.
Je ne suis pas d’accord avec ça. Depuis l’arrivée des Statefulset ce n’est plus le cas.
Tu ne peux pas avoir un soft qui se créait sa propre base de donnée et l'utilise (par > exemple avec helm).
Si tout à fait. C'est le cas de gitlab, de owncloud par exemple. Tu leur donnes le nom de ta storageclass et ils se débrouillent.
Posté par oau .
En réponse à la dépêche Harbor 2.0.
Évalué à 1.
En vrai ça dépend de la taille de ton cluster ceph. Si comme moi il est tout petit en stockage (30to) et moins petit en node (7 nodes) effectivement on s'en fout.
Mais sur un cluster plus gros ceph peut être assez violent quand il se reconstruit sur la consommation des ressources. Principalement parce que souvent les gens mettent 3 machines avec 48 disques de 12to. Et quand une machine meurt ou reboot sans le petit noout qui va bien et bien il faut reconstruire beaucoup de données. Si tu as sur les mêmes machine ta prod k8s elle va en souffrir.
Posté par oau .
En réponse à la dépêche Harbor 2.0.
Évalué à 1.
C'est vrai. Mais je suis très stressé sur la pérennité des données que je reçois. Alors je réplique partout et je backup tout le temps. Mon cluster ceph est d'ailleurs répliqué sur un autre DC au cas ou …
Pour tout dire je reçois mes flux de données sur un serveur. Je transfère les données brutes dans l'object storage de ceph et dans kafka, qui lui a sont propre moyen de réplication et a qui j'ai donné des disques dans ceph. Donc encore répliqué. Et je retiens les données dans kafka indéfiniment.
Ensuite ça passe dans un ETL qui envoie ça dans une base postgres avec 4 réplica. 3 sur des disques locaux géré avec stolon et 1 dans ceph. 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.
Au final mes dev peuvent avoir en 2/3min une pile applicative complète et à jour sur laquelle développer juste en créant une nouvelle branche.
Et enfin la sortie de l'ETL va aussi dans EKS de même que tout mes logs pour faire un peu de data visualisation avec kibana. Mais sur ce point je ne suis vraiment pas au top.
Posté par oau .
En réponse à la dépêche Harbor 2.0.
Évalué à 1.
Pour pouvoir garder tes données ? Si j'installe un elastiksearch je veux pouvoir conserver mes données si la machine disparaît pour une raison ou une autre. Si je n'ai pas de fs partagé les données sont en local. Ou dans un stockage éphémère qui disparaît quand le pod redémarre ou dans un Persistent Volume local qui disparaîtra si la machine disparaît. Qu'elle crashe, qu'elle disparaisse du réseau, que le disque meure etc.
Posté par oau .
En réponse à la dépêche Harbor 2.0.
Évalué à 1.
Je n'ai encore vu si la modes des clusters k8s était de séparer serveur de calcul et serveur de fichiers > (de volumes, SAN…), ou bien de faire n machines identiques, avec partage distant ou non des fichiers par > une techno d'accès réseau.
Ça ce n'est qu'un question d'argent. Si tu es riche tu as 3 machines maîtres k8s et 3 autres monitor pour ceph. N machines pour tes données cephs (OSD) et N autres machines pour k8s (les computes). Si tu es pauvre comme moi tu as 7 machines identiques qui font tout :) et vraiment pour mon usage c'est tout à fait bien.
Posté par oau .
En réponse à la dépêche Harbor 2.0.
Évalué à 1.
Effectivement pour mes bases je n’utilise pas ceph. j'utilise stolon que je déploie avec helm et qui gère la réplication de postgres. Postgres qui tourne sur le stockage local qui sera quand même toujours plus rapide que ceph.
Ceph c'est plus pour les disques de elastiksearch, prometheus, pour notre owncloud et comme object storage. Je l'utilise aussi pour les applications que je déploie directement avec helm comme gitlab ou un peu à la mains comme zimbra.
Posté par oau .
En réponse à la dépêche Harbor 2.0.
Évalué à 2.
Ceph n'est pas une obligation mais avoir un stockage partagé oui. Tu peux utiliser autre chose. HDFS je n'ai jamais utilisé. Mais vraiment ça ne me donne pas envie, de loin ca à l'air particulièrement lourd. Sur la ML de ceph beaucoup de gens cherchent à remplacer HDFS par ceph.
Posté par oau .
En réponse à la dépêche Harbor 2.0.
Évalué à 2.
C'est la partie qui exécute les commandes kubectl, typiquement dans un .gitlab-ci.yaml ?
c’est en partie ça, on parle aussi d’infrastructure as code. C’est un moyen de garder une consistance entre une infra décrite avec du code et la réalité.
J'ai l'impression aussi que l'installation de kubernetes lui-même n'est pas simple. Par exemple, si on
veut se faire un cluster à soi chez un fournisseurs de bare-metal (ovh) ou de VM.
C’est ce que je fais chez OVH. Kubernetes c’est 3 binaires en go et une base etcd. C’est donc assez simple. À installer et à mettre à jour.
La partie pas nécessairement simple est au niveau du réseau quand on veut bien tout séparer dans différents vlans. Il faut assi bien faire attention aux api qu’on utilise dans ses yaml. Il y a des changements lors des montés de version qui peuvent casser les déploiements. Dans mon souvenir les déploiements ont changé entre la version 1.15 et 1.16, c’est passé de beta à stable. Après c’est juste une ligne à changer dans son yaml. Mais sur le coup ça surprend.
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.
Mais dans l’ensemble ce n’est pas si compliqué que ça quand je pense aux usines à gaz que j'ai dû installer pour "des grands comptes". Ceph est incroyablement stable, simple, cohérent, performant et plein de fonctionnalité. Pour mon utilisation c’est vraiment un point final à la gestion du stockage. Je dirais la même chose pour k8s.
Après je ne propose pas à mes clients de faire la même chose chez eux. Il est tellement simple de déployer un cluster k8s chez google, aws ou azure que je ne suis pas sur que le faire chez soi ait du sens si on parle de simplicité. Par contre niveaux coût par mois pour le moment il semble que c'est quand même bien moins cher de le faire soi-même. On garde aussi la main sur le hardware qu’on utilise.
Avant de partir sur un type de serveur chez ovh j'ai passé un bon mois à tester les différentes offres. Surtout au niveau des disques SSD/NVME. Ceph est particulièrement tatillon sur les disques.
Au final k8s et Ceph ont totalement changé ma tripple vie de dev, de datascientist et d’admin. Avant je faisais 50 % d’admin, 40 % de dev et 10 % de datascience. Aujourd’hui je fais 10 % d’admin, 40 % de dev et 50 % de datascience. Mon unique outil d’admin c’est git. Et c’est un admin de trèèès longue date qui dit ça ;)
Posté par oau .
En réponse à la dépêche Harbor 2.0.
Évalué à 2.
Bonjour,
effectivement, je suis en plein dedans. Autant je pense que la couche container avec ou sans docker et orchestrateur avec kubernetes est stable et on trouve un kubernetes chez tous les hébergeurs de cloud.
La partie déploiement ne l'est pas du tout. Et pour le moment je ne vois rien qui se détache réellement.
Helm c'est bien pour déployer des applications qui existent déjà. Je le vois comme le apt du cloud. Mais pour déployer sa propre application je trouve ça trop lourd. Il y a terraform dont beaucoup de gens parlent, mais apprendre encore un langage relativement neuf c'est pénible et pas nécessairement pérenne. Je n'ai pas encore regardé kompose ou crossplane mais j'ai un faible pour pulumi. C'est du python et j'aime bien le python.
Après pour une application relativement simple avec 2, 3 services, une base de données, un django, un nginx ce n'est pas forcément nécessaire. Un petit coup de envsubst dans le yaml suffit. Mais il est vrai que ma cicd gitlab qui faisait 20 lignes il y a un an en fait 400 aujourd’hui …
Microsoft reconnait avoir toujours été du mauvais côté de l’Histoire
internet, le zune, le windows phone, la xbox, bing, le Kin, Games for Windows, le cloud, HoloLens, rt, vista, millenium, 8, silverlight, msn, powershell, cortana, edge.
J'ai toujours trouvé la police de Windows particulièrement moche. Mais vraiment. Ca fait même partie des raisons de ma transition définitive sous linux.
Récemment j'ai passé du temps sur azure pour un client et j'ai retrouvé cette police… Sur une page web ca choque. J'ai l'impression que la police est particulièrement aliasé. Cest le cas ou c'est moi ? Si c'est le cas pourquoi garder une police aliasé ? C'est toujours la même police sur windows 10 ?
Merci pour ce que vous faites, j'ai travaillé pendant longtemps sur du matériel HP avec des DL et j'ai toujours beaucoup aimé leur robustesse, leur stabilité et leur ouverture vers linux. Si en plus maintenant on va avoir du logiciel libre dedans c'est fantastique.
depuis un an j'utilise nord partout, j'aime vraiment bien. C'est tout doux comme couleur. J'utilise les versions pour vim, gnome-terminal, powerline.bash, i3 et firefox. Bref tout ce que j'utilise au quotidien. Vous pourrez trouver mes dotfiles sur gitlab.com
pandas c'est bien aussi pour faire ce genre de chose et c'est du python. J'aime vraiment bien le python, autant pour faire du traitement de données (scikitlearn, scipy, numpy) que pour passer tout ça à l'échelle avec dask, faire du web avec django, manipuler mon k8s, monitorer tout un tas de truc (il y a toujours une lib en python pour ceph, pour k8s pour du http avec requests) et même faire du javascript (j'ai pas encore essayé). J'ai été un mongeur pendant 10ans je suis un pythoniste depuis 5ans et je regrette pas.
Par ailleurs que ce soit un type sympa, honnête, humaniste ou bien la pire des personnes, ce qui me gêne c'est que ce type à une puissance de frappe de pas loin de 50Milliards de $ sur laquelle il n'existe aucun pouvoir démocratique.
Enfin bref.
Tout changera encore une fois pour que surtout rien ne change. Pour ma part j'ai des salades à repiquer et des tomates à planter.
j'aimerais bien qu'on me démontre cette réduction des coûts. Vu les tarifs pratiqués par les grands fournisseurs de cloud je suis pas du tout sûr que ça coûte moins cher d'avoir son infra chez eux. À moins bien sûr de n'avoir que des vps et encore.
Et je ne parle que des coûts bruts. Sans parler de la dépendance technologique à des services cloud dont on ne sait pas grand-chose.
Pour ma part ma plateforme chez ovh me coûte 500€ HT par mois. Ce qui me donne 5 machines pour un total de 160Go de ram, 40cpu et 12to de ssd et une interco réseau de 2Gbps. J'y fais tourner 400 container docker, un kubernetes et un ceph.
Bof, je suis client depuis longtemps et pour 20 fois moins cher je peux prendre 10fois plus de machines. Blague a part je n'ai que des machines physiques et j'en suis très content je n'ai que rarement des problèmes. Peut être une fois par an. Peut être même pas.
En fait 1 en 2019 avec une coupure de vrack sur roubaix. Mais j'ai aussi des machines sur graveline et strasbourg. Donc pas d'impact.
Aucune coupure en 2018. Et la grosse de 2017 il me semble. Celle qui a coupé tout le web français :)
Marre également de passer pour un extraterrestre ou un débile lorsque tu expliques que Aws/Azur ça ne
t’intéresse pas, c'est du mainframe 2.0, en revanche j'aimerais bosser sur un projet OpenStack.
"En revanche je gère mon propre cluster k8s/ceph chez ovh pour 20 fois moins cher que chez aws/azur, avec des tera de data et non je ne fais pas de hdf (tiens le nom m'échappe) j'ai un postgres et ça me va très bien"
Souvent l'entretien ne va pas beaucoup plus loin. Alors je le dis plus et quand j'ai moins de travail dans ma boite je code au lieu d'aller me vendre ailleurs 'pour voir comment va le monde'.
Il y a trois ans au capitole du libre j'ai dis la même chose à un conférencier. Sa réponse a été lapidaire et salvatrice. "Il existe des endroits ou tout ça existe. Trouve les et vas-y". J'ai fait une rupture conventionnelle avec mon ancienne boite un an plus tard et j'ai monté ma propre "start-up".
"Il faut" trouver les bonnes personnes et se lancer. C'est pas facile. Mais c'est jouissif :)
toute le monde cotise à 28% de son salaire (net + cotisation patronale + cotisation salariale). On plafonne à 120k€/an les retraites vers le haut. On limite le taux de remplacement à 80% pour les plus bas salaire avec un minimum à 1000€ et un taux de remplacement de 60% pour les plus hauts salaires. Et si il manque des thunes, on prend un petit peu plus de pib pour financer. Et bien sur retraite pleine à 60ans.
Ah oui mais non on me dit que les 5% des français à plus de 10k€/mois veulent pas. Alors puisqu'il veulent pas on va faire comme ils disent. Parce que moi petit français. Je suis bête. Je comprend pas. Le monsieur là avec le costard qu'il s'est payé en traversant la rue il sait mieux que moi ce qui est bon pour luimoi ou lui. Arg je sais plus….
[^] # Re: container compatible OCI ?
Posté par oau . En réponse à la dépêche Harbor 2.0. Évalué à 1.
depuis 2014 les choses ont bien changé :
petit bench de mon cluster. 7 nodes avec des ssd de 1to et un lien de 2Gbps entre chaque. Sur chaque nodes tourne ceph mais aussi ma prod k8s
montage et formatage de l'image ceph.
rbd map kube/test
mkfs.ext4 /dev/rbd1
mount /dev/rbd1 /mnt/
Un petit dd dedans pour les perf en écriture :
dd if=/dev/zero of=test bs=8192k count=1000 oflag=direct
1000+0 records in
1000+0 records out
8388608000 bytes (8.4 GB, 7.8 GiB) copied, 71.8563 s, 117 MB/s
Les performances de ceph dépendent clairement du réseau. Plus gros sera le réseau plus ca ira vite. Il faut aussi bien faire attention au disques choisis.
[^] # Re: container compatible OCI ?
Posté par oau . En réponse à la dépêche Harbor 2.0. Évalué à 1.
Je pense qu’on s’est mal compris. Le posgresql en sus qui tourne dans ceph et qui est un replica de la production qui tourne sur des disques en local n’est là que pour avoir la possibilité d’en faire un snapshot.
Mais tout est géré par k8s. Aussi bien le cluster de postgres de prod qui est géré par helm et qui a un Persistent Volume local géré aussi par k8s, et le postgres en sus qui est une image docker que j’ai faite mais qui est géré aussi par k8s (dans un statefulset) et qui a un Persistant Volume dans ceph et enfin les Snaphot de la base dans ceph sont eux aussi géré par k8s via la fonctionnalité de Snapshot de k8s. Je ne fais absolument rien hors de k8s.
Pour clarifier la gestion sur stockage dans k8s. Il y a plusieurs choses.
Le plus simple c’est le stockage éphèmere. Le container écrit sur le disque local du node qui le fait tourner. Quand le container s’arrête tout est perdu.
Ensuite on a la couche stockage persistant. On a d’abord un type storageclass. Dans mon cas j’en ai deux. Une locale et une pour ceph.
Pour la locale je dois créer à la main les lv et les assigner ensuite dans un Persistant Volume (PV), je ne crois pas qu’on puisse encore lui donner un vg et débrouille-toi pour créer les lv.
Pour ceph c’est plus simple. Je crée un Persistant Volume Claim (PVC) qui va créer automatiquement le PV avec la bonne taille.
Avec tout ça il y a un volumesnapshotclass et un volumespnashot qui vont me permettre de créer des snapshot de mes PVC et de les transformer en PV. Ça m’évite de copier 50G de base quand j’ai besoin d’une nouvelle pile pour tester une branche de notre dev.
Là je snapshot mon postgres qui tourne dans ceph et je démarre un nouveau postgres sur le PV créé à partir du snaphost. Merci à postgres d’être capable de se relancer proprement à partir d’un snapshot totalement inconsistant. J’ai vu qu’une commande fsfreeze existait mais pour le moment ça marche.
Donc maintenant j’ai mon pvc.
Si je l’utilise dans un déploiement tous mes pod vont pouvoir y accéder. J’ai donc un volume partagé entre tous mes pods.
Si je l’utilise dans un Statefulset un seul pod pourra utiliser mon pvc et le nom du pod sera fixe.
Je ne suis pas d’accord avec ça. Depuis l’arrivée des Statefulset ce n’est plus le cas.
Si tout à fait. C'est le cas de gitlab, de owncloud par exemple. Tu leur donnes le nom de ta storageclass et ils se débrouillent.
[^] # Re: container compatible OCI ?
Posté par oau . En réponse à la dépêche Harbor 2.0. Évalué à 1.
En vrai ça dépend de la taille de ton cluster ceph. Si comme moi il est tout petit en stockage (30to) et moins petit en node (7 nodes) effectivement on s'en fout.
Mais sur un cluster plus gros ceph peut être assez violent quand il se reconstruit sur la consommation des ressources. Principalement parce que souvent les gens mettent 3 machines avec 48 disques de 12to. Et quand une machine meurt ou reboot sans le petit noout qui va bien et bien il faut reconstruire beaucoup de données. Si tu as sur les mêmes machine ta prod k8s elle va en souffrir.
[^] # Re: container compatible OCI ?
Posté par oau . En réponse à la dépêche Harbor 2.0. Évalué à 1.
C'est vrai. Mais je suis très stressé sur la pérennité des données que je reçois. Alors je réplique partout et je backup tout le temps. Mon cluster ceph est d'ailleurs répliqué sur un autre DC au cas ou …
Pour tout dire je reçois mes flux de données sur un serveur. Je transfère les données brutes dans l'object storage de ceph et dans kafka, qui lui a sont propre moyen de réplication et a qui j'ai donné des disques dans ceph. Donc encore répliqué. Et je retiens les données dans kafka indéfiniment.
Ensuite ça passe dans un ETL qui envoie ça dans une base postgres avec 4 réplica. 3 sur des disques locaux géré avec stolon et 1 dans ceph. 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.
Au final mes dev peuvent avoir en 2/3min une pile applicative complète et à jour sur laquelle développer juste en créant une nouvelle branche.
Et enfin la sortie de l'ETL va aussi dans EKS de même que tout mes logs pour faire un peu de data visualisation avec kibana. Mais sur ce point je ne suis vraiment pas au top.
[^] # Re: container compatible OCI ?
Posté par oau . En réponse à la dépêche Harbor 2.0. Évalué à 1.
Pour pouvoir garder tes données ? Si j'installe un elastiksearch je veux pouvoir conserver mes données si la machine disparaît pour une raison ou une autre. Si je n'ai pas de fs partagé les données sont en local. Ou dans un stockage éphémère qui disparaît quand le pod redémarre ou dans un Persistent Volume local qui disparaîtra si la machine disparaît. Qu'elle crashe, qu'elle disparaisse du réseau, que le disque meure etc.
[^] # Re: container compatible OCI ?
Posté par oau . En réponse à la dépêche Harbor 2.0. Évalué à 1.
Ça ce n'est qu'un question d'argent. Si tu es riche tu as 3 machines maîtres k8s et 3 autres monitor pour ceph. N machines pour tes données cephs (OSD) et N autres machines pour k8s (les computes). Si tu es pauvre comme moi tu as 7 machines identiques qui font tout :) et vraiment pour mon usage c'est tout à fait bien.
[^] # Re: container compatible OCI ?
Posté par oau . En réponse à la dépêche Harbor 2.0. Évalué à 1.
Effectivement pour mes bases je n’utilise pas ceph. j'utilise stolon que je déploie avec helm et qui gère la réplication de postgres. Postgres qui tourne sur le stockage local qui sera quand même toujours plus rapide que ceph.
Ceph c'est plus pour les disques de elastiksearch, prometheus, pour notre owncloud et comme object storage. Je l'utilise aussi pour les applications que je déploie directement avec helm comme gitlab ou un peu à la mains comme zimbra.
[^] # Re: container compatible OCI ?
Posté par oau . En réponse à la dépêche Harbor 2.0. Évalué à 2.
Ceph n'est pas une obligation mais avoir un stockage partagé oui. Tu peux utiliser autre chose. HDFS je n'ai jamais utilisé. Mais vraiment ça ne me donne pas envie, de loin ca à l'air particulièrement lourd. Sur la ML de ceph beaucoup de gens cherchent à remplacer HDFS par ceph.
[^] # Re: container compatible OCI ?
Posté par oau . En réponse à la dépêche Harbor 2.0. Évalué à 2.
pour tester microk8s est bien plus simple je trouve que minikube qui dans mon souvenir nécessite virtualbox ou kvm
[^] # Re: container compatible OCI ?
Posté par oau . En réponse à la dépêche Harbor 2.0. Évalué à 2.
c’est en partie ça, on parle aussi d’infrastructure as code. C’est un moyen de garder une consistance entre une infra décrite avec du code et la réalité.
C’est ce que je fais chez OVH. Kubernetes c’est 3 binaires en go et une base etcd. C’est donc assez simple. À installer et à mettre à jour.
La partie pas nécessairement simple est au niveau du réseau quand on veut bien tout séparer dans différents vlans. Il faut assi bien faire attention aux api qu’on utilise dans ses yaml. Il y a des changements lors des montés de version qui peuvent casser les déploiements. Dans mon souvenir les déploiements ont changé entre la version 1.15 et 1.16, c’est passé de beta à stable. Après c’est juste une ligne à changer dans son yaml. Mais sur le coup ça surprend.
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.
Mais dans l’ensemble ce n’est pas si compliqué que ça quand je pense aux usines à gaz que j'ai dû installer pour "des grands comptes". Ceph est incroyablement stable, simple, cohérent, performant et plein de fonctionnalité. Pour mon utilisation c’est vraiment un point final à la gestion du stockage. Je dirais la même chose pour k8s.
Après je ne propose pas à mes clients de faire la même chose chez eux. Il est tellement simple de déployer un cluster k8s chez google, aws ou azure que je ne suis pas sur que le faire chez soi ait du sens si on parle de simplicité. Par contre niveaux coût par mois pour le moment il semble que c'est quand même bien moins cher de le faire soi-même. On garde aussi la main sur le hardware qu’on utilise.
Avant de partir sur un type de serveur chez ovh j'ai passé un bon mois à tester les différentes offres. Surtout au niveau des disques SSD/NVME. Ceph est particulièrement tatillon sur les disques.
Au final k8s et Ceph ont totalement changé ma tripple vie de dev, de datascientist et d’admin. Avant je faisais 50 % d’admin, 40 % de dev et 10 % de datascience. Aujourd’hui je fais 10 % d’admin, 40 % de dev et 50 % de datascience. Mon unique outil d’admin c’est git. Et c’est un admin de trèèès longue date qui dit ça ;)
[^] # Re: container compatible OCI ?
Posté par oau . En réponse à la dépêche Harbor 2.0. Évalué à 2.
Bonjour,
effectivement, je suis en plein dedans. Autant je pense que la couche container avec ou sans docker et orchestrateur avec kubernetes est stable et on trouve un kubernetes chez tous les hébergeurs de cloud.
La partie déploiement ne l'est pas du tout. Et pour le moment je ne vois rien qui se détache réellement.
Helm c'est bien pour déployer des applications qui existent déjà. Je le vois comme le apt du cloud. Mais pour déployer sa propre application je trouve ça trop lourd. Il y a terraform dont beaucoup de gens parlent, mais apprendre encore un langage relativement neuf c'est pénible et pas nécessairement pérenne. Je n'ai pas encore regardé kompose ou crossplane mais j'ai un faible pour pulumi. C'est du python et j'aime bien le python.
Après pour une application relativement simple avec 2, 3 services, une base de données, un django, un nginx ce n'est pas forcément nécessaire. Un petit coup de envsubst dans le yaml suffit. Mais il est vrai que ma cicd gitlab qui faisait 20 lignes il y a un an en fait 400 aujourd’hui …
# Même si on est pas vendredi ....
Posté par oau . En réponse au journal Compétition : faites exploser les compteurs du trolomètres. Évalué à 6.
pas taper j’arrête, je suis déjà dehors => []
[^] # Re: Actif Actif, multimaster, bi site?
Posté par oau . En réponse au journal Postgresql, un retour d'expérience. Évalué à 1.
Stolon en prod ici depuis 18 mois. Et franchement c'est top.
https://github.com/sorintlab/stolon
Par contre pas de actif/actif pour autant que je sache. En écriture du moins. Les n replica sont accessibles en lecture.
# Vu qu'on de windows j'aurais une question.
Posté par oau . En réponse au journal Mieux que Santa Barbara : Munich revient aux logiciels libres. Évalué à 3.
J'ai toujours trouvé la police de Windows particulièrement moche. Mais vraiment. Ca fait même partie des raisons de ma transition définitive sous linux.
Récemment j'ai passé du temps sur azure pour un client et j'ai retrouvé cette police… Sur une page web ca choque. J'ai l'impression que la police est particulièrement aliasé. Cest le cas ou c'est moi ? Si c'est le cas pourquoi garder une police aliasé ? C'est toujours la même police sur windows 10 ?
# Tout est css...
Posté par oau . En réponse à la dépêche Sortie de Deno 1.0. Évalué à 3.
http://www.commitstrip.com/fr/2019/03/15/css-css-everywhere/
# Merci !
Posté par oau . En réponse au journal Microcode ouvert sur materiel HPE ?. Évalué à 4.
Merci pour ce que vous faites, j'ai travaillé pendant longtemps sur du matériel HP avec des DL et j'ai toujours beaucoup aimé leur robustesse, leur stabilité et leur ouverture vers linux. Si en plus maintenant on va avoir du logiciel libre dedans c'est fantastique.
# Polices
Posté par oau . En réponse à la dépêche Quelle palette de couleurs pour vos outils ?. Évalué à 3.
vous pourriez partager les polices que vous utilisez ? J'ai du mal à en trouver une qui me plaît. Aujourd'hui j'utilise Source code pro.
# Nord
Posté par oau . En réponse à la dépêche Quelle palette de couleurs pour vos outils ?. Évalué à 4.
depuis un an j'utilise nord partout, j'aime vraiment bien. C'est tout doux comme couleur. J'utilise les versions pour vim, gnome-terminal, powerline.bash, i3 et firefox. Bref tout ce que j'utilise au quotidien. Vous pourrez trouver mes dotfiles sur gitlab.com
[^] # Re: Mon favoRi !
Posté par oau . En réponse au journal Explorer des langages de programmation - édition 2020. Évalué à 1.
justement, pas de for en panda. Enfin à terme :)
[^] # Re: Mon favoRi !
Posté par oau . En réponse au journal Explorer des langages de programmation - édition 2020. Évalué à 1.
pandas c'est bien aussi pour faire ce genre de chose et c'est du python. J'aime vraiment bien le python, autant pour faire du traitement de données (scikitlearn, scipy, numpy) que pour passer tout ça à l'échelle avec dask, faire du web avec django, manipuler mon k8s, monitorer tout un tas de truc (il y a toujours une lib en python pour ceph, pour k8s pour du http avec requests) et même faire du javascript (j'ai pas encore essayé). J'ai été un mongeur pendant 10ans je suis un pythoniste depuis 5ans et je regrette pas.
# Bill Gates est-il vraiment un bienfaiteur ?
Posté par oau . En réponse au journal Les pandémies du futur. Évalué à 4.
https://www.franceculture.fr/emissions/de-cause-a-effets-le-magazine-de-lenvironnement/bill-gates-est-il-vraiment-un-bienfaiteur
Par ailleurs que ce soit un type sympa, honnête, humaniste ou bien la pire des personnes, ce qui me gêne c'est que ce type à une puissance de frappe de pas loin de 50Milliards de $ sur laquelle il n'existe aucun pouvoir démocratique.
Enfin bref.
Tout changera encore une fois pour que surtout rien ne change. Pour ma part j'ai des salades à repiquer et des tomates à planter.
[^] # Re: « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par oau . En réponse au journal Nouvelle vulnérabilité pour les processeurs Intel : l’attaque CacheOut. Évalué à 6.
j'aimerais bien qu'on me démontre cette réduction des coûts. Vu les tarifs pratiqués par les grands fournisseurs de cloud je suis pas du tout sûr que ça coûte moins cher d'avoir son infra chez eux. À moins bien sûr de n'avoir que des vps et encore.
Et je ne parle que des coûts bruts. Sans parler de la dépendance technologique à des services cloud dont on ne sait pas grand-chose.
Pour ma part ma plateforme chez ovh me coûte 500€ HT par mois. Ce qui me donne 5 machines pour un total de 160Go de ram, 40cpu et 12to de ssd et une interco réseau de 2Gbps. J'y fais tourner 400 container docker, un kubernetes et un ceph.
Honnêtement je trouve le prix très raisonnable.
[^] # Re: Marre également
Posté par oau . En réponse au journal Tout cela me fatigue…. Évalué à 7.
Bof, je suis client depuis longtemps et pour 20 fois moins cher je peux prendre 10fois plus de machines. Blague a part je n'ai que des machines physiques et j'en suis très content je n'ai que rarement des problèmes. Peut être une fois par an. Peut être même pas.
En fait 1 en 2019 avec une coupure de vrack sur roubaix. Mais j'ai aussi des machines sur graveline et strasbourg. Donc pas d'impact.
Aucune coupure en 2018. Et la grosse de 2017 il me semble. Celle qui a coupé tout le web français :)
# Marre également
Posté par oau . En réponse au journal Tout cela me fatigue…. Évalué à 10.
"En revanche je gère mon propre cluster k8s/ceph chez ovh pour 20 fois moins cher que chez aws/azur, avec des tera de data et non je ne fais pas de hdf (tiens le nom m'échappe) j'ai un postgres et ça me va très bien"
Souvent l'entretien ne va pas beaucoup plus loin. Alors je le dis plus et quand j'ai moins de travail dans ma boite je code au lieu d'aller me vendre ailleurs 'pour voir comment va le monde'.
Il y a trois ans au capitole du libre j'ai dis la même chose à un conférencier. Sa réponse a été lapidaire et salvatrice. "Il existe des endroits ou tout ça existe. Trouve les et vas-y". J'ai fait une rupture conventionnelle avec mon ancienne boite un an plus tard et j'ai monté ma propre "start-up".
"Il faut" trouver les bonnes personnes et se lancer. C'est pas facile. Mais c'est jouissif :)
# c'est simple
Posté par oau . En réponse au journal Le sujet dont tout le monde a envie de parler, mais qu'on n’ose pas.. Évalué à 10.
toute le monde cotise à 28% de son salaire (net + cotisation patronale + cotisation salariale). On plafonne à 120k€/an les retraites vers le haut. On limite le taux de remplacement à 80% pour les plus bas salaire avec un minimum à 1000€ et un taux de remplacement de 60% pour les plus hauts salaires. Et si il manque des thunes, on prend un petit peu plus de pib pour financer. Et bien sur retraite pleine à 60ans.
Ah oui mais non on me dit que les 5% des français à plus de 10k€/mois veulent pas. Alors puisqu'il veulent pas on va faire comme ils disent. Parce que moi petit français. Je suis bête. Je comprend pas. Le monsieur là avec le costard qu'il s'est payé en traversant la rue il sait mieux que moi ce qui est bon pour
luimoioului. Arg je sais plus….…..