Bonjour’nal
Jusqu’à présent pour mouler sur LinuxFr.org de manière sécurisée moderne avec mon copain TLS Patrick, on est obligé d’utiliser les services de l’EFF IPv4, on est maintenant en 2k17 et ça nous déçoit un peu…
Administrateurs, si vous nous lisez ne voulez‐vous pas déposer une petite redirection 301 de http://linuxfr.org vers https://linuxfr.org ? une… euh… j’imagine que ça ne doit pas être aussi simple qu’une ligne à changer dans un fichier.
Sinon, voulez‐vous bien éclairer ma lanterne fort cabossée ? Qu’est‐ce qui serait limitant pour forcer HTTPS autoriser IPv6 aujourd’hui ?
La bise.
Note originale : Je me suis amusé à débrancher IPv4 sur mon ordinateur pour voir la tête du Web et j’étais surpris de ne pas y trouver _LinuxFr.org (au milieu des géants et des sites geek)._
# Quand quelqu'un l'aura codé
Posté par benoar . Évalué à 5.
Le problème n'est pas l'accès, mais l'applicatif, cf. https://linuxfr.org/suivi/support-ipv6
Tant qu'un codeur en ruby n'y aura pas jeté un œil, malheureusement ça restera bloqué.
[^] # Re: Quand quelqu'un l'aura codé
Posté par Bruno Michel (site web personnel) . Évalué à 10.
Perdu, tu as mal lu les commentaires. C'est tout l'inverse. Comme oumph le dit dans un commentaire :
Pour le code, on sait ce qui ne va pas marcher (on stocke les IP des personnes sans compte qui votent sur les sondages pendant une courte période pour leur montrer les résultats du sondage plutôt que le sondage lui-même). Il faudra le corriger, mais c'est limité comme problème.
Par contre, on est actuellement hébergé chez la fondation Free et elle ne nous donne pas d'IPv6 (en tout cas, pas par défaut, on ne leur pas fait de demande particulière pour ça non plus). Ensuite, il faudrait également gérer le routage vers les containers LXC et les différents services (webalizer, sympa, etc.). Et surtout passer du temps à bien tester tout ça.
[^] # Re: Quand quelqu'un l'aura codé
Posté par benoar . Évalué à 3.
Ah, en fait j'ai même pas lu les commentaires, je l'ai fait de mémoire /o\
Ouai donc ya quand même un peu de code à faire… :-)
Ça c'était le problème dont j'avais également entendu parler. À une époque j'avais proposé (en commentaire) de voir pour que FDN puisse vous faire un tunnel par exemple. J'aurais dû en parler plus concrètement la dernière fois que j'ai croisé oumph, mais je suppose que la flemme a frappé. Ou sinon, j'espère que la fondation Free peut peut-être elle-même vous fournir de l'IPv6, depuis le temps ?…
Je voudrais commencer à troller, mais sérieusement, si possible : une des choses qu'amène IPv6, mais que personne n'a l'air de comprendre, c'est qu'avec Internet partout on était sensé se passer de ces problèmes. Je veux dire, une application se bind sur sa socket (addresse + port), ou se connectait à une autre (addresse + port), et point, elle n'avait rien d'autre à faire. Le problème du routage, ça revenait à l'admin sys/réseau, et chacun faisait bien son boulot sans mélanger les problématiques. Mais depuis sont arrivés les devops avec les VMs et les containers, et tout est parti en sucette : on a tout mélangé, on s'est « abstrait » d'IP en réiventant tout mais en moins bien (vive docker et son archi NATée IPv4… on est en quelle année déjà ?), et maintenant quand il faut déployer en IP « normal » (= v6) bah c'est la grosse galère. Je veux bien regarder s'il y a moyen de brancher ça sans trop tout foutre en l'air, mais ça aurait été beaucoup plus simple, je pense, de migrer vers IPv6 si la containerisation n'était pas passée par là. Après, tu me dis LXC et pas docker, donc j'ai un peu d'espoir que ça ait été bien fait, et je sais que normalement tu codes pas trop mal, alors je vais partir positif pour une fois et pas trop râler !
Par contre j'ai cherché dans le code et je vois pas de trace de sympa ou webalizer : c'est géré en interne ? Y a-t-il moyen de contribuer ?
Oui, c'est sûr.
[^] # Re: Quand quelqu'un l'aura codé
Posté par Seazor . Évalué à 5.
Dans la pratique, je ne peux pas te confirmer si ça se passe bien (je n'ai pas essayé), mais en théorie, ça fait 2 ans que Docker fait de l'IPv6.
https://docs.docker.com/v1.5/articles/networking/#ipv6
[^] # Re: Quand quelqu'un l'aura codé
Posté par Sacha Trémoureux (site web personnel) . Évalué à 10.
Et côté LXC, c'est géré depuis belle lurette. Bien avant que LXC soit devenu stable d'ailleurs.
En fait, le commentaire est un peu approximatif. Les VMs/conteneurs sont arrivés pour répondre à un besoin mais ne changent pas spécialement la façon dont ça se connecte. Ça reste des équipements virtuels nécessitant des IPs.
Là où benoar a raison, c'est la gestion du réseau y'a 2-3 ans dans Docker où c'était effectivement codé assez bizarrement de façon hard-codée dans tous les sens. Mais c'était de l'alpha.
[^] # Re: Quand quelqu'un l'aura codé
Posté par benoar . Évalué à 3.
Besoin que je ne comprends toujours pas vraiment ; enfin, je vois bien les avantages, mais les désavantages qu'on aime bien cacher sous le tapis sont toujours trop grands pour moi.
Oui, mais la question est dans la gestion de la complexité de ton routage, et le découplage du réseau de l'application. Faire « de l'IP », c'est simple : c'est un des protocoles réseau les plus bêtes. Comprendre et bien utiliser l'architecture d'Internet, c'est une tout autre histoire. Quand les personnes qui font du Docker voudront automatiser la configuration réseau de leurs containers, ils vont réinventer DHCPv6, ça nous fera une belle jambe.
Effectivement, c'est ce que j'avais vu à l'époque. Je n'ai pas trop regardé depuis, mais de ce que je lis ça n'est pas la folie non plus.
[^] # Re: Quand quelqu'un l'aura codé
Posté par benoar . Évalué à 1.
Ma critique va dans le sens où ça n'avance pas à grand chose de « faire de l'IPv6 », quand on n'utilise pas l'architecture logicielle de l'Internet : ton « unité » de base reste le container, avec ses API spécifiques. L'API de l'Internet, c'est les socket, et normalement une application a « juste » à gérer son socket pour pouvoir communiquer avec le reste du monde. De son côté, l'admin sys/réseau configure son OS et ses routeurs.
Ici, avec Docker, on a réinventé une nouvelle abstraction, avec son API, etc. Ceux qui savaient comment administrer un OS doivent tout réadapter avec cette nouvelle couche. Alors, pourquoi pas passer vers une nouvelle techno si elle t'apporte des bénéfices, mais perso je vois juste Docker comme un système de packaging qui s'abstrait de la distribution, avec plus de rigidité en échange d'une meilleure reproductibilité. Mais ça amène tout son lot de trucs chiants avec. En particulier pour les admin sys/réseau, je pense que c'est une grosse usine à gaz qui ne leur apporte pas vraiment grand chose.
En fait, Internet est une architecture logicielle qui est tellement plus que ce qu'on l'imagine : c'est comment découpler l'architecture du réseau des applications qui tournent dessus. L'intelligence est aux extrémités (dans les applications), découplée du fonctionnement du réseau (le routage), qui est très bête. Les VMs ou les containers, c'est ramener du couplage sous les applications, et ramener de l'état dans le réseau, à gérer, synchroniser, etc, et ça c'est très compliqué et peu fiable. Je suis quasiment sûr que ces couches ramènes des problématiques de circuit par connexion (avec du conntrack, voire pire, du NAT), et ça personne n'a l'air de comprendre pourquoi c'est mal même si on a la démonstration depuis des dizaines d'années par les telcos que ça scale pas (c'est pas pour rien que les propositions d'amélioration de MPLS vont vers moins d'état dans le cœur du réseau… ils réinventent Internet 40 ans plus tard, mais bon, on n'est pas à une réinvention de la roue près).
[^] # Re: Quand quelqu'un l'aura codé
Posté par Bruno Michel (site web personnel) . Évalué à 5.
Pour le routage des containers LXC et la configuration des différents services (webalizer, sympa), c'est du boulot d'admin/sys. Je n'ai rien à voir avec ça.
[^] # Re: Quand quelqu'un l'aura codé
Posté par Tangi Colin . Évalué à -2.
Docker gère tout type de réseau, par défaut c'est un bridge, mais tu as tout les configurations possibles. T'a perdu ton boulot à cause d'un devops pour être aussi négatif ?
Oui les VM (afin les première version des outils de chez VMware) ne géré que du L2 et on a crée des énormes réseau L2 avec tout les problèmes que ça a amenés mais ce temps la est révolu. Un DevOps "compétant" il te fait du L3 avec du iBGP pour le routage maintenant (et depuis quelque temps déjà).
Après toute migration IPv4 -> IPv6 est compliquée, beaucoup de gens croit que c'est juste la taille des IP qui a grossie mais c'est quasiment tout qui change, y a beaucoup de chose a réapprendre (ARP -> NDP, les multiples configuration possible entre RA et DHCPv6 etc…).
[^] # Re: Quand quelqu'un l'aura codé
Posté par Anonyme . Évalué à 7.
DevOps c’est une méthode de travail, pas un poste.
[^] # Re: Quand quelqu'un l'aura codé
Posté par benoar . Évalué à 6.
Ah non, au contraire, ça me fait plein de boulot en plus, qu'on aurait pu éviter si les devops savaient bosser un peu mieux…
Heu… et ça c'est quoi ? https://tools.ietf.org/html/rfc7348 (peut-être que tu considère ça vieux, je ne connais pas ton échelle de temps) On a ensuite réinventé la mobilité niveau L2 alors que c'était ce qu'apportait IPv6 en mieux, on a maintenant le problème des tables trop grosses donc on va partitionner, comme… du routage ! J'avais vu il y a quelques années un ingé de chez Gandi proposer de l'interconnexion de L2 (avec TRILL et compagnie) pour créer un grand réseau mondial !! Allo, NIH ?
J'aimerais bien en voir… ou pas, parce qu'un dev en général il connaît mal le réseau, ou pire, il croit le connaître bien… Mais le problème ça n'est pas que le dev, c'est toute l'infrastructure autour qui est en train de se complexifier à mort, et qui va lui donner raison d'avoir choisi du container complexe.
Oui bien sûr, c'est plus compliqué que juste la taille. Les problèmes que tu cites sont par contre liés à l'administration du réseau et des machines, et ne devraient pas concerner les devs. Ils auraient théoriquement dû uniquement adapter leur code aux sockets indépendantes de la famille d'adresse (je ne dis pas que c'est facile, hein, mais peu de monde s'en préoccupe).
Ce qui me chagrine, c'est que depuis plusieurs années on a fait une migration d'IPv4 vers une « autre couche » non-standardisée au niveau des développeurs, au lieu de migrer vers une architecture IPv6 (avec des sockets simples), et comme plein d'argent a été mis dedans, on ne va pas vouloir la changer de si tôt ! Et rien n'a été appliqué de l'architecture d'Internet telle qu'elle a été définit (mais sûrement mal expliquée, vu que tout le monde martèle l'histoire de taille d'adresse uniquement). Ce qu'il faudrait enseigner, c'est la version technique du « Minitel 2.0 », et faire comprendre que gérer des VMs/containers ça scale pas, et que c'est juste une nouvelle couche pour devenir l'abstraction proprio (ou presque) de référence au détriment des technologies standard de l'Internet.
Mais en fait je me rends compte qu'à chaque fois que j'en parle, personne ne comprend… s'ils y en a qui voient un peu ce que je veux dire, qu'ils lèvent la main !
[^] # Re: Quand quelqu'un l'aura codé
Posté par Tangi Colin . Évalué à 5.
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. 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, ni la collecte des logs d ailleurs (12 factor apps), après on est d accord qu il sa faut des gens compétents qui gèrent la platerforme. Docker et ipv6 c est des sujets complètement orthogonaux pour moi. 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?
[^] # Re: Quand quelqu'un l'aura codé
Posté par Anonyme . Évalué à 5.
Pas la peine d’aller jusque là. Regarde comment fonctionne Google.
[^] # Re: Quand quelqu'un l'aura codé
Posté par benoar . É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.
[^] # Re: Quand quelqu'un l'aura codé
Posté par Psychofox (Mastodon) . Évalué à 6.
Vous mélangez dev et devops dans vos histoire et l'essentiel de vos peurs / mauvaises expériences tiennent d'une mauvaise organisation plutôt qu'un problème technologique.
Ce n'est pas parce qu'on utilise docker que ce sont les devs qui font les mises en prod et que les sysadmins n'ont pas une vue sur la configuration.
Un developpeur déjà n'a aucune raison de toucher à la prod, il fait ce qu'il veut avec ses containers dans sont environnements de dev mais c'est au sysadmin de spécifier un cahier des charges de ce qui peut être mis en pré-prod et prod (et la conf réseau dans docker en fait partie).
Ce n'est pas uniquement valable pour docker.
[^] # Re: Quand quelqu'un l'aura codé
Posté par benoar . Évalué à 3.
Malheureusement, j'ai rarement (voire jamais) vu une bonne séparation des rôles comme tu le prônes en pratique. C'est dans quel genre de boîte que tu vois ça ?
[^] # Re: Quand quelqu'un l'aura codé
Posté par Psychofox (Mastodon) . Évalué à 3.
Je ne connais aucune boite qui a cette séparation pour tout, car il y'a toujours un poids de l'historique et des applis vieilles de 10ans voire plus qui ont été mise en production à une époque où ce genre de pratique n'existait pas.
Par contre dans les deux dernières boites pour lesquelles j'ai bossé ce type d'organisation était d'actualité pour toute nouvelle appli (et docker est pas assez vieux pour que les devs aient pu prendre de mauvaises habitudes). Après on parle de boites avec un département IT d'environ 100 et 400 personnes respectivement.
[^] # Re: Quand quelqu'un l'aura codé
Posté par BAud (site web personnel) . Évalué à 0. Dernière modification le 17 février 2017 à 21:24.
moui… moi je vois des boîtes où ils croient faire du devops :
bon, l'avantage de devops, c'est que cela permet de promouvoir gitlab / jenkins en dév et en exploit', mais bon ça les fait pas beaucoup plus parler ensemble (même si cela supprime la doc' d'install en word qui a des espaces insécables ou des tirets quadratins qui vautrent comme une grosse loutre dans le terminal au copier/coller tel quel…).
Mais bon, je ne côtoie peut-être pas les bonnes boîtes, ni les bons prestas :/ D'ici 5 ans, tout le monde aura peut-être été formé ?
idem, plus proche de 500 même… (mais avec 2000, il y avait un poids de l'histoire, on va dire)
[^] # Re: Quand quelqu'un l'aura codé
Posté par Antoine . Évalué à 5. Dernière modification le 17 février 2017 à 11:33.
Vraiment ? Franchement, je n'ai pas l'impression que les services logiciels les plus répandus ne soient pas compatibles IPv6. Par contre, des opérateurs ou des fournisseurs d'accès qui ne fournissent pas de connectivité IPv6 correcte, ça existe encore : ici encore, un exemple avec Free qui ne file que de l'IPv4 à Linuxfr (ou encore OVH qui tarde à activer l'IPv6 sur sa dernière génération d'offre VPS). C'est pas la faute à Ruby on Rails, nginx, Docker ou je ne sais quoi.
Je me doute bien qu'il y a quelques bouts de code de-ci de-là qui ne connaissent que AF_INET, mais ce n'est pas le problème dominant.
Corrigeons : très peu de gens se soucient de l'API socket parce qu'ils développent des services réseaux à un plus haut niveau, en se basant sur un canevas logiciel ou au minimum une couche d'abstraction existante. On est en 2017…
[^] # Re: Quand quelqu'un l'aura codé
Posté par benoar . Évalué à -2.
Les services « les plus répandus », oui, mais ceux qui créent des services au-dessus et qui cassent tout en les utilisant mal…
Oui ça c'est vrai que c'est l'autre gros point noir ; je m'y était juste tellement habitué que je n'y fais plus gaffe. Mais ça n'est pas près d'arriver, vu que c'est pour des raisons commerciales : offrir de l'IPv6, c'est ouvrir le marché de se abonnés captifs derrière leur NAT « protecteur »…
C'est le problème dominant de la couche « service » uniquement, mais ça n'est pas rien. C'est également une des excuses des opérateurs : les applications « n'en ont pas besoin », vu que tout est codé pour s'abstraire d'IP à cause des NAT et de réinventer des couches d'abstraction usine à gaz en-dessous.
Oui, mais souvent ils l'utilisent mal… Par exemple, au-delà des sockets pur, savoir utiliser getaddrinfo() : tu vas me dire que c'est abstrait par les framework, mais non, souvent soit ils ne l'utilisent pas, soient ils l'utilisent mal ; on doit normalement itérer sur les résultats pour jauger la connectivité, pour des raisons de transition, de répartition, et de disponibilité. Encore une fois, ces frameworks veulent souvent abstraire ça et rajouter un couche, et foutent la grouille parce qu'ils n'ont pas compris que seule l'application elle-même peut prendre des décisions sur le choix des destinations en fonction de leur atteignabilité.
[^] # Re: Quand quelqu'un l'aura codé
Posté par Antoine . Évalué à 7.
Captifs de quoi ? En général, derrière un NAT, on a accès à tout Internet… Et en l'occurrence, concernant Linuxfr ou les VPS OVH, je ne vois même pas où est censé être ce « NAT protecteur ». Ce n'est pas parce qu'un hébergeur ne fournit pas IPv6 que l'IPv4 du serveur est NATtée.
Tu ne serais pas en train de chercher à inventer des coupables ? Je n'ai jamais vu d'applications qui serait écrites en imposant à l'utilisateur d'être derrière un NAT.
Oui, enfin franchement, j'ai l'impression que tu as rencontré un jour dans ta vie un cas de framework mal codé, et que tu extrapoles à la Terre entière parce que ça t'arrange de croire que tous les autres codent comme des gorets alors que toi, tu as tout compris.
[^] # Re: Quand quelqu'un l'aura codé
Posté par benoar . Évalué à 4.
Tu as accès au Minitel, oui, mais tu ne fais pas partie d'Internet. Donc tu n'auras pas de téléphone SIP qui marche (ton FAI se garde de la concurrence ainsi), tu ne pourras pas t'autohéberger facilement, tu ne pourras pas avoir de service de télévision multicastée (ton FAI te « l'offre », pourquoi aller voir ailleurs ?), etc.
Je pensais qu'on parlait des FAI pour le grand public, quand tu disais qu'ils étaient à la bourre sur IPv6. Je parlais du NAT sur le grand public, donc.
Je n'ai pas dit ça. Je dis au contraire que les applications actuelles sont souvent codées pour s'accommoder du NAT, du coup les opérateurs les utilisent comme excuse pour ne pas proposer IPv6. En oubliant de parler des problèmes pour les applications qui tirent profit complètement de l'architecture d'Internet : SIP, P2P, etc.
Je ne dis pas que « j'ai » tout compris, ça vient de l'IETF. Les applis étaient relativement bien codées jusqu'à maintenant, c'est juste qu'on vient mettre une couche avec les containeurs qui casse souvent ces applications. C'est cette régression que je déplore.
[^] # Re: Quand quelqu'un l'aura codé
Posté par Psychofox (Mastodon) . Évalué à 5.
Je ne l'utilise plus mais mon téléphone SIP Siemens marchait très bien derrière un NAT ipv4. Je crois qu'il utilisait STUN pour cela mais quoiqu'il en soit c'est possible. Le fait que le NAT est utilisé par défaut depuis 2 décennies pour l'acès internet des réseau domestique fait qu'on a depuis mis en place toute sorte de méthodes et que ça n'en fait pas un accès [i]minitel[/i].
Je ne crois pas qu'il faille chercher une sorte de théorie du complot pour le faible support ipv6 par les opérateurs. Je crois que ça tient plus du :
-on a la flemme.
-if it ain't broken don't fix it (ouais c'est "broken" mais bon dans les faits ça marche encore)
-ça coûte cher de mettre en place des trucs, les tester sans rien casser…et surtout assurer le support après de clients chez qui potentiellement il y'aura un truc qui marchera pas car pas supporté.
[^] # Re: Quand quelqu'un l'aura codé
Posté par Seazor . Évalué à 4. Dernière modification le 20 février 2017 à 13:38.
Là où je suis d'accord avec lui, c'est que STUN et d'autres sont des bidouilles plus ou moins propres pour contourner le fait qu'on ne puisse pas utiliser le protocole de base comme prévu au départ (SIP est prévu pour une connexion directe entre 2 IP publiques ou au moins du même réseau. et c'est le cas de pas mal d'autres protocoles "standards")
D'autant plus que pas mal de services en profitent maintenant pour faire payer ce service et en ajoutant au passage une authentification centralisée pour "se rendre utile", alors qu'on pourrait très bien se passer d'eux si on n'avait pas les NATs à contourner.
Exemples : Teamviewer, Plex, j'hésite à mettre Skype…
[^] # Re: Quand quelqu'un l'aura codé
Posté par benoar . Évalué à 2.
Je pense que ton téléphone ne marchera plus aussi bien aujourd'hui, et ne marchera plus dans le futur, à cause des « CGN » et autres conneries pour minitéliser Internet. C'est le problème d'IPv4 : ça va marcher de moins en moins bien ; enfin, pour les protocoles qui exploitent vraiment l'architecture d'Internet. Pour consulter FB, forcément, oui, ça marchera toujours… Mais la non mise en place d'IPv6 va finir de tuer ces usages décentralisés.
Pour tes arguments sur la non-migration, bien sûr qu'ils sont valides et comptent aussi, mais le miens sur « l'ouverture » que permet IPv6 n'est pas anodin non plus, et prend de plus en plus d'importance au fur et à mesure que les premiers deviennent de moins en moins valable.
[^] # Re: Quand quelqu'un l'aura codé
Posté par eingousef . Évalué à 2.
Comment ça se fait ça ? On m'a toujours dit que Free était le seul gros FAI à fournir de l'IPv6 à ses clients
*splash!*
[^] # Re: Quand quelqu'un l'aura codé
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
La Fondation Free (potentiellement une gestion différente de Free FAI) nous fournira de l'IPv6 quand l'équipe LinuxFr en fera la demande.
[^] # Re: Quand quelqu'un l'aura codé
Posté par BAud (site web personnel) . Évalué à 7.
Free a filé de l'IPv6 à TuxFamily.org (on leur a demandé, tout simplement, comme l'indique NoNo< : faudrait peut-être faire la demande :D).
[^] # Re: Quand quelqu'un l'aura codé
Posté par Marotte ⛧ . Évalué à 7. Dernière modification le 17 février 2017 à 11:49.
Tu as l’air d’oublier que le but de docker (ou autres types de conteneurs, ainsi que la virtualisation) c’est la séparation des privilèges et avoir la possibilité de chier des environnements identiques, « isos », à la demande très rapidement. Pouvoir les copier aussi facilement qu’on copie un fichier…
Besoin de 3 environnements de dév et deux de recette ? OK ! Pouf pouf on déploie des conteneurs. C’est impossible de fournir le même service avec des serveurs qui font tourner des applications, de manière classique.
Imagine un hébergeur de services mutualisés…
Après c’est sûr que ça vient avec sont lots de problèmes propres. Quand une faille de sécu est corrigée dans une lib, c’est l’ensemble des tes conteneurs dockers qu’il faut redéployer si tu veux patcher…
[^] # Re: Quand quelqu'un l'aura codé
Posté par Antoine . Évalué à 2.
Je n'ai pas compris ce point… Utiliser BGP pour faire du routage entre des VM, ce n'est pas un peu usine à gaz ? Explications bienvenues :-)
[^] # Re: Quand quelqu'un l'aura codé
Posté par Tangi Colin . Évalué à 1.
Usine à gaz ça dépend du nombre de machine et de "vlan" que tu veux gérer, si tu veux vraiment scaler c est encore ce qui marche le mieux. Les overlays netWork c est moins performant . Si le sujet t intéresse et que l anglais te fait pas peur, regarde par la: http://docs.projectcalico.org/master/introduction/ (ils ont une doc où ils expliquent pourquoi bgp et pas ospf).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.