¿Qué es la CLI de Cirrus? La siguiente descripción se tomó de la descripción de la página Cirrus CLI GitHub:
Cirrus CLI es una herramienta para ejecutar tareas en contenedores de forma reproducible en cualquier entorno. Por lo general, las tareas de Cirrus se usan como parte de los flujos de trabajo de integración continua, pero también se pueden usar como parte del proceso de desarrollo local como un reemplazo hermético de los scripts auxiliares/Makefiles. Cirrus CLI ejecuta sus tareas localmente de la misma manera que se ejecutan en CI o en la máquina de su colega. La inmutabilidad de los contenedores garantiza que las tareas se ejecutarán de la misma manera dentro de unos años, independientemente de las versiones de los paquetes que tenga localmente.
Cirrus CLI admitió Docker desde su inicio, pero requerir un demonio de contenedor que se ejecute como root y brinde acceso a los usuarios con menos privilegios a veces no es una opción:por ejemplo, al construir en una máquina compartida, aislar contenedores anidados o simplemente ser seguridad -consciente de lo que se ejecuta en su escritorio.
Y a pesar de que Docker introdujo el modo sin raíz hace aproximadamente un año, en nuestra opinión, su experiencia de usuario actualmente es deficiente, principalmente debido a la falta de empaque y al historial de Docker como un demonio. Podman, por otro lado, comenzó como un motor contenedor sin demonios y su proceso de instalación cubre prácticamente todas las distribuciones.
Además de eso, cuando investigamos Podman como una opción adicional para ejecutar tareas de Cirrus, nos dimos cuenta de que es un pequeño paso hacia la disrupción de la monocultura del software porque, al final, la calidad de su software aumenta. Surgen nuevos estándares y componentes básicos, como el proyecto Rootless Containers, que allanan el camino para el futuro del software.
Los contenedores sin raíz funcionan con... ¿espacios de nombres?
Los espacios de nombres de Linux son la piedra angular más importante de lo que hace que los contenedores funcionen en Linux. Son muy específicos de Linux, hasta el punto de que se activa una máquina virtual de Linux separada cuando ejecuta contenedores en Windows y macOS.
Los espacios de nombres permiten la separación granular de recursos. Por ejemplo, si un proceso está adjunto a un espacio de nombres PID específico, solo ve otros procesos adjuntos al mismo espacio de nombres. O si un sistema de archivos FUSE está montado en la raíz (/ ) mientras se encuentra en un espacio de nombres de montaje separado, el host no se bloqueará repentinamente debido a la falta de archivos binarios.
Uno de los espacios de nombres más complicados son los espacios de nombres de usuario. Los espacios de nombres de usuario esencialmente permiten que uno sea una raíz dentro de ese espacio de nombres, pero aparece como un usuario normal desde el exterior. Dado que la mayoría de las imágenes de contenedores esperan ejecutarse como raíz para ciertas operaciones, la implementación de espacios de nombres de usuario es crucial para los contenedores sin raíz.
Veamos qué sucede cuando varios usuarios inician sus comandos de compilación usando Docker sin espacios de nombres de usuario habilitados:
Al observar las ID de estos procesos desde el host del contenedor, todos los trabajos se ejecutan bajo la raíz, a pesar de que los inician diferentes usuarios. Lo mismo se aplica a containerd . Y aunque podrías haberle pasado el --userns-remap flag, el contenedor seguirá ejecutándose como root y será un único punto de falla.
Las cosas funcionan así en el modo predeterminado porque la implementación de contenedores sin raíz no es trivial.
Los espacios de nombres de usuario en sí son probablemente una de las configuraciones más complejas de implementar y producen muchos errores relacionados con la seguridad. Algunas distribuciones como Debian incluso optaron por deshabilitarlas por defecto hace algún tiempo.
[ En caso de que se lo haya perdido: Principios básicos de seguridad para contenedores y tiempos de ejecución de contenedores]
Cómo resuelve Podman las dificultades de ejecución sin raíz
Iniciar un contenedor sin privilegios de raíz implica algunos compromisos y soluciones.
Por ejemplo, como usuario, cuando crea un espacio de nombres de red (que debe venir con un espacio de nombres de usuario), solo obtiene un lo interfaz. Normalmente, un motor de contenedor también crea un veth par de dispositivos y mueve uno de sus extremos de regreso al host para conectarlo a una interfaz de red real o puente (para la comunicación entre contenedores).
Sin embargo, la conexión de interfaces en el host requiere que usted sea root en el espacio de nombres del host, por lo que eso no es posible. Podman soluciona esto mediante el uso de slirp4netns, una pila de red que enruta los paquetes entre el contenedor y el monitor en sí, en lugar de utilizar las instalaciones de Kernel. Por lo tanto, no requiere privilegios de superusuario.
Debido a las complejidades involucradas con los espacios de nombres de usuario, tampoco puede usar ciertos sistemas de archivos normalmente disponibles para la raíz del host. Uno de esos sistemas de archivos es OverlayFS, que es de gran ayuda para eliminar la duplicación de capas de imágenes de contenedores y mejora la experiencia del contenedor. Sin embargo, todavía se puede usar FUSE. El equipo de Podman implementó fuse-overlayfs , que se usa si está instalado, recurriendo a simplemente extraer el contenido de la imagen en un directorio a costa del rendimiento.
Ahora, si ejecutamos los mismos trabajos que ejecutamos antes, pero con Podman, el resultado se ve así:
Tenga en cuenta que nada se ejecuta como root ahora, y no hay un punto único de falla si un motor de contenedor falla por algún motivo.
Integración con Podman
Cuando inicia una nueva compilación con cirrus run , genera el proceso Podman bajo el capó y se comunica con él a través de la API REST, que se introdujo recientemente como sucesora de la antigua API Varlink.
La API en sí se parece mucho a la API de Docker Engine, lo que permite una abstracción limpia para ambas API en la misma base de código.
De hecho, el mismo punto final de Podman ofrece una capa de compatibilidad con la API de Docker Engine, pero aún es un trabajo en progreso al momento de escribir este artículo.
Habilitación de Podman en la CLI
Si aún no tiene Podman instalado, siga las instrucciones para su distribución de Linux y luego lea el tutorial sin raíz.
CLI es compatible con Podman versión 0.17.0 y posteriores. Puede habilitarlo pasando el --container-backend=podman bandera:
cirrus run --container-backend=podman Lint Tenga en cuenta que si no tiene Docker instalado en su sistema, ni siquiera necesita especificar nada:todo funciona automáticamente.
[ ¿Empezando con los contenedores? Consulta este curso gratuito. Implementación de aplicaciones en contenedores:una descripción técnica general. ]
Resumir
Las compilaciones sin raíz son un componente importante de las implementaciones de contenedores. Cirrus CLI trabaja con Podman para proporcionar esta funcionalidad. Utilice estas dos utilidades para administrar y proteger mejor sus entornos de contenedores.