Dire que les conteneurs ça ne scale pas j ai un peu du mal avec ça, suffit de voir les démos hyperscale de mesos pour être convaincu du contraire.
Mais à quoi ça sert de mesurer le nombre de containers que tu peux faire tourner ? Dire qu'on peut mettre 1000 apache sur une machine est une prouesse qui sert à quoi ? Sans containers, tes applis marcheraient aussi bien, voire plus vite, mais personne n'a jamais pensé à faire sa pub sur combien d'applis il pouvait faire tourner sur une machine... Ce que je dis, c'est que les containers c'est souvent coupler l'appli, l'admin, et le réseau, et ça c'est mauvais pour scaler.
Je sais pas comment on fait des conteneurs chez toi mais perso je trouve ça propre et les développeurs gèrent pas le réseau,
Alors ça m'intéresse de savoir comment « ils ne gèrent pas le réseau » : dans la plupart des cas d'utilisation que j'ai vu, les développeurs codent en dur des confs réseau et des paramètres de leurs socket, pour que ton framework de container fasse une traduction (ou une autre forme de configuration indirecte). C'est un état intermédiaire inutile, sujet à bugs, problèmes de fiabilité, etc.
ni la collecte des logs d ailleurs (12 factor apps),
Je ne connais pas, mais qu'est-ce que ça apporte face à syslog ?
après on est d accord qu il sa faut des gens compétents qui gèrent la platerforme.
En effet.
Docker et ipv6 c est des sujets complètement orthogonaux pour moi.
Théoriquement, oui. Je vois juste que les devs qui utilisent le réseau comptent sur son infra de NAT pour corriger leur méconnaissance de l'archi du net. Peut-être qu'en IPv6 ça va changer, mais j'ai quand-même vu des gens promouvoir le NAT IPv6 avec Docker, et ça me fait peur. Tant que les devs ne seront pas sensibilisés à l'architecture d'Internet, on aura des horreurs comme ça, même si en théorie ça doit être orthogonal.
La non migration d ipv4 à ipv6 n est en aucun cas lié au vm mais au fait que on a pas pensé la transition, par exemple combien de temps entre le début des normes ipv6 et les premiers tunelles 6 to 4?
Pardon ? 6to4 (RFC 3056 https://tools.ietf.org/html/rfc3056 ; déprécié, attention !) est apparu en 2001, moins de trois ans après IPv6 (RFC 2460 https://tools.ietf.org/html/rfc2460 en 1998). Il existe pléthore de mécanismes de transition, mais ça n'est pas le problème : chez les devs, très peu de gens se préoccupent de l'abstraction de la famille sur les sockets, et c'est LE problème qui casse tout à chaque fois. Encore une fois, il y a deux catégories de problèmes, et il ne faut pas les mélanger : les histoires d'infra (admin système et réseau), et les histoires d'architecture logicielle (pour les devs). Pour les premiers, comme je disais, il existe plein de solutions différentes. Mais c'est chez les seconds qu'il y a de grosses lacunes. Le problème est qu'on est venu palier ces problèmes chez les devs avec des archis complexes de VMs et containers, qui en plus mélangent les problèmes de déploiements et administration (i.e. les premiers, qu'on devait séparer) ! C'est une erreur qui nous coûte très cher, car on n'est pas près de passer ces archis à IPv6, selon moi.
[^] # Re: Quand quelqu'un l'aura codé
Posté par benoar . En réponse au journal À quand l’IPv6 sur LinuxFr.org ?. Évalué à 5.
Mais à quoi ça sert de mesurer le nombre de containers que tu peux faire tourner ? Dire qu'on peut mettre 1000 apache sur une machine est une prouesse qui sert à quoi ? Sans containers, tes applis marcheraient aussi bien, voire plus vite, mais personne n'a jamais pensé à faire sa pub sur combien d'applis il pouvait faire tourner sur une machine... Ce que je dis, c'est que les containers c'est souvent coupler l'appli, l'admin, et le réseau, et ça c'est mauvais pour scaler.
Alors ça m'intéresse de savoir comment « ils ne gèrent pas le réseau » : dans la plupart des cas d'utilisation que j'ai vu, les développeurs codent en dur des confs réseau et des paramètres de leurs socket, pour que ton framework de container fasse une traduction (ou une autre forme de configuration indirecte). C'est un état intermédiaire inutile, sujet à bugs, problèmes de fiabilité, etc.
Je ne connais pas, mais qu'est-ce que ça apporte face à syslog ?
En effet.
Théoriquement, oui. Je vois juste que les devs qui utilisent le réseau comptent sur son infra de NAT pour corriger leur méconnaissance de l'archi du net. Peut-être qu'en IPv6 ça va changer, mais j'ai quand-même vu des gens promouvoir le NAT IPv6 avec Docker, et ça me fait peur. Tant que les devs ne seront pas sensibilisés à l'architecture d'Internet, on aura des horreurs comme ça, même si en théorie ça doit être orthogonal.
Pardon ? 6to4 (RFC 3056 https://tools.ietf.org/html/rfc3056 ; déprécié, attention !) est apparu en 2001, moins de trois ans après IPv6 (RFC 2460 https://tools.ietf.org/html/rfc2460 en 1998). Il existe pléthore de mécanismes de transition, mais ça n'est pas le problème : chez les devs, très peu de gens se préoccupent de l'abstraction de la famille sur les sockets, et c'est LE problème qui casse tout à chaque fois. Encore une fois, il y a deux catégories de problèmes, et il ne faut pas les mélanger : les histoires d'infra (admin système et réseau), et les histoires d'architecture logicielle (pour les devs). Pour les premiers, comme je disais, il existe plein de solutions différentes. Mais c'est chez les seconds qu'il y a de grosses lacunes. Le problème est qu'on est venu palier ces problèmes chez les devs avec des archis complexes de VMs et containers, qui en plus mélangent les problèmes de déploiements et administration (i.e. les premiers, qu'on devait séparer) ! C'est une erreur qui nous coûte très cher, car on n'est pas près de passer ces archis à IPv6, selon moi.