[gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?

Arnaud listes.00 at gmail.com
Sat Feb 6 12:58:16 CET 2021


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.



More information about the gull mailing list