À partir de la version 1.3.3, l’agent exige HTTPdis 0.7.1 ou une version ultérieure. Si vous utilisez un fichier de mots de passe Basic, remplacez les empreintes SHA-1 et DES avant la mise à niveau.
Passer de la 1.3.0 à la 1.3.1
Dans le Compose de base, seul le proxy monte le socket Docker. L’agent peut lire l’état et les statistiques des conteneurs. Autorisez les sondes et commandes exec avec MONIT_PROXY_EXEC_TARGETS et les démarrages, arrêts ou redémarrages avec MONIT_PROXY_LIFECYCLE_TARGETS. Chaque liste contient les identifiants complets des conteneurs autorisés. Actualisez-les après une recréation.
L’installateur détecte le groupe du socket et s’arrête avant de remplacer un agent existant qui utilise le socket directement. Pour conserver les règles et le volume d’état, suivez la procédure de migration.
Mise à niveau depuis la 1.2.0
Mettez à jour l’agent et l’interface avant d’ajouter les sections serve, cron, stats ou monit. Pour revenir en 1.2.0, restaurez le fichier et la commande de démarrage précédents.
Chaque commande lit sa propre section. Une option explicite en ligne de commande l’emporte sur le fichier. Les listes de règles et de ressources passées au lancement remplacent la liste correspondante. Une lecture explicite avec monit --rsc écarte les actions configurées pour cette invocation. La simulation reste accessible avec --dry-run.
stats:
rsc: [cpu_percent, mem_usage]
output: json
serve:
interval: 60
status_token_file: /run/secrets/statusPour protéger GET et HEAD sur /v1/status, indiquez le chemin d’un secret distinct avec serve.status_token_file ou --status-token-file. Le client envoie le jeton Bearer. Avec le tableau de bord, configurez le proxy authentifié pour ajouter cet en-tête uniquement sur la route de statut vers l’agent.
Mise à niveau depuis la 1.1.4
Utilisez des secrets distincts pour les actions, les notifications, la lecture du journal et les métriques. Pour conserver un curseur par utilisateur, activez --trust-proxy-user uniquement derrière un proxy qui authentifie les utilisateurs, remplace l’en-tête de l’acteur et limite l’accès direct à l’agent. Sinon, les lecteurs partagent le curseur anonyme.
Par défaut, /metrics reste ouvert. Pour exiger une authentification, ajoutez serve --metrics-token-file FICHIER et configurez Prometheus avec le jeton Bearer correspondant. Ce réglage ne protège pas /v1/status.
Par défaut, l’agent attend 60 secondes la fin d’une commande Docker exec. Réglez kwargs.exec_timeout sur l’alias de commande (1 à 86 400 secondes). Après expiration, le résultat est inconnu : vérifiez le conteneur avant de réessayer, car la commande peut encore être en cours.
La version 1.2.0 proposait le proxy en option. Le fichier de surcharge reste accepté en 1.3.1.
Installation guidée en 1.1.4
La 1.1.4 est la première version publiée qui inclut install.sh. Depuis le dépôt cloné, lancez le script pour installer l’agent et son tableau de bord HTTPS local ou choisissez l’agent seul. Le script affiche le nombre de conteneurs après la première collecte. Installer pas à pas.
Pour une mise à niveau depuis la 1.1.3, conservez le même projet Compose, ses identifiants et ses volumes. Aucune migration du journal ou de l’état n’est nécessaire.
Dernier relevé complet en 1.1.3
Après un cycle en échec, le tableau de bord affiche le dernier relevé complet avec son heure, en lecture seule. Avant le premier cycle réussi, aucun historique n’est disponible.
La liste courante containers reste vide et /readyz renvoie 503. Le champ facultatif last_complete_snapshot contient les données historiques. Le champ failed_action identifie l’action et le conteneur quand ils sont connus.
Les règles et les alias acceptent les espaces autour des virgules dans les listes, par exemple status in (paused, running). La mise à niveau depuis 1.1.2 conserve la configuration et le journal.
Installer la version stable
python -m pip install 'monit-docker==1.3.3'
# Images correspondantes
# decryptus/monit-docker:1.3.3
# decryptus/monit-docker-ui:1.3.3Les images ciblent Linux amd64 ; le tag latest n’est pas mis à jour. Voir l’installation et les prérequis.
Corrections des règles dans la 1.1.2
Une unité non prise en charge comme 100 mb produit une erreur de syntaxe (code 140) sans traceback Python. Utilisez une unité reconnue comme MB, MiB, kB ou B. Une valeur incompatible avec le type mesuré, par exemple 1.5 pour mem_usage, produit une erreur de valeur (code 110) au lieu du code inattendu 150. Adaptez les scripts qui interprétaient ce dernier code.
Installation Compose et passage à la 1.1.2
Le Compose à la racine lance un agent serve en observation, sans action automatique par défaut. Une interface HTTPS authentifiée et un tutoriel mémoire sont disponibles. Consultez le démarrage rapide et le tutoriel mémoire.
Si vous utilisiez l’ancien Compose cron/PHP-FPM à la racine, conservez et relisez votre configuration avant de le remplacer : les anciens jobs MONIT_DOCKER_CRONS ne démarrent pas automatiquement dans cette nouvelle installation.
Aucune migration de configuration ou de schéma de journal n’est nécessaire depuis 1.1.1. Préservez configuration, état, budgets de redémarrage et journaux. Python 3.10+ reste pris en charge par l’agent. La mise à jour de Pillow concerne uniquement les outils de création des visuels.
Textual dans la 1.1.0
Installez monit-docker[textual] et lancez monit-docker tui --ui textual. Curses reste l’interface par défaut. Les deux interfaces terminal sont en lecture seule ; aucune intervention manuelle n’est déclenchée. Aucune migration de configuration ou de données stockées n’est nécessaire. Consultez le guide terminal et les captures actualisées.
Corrections de la 1.0.1
Un dépassement de délai de transport typé devient désormais MonitoringError(115), que le socket ou le watchdog expire en premier, y compris pendant la connexion ou la lecture des en-têtes. Les autres erreurs et le nettoyage des réponses conservent leur comportement. La validation structurelle YAML utilise Sonicprobe 0.3.57 ou ultérieur, sans modifier les sélecteurs, les priorités ni le traitement littéral des virgules.
Aucune migration de configuration ou de journal n’est nécessaire depuis 1.0.0. Conservez l’état, les budgets de redémarrage, les journaux et les archives. La limite de lecture du corps ne constitue pas un délai maximal absolu pour un cycle complet de supervision.
Ce que fixe la 1.0
Configuration YAML locale, commandes ponctuelles, cron, serve et interface terminal explicite en lecture seule. Une commande non interactive n’ouvre jamais curses. L’API conserve /v1. Les évolutions suivent la politique de dépréciation.
La publication inclut le contrôle de collecte des tests unittest, des lectures de statistiques Docker bornées, la normalisation des erreurs de sélecteurs et la restauration du terminal sur les signaux gérés. Les validations de paquets installés, images, interface et mises à niveau portent sur la même révision publiée.
Mettre à niveau depuis la bêta
Depuis 0.0.80, la validation YAML est partagée et stricte, un client inconnu est refusé, groupes et motifs directs se combinent par intersection, les virgules restent littérales et les comparaisons chaînées suivent l’ordre Python. Relisez vos règles : ces corrections peuvent modifier les actions exécutées.
# Plusieurs motifs : répéter l’option, sans découpage aux virgules
monit-docker --name 'web-*' --name 'api-*' stats
monit-docker -c config.yml check-config --output json
monit-docker -c config.yml run web-guard --dry-runArrêtez les processus qui écrivent pour sauvegarder configuration, état, journal et archives avec leurs droits. Testez sur des copies, conservez l’ancienne version et préservez séparément les données nouvelles avant un retour arrière. Ne réinitialisez pas les budgets de redémarrage et ne rejouez pas les actions historiques.
Les essais de publication couvrent les mises à niveau depuis 0.0.78, 0.0.79 et 0.0.82. La procédure détaillée précise sauvegarde, vérification et retour arrière ; cela ne certifie pas toute ancienne version.
Les vérifications automatisées couvrent les paquets installés, les images, l’interface et les mises à niveau. Ce correctif ne démontre ni l’absence de fuite ni la tenue sous saturation.
Validation et limites
La CI de publication 1.0.0 a réussi : suite applicative unittest, tests Docker/PTY dédiés, interface ordinateur/mobile et essais de mise à niveau/retour arrière. L’acceptation TUI par SSH a ensuite réussi le 28 septembre 2026. Les observations prolongées restent ouvertes jusqu’à l’analyse de leurs résultats.
Ces contrôles ne constituent ni une garantie de latence, ni une certification de tous les hôtes ou de toutes les pannes de stockage. La déduplication des actions manuelles est en mémoire, et un événement Docker OOM n’est jamais déduit du seul code de sortie 137.