Gestion par container (Kubernetes) plutôt que VM

antoine-c commented

2020-11-19 09:15:05 +01:00

Owner

Gestion par container

Je propose qu'une réflexion soit lancée sur une gestion de la plateforme et des services, via la logique des containers, par exemple en utilisant https://kubernetes.io/.

Référence / provenance

Non renseigné
Forum : URL de la discussion :
Liste de discussions : nom de la liste / date
Autre (précisez) résultat d'une exploration de ce qui se pratique par ailleurs, par exemple chez certains CHATONS et chez des entités européennes.

## Gestion par container Je propose qu'une réflexion soit lancée sur une gestion de la plateforme et des services, via la logique des containers, par exemple en utilisant https://kubernetes.io/. ## Référence / provenance  * [ ] Non renseigné * [ ] Forum : URL de la discussion : * [ ] Liste de discussions : nom de la liste / date * [X] Autre (précisez) résultat d'une exploration de ce qui se pratique par ailleurs, par exemple chez certains CHATONS et chez des entités européennes.

fdelalleau commented

2020-11-19 16:17:03 +01:00

J'avais proposé une architecture de ce type en arrivant au CS, on m'avait répondu que c'était trop complexe pour Ouvaton et Inulogic. Peut-être le changement d'infogerant sera-t-il l'occasion de réévaluer la faisabilité...

gurvan commented

2020-11-20 00:12:51 +01:00

Oui je me souviens du sujet, de mémoire fin 2017, tu avais parlé de nous fournir un concept de système container as a service avec docker.
Beaucoup d'idées mais en pratique, personne n'a rien fait. L'ancien président du CS était resté réaliste sur la situation d'Ouvaton. Le problème n'était pas une question de faisabilité mais de moyens principalement. C'est un projet de plusieurs mois/homme. Si Ouvaton trouve quelqu'un pour développer tout ça gratuitement, tant mieux, mais à l'époque personne ne s'était proposé. D'ailleurs il me semble qu'on attend toujours le poc et la démonstration.

Pour l'infogérant, ça ne fait pas de différence. En terme de RUN, ce sont des services à monitorer en plus. Ce n'est pas le contrat de RUN qui construit cette plateforme k8s et à la direction technique d'Ouvaton, il n'y a personne qui sache le faire.

Au-delà de la faisabilité, il faut étudier l'intérêt de la conteneurisation et quoi conteneuriser. Ouvaton, c'est principalement 5 600 sites LAMP/Mail et DNS mutualisés. On pourrait donc imaginer conteneuriser chaque site comme si chaque client consommait du PaaS.

Apache/PHP : Prenons l'hypothèse de conteneuriser un site individuellement avec une emprunte mémoire de 5 Mo juste pour Apache. Pour servir du contenu statique pour l'ensemble des sites, il faudrait donc 25 Go de RAM avec un ScaleSet à 1 (une instance de pod par site i.e. pas de redondance). Aujourd'hui, en comparaison, les 6 serveurs Apache consomment max 3Go au total et permettent une répartition de charge. HAProxy pouvant servir d'ingress controller comme il sert aujourd'hui de load balancer, ça ne ferait pas de grosse différence.
PHP aujourd'hui sur les serveurs, c'est 6 à 8Go de conso par serveur web. Quand on voit que nextcloud envoi une alerte parce qu'il ne peut pas faire des process php de 512mo de ram...
MySQL : Je ne connais pas un expert k8s qui préconiserait de conteneuriser une charge StateFull type base de données en production.
Serveur mail : NGinx peut servir de reverse proxy et rediriger le trafic vers des conteneurs SMTP/POP/IMAP dédiés à chaque domaine. Même problème que pour Apache.
DNS : même principe sûrement, un conteneur par zone.

Pour MySQL/Mail/DNS, en général ce sont des services qui sont consommés en dehors du cluster.

La conteneurisation évite d'avoir à virtualiser un OS entier pour chaque service, mais si c'est pour conteneuriser un monolythe qui occupe tout un OS, ça n'a guère de sens.

Sans compter qu'au final, la donnée est au même endroit pour tous les services. En cas de panne disque grave comme récemment, restaurer un serveur NFS est bien plus simple que restaurer 5 600 PVC.

Le site actuel d'Ouvadmin pourrait être conteneurisé. Les jobs pourraient l'être aussi, ce sont de bêtes appels curl sur le site. Il faudrait que la direction technique évalue le ROI d'une refonte de toute la stack technique sur ce que tu proposais à l'époque.

Enfin, Ouvaton pourrait proposer du k8s managé ou mutualisé mais c'est une autre histoire.

Oui je me souviens du sujet, de mémoire fin 2017, tu avais parlé de nous fournir un concept de système container as a service avec docker. Beaucoup d'idées mais en pratique, personne n'a rien fait. L'ancien président du CS était resté réaliste sur la situation d'Ouvaton. Le problème n'était pas une question de faisabilité mais de moyens principalement. C'est un projet de plusieurs mois/homme. Si Ouvaton trouve quelqu'un pour développer tout ça gratuitement, tant mieux, mais à l'époque personne ne s'était proposé. D'ailleurs il me semble qu'on attend toujours le poc et la démonstration. Pour l'infogérant, ça ne fait pas de différence. En terme de RUN, ce sont des services à monitorer en plus. Ce n'est pas le contrat de RUN qui construit cette plateforme k8s et à la direction technique d'Ouvaton, il n'y a personne qui sache le faire. Au-delà de la faisabilité, il faut étudier l'intérêt de la conteneurisation et quoi conteneuriser. Ouvaton, c'est principalement 5 600 sites LAMP/Mail et DNS mutualisés. On pourrait donc imaginer conteneuriser chaque site comme si chaque client consommait du PaaS. - Apache/PHP : Prenons l'hypothèse de conteneuriser un site individuellement avec une emprunte mémoire de 5 Mo juste pour Apache. Pour servir du contenu statique pour l'ensemble des sites, il faudrait donc 25 Go de RAM avec un ScaleSet à 1 (une instance de pod par site i.e. pas de redondance). Aujourd'hui, en comparaison, les 6 serveurs Apache consomment max 3Go au total et permettent une répartition de charge. HAProxy pouvant servir d'ingress controller comme il sert aujourd'hui de load balancer, ça ne ferait pas de grosse différence. PHP aujourd'hui sur les serveurs, c'est 6 à 8Go de conso par serveur web. Quand on voit que nextcloud envoi une alerte parce qu'il ne peut pas faire des process php de 512mo de ram... - MySQL : Je ne connais pas un expert k8s qui préconiserait de conteneuriser une charge StateFull type base de données en production. - Serveur mail : NGinx peut servir de reverse proxy et rediriger le trafic vers des conteneurs SMTP/POP/IMAP dédiés à chaque domaine. Même problème que pour Apache. - DNS : même principe sûrement, un conteneur par zone. Pour MySQL/Mail/DNS, en général ce sont des services qui sont consommés en dehors du cluster. La conteneurisation évite d'avoir à virtualiser un OS entier pour chaque service, mais si c'est pour conteneuriser un monolythe qui occupe tout un OS, ça n'a guère de sens. Sans compter qu'au final, la donnée est au même endroit pour tous les services. En cas de panne disque grave comme récemment, restaurer un serveur NFS est bien plus simple que restaurer 5 600 PVC. Le site actuel d'Ouvadmin pourrait être conteneurisé. Les jobs pourraient l'être aussi, ce sont de bêtes appels curl sur le site. Il faudrait que la direction technique évalue le ROI d'une refonte de toute la stack technique sur ce que tu proposais à l'époque. Enfin, Ouvaton pourrait proposer du k8s managé ou mutualisé mais c'est une autre histoire.

fdelalleau commented

2020-11-20 07:18:41 +01:00

En allant moins sur le technique, et en étant plus sérieux que pour mon commentaire :

Mettre en place des containers n'a d'intérêt que dans une logique différente de celle de Ouvaton actuellement.
En gros, pour continuer à donner une plaque de base, aucun intérêt. En revanche, si on oriente service une partie de l'activité, là oui. Par exemple pour des WordPress en un clic, mettre en ligne deux containers exe (WP et SQL) et deux containers data est plus simple et plus efficient que d'installer un WP par script, recréer une bdd, etc... Par contre pour un Nextcloud mutualisé où l'on ne créé que les utilisateurs, aucun intérêt. Bref, ça se regarde au cas par cas.

En revanche, que la plateforme soit en capacité de faire ça, ce serait un plus. Quand je parlé du changement d'infogerant, je voulais surtout dire "profiter de la migration". Je sais que Octopuce travail pas mal en containers. Bref, l'occasion fait le larron, et tout comme on peut en profiter pour discuter de la rearchitecturation de Ouvadmin, on peut discuter de celle de la plateforme... Et une discussion ne coûte rien.

En allant moins sur le technique, et en étant plus sérieux que pour mon commentaire : Mettre en place des containers n'a d'intérêt que dans une logique différente de celle de Ouvaton actuellement. En gros, pour continuer à donner une plaque de base, aucun intérêt. En revanche, si on oriente service une partie de l'activité, là oui. Par exemple pour des WordPress en un clic, mettre en ligne deux containers exe (WP et SQL) et deux containers data est plus simple et plus efficient que d'installer un WP par script, recréer une bdd, etc... Par contre pour un Nextcloud mutualisé où l'on ne créé que les utilisateurs, aucun intérêt. Bref, ça se regarde au cas par cas. En revanche, que la plateforme soit en capacité de faire ça, ce serait un plus. Quand je parlé du changement d'infogerant, je voulais surtout dire "profiter de la migration". Je sais que Octopuce travail pas mal en containers. Bref, l'occasion fait le larron, et tout comme on peut en profiter pour discuter de la rearchitecturation de Ouvadmin, on peut discuter de celle de la plateforme... Et une discussion ne coûte rien.

antoine-c commented

2020-11-20 09:16:03 +01:00

Author

Owner

#11 (comment) : Le problème n'était pas une question de faisabilité mais de moyens principalement.

#11 (comment) : Au-delà de la faisabilité, il faut étudier l'intérêt de la conteneurisation et quoi conteneuriser.

#11 (comment) : Mettre en place des containers n’a d’intérêt que dans une logique différente de celle de Ouvaton actuellement. En gros, pour continuer à donner une plaque de base, aucun intérêt. En revanche, si on oriente service une partie de l’activité, là oui.

Vous avez assez bien résumé mes pensées.

Une des solutions d'avenir d'Ouvaton, passe par la possibilité d'avoir une tarification au service et à la consommation (de volume, de capacité, de vitesse, d'effort, d'assistance, de mise à disposition de ressources matérielles), de façon souple aussi bien pour les utilisateurs que pour la gestion administrative et technique. Dans ce cadre, une logique "technique par container" peut avoir un sens.

La logique par container est de plus en plus présentée, comme une sorte de "saut" technique, venant à la suite des logiques de gestion par VM. Le nombre de personnes utilisant les containers et le nombre de projets costauds utilisant la logique des containers, est maintenant très important et n'arrête pas d'augmenter à grande vitesse. Cela pourrait signifier que se reposer sur cette technique est pertinent.

Le changement en vue d'infogérance, et l'appartenance des infogérants contactés à des groupes s'intéressant aux logiques de containers, pourrait permettre de s'orienter plus facilement vers ces logiques.

Si Ouvaton souhaite proposer un assez haut degré de service de niveau professionnel à destination des particuliers mais aussi et surtout à destination des professionnels, alors, cette logique par containers pour s'imposer à elle à un moment ou un autre, assez rapidement, qu'elle le veuille ou non.

Commencer à aborder ces questions dès aujourd'hui, est peut-être bien déterminant.

> https://git.ouvaton.coop/Ouvaton/EvolutionPlateforme/issues/11#issuecomment-206 : Le problème n'était pas une question de faisabilité mais de moyens principalement. > https://git.ouvaton.coop/Ouvaton/EvolutionPlateforme/issues/11#issuecomment-206 : Au-delà de la faisabilité, il faut étudier l'intérêt de la conteneurisation et quoi conteneuriser. > https://git.ouvaton.coop/Ouvaton/EvolutionPlateforme/issues/11#issuecomment-207 : Mettre en place des containers n’a d’intérêt que dans une logique différente de celle de Ouvaton actuellement. En gros, pour continuer à donner une plaque de base, aucun intérêt. En revanche, si on oriente service une partie de l’activité, là oui. Vous avez assez bien résumé mes pensées. Une des solutions d'avenir d'Ouvaton, passe par la possibilité d'avoir une tarification au service et à la consommation (de volume, de capacité, de vitesse, d'effort, d'assistance, de mise à disposition de ressources matérielles), de façon souple aussi bien pour les utilisateurs que pour la gestion administrative et technique. Dans ce cadre, une logique "technique par container" peut avoir un sens. La logique par container est de plus en plus présentée, comme une sorte de "saut" technique, venant à la suite des logiques de gestion par VM. Le nombre de personnes utilisant les containers et le nombre de projets costauds utilisant la logique des containers, est maintenant très important et n'arrête pas d'augmenter à grande vitesse. Cela pourrait signifier que se reposer sur cette technique est pertinent. Le changement en vue d'infogérance, et l'appartenance des infogérants contactés à des groupes s'intéressant aux logiques de containers, pourrait permettre de s'orienter plus facilement vers ces logiques. Si Ouvaton souhaite proposer un assez haut degré de service de niveau professionnel à destination des particuliers mais aussi et surtout à destination des professionnels, alors, cette logique par containers pour s'imposer à elle à un moment ou un autre, assez rapidement, qu'elle le veuille ou non. Commencer à aborder ces questions dès aujourd'hui, est peut-être bien déterminant.

antoine-c commented

2020-11-20 17:43:35 +01:00

Author

Owner

Dans ce domaine, Kubeapps est tout à fait surprenant et on voit bien où cela va finir par aller: des installations d'applications par containers facilitées, un peu à la façon de Yunohost, avec des réglages de capacités disques en plus ... Les perspectives semblent illimitées. On sent bien que les choses vont se passer par là dans les années qui viennent.

Dans ce domaine, [Kubeapps](https://kubeapps.com/) est tout à fait surprenant et on voit bien où cela va finir par aller: des installations d'applications par containers facilitées, un peu à la façon de Yunohost, avec des réglages de capacités disques en plus ... Les perspectives semblent illimitées. On sent bien que les choses vont se passer par là dans les années qui viennent.

fdelalleau commented

2021-03-29 12:49:51 +02:00

Salut,

@antoine-c je "relance" le ticket. Je pense que le sujet n'est pas à l'ordre du jour, et potentiellement e le sera jamais. Je te propose de clore le ticket, en attendant d'avancer sur le débat de l'offre d'Ouvaton, et sur pendant technique.

Salut, @antoine-c je "relance" le ticket. Je pense que le sujet n'est pas à l'ordre du jour, et potentiellement e le sera jamais. Je te propose de clore le ticket, en attendant d'avancer sur le débat de l'offre d'Ouvaton, et sur pendant technique.

antoine-c commented

2021-03-29 14:34:14 +02:00

Author

Owner

OK. Je ferme le ticket. On le rouvrira s'il le faut plus tard ou jamais.

antoine-c closed this issue

2021-03-29 14:34:15 +02:00

fdelalleau locked as Too heated and limited conversation to collaborators 2021-03-29 14:45:37 +02:00

Gestion par container (Kubernetes) plutôt que VM #11

Gestion par container

Référence / provenance