| | | * Êtes-vous parti sur des bare-metal (qui demande surement plus de | config) ? ou est-ce que vos workers sont des VMs ?
chez nous c'est master en vm et worker en physique (il faut être capable de provisionner des phys as code)
| * L'utilisation de VMs permet d'être plus flexible, mais en terme de | performances, ne faut-il pas plutôt utiliser des srv physiques (pour | éviter d'avoir une couche de virtu supplémentaire) ?
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... , potentiellement des licences en plus a acheter (autant prendre PKS... non j'deconne ;) ) Bon ok on a une API, mais si ton provisionning Baremetal est as code, alors pkoi pas faire du baremetal sur les workers
| * Comment est-ce que vous gérer le stockage ? Infra dédiée du type | Ceph/autre ?
Stateless tant qu'on peut (et ca va pas durer longtemps....)
| * Quelle est votre gestions des logs (container + infra) ? Solution | maison ? ou artillerie lourde du genre cluster Elasticsearch ?
Elk
Nico
Bon ok on a une API, mais si ton provisionning Baremetal est as code, alors pkoi pas faire du baremetal sur les workers
Parce que ce n'est pas pareil de gérer 100 containers sur un kernel que 10 sur 10 kernels.
--
Raphael Mazelier
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.
*Cordialement / Regards*
*Pierrick CHOVELON* Administrateur Systèmes *Département Infrastructure & Production* *A-SIS - 04 77 49 47 00* *pierrick.chovelon@a-sis.com pierrick.chovelon@a-sis.com*
-
Nicolas Belafekir -
Pierrick CHOVELON -
Raphael Mazelier