Estabilización de Contenedores podman rootless
Podman in the Wild - Episode 1.
1. Detención aleatoria de Contenedores o Pods
La detención aleatoria de los contenedores no se debe a fallos de la aplicación ni a herramientas de seguridad. El origen reside en la gestión de sesiones de usuario por parte de systemd para el UID 1000 (usuario zymo). En sistemas basados en RHEL (AlmaLinux, CentOS, Rocky Linux), systemd destruye procesos en segundo plano al terminar sesiones SSH o tareas cron, afectando el contexto "rootless" de Podman.
Secuencia de la caída (Logs):
Detonante: Cierre del User Manager para el UID 1000.
systemd[1]: Stopping User Manager for UID 1000...
Impacto (DB): Cierre rápido de la base de datos customer_gestion_db.
Impacto (App): Cierre forzado de Odoo (customer_gestion_app).
2. Soluciones Aplicadas
2.1. Persistencia de Usuario (Linger)
Habilita la persistencia para que el entorno del usuario corra en segundo plano indefinidamente.
# Ejecutar como root
loginctl enable-linger zymo
2.2. Modificación de la Política KillUserProcesses
Configura el sistema para evitar el cierre de procesos al terminar la sesión.
En /etc/systemd/logind.conf:
KillUserProcesses=no
Reinicio del servicio:
systemctl restart systemd-logind
2.3. Activación de podman-restart.service
Habilita el servicio que vigila y reinicia contenedores con política "always".
# Como usuario zymo
systemctl --user enable --now podman-restart.service
3. Verificación Final
Para asegurar la disponibilidad continua, verifica las políticas de reinicio:
Verificar contenedores:
podman inspect customer_gestion_app --format '{{.HostConfig.RestartPolicy.Name}}'
Verificar Pods:
podman pod inspect customer_gestion_prod --format '{{.RestartPolicy}}'
Verificar estado del servicio:
systemctl --user status podman-restart.service
Si la política responde 'always' o 'on-failure' y el servicio de reinicio está activo, el sistema es inmune a las interrupciones de sesión.
No hay comentarios:
Publicar un comentario