Containerization - paquete Swift para ejecutar contenedores Linux en macOS

 (github.com/apple)
6 puntos por GN⁺ 2025-06-10 | 1 comentarios | Compartir por WhatsApp
  • Containerization es una herramienta open source basada en Swift que permite ejecutar contenores Linux en macOS
  • Funciona en Macs con Apple Silicon y utiliza Virtualization.framework para aislar y ejecutar cada contenedor dentro de una máquina virtual ligera
  • Incluye varias funciones, como gestión de imágenes OCI, integración con registros remotos, creación de sistemas de archivos ext4 y control del entorno del contenedor
  • Puede admitir la ejecución de procesos x86_64 en Apple Silicon usando Rosetta 2
  • Mejora la flexibilidad y el rendimiento para desarrolladores con arranque ultrarrápido, entornos ligeros y personalización de la versión del kernel

Descripción general del proyecto

  • Containerization es un paquete Swift que ayuda a las aplicaciones a usar contenedores Linux
  • Está implementado en el lenguaje Swift y funciona en Macs con Apple Silicon usando Virtualization.framework
  • A través de su API ofrece funciones como las siguientes
    • Gestión de imágenes OCI
    • Integración con registros remotos de contenedores
    • Creación y despliegue de sistemas de archivos ext4
    • Interacción con la familia de sockets Netlink
    • Provisión de un kernel Linux optimizado para arranque rápido
    • Creación y administración de máquinas virtuales ligeras
    • Control del entorno de ejecución de la máquina virtual
    • Creación y control de procesos en contenedores
    • Ejecución de procesos x86_64 en Apple Silicon mediante Rosetta 2
  • La documentación de la API puede consultarse en su página oficial

Diseño y estructura

  • Cada contenedor Linux se ejecuta dentro de una máquina virtual independiente
  • Se puede asignar una dirección IP dedicada a cada contenedor, lo que simplifica la administración de red incluso sin port forwarding
  • Gracias a una configuración de kernel optimizada y a un sistema de archivos raíz ligero, es posible lograr un arranque del contenedor en menos de 1 segundo
  • vminitd es un subproyecto de Containerization y actúa como un sistema init ligero que funciona como proceso inicial dentro de la máquina virtual
    • Configura el entorno de ejecución mediante una API de GRPC y da soporte a la operación y administración de procesos en contenedores
    • Reenvía la entrada/salida, señales y manejo de eventos al proceso que lo invocó

Requisitos

  • Se requiere un dispositivo Apple Silicon Mac
  • Para compilar el paquete se necesita
    • macOS 15 o superior y Xcode 26 Beta
    • o macOS 26 Beta 1 o superior
  • Si se usa macOS 15, la siguiente función está limitada
    • Red de contenedores no aislada: no es posible la comunicación entre contenedores dentro de la misma red vmnet

Ejemplos de uso

  • Se proporciona el ejecutable cctl: funciona como un playground para experimentar con varias capacidades de la API
    • Ejemplos de comandos principales
      • Manipulación de imágenes OCI
      • Inicio de sesión en registros de contenedores
      • Creación de bloques de sistema de archivos raíz
      • Ejecución de un contenedor Linux simple

Configuración del kernel Linux

  • Se necesita un kernel Linux para ejecutar máquinas virtuales ligeras para contenedores
  • La configuración de kernel optimizada que ofrece Containerization está ubicada en el directorio kernel
  • Esa configuración incluye solo las funciones mínimas necesarias para ofrecer arranque rápido y un entorno ligero
  • También se incluye una API para especificar distintas configuraciones y versiones del kernel según cada contenedor
    • Esto permite probar distintas versiones y configuraciones del kernel
  • Se pueden usar kernels precompilados como vmlinux.container del proyecto Kata Containers
    • Sin embargo, los drivers VIRTIO deben estar integrados en el kernel (compiled-in)

Resumen del proceso de desarrollo y pruebas

  • Es necesario preparar el entorno con Swift, Static Linux SDK y otros componentes
  • Es posible compilar y probar el código fuente (make all, make test integration, etc.)
    • Para ejecutar las pruebas de integración se necesita una imagen del kernel
  • Se admite una configuración de dependencias con versiones específicas relacionadas con gRPC/Protobuf
  • Incluye funciones para generación automática de documentación de la API y vista previa local

Contribuciones open source y estado del proyecto

  • Se aceptan contribuciones
  • La versión 0.1.0 es la primera versión oficial, y la estabilidad del código fuente solo está garantizada dentro del rango de la versión minor
  • Existe la posibilidad de que esta política cambie en futuras versiones minor

Resumen

  • Containerization es un innovador paquete Swift que permite a los desarrolladores administrar, ejecutar y desarrollar contenedores Linux en macOS dentro de un entorno optimizado
  • Al ejecutar cada contenedor en una máquina virtual dedicada y ligera, ofrece ventajas en aislamiento, rendimiento, redes y personalización del kernel
  • Es una solución adecuada para desarrolladores que buscan extender los entornos open source de contenedores hacia una experiencia nativa en macOS

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-06-10
Opiniones en Hacker News

  • Comparto lo que me pareció la parte más sorprendente e interesante

    Me parece bastante inusual la actitud de Apple al decir que reciben y fomentan contribuciones al proyecto container.
    WebKit fue un fork hostil de KHTML, y Darwin también daba la impresión de que arrojaban piezas por encima del muro, una por una.
    Ojalá en proyectos como estos, que Apple ha publicado recientemente en GitHub, se active más la colaboración entre usuarios y desarrolladores.
    Yo tengo una inclinación F/OSS (open source), pero por políticas de la empresa no puedo usar Linux y no me queda otra que usar Mac todos los días.
    Desde la llegada de Apple Silicon también cambié a Mac la laptop que uso en casa, pero últimamente las alternativas más amigables con Linux se sienten cada vez más cercanas, así que tengo muchas expectativas.
    Este tipo de cambios es una señal positiva y, para usuarios como yo que tenían un conflicto interno, resulta tranquilizador.
    Si esta colaboración open source de verdad genera un círculo virtuoso, creo que la cultura de colaboración entre Apple y la comunidad podría crecer mucho más.
    Me imagino un ambiente en el que desarrolladores como yo obtengan beneficios directos de estos cambios y, al mismo tiempo, hasta ganen respeto por Apple.

    • Hay quien opina que no debería sorprender tanto que Apple participe en la comunidad open source.
      Se menciona que Swift y sus frameworks relacionados también han recibido muchas contribuciones de la comunidad open source.

    • Como este proyecto trata con Linux, también está la visión de que Apple no tiene más remedio que colaborar debido al copyleft de Linux (licencia open source fuerte).

  • Recomiendan como video relacionado la sesión de WWDC 2025 (https://developer.apple.com/videos/play/wwdc2025/346/)
    La estructura separa cada contenedor como una VM ligera de Linux.
    Se puede ejecutar directamente descargando la herramienta container (https://github.com/apple/container/releases); requiere macOS 26.

    • Esta publicación es sobre https://github.com/apple/containerization y no sobre el proyecto container.
      containerization sirve para desplegar apps junto con un sidecar de contenedor, así que es una noticia todavía más interesante.
      En cambio, container está pensado para que los desarrolladores usen un entorno tipo docker run ....
      Sobre container, indican un hilo aparte en HN (https://news.ycombinator.com/item?id=44229239).

    • También puede funcionar en macOS 15, aunque algunas funciones de red podrían estar limitadas.

  • En el comunicado de prensa y en la sesión de WWDC se menciona que la herramienta CLI está en https://github.com/apple/container
    Como a algunos les interesan mucho este tipo de herramientas, esperaban que viniera incluida por defecto en la última Xcode Beta, pero todavía no está.
    El paquete prebuilt aún está en preparación, pero el estado del trabajo puede verse en el issue público (https://github.com/apple/container/issues/54).

  • Me pregunto cómo se sentirá Docker con esto.
    Imagino que una parte considerable de los usuarios de Docker for Desktop usa Mac.

    • Hay quien opina que este cambio en realidad le facilitará mucho el desarrollo a Docker Desktop.
      Ahora ya no necesitarían configurar su propia VM de Linux por separado, así que baja la dificultad de desarrollo.
      Aun así, predicen que muchos usuarios seguirán prefiriendo Docker Desktop por su CLI conocida, Docker Compose y varias experiencias de usuario propias de Docker.
      Cambiar el runtime de contenedores no es algo sencillo.

    • También se especula que Docker lo verá de forma parecida a como ve a podman.

    • Como Docker Desktop es software comercial de código cerrado y este proyecto es software libre, desde la perspectiva del usuario esto parece una buena noticia.

  • Hay curiosidad sobre si esta tecnología puede usarse para incluir contenedores Linux dentro de apps de macOS.
    Por ejemplo, sería útil para que una herramienta como GPT acceda a un entorno Linux sin requerir comandos CLI con privilegios de root.

    • Si te basta con que funcione solo en macOS 26, te sirve justo para ese objetivo.
      Si no, también podría hacerse usando directamente Virtualization.framework, aunque requiere más trabajo adicional.

    • Hay quien está convencido de que esta tecnología salió precisamente para ese caso de uso.

  • Que cada contenedor se ejecute en su propia VM aislada, con aislamiento completo e IP independiente, es una estructura interesante, pero este diseño no es algo familiar en Linux o Windows.
    Si en el equipo de desarrollo hay aunque sea una persona que no use Mac, el modelo de desarrollo local se rompe.
    La conclusión es que no será fácil reemplazar a Docker/Compose.

  • Dos de los tres principales sistemas operativos de escritorio ya pueden ejecutar oficialmente VMs de Linux para correr aplicaciones nativas de Linux.
    Viendo esta tendencia, se puede argumentar que Linux básicamente ya ganó.
    La API de syscalls de Linux ahora ocupa casi el lugar de una API universal que funciona en todas partes.

    • También hay una réplica: el simple hecho de que el desarrollo de aplicaciones basadas en Linux tenga que hacerse correctamente sobre dos grandes OS no-Linux no necesariamente significa una “victoria de Linux”.
      Se comparte la experiencia de que la realidad del escritorio Linux sigue siendo inestable y difícil de recomendar.
      Comentario sincero: aunque cada año instalan Fedora/Ubuntu en PCs o laptops recientes, todavía no sienten una buena experiencia de uso ni estabilidad.

    • Otra visión es que, al ofrecer formas de seguir usando Linux sin salir de esas otras dos plataformas, se frena el crecimiento de la cuota de Linux en el mercado de escritorio.

    • También se destaca como desventaja que todavía no hay una solución realmente adecuada para gráficos, audio y GUI.

    • Surge la pregunta: “si eres el único jugador en la partida, ¿realmente ganaste?”.
      En tono de broma, dicen que si se lo comentas a un usuario común de Windows o Mac, probablemente ni siquiera sepa qué es Linux.

    • También está la opinión de que el simple hecho de tener “macOS con Linux” ya tiene impacto.

  • Hay curiosidad por saber si también optimizaron la gestión de memoria, de modo que la VM no consuma más memoria de la necesaria.

  • No está claro cuál es exactamente el proceso, pero la sensación es que el build es demasiado lento.
    Incluso aumentando más recursos de CPU/memoria con las opciones -c y -m, no se nota gran mejora.

    • Preguntan con qué entorno se está comparando esa lentitud.
      Se comparte una experiencia pasada con una Mac Silicon + Rancher Desktop, donde parecía construir imágenes x86, pero luego esas imágenes no funcionaban correctamente en hardware x86 real.

  • En la demo corta (https://developer.apple.com/videos/play/wwdc2025/346) impresionó que la VM pudiera arrancar en el orden de cientos de milisegundos.
    Funciona sobre Virtualization.framework, una tecnología que también usaban opcionalmente Docker Desktop/Colima/UTM y otros.
    Hay curiosidad por el overhead de memoria al correr varios contenedores en paralelo.

    • Se explica que, gracias a una configuración optimizada del kernel de Linux (kernel config, https://github.com/apple/containerization/…), un root filesystem mínimo y un sistema init ligero, el arranque de los contenedores se redujo a menos de 1 segundo.