- Un texto que repasa la historia del despliegue en servidores y de los problemas de aislamiento de procesos, destacando que los FreeBSD jails implementaron el concepto moderno de contenedores una década antes que la industria
- Introducidos en FreeBSD 4.0 en el año 2000, los jails ampliaron
chroot para ofrecer aislamiento completo de sistema de archivos, red y procesos como una función nativa del kernel
- Linux llegó a los contenedores con LXC en 2008 y Docker en 2013, pero en el proceso acumuló capas complejas de abstracción como namespace, cgroups y OCI
- Lo que Docker resolvió muy bien fue el problema del empaquetado y despliegue de aplicaciones (shipping), mientras que los jails destacan en aislamiento pero tienen como debilidad la ausencia de un estándar nativo de distribución
- En la siguiente parte se abordará cómo construir infraestructura basada en jails, snapshots de ZFS y aprovisionamiento con Ansible, entre otros métodos de operación reales
Los problemas del despliegue inicial en servidores
- Hace décadas, la forma estándar de desplegar algo en un servidor era copiar archivos manualmente por FTP usando herramientas como Total Commander, FileZilla o FAR Manager; los usuarios más avanzados usaban
scp o rsync, pero la esencia era la misma
- En proyectos donde trabajaba una sola persona, los errores no eran un gran problema, pero al gestionar decenas de proyectos de clientes podían ser fatales
- En una configuración típica de backend, varios sitios web compartían la misma instancia del servidor web Apache y el mismo ciclo de vida; si Apache caía, caían todos
- Cuando el tráfico se disparaba, si un sitio consumía todos los recursos, los demás sitios del mismo servidor se asfixiaban en silencio
- Los administradores de sistemas intentaban automatizar con scripts de shell, pero no existía un método estándar para control de versiones o rollback, así que era común usar nombres de carpetas de proyecto con números incrementales o marcas de tiempo
Dos problemas clave que había que resolver
- Despliegue (Deployment): se necesitaba una solución general que cubriera todos los casos de negocio, con entrega confiable, prevención de errores humanos, control de versiones y rollback
- Aislamiento de procesos (Process Isolation): se necesitaba protección mutua entre aplicaciones y sistema, evitar que los requisitos de una app rompieran en secreto a otra y resolver conflictos de dependencias
- Los intentos por resolver el problema del despliegue evolucionaron hacia los modernos pipelines de CI/CD, estándares de empaquetado y sistemas de control de versiones, pero la historia del aislamiento es relativamente menos conocida
De chroot a las máquinas virtuales
chroot, introducido por Bell UNIX en 1979, ofrecía a un proceso una vista aislada del sistema de archivos, impidiéndole acceder fuera de un subárbol: una idea primitiva, pero útil
- Limitación: solo aislaba el sistema de archivos; todavía era posible interferir con la red, otros procesos y recursos del sistema, e incluso escapar
- La primera respuesta empresarial seria fue la máquina virtual (VM), popularizada por VMware a finales de los años 90
- Daba a cada aplicación un entorno de sistema operativo completamente aislado, pero como cada VM incluía un SO completo, existía el costo de un overhead considerable y tiempos de arranque medidos en minutos
El nacimiento de FreeBSD Jails
- En el año 2000 ocurrió una revolución silenciosa, no en Windows Server ni en Linux, sino en FreeBSD
- FreeBSD funciona de una manera fundamentalmente distinta a Linux: mientras Linux proporciona solo el kernel y combina aparte el userland de GNU, el ecosistema de paquetes y las decisiones de cada distribución, FreeBSD desarrolla, versiona y prueba kernel, userland, herramientas base y bibliotecas como un único sistema operativo completo
- La solución construida sobre esa base coherente fue jails, presentada por Poul-Henning Kamp y Robert Watson, e incorporada como función nativa del kernel en FreeBSD 4.0 (marzo de 2000)
- Cada jail tiene su propia vista del sistema de archivos, stack de red y espacio de procesos, y el sistema host no es visible
- Como comparten el kernel del host, logran un overhead cercano a cero y tiempos de arranque casi instantáneos
- FreeBSD consiguió en producción una implementación práctica de lo que hoy llamamos contenedores una década antes que la industria
Línea de tiempo de las tecnologías de aislamiento
- La ruta real de evolución del problema del aislamiento fue: servidores compartidos sin aislamiento → máquinas virtuales pesadas pero aisladas → contenedores ligeros y aislados
- FreeBSD llegó a la tercera etapa en 2000; Linux lo hizo con LXC en 2008; Docker apareció en 2013
- Cuando Docker era elogiado como revolucionario, FreeBSD jails ya llevaba 13 años de madurez y validación en producción
Por qué Linux ganó
- La superioridad técnica no garantiza la victoria en una guerra de ecosistemas
- Linux ganó gracias a decisiones rápidas, el efecto viral de la licencia GPL y el fuerte respaldo empresarial de Red Hat e IBM
- Después, Google, Facebook y Amazon desarrollaron herramientas para centros de datos a gran escala y marcaron la dirección de toda la industria
- Linux pasó de ser “el SO gratis para quienes no podían pagar una licencia comercial” a “la única opción para servidores”
La complejidad del ecosistema de contenedores en Linux
- Para resolver los problemas de aislamiento y despliegue, los ingenieros de Linux construyeron primitivas del kernel como namespace, cgroups y seccomp, y sobre ellas apilaron capas complejas de abstracción como LXC (2008) → OCI/runc (2015) → Docker/Podman (2013/2018) → Docker Hub
- El resultado fue una masa sobreingenierizada de abstracciones con fugas (leaky abstractions) pensada para infraestructura en la nube y dependiente de proveedores
- Hoy, operar aplicaciones en sistemas a gran escala implica de forma predeterminada contenedorizarlas con Docker y orquestarlas con Kubernetes; ya no se presenta como una opción entre varias, sino como la elección obvia
El aporte de Docker y la debilidad de Jails
- Lo que Docker resolvió muy bien fue el problema de shipping: empaquetar aplicaciones junto con todas sus dependencias, distribuirlas mediante un registro y ejecutarlas igual en cualquier máquina, ofreciendo un estándar general
- El formato de imagen OCI se consolidó como estándar de facto de la industria
- Jails resuelve muy bien el problema del aislamiento, pero carece de una solución nativa para shipping, y esa es la razón principal por la que el ecosistema de jails se percibe menos maduro que el de Docker
- La comunidad también reconoce esta brecha, y algunas herramientas (
cbsd, bastille, pot, appjail, etc.) intentan imitar el ecosistema moderno de contenedores, aunque también existen otros enfoques que aprovechan primitivas nativas de FreeBSD
Avance de la siguiente parte
- En la próxima parte se explicará la simplicidad y elegancia de una infraestructura basada en FreeBSD, desde los fundamentos de jails y su funcionamiento, hasta la reducción de boilerplate con administradores de jails, el aprovisionamiento y despliegue con Ansible, la potencia de los snapshots de ZFS y cómo combinar todo eso para construir una infraestructura sólida y escalable para Hypha
1 comentarios
Comentarios en Hacker News
La superioridad técnica por sí sola no bastó para ganar la guerra de ecosistemas
A mediados de los 90, Linux creció gracias a una toma de decisiones rápida, la naturaleza expansiva de la licencia GPL y el respaldo empresarial de Red Hat e IBM
Yo instalé Linux en 1994, pero en la comunidad de FreeBSD despreciaron mi PC de $3,500 diciendo que era “meh”
Había un bug en la interfaz IDE, pero Linux sacó una solución alternativa en pocos días, mientras que del lado de BSD solo me dijeron que comprara equipo SCSI
En ese entonces yo era universitario y no tenía dinero, así que Linux terminó siendo la opción realista
Más adelante volví a probar FreeBSD, pero para entonces Linux ya hacía todo lo que yo necesitaba
El bug relacionado está resumido en el artículo de Wikipedia sobre CMD640
Aun así, me gusta que FreeBSD mantenga una mayor coherencia del sistema y que componentes clave como el sonido o las API de eventos se conserven estables
El soporte para drivers de hardware reciente sigue siendo mejor en Linux, pero ojalá FreeBSD no se “linuxifique” demasiado
La verdad es que con cualquier *nix moderno se puede hacer casi todo. Ahora es más una cuestión de preferencias y costumbre que de rendimiento
En cambio, BSD generaba rechazo en las empresas por la demanda con AT&T, y mientras tanto Linux se quedó con el mercado
Incluso ahora aparecen textos defendiendo a FreeBSD, pero es difícil romper una tendencia que quedó fijada en los 90
Aun así, creo que el soporte de hardware todavía tiene bastante margen de mejora
El texto me pareció interesante
No estoy de acuerdo con la idea de que primitivas del kernel de Linux como namespaces, cgroups y seccomp terminaron creando un ecosistema de abstracciones complejas
Linux se volvió complejo porque tuvo éxito, no por un diseño fallido
Si BSD hubiera sido la opción dominante, habría surgido exactamente el mismo ecosistema “sobreingenierizado”
Los contenedores al final no son más que VM ligeras, así que me parece mejor usar VM de verdad
Docker se hizo popular por la reutilización y el ecosistema, no por el aislamiento de seguridad
El jail de FreeBSD es simple y elegante, pero los contenedores OCI de Linux son mucho más fáciles de usar
Un contenedor no es una función independiente del kernel, sino una ilusión construida combinando varios namespaces, montajes y aislamiento de procesos
El diseño de Linux fue intencional, y cgroups y seccomp se usan ampliamente también fuera de los contenedores, por ejemplo en systemd o flatpak
La filosofía de “ganado vs mascotas” puede aplicarse en el nivel de VM y orquestación
Decir que los jails son mejores no me resulta convincente en la práctica
Docker ganó no por el aislamiento técnico, sino por el ecosistema
Gracias a herramientas como Dockerfile, el registro público y compose, era posible crear un entorno ejecutable en 30 segundos
El jail de FreeBSD era técnicamente excelente, pero tenía una barrera de entrada alta
Últimamente también se ve un movimiento de regreso a jails o VM simples por la complejidad del stack de contenedores
Pero no se trata de competir, sino de que cada uno cumple un rol distinto
FreeBSD no tiene un concepto así y también carece de un buen sistema de imágenes
Si FreeBSD hubiera invertido en UX y ecosistema como lo hizo Docker, su base de usuarios sería varias veces mayor
Hacia 2005 operábamos toda una empresa sobre FreeBSD
Pero con el tiempo Linux terminó dominando tanto en lo personal como en el trabajo
Ahora Docker también es lo bastante bueno y ya no hay una razón lógica para volver
Pero reaccionó tarde a la era de los CPU multinúcleo y quedó atrás frente a Linux y Windows
Hoy el rendimiento se ha recuperado, pero sigue en desventaja por la falta de drivers y la cantidad limitada de desarrolladores
Yo uso Linux donde necesito GPU o CUDA, y FreeBSD para servidores estables
La UX de FreeBSD es más coherente, pero en la práctica Linux se volvió el “camino feliz”
Siempre da gusto ver un texto que presenta FreeBSD
FreeBSD introdujo jail en 2000, pero Linux ya tenía tecnologías parecidas como OpenVZ y VServer
Al final, cuando apareció LXC a fines de los 2000, se instaló la idea de que “FreeBSD iba adelantado”
Me da curiosidad si existe algún texto que explique técnicamente cómo se implementa el aislamiento en contenedores y VM
No solo al nivel de decir “comparten el mismo kernel, así que son más débiles”, sino con detalles reales de implementación
Últimamente, por funciones como systemd-oomd, me dan ganas de volver a FreeBSD
Antes desarrollaba dejando varios procesos corriendo en la terminal y guardando logs,
pero ahora systemd mata procesos completos a nivel de cgroup, y eso hace que pierda trabajo
Estos cambios incompatibles del sistema rompen el flujo de desarrollo, y me frustra tener que usar systemd-run o Docker cada vez para aislar procesos
La clave del éxito de Linux fue la naturaleza contagiosa de la GPL y los efectos de red
A medida que los usuarios empezaron a ver Linux como el estándar, los fabricantes de hardware naturalmente comenzaron a sacar drivers para Linux
Gracias a la flexibilidad del kernel, el ecosistema de drivers de código abierto creció de forma explosiva