Mantenimiento del sistema

El área de Sistema cubre las tareas de mantenimiento que evitan que un host de Pier se llene o se quede atrás: limpiar Docker, vigilar el uso de disco, leer los registros de los servicios y actualizar Pier en sí.

Limpieza de Docker

Pier puede limpiar (prune) cuatro tipos de datos de Docker. La acción manual Clean ejecuta un prune -f inmediato para el objetivo que elijas:

Objetivo	Comando
Imágenes	docker image prune -f
Caché de compilación	docker builder prune -f
Contenedores	docker container prune -f
Caché de Railpack/BuildKit	buildctl prune dentro del contenedor buildkit

La limpieza también se ejecuta según una programación. La configuración de limpieza —habilitada, intervalo y qué objetivos limpiar— se refleja en una programación del sistema dentro del planificador unificado. La cadencia predeterminada es diaria; los intervalos de 1, 6, 12, 24, 48 o 168 horas se corresponden con la expresión cron equivalente. De forma predeterminada, la ejecución programada limpia imágenes y caché de compilación, deja en paz los contenedores y deja desactivada la caché de Railpack/BuildKit.

La limpieza manual de Railpack es agresiva — borra la caché de BuildKit por completo (--keep-storage 0 --keep-duration 0). La pasada programada es conservadora, conservando aproximadamente 10 GB / 7 días de caché para que no entre en conflicto con la compilación automática (Auto-build).

Uso de disco

Una vista de uso de disco desglosa la huella de Docker —imágenes, contenedores y volúmenes por separado, más el total de la caché de compilación—, ordenada de mayor a menor, con un total general. Un resumen de información de limpieza independiente indica cuánto es recuperable, incluida la caché de Railpack/BuildKit medida desde dentro del contenedor buildkit. Cuando Auto-build está deshabilitado o el contenedor buildkit no está en ejecución, la cifra de BuildKit simplemente muestra 0 en lugar de dar un error.

Registros del sistema

Pier expone los registros de journald para un conjunto estrictamente permitido de unidades de systemd (pier y pier-agent) para que puedas depurar problemas de ejecución y de arranque sin SSH. Dos modos:

• Instantánea — una extracción puntual, filtrable por ventana de tiempo (de 5 min hasta 7 días, o todo), número de líneas (30 / 100 / 500 / 1000 / 5000) y prioridad (err, warning, info, debug).
• Cola en vivo — un flujo por WebSocket (journalctl -f) que envía las nuevas líneas a medida que llegan.

Solo pueden consultarse las unidades de la lista permitida; cualquier otra se rechaza en la API.

Zona horaria

Una única zona horaria IANA (p. ej., Europe/Moscow) se almacena en la configuración y se usa para formatear las marcas de tiempo en las notificaciones salientes. El nombre se valida antes de guardarse, y los valores desconocidos recurren a UTC.

Autoactualización

Pier comprueba las releases de GitHub en busca de una compilación más reciente y compara el binario publicado con el que está en ejecución. El comportamiento de actualización se controla mediante un ajuste de modo:

Modo	Comportamiento
notify	Te informa de que hay una actualización disponible (predeterminado)
auto	Aplica las actualizaciones automáticamente
manual	No comprueba ni avisa

Aplicar una actualización descarga el binario, lo prepara en el directorio de datos y solicita al ayudante local privilegiado que lo intercambie y reinicie Pier. En instalaciones sin el ayudante, Pier recurre a un intercambio directo y a systemctl restart; si la instalación está reforzada y eso no está permitido, en su lugar muestra una sugerencia de actualización manual.

Próximos pasos

• Tareas programadas — el planificador que impulsa la limpieza.
• Alertas y notificaciones — las ejecuciones de limpieza emiten eventos de alerta.
• Refuerzo de seguridad — el aislamiento (sandboxing) que el actualizador sortea.