Faites d'un agent un service, pas un terminal oublié.

Empaqueter le worker

Utilisez un environnement d'exécution pris en charge, des dépendances épinglées et un gestionnaire de services ou un conteneur. Configurez des limites de redémarrage et un utilisateur de service dédié. Conservez les identifiants privés du fournisseur dans une configuration protégée, hors des fichiers publics de l'application.

Enregistrez votre progression avant que les actions n'aient d'importance

Utilisez une file d'attente ou une base de données durable pour les tâches. Attribuez un identifiant d'opération unique, enregistrez les requêtes externes et réconciliez les résultats incertains. Un redémarrage ne doit pas envoyer un second e-mail, créer une seconde commande ni facturer deux fois.

Ajouter une observabilité utile

Surveillez l'achèvement des tâches, l'ancienneté de la file d'attente, le taux d'erreur et le coût plutôt que de vérifier uniquement l'existence d'un processus. Gardez des journaux suffisamment petits pour être examinés et masquez les jetons, invites et documents qui n'ont pas besoin d'être conservés.

Fixez un plafond clair

Limitez les dépenses du modèle, la concurrence du navigateur, la durée d'exécution et le nombre de tentatives. Prévoyez un interrupteur de pause facile et un parcours de revue humaine pour les actions à conséquences. Un worker plus petit et bien observé est plus facile à approuver qu'un worker sans restrictions.

Utilisez un superviseur et une planification réfléchie

Systemd et Docker sont des moyens courants de faire survivre un processus à une déconnexion du terminal. Pour un service systemd, Type=exec peut signaler un échec d'exécution plus directement qu'un simple lancement en arrière-plan, et Restart=on-failure peut redémarrer les échecs selon une politique encadrée. Les tâches planifiées doivent éviter les exécutions qui se chevauchent. Rendez explicites le répertoire de travail, l'utilisateur du service et l'environnement. L'exemple suppose que l'utilisateur koala-agent, l'environnement virtuel, le module worker et le fichier d'environnement privé existent déjà ; adaptez-les avant d'installer une unité.

• Utilisez un compte de service dédié
• Définir un délai de redémarrage et un plafond d'échecs
• Vérifiez l'état de la tâche précédente avant de lancer une exécution planifiée

[Unit]
Description=Example agent worker
After=network-online.target

[Service]
Type=exec
User=koala-agent
WorkingDirectory=/opt/koala-agent
EnvironmentFile=/etc/koala-agent.env
ExecStart=/opt/koala-agent/.venv/bin/python -m worker
Restart=on-failure
RestartSec=10
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

Documentation officielle : Sémantique des services systemd

Définissez un budget quotidien et une limite de doublons

Fixez au worker un nombre maximal de requêtes, une limite de dépenses et un délai d'exécution. Utilisez un enregistrement d'idempotence durable pour les actions qui affectent le monde extérieur. Un clic réussi dans le navigateur peut se produire avant que le processus ne reçoive une réponse ; inspectez l'état externe avant de réessayer. Les montages de secrets Docker Compose peuvent garder un secret hors de l'image, mais les permissions et l'application consommatrice doivent encore être vérifiées.

Documentation officielle : Secrets Docker Compose

Donnez à une tâche périodique une politique de rattrapage explicite

Utilisez un service de longue durée pour un worker de file d'attente persistant et un service oneshot déclenché par minuterie pour une tâche planifiée bornée. Avec une minuterie calendaire systemd, Persistent=true peut déclencher une activation manquée après une indisponibilité ; cela ne recrée pas tout un arriéré métier. Décidez si ce rattrapage est souhaitable. RandomizedDelaySec peut répartir les démarrages, tandis qu'un bail au niveau applicatif empêche deux réplicas de traiter la même tâche planifiée.

• Enregistrez le fuseau horaire prévu et vérifiez les prochaines heures d'exécution avant d'activer la planification.
• Maintenez la date limite d'exécution de la tâche plus courte qu'un intervalle qui ne doit pas se chevaucher, ou utilisez un bail durable avec expiration et propriété.
• Faites en sorte que la tâche sélectionne le travail en attente à partir de l'état stocké plutôt que de supposer que chaque événement de minuterie précédent s'est exécuté.
• Vérifiez la version de systemd installée avant d'utiliser une directive issue du dernier manuel.

# Read-only checks after creating your own matching units.
systemctl list-timers --all
systemctl status koala-agent.service
journalctl -u koala-agent.service --since today --no-pager

Documentation officielle : systemd : planification par timer

Distinguez une boucle de plantage d'un worker bloqué

Une politique de redémarrage peut rétablir un processus en échec, mais répéter toutes les quelques secondes un identifiant invalide ou une migration cassée rend la panne plus bruyante. Bornez les démarrages du service et alertez en cas d'échec répété. Un processus actif peut aussi être bloqué : mesurez l'âge de la tâche la plus ancienne et de la dernière opération terminée. Testez une panne API, un disque vide et un arrêt de processus avec des tâches jetables, puis vérifiez que l'état durable empêche les actions externes en double.

• Définissez un budget de fournisseur et un délai d'expiration des requêtes dans l'application, ainsi qu'une limite CPU/mémoire sur l'environnement d'exécution.
• Les conteneurs Docker n'ont pas de limite de mémoire utile propre à la charge de travail du seul fait qu'ils sont des conteneurs ; configurez et testez les limites délibérément.
• Stockez un secret hors de l'image et de l'arborescence publique, puis vérifiez que les journaux de plantage et les diagnostics le masquent.
• Maintenez une procédure d'arrêt manuel et exigez une validation appropriée pour les dépenses, les écritures en production ou les messages externes.

Documentation officielle : systemd : supervision des services · Docker : contraintes de ressources des conteneurs