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

[Daniel Cordey]

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.

dc