<!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>