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
_______________________________________________
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull
