Mais" exec " est impossible lorsque le conteneur est arrêté, et ce conteneur contient également des données "fonctionnelles" à l'intérieur, utilisées pour ces commandes, donc je ne peux pas utiliser
docker run ...
chaque fois, parce qu'il recrée le conteneur à partir de l'image et détruit mes données.
Quelle est la "bonne" et la "meilleure" façon de faire fonctionner un tel conteneur? Quelle commande puis-je lancer à l'intérieur?
Vous n'avez pas besoin d'effectuer à chaque fois docker run.
docker run est en fait une séquence de deux commandes: "créer" et "démarrer".
Lorsque vous exécutez le conteneur, vous devez spécifier le "-it":
- i, interactive interactive=false Garder STDIN ouvert même s'il n'est pas attaché - t, --tty=false Allouer un pseudo-TTY
Exemple:
docker run -it debian:stable bash
Une fois le travail terminé, la commande spécifiée au démarrage (dans mon exemple bash). Par exemple, vous effectuez la "sortie". Arrêts de conteneurs:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES1329c99a831b debian:stable "bash" 51 seconds ago Exited (0) 1 seconds ago goofy_bardeen
Maintenant, vous pouvez le recommencer
docker start 1329c99a831b
Le conteneur est démarré et exécute à nouveau la commande "bash". Connectez-vous à cette session "bash" avec la commande
docker attach 1329c99a831b
Résumer: vous devez comprendre la différence entre les run et start conteneur. En outre, regardez le documentation pour le rôle des paramètres "-i t" et "-d"pour la "Course"
Puisque vous avez mentionné des tâches périodiques et que vous utilisez probablement quelque chose comme cron en raison de la façon dont vous souhaitez utiliser docker exec, J'ai juste le médicament pour toi. Au moins, j'ai fini par faire quelque chose comme ça.
Dockerfile
FROM <some base>CMD tail -f /dev/null
Courez avec l'habituel docker run -d .... (J'ai utilisé docker-compose)
Configurer des machines hôtes crontab, par exemple:
Je trouve cette solution intéressante car nous nous appuyons sur l'ancien et éprouvé crontab dans un environnement Linux assez par défaut, tandis que Docker gère les deps et les variables d'environnement plus exotiques de votre logique métier. Vous pouvez également définir des limites si vos tâches périodiques sont bloquées et présentent des fuites de mémoire ou autre.
La queue provoque encore certaines opérations sur les fichiers de temps en temps.
Dormez pour toujours, sans effets secondaires
# Ah, ha, ha, ha, stayin' alive...while :; do :; done & kill -STOP $! && wait $!
Comment ça marche
while :; # Run an endless loop,do :; # of do nothing,done & # as background task.kill -STOP $! # Stop the background task.wait $! # Wait forever, because background task process has been stopped.
Toute cette question de savoir si vous pouvez ou non démarrer un conteneur arrêté dépend de la façon dont le conteneur a été créé à l'origine, c'est-à-dire exécuté. Si vous avez exécuté une commande qui s'est terminée ou si vous quittez une commande interactive, par exemple bash, vous ne pouvez pas démarrer, redémarrer ou exécuter le conteneur arrêté. Tout ce que vous pouvez faire est de l'enlever. C'est de la camelote.
Mais le dernier commentaire de taranaki, utiliser '- itd', semble être ce que le docker a ordonné.
Le conteneur continue de fonctionner, et vous pouvez exécuter ce que vous voulez, et vous pouvez arrêter, démarrer ou redémarrer le conteneur. Bien sûr, ce n'est qu'une découverte préliminaire basée sur l'image alpine. Notez que si vous vous attachez au conteneur, il s'arrêtera lorsque vous quitterez, mais vous pourrez le redémarrer.
J'ai moi-même utilisé toutes les solutions proposées ici, mais toutes ne gèrent pas les signaux SIGTERM provenant du démon Docker lorsqu'il souhaite arrêter le conteneur (par ex. docker stop $containername).
Je propose donc ce qui suit:
FROM base:image# ...CMD sh -c 'trap "exit" TERM; while true; do sleep 1; done'
Il s'agit essentiellement d'un court script shell qui intercepte d'abord ("piège") les signaux SIGTERM, puis se met en veille pendant une seconde dans une boucle infinie.
Je l'utilise principalement avec docker-compose et Ophelia fournir des conteneurs latéraux pour sauvegarder un autre service dans un autre conteneur (par exemple, des bases de données MariaDB).