Je me posais la question de savoir comment vous gérez au jour le suivi des mises à jours des services sur vos infras.
De mon côté, je dois avoir une quarantaine de services installés hors packages du système (Etherpad, Mastodon, Cryptpad, Uptime Kuma, etc etc) et je dois avouer qu’il m’est parfois difficile de suivre les trains de mise à jour de chacun.
Je dois avoir une dizaine de services sous docker dont la plupart sont sur la branche « latest ». L’update est gérée automatiquement via Watchtower (oui, j’aime vivre dangeureusement ).
Mais pour le reste, je me contente de suivre le flux RSS des releases sur Github/Gitlab de chacun et laisser l’article dans mon lecteur tant que je n’ai pas appliqué la mise à jour.
Il y a parfois des ratés et je me retrouve à louper quelques mises à jour. Non pas que je n’ai pas eu l’info d’une mise à jour. Juste que… j’ai zappé de l’appliquer, ou « pas le temps on verra plus tard ».
Il me manque juste un rappel, ou simplement un tableau de bord.
Je me demandais comment vous faites de votre côté ? Avez-vous un process particulier ? Ou un soft qui permet de répertorier l’intégralité de vos services avec la version actuelle et une alerte en cas de mise à jour de dispo ?
Pour les packages système, de mon côté c’est géré via unattended-upgrade (sur Debian) pour l’application des patch de sécu et mise à jour mensuelle via apt-dater.
Chez Chapril ça fait parti de nos procédures d’installation du service. L’idée c’est de remonter dans Icinga le maximum de choses, dont la disponibilité de mise à jour. Après, disponibilité ne signifie pas nécessité, et signifie encore moins qu’un bénévole va prendre le temps et la responsabilité de l’upgrade: c’est jugé au cas par cas.
Pour ce qui est de l’infra, très majoritairement sur la base des paquets distribués par Debian (stable), c’est un peu plus rôdé car on s’appuie sur le travail des packageurs. Donc suivi de la disponibilité des MaJ par Icinga et application automatique par unattended-upgrades. Application manuelle au cas par cas, soit en urgence, soit quand une personne peut s’en charger, soit avec une planification en amont (genre week end de travail). Par ailleurs plusieurs adminsys suivent la ML debian-security-announce@lists.debian.org.
Chez Picasoft on a un petit bot qui s’abonne aux API de Github, Gitlab, Gitea ou aux flux RSS. Il nous fait remonter sur Mattermost chaque mise à jour sortie.
Il est en cours de refonte pour que le code soit moins sale et plus maintenable, on planifie également la découverte automatique des services en route et des versions utilisées avec Docker.
Et bien sûr on a unattended-upgrade de configuré sur nos hyperviseurs et nos VM.
C’est une des raisons pour lesquelles j’utilise Yunohost : des mises à jour suivies par un collectif motivé et applicables en un clic, même depuis mon téléphone, et quelques soit la source réelle de l’app (paquet Debian, tar.gz, npm truc-machin, etc.).
Alors que par ailleurs (au boulot) j’utilise des systèmes plus complexes (type Docker, Swarm, Kubernetes, Ansible, Gitlab-ci, et tout plus ou moins mélangés), pour le serveur familial, je ne souhaite pas y passer beaucoup de temps, et donc j’apprécie la simplicité de la maintenance avec Yunohost.
En parallèle de ça j’utilise aussi unattended-upgrades, puisque ça tourne sur Debian et Proxmox VE.
De temps en temps aussi je contribue aux mises à jour des paquets, à faire passer une info s’il y a une mise à jour de sécu urgente, à tester les branches testing quand je suis motivé, etc.
C’est un vrai sujet. Ce qui est assez facile (même si ça demande une certaine discipline) c’est de:
Configurer unattended upgrades sur Debian pour profiter du travail des mises à jour de sécurité
Configurer unattended upgrades pour rebooter sans intervention manuelle en cas d’upgrade noyaux ce qui demande de corriger tout ce qui pourrait empecher un « reboot unattended »
Etre informé des mises à jour applicatives (via les diverses méthodes citées ci dessus)
Ce qui est beaucoup moins facile c’est de:
Lire les release notes correspondantes
Appliquer les mises à jour en comprenant ce qui disent les release notes
Et ce qui est encore moins facile c’est de:
Anticiper les lacunes des releases notes et les approximations des procédures de mises à jour pour ne pas mettre le service en vrac
Pour Enough l’essentiel du travail consiste à tester les mises à jour dans un environnement isolé (test d’intégration et pas pre-production) avant de les appliquer en production. Et c’est non seulement beaucoup de travail mais en plus ça ne suffit pas, donc c’est aussi des galères occasionnelles.
De mon côté je fais de l’infra as code avec Ansible, et j’ai installé Renovate sur mes repos, du coup je reçois les mises à jour automatiquement sous forme de PR.
Je pense même que c’est le vrai sujet. Déployer c’est facile, d’une certaine façon (surtout avec les .deb, les Docker, les SnapImagePack, etc.). Maintenir en conditions opérationnelles pendant 10 ans, sans forker et en maintenant le socle à jour, c’est ça qui fait la valeur ajoutée d’un hébergeur.
J’entends de plus en plus parler de renovate et une fois sur deux il s’agit d’une version propriétaire. Je suis curieux de savoir comment tu as fait pour l’installer sans tomber sur la version propriétaire ? Je suivrais probablement la même méthode
Je ne suis pas complètement open-source sur la gestion de mon infra : j’ai des repos sur Github (ils auraient pu être sur Gitlab.com, mais ça reste du SaaS), et du coup j’utilise l’application Renovate pour Github.
Dans un monde idéal, j’aurais pu tout mettre sur un Gitlab auto-hébergé et ma propre instance de Renovate (c’est ce qu’on fait dans ma boite), mais j’ai pas les moyens, pas le temps, etc. J’ai préféré mettre mes efforts autour de l’open-source sur les services que je propose en eux même.
Merci pour ce retour d’expérience. Ca confirme mon impression générale qu’utiliser renovate dans sa version logiciel libre est assez compliqué pour rebuter des gens pourtant assez motivés. Je n’irais pas jusqu’à dire que c’est du crippleware mais je n’en suis pas loin
@dachary tu es sur du Gitlab auto-hébergé ? Je pense que si tu as les ressources pour héberger un Gitlab, ça ne doit pas être si compliqué / couteux de faire tourner ton propre Renovate. Je viens de voir qu’ils proposent une méthode à base de Gitlab CI : WhiteSource Renovate / renovate-runner · GitLab
J’ai suivi les liens jusque cette page qui explique un passé propriétaire qui est devenu libre en 2019. Je me suis ensuite un peu perdu dans les explications et j’ai un mauvais pressentiment. J’avoue que je suis moyen motivé a passer du temps sur le sujet, raison pour laquelle j’ai posé ma question initialement. Je cherche un chemin qu’une personne me dit avoir suivit avec succès elle même. Je partagerais cette information ici quand/si je la trouve.
P.S. Oui, je fais tourner GitLab CE et aussi Gitea en auto-hébergé.
).
:
