Aislar servicios locales: recursos, red y reversión operativa

Ejecutar servicios de inferencia en una máquina propia parece sencillo hasta que comparten disco, puertos, memoria y rutinas de mantenimiento con el resto del homelab. El problema no es sólo que un proceso falle: es que un cambio poco delimitado convierta una prueba en una incidencia que afecte a copias de seguridad, monitorización, automatizaciones o a otros servicios domésticos.

La noticia que motiva esta revisión es concreta y limitada: el repositorio oficial ollama/ollama anuncia la versión de software v0.40.6, publicada el 16 de octubre de 2026. Es una publicación de tooling, no el anuncio de un modelo ni una garantía sobre comportamiento, rendimiento o compatibilidad de una instalación concreta.

El aislamiento empieza por definir el radio de daño

Antes de elegir contenedor, máquina virtual o proceso nativo, conviene responder una pregunta operativa: si este servicio se bloquea, consume más recursos de los previstos o requiere restauración, ¿qué más puede dejar de funcionar? La respuesta define el perímetro útil.

En una instalación pequeña, aislar no equivale a levantar una infraestructura compleja. Significa separar de forma explícita cuatro planos: identidad del proceso, recursos de cómputo, datos persistentes y exposición de red. Cuando esos planos se mezclan, el diagnóstico se vuelve ambiguo y la reversión pierde precisión.

• Proceso: usuario de ejecución, directorio de trabajo, variables de entorno y permisos mínimos.
• Recursos: límites y observación de CPU, memoria, almacenamiento temporal y, si aplica, aceleración disponible.
• Datos: volúmenes, cachés y artefactos con rutas conocidas y política de retención.
• Red: puertos publicados sólo donde hagan falta y comunicación interna definida por necesidad.

Contenedor no significa frontera absoluta

Un contenedor es una buena unidad de despliegue cuando reduce diferencias entre entornos y hace visible su configuración. Pero no sustituye el diseño de permisos. La documentación de Docker explica que los contenedores utilizan espacios de nombres y grupos de control, y que cada contenedor dispone de su propia pila de red; también advierte, en la práctica, que publicar puertos habilita tráfico que debe gobernarse de forma deliberada. Ese marco resulta útil para pensar el servicio como una pieza acotada, no como un proceso con acceso implícito a todo el host.

La referencia técnica está en la documentación de seguridad de Docker Engine. Conviene leerla como base de arquitectura, no como una receta que elimine la necesidad de revisar montajes, privilegios y reglas de red.

Separar estado de ejecución

La práctica más rentable es distinguir datos que deben sobrevivir de datos que pueden recrearse. Un directorio persistente no debería ser un cajón de sastre. Si modelos, configuraciones, registros, cachés y temporales comparten ubicación, limpiar espacio o restaurar una versión se vuelve arriesgado.

Esta separación también mejora las actualizaciones. Si la versión del servicio cambia, el operador puede preservar la configuración y los datos necesarios sin arrastrar residuos de ejecuciones anteriores. La reversión deja de ser “deshacer cosas” y pasa a ser restaurar una unidad conocida.

Presupuesto de recursos antes que optimización

En un host compartido, el recurso crítico no siempre es el procesador. La memoria puede desplazar procesos vecinos, el almacenamiento puede llenarse por cachés y registros, y una tarea de descarga puede competir con copias de seguridad. Por eso es preferible acordar un presupuesto inicial y revisarlo con observabilidad básica.

1. Reserve un margen para el sistema operativo y los servicios que no pueden degradarse.
2. Establezca un límite de memoria o, como mínimo, un umbral de alerta comprensible.
3. Separe el almacenamiento persistente del espacio temporal y mida ambos.
4. Defina qué puerto escucha el servicio y en qué interfaz; no publique por inercia.
5. Registre reinicios, errores y cambios de configuración junto con su momento de despliegue.

El objetivo no es demostrar una cifra universal. Es detectar desviaciones respecto al comportamiento esperado de ese host. Una gráfica de memoria sin contexto ayuda poco; una gráfica asociada a una versión, una configuración y una ventana de cambio sí permite decidir si revertir, ampliar el presupuesto o investigar.

Red mínima: accesible no es lo mismo que expuesto

Un servicio local puede necesitar ser consumido por otra aplicación del mismo host, por una red privada o sólo durante una sesión administrativa. Son tres necesidades distintas. Trátelas como tales. Publicar un puerto en todas las interfaces para resolver una prueba rápida suele convertir una decisión temporal en superficie permanente.

Una pauta conservadora consiste en iniciar con acceso local, abrir conectividad sólo al consumidor identificado y documentar el motivo. Si hay un proxy inverso, una automatización o una interfaz web delante, cada salto debe conservar límites claros: autenticación cuando corresponda, registros suficientes y una ruta de apagado sencilla. La red interna de contenedores puede organizar dependencias, pero no reemplaza una política de quién puede hablar con quién.

Despliegues reversibles y mantenimiento repetible

La actualización más segura es la que se puede abandonar sin improvisar. Mantenga una definición declarativa del servicio, anote la versión utilizada, conserve una copia verificable de la configuración y defina qué datos se preservan. Antes de modificar nada, escriba el criterio de vuelta atrás: recuperar la definición anterior, restaurar el estado compatible y comprobar que el puerto y los procesos esperados vuelven a su situación conocida.

cambio propuesto
  ├─ configuración versionada
  ├─ datos persistentes identificados
  ├─ límites de recursos definidos
  ├─ exposición de red documentada
  └─ procedimiento de reversión escrito

No hace falta automatizar todo desde el primer día. Sí hace falta evitar que el único procedimiento válido dependa de recordar comandos o rutas locales. Un archivo de composición, una unidad de servicio o un documento de operación corto pueden ser suficientes si describen dependencias, almacenamiento, puertos y orden de recuperación.

Lista de control para el homelab

• Inventario: identifique proceso, puerto, rutas de datos y dependencias.
• Principio de mínimo acceso: retire montajes, permisos y puertos que no sean necesarios.
• Observabilidad: vigile consumo y errores con retención razonable.
• Capacidad: mantenga margen en disco y memoria para recuperaciones, no sólo para operación normal.
• Reversión: documente cómo volver a una definición anterior antes de aplicar el cambio.
• Rutina: revise periódicamente cachés, registros, copias y reglas de acceso.

Aislar servicios no persigue una perfección teórica. Persigue que el mantenimiento tenga consecuencias acotadas. Cuando recursos, datos y red poseen fronteras explícitas, una actualización de tooling como la publicada por ollama/ollama puede evaluarse como un cambio controlado dentro de un sistema que sigue siendo administrable.