[gull] [SPAM] Re: Linux,Le support long terme au noyau Linux passe à 2 ans

[Daniel Cordey]

Le 10/3/24 à 14:34, Yves Martin via gull a écrit :
>> J'ai adoré la qualité de Debian et les mises à jour quasiment
>> parfaites
>> et cohérentes pendant plus de 20 ans, mais peut-être, effectivement,
>> que
>> ce modèle va s'éteindre.
> Sincèrement, je ne crois pas.
> Car container ou pas, il faudra toujours un système "hôte" pour tourner
> le moteur de container quel qu'il soit (on commence à en avoir un
> certain nombre) et la qualité Debian est un grand plus dans ce
> contexte.

Non, je ne pense pas non plus que le modèle Debian va s'éteindre, mais, 
à mon humble avis, il va subsister, mais de manière beaucoup plus 
discrète que jusqu'à aujourd'hui. Le monde évolue et les web apps 
prennent de plus en plus d'importance (pour de multiples raisons). Donc, 
il va y avoir un besoin massif de services non-stop, etc. Le concept de 
"server" est gentiment remplacé par celui de "service". Or, un service 
doit être mobile et résilient, et les technologies qui permettent de le 
gérer facilement dépassent la simple notion du "server". C'est un fait 
qui correspond à la demande et qui se généralise sans grands effets 
d'annonce. Tout ceci se fait tranquillement, car on ne change pas une 
architecture IT comme ça du jour au lendemain. Debian, c'était très bien 
et c'est toujours très bien, mais ça ne suffit plus.J'ai toujours été 
gêné par le cycle des release de Debian que je trouve trop lent pour de 
multiples raisons; et je me refuse à jouer aux équilibristes en 
bricolant entre "stable" et "testing".

> De plus, une image de container n'est quasiment jamais construit "ex-
> nihilo" même quand il s'agit de tourner un service compilé en Go (qui
> sur le principe n'a besoin d'aucune bibliothèque partagée d'un système
> POSIX classique)

Non, pas d'accord du tout. Docker permet de construire des images de 
manière très facile et en n'incluant que le strict nécessaire. De plus, 
il ne se passe pas une semaine sans que de nouveaux outils gravitants 
autours de Docker et de ses outils associés ne voient le jour. De plus, 
les images ainsi construites peuvent justement avoir n'importe quelle 
distro comme de base de fonctionnement. C'est d'ailleurs l'objectif de 
Docker. La création d'une image simple prend quelques minutes, mais il 
est aussi possible de faire des tas de choses très sophistiquées au 
niveau réseau. file system, etc. L'avantage étant que la réplication 
d'un service ainsi construit peut-être ensuite diffusé sans limites sur 
n'importe quel hôte.

> Et les images de container à base de Debian (qui certes dans ce cas
> n'inclut pas le kernel Linux, puisque c'est le sujet initial ici)
> profitent des bonnes propriétés de la distribution en terme de
> modularité des packages et de mises à jour de sécurité.

Précisément, inclure une image complète Debian est "over killing". Il 
est d'ailleurs très rare et d'utiliser une distro complète à intégrer 
dans une image. D'ailleurs, ça n'a pas beaucoup de sens et c'est 
inefficace (place mémoire, temps de démarrage, etc.). On se limite donc 
très souvent à utiliser une base minimum comme Alpine qui ne fait que 5 
MB, et on ajoute ce dont on a besoin. Ceci permet de construire des 
images vraiment petites.

> Tout comme l'introduction de la virtualisation a réorganisé certains
> aspects des distributions, il en est déjà de même pour la
> containerization depuis quelques années.

Oui, mais ça ne s'arrête pas là. On peut utiliser des conteneurs de 
manière manuelle ; ce qui est déjà une bonne étape. Mais pour se 
construire un cluster de serveur Web, DB, etc. on va utiliser des 
technologies comme Kubernetes, qui dépasse largement les domaines 
couverts par Docker et qui justement permet cette fameuse approche CI/CD.

Pendant des années, j'ai suivi les pratiques consistant à faire des MAJ 
le moins souvent possible et à ne pas rebooter mon système, à moins 
d'une absolue nécessité. Mes années de production dans un environnement 
24/7 m'ont fait changer mon fusil d'épaule. Pourquoi ? Pour trois 
raisons principales.

La première est que le cycle 'stable' de Debian était trop lent et ne 
permettait pas d'adopter des technologies dont nous avions besoin pour 
répondre à des demandes croissantes de performances et de capacités. 
Comme une nouvelle fonctionnalité de MariaDB... non supportée par la 
version 'stable'. On peut bricoler avec 'testing', mais alors, je ne 
vois pas pourquoi je n'utiliserais pas directement une distro Ubuntu...? 
Multiplier les bricolages est une stratégie qui n'a aucun sens dans un 
environnement de production intense. La gestion des bricolages finis par 
vous prendre trop de temps et causer des problèmes.

La deuxième raison est liée à la première... Mettre à jour votre système 
tous les 2-3 ans est un bon moyen de vous créer des problèmes... Vous 
utilisez MariaDB, nginx, uwsgi, python2.7, etc. et soudainement, vous 
migrez tous ces sous-systèmes vers de nouvelles versions... Vous partez 
alors pour une semaine d'enfer... Dans un environnement où vos clients 
attendent des signaux sur les marchés toutes les cinq secondes !!! En 
effet, c'est à ce moment que vous découvrez que la syntaxe des fichiers 
de config a changé et que vos directives ne sont plus prises en compte, 
que la librairie xxx.yyy ne donne pas les résultats escomptés, car 
maintenant, elle prend des valeurs par défaut dans certains cas, etc., 
etc. Et c'est sans fin... Alors, non, je ne fais plus ce genre de chose 
et je suis fermement opposé à cette manière de faire. Ah... il faudrait 
un système de test... ouai, mais on n'a pas le temps ni les moyens de se 
disperser dans quelque chose qui, de toute façon, ne va pas marcher 
lorsque vous le mettez en production, malgré les centaines de test que 
vous aurez pu faire ! Quand vous devez stocker des millions de prix 
chaque jour dans une DB et répondre à des milliers de requêtes (que vous 
facturez), vous ne pouvez pas vous permettre d'expérimenter à la volée. 
Pour info, nos DB servers étaient en permanence à plusieurs centaines 
d'accès à la seconde 24h. sur 24. Comme me l'avait dit un jour un client 
(NYSE), à qui je demandais pourquoi il n'utilisait pas XON/XOFF pour 
éviter ses "buffer overflow"... "Monsieur, les marchés n'attendent pas 
!". Et si vous perdez des valeurs, personnes ne viendra vous les donner 
après coup. Faire un site web pour un office du tourisme dans une 
station de montagne n'a pas les mêmes exigences que les marchés 
financiers ; il faut donc en tenir compte et adapter ses pratiques de 
system admin en conséquence.

La troisième raison est aussi liée aux points évoqués dans le paragraphe 
précédent. Il est inenvisageable de produire du code qui n'a pas de bug. 
De plus, il arrive aussi que ces bugs ne soient pas de votre ressort... 
Donc, vous devez continuellement corriger ceux-ci, en plus des nouvelles 
fonctionnalités que l'on vous demande d'ajouter en permanence. Ce qui 
fait que... en faisant de petites modifications ponctuelles, on limite 
grandement le risque de tout casser, et les problèmes engendrés sont 
nettement plus faciles à gérer, car confinés au seul changement que vous 
venez de faire ! Ainsi, pourquoi ne pas faire des changements en 
permanence ? Justement si ! C'est une bonne idée qui fonctionne très 
bien (à condition d'avoir architecturé votre ensemble dans ce sens). 
Cela s'appelle donc CI (Continuous Integration), CD (Continuous 
Delivery). Couplé à Docker/Kubernetes, c'est une vraie stratégie qui 
permet de répondre aux exigences d'environnement très intenses, alors 
que la stratégie classique avec nos serveurs Debian/etc. vous engagerait 
dans des manipulations complexes en permanence et avec une probabilité 
de plantage très important. De plus, il est beaucoup plus facile de se 
créer des environnements de test avec Docker/Kubernetes. Sans compter 
qu'il est possible de définir à quelle vitesse vous modifier vos 
serveurs dans Kubernetes en décommissionnant les anciens et en mettant 
les nouveaux en production.

A+


dc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://forum.linux-gull.ch/pipermail/gull/attachments/20240313/4465ced2/attachment-0001.html>