Cuando Docker finaliza, todos sus contenedores se detienen. La instalación predeterminada no permite que los contenedores se ejecuten a menos que el daemon también esté activo. Aquí se explica cómo minimizar el tiempo de inactividad de la carga de trabajo manteniendo los contenedores activos durante una interrupción del demonio.
¿Por qué esto importa?
Docker ha demostrado ser un sistema confiable que es capaz de soportar soluciones en producción. Eso no quiere decir que sea infalible. Todavía podría encontrar un bloqueo que deje fuera de servicio al daemon y desconecte sus contenedores.
En otro escenario, el administrador de paquetes de su sistema operativo podría actualizar automáticamente Docker, lo que provocaría un reinicio del demonio y un breve período de inactividad. Idealmente, estas situaciones podrían resolverse sin ningún impacto en sus cargas de trabajo. Como el daemon solo gestiona contenedores, implementando comandos como docker run y docker rm , no hay una necesidad inherente de que permanezca durante el período intermedio en el ciclo de vida de un contenedor.
Restauración en vivo del contenedor
Docker admite un sistema llamado "restauración en vivo" que lo hace posible. En lugar de terminar los contenedores durante el cierre del demonio, Docker los mantendrá en funcionamiento. Continuará donde lo dejó una vez reiniciado.
La restauración en vivo debe habilitarse manualmente. Puede usarlo de forma única ejecutando dockerd con el indicador --live-restore flag :
sudo dockerd --live-restore
Para habilitar permanentemente la restauración en vivo, agréguela a su archivo de configuración del demonio de Docker. Esto generalmente se encuentra en /etc/docker/daemon.json . Deberá crear el archivo si aún no existe.
{
"live-restore": true
} A continuación, debe indicarle a Docker que vuelva a cargar su configuración. Una recarga no afectará a sus contenedores, a diferencia de un reinicio completo del demonio.
sudo systemctl reload docker
La restauración en vivo ahora debería estar activada. Puede probarlo deteniendo el demonio Docker.
sudo systemctl stop docker
Todos los contenedores en ejecución deben permanecer activos, aunque el daemon esté cerrado. No podrá usar docker comandos, ya que la conexión del demonio desaparecerá, pero los contenedores seguirán ejecutándose y conservarán sus conexiones de red.
Docker detectará automáticamente los contenedores existentes cuando se reinicie. Podrá continuar donde lo dejó, sin tener que sufrir ningún tiempo de inactividad.
Manejo de ejecución sostenida sin daemon
La ejecución de contenedores sin una conexión de daemon activa no debería tener consecuencias graves, incluso durante un período prolongado. Sin embargo, notará que los registros comienzan a perderse durante una interrupción prolongada del demonio.
Los contenedores Docker canalizan sus registros en un búfer de primero en entrar, primero en salir (FIFO). El demonio de Docker lee el contenido del búfer para crear los archivos de registro persistentes que ve con docker logs .
El tamaño del búfer predeterminado es de solo 64 K, por lo que puede agotarse si el daemon no está leyendo activamente su contenido. Cuando el búfer se llena, no se pueden manejar más registros hasta que el daemon complete un vaciado del búfer. Puede aumentar el tamaño del búfer editando el valor de /proc/sys/fs/pipe-max-size .
Advertencias de Live Restore
Live Restore debería cubrir la mayoría de los escenarios en los que el demonio Docker se apaga y luego se recupera. Esto incluye actualizaciones de Docker, pero solo entre versiones de parches menores. Si instala una nueva versión principal de Docker (como 19.03 a 20.10 ), Live Restore no se utilizará y el demonio Docker siempre se reiniciará.
Debe tener cuidado con el uso de Live Restore como una forma de editar la configuración del demonio Docker sobre la marcha. Cambiar algunas opciones, como las direcciones IP del puente, evitará que los contenedores se restablezcan correctamente cuando se reinicie el daemon. Si esto sucede, deberá detener manualmente todos los contenedores afectados y reemplazarlos por otros nuevos. Esta situación también podría surgir si su sistema operativo asigna una configuración de red diferente después de reiniciar.
Live Restore está diseñado para usarse durante las actualizaciones de Docker y las interrupciones no planificadas del daemon. Si necesita editar la configuración del daemon, intente planificar el tiempo de inactividad en su lugar. También puede usar systemctl reload docker para volver a cargar los archivos de configuración sin reiniciar completamente el daemon.
Todavía no hay Live Restore para contenedores basados en Windows. Tu puedes usar Live Restore activado Windows con contenedores basados en Linux. Está integrado en Docker Desktop y se habilita a través de Preferencias> Daemon> Avanzado.
Conclusión
Live Restore le permite minimizar el tiempo de inactividad disruptivo al mantener los contenedores en ejecución en ausencia del demonio Docker. Si necesita instalar una actualización urgente de Docker, o se encuentra con un bloqueo inesperado, sus cargas de trabajo deberían permanecer operativas mientras se reinicia el demonio.
La activación de Live Restore es un paso de práctica recomendada cuando se ejecuta Docker en producción. Las herramientas de análisis de configuración pueden marcar instalaciones que no lo tienen habilitado.
Más allá de usar Live Restore, debe asegurarse de que sus contenedores también tengan políticas de reinicio adecuadas. Usando restart: always hará que los contenedores individuales vuelvan a funcionar después de un reinicio del sistema operativo, o cualquier otro lanzamiento de daemon donde no se pueda usar Live Restore.