Mi servicio de videollamadas —Meet, un Jitsi propio— no vive en ningún servidor de pago por ahí fuera. Corre en el Mac mini de casa, dentro de cuatro contenedores Docker orquestados con docker compose: el frontend web, el puente de medios (JVB), el orquestador (Jicofo) y el XMPP (Prosody). Y todo eso lo levanta OrbStack, que en un Mac es la forma más cómoda y ligera de correr contenedores Linux.

Funciona estupendamente. Tanto, que esta misma semana actualicé OrbStack, se reiniciaron los cuatro contenedores solos y no tuve que tocar nada. Entonces, ¿por qué me planteo cambiarlo?

La tentación: contenedores sin Docker, hechos por Apple #

Desde hace un año, Apple trae su propio sistema de contenedores nativo en macOS: el framework Containerization y la herramienta container. Es código abierto, está escrito en Swift y está pensado al milímetro para el chip de los Mac. La idea es seductora: correr contenedores Linux sin Docker de por medio, sin una máquina virtual pesada montada todo el día, con una integración nativa con el sistema. Para una máquina que es a la vez mi servidor de todo, quitar una capa intermedia siempre suena bien.

Así que la pregunta era inevitable: ¿podría jubilar OrbStack y pasar mi Jitsi a los contenedores de Apple?

La respuesta, hoy, es todavía no. Y me parece más interesante contar por qué que fingir que ya está.

Los dos muros #

Mi Meet no es un contenedor suelto: son cuatro piezas que tienen que hablar entre ellas y salir a internet de una forma muy concreta. Ahí es donde choco.

1. No hay un compose nativo. La herramienta de Apple va, de momento, de un contenedor en uno. Pero mi Jitsi se define en un único archivo docker-compose.yml que describe los cuatro servicios, sus variables, su red interna y quién depende de quién. Sin un equivalente nativo a compose, migrar significaría reescribir toda esa orquestación a mano con scripts, o apoyarme en proyectos de terceros que aún están muy verdes. Para un servicio que uso de verdad, cambiar algo que funciona por algo artesanal y frágil no compensa.

2. El vídeo va por UDP, y eso era el punto débil. El puente de medios de Jitsi necesita exponer un puerto UDP al exterior para transportar el audio y el vídeo. Y precisamente el reenvío de puertos —y el de UDP en particular— era la parte más inestable de la herramienta de Apple, con fallos reportados de “acepta la conexión pero no la reenvía”. Justo lo único que mi Meet no se puede permitir.

Qué cambió este junio #

En la WWDC de este año Apple presentó macOS 27 Golden Gate. Trae bastante: una Siri rehecha, cambios de diseño, una búsqueda reconstruida de raíz, más controles parentales, mejoras de rendimiento… Pero, para lo que aquí me ocupa, conviene no confundirse: nada de eso toca los contenedores. Actualizar a la nueva versión, por sí mismo, no cambia nada de esta historia.

Lo que sí se movió fue el lado de desarrolladores, fuera del escenario. Por un lado, la herramienta container llegó a su versión 1.0. Y ahí hay una buena noticia a medias:

• El UDP ya se puede publicar. Añadieron el reenvío de puertos TCP y UDP. Es decir, el muro número dos ha empezado a caer, aunque con un asterisco: que exista la capacidad no quiere decir que sea fiable en producción, y eso habría que probarlo en banco antes de fiarme.
• El compose sigue sin existir. El muro número uno, el que de verdad me bloquea, sigue en pie. Es el límite que más señala todo el mundo.

Y hubo una cosa más, que al principio me ilusionó: Apple presentó Container Machine, con sesión propia incluida. Pero cuando miras qué es, no es lo que mi Jitsi necesita. Es un entorno Linux persistente al estilo del WSL de Windows: una máquina virtual ligera con su propio systemd, pensada para desarrollar en Linux desde el Mac —editas en el Mac, compilas y pruebas en Linux sin sincronizar archivos—, no un sistema para orquestar varios contenedores en producción. Podría meter mi Jitsi dentro de una de esas máquinas, pero eso sería rehacer, con más pasos, justo lo que OrbStack ya me da. No me destraba nada.

Así que he pasado de tener dos muros a tener uno y medio. Avanza, pero el que manda —la orquestación de varios contenedores— no ha caído.

Cuándo daré el salto #

No es un “no” definitivo, es un “todavía no”, y tengo claro qué espero para reabrir el tema:

• Que aparezca una forma nativa y estable de orquestar varios contenedores (un compose de Apple, o un tercero que se gane mi confianza).
• Que el reenvío de UDP demuestre ser sólido, no solo posible.

Mientras tanto, lo sensato es no tocar lo que funciona. OrbStack me da compose y un UDP fiable, que es exactamente lo que mi Jitsi exige. Lo que sí haré, sin prisa, es montar una prueba aparte —un contenedor inofensivo, sin tocar Meet— para irle cogiendo el pulso a la herramienta de Apple y estar listo el día que los dos muros caigan del todo.

Que una cosa funcione no es excusa para dejar de mirar qué viene detrás. Pero tampoco es razón para cambiarla antes de tiempo.