Cómo usar las políticas de reinicio de Docker para mantener los contenedores en funcionamiento

Docker le brinda varias opciones para administrar el ciclo de vida de su contenedor. Los contenedores normalmente no se reinician automáticamente después de que terminan. Con las políticas de reinicio, puede tomar el control de los ciclos de vida de los contenedores individuales.

Las políticas de reinicio se utilizarán cada vez que un contenedor deje de ejecutarse. Docker también analiza las políticas de reinicio cuando se inicia el demonio. Puede usar este mecanismo para abrir contenedores con su host después de reiniciar.

Políticas disponibles

Actualmente existen cuatro políticas de reinicio diferentes:

• no – Esta política nunca iniciará automáticamente un contenedor. Esta es la política predeterminada para todos los contenedores creados con docker run .
• always – Docker se asegurará de que el contenedor esté siempre en ejecución. Si el contenedor se detiene, se reiniciará inmediatamente. Todavía puede detener manualmente el contenedor con docker stop pero Docker lo traerá de vuelta la próxima vez que se reinicie el demonio.
• on-failure – El contenedor se reiniciará si se detiene debido a un error. Docker no abrirá el contenedor después de que se reinicie el demonio.
• unless-stopped – Esto funciona de manera similar a always . La diferencia es que Docker nunca reiniciará el contenedor si se ha detenido manualmente.

Por lo general, utilizará una de las últimas tres opciones para las cargas de trabajo de producción. Como los contenedores de Docker a menudo se usan para servicios en segundo plano de ejecución prolongada, por lo general desea que se reinicien cada vez que algo sale mal. El no política se adapta mejor al uso del desarrollo local. También es útil para contenedores de utilidades que ejecutan un solo ejecutable y luego terminan.

Puede ser difícil decidir qué política de reinicio usar. always suele ser la opción más natural, pero el comportamiento de reinicio del daemon puede pasarse por alto fácilmente. Si desea que los contenedores permanezcan detenidos de manera confiable después de ejecutar docker stop , debe usar unless-stopped .

Docker detecta errores en función del código de salida emitido por el proceso de primer plano del contenedor. Un código de salida de 1 o superior se interpreta como un error. Esto coincide con el manejo de códigos de salida de Unix, donde solo 0 representa una ejecución exitosa.

Cuando Docker reinicia su contenedor, es equivalente a ejecutar docker run otra vez. Eso significa que el ENTRYPOINT de la imagen se invocará el script. Los sistemas Bootstrap siempre deben ser resistentes a múltiples invocaciones.

Aplicando una política de reinicio

Puede iniciar un contenedor con una política de reinicio específica pasando el --restart marcar para docker run :

docker run --name httpd --restart always httpd:latest

Si está utilizando Docker Compose, agregue el restart campo a su docker-compose.yml :

services:
  httpd:
    image: httpd:latest
    restart: always

Puede cambiar la política de reinicio de un contenedor existente usando docker update . Pase el nombre del contenedor al comando. Puede encontrar nombres de contenedores ejecutando docker ps -a .

docker update --restart-policy unless-stopped httpd

Puedes usar docker update con contenedores en funcionamiento o detenidos.

Reiniciar bucles

Docker incluye un par de protecciones contra bucles de reinicio perpetuos. El primero es un retraso de tiempo obligatorio antes de que se activen las políticas de reinicio. Docker no comenzará a monitorear los reinicios hasta que un contenedor se haya estado ejecutando durante al menos 10 segundos. Esto evita que un contenedor fallido se reinicie continuamente.

El otro comportamiento del especialista se refiere a la docker stop dominio. Docker siempre respetará el uso de docker stop , por lo que el contenedor no se reiniciará inmediatamente después de ejecutar el comando. Si realmente desea reiniciar el contenedor, use docker restart en su lugar.

Limitación de reintentos de reinicio

El on-failure La política de reinicio le permite especificar cuántos reintentos se deben intentar. Docker se dará por vencido y dejará el contenedor en un estado detenido si no se inicia varias veces seguidas.

docker run httpd:latest --restart on-failure:5

En este ejemplo, Docker intentará reiniciar el contenedor cinco veces después de una falla (código de salida distinto de cero). Si el contenedor no se inicia en el quinto intento, no se intentarán más reintentos. Esta opción es útil para contenedores en los que es poco probable que un error de inicio persistente se resuelva sin una intervención manual.

Investigando por qué se detuvieron los contenedores

Si necesita saber por qué se detuvo un contenedor, ejecute docker ps -a . Esto mostrará los detalles de todos sus contenedores, ya sea que estén detenidos o en ejecución. Busque el contenedor de destino y busque en su columna "Estado". Para contenedores detenidos, el código de salida se mostrará entre paréntesis. Si el código es mayor que cero, el contenedor finalizó debido a un error.

Deberá consultar la documentación del proceso que se ejecuta en el contenedor para determinar los significados de los códigos de error individuales. Sin embargo, a menudo puede obtener información sobre qué causó un bloqueo al recuperar los registros del contenedor. Los registros permanecen disponibles después de que se detiene un contenedor.

docker logs my-container

El flujo de registro agrega la salida estándar del contenedor y los flujos de error estándar. Si se registró el error, debe esperar verlo en las últimas líneas de salida.

Resumen

Las políticas de reinicio ayudan a garantizar que sus contenedores Docker estén allí cuando los necesite. El no predeterminado La política no es adecuada para la mayoría de las cargas de trabajo de producción. ¡No querrá que sus contenedores permanezcan detenidos si chocan!

El uso de una de las tres políticas con capacidad de reinicio hace que sus contenedores sean más resistentes a los reinicios de hardware y la terminación inesperada. Docker mantendrá la disponibilidad del servicio en caso de un bloqueo del contenedor.