Depuis la 0.0.69, suspendre les actions automatiques d’un conteneur tout en poursuivant sa surveillance.
1. Comprendre le périmètre
La maintenance suspend les actions des règles automatiques de cet agent. La collecte, les métriques, le journal et les actions manuelles continuent. Elle ne suspend pas les politiques de redémarrage Docker, les autres agents, les notifications externes ni la récupération de la démo après cinq minutes. Les actions déjà en cours ne sont pas interrompues.
2. Définir une durée limitée
Utilisez le même fichier d’état que votre processus cron ou serve et l’identifiant complet du conteneur :
monit-docker maintenance --state-file /var/lib/monit-docker/state.json --container-id FULL_CONTAINER_ID --duration 900
monit-docker maintenance --state-file /var/lib/monit-docker/state.json --container-id FULL_CONTAINER_ID --duration 0La première commande suspend les actions pendant 15 minutes ; la seconde reprend avant l’échéance. La durée est un nombre entier de secondes entre 1 et 86400 ; 0 annule. Ces commandes fonctionnent hors ligne et ne résolvent pas les noms de conteneurs. Un conteneur remplacé reçoit un autre ID et n’hérite pas de la maintenance.
3. Activer les commandes de l’interface
Utilisez les images assorties decryptus/monit-docker:1.3.3 et decryptus/monit-docker-ui:1.3.3. Ajoutez --allow-maintenance à votre commande serve --allow-actions en conservant les options d’origine, de jeton, d’état et de journal. L’interface propose 15 minutes, une heure et la reprise anticipée, avec confirmation. Les commandes restent désactivées sur les conteneurs protégés. La démo les active uniquement sur ses deux conteneurs de test.
4. Persistance, journal et reprise
L’échéance survit au redémarrage de l’agent. L’ordonnanceur reprend l’évaluation des règles après expiration. Les cooldowns et quotas de redémarrage existants restent applicables ; la maintenance ne les consomme pas. L’activation, les résultats, les actions suspendues et l’expiration automatique sont journalisés. Par prudence, les transitions réinitialisent les durées d’observation des conditions dans le fichier d’état partagé, y compris pour les autres conteneurs ; --trigger-after repart sur des observations fraîches.
La maintenance fait passer l’état local au schéma 4. Les anciens agents le refusent : préservez une sauvegarde et prévoyez la migration de l’état avant tout retour à une ancienne version. Synchronisez l’horloge du serveur. Le statut et les métriques affichent l’échéance et l’état de maintenance observés lors de la dernière collecte.