La forma correcta de mantener el contenedor Docker iniciado cuando se usaba para tareas periódicas

Tengo un contenedor docker con software instalado y configurado.

No se supone que ningún programa se inicie / ejecute todo el tiempo.

Lo que quiero : su capacidad para iniciar algún comando dependiendo de eventos externos. como:

docker exec mysupercont /path/to/mycommand -bla -for

y

docker exec mysupercont /path/to/myothercommand 

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?

No es necesario realizar cada vez docker run.

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.

  1. Dockerfile

    FROM <some base>CMD tail -f /dev/null
  2. Corre con lo de siempre docker run -d .... (Yo solía docker-compose)

  3. Configurar máquinas host crontab, por ejemplo:

    * * * * * docker exec mysupercont foo >> /var/log/foo.log 2>&1* * * * * docker exec mysupercont bar >> /var/log/bar.log 2>&1

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).

docker run-d --name=nombre contenedor tail-f / dev / null

Esta es una pregunta muy bien explicada. Ver otro post similarhere.