-
@Metal3d @EricLeVacon @briceatwork Faux. Complètement faux.
-
@Metal3d @EricLeVacon @briceatwork Les modifs de dépendances sont **RÉELLEMENT** testées et reviewées par les mainteneurs des distributions, qui **GARANTISSENT** une non régression au niveau applicatif.
-
@Metal3d @EricLeVacon @briceatwork Aller bouger à l’arrache des libs systèmes dans des images docker par les ops sans repasser l’intégralité de la QA (qui généralement n’est pas complète en plus), c’est du suicide…
-
@Metal3d @EricLeVacon @briceatwork Le mainteneur de OpenSSL chez Debian, il est cryptologue et connaît la lib sur le bout des doigts et peu réciter le changelog par cœur. Tu peux en dire pareil de ton ops face à une release OpenSSL ?
-
@Metal3d @EricLeVacon @briceatwork C’est ce mainteneur qui est en charge de savoir si le patch de sécu doit être rétroporté sur l’ancienne version de la lib proposée par la distribution ou si un upgrade de version sera sans impact au niveau userland (ie dev).
-
@Metal3d @EricLeVacon @briceatwork Chez Docker, c’est « yolo, l’overlay N-1 a bougé, je rebuild chez moi ». Tu es de toute façon incapable de savoir précisément ce qui a bougé et si ça impacte tes applicatifs. Sinon refaire une passe complète de QA dessus.
-
@Metal3d @EricLeVacon @briceatwork Et comme la QA ça prend du temps voire c’est rarement automatisé/able, ben on en arrive à « bon ben on va rester avec notre conteneur troué hein ».
-
@Metal3d @EricLeVacon @briceatwork Parce qu’on ne veut prendre aucun risque et effectivement avoir un truc reproductible de jours en jours. Y compris en terme de sécurité du coup, et donc de vieilles failles…
-
@Metal3d @EricLeVacon @briceatwork Là où un « apt dist-upgrade -y » te (presque) garantie la non régression au niveau applicatif et donc sera plus facilement réalisé par les teams d’ops, les rebuilds Docker sont des jeux de roulette russes avec un pistolet automatique, et donc ne sont *PAS* faits en pratique.