2026-09-05 10:04 UTC
Replies (2)
-
@netappblackbox@mastodon.social 2026-09-05 10:26
Justo: el problema no era Docker ni LXC, sino la gestión de imágenes y volúmenes huérfanos. En ONTAP, lo equivalente sería limpiar snapshots y volúmenes FlexVol sin montar (localizalos con `volume show -space` y eliminalos con `volume delete`). La tabla de consumo sin limpieza previa solo mide el desorden, no la tecnología.
-
@Prozak@corteximplant.com 2026-09-05 12:43
@homelabista@mastodon.social un par de pensamientos sobre tu post, si me permites. Creo que la comparación tiene un problema más fundamental: comparas el estado observado de un host Docker contra una estrategia de deployment en LXC, sin considerar realmente la arquitectura en sí. Elaboro: Dangling images, contenedores detenidos, caché y volúmenes huérfanos no demuestran un problema de Docker como plataforma. La mayor parte de esa capa es deliberadamente desechable y debería someterse a pruning rutinariamente. Si un volumen no adjunto contiene datos importantes y no puedes determinar si es seguro eliminarlo, eso es un problema de gestión del almacenamiento persistente. El estado importante debe identificarse explícitamente, almacenarse, respaldarse y separarse de los artefactos de ejecución desechables. LXC en Proxmox no es solo una forma alternativa de empaquetar una aplicación. Elegir LXC puede ser una estrategia de infraestructura específicamente para obtener ciclo de vida gestionado por el hypervisor, límites de recursos, respaldo/restauración, networking y visibilidad a nivel de host, entre otras cosas. Docker dentro de un LXC tampoco es inherentemente una capa inútil. El LXC puede definir el límite de infraestructura o plataforma, mientras Docker proporciona el ciclo de vida de las aplicaciones en su interior. Si esa capa adicional es útil o no depende de la arquitectura. Contar artefactos acumulados en un host Docker y, a partir de eso, concluir ventajas conceptuales de LXC no establece realmente una comparación Docker vs. LXC. Compara el estado de mantenimiento de una implementación con las propiedades arquitectónicas de otra. Una comparación significativa comenzaría con workloads y requisitos equivalentes, definiría el estado persistente y qué capa es responsable de backup, después compararía deployment, fallos, reconstrucción, restauración y mantenimiento continuo bajo Docker, LXC, Docker-en-LXC y quizá una VM. De lo contrario, los 31 volúmenes mayormente nos dicen que este host Docker en particular tiene 31 volúmenes.