On 06/12/2019 18:14, Wallace wrote:
Bonjour,
Assez d'accord pour dire que garder la couche VM c'est pratique et ça ne consomme pratiquement rien.
Il ne faut surtout pas perdre de vue que du Docker c'est temporaire moyenne à 5 min (cf https://www.zdnet.fr/actualites/duree-de-vie-des-conteneurs-moins-de-cinq-mi...) ce qui signifie que toute volonté de faire du docker comme des VM est voué à l'échec. Je te passe les catastrophes de clients qui ont des docker avec des uptimes de plusieurs mois ou années et où la maintenance du host est impossible car les images sont trop anciennes, les dépendances plus en place, ... donc reboot impossible...
En effet si on essaye de faire de la vm avec des containers c'est l'échec assuré. Un container est éphémère et doit pouvoir redémarrer à tout instant.
A l'époque on avais instauré un rollout complet de notre cluster tout les vendredis matin, et chose incroyable cela marchait très bien.
Ensuite vient K8s où sérieusement tant que tu n'as pas dans les 100 images identiques à faire pop sur un même cluster alors j'estime que ça n'en vaut pas la chandelle. Si l'objectif est de faire un cluster de baremetal et avoir dessus plein de services différents avec autant d'images docker alors il vaut mieux partir sur une autre solution.
L'autre solution c'est ton baremetal est un cluster de virtualisation au choix, et tu mets des VM qui font juste du Docker host. Ça permet d'une de faire des points de montage (base de données, applis, ...) sans se prendre la tête avec le stockage partagé. Et tu orchestres le tout avec de l'infrastructure as a code comme Ansible. Ca permet de démarrer rapidement une image sur plusieurs vm pour faire un cluster, tu évites tous les crashs K8s qui vont éclater ta prod, puisque là les vms sont indépendantes.
Et pour tous les services qui ont une durées de vie de plus d'une semaine, pas de Docker, un OS en VM piloté par Ansible c'est bien plus stable dans le temps.
C'est discutable. De quels crash k8s parle tu ? des crash du control plane ? parce qu'au final je n'ai quasiment jamais eu de problème lié à k8s lui même.
Pour les logs il faut clairement externalisé du cluster, rappel au passage l'obligation légale de stocker pendant 1 an, combien de client en Docker ont les logs qui disparaissent quand l'image ou le K8s est explosé, s'il y a une requête judiciaire qui arrive pour avoir les logs de juste avant l'incident, le patron est quitte pour une prune et de la prison potentiellement ...
De souvenir il y a obligation de moyen, pas de résultat ;) et puis il ne s'agit que des logs d'accès pas des logs techniques.
Mais bon oui il te faut une infra de log avec k8s puisque la bonne pratique selon les 12 factors apps étant de logguer stdout/stderr, après tu utilises ce que tu veux pour centraliser.
Voila mon point de vue, pour moi c'est génial quand tu déploies plein de conteneurs ayant la même fonctionnalité pour piloter le scale up and down. Pour faire une infra docker de tout un service / produit alors plutôt des docker hosts sinon des VMs en infra as a code c'est très efficace aussi.
Il faut utiliser ce avec quoi tu es à l'aise.
--
Raphael Mazelier