Explorando ‘Podman’, la alternativa a Docker con seguridad reforzada

 (betterstack.com)
6 puntos por GN⁺ 2024-01-14 | 1 comentarios | Compartir por WhatsApp
  • Podman ofrece una experiencia de ejecución de contenedores similar a Docker, pero funciona sin daemon, lo que lo diferencia en seguridad y trazabilidad de auditoría
  • Docker usa una arquitectura cliente-servidor centrada en Docker daemon, mientras que Podman crea los contenedores directamente desde la sesión del usuario, por lo que el rastreo del usuario que ejecuta es más claro
  • Como sigue el estándar OCI, puede ejecutar imágenes como hello-world, caddy, wordpress, mysql:5.7 de Docker Hub, y en muchos casos se puede usar cambiando el comando docker por podman
  • Los nombres cortos de imágenes no toman automáticamente Docker Hub como valor predeterminado como en Docker, por lo que se necesita el nombre completo de la imagen, un alias o una configuración de unqualified-search-registries
  • Las configuraciones de múltiples contenedores pueden manejarse con Podman Compose, pods y manifiestos de Kubernetes, pero no tiene una orquestación de producción integrada como Docker Swarm, así que hay que usar un sistema externo como Kubernetes

Dónde se separan Podman y Docker

  • Podman es un motor de contenedores de código abierto que busca ser una alternativa más segura y ligera que Docker
  • Ejecuta contenedores sin un daemon residente y usa una estructura en la que el usuario administra directamente los contenedores
  • Su enfoque de seguridad por defecto está alineado con contenedores rootless, namespaces de usuario y un uso más cuidadoso de las capabilities del kernel
  • Tiene alta compatibilidad con las imágenes y la estructura de comandos de Docker, por lo que es una opción práctica para desarrolladores y administradores de sistemas que buscan una alternativa a Docker

Arquitectura y trazabilidad de auditoría

  • Docker usa un modelo cliente-servidor, y las solicitudes para ejecutar contenedores se envían del Docker client al Docker daemon
    • Los procesos del contenedor se convierten en procesos hijo del Docker daemon, no de la sesión del usuario
    • Cuando auditd, el sistema de auditoría de Linux, detecta eventos de procesos del contenedor, el audit user ID puede aparecer como unset en vez del ID real del usuario
    • En esta estructura, es difícil vincular actividad maliciosa con un usuario específico
  • Podman usa una arquitectura sin daemon
    • Cada contenedor se crea directamente a través de la sesión de inicio de sesión del usuario
    • Los datos de proceso del contenedor conservan la información del usuario
    • auditd puede detectar y registrar con precisión el ID del usuario que inició un proceso específico del contenedor
  • Dependiendo de la imagen, la velocidad de inicio de contenedores en Podman puede ser hasta 50% más rápida que en Docker

Gestión del ciclo de vida del contenedor

  • Como Podman no tiene daemon, su forma de gestionar el ciclo de vida de los contenedores también difiere de Docker
  • En Linux depende en gran medida de Systemd
    • Para aplicar la política de reinicio de contenedores especificada con la bandera --restart always, usa un servicio de systemd llamado podman-restart
    • Este servicio reinicia automáticamente los contenedores designados después de reiniciar el sistema
  • También ofrece un comando para generar archivos de servicio de Systemd a partir de contenedores en ejecución
    • Poner contenedores bajo la administración de systemd facilita iniciarlos, detenerlos y revisarlos
  • Docker maneja estas tareas dentro del daemon

Opciones de orquestación

  • En desarrollo local, los usuarios de Docker suelen definir y administrar aplicaciones de múltiples contenedores con Docker Compose
  • Podman no soporta archivos Compose de forma nativa, pero ofrece Podman Compose como alternativa compatible
    • En general funciona con archivos docker-compose.yml existentes
    • Quienes ya están familiarizados con Docker Compose pueden seguir usando sus archivos Compose actuales
  • Como enfoque nativo, Podman puede usar pods
    • Es un concepto tomado de Kubernetes
    • Permite administrar varios contenedores como una sola unidad
  • En despliegues de producción, Podman no tiene una herramienta de orquestación integrada como Docker Swarm
    • En ese caso, un sistema externo de orquestación como Kubernetes se vuelve la alternativa
    • Kubernetes puede integrarse con Podman, pero puede requerir configuración adicional para funcionar correctamente

Seguridad por defecto

  • Un gran riesgo en la seguridad de contenedores es que un escape de contenedor comprometa el sistema host
  • Podman está diseñado para ofrecer una configuración de seguridad predeterminada más fuerte que Docker
    • contenedores rootless
    • namespaces de usuario
    • perfiles seccomp
  • Docker también puede usar contenedores rootless, namespaces de usuario y perfiles seccomp, pero no suelen estar habilitados por defecto y a menudo requieren configuración adicional
  • La configuración predeterminada de Podman ejecuta contenedores rootless dentro de namespaces de usuario aislados para limitar el impacto de un escape potencial
  • La configuración predeterminada de Docker ejecuta los procesos del contenedor como root, lo que implica un riesgo mayor en caso de escape
  • Los valores predeterminados de capabilities también difieren
    • Podman inicia contenedores con 11 capabilities por defecto
    • Docker usa 14 capabilities con una configuración predeterminada más permisiva
  • Ambas herramientas pueden configurarse con una postura de seguridad fuerte, pero normalmente Podman requiere menos esfuerzo para llegar a ese punto

Diferencias que resaltan en la comparación de funciones

  • Podman soporta una arquitectura sin daemon e integración con Systemd
  • Puede agrupar contenedores en pods y también manejar YAML de Kubernetes
  • Docker soporta Docker Swarm, pero Podman no
  • Fuera de eso, la mayoría de las funciones pueden considerarse bastante equivalentes en ambos lados

Instalación y entorno de ejecución

  • Podman puede ejecutarse en los principales sistemas operativos, igual que Docker
    • macOS
    • Windows
    • principales distribuciones de Linux
  • La diferencia importante es que en Linux corre de forma nativa, pero en Windows y macOS requiere una máquina virtual
  • Los ejemplos asumen distribuciones Linux basadas en Debian, como Ubuntu, Mint y Debian
  • Para instalar una versión reciente de Podman se necesita una distribución relativamente reciente
    • Al momento de escribir, la versión principal más reciente de Podman es 4.x
    • Ubuntu 22.04 LTS está atado a Podman 3.x
    • Los ejemplos se basan en Ubuntu 23.10
  • Después de la instalación, la salida de ejemplo muestra podman version 4.3.1, confirmando que el comando podman puede ejecutarse localmente

Ejecución de imágenes Docker y compatibilidad con OCI

  • Podman puede ejecutar la imagen hello-world, creada con herramientas del ecosistema Docker
  • Esta compatibilidad existe porque tanto Docker como Podman siguen los estándares de OCI (Open Container Initiative)
    • OCI define la especificación del formato de imágenes y la especificación del runtime
    • Esto permite la interoperabilidad entre distintos runtimes de contenedores
  • La mayoría de las imágenes y contenedores de Docker Hub pueden usarse en Podman
  • Eso permite migrar cargas de trabajo existentes a Podman sin modificaciones o aprovechar la biblioteca de imágenes de Docker Hub
  • Aunque la salida de hello-world muestre “Hello from Docker!”, quien realmente lo ejecuta es Podman
    • Ni el Docker client ni el Docker daemon participan en el proceso de ejecución

Cómo maneja los nombres cortos de imágenes

  • Docker usa docker.io, es decir Docker Hub, como registro predeterminado cuando no se especifica un nombre completo de imagen
  • Podman no recomienda usar nombres cortos y no asume automáticamente un registro predeterminado
  • hello-world tiene un alias en shortnames.conf, por lo que se resuelve como docker.io/library/hello-world
  • Si se intenta ejecutar con nombre corto una imagen sin alias, como caddy, aparece el siguiente error
    • Error: short-name "caddy" did not resolve to an alias and no unqualified-search registries are defined in "/etc/containers/registries.conf"
  • Hay tres formas de resolverlo
    • Usar el nombre completo de la imagen, como docker.io/library/caddy
    • Agregar una sección [aliases] en registries.conf para definir el alias "caddy"="docker.io/caddy"
    • Configurar unqualified-search-registries=["docker.io"] para que los nombres cortos se busquen en Docker Hub
  • La configuración por usuario puede guardarse en $HOME/.config/containers/registries.conf
    • Ese archivo tiene prioridad sobre /etc/containers/registries.conf
    • Puede configurarse sin permisos de root, lo que encaja mejor con el enfoque rootless
  • Si quieres usar Podman como sustituto de Docker, a largo plazo suele ser más cómodo configurar unqualified-search-registries que depender de aliases

Uso de registros privados

  • Podman puede usar registros privados igual que Docker
  • Un ejemplo con una cuenta de Docker Hub sigue este flujo
    • Crear un access token en Docker Hub
    • Poner la descripción como Podman tutorial y asignar permisos Read & Write
    • Crear un private repository
    • Iniciar sesión con podman login docker.io
  • Si docker.io es la primera entrada de unqualified-search-registries en registries.conf, puede omitirse, pero es una buena práctica especificar el registro
  • Si no se proporciona un registro, podman login falla con el siguiente error
    • Error: no registries found in registries.conf, a registry must be provided
  • Después de iniciar sesión, se puede hacer push de la imagen hello-world al private repository, borrar la imagen pública local y luego ejecutar un contenedor desde la imagen del repositorio privado
  • Si no hay credenciales válidas de inicio de sesión, al hacer pull de una imagen privada aparecen errores de acceso denegado y autenticación requerida
  • La diferencia más visible al usar registros privados es escribir podman en lugar de docker, y Podman puede usarse con registros privados ampliamente adoptados

Ejecutar múltiples contenedores con Podman Compose

  • Cuando se necesita ejecutar varios contenedores como una sola unidad, Podman ofrece varias opciones
    • Podman Compose
    • pods
    • manifests de Kubernetes
  • El ejemplo usa Podman Compose para ejecutar WordPress y MySQL
  • Podman Compose es una herramienta impulsada por la comunidad que implementa la Compose specification y se integra con Podman
  • Depende de Python 3 y en el ejemplo se instala con pipx
    • La salida de instalación de ejemplo muestra podman-compose 1.0.6
    • La versión de Podman usada es 4.3.1
  • Si pipx se instala en $HOME/.local/bin, puede que esa ruta no esté en $PATH
    • Se puede agregar con pipx ensurepath
    • Luego hay que abrir una terminal nueva o volver a cargar el archivo de configuración del shell

Ejemplo con WordPress y MySQL

  • El ejemplo define en un archivo .env el usuario, la contraseña y el nombre de la base de datos, y usa docker-compose.yml para configurar los servicios de WordPress y MySQL
  • Al ejecutar podman-compose up -d, Podman Compose analiza docker-compose.yml
  • Proceso para el servicio wordpress
    • Busca el volumen externo necesario y lo crea si no existe
    • Busca la red adecuada y la crea si no existe
    • Ejecuta el contenedor wordpress
    • Si no hay imagen local, obtiene wordpress:latest desde el registro configurado docker.io
  • Proceso para el servicio db
    • Crea el volumen podman-tutorial_db
    • Verifica la red existente
    • Ejecuta el contenedor mysql:5.7
    • Si no hay imagen local, la obtiene de Docker Hub
  • Después de ejecutarlo, se puede ver la página de instalación de WordPress en localhost:8080
  • La salida de podman ps muestra los contenedores wordpress y db en ejecución
    • wordpress tiene el puerto mapeado como 0.0.0.0:8080->80/tcp
    • db se ejecuta con la imagen mysql:5.7
  • La lista de imágenes muestra docker.io/library/wordpress:latest y docker.io/library/mysql:5.7
  • La lista de redes muestra la red predeterminada podman y la red podman-tutorial_default creada por Podman Compose
    • podman-tutorial_default se crea para aislar los contenedores definidos en docker-compose.yml de otros contenedores en el mismo sistema
  • La lista de volúmenes muestra podman-tutorial_db y podman-tutorial_wordpress
  • podman-compose down detiene y elimina los contenedores, pero conserva la red y los volúmenes
    • Para eliminar volúmenes se usa podman volume rm
    • Para eliminar redes se usa podman network rm
  • Los comandos son casi iguales a los de Docker y Docker Compose; la diferencia es usar podman y podman-compose en lugar de docker y docker-compose

Criterios de elección

  • Podman es una alternativa práctica a Docker para ejecutar cargas de trabajo en contenedores
  • Puede hacer la mayoría de las cosas que hace Docker y además tiene la ventaja de no requerir un daemon en segundo plano
  • También ofrece funciones que Docker no tiene
    • trabajar con archivos manifest de Kubernetes
    • organizar contenedores individuales en pods
  • Si necesitas una solución de administración de contenedores más ligera y segura, Podman puede ser una mejor opción
  • Si priorizas un ecosistema sólido y un soporte comunitario amplio, Docker podría ser más adecuado
  • Para seguir explorando, se pueden consultar el sitio oficial de Podman, la documentación y la comunidad

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-01-14
Opiniones de Hacker News

  • Me gustaba cuando Podman soportaba archivos de unidad de systemd. Era porque se podían iniciar automáticamente y actualizar automáticamente con systemd no solo contenedores, sino también pods completos.
    Pero eliminaron esa función y empezaron a impulsar Quadlet. Un contenedor individual se puede manejar con un archivo de unidad, pero para un pod hay que usar una definición de clúster de Kubernetes.
    Además, a diferencia de Docker, como los contenedores obedecen las definiciones de SELinux, sufrí varias veces porque no podían acceder a directorios mapeados.
    Al final, no entiendo qué se supone que hay que hacer con Podman. ¿Usar Kubernetes? ¿No mapear rutas lógicas y crear directorios dedicados para todo?

    • Yo ya tenía definida la infraestructura con docker-compose.yml, y descubrí que podman-compose tiene una función poco documentada para generar unidades de systemd.
      Esta función no usa la funcionalidad ya obsoleta de Podman, sino que escribe directamente los archivos de unidad, y personalmente me resultó mucho más fluida que el enfoque anterior de Podman.
      La función se activa con $ podman-compose systemd -a create-unit, y las unidades de systemd se registran con $ podman-compose systemd -a register, $ systemctl --user enable --now "podman-compose@$PROJECT_NAME".
      Las actualizaciones se manejan con $ podman-compose pull y luego $ systemctl --user restart "podman-compose@$PROJECT_NAME". $PROJECT_NAME suele ser el nombre del directorio.
      Si quieres revisarlo, el código fuente de la función está aquí: https://github.com/containers/podman-compose/blob/f6dbce3618...
      Aunque todavía uso podman 4.3.1, no veo por qué este método tendría que dejar de funcionar en versiones posteriores.
    • Eso de que “a diferencia de Docker, los contenedores obedecen las definiciones de SELinux” es más bien un bug de Docker. Si el sistema no está configurado para SELinux, debería desactivarse.
      Además, los archivos de systemd que generaba podman-generate-systemd al final básicamente ejecutaban "podman start containername", así que también son fáciles de escribir a mano. Eso sí, a diferencia de algo como docker-compose, el contenedor es casi una caja negra.
      La ventaja de Quadlet es que la definición del contenedor se declara en un archivo .container. Antes uno escribía a mano la línea de comandos de podman run en una unidad de systemd; en ese sentido, Quadlet es una gran mejora y también puede ser una alternativa a docker-compose. Claro, tiene pros y contras.
    • Soy fan desde hace mucho, pero en esta parte estoy de acuerdo.
      Cada vez que intento ejecutar podman generate systemd [...], vuelvo a recordar que ocurrió esta transición.
      La razón por la que no me pasa seguido es que armé mi propio rol de Ansible que maneja esto de una forma bastante decente.
      Aun así, siento con fuerza que Podman perdió el rumbo. Ya que aceptaron la parte de mantener archivos de unidad y diseñar relaciones, me gustaría que simplemente dejaran usar el generador. No me interesa Quadlet ni que digan que eso es mejor.
    • Si no quieres lidiar con SELinux, basta con agregar esto a containers.conf: [containers] label=false
      Si no te gusta el nivel de seguridad predeterminado de Podman, normalmente hay una forma de desactivarlo.
    • Hace poco me pasé a NixOS, y NixOS trata a systemd como la referencia para todo, incluidos los contenedores.
      Este modelo me resultó muy intuitivo, pero aplicarlo a Docker Compose requería mucha migración manual.
      Por eso creé una herramienta que convierte archivos Compose a configuración de NixOS para que puedan interpretarse y administrarse de forma nativa: https://github.com/aksiksi/compose2nix

  • Hay una ventaja que casi nunca se menciona como razón decisiva para preferir Podman sobre Docker: Docker rompe la configuración de red.
    Intentar ejecutar al mismo tiempo Docker y máquinas virtuales KVM con un bridge es una pesadilla, y Podman convive mucho mejor incluso con la configuración por defecto.
    Las VPN también se me han roto por culpa de Docker, o han roto Docker muchas veces. No sé bien cómo funciona internamente el networking de Podman, pero al menos parece estar bien diseñado para no interferir con otros trabajos. Jamás podría decir eso de Docker.

    • Para mí, Buildah es la verdadera funcionalidad clave. Puede funcionar bien también con Docker, pero es más cercano a la familia de herramientas de Podman.
      Considero que Dockerfile es basura pura. Me alcanza con lenguajes existentes, y realmente detesto que algún “desarrollador aburrido” invente un DSL o un lenguaje de programación nuevo. Especialmente si es YAML; aunque este no sea el caso, Dockerfile es un gran ejemplo de por qué hay que dejar de hacer estas cosas.
      Si miras Buildah sin bud, la razón queda clara. En lugar de un DSL endeble y molesto apenas tu caso de uso se sale un poco del camino estándar, puedes usar Bash, Fish o lo que quieras.
      Este tipo de malas decisiones se extiende a todo el ecosistema Docker. DCS y sus alternativas siempre incompletas también son ejemplos. En vez de usar un protocolo de firmas establecido como Cosign, quisieron crear un sistema complejo, difícil de automatizar y especialmente complicado para la rotación de claves.
    • Podman es gratis. Docker también es gratis, pero instalar Docker sin Docker Desktop es una molestia.
    • Todavía ejecuto Docker y máquinas virtuales KVM con un bridge, y simplemente funciona bien, sin pesadillas. Qué raro.

  • Me alegra que Podman se use más ampliamente. Demasiadas herramientas están hechas asumiendo que el usuario agrega el grupo sudo docker, así que se rompen en una configuración de Docker consciente de la seguridad que no entrega acceso root sin más.

    • Siempre me causa gracia que ese futuro avanzado de serverless y contenedores al final esté construido sobre la base de ejecutar todo tipo de cosas como root.

  • Como ingeniero certificado en RHEL, llevo ya varios años usando Podman.
    Sinceramente, para uso personal de contenedores me gusta bastante. Pero en el trabajo seguimos ofreciendo Docker a los desarrolladores. Hasta ahora no había forma de darles algo que igualara la simplicidad de docker compose.
    Al crear imágenes de contenedores, en los pipelines de CI también usamos buildah, pero desde el punto de vista del usuario final desarrollador, docker compose sigue dominando.

  • https://www.techrepublic.com/article/how-to-fix-the-docker-a...
    Por este problema casi me atrapan.

    • Docker, incluso con la configuración e instalación predeterminadas, toca iptables. En especial cuando quería usar el nftables más nuevo, siempre fue un dolor de cabeza.
    • Por las opciones predeterminadas inseguras de Docker, en un contenedor privado autohospedado de un proyecto de GitHub que supuestamente era solo para VPN, se coló un minero de criptomonedas. Todavía me molesta.
    • Hablando de problemas de red, hubo un problema grande en una configuración anidada en la que se agotaba la memoria para dispositivos de red y hacía falta reiniciar el sistema. Si no hubiera sido por eso, habría sido una gran alternativa a lxc; qué lástima.

  • Todavía no tengo del todo claro por qué Red Hat invierte en crear una alternativa a Docker, pero el resultado me gusta mucho.
    Podman hace casi todo lo que hace Docker, pero además tiene funciones como pod, o en muchos casos un enfoque mejor, como el proceso de creación de contenedores sin daemon.
    Para un desarrollador común, el mayor problema probablemente sea Docker compose, pero si usas un archivo compose sencillo, existe el script podman-compose, que intenta ser compatible con la especificación de Docker compose.
    También hay una forma de usar Podman como backend de docker-compose [1]. En general, en 2024 no veo motivos para usar Docker en una máquina Linux. No sé muy bien cómo anda Podman en macOS o Windows.
    [1] https://www.redhat.com/sysadmin/podman-docker-compose

    • Red Hat originalmente intentó colaborar con Docker para corregir varios problemas que habían salido a la luz, por ejemplo problemas de compatibilidad con systemd en ciertos casos de uso, pero no tuvo mucho éxito.
      Si a eso le sumamos que Docker antes, y todavía ahora, tiene una cantidad inusualmente alta de problemas de seguridad, y que los contenedores e imágenes al estilo Docker son muy usados entre desarrolladores, no les quedó otra que crear su propia implementación, más alineada con el valor y el enfoque de RHEL.
      Por ejemplo, aunque Docker puede funcionar en modo rootless, todavía no lo usa como valor predeterminado. En entornos endurecidos, tanto el grupo de usuarios docker como la ejecución sin ese grupo son difíciles de aceptar desde el punto de vista de seguridad en muchos casos de uso.
      Al principio Docker fue demasiado poco proactivo para lograr que los contenedores sin privilegios tuvieran al menos un aislamiento mínimo, y aun después de que se conocieron los problemas tardó mucho en corregirlos. También tiene muchos problemas en la forma en que interactúa con firewalls, reglas de red y SELinux. Por eso no es raro que Docker esté prohibido en empresas que cuentan con administradores Linux dedicados y enfocados en seguridad.
    • Uso Podman en Windows. Docker en Windows fue una sucesión interminable de molestias y frustraciones.
      Desde el inicio, toda la documentación te empuja agresivamente hacia una instalación con GUI poco amigable para el usuario. Levanta procesos pesados al arrancar, por algún motivo exige registrarse con una cuenta en la nube y encima te sermonea con que no debes usar en el trabajo un supuesto producto open source.
      La alternativa no soportada de instalar “solo Docker de línea de comandos” era innecesariamente complicada y, la última vez que lo intenté, la mayoría de las VM de WSL ni siquiera la soportaban en su estado predeterminado.
      En cambio, con Podman basta con winget install podman y no molesta. Solo inicio la VM de Podman cuando necesito ejecutar contenedores, y cuando no la necesito el sistema se comporta como antes.
      Si necesito ejecutar algo con un archivo compose, está podman-compose. Quizá no maneje configuraciones raras, pero para mi uso funcionó bien.
      Lo único que Podman no hace bien es la integración con VS Code, pero el esfuerzo de hacer que Docker se comporte de forma tranquila en Windows es mucho más irritante que perder algunos atajos de VS Code, así que no es un problema.
      Recomiendo Podman como la solución básica para contenedores en Windows. Las únicas razones para usar Docker serían que la empresa pague el costo o que tengas una configuración compose compleja; en ese caso, quizá valga la pena migrar a Kubernetes.
    • Red Hat invierte porque Docker está demasiado desconectado de cómo se hacen las cosas en Linux.
      Hace cosas que rompen el sistema, pasó años sufriendo con rootless, y tampoco se puede dejar fuera el vendor lock-in.
      Podman es abierto, sigue estándares y encaja bien con Kubernetes. Es absurda la cantidad de esfuerzo que los desarrolladores invirtieron en Docker solo porque llegó primero al mercado de contenedores fáciles.
    • Espero que la postura de “en Linux no hay motivos para usar Docker” no se vuelva mayoritaria. Docker no es RedHat/IBM.
      Si Docker desaparece, RedHat podrá impulsar su agenda corporativa con una mano más fuerte.
      Podman tiene sus ventajas, pero también hay partes que no se ejecutaron bien en el proceso de RedHat de intentar reemplazar todo lo de Docker.
      Si miramos la historia de cómo RedHat ha abordado el área de contenedores, en parte desperdició tiempo y esfuerzo en muchos proyectos en los que podría haber contribuido y mejorado.
      RedHat no es una empresa con una agenda de hacer lo correcto para sus clientes, así que conviene pensar qué se quiere en el panorama más amplio.
    • Uso Podman en macOS. En general, la experiencia fue mejor que con Docker, especialmente en cuanto al soporte para versiones antiguas de macOS.
      La única gran desventaja de Podman para macOS es que no se puede usar la red del host desde los contenedores. Pero es raro querer usar la red del host desde un contenedor.
      Eso sí, si haces experimentos relacionados con redes dentro de un contenedor y quieres mantener el mismo nombre de host y la misma dirección IP que el host, hay que tenerlo en cuenta. Aun así, estoy usando esta limitación con soluciones alternativas.

  • Me parecen bien el enfoque y las decisiones de priorizar la seguridad. Me gusta que sea seguro desde la configuración predeterminada y que además funcione con docker compose.
    Sin embargo, me pregunto si, cuando Podman gane suficiente popularidad, algún día tomará su propio camino en los comandos y el formato yml. Por ahora parece una herramienta que se apoya en Docker y en el formato de archivos de Docker compose.
    Me gustaría que Podman tuviera una alternativa a Swarm. Ahora, por la falta de orquestación, se siente como si Kubernetes se usara de muleta.
    Un equipo que tenga muy en cuenta la seguridad podría crear una forma razonable y simple de ejecutar contenedores a pequeña escala, sin tener que meterse en Kubernetes como si fuera un doctorado, siendo que sus valores predeterminados no son seguros. Y al mismo tiempo podría mantener la compatibilidad con el formato de Docker compose.

  • Estoy de acuerdo en que los contenedores rootless y los espacios de nombres aislados son funciones de seguridad importantes. Pero también se puede hacer con Docker rootless y no es complicado. Solo hay que configurarlo así
    Escribí un artículo sobre cómo configurar Mastodon con Docker rootless aplicando todas las mejores prácticas disponibles actualmente [1]
    La ventaja de seguir usando Docker es que tiene mejor accesibilidad. Hay más comunidad y blogs, las configuraciones de Docker Compose están muy extendidas y hay más gente alrededor que sabe usarlo
    Al final, tanto Podman como Docker ejecutan procesos en espacios de nombres aislados del host
    [1]: https://du.nkel.dev/blog/2023-12-12_mastodon-docker-rootless...

  • No quisiera que haya malentendidos. Podman es excelente y hoy lo uso en lugar de Docker, pero al principio empecé a usarlo pensando que era un simple reemplazo de Docker y me llevé golpes fuertes con el mapeo de UID/GID, las políticas de SELinux, configuraciones DNS faltantes, etc.
    Varias veces ejecuté system migrate para intentar corregir problemas y terminé rompiendo toda la configuración. Tiene todo un sistema propio relacionado con ACL de seguridad, mapeo de ID y etiquetas
    Si haces chmod -R debajo de tu carpeta home, probablemente puedas matar todos los contenedores
    Estoy satisfecho con el resultado, pero estuvo lejos de ser una solución que “simplemente funciona” como Docker. Probablemente haya mejorado mucho desde que empecé a usarlo

    • Empecé a usarlo este año, con el objetivo de aislar varios entornos de desarrollo y evitar que npm tuviera acceso fácil a toda la máquina de desarrollo
      Para mí fue más fácil de usar que Docker. Parece que ahora está más mejorado que las situaciones que se mencionan arriba

  • Visto en perspectiva, Podman se siente tan esencial como lo era Linux antes
    Aunque lo use muy poca gente, su mera existencia evita que sus hermanos de software propietario mucho más grandes hagan cosas horribles
    Con “Linux antes” no quiero decir que Linux se haya vuelto menos importante, sino que ahora, por el contrario, se volvió aún más esencial y central

    • Si con “hermanos de software propietario mucho más grandes” te refieres a Docker, es un poco irónico. Porque RedHat e IBM también hacen muchas cosas malas en el ámbito del código abierto