đŸ“» RDO #9 - Jusqu’oĂč conteneuriser?

:whale: Tu es convaincu qu’il faut utiliser les #conteneurs et @Docker, mais jusqu’oĂč le faire ?

:radio: Nous en parlons justement dans #RadioDevOps avec :
@Benoit Petit
@Erwan Ben Souiden
@Thomas GERARDIN

Tu y dĂ©couvriras dans cet Ă©pisode des pistes sur ce que tu doit, oĂč pas, conteneuriser.

:package: Et toi, qu’est-ce que tu ne conteneurise pas et pourquoi ?

Nous sommes tous curieux et friands de retours d’expĂ©rience. :popcorn:

@Quentin Adam je te dédie cet épisode. :wink:

2 J'aimes

Pour changer je vais me faire l’avocat du diable parce que j’aime bien ça :wink:

Un point important donnĂ© par un intervenant (et avec lequel je suis totalement d’accord) est le fait qu’on peut faire une analogie entre les conteneurs et les machines virtuelles concernant le fait de ne pas gaspiller de ressources.

Bien sĂ»r, l’OS d’une VM consommera un peu plus de ressources mais c’est aussi parce qu’il y a peu d’efforts de fait pour crĂ©er des images de base trĂšs lĂ©gĂšres (une fois tout le bloat enlevĂ© un Linux peut consommer trĂšs peu de ressources).

La VM a quand mĂȘme un certain nombre d’avantages:

  • Isolation plus importante qu’un conteneur.
  • Des outils de dingue (kvm/libvirt par exemple) pour les gĂ©rer. Les migrations live de VM avec libvirt c’est de la magie. A titre d’exemple on a migrĂ© une zone entiĂšre d’un datacenter Ă  un autre sans downtime il y a 2 ans, j’attends de voir la mĂȘme chose avec des conteneurs.
  • On peut aussi gĂ©rer prĂ©cisĂ©ment la RAM/CPU allouĂ©, et mĂȘme configurer des tonnes de trucs comme par exemple la façon dont le disque est utilisĂ© etc

  • Beaucoup d’outillage sur les Cloud pour les gĂ©rer (rĂ©seau, snapshots/restore, tooling comme Terraform, load balancers, autoscaling
), ou mĂȘme avec des outils open source.
  • Linux fournit des outils super performants pour gĂ©rer de nombreux cas de dĂ©ploiements (un exemple avec les sockets systemd, article Ă©crit par un ancien collĂšgue d’ailleurs https://vincent.bernat.ch/fr/blog/2018-systemd-golang-socket-activation), les namespaces/cgroups peuvent s’utiliser facilement Ă©galement avec systemd par exemple etc


De mĂȘme, je n’ai jamais compris le marketing de Docker Ă  base de “on a le mĂȘme binaire sur tous les environnements”. Que sorte de ma CI un conteneur, un paquet Debian, une VM crĂ©Ă©e avec packer
 c’est le cas aussi, personne s’amuse Ă  rebuild ses artefacts entre environnements.

Bref, tout ça pour dire que je pense que les conteneurs sont dĂ©tail d’implĂ©mentation. L’immutable infrastructure, l’infra as code, le monitoring etc
 sont importants. Tout ça est faisable sans conteneurs. Et je rajouterai que si une boĂźte ne sait pas gĂ©rer des VMs, elle aura encore plus de difficultĂ©s Ă  faire du conteneur.

Mais je reconnais aussi que les conteneurs (et Docker, Kubernetes
) sont des technologies intĂ©ressantes. Par contre, j’ai le sentiment que ce que les gens recherchent c’est:

  • Une façon de dĂ©crire des apps (comme les manifests Kubernetes en yaml)
  • Un truc qui orchestre ces apps (ça plante => je redĂ©marre ailleurs, je peux scale up/down
)

Et finalement, que Kube soit partie sur les conteneurs pour rĂ©aliser cela est lĂ  aussi un dĂ©tail d’implĂ©mentation (mais Ă©tait-ce le bon choix ?).

2 J'aimes

Bonjour @mcorbin,

Merci pour ton retour.

NĂ©anmoins tous les arguments que tu donnes sont issue de cas d’usage de VM.
En fait si tu n’a que ces cas d’usage tu n’a pas besoin des conteneurs c’est certain.

Et bien sur les VM ont leur avantages, comme les conteneurs. :stuck_out_tongue_winking_eye:

Certes mais jamais une VM ne sera aussi lĂ©gĂšre qu’un conteneur, pour la simple et bonne raison qu’une VM virtualise l’hardware. MĂȘme les microvm reste plus “lourdes” mais c’est une avancĂ©e importante et je vois dĂ©jĂ  des cas d’usage.

C’est un peu de mauvaise foi comme argument non ?
Bon je sais tu annonces dĂšs le dĂ©part que tu fait l’avocat du Diable mais quand mĂȘme. :thinking:

Un paquet Debian ne peut pas s’installer sur CentOS ou MacOS pourtant.

Docker promet que si ton conteneur tourne sur ton laptop il tournera partout de la mĂȘme maniĂšre car il embarque toutes les dĂ©pendances dont l’application Ă  besoin, il est autosuffisant.

Rappel toi le “ça marche sur ma machine !”, avec le Developpeur qui a PG12 alors que toi en prod ton agrĂ©gat haute-dispo est sur PG10. :wink:

Je prends cet exemple, mais on peut avoir le mĂȘme raisonnement avec la version de PHP ou de Phyton.

Je pense tout le contraire. Ils apportent des solutions Ă  des cas d’usages qui Ă©tait compliquĂ© Ă  rĂ©gler.
C’est un outil supplĂ©mentaire Ă  notre disposition.

Sinon on peut répondre : pourquoi utiliser des VM ont peu tout faire avec des machines physique ! :wink:

Pour moi il y a clairement des cas d’usages pour le baremetal, les VM et les conteneurs.
Le tous c’est de les trouver sans se tromper.

Oui, mais je pense que si on aurait mis l’effort sur crĂ©er de petites images (consommant quelques dizaines de MB de ram pour l’OS) ça aurait Ă©tĂ© nĂ©gligeable dans beaucoup de situations.

Un binaire statique Go est aussi autosuffisant, un uberjar java aussi (avec jlink on peut mĂȘme intĂ©grer la JVM dans le binaire). Ou bien ta CI peut carrĂ©ment sortir une image avec l’appli prĂ©installĂ©e :wink:

Je dĂ©ploie 95 % des apps que je code sur Kubernetes. Pourtant, je n’ai jamais fait tourner dans un conteneur une application que je dĂ©veloppe en local.
Le fait que ma CI produise un conteneur Docker et pas un uberjar ou un .deb est un dĂ©tail, d’ailleurs je pourrai facilement “sortir” mes apps de Kubernetes et les faire tourner sur du bare metal si je le voulais par exemple (suffit de changer le format de ce qui sort de la CI).

Ce que je veux dire c’est que pour moi parler de conteneurs Ă  la phase de dev c’est trop tĂŽt. Une application doit pouvoir selon moi tourner dans diffĂ©rents contextes (conteneur ou non par exemple), comment c’est dĂ©ployĂ© est pour moi Ă  sĂ©parer de la phase de dĂ©veloppement. Quand je code, je veux pas avoir Ă  penser Ă  Docker, Kubernetes ou autre, je laisse ça Ă  la CI.

Par contre pouvoir utiliser docker-compose ou des conteneurs en local pour les tests (comme dĂ©marrer une base Postgres ou un Kafka) lĂ  c’est cool en effet.

C’est exactement mon avis.

Quand les dĂ©veloppeurs ont commencĂ© il y a quelques annĂ©es Ă  venir nous voir avec toute la hype derriĂšre Docker j’étais dubitatif.

J’avais vu l’annonce du produit Ă  l’époque Ă  grand coup de marketing et je n’avais pas notĂ© de grande valeur ajoutĂ©e par rapport Ă  un simple packaging DEB ou RPM, au contraire plus de problĂšmes Ă  anticiper dont les dĂ©veloppeurs n’ont pas conscience notamment du point de vue sĂ©curitĂ© (mise Ă  jour des packages contenus dans l’image Docker, lancement des processus en root la plupart du temps, non comprĂ©hension de ce que lancer un processus en PID1 implique, etc ).

La vrai valeur ajoutée je la vois dans Kubernetes, un orchestrateur universel et extensible qui permet finalement de formaliser la plupart des concepts que nous manipulons dans un langage partagé.

C’est pour moi la fusion ultime des outillages que j’ai pu utiliser pour assurer le fonctionnement des applications (clusters de type Heartbeat, Pacemaker/Corosync et des solutions plus anciennes comme HACMP sous AIX) et des outils de gestion de dĂ©ploiements (Puppet, Ansible, Terraform et autres).

Aujourd’hui il gĂšre nativement principalement des containers mais il peut, Ă  l’aide de composants supplĂ©mentaires, orchestrer des machines virtuelles, gĂ©rer du DNS, fournir des certificats, gĂ©rer des bases de donnĂ©es, configurer de la supervision, proposer du FaaS, etc.

C’est cela qui m’enchante et pas les containers Docker, qui ne sont finalement qu’une mise en oeuvre normalisĂ© et certes assez simple de solutions d’isolation de processus qui existent depuis fort longtemps.

Donc moi je dirai que oui il faut viser Ă  tout containeriser mais sur Kubernetes uniquement.

Je suis d’accord, Kubernetes est intĂ©ressant comme runtime pour pleins de trucs mais tire une Ă©norme complexitĂ©. DĂ©jĂ  Kubernetes lui mĂȘme est complexe (gestion du tls dans le cluster, pod policies, network policies, rbac, rĂ©seau
 ça c’est le quickstart calico par exemple: https://docs.projectcalico.org/manifests/calico.yaml. Faut aimer bgp, vxlan etc
 :D).

GĂ©rer un cluster c’est une Ă©quipe Ă  plein temps (et mĂȘme sur les offres managĂ©s il y a encore beaucoup de boulot).

De plus, imaginons une entreprise qui a une infra classique et décide de passer sur Kubernetes. Généralement ça se passe aussi comme ça:

  • Mince il faut maintenant qu’on utilise fluentd pour les logs car Kubernetes supporte que ça
  • Faut qu’on passe le monitoring sur Prometheus car Kubernetes supporte que ça
  • Notre CI est plus adaptĂ©e, faut tout changer
  • Comment on provisionne le cluster ?

De plus, on aura toujours des apps hors Kubernetes donc il faut de toute façon savoir gérer des VMs.

Bref, Kubernetes tire beaucoup de dĂ©pendances. Est ce que ça vaut le coup ? Je dirai que ça dĂ©pend des situations. On peut aller dĂ©jĂ  trĂšs loin avec de l’immutable infrastructure, de la vm, et du service discovery type Consul.
Une boite qui ne fait pas de conteneurs en 2020 moi ça me choque pas.

GĂ©rer un cluster c’est une Ă©quipe Ă  plein temps (et mĂȘme sur les offres managĂ©s il y a encore beaucoup de boulot).

Salut pour ma part je vois un gros bĂ©nĂ©fice a kubernetes managĂ©, une fois en place, j’ai pratiquement aucune maintenance, je dois juste mettre Ă  jour la version de temps en temps. Et cela se fait en 3 cliques.

Etant sur GCP, les logs sont gérés par GCP et visualisable facilement.
J’ai aussi des metrics gĂ©rĂ© par GCP.
La CI on utilisait gitlab-ci, et il a juste suffit d’adapter un peu le fichier gitlab-ci

J’ai un monitoring externe qui ping mes services toutes les 5 minutes et sur mon cluster de production (3 nodes sur 3 zones), pour mes conteneurs dĂ©ployĂ©s sur ces 3 zones j’ai aucun fail sur les pings depuis 2 ans.

Du coup effectivement kubernetes n’est pas a utiliser dans toutes les situations, mais si on est dans le bon use case, c’est quand mĂȘme excellent ;p

Docker n’est qu’une solution de packaging basĂ©e sur des containers (Ă  la base de type LXC). Docker a su s’imposer par rapport aux technologies dĂ©jĂ  existantes (LXC, OpenVZ, Vserver) par son outillage permettant facilement de construire des images, de les partager, 
etc.

Comparativement à d’autres solutions de packaging comme les formats native RPM et DEB, Docker offre certains avantages (je ne cite que le minimum) :

  • Distribution agnostique.
  • Isolation des dĂ©pendances.
  • Optimisation de l’espace disque grĂące Ă  l’usage d’un systĂšme de fichier de type overlay.
  • Support d’instances multiples sur une mĂȘme machine.

Il ne faut donc pas voir Docker pour ce qu’il n’est pas, une solution de sĂ©curitĂ© ou de virtualisation.

Docker n’est pas une alternative ou un concurrent aux technologies de virtualisation, c’est plutĂŽt un outil complĂ©mentaire et on se dirige vers une hybridation des deux technologies (virtualisation et containers) avec des outils comme Kata.

D’ailleurs, je pense qu’il faut arrĂȘter de parler de Docker et plutĂŽt utiliser le terme container (au sens OCI) car cette technologie a donnĂ© lieu maintenant Ă  un standard normalisĂ©.

Et si Docker a connu aussi du succĂšs, c’est que les containers rĂ©pondent Ă  des besoins liĂ©s aux pratiques DevOps et d’automatisation, il est tombĂ© au bon moment si j’ose dire.

Ce n’est pas totalement vrai, on gĂšre 5 clusters kubernetes avec 2 personnes (qui ne font pas que ça). Est-ce que cela est plus galĂšre que de gĂ©rer un cluster VMWare ou Openstack ? Je ne crois pas.

Ce n’est pas totalement vrai non plus, on peut faire ça avec autre chose que Fluentd ou Prometheus. Pour la partie CI ce n’est pas non plus le cas si de base l’artefact gĂ©nĂ©rĂ© est une image docker, cela pourrait ĂȘtre pire avec des techo de packaging moins agnostiques comme du DEB/RPM.

Kubernetes vaut le coup si on a besoin d’orchestration, si on n’a pas besoin de cela alors oui il ne sert Ă  rien (et c’est la mĂȘme choses pour toutes les techno).

Un client dont l’app n’a pas une architecture de type microservices, 
 on ne va surement pas lui conseiller de dĂ©ployer un k8s.

Pour finir, je dirais par expĂ©rience que beaucoup d’équipes IT sont Ă  la traine que cela soit sur des infra classiques ou modernes car le souci est souvent organisationnel (Ă©quipes cloisonnĂ©es, silos,
) et techniques (manque de compĂ©tences).

Ce n’est pas mon expĂ©rience aprĂšs plus de 3 ans de Kubernetes (on premise, on gĂšre pas mal de clusters). Une fois les clusters en place c’est sĂ»r il y a moins de travail (mais il y a toujours beaucoup de maintenance), mais le ticket d’entrĂ©e est Ă©norme.
Concernant la difficulté, je comparais plutÎt à des architectures basées sur des VMs (chez un cloud provider par exemple).

Et ça marchera Ă  moitiĂ©, l’intĂ©gration ne sera pas bonne etc
 Ne pas partir sur Prometheus quand on fait du Kubernetes c’est se tirer une balle dans le pied.

La difficultĂ© n’est pas de gĂ©nĂ©rer l’image, mais d’avoir le tooling en place pour gĂ©nĂ©rer le manifest et l’apply en prod (kustomize vs helm vs 
) + tout ce qui doit ĂȘtre dĂ©ployĂ© Ă  cĂŽtĂ© (network policies par exemple).

En effet Kubernetes peut simplifier les architectures microservices (bien qu’il soit faisable d’en faire sans Kubernetes, Netflix a longtemps packagĂ© ses apps dans des images de vms par exemple).
Mais soyons honnĂȘte, combien d’entreprises ont rĂ©ellement besoin de faire du microservice ? 5 % ? 10 % ? La complexitĂ© apportĂ©e par ce genre d’architecture ne se justifie que dans des cas spĂ©cifiques.

Dans ce cas il faudrait comparer cela à la difficulté de gérer un cluster k8s en offre managée chez un cloud provider.

On est d’accord que ce n’est pas simple, comme toute techno il faut comprendre ce qu’on utilise. C’est aussi pour ça que cela me fait sourire lorsqu’on a des clients qui affirment que leur Ă©quipe de dev peut s’occuper de gĂ©rer leur cluster k8s.

Tu as des outils comme Newrelic ou Datadog qui font trĂšs bien cela, c’est un bon moyen de s’épargner la maintenance complĂšte d’un outil de monitoring et d’APM.

C’est le cas dĂšs qu’on veut faire de l’automatisation et du dĂ©ploiement continu, non ? Il faut pouvoir provisionner les infrastructures, configurer les app, 
Etc.

Oui et ils ont crĂ©Ă©s Ă©normĂ©ment d’outils en interne pour cela, y’a qu’à voir leurs projets OSS, aujourd’hui je pense qu’ils adoptent les standards existants ou qui se mettent en place.

On est d’accord, cependant, il y a aussi je pense pas mal de boites qui seraient moins en galùre si elles avaient la bonne architecture.

Alors c’est un argument qui revient souvent, cependant rĂ©cemment je suis tombĂ© (sans me faire mal) sur ce tweet : https://twitter.com/aeris22/status/1311209008213168128 (Que j’ai tentĂ© de suivre malgrĂ© mes connaissances en compilation c++)

Ça n’a pas l’air quand mĂȘme si magique et si simple le “Tourne partout de la mĂȘme maniĂšre”. Quelqu’un saurait expliquer ce qu’est le problĂšme ?

Oui enfin c’est portable sur des plateformes similaires, ici le souci visiblement et qu’ils essaient de faire tourner une application 64 bits sur une machines dont l’OS est en 32 bits.

C’est portable tant que le kernel commun est supportĂ©.

1 J'aime

C’est la chose entre la chaise et le clavier le problĂšme. Rapidement lu et il sort que c’est la libc du systĂšme hĂŽte qui est utilisĂ© par les processus du container
 Je me suis arrĂȘtĂ© lĂ .

Sur le cas mentionnĂ© dans le tweet, difficile de dire oĂč est le problĂšme.

En effet, je crois que l’auteur s’est plantĂ© sur la rĂ©ponse que tu mentionnes, mais le reste du thread n’en est pas pour autant dĂ©nuĂ© de sens.

Si je ne m’abuse, il arrivera forcĂ©ment un moment oĂč la (vieille) libc du container deviendra incompatible avec le (nouveau) kernel de l’hĂŽte. Ça va certainement se compter en annĂ©es, mais ça va planter un beau jour sans prĂ©venir. Et si il faut re-builder l’image du conteneur dans plusieurs annĂ©es, il y a des chances pour que ce soit compliquĂ©, voire impossible (sans mettre Ă  jour les dĂ©pendances et le code).

Ce qui est le plus gĂȘnant, c’est que c’est difficile Ă  anticiper. Que ça va se produire sur du legacy (mĂȘme image qui tourne depuis X annĂ©es sans mise Ă  jour). Et que ça arrivera potentiellement au mauvais moment.

Sur cet exemple, on s’éloigne du cas dont il est question dans le tweet, mais ça me semble intĂ©ressant d’en parler.

On pourra toujours argumenter que c’est une mauvaise gestion de projet, de prioritĂ©, etc. Le fait est que l’on a, pour beaucoup d’entre nous, du legacy Ă  gĂ©rer, me semble t-il.

Ce n’est pas de la mauvaise fois Ă  mon humble avis. Je pense en revanche que tu idĂ©alises beaucoup les outils que tu utilises, ce que tu pousses Ă  penser cela. :wink:

@mcorbin a citĂ© l’exemple de la migration live.

Au moins, le contrat est clair. Pas de fausses promesses et de cas bizarres (cf messages précédents).

Sur macOS, le conteneur Docker dĂ©marre dans une VM Linux. Avec un Vagrant, j’installe n’importe quel paquet Debian dans une VM Linux Ă©galement.

Donc je suis plutĂŽt d’accord avec @mcorbin lorsqu’il parle de dĂ©tail d’implĂ©mentation.

Les conteneurs et k8s sont supers en façade, car il rĂ©solvent des problĂšmes que l’on a depuis des annĂ©es. Mais ils apportent plus de problĂšmes qu’ils n’en rĂ©solvent, et au coĂ»t d’une trop grande complexitĂ© (en particulier dans le cas de k8s).

Je dĂ©plore surtout le manque d’alternatives simple et fiable sur la partie orchestration (quid de Nomad ?).

Les containers n’ont pas vocation Ă  rester tel-quel des annĂ©es, ils ont un cycle de vie court. On parle ici d’un outil qui trouve sa place dans une approche DevOps oĂč on dĂ©ploie rĂ©guliĂšrement de nouvelles versions.

A mon sens il y a legacy et legacy. Si une boite en arrive au point d’avoir du code tellement pas maintenu qu’il n’est plus dĂ©ployable sur un OS moderne, alors Docker c’est le cadet de ses soucis.

Sinon, au contraire Docker favorise les montĂ©es en versions et facilite le refactoring, notamment grĂące Ă  l’isolation des dĂ©pendances, Ă  la favorisation des architectures microservices, 
etc.

Curieux de voir la liste de ces problĂšmes.

Il y a Docker Swarm mode qui est l’orchestrateur le plus simple de prise en main mais du fait de ses limitations et de son manque d’ouverture, il tombe dans l’oubli.

Nomad ne semble pas dĂ©coller du fait que K8S s’est aujourd’hui imposĂ© comme le standard de facto.

Je parle de l’image qui restera la mĂȘme Ă  travers les annĂ©es.

DevOps et dĂ©ploiement continue ou pas, tu auras toujours des projets qui seront abandonnĂ©s d’un point de vue dĂ©veloppement mais qui devront continuer Ă  fonctionner en prod.

Si la prod repose sur des containers Docker, ce n’est justement pas le cadet de ses soucis.

Pas vraiment.

Il y en a tellement que je n’ai pas de liste finie. Les problĂšmes de performance, de sĂ©curitĂ©, le monitoring devient plus complexe, l’orchestration qui impose pratiquement d’avoir un cluster k8s, les images non maintenues et/ou pas mal conçues, etc. Chacun de ces points pourrait ĂȘtre dĂ©veloppĂ©, mais je n’arriverai pas Ă  ĂȘtre exhaustif.

Et c’est bien regrettable tant la solution est complexe et imparfaite.