Le 06.02.21 à 12:50, Daniel Cordey a écrit : > On 06/02/2021 10:31, Marc SCHAEFER wrote: > >> >>>> Dans ce cas, la seule solution est que les données soient stockées à >>>> part et que les conteneurs soient générables automatiquement par scripts >>>> ou Docker compose ou autre, et on les regénère régulièrement à partir >>>> d'images de bases mises à jour. >>> Oui, données à part, c'est une de mes finalités. > > Je me greffe sur cette discussion pour faire un petit commentaire plus > général en ce qui concerne la gestion des "conteneurs". > > La question est de bien définir l'usage. Si l'objectif est de remplacer N > serveurs (ou services) de manière à les isolés sur un seul "host", la > solution la plus tendance à l'heure actuelle est "Ansible". Il y a encore pas > mal de gens qui font du Puppet, mais il est plus logique de s'orienter vers > Ansible qui offre plus de performance et de facilités. Néanmoins, chaque > service devra avoir sa propre config et il faudra quand même gérer toutes ces > entités. > > Les choses se complique lorsque l'on veut faire de la redondance ou du > load-balancing. On se trouve alors confronté à la notion de "découverte des > services", qui peuvent bouger avec ces exigences. C'est justement l'autre > objectif d'utilisation des conteneurs. Ceci s'appelle l'0erchestration des > services et est un domaine en soit. Après quelques années d'hésitations et de > flou, Kubernetes semble être le choix par défaut et le plus logique. > Kubernetes est intimement lié aux conteneurs et principalement à Docker > aujourd'hui. Il permet de définir une configuration standard pour un service, > qui peut être lancé par goupe ou en séquence, tout en intégrant les notions > évoquées plus tôt (redondance, fail-over, load-balancing). Cela permet aussi > de faire du "Scaling". Naturellement, c'est une couche d'administration > au-dessus de Docker, mais c'est aussi le moyen le plus simple et élégant > d'obtenir ce genre de service en masse. Il y a des fonctionnalités qui > permettent de planifier des > mises à jour des "serveurs", avec des notions de gestion de production assez > avancées. Il ne faut pas négligé la partie "file-system", qui est un point > essentiel dans le domaine de la redondance/fail-over/non-stop... mais là on > entre alors dans un monde encore plus complexe qui implique quasi > systématiquement de repenser son architecture de gestion des données (NoSQL, > etc.) > > En conclusion, la virtualisation du style hyper-v, kvm, etc. permet de > construire un monde très hétérogène, tout en minimisant l'utilisation du > matériel, alors que la virtualisation système (docker, LXC/LXD) offre un gros > gain de performance et de ressources, mais en ayant l'obligation d'être > homogène au niveau de l'OS. Kubernetes permet d'entrer dans le monde du > big-data et offre une quantité d'outils et de solutions pour ceux qui ont > besoin de ces fonctionnalités; mais là on ne peut plus se permettre de gérer > tout ça avec des scripts et Ansible.
Oui ça aussi c'est en cours. k8s, k3s/k3d, k1s, minikube, etc. . Il y en a un paquet. _______________________________________________ gull mailing list gull@forum.linux-gull.ch https://forum.linux-gull.ch/mailman/listinfo/gull
