<!DOCTYPE html>
<html data-lt-installed="true">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body style="padding-bottom: 1px;">
<p><br>
</p>
<div class="moz-cite-prefix">Le 10/3/24 à 14:34, Yves Martin via
gull a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:ac736ac5eeb13879891de49ecd67d15551a24f25.camel@free.fr"><span
style="white-space: pre-wrap">
</span>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.</pre>
</blockquote>
<p>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.<span
style="white-space: pre-wrap"> 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".
</span></p>
<p><span style="white-space: pre-wrap">
</span></p>
<blockquote type="cite"
cite="mid:ac736ac5eeb13879891de49ecd67d15551a24f25.camel@free.fr">
<pre class="moz-quote-pre" wrap="">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)</pre>
</blockquote>
<p>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.</p>
<p><span style="white-space: pre-wrap">
</span></p>
<blockquote type="cite"
cite="mid:ac736ac5eeb13879891de49ecd67d15551a24f25.camel@free.fr">
<pre class="moz-quote-pre" wrap="">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é.</pre>
</blockquote>
<p>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.</p>
<p><span style="white-space: pre-wrap">
</span></p>
<blockquote type="cite"
cite="mid:ac736ac5eeb13879891de49ecd67d15551a24f25.camel@free.fr">
<pre class="moz-quote-pre" wrap="">
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.</pre>
</blockquote>
<p>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.</p>
<p>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. </p>
<p>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.</p>
<p>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.<br>
</p>
<p>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. <br>
</p>
<p>A+</p>
<p><br>
</p>
<p>dc<br>
</p>
</body>
<lt-container></lt-container>
</html>