Je pose ça dans la rubrique « café » pour savoir si vous utilisez (et lequel) un outil pour effectuer le suivi de vos services, les mises à jour que vous faites, les modifs…
Actuellement j’ai un pauvre wiki, mais ça m’intéresserait de savoir comment vous vous organisez pour savoir quand vous avez fait une mise à jour de tel service, quelle est sa version, la customisation ou le correctif que vous y avez apporté.
En gros, je voudrais pouvoir rapidement savoir si j’utilise bien la dernière version de tel service ou si un service n’a pas été mis à jour depuis longtemps.
Je me dis qu’il doit bien y avoir un outil, sans doute un peu détourné, pour faire ça.
Pour ma part, je suis par rss ou mailing-list les nouvelles versions des outils que j’utilise/héberge. Puis en général je fais rapidement les mises à jour. Pour me rappeler des tâches à accomplir, j’utilise Deck de Nextcloud.
C’est tout !
Pour ma part c’est aussi très KISS (Simple & Stupid…) :
un fichier texte par « serveur » dans lequel je journalise tout ce que je fais (ou tout ce que je dois faire)
un fichier texte par « appli/service » qui contient :
les liens vers les sources officielles du projet,
le « comment je l’ai installé »,
le « comment je l’ai personnalisé le cas échéant ».
et c’est tout !
Ensuite, c’est de la discipline dans le sens où je m’astreins à des opérations de maintenance hebdomadaires (serveurs & services), opérations qui consistent entre autres à prendre des nouvelles de chaque appli/service en allant directement aux sources !
Cette « bête » gestion, à base de fichiers texte est facile à partager au cas où tu dois laisser les clés de ton infra à quelqu’un d’autre (pendant tes vacances)… Quant à ton Wiki, c’est une solution qui me parait encore un niveau au dessus de la mienne et qui n’est pas du tout « pauvre »
De mon côté j’ai un Readmin avec un projet privé. Comme ça j’ai un wiki pour la doc, un dépôt GIT avec tout les /etc de mes serveurs comme ça je peux lier des « demandes » à des changement sur les serveurs…
Dans un monde idéal tu n’inventorie pas les versions : tu fais apt update && apt upgrade. Bon … ok. Le monde est idéal pour plein de choses (apache, nginx, openssl, …) mais pas partout et pour tout.
Si tu fais du déploiement par Ansible comme c’est le cas pour Enough, c’est l’inventaire et la base de code qui désigne explicitement c’est quoi qui est où. Et c’est la base de code qui paramètre les versions, les modifications, etc. L’avantage c’est que c’est très proche de la prod : cette dernière est vraiment un reflet fidèle du dépôt de code (et peut être dupliquée facilement pour des tests).
Si tu fais du déploiement à la main comme c’est le cas pour Chapril, c’est moins parfait mais c’est important de conserver des traces (documentation) :
Chez nous le choix de dokuwiki est notamment guidé par le fait que le stockage de la doc sur des fichiers facilite la production d’un miroir dans git, synchronisé sur les postes des admins. Ainsi, même en cas de désastre, on a accès à notre doc.
Toutefois on évite de mettre en doc des choses très périssables comme des versions car sinon on est sûr que la doc ne sera jamais à jour (plus généralement, plus on duplique de l’information plus on est sûr qu’on trouvera à terme des incohérences).
Donc pour tout un tas d’applications, on surveille que la version en prod colle à la version upstream grâce à la supervision (exemple : https://agir.april.org/issues/4832). Pour les correctifs importants ou susceptibles d’être perdus, même traitement : une sonde dans la supervision. La supervision est un super système de non-régression, bien plus efficace qu’une doc.
Merci @PoluX super idée que ce script de test de dernière version. Il faut le bricoler pour chaque service (mutualiser ?), mais ça évite en effet d’avoir à aller checker régulièrement les releases de chaque service pour voir si ça a bougé. J’ai un zabbix qui peut faire ça.
Même chose pour la forge avec les issues qui servent de trace des opérations de maintenance, super idée.
Habituellement je mettais ça dans le dokuwiki, j’ai le même genre que le wiki.chapirl, garder traces des procédures d’install pour chaque service.
Je n’ai pas vraiment compris ce que faisait Enough, j’ai surtout vu Ansible pour déployer automatiquement des trucs (install ou mise à jour), mais je n’ai pas compris comment Enough fonctionne.
Oui, malheureusement. À l’April on commence à avoir une petite collection de scripts de ce genre, pour spip, dotclear, matomo, piwigo, yourls, gitea, etc. et les services chatons (dispersés dans la forge).
