Diferencias entre FreeBSD Jails y contenedores Docker

Jails de FreeBSD frente a contenedores Docker, en un párrafo

Las jails de FreeBSD y los contenedores Docker resuelven el mismo problema con enfoques distintos. Ambos ejecutan entornos de usuario aislados sobre un mismo kernel compartido, por lo que ninguno de los dos es una máquina virtual. La diferencia reside en su contenido. Un contenedor Docker ejecuta un único proceso a partir de una imagen por capas descargada de un registro. Una jail ejecuta un entorno de usuario completo de FreeBSD: su propio /etc, sus propios scripts de inicio rc, su propia base de datos pkg y tantos procesos como se desee. Casi todas las demás diferencias expuestas en esta página derivan de este punto fundamental.

SSD Nodes no ofrece imágenes de FreeBSD. No es posible alquilar un servidor FreeBSD en esta plataforma y el contenido siguiente no es una guía de instalación para una máquina que pueda adquirir aquí. Se trata de una comparativa entre dos modelos de aislamiento, redactada para que pueda determinar cuál requiere su carga de trabajo y para que pueda interpretar la configuración de un equipo FreeBSD sin suposiciones.

Qué es realmente una jail

Las jails llegaron a FreeBSD 4.0 en marzo de 2000, lo que las hace más antiguas que los cgroups y aproximadamente una década más veteranas que Docker. El mecanismo consiste en una llamada al kernel. jail(8) toma un árbol de directorios e inicia procesos dentro de él con un ID de jail asignado; a partir de ahí, el kernel deniega un conjunto fijo de operaciones a cualquier proceso que porte dicho ID. Un proceso en una jail no puede ver procesos fuera de su entorno, no puede montar ni desmontar sistemas de archivos, no puede cargar módulos del kernel y no puede vincularse a direcciones de red que no hayan sido asignadas a la jail. No hay tipos de espacio de nombres separados que aprender ni activaciones por cada funcionalidad: las restricciones llegan como una unidad, ajustada mediante parámetros en la configuración de la jail.

En el host, jls lista las jails en ejecución y jexec web sh le sitúa en una shell dentro de la jail llamada web.

Usted construye una jail colocando el espacio de usuario (userland) de FreeBSD en un directorio. El sistema base hace esto por usted:

sudo bsdinstall jail /usr/local/jails/containers/web

Esto descarga el conjunto de distribución base para su versión y ejecuta los pasos habituales de post-instalación, por lo que usted establece una contraseña de root y selecciona una zona horaria exactamente igual que en un servidor nuevo. El resultado es una instalación de FreeBSD alojada en una carpeta. Luego, usted la describe en /etc/jail.conf:

web {
  host.hostname = "web.example.internal";
  path = "/usr/local/jails/containers/web";
  ip4.addr = "10.0.0.10";
  exec.start = "/bin/sh /etc/rc";
  exec.stop = "/bin/sh /etc/rc.shutdown";
  mount.devfs;
}

Iníciela y luego verifíquela:

sudo service jail start web
jls

jls debería listar ahora web con un JID, su nombre de host y su dirección IP. Si la jail no aparece, ejecute sudo jail -c web directamente. Esto aplica la misma configuración en primer plano e imprime el parámetro que no pudo aceptar, en lugar de dejar el fallo en la salida del servicio.

La línea que merece la pena leer dos veces es exec.start = "/bin/sh /etc/rc". Iniciar una jail ejecuta el script de arranque normal de FreeBSD en su interior, por lo que la jail pone en marcha todos los servicios habilitados en su propio /etc/rc.conf. Un contenedor Docker no tiene un paso equivalente, ya que ejecuta el proceso de punto de entrada de la imagen y se detiene cuando dicho proceso finaliza.

Cómo se obtiene el software: imágenes y registros frente a un espacio de usuario que usted completa

Esta es la diferencia que notará desde el primer día.

Con Docker, usted nombra el software y lo recibe. docker pull nginx descarga una imagen por capas y direccionada por contenido que alguien más construyó y probó, y docker compose up -d la inicia con sus volúmenes y su red adjuntos. El registro es el producto. La mayor parte del valor en un flujo de trabajo de Docker reside en que miles de proyectos publican una imagen funcional, lo cual hace que ejecutar Docker en un VPS sea una tarea breve en lugar de un proyecto.

FreeBSD no incluye un registro público predeterminado de imágenes de jail. Usted crea un espacio de usuario vacío e instala el software en él, de la misma manera que configuraría un servidor desde cero. Esto requiere más escritura. También es más transparente, porque lo que se ejecuta en la jail es lo que pkg instaló allí, utilizando el mismo conjunto de paquetes que emplea el host.

Las herramientas facilitan el proceso. BastilleBSD es el gestor de jails habitual y es un paquete:

sudo pkg install bastille
sudo sysrc bastille_enable=YES
sudo bastille setup
sudo bastille bootstrap 15.1-RELEASE

bastille setup configura la red, el almacenamiento y el firewall por usted. bastille bootstrap descarga una versión una sola vez, y cada jail que cree posteriormente la reutiliza. FreeBSD 15.1 es la versión de producción actual, lanzada en junio de 2026; sustitúyala por la versión que usted utilice.

Crear una jail es entonces un solo comando, y completarla requiere uno más:

sudo bastille create web 15.1-RELEASE 10.17.89.10/24
sudo bastille pkg web install nginx
sudo bastille service web nginx start
sudo bastille console web

bastille console web le proporciona una shell de inicio de sesión dentro de la jail, y bastille list muestra lo que existe en el host. Para repetir una compilación, las plantillas de Bastille almacenan los pasos en un archivo y los aplican a una jail, lo cual es lo más parecido que existe en este entorno a un Dockerfile. Una plantilla se reproduce en cada jail. Nada llega precompilado.

Por lo tanto, el resumen honesto es breve. Docker le entrega las compilaciones de otros. Las jails le entregan sus propias instalaciones. Si el software de su lista de candidatos se distribuye únicamente como una imagen de contenedor, eso resuelve la cuestión antes de que cualquier otro factor sea considerado.

Estado y actualizaciones: el papel de ZFS

Docker separa el estado deliberadamente. El sistema de archivos del contenedor es desechable, sus datos residen en un volumen con nombre o en un montaje de enlace (bind mount), y una actualización consiste en docker compose pull seguido de docker compose up -d. El contenedor se reemplaza y todo lo que no haya guardado en un volumen se pierde. Esto es una ventaja si sigue la regla y un incidente de pérdida de datos si la olvida; por eso la elección entre montajes de enlace y volúmenes con nombre tiene tanto peso en una pila de Compose.

Una jail no separa el estado, y ZFS es la razón por la que esto funciona. La jail completa es un único dataset:

sudo zfs snapshot zroot/jails/containers/web@pre-upgrade
sudo pkg -j web upgrade
sudo zfs rollback zroot/jails/containers/web@pre-upgrade

Compruebe el nombre real del dataset con zfs list antes de ejecutar esto; la ruta anterior es la estructura que utiliza el manual. La instantánea (snapshot) tarda aproximadamente un segundo y casi no ocupa espacio hasta que el contenido de la jail cambia. Si la actualización rompe el servicio, la reversión (rollback) devuelve todo el espacio de usuario a su estado anterior, incluyendo la base de datos de paquetes y los archivos de configuración que editó manualmente a las 2 de la mañana. Docker no tiene un equivalente integrado, porque su modelo asume que nunca lo necesitará.

zfs clone es la otra mitad. Un clon de una instantánea es una nueva jail escribible que comparte bloques inalterados con su padre, por lo que una copia de pruebas de una jail de 3 GB casi no cuesta espacio en disco hasta que empieza a modificarla. Así es como un administrador de FreeBSD crea una jail "idéntica a producción" para ensayar una actualización.

La actualización del sistema base es independiente de los paquetes. Para una jail que mantiene su propia copia del espacio de usuario:

sudo freebsd-update -b /usr/local/jails/containers/web fetch install

Las jails ligeras (thin jails) evitan repetir ese trabajo. Montan una base compartida de solo lectura a través de nullfs y proporcionan a cada jail una pequeña capa escribible propia, de modo que usted parchea la base una vez y todas las jails ven el resultado. Bastille crea jails ligeras de forma predeterminada.

Redes: puertos publicados frente a una decisión de direccionamiento

Docker gestiona la red por usted y le solicita que publique las excepciones. Los contenedores se sitúan en un puente, se comunican entre sí mediante el nombre del servicio en una red definida por el usuario, y -p 8080:80 expone uno de ellos al host. Docker escribe sus propias reglas de filtrado de paquetes para lograrlo, que es también la forma en que un puerto de contenedor publicado ignora directamente ufw.

Una jail le obliga a elegir el modelo desde el principio, y existen dos.

IP compartida. ip4.addr = "10.0.0.10" añade esa dirección a una interfaz existente del host y restringe la jail a ella. La jail no posee su propia pila de red, por lo que no puede ejecutar su propio firewall. Tampoco puede vincularse realmente a todas las direcciones: el kernel reescribe cualquier socket de la jail que solicite 0.0.0.0 hacia la propia dirección de la jail. Dos jails no pueden escuchar simultáneamente en el puerto 80 de la misma dirección, por lo que debe asignar una dirección a cada una o colocar un proxy inverso delante.

VNET. Añada vnet; a la jail y esta obtendrá una pila de red completa: sus propias interfaces, su propia tabla de enrutamiento y sus propias reglas de firewall. Usted la conecta al host con un epair, un cable virtual con un extremo en cada lado, y coloca el extremo del host en un puente. Este es el equivalente más cercano a lo que ofrece Docker, y es el modo que utilizan los tipos de jail -V y -B de Bastille.

Redirigir un puerto del host hacia una jail es una regla de redirección pf. Bastille lo encapsula:

sudo bastille rdr web tcp 80 80

No existe EXPOSE ni publicación automática. Nada llega a una jail a menos que su dirección o una regla de redirección lo permitan. Esto supone un inicio más lento y un firewall mucho más silencioso.

Límites de recursos: cgroups frente a rctl

Docker limita un contenedor mediante cgroups, y los límites residen donde se define el contenedor: --memory=1g --cpus=1.5 en la línea de comandos, o las claves correspondientes en un archivo Compose. Si ya mantiene su stack en un archivo Docker Compose en un VPS, el límite se sitúa junto al servicio al que se aplica y viaja con él en git.

FreeBSD utiliza rctl, y es un subsistema que debe activar. La contabilidad de recursos está desactivada por defecto porque supone un pequeño coste en cada asignación. Añada el parámetro ajustable a /boot/loader.conf y reinicie:

kern.racct.enable=1

A continuación, establezca una regla y monitorícela:

sudo rctl -a jail:web:vmemoryuse:deny=1g
rctl -hu jail:web

rctl -hu jail:web imprime el uso actual de la jail en unidades legibles para humanos, de modo que puede ver qué tan cerca está del límite antes de que algo falle. La acción deny hace que la asignación que supera el límite falle dentro de la jail, por lo que verá el error de asignación de la propia aplicación en lugar de un mensaje de terminación (kill) en el host.

Las reglas añadidas con rctl -a desaparecen en el siguiente reinicio. El servicio rctl de FreeBSD las recarga desde /etc/rctl.conf, así que escriba la regla en ese archivo y habilite el servicio:

sudo sysrc rctl_enable=YES

Este es el punto donde Docker es claramente más cómodo. Un límite en un archivo Compose se revisa junto al servicio que restringe. Una regla de rctl es una línea en un archivo independiente que hace referencia a una jail definida en otro lugar.

Cuando la respuesta es una máquina virtual: bhyve

Una jail comparte el kernel del host, por lo que algunas funciones son inaccesibles de forma permanente. No puede ejecutar una versión de kernel distinta, no puede cargar módulos del kernel y no puede ejecutar binarios de Linux de la misma forma que un contenedor de Linux. FreeBSD cuenta con una capa de compatibilidad con Linux, el linuxulator, pero esta implementa un subconjunto de llamadas al sistema de Linux y no es una solución general para imágenes de Linux arbitrarias.

bhyve es el hipervisor de FreeBSD y es la herramienta adecuada cuando se requiere un límite de máquina real: un sistema operativo distinto, un kernel diferente o un inquilino con el que prefiere no compartir el kernel. El coste es la memoria reservada en lugar de compartida y un segundo kernel que mantener actualizado. Es la misma decisión que se toma en Linux entre contenedores y máquinas virtuales completas, y es la que determina si necesita un VPS que soporte virtualización anidada como base.

El ecosistema, la razón principal por la que la mayoría de los equipos usan Docker

Todo lo anterior trata sobre el modelo. Lo que determina la elección de la mayoría de los equipos es el tamaño del entorno que rodea a cada uno.

Docker aporta Docker Hub y GHCR, docker compose, Kubernetes cuando un solo servidor deja de ser suficiente, ejecutores de CI con soporte para contenedores ya integrado y un inicio rápido mediante un solo comando en el README de casi cualquier proyecto. Las Jails ofrecen el árbol de ports de FreeBSD, que es extenso y se mantiene cuidadosamente, además de un conjunto mucho más reducido de paquetes de aplicaciones listos para ejecutar. Cuando un proyecto publica una imagen de contenedor y nada más, la ruta en FreeBSD consiste en leer su documentación y ensamblar las piezas usted mismo.

Las Jails se ganan su lugar en el otro lado de esa balanza. Usted las querrá cuando ya utilice ZFS y valore la capacidad de realizar instantáneas (snapshots) y revertir un servicio completo, cuando sus servicios sean nativos de FreeBSD, cuando desee un espacio de usuario (userland) completo por inquilino en lugar de un único proceso, o cuando prefiera que el kernel, el filtro de paquetes, el sistema de archivos y la documentación se mantengan juntos como un solo sistema. Ese último punto es a lo que se refieren las personas cuando dicen que FreeBSD es coherente, y se trata con más detalle en la comparativa más amplia entre Linux y FreeBSD como plataformas de servidor y en lo que FreeBSD 15 cambió para el uso en servidores.

Una valoración final. Si su equipo ya conoce Docker, el coste de migrar es real y la recompensa debe ser específica. No cambie por la calidad del aislamiento; ambos modelos son lo suficientemente similares como para que su configuración sea lo que realmente importa. Cambie porque desea revertir servicios completos mediante ZFS, o porque ya utiliza FreeBSD.

FAQ

¿Puedo ejecutar imágenes de Docker en FreeBSD?

No imágenes de Linux, y no como una ruta soportada. FreeBSD cuenta con soporte para contenedores OCI: sudo pkg install -y podman-suite instala Podman, que ejecuta contenedores mediante ocijail, un entorno de ejecución que crea jails reales subyacentes. Requiere fdescfs montado en /dev/fd para el monitor de contenedores, y pf para la NAT (traducción de direcciones de red) de los contenedores. Las imágenes OCI nativas de FreeBSD funcionan mejor. Las imágenes de Linux requieren adicionalmente la capa de compatibilidad con Linux y, a fecha de agosto de 2026, el port de Podman para FreeBSD sigue considerándose experimental. Si su despliegue consiste en una pila de imágenes de Linux, ejecútelo sobre Linux.

¿Son las jails de FreeBSD más seguras que los contenedores de Docker?

Ambas comparten el mismo kernel del host, por lo que un error en el kernel supone un riesgo para ambas, y ninguna constituye el límite que elegiría para código verdaderamente no confiable. La diferencia radica en el punto de partida. Una jail comienza con un amplio conjunto de operaciones denegadas que usted debe habilitar parámetro a parámetro. Un contenedor de Docker comienza como root dentro de un conjunto de espacios de nombres con algunas capacidades eliminadas, y el endurecimiento adicional es opcional. En la práctica, la configuración determina más que el modelo: una jail ejecutándose con allow.mount y allow.raw_sockets habilitados no es más segura que un contenedor configurado cuidadosamente.

¿Cómo realizo una copia de seguridad de una jail?

Tome una instantánea del dataset y envíela. sudo zfs snapshot zroot/jails/containers/web@backup, luego zfs send esa instantánea a otro pool o a un archivo que copie fuera del equipo. Dado que una jail mantiene todo su espacio de usuario en un único dataset, la instantánea captura los paquetes instalados y los datos en un punto consistente, junto con cada archivo de configuración que haya editado manualmente. Esto es lo opuesto a la costumbre de Docker, donde se respaldan los volúmenes con nombre y el archivo Compose, y se reconstruye el resto a partir de la imagen.

¿Necesito BastilleBSD o el sistema base es suficiente?

El sistema base es suficiente y es el mejor lugar para empezar. jail.conf, jls, jexec y service jail start cubren todo el modelo; una vez que los conozca, podrá leer cualquier host de FreeBSD sin necesidad de aprender primero las herramientas específicas de ese host. Bastille es una capa de conveniencia sobre el mismo: arranca versiones, crea jails ligeras, aplica plantillas y escribe reglas de redirección de pf por usted. Aprenda primero los comandos base y añada Bastille cuando la cantidad de jails haga que escribir los comandos sea tedioso.