Pero "exec" es imposible cuando se detiene el contenedor, y también este contenedor tiene algunos datos "en funcionamiento" en su interior, que se utilizan para esos comandos, por lo que no puedo usar
docker run ...
cada vez, porque recrea el contenedor a partir de la imagen y destruye mis datos.
¿Cuál es la forma" correcta "y la" mejor " de mantener dicho contenedor en funcionamiento? ¿Qué comando puedo iniciar en el interior?
docker run es en realidad una secuencia de dos comandos: "crear" y "start".
Cuando ejecuta el contenedor, debe especificar el "-it":
- i, --interactive=false Mantener STDIN abierto incluso si no está conectado - t, --tty=false Asignar un pseudo-TTY
Ejemplo:
docker run -it debian:stable bash
Después de que se completó el trabajo, se especificó el comando al inicio (en mi ejemplo, bash). Por ejemplo, realiza la "salida". Paradas de contenedores:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES1329c99a831b debian:stable "bash" 51 seconds ago Exited (0) 1 seconds ago goofy_bardeen
Ahora puedes empezar de nuevo
docker start 1329c99a831b
El contenedor se inicia y de nuevo ejecuta el comando "bash". Conéctese a esta sesión "bash" con el comando
docker attach 1329c99a831b
Resumir: tienes que entender la diferencia entre el run y start contenedor. Además, mira el documentación por el papel de los parámetros "-i t" y "-d"para la "carrera"
Como mencionaste tareas periódicas y probablemente estés usando algo como cron debido a la forma en que quieres usar docker exec, Solo tengo la medicina para ti. Al menos terminé haciendo algo como esto.
Dockerfile
FROM <some base>CMD tail -f /dev/null
Corre con lo de siempre docker run -d .... (Yo solía docker-compose)
Encuentro esta solución agradable ya que podemos confiar en el antiguo y probado crontab en un entorno Linux bastante predeterminado, mientras que Docker maneja los departamentos y variables de entorno más exóticos de su lógica de negocios. También puede establecer algunos límites si sus tareas periódicas se atascan y tienen pérdidas de memoria o lo que sea.
La cola seguirá causando algunas operaciones de archivo de vez en cuando.
Duerma para siempre, sin efectos secundarios
# Ah, ha, ha, ha, stayin' alive...while :; do :; done & kill -STOP $! && wait $!
Cómo funciona
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.
Todo este asunto de si puede o no iniciar un contenedor detenido depende de cómo se creó originalmente el contenedor, es decir, se ejecutó. Si ejecutó un comando que finalizó, o si sale de un comando interactivo, por ejemplo, bash, no puede iniciar, reiniciar o ejecutar el contenedor detenido. Todo lo que puedes hacer es eliminarlo. Es basura.
Pero el último comentario de Taranaki, use '- itd', parece ser lo que ordenó la ventana acoplable.
El contenedor sigue ejecutándose, y puede ejecutar lo que quiera, y puede detener, iniciar o reiniciar el contenedor. Por supuesto, este es solo un hallazgo preliminar basado en la imagen alpina. Tenga en cuenta que si se conecta al contenedor, se detendrá cuando salga, pero puede volver a iniciarlo.
Yo mismo he usado todas las soluciones propuestas aquí, pero todas ellas no manejan las señales SIGTERM que provienen del demonio Docker cuando quiere cerrar el contenedor (p. ej. docker stop $containername).
Así que propongo lo siguiente:
FROM base:image# ...CMD sh -c 'trap "exit" TERM; while true; do sleep 1; done'
Básicamente es un script de shell corto que primero intercepta (" atrapa & quot;) señales SIGTERM y luego se duerme por un segundo en un bucle infinito.
Lo uso principalmente junto con docker-compose y ofelia para suministrar contenedores de sidecar para realizar copias de seguridad de algún otro servicio en otro contenedor (por ejemplo, bases de datos MariaDB).