Tema: containers
-
¿Qué reglas de retención de imágenes mantienen pequeño un registro de contenedores sin eliminar imágenes que todavía están desplegadas?
Pregunta abierta: los registros solo recolectan como basura los blobs que ningún manifiesto referencia, y las políticas de ciclo de vida caducan imágenes por antigüedad, cantidad o patrón de etiqueta; ¿qué combinación de reglas han ejecutado los equipos durante años sin crecimiento ilimitado ni una reversión que fallara porque su imagen había desaparecido?
-
cgroups v2 en el host: comprobar el modo y leer los límites de recursos por unidad
Los runtimes de contenedores modernos y systemd dependen ambos de cgroups v2 (la jerarquía unificada) para aplicar límites de memoria y CPU. Esta metodología cubre confirmar que el host está en modo unificado, explorar el árbol con systemd-cgls/systemd-cgtop, y leer los límites reales de una unidad o un contenedor.
-
Códigos de salida de docker/podman run: 125, 126, 127 y los códigos de señal que se transmiten a través de ellos
docker run reserva 125, 126 y 127 para fallos del propio Docker, un comando que no se puede invocar y un comando no encontrado, respectivamente; cualquier otro código se transmite sin cambios desde el proceso del contenedor, incluidos los códigos 128+señal (137 para SIGKILL, a menudo por OOM; 139 para SIGSEGV; 143 para SIGTERM). Para confirmar una terminación por falta de memoria, la forma documentada es el indicador OOMKilled del contenedor, no el 137 por sí solo, aunque en algunos hosts con cgroup v2 devuelve false incluso tras una terminación por OOM del kernel.
-
Aislar en un sandbox las acciones de un agente: límites de sistema de archivos, red y credenciales
Un agente que ejecuta comandos o código debería hacerlo dentro de un límite que restrinja qué archivos puede tocar, qué hosts puede alcanzar y qué secretos puede leer; los contenedores con capacidades reducidas y un perfil seccomp, los núcleos en espacio de usuario como gVisor, una red denegada por defecto y credenciales de corta vida y alcance limitado son los componentes básicos.
-
Dimensionar una JVM dentro de un contenedor: porcentaje de heap, memoria fuera del heap y número de CPU
La JVM lee por defecto los límites de cgroup (UseContainerSupport) y dimensiona el heap como un porcentaje de la memoria del contenedor, no del host; el heap es solo parte de la huella, así que conviene fijar MaxRAMPercentage dejando espacio para el metaspace, las pilas de hilos, los búferes directos y la caché de código, comprobar el número de CPU que ve la JVM, y verificar con -Xlog:os+container y el seguimiento de memoria nativa antes de confiar en un límite.
-
El acceso al socket de Docker equivale a root en el host: lo que realmente otorga montarlo en un contenedor
Quien pueda hablar con el daemon de Docker puede iniciar un contenedor que monte el sistema de archivos raíz del host con acceso completo. Montar /var/run/docker.sock en un contenedor, añadir un usuario al grupo docker o exponer la API por TCP equivale, por tanto, a otorgar acceso root.
-
Diseño de Control en Godot: decidir quién controla la posición y el tamaño
Usa anclas y offsets para colocar elementos respecto al padre, deja que los contenedores organicen a sus hijos y revisa las restricciones de tamaño derivadas del contenido cuando una interfaz no respeta la geometría esperada.
-
Ejecutar contenedores Podman como servicios systemd con Quadlet
Quadlet permite que systemd administre contenedores Podman directamente a partir de archivos de unidad declarativos .container, en sustitución del flujo de trabajo en desuso podman generate systemd. Esta metodología cubre las ubicaciones de archivo para servicios de sistema y de usuario, la activación y la etiqueta de actualización automática.
-
Alpine Linux para agentes: apk add/del/upgrade, --no-cache en contenedores, y fijar la versión de un paquete
apk rastrea los paquetes solicitados explícitamente en /etc/apk/world y las fuentes de repositorio en /etc/apk/repositories; apk add/apk del editan ambos archivos junto con la instalación o eliminación de archivos, apk upgrade resincroniza el índice y actualiza todo lo que hay en world, y un paquete puede fijarse a una versión exacta o a un repositorio etiquetado. --no-cache omite por completo la caché local de paquetes, la forma que se usa al construir imágenes de contenedor.
-
musl frente a glibc en Alpine: por qué difieren algunos binarios preconstruidos, las ruedas (wheels) de Python y el comportamiento DNS
La biblioteca musl de Alpine no es compatible binariamente con glibc, tiene un solucionador DNS distinto (paralelo, sin recurrir a la búsqueda por dominio), usa por defecto la configuración regional C.UTF-8 en lugar de una base de datos de configuraciones regionales completa, y no admite el enlace perezoso de símbolos: diferencias que explican por qué fallan al ejecutarse los binarios enlazados con glibc, por qué se rechazan las ruedas manylinux de Python y por qué algunas configuraciones DNS heredadas se comportan de forma distinta. gcompat puede ejecutar algunos binarios de glibc sin modificar, pero no puede usarse para compilar software que a su vez requiera las cabeceras de glibc.
-
El error «detected dubious ownership in repository» de Git y la solución con safe.directory
Git se niega a operar en un repositorio cuyo propietario es distinto del usuario que ejecuta el comando y muestra 'fatal: detected dubious ownership in repository at'. El artículo explica la corrección de CVE-2022-24765 que hay detrás de este error, cuándo conviene una entrada safe.directory por repositorio y por qué chown es mejor solución en contenedores y CI.
-
Docker Compose para el desarrollo local: archivos override, perfiles, dependencias saludables y watch
Mantener un único compose.yaml confirmado en el control de versiones que refleje la forma de producción, añadir un compose.override.yaml para los puertos locales y los bind mounts, colocar las herramientas opcionales detrás de perfiles, hacer que depends_on espere a service_healthy, y usar develop.watch para sincronizar o reconstruir ante cambios de archivos.
-
Etiquetas frente a digests en imágenes de contenedor: nombres mutables y direcciones de contenido
Una etiqueta es un puntero legible para humanos que puede moverse a un manifiesto distinto en cualquier momento; un digest es el hash de los bytes del manifiesto e identifica exactamente una imagen para siempre. Conviene construir y probar por etiqueta, pero desplegar y fijar por digest, y registrar el digest en cada nota de release.
-
¿Qué métrica de memoria deben usar las alertas y los autoscalers en un servicio en contenedores: RSS, PSS, working set o memory.current de cgroup?
Pregunta abierta: el RSS de un proceso cuenta las páginas compartidas en cada proceso, memory.current de cgroup incluye la page cache y la memoria del kernel, y Kubernetes informa un working set heurístico. ¿Cuál se ha usado como señal de alerta y escalado en un servicio de larga duración sin generar avisos por cache recuperable ni pasar por alto la cercanía al límite de OOM?
-
Podman rootless frente a rootful en hosts de la familia RHEL: almacenamiento, subuid y lingering
Podman ejecuta contenedores como usuario normal (rootless) o como root (rootful), con ubicaciones de almacenamiento y límites de privilegios distintos. Esta metodología explica cómo inspeccionar contenedores en ejecución, localizar las rutas de almacenamiento, configurar los rangos subordinados de UID/GID y mantener activos los servicios rootless sin una sesión iniciada.
-
Dev containers: devcontainer.json como entorno de desarrollo reproducible
Un archivo devcontainer.json describe el contenedor que un editor, un espacio de trabajo en la nube o un ejecutor de CI debe construir para un repositorio: imagen o Dockerfile, features, puertos reenviados, comandos de ciclo de vida y personalizaciones del editor. La especificación abierta de containers.dev permite usar el mismo archivo en local, en espacios de trabajo alojados y en pipelines, de modo que la toolchain queda fijada junto al código en lugar de depender de cada host.
-
Requests y limits de recursos en Kubernetes: planificación, throttling y OOM kills
Un request es lo que el scheduler reserva para un contenedor y lo que el kubelet garantiza; un limit es lo que impone el kernel. Los límites de CPU provocan throttling, los de memoria provocan terminación del proceso, y la relación entre request y limit determina la clase de QoS del Pod y, con ello, quién es desalojado primero bajo presión del nodo.
-
Contenedores de sistema LXC/Incus: qué son y cuándo elegirlos en lugar de un contenedor de aplicación
Incus (una bifurcación comunitaria de LXD) gestiona contenedores de sistema y máquinas virtuales con una sola herramienta. Un contenedor de sistema ejecuta un sistema init completo y varios servicios, como una VM ligera, a diferencia de un contenedor de aplicación, construido en torno a un único proceso; conviene conocer esta diferencia antes de elegir uno u otro para una carga de trabajo en un host.
-
Diagnóstico de contenedores desde el host con lsns y nsenter
Cuando las propias herramientas de un contenedor son demasiado mínimas para depurar un problema de red, nsenter permite entrar en sus namespaces desde el host y ejecutar utilidades completas del host, como ss o ip, sobre el entorno del contenedor. Esta metodología explica cómo localizar el PID y el namespace del contenedor, y la diferencia entre entrar en todos los namespaces o solo en uno.
-
Administración del host de Docker Engine: daemon.json, uso de disco y live-restore
Administrar Docker Engine en un host implica trabajar con el archivo de configuración del daemon, no con los Dockerfiles de las aplicaciones: valores predeterminados de rotación de logs, ubicación de imágenes y contenedores, recuperación segura de espacio en disco y mantenimiento de los contenedores en ejecución durante un reinicio del daemon.
Legible por máquina: JSON