Aplicar parches a un host de Docker¶
Traducción automática del original francés.
Aplicar las actualizaciones de paquetes sin detener los contenedores.
Principio¶
Los parches de seguridad se aplican por defecto, sin validación previa. Lo que se verifica es el después: ¿qué servicios dependían del paquete actualizado y se han restablecido correctamente?
Los siete hosts Linux del parque se parchean automáticamente durante la noche (registro del 2026-10-06: vm-claude, vm-docker, vm-addons, vm-agents, vm-compute-01, vm-compute-02, vps-fr-ovh; la propia pila del hipervisor permanece en parche manual); los reinicios, cuando son necesarios, se realizan entre las 00:05 y las 03:00. Un paquete eliminado genera una notificación que indica la acción de reemplazo, no solo el error.
Procedimiento manual¶
HOST="ssh -p <port-ssh> <user>@vm-docker"
# 1. ce qui est en attente
$HOST "sudo apt-get update -qq && apt list --upgradable 2>/dev/null | tail -n +2"
# 2. appliquer
$HOST "sudo DEBIAN_FRONTEND=noninteractive apt-get -y upgrade"
# 3. un redémarrage est-il nécessaire ?
$HOST "test -f /var/run/reboot-required && cat /var/run/reboot-required.pkgs || echo 'aucun redemarrage requis'"
# 4. quels services tournent encore sur des bibliothèques supprimées ?
$HOST "sudo needrestart -b"
apt upgrade puede ser un reinicio de dockerd disfrazado
En un host donde se actualiza el paquete docker-ce, la actualización reinicia el demonio — y, por lo tanto, según la política de reinicio, todo lo que se ejecuta encima. En vm-compute-01, que tiene la GPU y unas sesenta contenedores, esto nunca es trivial.
Verificar antes: apt list --upgradable | grep -E 'docker|containerd'.
Control posterior¶
# aucun conteneur ne doit être resté au tapis
$HOST "docker ps -a --filter 'status=exited' --format '{{.Names}}\t{{.Status}}'"
# et la politique de redémarrage doit être celle du fichier Compose
$HOST "docker inspect \$(docker ps -q) \
--format '{{.Name}} {{.HostConfig.RestartPolicy.Name}}' | grep -v 'on-failure'"
Una actualización importante desactiva los repositorios de terceros
Un do-release-upgrade desactiva los archivos .list de los repositorios de terceros renombrándolos a .save. Se ha constatado que los repositorios de Docker y Tailscale permanecieron desactivados tres meses, sin ninguna alerta — la máquina decía que estaba actualizada, y lo estaba, para los únicos repositorios que estaban activos.
Después de cualquier actualización:
Qué reinicia otras cosas además de uno mismo¶
Antes de aplicar la solución, es importante preguntarse quién depende del servicio afectado. Por ejemplo: reiniciar el contenedor VPN del grupo de descarga corta la red de todos los contenedores que comparten su pila de red, y docker ps lo muestra en funcionamiento.
Dernière vérification de cette page : 2026-09-08