Ejecutar contenedores sin Docker: container-rs en Rust

Q: ¿Puedo ejecutar contenedores en macOS sin Docker Desktop?

Sí. En Apple Silicon podés usar el runtime container de Apple, que corre contenedores Linux en máquinas virtuales livianas, y container-rs se conecta a él vía XPC. No necesitás Docker Desktop instalado para que tus tests de integración en Rust funcionen.

En pocas palabras: container-rs es un crate de Rust publicado por shiguredo —la organización japonesa detrás del SFU WebRTC Sora— que levanta contenedores efímeros en tus tests sin Docker Desktop: en macOS habla por XPC con el runtime container de Apple y en Linux usa la API de Docker Engine, compatible también con Podman.

Shiguredo publicó container-rs, una librería de Rust para levantar contenedores efímeros dentro de tus tests sin depender de Docker Desktop. La gracia: en macOS habla directo con el runtime container de Apple, así que podés ejecutar contenedores sin Docker en la Mac, y en Linux sigue usando la API de Docker Engine de siempre.

container-rs es una librería (crate) de Rust creada por shiguredo, la organización japonesa detrás del SFU WebRTC Sora, que levanta y destruye contenedores desde tests automatizados. En macOS se apoya en el runtime container de Apple mediante su API XPC, sin Docker Desktop instalado; en Linux se comunica con la API de Docker Engine, compatible también con Podman. Está publicada en GitHub y en lib.rs.

En 30 segundos

Qué es: un crate de Rust para levantar contenedores de testing, al estilo testcontainers, publicado por shiguredo en GitHub y lib.rs.
El diferencial: soporte del runtime container de Apple en macOS, algo que testcontainers-rs todavía no cubre.
En Linux no cambia nada: usa la API de Docker Engine, con la que Podman también es compatible.
Alcance: testing e integración local, no un runtime de producción. Para eso están runc, crun o youki (este último, también escrito en Rust).
Costo: cero. Es open source, y la licencia figura en el repo.

¿Qué problema resuelve container-rs que testcontainers-rs no resolvía?

El hueco es puntual: testcontainers-rs no soporta el runtime de contenedores de Apple. Si trabajás en una Mac con Apple Silicon y decidiste sacarte Docker Desktop de encima, tus tests de integración se quedaban sin backend. container-rs cubre justo ese caso, manteniendo una API parecida a la que ya conocés y agregando la ruta nativa de macOS.

Y ojo, que esto no salió de la nada. Rust viene siendo el lenguaje elegido para reescribir capas de contenedores desde hace rato: youki es un runtime OCI completo en Rust, y hay series enteras documentando cómo construir un runtime desde cero con namespaces y cgroups. container-rs juega un escalón más arriba, en la capa de orquestación para tests.

¿Cuándo conviene ejecutar contenedores sin Docker en tu flujo de testing?

Conviene cuando Docker Desktop es un costo (de licencia, de RAM o de fricción) y lo único que necesitás es un Postgres efímero durante 40 segundos. Ponele que tenés un test de integración que levanta una base, corre 12 migraciones, valida y destruye todo: para eso no hace falta un daemon corriendo todo el día comiéndote memoria. Más contexto en herramientas de CI/CD contemporáneas.

Desarrollo local en macOS: el caso más obvio. Apple Silicon, sin Docker Desktop, y aún así los tests de integración corren.
CI/CD con runners propios: en GitHub Actions o GitLab CI sobre runners Linux, container-rs habla con Docker Engine o Podman según lo que tengas instalado.
Entornos con Docker restringido: hay empresas donde instalar Docker Desktop pasa por un comité. Si tenés Podman aprobado, zafás.
Equipos mixtos: devs en Mac, CI en Linux, y el mismo código de test para los dos.

¿Cómo funciona container-rs en macOS comparado con Linux?

Son dos caminos distintos bajo la misma API. En macOS, container-rs se comunica con el runtime container de Apple a través de XPC, el mecanismo de comunicación entre procesos del sistema, que a su vez levanta cada contenedor en una VM liviana. En Linux, en cambio, no hay nada exótico: habla el protocolo de la API de Docker Engine, el mismo que implementa Podman en su socket compatible.

Esa diferencia arquitectónica tiene una consecuencia práctica que conviene tener en la cabeza. Levantás el test en tu Mac, anda perfecto, lo mandás al pipeline en Linux y ahí el modelo de red es otro, el montaje de volúmenes se comporta distinto, el arranque tarda diferente porque no hay VM de por medio, y de repente el test que era verde se pone caprichoso. No es culpa de la librería: es la naturaleza de correr dos runtimes distintos detrás de la misma interfaz.

container-rs vs Docker vs Podman: ¿cuál es la diferencia real?

No compiten en la misma categoría, y esa es la confusión más común. container-rs es una librería que orquesta contenedores desde código Rust; Docker y Podman son plataformas completas de contenedores. La comparación válida es contra testcontainers-rs, no contra Docker. En soluciones para automatizar tu pipeline profundizamos sobre esto.

Herramienta	Qué es	macOS sin Docker Desktop	Uso en producción
container-rs	Librería Rust de contenedores para tests	Sí (runtime container de Apple)	No, orientada a testing
testcontainers-rs	Librería Rust de contenedores para tests	No soporta el runtime de Apple	No, orientada a testing
Docker	Plataforma de contenedores con daemon	Requiere Docker Desktop o alternativa	Sí
Podman	Plataforma sin daemon, API compatible	Vía máquina virtual (podman machine)	Sí
youki	Runtime OCI de bajo nivel en Rust	No aplica (Linux)	Sí, como reemplazo de runc

ejecutar contenedores sin docker diagrama explicativo

¿Cómo instalo container-rs en un proyecto Rust?

Se agrega como dependencia de desarrollo con Cargo, más el runtime correspondiente a tu sistema operativo. En macOS necesitás el runtime container de Apple instalado (requiere Apple Silicon); en Linux, Docker Engine o Podman con su socket habilitado. Del lado de Rust, alcanza con una línea en el Cargo.toml.

# En la raíz del proyecto
cargo add --dev container-rs

# macOS: runtime de Apple (Apple Silicon)
brew install --cask container

# Linux: alcanza con Docker Engine o Podman ya instalados
docker info # o: podman info

La API concreta (nombres de traits, imágenes predefinidas, cómo se resuelven puertos) está en el README del repo y en la doc del crate. No te fíes de ejemplos copiados de blogs, incluido este: mirá la versión publicada en lib.rs, porque en un proyecto joven la superficie de API se mueve.

¿Cómo migro desde testcontainers-rs?

La migración es de bajo riesgo porque el patrón de uso es el mismo: definís la imagen, la levantás, pedís el puerto mapeado, armás la cadena de conexión, corrés el test y el contenedor muere solo al terminar el scope. Lo que cambia es el crate que importás y, según el caso, algún nombre de tipo.

Migrá un test primero: el más simple que tengas, con una sola imagen. Si pasa en Mac y en el CI Linux, seguí con el resto.
Revisá los healthchecks: si esperabas readiness con un sleep fijo (mala práctica, pero pasa), en macOS el arranque por VM puede tardar distinto y el test se te cae.
Cuidado con los volúmenes: las operaciones de archivos entre host y contenedor son el punto donde más difieren las dos rutas.
Dejá el fallback: mantené testcontainers-rs detrás de una feature flag hasta que tengas dos semanas de CI verde.

¿Qué significa esto para equipos en Latinoamérica?

Impacta en costos, sobre todo. Los runners macOS hosteados son los más caros de cualquier proveedor de CI, así que muchos equipos de la región resuelven el pipeline en Linux y dejan la Mac solo para desarrollo local. Con container-rs, el dev en macOS deja de necesitar Docker Desktop (que para empresas de cierto tamaño es licencia paga) y el pipeline sigue corriendo sobre infraestructura Linux, ya sea en un VPS o en cloud con donweb.com. Menos licencias, mismo test.

Qué está confirmado y qué no

Acá conviene ser prolijo, porque es un proyecto joven y circula bastante entusiasmo prematuro. Ya lo cubrimos antes en ejecutar en múltiples regiones.

Confirmado: el proyecto existe, es de shiguredo, está publicado en GitHub y como crate en lib.rs.
Confirmado: apunta a contenedores para testing, con soporte del runtime de Apple en macOS y de la API de Docker Engine en Linux.
No confirmado: no hay benchmarks independientes que comparen su tiempo de arranque contra testcontainers-rs. Si ves una cifra por ahí, pedí la metodología.
No confirmado: el nivel de compromiso de soporte a largo plazo. Shiguredo publica mucho OSS y cada repo define su propia política de soporte en el README. Leelo antes de meterlo en un pipeline crítico.
A verificar en el repo: licencia exacta, versión mínima de Rust (MSRV) y catálogo de imágenes soportadas de fábrica.

Errores comunes al adoptar container-rs

Tres que vas a cometer si venís de Docker y no prestás atención.

Usarlo como runtime de producción. Es una librería de testing. Para producción, el stack es runc, crun o youki bajo un orquestador, no un crate que levanta contenedores desde un test.
Asumir paridad total entre macOS y Linux. Son dos backends distintos. Corré la suite completa en las dos plataformas antes de sacar testcontainers-rs del proyecto (spoiler: alguna prueba de archivos te va a fallar).
Fijar puertos del host a mano. Si hardcodeás el 5432, dos tests en paralelo se pisan. Pedile siempre el puerto mapeado a la librería y armá la conexión con eso.
Olvidarse del cleanup en CI. Si el proceso muere por timeout, pueden quedar contenedores colgados quemando recursos del runner. Agregá un paso de limpieza al final del job.

Preguntas Frecuentes

¿Qué es container-rs?

Es una librería de Rust publicada por shiguredo para levantar y destruir contenedores desde tests automatizados. Soporta el runtime container de Apple en macOS y la API de Docker Engine en Linux. El código está en github.com/shiguredo/container-rs.

¿Puedo ejecutar contenedores en macOS sin Docker Desktop?

Sí. En Apple Silicon podés usar el runtime container de Apple, que corre contenedores Linux en máquinas virtuales livianas, y container-rs se conecta a él vía XPC. No necesitás Docker Desktop instalado para que tus tests de integración en Rust funcionen.

¿Cuánto cuesta container-rs?

Nada. Es un proyecto open source disponible como crate público en lib.rs y con el código en GitHub. La licencia específica figura en el repositorio y conviene revisarla antes de usarlo en un producto comercial. Para más detalles técnicos, mirá alternativas sin dependencia de APIs.

¿Funciona con Podman?

En Linux, sí, porque Podman expone un socket compatible con la API de Docker Engine, que es la que usa container-rs. Necesitás habilitar el servicio de socket de Podman y apuntar la variable de entorno correspondiente a ese socket.

¿Es más rápido que Docker para testing?

No hay benchmarks públicos independientes que lo confirmen, así que cualquier número que veas circulando tomalo con pinzas. Lo que sí evitás en macOS es tener el daemon de Docker Desktop corriendo de fondo todo el día, que es un ahorro de RAM medible en tu propia máquina.

Conclusión

Lo que cambió es chico pero concreto: si desarrollás en Rust sobre una Mac y querías sacarte Docker Desktop de encima, hasta ahora tus tests de integración te lo impedían. container-rs saca ese impedimento.

¿Vale la pena migrar toda tu suite mañana? Todavía no. Es un proyecto joven, sin benchmarks independientes y con una política de soporte que tenés que leer en el README antes de apoyarte en él. El movimiento sensato es probarlo en un test de integración de una sola imagen, correrlo en macOS y en el CI Linux durante un par de semanas, y recién ahí decidir. Si el ahorro de licencias y de RAM en las máquinas del equipo te cierra, la migración es barata. Si tu suite depende mucho de montar archivos, andá despacio.

container-rs: contenedores sin Docker en macOS y Linux