Qu’est-ce qui fait que les tâches planifiées s’exécutent sur l’hôte, mais pas dans un conteneur ?
Les tâches planifiées échouent dans un conteneur lorsque le planificateur, l’environnement, l’utilisateur, l’heure ou le chemin d’exécution requis diffère du contexte fonctionnel de l’hôte.
Une commande qui réussit dans un shell interactif sur l’hôte peut dépendre du PATH de l’hôte, du profil de connexion, du fuseau horaire, des fichiers montés, des identifiants, du DNS ou d’un démon cron exécuté en continu. Dans un conteneur, rien de tout cela n’est garanti. Commencez par vérifier qu’un processus de planification est actif, puis exécutez la tâche exacte avec le même environnement minimal et le même utilisateur que ceux utilisés par cron.
Vérifier qu’un processus de planification est réellement actif
Inspectez les processus actifs du conteneur et sa commande de démarrage. L’installation de paquets cron dans l’image ne démarre pas le démon, et un conteneur n’exécute généralement que le point d’entrée ou la commande configurée.
La longue discussion de Stack Overflow consacrée à cron dans Docker souligne qu’il faut exécuter un planificateur dans le conteneur, plutôt que de supposer que le service de l’hôte contrôle sa crontab. Le premier élément à vérifier est de savoir si le processus cron est actif au moment prévu.
Si aucun planificateur ne s’exécute, choisissez une architecture délibérée : exécutez cron ou un planificateur adapté aux conteneurs comme processus au premier plan, utilisez un conteneur dédié aux tâches, ou invoquez le conteneur applicatif depuis le cron de l’hôte. N’ajoutez pas un second démon non géré sans décider comment il sera journalisé et arrêté.
Exécuter la commande exacte avec un environnement minimal
Copiez la commande planifiée et exécutez-la dans le conteneur avec l’utilisateur prévu pour la tâche et un environnement réduit au minimum. Capturez la sortie standard, la sortie d’erreur, le code de sortie, le répertoire courant et les variables d’environnement.
Les tâches cron dans les conteneurs échouent souvent parce que cron ne charge pas le profil du shell interactif qui fournissait le PATH, les environnements d’exécution, les jetons d’API ou les variables de l’application. Un guide consacré à la planification dans les conteneurs souligne que la conservation de l’environnement requis par la tâche est essentielle.
Si la commande échoue uniquement dans l’environnement minimal, ajoutez des chemins absolus explicites et uniquement les variables nécessaires. Évitez de charger un profil utilisateur complet qui introduirait des alias, des invites ou des secrets sans rapport.
Vérifier le PATH, le shell, le répertoire de travail et l’utilisateur
Remplacez les commandes et chemins de fichiers relatifs par des chemins absolus. Vérifiez que le shell sélectionné existe et que la syntaxe de la crontab correspond à l’implémentation de cron installée dans l’image.
Exécutez la tâche avec l’utilisateur cron configuré et testez les droits de lecture, d’écriture et d’exécution sur les scripts, les fichiers de configuration, les sockets et les répertoires de sortie. Un test manuel effectué uniquement avec les droits root ne prouve pas qu’une tâche planifiée sans privilèges pourra s’exécuter jusqu’au bout.
Définissez le répertoire de travail dans la commande ou le script d’encapsulation. Si la tâche réussit après avoir uniquement changé de répertoire ou d’utilisateur, conservez explicitement ce contexte dans une configuration versionnée plutôt que de dépendre des valeurs par défaut du conteneur.
Comparer l’heure et le fuseau horaire du conteneur avec la planification
Affichez l’heure actuelle, le fuseau horaire et la prochaine exécution prévue dans le conteneur. Les conteneurs partagent l’horloge du noyau de l’hôte, mais peuvent utiliser UTC ou des fichiers de fuseau horaire différents pour l’affichage et l’interprétation de cron.
Un cas présenté sur Server Fault montre que l’heure d’un conteneur peut s’afficher dans un autre fuseau horaire alors que l’hôte affiche l’heure locale, ce qui fait s’exécuter une crontab correcte à la mauvaise heure locale apparente.
Choisissez une stratégie explicite pour le fuseau horaire et vérifiez-la après chaque recréation. Ne compensez pas le problème en décalant l’expression cron tout en laissant le fuseau horaire sous-jacent ambigu, car le passage à l’heure d’été ou une modification de l’image pourrait à nouveau la décaler.
Vérifier les montages, les secrets, l’accès réseau et la durée de vie du conteneur
Vérifiez que chaque répertoire d’entrée, chemin de sortie, secret, socket et fichier de configuration existe dans le conteneur au moment de l’exécution. Testez ensuite l’accès au DNS, à la base de données, à l’API ou au NAS depuis le même réseau de conteneurs.
Le cron de l’hôte peut accéder à des chemins de l’hôte qui sont absents du conteneur. Un cas Nextcloud avec Docker montre qu’une tâche d’arrière-plan peut sembler configurée alors que la commande, l’utilisateur ou le chemin applicatif du conteneur empêche encore l’exécution en arrière-plan attendue.
Vérifiez également que le conteneur reste actif lorsque l’heure prévue arrive. Les conteneurs applicatifs de courte durée et les remplacements lors des déploiements peuvent arrêter un planificateur interne avant la fin des tâches longues ou peu fréquentes.
Choisir une seule limite de planification et prouver que l’exécution sans surveillance fonctionne
Attribuez la planification à un seul composant : le cron de l’hôte qui invoque docker exec, un conteneur de planification dédié ou un planificateur au premier plan dans l’image applicative. Des planificateurs en double peuvent exécuter deux fois la même tâche de maintenance.
Le guide de ZimaSpace consacré aux tests DNS côté conteneur décrit une cause secondaire possible lorsque le planificateur démarre, mais ne parvient pas à joindre un autre service.
Le problème n’est résolu que lorsque la tâche s’exécute à l’heure prévue après la recréation du conteneur et le redémarrage de l’hôte, génère des journaux capturés, utilise l’utilisateur et les chemins attendus, et produit le résultat applicatif vérifié. Une commande manuelle réussie ne constitue pas le test final.
Produits recommandés
Assistance et conseils
Plus à lire
Pourquoi la restauration d’un volume Docker recrée-t-elle le contenu des fichiers, mais supprime-t-elle les attributs étendus ?
Un diagnostic de restauration de volume couvrant l’inventaire des xattr, les options de tar et de Rsync, les espaces de noms, la prise en...
Pourquoi un conteneur en cours d’exécution conserve-t-il son ancienne limite de mémoire après la modification du fichier Compose ?
Un diagnostic des limites mémoire couvrant les cgroups actifs, le redémarrage par rapport à la recréation, les champs Compose, les limites strictes et souples,...
Pourquoi le redémarrage d’un proxy inverse invalide-t-il toutes les sessions d’une application auto-hébergée ?
Un diagnostic de perte de session couvrant la portée des redémarrages, la propriété des cookies, la rotation des secrets, les sessions adossées au cache,...
