📻 RDO #9 - Jusqu’où conteneuriser?

cchaudier · Septembre 24, 2020, 8:22

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

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.

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

Nous sommes tous curieux et friands de retours d’expérience.

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

Lydra · Septembre 24, 2020, 8:22

mcorbin · Octobre 1, 2020, 9:29

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

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 ?).

cchaudier · Octobre 2, 2020, 8:30

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.

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.

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.

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 !

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.

mcorbin · Octobre 2, 2020, 8:53

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

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.

sebastien.prudhomme · Octobre 2, 2020, 9:23

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.

mcorbin · Octobre 2, 2020, 9:51

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.

bat79a · Octobre 2, 2020, 10:23

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

aselkim · Octobre 2, 2020, 11:11

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).

mcorbin · Octobre 2, 2020, 11:48

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.

aselkim · Octobre 2, 2020, 12:12

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.

lugirard · Octobre 2, 2020, 12:53

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 ?

aselkim · Octobre 2, 2020, 1:01

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é.

sebastien.prudhomme · Octobre 2, 2020, 4:08

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à.

jderrien · Octobre 3, 2020, 8:08

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.

jderrien · Octobre 3, 2020, 8:31

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.

@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 ?).

aselkim · Octobre 3, 2020, 7:27

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.

aselkim · Octobre 3, 2020, 7:40

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.

jderrien · Octobre 3, 2020, 8:10

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.

jderrien · Octobre 3, 2020, 8:18

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.