- Podman es daemonless, compatible con OCI y permite operar en modo rootless con seguridad reforzada.
- UBI, Buildah y Skopeo forman un stack sólido para construir, firmar y distribuir imágenes.
- Pods, YAML de Kubernetes y unidades systemd facilitan del entorno local al despliegue estable.
Si tu objetivo es lanzar contenedores ligeros en Linux con máxima seguridad y control, Podman es de las mejores cartas que puedes jugar. Comparte el ecosistema OCI, ofrece una CLI muy familiar para quien venga de Docker y, sobre todo, elimina el daemon central, reduciendo la superficie de ataque y el consumo de recursos.
Este recorrido práctico y a fondo reúne lo más relevante de las guías de Red Hat, SUSE y herramientas afines como Buildah y Skopeo. Vas a ver cómo instalar, configurar y operar contenedores y pods, crear imágenes eficientes (incluidas UBI), generar ficheros YAML para Kubernetes o unidades systemd y, de paso, aprender a moverte con soltura por registros, políticas de confianza, healthchecks y eventos.
Qué es Podman y por qué destaca para contenedores ligeros
Podman es un motor de contenedores sin daemon que cumple con las especificaciones OCI y permite ejecutar, construir y gestionar imágenes y contenedores con una sintaxis prácticamente idéntica a la de Docker. La gran diferencia es arquitectónica: no hay un proceso maestro root en segundo plano al que mandar peticiones, lo que simplifica la seguridad y el modelo operativo.
Otra baza clave es el soporte de rootless: los usuarios no privilegiados pueden crear y ejecutar contenedores sin elevar permisos. Esto no solo es más seguro; también mejora la trazabilidad, porque las acciones se asocian al usuario real del sistema y no a un daemon que corre como root.
La compatibilidad con la CLI de Docker está muy pulida. Puedes usar comandos como podman build, podman run o podman images casi del mismo modo. Incluso existe el paquete podman-docker que crea un alias para que al ejecutar docker se invoque Podman de forma transparente, algo útil cuando hay scripts heredados.
Podman adopta el concepto de pods de Kubernetes: agrupar varios contenedores que comparten red y ciertos espacios de nombres. Es ideal para componer servicios que cooperan entre sí (por ejemplo, una base de datos y su cliente) y para generar descripciones portables hacia Kubernetes mediante YAML, por ejemplo para integrar Docker en Kubernetes.
En el ecosistema empresarial, Red Hat sustituyó el motor Docker en RHEL 8 por un stack sin daemon basado en Podman, Buildah y Skopeo. Además, promueve imágenes UBI redistribuibles para construir sobre una base de calidad RHEL sin ataduras de suscripción en destino.
Instalación y requisitos por distribución
En RHEL 8 y derivados, lo más cómodo es habilitar el módulo de container-tools, que arrastra Podman, Buildah y Skopeo. Tras registrar el sistema si procede, instala el módulo disponible y tendrás el conjunto listo para trabajar con contenedores de forma integrada.
En Fedora, el paquete está en repos y se instala con el gestor de paquetes habitual. En Ubuntu (20.04 en adelante) se puede instalar con APT desde los repos estándar o añadir el PPA estable de libcontainers para ir a la última. En SLE Micro, Podman viene de serie, y si faltase se puede añadir siguiendo la documentación oficial de SUSE.
Comprueba el entorno con podman info para ver detalles de almacenamiento, cgroups, compatibilidad rootless y complementos. Un arranque rápido y ligero para verificar red y DNS consiste en ejecutar un contenedor Alpine interactivamente con un simple podman run –rm -it alpine sh.
Si piensas compilar o consumir imágenes de Red Hat protegidas (por ejemplo en registry.redhat.io), recuerda que necesitas autenticación con credenciales válidas del portal, mientras que registry.access.redhat.com ofrece acceso sin autenticación a parte de su catálogo.
Trabajar en modo rootless: configuración y límites prácticos
El modo rootless es una de las funciones más interesantes de Podman. Para habilitarlo correctamente conviene ajustar namespaces de usuario y mapas de subuid y subgid. Si vienes de sistemas antiguos o cuentas preexistentes, revisa los ficheros /etc/subuid y /etc/subgid para asignar rangos suficientes a cada usuario.
La orden podman unshare te permite entrar en el namespace del usuario y verificar los mapeos efectivos de UIDs y GIDs. Es útil para diagnosticar por qué un contenedor rootless no puede acceder a determinados ficheros o por qué un volumen remoto falla con ese usuario.
Hay restricciones importantes: un contenedor en modo rootless no puede abrir puertos menores de 1024. En escenarios de desarrollo puedes cambiar el parámetro del kernel para habilitar puertos no privilegiados más bajos o usar redirecciones de puerto en el host para llegar al 80 o 443 sin elevar permisos.
También existen servicios que requieren privilegios globales, como ajustes de tiempo del sistema. Si ejecutas un ntpd dentro de un contenedor rootless y le concedes capacidades inapropiadas, puedes acabar afectando al host. Es preferible mantener esos demonios en el sistema o usar pods/servicios con los límites correctos.
Un detalle operativo: el almacenamiento de contenedores rootless debe vivir en un sistema de ficheros local. Montajes remotos suelen dar guerra con los namespaces de usuario. Además, si tu autenticación de usuarios viene de LDAP o Active Directory, tendrás que mantener rangos estáticos de subuid y subgid en local para que el mapeo funcione bien.
Búsqueda, extracción y política de confianza en registros
Podman consulta por defecto los registros listados en /etc/containers/registries.conf. Como root puedes modificar la configuración de sistema; como usuario sin privilegios, puedes anularla creando tu propio fichero en $HOME/.config/containers/registries.conf para ajustar prioridades, espejos o marcar registros inseguros en tu sesión.
Para localizar imágenes usa podman search. Puedes buscar en todos los registros definidos o limitar por dominio y, si necesitas resultados completos, añadir –no-trunc. Si un registro requiere credenciales, inicia sesión previamente para que el listado muestre repos privados accesibles.
La política de confianza permite verificar firmas de imágenes. Se define en /etc/containers/policy.json y en los YAML de /etc/containers/registries.d/. Red Hat publica firmas para sus imágenes; puedes añadir secciones específicas para registry.access.redhat.com y registry.redhat.io, indicando las URLs de sigstore que el sistema debe consultar al hacer pull.
Si cambias la política por defecto a reject, solo podrás extraer de ámbitos firmados o explícitamente permitidos. Esto es útil para endurecer servidores de build o entornos regulados. Puedes comprobar la política activa mostrando el JSON de policy y probar con una ubi8-minimal para ver cómo se valida la firma durante el pull.
Es muy recomendable usar nombres totalmente cualificados al hacer pull, indicando registro, espacio de nombres, repositorio y etiqueta. Evitas suplantaciones de nombres cortos y de paso documentas mejor el origen de cada imagen en tus scripts.
Imágenes base UBI y construcción con Buildah
Las UBI (Universal Base Images) de RHEL 8 son base oficial con licencia de redistribución libre. Tienes sabores estándar, minimal e init, además de imágenes de tiempos de ejecución por lenguaje (como Python, PHP, Ruby o Node.js). El objetivo es que puedas construir tu aplicación sobre una base de calidad RHEL y distribuirla sin atarte a la suscripción en destino.
La imagen ubi8 estándar ofrece un conjunto de herramientas robusto para la mayoría de escenarios. En cambio, ubi8-minimal recorta al máximo el tamaño y solo incluye lo imprescindible; puedes añadir paquetes con microdnf durante el build si necesitas dependencias adicionales.
La variante ubi8-init integra systemd como PID 1 y establece un StopSignal especial, ya que systemd ignora señales de salida convencionales. Es útil cuando quieres ejecutar servicios gestionados por systemd dentro del contenedor con mayor fidelidad a una máquina tradicional.
En hosts RHEL suscritos, el contenedor UBI estándar puede ver repos del host y los repos UBI, de modo que tienes todo el catálogo de paquetes. Si quieres que la imagen resultante sea redistribuible, desactiva repos no UBI al construir para garantizar que solo entren RPM con licencia de distribución libre.
Para construir, Buildah te da dos caminos: desde un Dockerfile usando buildah bud, o bien de forma más granular creando un contenedor de trabajo, montando su filesystem, copiando ficheros y ejecutando configuraciones con buildah config. Con ubi8-minimal recuerda usar microdnf en lugar de yum.
Operar contenedores e imágenes con Podman
Para ejecuciones puntuales, puedes lanzar comandos breves con podman run –rm. Por ejemplo, ver el sistema base de una imagen con cat /etc/os-release o abrir un shell bash interactivo para investigar el contenido del contenedor y realizar pruebas sin persistencia.
La inspección es muy completa: con podman inspect puedes ver metadatos de contenedores e imágenes y formatear la salida para obtener campos concretos como NetworkSettings.IPAddress, .Config.ExposedPorts o el State.Pid del proceso.
Si necesitas entrar en un contenedor que ya está en ejecución, usa podman exec con un shell y no interrumpirás el proceso principal. Esto resulta ideal para observar qué hace realmente una aplicación mientras sirve tráfico o procesa trabajos.
Para persistir y compartir datos, Podman soporta volúmenes. Puedes crear un volumen, montarlo en un contenedor y así mantener ficheros aunque elimines y recrees el contenedor. Mejor monta por nombre de volumen que por ruta interna del host para evitar purgas accidentales con prune.
Las imágenes y contenedores se gestionan con podman images, podman rmi, podman ps, podman rm y compañía. Para trasladar imágenes entre máquinas, guarda con podman save a un tar y recarga con podman load. La pareja export/import también existe si lo que quieres es capturar el filesystem de un contenedor concreto.
Pods y generación de YAML para Kubernetes
Un pod agrupa contenedores y los dota de un contenedor infra que mantiene sus namespaces. Puedes crearlos con podman pod create, listar con podman pod ps y ejecutar contenedores dentro indicando –pod. Es una manera natural de preparar despliegues con varias piezas que cooperan.
Cuando tengas un pod definido a tu gusto, puedes generar su manifest de Kubernetes con podman generate kube. Obtendrás un fichero YAML portable que describe el pod y los contenedores. Más tarde, puedes recrear el conjunto en el mismo host con podman play kube o llevártelo a un clúster con kubectl u oc.
Ten presente que la generación no refleja volúmenes de LVM del host ni detalles de storage avanzados; si los usas, documenta esos requisitos por separado o crea objetos de almacenamiento equivalentes en el orquestador.
En OpenShift puedes usar oc create con las banderas de dry run para construir YAMLs de recursos a partir de imágenes y publicarlos de forma controlada. En Kubernetes la operación es muy similar con kubectl create.
Trabajar con pods en local acelera el salto a producción, porque la topología ya está pensada en términos de pods y contenedores, y el fichero YAML sirve de contrato entre desarrollo y operaciones.
Integración con systemd: servicios de contenedores y pods
Podman se integra de maravilla con systemd. Con podman generate systemd creas unidades para contenedores o pods existentes, o generas definiciones portables con –new que construyen y arrancan el contenedor si no existe, y lo destruyen al parar el servicio.
Las unidades pueden ser de usuario (en $HOME/.config/systemd/user) o de sistema (en /etc/systemd/system o /usr/lib/systemd/system). Para servicios de usuario, habilita con systemctl –user y recuerda ajustar el arranque de user lingering si quieres que persista al desconectar sesión.
Si vas a manejar un pod con varios contenedores, céntrate en el servicio del pod y evita arrancar o detener contenedores internos por separado con systemctl, ya que los coordina el servicio del pod junto al contenedor infra.
Revisa opciones como –restart-policy para que tus servicios de contenedores se levanten automáticamente en arranque y ante fallos. Es una forma sencilla de orquestación local con semántica de unidad de servicio bien conocida en Linux.
Un consejo: regenera los ficheros de unidad cuando actualices Podman; los templates evolucionan y podman generate systemd te proporciona la versión más reciente de las directivas recomendadas.
Herramientas Skopeo, Buildah y la caja de herramientas
Skopeo te deja inspeccionar imágenes en registros remotos sin descargarlas enteras, copiar entre backends de almacenamiento y firmar. Es ideal para auditar metadatos de imágenes y sincronizar repositorios, y comparte archivo de autenticación con Podman y Buildah cuando corren en el mismo host.
Si ejecutas Skopeo en un contenedor, monta el authfile del host con la opción adecuada o vuelve a iniciar sesión dentro del contenedor. Para listar o copiar hacia el almacenamiento local, monta además la ruta de containers storage del usuario o del sistema según proceda.
Buildah simplifica la construcción de imágenes OCI desde cero, desde Dockerfiles o desde contenedores en ejecución. Comparte el mismo almacenamiento local, así que las imágenes que bajes con Podman o Buildah están disponibles indistintamente. Puedes montar el filesystem del contenedor de trabajo, copiar ficheros y confirmar cambios con buildah commit.
Existe la utilidad toolbox y la imagen support-tools para abrir un contenedor privilegiado orientado a diagnóstico del host. Monta el filesystem del sistema en /host y te permite ejecutar herramientas como sosreport o gcore contra procesos del host sin ensuciar el sistema base.
Algunas imágenes de Red Hat incluyen runlabels que definen comandos listos para instalar, ejecutar o desinstalar. Con podman container runlabel puedes invocar esas etiquetas sobre imágenes como rsyslog o support-tools para simplificar despliegues con los privilegios y mounts adecuados.
Healthchecks, información del sistema y eventos
Los healthchecks sirven para determinar si el proceso dentro del contenedor está sano o listo. Se definen con un comando a ejecutar y parámetros como intervalo, número de reintentos, timeout y periodo de gracia al inicio. Funcionan dentro del contenedor, así que diseña el chequeo con conocimiento de la aplicación.
Si quieres ejecutarlo manualmente puedes usar la orden de comprobación para ver el último estado y su código de salida; cero significa éxito. Es una forma útil de depurar cuando una sonda marca el contenedor como unhealthy.
Con podman system obtienes información global del entorno: almacenamiento, versión, soporte cgroups, runtime y configuración. Muy práctico cuando sospechas de un problema de permisos, cgroups o compatibilidad de kernel.
Por último, podman events te permite monitorizar lo que sucede: creación, inicio y parada de contenedores; cambios de pods; operaciones sobre imágenes; eventos de sistema y volúmenes. Cada evento incluye sello temporal, tipo, estado y nombres, perfecto para trazar comportamientos extraños.
Con todo lo anterior puedes crear contenedores realmente ligeros y bien controlados con Podman en Linux: instalarlo en tu distro favorita, usar rootless con cabeza, tirar de UBI cuando toque, construir con Buildah, inspeccionar y sincronizar con Skopeo, componer servicios en pods, generar YAML para Kubernetes, integrar con systemd y vigilar la salud y los eventos sin perder de vista la seguridad.
Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.