Infraestructura durmiente: añadir la abstracción de runtime de contenedores antes de necesitarla

Hay un patrón en la ingeniería de software del que no se habla lo suficiente: construir infraestructura que no hace nada hoy pero que evita un refactoring doloroso más adelante. Acabamos de hacerlo en sh0, y la metodología detrás merece ser documentada.

El problema que todavía no tenemos

sh0 actualmente ejecuta todos los contenedores con el runtime por defecto de Docker: runc. Namespaces, cgroups, el aislamiento estándar de contenedores Linux. Esto funciona perfectamente para despliegues autoalojados donde confías en el código que despliegas.

Pero estamos construyendo hacia sh0 Cloud -- multi-tenant, donde desconocidos despliegan código en servidores compartidos. De repente runc no es suficiente:

• sh0 Debug permite a los usuarios ejecutar código arbitrario. Un exploit del kernel = acceso al host.
• sh0 Cloud significa que una evasión de contenedor = datos de otros clientes.

Las soluciones existen: gVisor (kernel en espacio de usuario, ~10-30 % de sobrecarga I/O) y Kata Containers (micro-VM, ~150 ms de penalización de arranque). Docker soporta ambos a través de un simple campo Runtime en su API.

La decisión: construir la abstracción ahora

Llegó una especificación sugiriendo implementar soporte completo de runtimes de contenedores -- verificaciones previas, flags CLI, interfaz de dashboard, detección de disponibilidad de runtimes. El tipo de especificación que una IA escribe cuando no conoce la base de código.

Lo redujimos a la abstracción mínima viable:

rust#[derive(Debug, Clone, Copy, PartialEq, Eq, Serialize, Deserialize, Default)]
#[serde(rename_all = "snake_case")]
pub enum ContainerRuntime {
    #[default]
    Runc,
    Gvisor,
    KataQemu,
    KataFirecracker,
}

Un enum, una columna de base de datos, un campo en la solicitud de la API Docker. Eso es todo. Sin verificaciones previas (nada que verificar -- solo runc está instalado). Sin flag CLI (la API es suficiente). Sin interfaz de dashboard (el administrador puede configurar vía API cuando llegue el momento).

Qué significa "durmiente" con precisión

Cada aplicación tiene como valor predeterminado Runc. El campo HostConfigRequest.runtime es Option<String> con skip_serializing_if = "Option::is_none". Para runc, es None -- el campo no aparece en absoluto en la solicitud de la API Docker. Docker usa su valor predeterminado. El comportamiento es byte por byte idéntico al anterior.

La única forma de activar esto es hacer PATCH /api/v1/apps/:id con {"container_runtime": "gvisor"}. En ese momento, Docker intentará usar runsc y fallará (porque no está instalado). Lo cual es el modo de fallo correcto -- Docker te dice que el runtime no existe.

La auditoría detectó algo

Seguimos una metodología construir-auditar-auditar-aprobar. El primer auditor (sesión Claude fresca, cero contexto de la sesión de construcción) encontró que 6 de los 8 caminos de despliegue tenían codificado container_runtime: None en lugar de leer la configuración de la aplicación:

• Despliegue de imagen Docker
• Despliegue de contenido Dockerfile
• Despliegue por upload
• Despliegue de rollback
• Escalado de réplicas
• Despliegue de entorno de vista previa

Solo los 2 caminos de despliegue Git (primario + réplica) usaban correctamente el runtime de la aplicación.

Impacto actual: cero -- todas las aplicaciones son runc, así que None y leer-desde-la-aplicación producen el mismo resultado. Pero si hubiéramos activado gVisor 6 meses después, 6 caminos de despliegue habrían ignorado silenciosamente la configuración. Los usuarios habrían configurado gvisor, desplegado por upload, y obtenido runc. El tipo de bug que es invisible hasta producción.

El auditor corrigió los 6 sitios. El segundo auditor confirmó las correcciones. Limpio.

El costo

• 20 archivos tocados -- mayormente mecánico (añadir container_runtime: Default::default() a los inicializadores de structs App, container_runtime: None a los sitios de llamada Sh0ContainerParams)
• 1 migración -- ALTER TABLE apps ADD COLUMN container_runtime TEXT NOT NULL DEFAULT 'runc'
• ~60 líneas de lógica real -- el enum, Display/FromStr, 2 patrones match en el pipeline de despliegue
• Tiempo de construcción: aproximadamente 2 horas incluyendo ambas rondas de auditoría
• Costo en tiempo de ejecución: cero (el campo no se serializa para runc)

Cómo luce la activación

Cuando instalemos gVisor en un servidor:

bash# En el servidor sh0
apt install runsc

# En la API sh0
PATCH /api/v1/apps/:id {"container_runtime": "gvisor"}

# El próximo despliegue usa runsc automáticamente

Sin cambios de código. Sin migraciones. Sin nuevas releases. La infraestructura ya está en su lugar.

El patrón

El marco de decisión es simple:

1. ¿Es la abstracción económica? (Sí -- un enum y una columna de base de datos)
2. ¿El punto de integración es claro? (Sí -- el campo Runtime de Docker en HostConfig)
3. ¿Cambia el comportamiento actual? (No -- None = predeterminado Docker = runc)
4. ¿Sería doloroso hacer la retrointegración? (Sí -- tocar cada camino de despliegue, migración, tipo API, handler)

Si las cuatro condiciones se cumplen: construir ahora, activar después. La metodología de auditoría atrapa los bugs de integración que de otro modo descubrirías 6 meses después en producción.