Bonjour,

@François : Merci pour sylabs.io j'irai faire un tour.
@Vincent : Merci pour ce lien. Ca nous fera un peu de lecture :).

@Raphael :
"L'overhead des vm(s) étant quasi négligeable de nos jours je pense que cela vaut le coup d'ajouter cet abstractions."

C'est ce que je me dis de plus en plus. Et comme on a pas de quoi provisionner du physique as code comme le suggère @Nicolas, je pense que c'est le mieux pour nous.

"Après évidement si tu as un pod qui doit consommer plus que ça, la ça se discute et il vaux mieux à mon avis lui dédier un pool de worker."
En tout logique non, mais on est pas à l'abri d'une petite blague d'un dev :D.

"Le meilleur c'est aucun, que du stateless."
Si seulement ça pouvait être le cas...

+1 Pour Loki on vient de le tester et ça promet. Leur idée de se rapprocher du fonctionnement de Prometheus est pas mal du tout.

@Wallace :

Très intéressant le lien. Merci, et merci pour l'éclairage global.
-> Du coup, si tu pars sur de l'Ansible, tu ne te coupe des fonctionnalitées d'un orchestrateur non ? Par exemple, les concepts de liveness/readiness, ou les rollbacks de déploiements.

Pour les logs on est bien au courant de ça -> rsyslog vers un serveur dédié pour le moment.

@Nicolas :
"Moi je suis moins optimiste sur la virtu, sur des containers Java je ne suis pas sur que cela soit optimum (mon retour d'experience est assez limité pour le coup)
ca fait une couche en plus a gérér/monitorer/exploiter/administrer..."

Ouai, mais sur une infra virtuelle déjà existante, ces problématiques d'exploitation et d'administration sont déjà réglées normalement.
Si le overhead n'est pas si catastrophique que ça, alors ...

-> Mais du coup, est-ce que déployer des applications statefull, n'implique pas nécessairement de faire une sorte "de gestion de VMs" avec des containers ?


Merci à tous.