¿Cómo inicio automáticamente los contenedores acoplables en el arranque del sistema?


113

¿Cuál es una buena manera de iniciar automáticamente los contenedores acoplables cuando se inicia el sistema?

¿Hay alguna forma preferida de hacer esto en Ubuntu 14.04?

Lo he usado supervisorden el pasado para iniciar automáticamente aplicaciones web. Pero eso no parece ser lo correcto para Docker.

Respuestas:


136

Aparentemente, el método actual para iniciar automáticamente los contenedores Docker ( desde Docker 1.2 ) es usar políticas de reinicio . Esto controlará cómo Docker debe manejar el inicio del contenedor al iniciar y reiniciar el contenedor cuando sale. He usado la opción 'siempre' hasta ahora, y puedo confirmar que Docker inicia automáticamente el contenedor en el arranque del sistema:

sudo docker run --restart=always -d myimage

Extracto de documentación

Reiniciar políticas Con el indicador --restart en la ejecución de Docker, puede especificar una política de reinicio de cómo un contenedor debe o no reiniciarse al salir.

no: no reinicie el contenedor cuando salga.

en caso de fallo: reinicie el contenedor solo si sale con un estado de salida distinto de cero.

always: reinicia siempre el contenedor independientemente del estado de salida.

También puede especificar la cantidad máxima de veces que Docker intentará reiniciar el contenedor cuando use la política de falla. El valor predeterminado es que Docker intentará siempre reiniciar el contenedor.

$ sudo docker run --restart=always redis

Esto ejecutará el contenedor de redis con una política de reinicio de siempre, de modo que si el contenedor se cierra, Docker lo reiniciará.

$ sudo docker run --restart=on-failure:10 redis

Esto ejecutará el contenedor de redis con una política de reinicio de falla y un recuento máximo de reinicio de 10. Si el contenedor de redis sale con un estado de salida distinto de cero más de 10 veces seguidas, Docker abortará al intentar reiniciar el contenedor. Proporcionar un límite máximo de reinicio solo es válido para la política en caso de fallo.


12
"siempre: reiniciar siempre el contenedor independientemente del estado de salida" es un poco confuso. No reiniciará el contenedor si sale / detiene manualmente el contenedor, que es el comportamiento que estaba buscando.
w00t

12
Nota: unless-stoppedse agregó otra política llamada . Actúa así, alwayspero si se detiene el contenedor y se reinicia el sistema o si se reinicia el demonio de Docker, el contenedor no se reiniciará. Vea aquí una buena reseña
David Morales

44
Por supuesto, el dockerdemonio debe iniciarse automáticamente para admitir esto.
sherrellbc

Creo que la pregunta es "en el arranque del sistema", es decir, después del reinicio del servidor físico o virtual, ¿cómo se reinician automáticamente los contenedores, suponiendo que el motor de Docker se esté ejecutando completamente después del reinicio del servidor?
Root Loop

8

Docker tiene esta página que explica cómo hacerlo con upstart y systemd. Estoy de acuerdo en que no parece ser lo correcto para Docker. Su solución es ejecutar docker start, lo que supone que ya ha creado su contenedor. Creo que lo haría docker run --rmen la secuencia de comandos inicial (tratándolo como un proceso y un contenedor nuevos a partir de una imagen) o simplemente dejaría que el demonio docker reiniciara los contenedores en el arranque (como lo hará de forma predeterminada si no hace nada más ) Upstart tiene la ventaja de permitir un inicio / detención fácil de los procesos, ¡pero eso también se obtiene con el inicio / detención de Docker!

Creo que es extraño forzar al usuario a crear manualmente un contenedor (con todos los enlaces correctos de puerto / volumen) antes de que funcione el script inicial.


El enlace está roto ... Esto parece un posible reemplazo, pero ciertamente no muestra "cómo"
Gert van den Berg

Gracias, arreglé el enlace a una página similar, pero no puedo estar seguro de que diga lo mismo que el original.
Lawrence Kesteloot

6

Pero eso no parece ser lo correcto para Docker.

Por qué no?

Utilizo supervisor para esto con gran éxito.

Usa lo que sabes, usa lo que funciona, usa algo que puedas mantener y entender fácilmente.


Gracias @EEAA ... ¿eso significa que los ejecutas en modo no demonio? ¿Eso no significa también que necesitas ejecutarlos --rm?
Stefan Arentz

Ejecuto los contenedores en modo de primer plano y dejo que el supervisor capture stdout / stderr. No estoy seguro de por qué --rmes relevante aquí.
EEAA

@EEAA: sobre su pregunta: para algunas personas, dockeres un reemplazo de lxco openvzque tienen lxc.start.auto = 1y vzctl set --onboot yes. También ESXi y otras soluciones de virtualización tienen dicha característica incluida. Al igual que Lawrence, tampoco creo que una función de inicio automático de este tipo deba implementarse de una manera específica de distribución porque un usuario de Docker debería poder resolver el mismo problema con el mismo conocimiento en cada plataforma.
Daniel Alder

1
Correcto, Docker es una excelente manera de desacoplar el host de los contenedores en ejecución, por lo que usar la configuración específica del host es un poco un paso atrás.
nijave
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.