Docker le ofrece varias opciones para administrar el ciclo de vida de su contenedor. Los contenedores normalmente no se reinician automáticamente después de terminar. Con las políticas de reinicio, puede tomar el control de los ciclos de vida de los contenedores individuales.
La política de reinicio se utilizará siempre que un contenedor deje de ejecutarse. Docker también examina las políticas de reinicio cuando se inicia el demonio. Puede utilizar este mecanismo para recuperar contenedores con su host después de reiniciar.
Políticas disponibles
Actualmente hay cuatro diferentes reiniciar políticas:
no
- Esta política nunca iniciará automáticamente un contenedor. Esta es la política predeterminada para todos los contenedores creados condocker run
.always
- Docker se asegurará de que el contenedor esté siempre en ejecución. Si el contenedor se detiene, se reiniciará inmediatamente. Sin embargo, puede detener manualmente el contenedor condocker stop
pero Docker lo restaurará la próxima vez que se reinicie el demonio.on-failure
- El contenedor se reiniciará si se detiene debido a un error. Docker no mostrará el contenedor después de reiniciar el demonio.unless-stopped
- Funciona similar aalways
. La diferencia es que Docker nunca reiniciará el contenedor si se detuvo manualmente.
Por lo general, utilizará una de las últimas tres opciones para cargas de trabajo de producción. Dado que los contenedores Docker se utilizan a menudo para servicios en segundo plano de larga ejecución, normalmente desea que se reinicien cada vez que algo sale mal. La no
la política se adapta más al uso del desarrollo local. También es útil para contenedores de utilidades que ejecutan un solo ejecutable y luego terminan.
Puede resultar difícil decidir qué política de reinicio utilizar. always
suele ser la elección natural, pero el comportamiento de reinicio del demonio puede pasarse por alto fácilmente. Si desea que los contenedores permanezcan estacionarios de manera confiable después de la ejecución docker stop
, Deberías usar unless-stopped
.
Docker detecta errores según el código de salida emitido por el proceso en primer plano del contenedor. Un código de salida de 1
o superior se interpreta como un error. Esto corresponde al manejo Unix de códigos de salida, donde solo 0
representa una ejecución exitosa.
Cuando Docker reinicia el contenedor, es equivalente a ejecutar docker run
aún. Esto significa que la imagen es ENTRYPOINT
se invocará el script. Los sistemas Bootstrap siempre deben ser resistentes a múltiples invocaciones.
Aplicar una política de reinicio
Puede iniciar un contenedor con una política de reinicio específica pasando el archivo --restart
marcar un docker run
:
docker run --name httpd --restart always httpd:latest
Si está utilizando Docker Compose, agregue el restart
campo al tuyo 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 los nombres de los contenedores ejecutando docker ps -a
.
docker update --restart-policy unless-stopped httpd
puedes usar docker update
con contenedores en funcionamiento o detenidos.
Reinicia los ciclos
Docker incluye un par de protecciones contra ciclos de reinicio perpetuos. El primero es un retraso de tiempo obligatorio antes de que se active la política de reinicio. Docker no comenzará a monitorear los reinicios hasta que un contenedor se haya estado ejecutando durante al menos 10 segundos. Esto evita el reinicio continuo de un gabinete fallido.
El otro comportamiento del especialista se refiere a la docker stop
mando. 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 vez de.
Limitación de intentos de reinicio
La on-failure
la política de reinicio le permite especificar el número de intentos a realizar. Docker se rendirá y dejará el contenedor en un estado roto 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 un error (código de salida distinto de cero). Si el contenedor no se inicia en el quinto intento, no se realizarán más intentos. Esta opción es útil para contenedores donde es poco probable que un error de arranque persistente se resuelva sin intervención manual.
Investigar 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, detenidos o en ejecución. Busque el contenedor de destino y busque en su columna "Estado". Para contenedores estacionarios, el código de salida se mostrará entre paréntesis. Si el código es mayor que cero, el contenedor ha terminado debido a un error.
Debe consultar la documentación del proceso que se ejecuta en el contenedor para determinar el significado de los códigos de error individuales. Sin embargo, a menudo es posible obtener información sobre la causa del bloqueo recuperando los registros del contenedor. Los registros permanecen disponibles después de que se cierra un contenedor.
docker logs my-container
La secuencia de registro agrega la salida estándar del contenedor y las secuencias de error estándar. Si se ha registrado el error, debe esperar verlo en las últimas líneas de salida.
Resumen
Las políticas de reinicio ayudan a garantizar que los contenedores de Docker estén allí cuando los necesite. El valor por defecto no
la política no es adecuada para la mayoría de las cargas de trabajo de producción. ¡No querrás que tus contenedores se detengan si se atascan!
El uso de una de las tres políticas que admiten el reinicio hace que los contenedores sean más resistentes a reinicios de hardware y cierres inesperados. Docker mantendrá la disponibilidad del servicio en caso de que un contenedor se caiga.
Deja una respuesta