Cómo Cirrus CLI usa Podman para realizar compilaciones sin raíz

¿Qué es la CLI de Cirrus? La siguiente descripción está tomada de Descripción de la página GitHub de la CLI de Cirrus:

Cirrus CLI es una herramienta para realizar tareas en contenedores de forma reproducible en cualquier entorno. Por lo general, las tareas de Cirrus se usan como parte de flujos de trabajo de integración continua, pero también se pueden usar como parte de un proceso de desarrollo local como un reemplazo hermético de scripts de ayuda / Makefiles. Cirrus CLI realiza sus tareas localmente de la misma manera que se realizan en CI o en la máquina de su colega. La inmutabilidad de los contenedores garantiza que las tareas se realizarán de la misma manera en los años venideros, independientemente de la versión de los paquetes que tenga localmente.

Cirrus CLI ha sido compatible con Docker desde sus inicios, pero requerir un demonio de contenedor que se ejecute como root y dé acceso a usuarios con menos privilegios a veces no es una opción: - estar al tanto de lo que se está ejecutando en su oficina.

E incluso si Docker introdujo el modo sin raíces Hace aproximadamente un año, su experiencia de usuario actualmente es deficiente en nuestra opinión, principalmente debido a la falta de empaque y al historial de Docker como un demonio. Podman, por otro lado, comenzó como un motor de contenedor sin demonios, y su proceso de instalación cubre prácticamente todas las distribuciones.

Además de eso, al estudiar Podman como una opción adicional para ejecutar tareas de Cirrus, nos dimos cuenta de que era un pequeño paso para romper con la monocultura del software porque, al final, la calidad de su software aumenta. Nuevos estándares y bloques de construcción como el Proyecto de contenedor sin raíces emergentes que allanan el camino para el futuro del software.

Índice

    Los contenedores sin raíz funcionan con... ¿espacios de nombres?

    el Espacios de nombres de Linux es la piedra angular más importante de cómo funcionan los contenedores en Linux. Son muy específicos de Linux, hasta el punto de que se inicia una VM de Linux separada cuando ejecuta contenedores en Windows y macOS.

    Los espacios de nombres permiten la separación granular de los 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 es el espacios de nombres de usuario. Los espacios de nombres de usuario esencialmente le permiten ser root dentro de ese espacio de nombres, pero aparecer como un usuario normal desde el exterior. Debido a que la mayoría de las imágenes de contenedores esperan ejecutarse como raíz para algunas operaciones, la implementación de espacios de nombres de usuario es fundamental para los contenedores sin raíz.

    Veamos qué sucede cuando varios usuarios inician sus comandos de compilación utilizando espacios de nombres de usuario habilitados para Docker:

    Al mirar las ID de estos procesos desde el host del contenedor, todas las tareas se ejecutan bajo la raíz, aunque fueron iniciadas por diferentes usuarios. Lo mismo se aplica a containerd. Y aunque podrías haberlo pasado, el --userns-remap flag, el contenedor aún se ejecutará 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 propios espacios de nombres de usuario son probablemente uno de los mas complejos configuraciones para implementar y producir muchos errores relacionados con la seguridad. Algunas distribuciones como Debian incluso han optado por deshabilitarlos por defecto hace algún tiempo.

    Cómo resuelve Podman las dificultades para correr sin raíces

    Iniciar un contenedor sin privilegios de root implica compromisos y soluciones alternativas.

    Por ejemplo, como usuario, cuando crea un espacio de nombres de red (que debe ir acompañado de un espacio de nombre 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 hacia el host para conectarlo a una interfaz de red real oa un puente (para la comunicación entre contenedores).

    Sin embargo, la conexión de interfaces al host requiere que sea root en el espacio de nombres del host, por lo que esto no es posible. Podman elude esto usando deslizador4netns, una pila de red que enruta paquetes entre el contenedor y el propio monitor, en lugar de utilizar la funcionalidad del núcleo. Por lo tanto, no requiere ningún privilegio de superusuario.

    En razón de complejidades de los espacios de nombres de usuario, tampoco puede usar algunos sistemas de archivos normalmente disponibles en la raíz del host. Uno de estos sistemas de archivos es SuperposiciónFS, que facilita en gran medida la deduplicación de las capas de imágenes del contenedor y mejora la experiencia del contenedor. Sin embargo, todavía podemos usar FUSIBLE. El equipo de Podman ha establecido fuse-overlayfs, que se usa si está instalado, volviendo a simplemente extraer el contenido de la imagen en un directorio a expensas del rendimiento.

    Ahora, si ejecutamos las mismas tareas que hicimos antes, pero con Podman, el resultado se ve así:

    Tenga en cuenta que nada se ejecuta como root ahora y que no hay un punto único de falla si un motor de contenedor falla por algún motivo.

    Integración con Podman

    Cuando comienzas una nueva construcción con cirrus run, inicia el proceso Podman bajo el capó y le habla a través del API REST, que se introdujo recientemente como sucesor de la antigua API de Varlink.

    La API en sí se parece mucho a API del motor Docker, 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 es Todavía un trabajo en progreso en el momento de escribir.

    Activación de Podman en la CLI

    Si aún no ha instalado Podman, siga las instrucciones para su distribución de linux entonces léelo tutorial sin root.

    CLI es compatible con Podman versión 0.17.0 y posteriores. Puedes activarlo pasando el --container-backend=podman bandera:

    cirrus run --container-backend=podman Lint

    Tenga en cuenta que si Docker no está instalado en su sistema, ni siquiera tiene que especificar nada, todo funciona automáticamente.

    Conclusión

    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.

    Artículos de interés

    Subir