Reprise du message précédent :

Exactement. OpenShift/Kubernetes dans mon cas avec des sysadmins tout ce qu'il y a de plus classiques.
 

Ça aussi.
 
On a pas attendu la containerization pour ruiner la santé mentale des devs avec Puppet et autres cochonneries.

on est d'accord, j'ai mal tourné ma phrase mais bon ça n'a quand même rien de délirant de le faire, c'est comme installer un IDE avant de commencer à développer, après c'est sûr que rien ne t’empêche d'utiliser notepad ou vim

 
C'est un peu le truc : tous nos process sont orienté waterfall > change management qui prend 3 mois > deploiement dans un data center physique
 
Amener l'outil c'est sympa, mais y'a des mois de change management pour convaincre les centaines de personnes ci-dessus que leur process sent la naphtaline

Reste que ta change request qui prend 3 mois pourrait très bien au final déployer une image Docker, c'est complètement orthogonal.

L'isolation n'est pas toujours un critère important.
Et normalement la migration c'est pas un soucis avec une orchestration digne de ce nom.

 
1/ S.Singh
2/ c'est un truc que je me suis toujours demandé : c'est pas un marché sur lequel vous auriez intéret à aller ?
 

 
C'est ça que j'aimerai bien comprendre, tu peux développer ?
 
 

 
1. OK
2. C'est compliqué. Les SMB sont lents, sans oublier la long-tail toussa. Dans le business, faut pas avoir raison trop tôt. Par contre on peut utiliser notre « marque » (enfin produit) pour pousser là dessus.

C'est rarement l'outil le problème, c'est effectivement la gestion du changement.

tu te crois chez les snowflakes ? ici on fait pas de tolérances

Enfin les smb c’est tellement vaste... c’est aussi des cycles beaucoup plus courts avec des acteurs très rapides et d’autre très lents

j'ai aucune idée de quoi vous parlez

 
Oui je parlais surtout des SMB avec une infra chez eux. Ceux là vont pas bouger rapidement… Après c'est sur que les startup en soft qui commencent maintenant vont pas s'acheter des serveurs

SMB

Small Medium Business ... Pas samba

Super Mario Bros

https://www.reddit.com/r/spacex/com [...] _email_to/

pour du devops de qualité, il faut utiliser replicated.com

haa... si seulement on avait eu un acronyme en français pour parler de la même chose

J'ai du réfléchir 30 secondes pour retrouver PME Donc désolé mais mon marché principal c'est les US, mes lectures sont en anglais et mes « conseils » aussi, donc je préfère pas trop me mélanger (j'ai déjà galéré quelques fois à l'oral a force de jongler entre les abréviations )

moi je Jean-Claude Vandise tout le temps, enfin moins maintenant parce que je parle plus trop français.

edit: avec un formidable "on a forguessé" dans la première semaine d'un nouveau boulot

 
putain, moi je le retrouvais même plus le PME

Vu que les migrations en ligne sont pas (du moins pas encore) possibles ça te force à architecturer ton infra et tes déploiements en prenant compte du fait que tes conteneurs peuvent disparaître à tout moment.
Pour du stateless c'est aussi trivial qu'avec des VMs et et en stateful y a des solutions qui marchent pas mal, avec Kubernetes ça s'appelle stateful sets. Niveau persistence on a du Postgres, Cassandra, Kafka, Zookeeper, ... et tout fonctionne très bien sur notre cluster OpenShift.

Pour du stateless oui la question ne se pose pas, par contre le stateful, ça me parait pas simple (sauf si architecturé de base pour). Bon je manque d'expérience dedans, d'où mes questions simples. Mais c'est pas un peu merdique du stateful en container sur des app legacy ?

Et sur des app toutes neuves, tu fais comment ? Par exemple, on utilise levelDB pour stocker (dans Node), tes données sont pas jetables (la BDD client   ), si ton container disparait ? Et sinon, si tu veux pas perdre trop de temps à m'expliquer (parce que j'y connais rien) je veux bien quelques ressources

wait, les disques sont pas dans le conteneur, donc tu perds pas tes données. T'es dans un problème classique de migration de schéma, de serveur web qui sont pas encore tous au courant du nouveau schéma etc.

 
Hé ben c'est triste

 
Oui mais tes data doivent bien être quelque part (sur l'hôte, bare metal ou VM, peu importe). J'imagine que le but des containers c'est de faire abstraction au maximum de l'endroit où tu démarre ton container, donc la data doit être accessible de partout. J'ai un peu de mal à bien comprendre tout ça sans avoir à regarder des trucs hyper compliqué comme Kubernetes

Franchement, dans le monde du LETQS (Logiciel En Tant Que Service) et des modèles récurrents, surtout sur la partie « Affaires » (business ) il y a très peu de ressources en français Et quand tu vends dans le monde entier, la langue des affaires c'est loin d'être le français…

C'est pas très reluisant comme constat, mais bon, c'est factuel  

je plussoie.

je plussoie aussi

C'est pourtant simple Plam. Tu mets toutes tes bases MySQL dans docker comme OVH et tu developpes des scripts automatiques pour réparer des centaines de base par jour  

C'est une conversation qu'on a déjà eu, je pense que tout le monde est d'accord pour dire que c'est plus facile pour celui qui s'exprime d'utiliser le premier mot qui lui vient. Mais ce n'est pas le plus adapté pour se faire comprendre, en particulier de ceux qui sont étranger au jargon en question.

Et après c'est une gymnastique, je pense que c'est une des deux ou trois compétences utiles que j'ai apprises pendant ma thèse : quand on s'entraîne à parler français c'est difficile au début on a l'impression de se travestir, mais ça devient naturel avec le temps. Après c'est vrai que j'avais une justification professionnelle de faire cet effort je sais pas si je le ferais maintenant, juste pour faire plaisir à trois débiles sur un forum...

Mais la limite est où ? Sur SMB ? LETS ? Graticiel ? MVJ (Machine virtuelle Java)  ? PTHT (Protocole de Transfert HyperTexte) ?

 
Il y'a t-il des études/papiers qui font une comparaison entre les failles des hyperviseurs et celles des conteneurs? Car tous le monde admet que les VMs sont + sécurisés que les conteneurs mais sans le sourcer.

Docker te force à externaliser les volumes persistants donc t'as pas le choix.

Tu devrais demander à ton pote Alex B, c'est un des sysadmins de notre cluster OpenShift, il doit avoir une meilleure idée de la machinerie derrière.
En tant qu'utilisateur je crée un volume, je l'associe à un déploiement et un point de montage et c'est bon, mon conteneur y aura accès à travers NFS.

Ce qu'il dit c'est que c'est dépendant du contexte. Ici il est clair que JVM et HTTP parlent à tout le monde, SMB on était déjà plus dans le même domaine et on voit bien qu'une partie de l'audience ne comprenait pas. LETS je ne sais pas je cherche encore.

C'est quoi LETS ?

Quand on utilise des sigles on a perdu de toutes façons on parle aucune langue.

 
Pas facile de faire une comparaison directe, mais par design, c'est évident. Enfin je parle de ce que je connais plus (talk autour de Xen et Docker pendant moult confs ou entre experts secu divers). Par contre, la gestion des failles est très différente entre Xen et KVM (pas de transparence dans le process chez KVM ) donc ça rend les comparaisons pas faciles.
 

 
Okay donc partage classique derrière quoi (NFS). Merci du hint, j'en parlerai à Alex à l'occaz' (ça fait un bail que j'lai pas croisé, il est pas venu a ma crémaillère de nos nouveaux locaux l'enfoiré )

Tu exagères, Plam l'a défini quelques posts au dessus. Il faut que tu passes au statefull
Et PME n'est pas moins un sigle que SMB

il en reste plus que 2 vu que je te considère comme le premier des 3.

Je suis en train de regarder pour me trouver un écran et ca me gonfle un peu, ces écrans incurvés.
Je cherche :
* une dalle assez grande (32" idéalement)
* réactif (pas plus d'une frame de latence à l'affichage, la rémanence peut être vers les 8ms, ca me dérange moins)
* résolution maximum de 1440p pour du 16/9 ou 1600p pour du 16/10
* plat et pas incurvé
* dalle matte
* edit : moins de 1000€, mais ca devrait pas trop être un souci, vraisemblablement.

en "plus" :
* raffraichissement 144Hz ou plus
* support de freesync (gsync ne m'intéresse pas : j'ai un GPU AMD)

Vous avez des recommandations ?
J'ai vu celui-ci : https://www.ldlc.com/fiche/PB00235414.html
Mais je ne sais pas trop ce qu'il en est de sa latence.

PME c'est de la merde aussi. C'est du jargon journalistique donc on perd pas grand monde du coup j'ai tendance à penser que ça reste mieux que SMB ; mais ça reste du language de feignasse, à la signification branlante et détachée de son sens original (le sens administratif), lui-même étant différent de son sens littéral.