Catégories
humeur

Fail #002 – Politique de mise à jour automatique

Le « patch management » ou la politique de mise à jour de nos logiciels et services, c’est toujours plus intéressant quand tout est fait de manière plus ou moins transparente pour l’utilisateur et surtout pour l’administrateur. Mais parfois le plan ne se déroule pas sans accroc. C’est pour cela qu’il existe des environnements de pré-production pour éviter de tout casser alors que les utilisateurs sont présents sur le S.I.

Mise à jour automatique sous Unraid OS

Récemment j’ai parlé de l’application CA Auto Update Applications. Elle permet de mettre à jour tous les plugins et les applications sous Unraid. En gros cela met à jour les services en mettant à jour le conteneur desservant l’applicatif. Si vous avez une base MariaDB, à chaque nouvelle release, celle-ci sera mise à jour automatiquement en « pullant » la nouvelle version du conteneur.

Il est possible de définir un délai permettant d’éviter d’installer des mises à jour sauvages qui peuvent planter les premières heures de leur apparition, et d’attendre que les premiers s’y cassent les dents.

Globalement ça fonctionne vraiment bien, et vu le nombre de mises à jour automatiquement déployées, le nombre d’erreurs rencontrées est vraiment négligeable. J’ai quand même été confronté récemment au plantage de mon Pi-Hole qui en passant en version 5 a eu son interface Web qui ne fonctionnait pas. Comme le contrôle de santé interne au conteneur n’accepte pas de fonctionner sans l’interface d’administration, le service ne cessait de redémarrer.

Par conséquence, j’ai pour l’instant « fixé » la version de Pi-Hole pour que celui-ci ne passe pas en version 5.

Mise à jour de conteneur avec Helm

Autre fai(l)t récent, j’ai essayé de mettre à jour sur mon infra k3s, quelques conteneurs :

  • Ne pas sauter plusieurs versions majeures (oui, c’est logique), mais les conteneurs n’embarquent généralement pas les scripts de mise à jour des données pour plusieurs versions. Et c’est même parfois le cas juste pour des version mineures (je viens de le rencontrer sur MongoDB, il va falloir éplucher les releases notes).
  • Lorsque l’on utilise Helm, la source des charts « stables » peuvent changer assez rapidement. C’est le cas pour le dépôt « stable » qui vient de passer à cette adresse : https://charts.helm.sh/stable/. De plus parfois les valeurs ne sont pas compatibles entre les charts… Bref c’est chaud !!!
  • Lorsque vous déployez pour la première fois un chart sur votre infra, il y a parfois des consignes de mise à jour qui s’affichent. Et bien il faut les noter car si on essaye de passer en force la fois prochaine, ça risque de ne pas fonctionner. Je me suis cassé les dents récemment en essayant de mettre à jour un chart NextCloud en force. J’ai dû tout bonnement réinstaller le service from scratch.

Conclusion

Rien de nouveau en clair dans ce type de fail, ou l’on perd finalement plus de temps qu’initialement prévu. Mais on va dire que pour un usage domestique on n’a vraiment pas le temps de tout tester en pré-production. Il ne faut donc pas ignorer les environnements d’exploitation des services à mettre à jour, et faire une analyse de risque avant de se lancer.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *