Aprovisionamiento

Lo que el motor instala en el paso Infraestructura.

El paso Infraestructura es donde se monta todo en el host. El motor instala, en secuencia, con progreso transmitido en vivo:

• k3s — Kubernetes ligero y production-grade (escala a multi-node más adelante).
• Ingress (Traefik) + cert-manager — enrutamiento y TLS automático vía Let's Encrypt.
• PostgreSQL y Redis in-cluster — la base de datos definitiva y la cola/pub-sub de logs.
• Registry de artefactos y los Runners de CI.
• Runtime serverless de Deploy.
• Las imágenes definitivas de api y web (despliegue + migraciones + seed del super admin como Jobs in-cluster).

Runners de CI#

Los jobs de pipeline corren como pods aislados en el clúster — un pod por job, con sus propios límites de CPU/memoria, de modo que un job pesado nunca deja sin recursos a la plataforma ni a sus vecinos. La capacidad se deriva del propio clúster (reservando siempre margen para el control plane): los jobs que exceden el techo esperan en la cola, y añadir un nodo a la fleet aumenta la capacidad de CI automáticamente.

Cada contenedor del pod de un job está acotado — el propio job, sus sidecars de services: y el daemon Docker por job llevan techos explícitos, y cada volumen de scratch tiene un tope de tamaño, de modo que un job desbocado se desaloja a sí mismo en lugar de presionar al nodo. El timeout-minutes del job también queda estampado en el pod: aunque el proceso de la plataforma muera a mitad del job, el clúster retira el pod por su cuenta.

Ajustar la capacidad#

El cálculo es un buen valor por defecto, no una sentencia: en Configuración → Plataforma → Capacidad de CI decides cuánto de la máquina puede tomar el runner, y cada cambio muestra lo que rendiría en este clúster antes de guardarlo.

Dos mandos importan más. La reserva de la plataforma es la porción de cada nodo que CI nunca toca: bajarla da más a CI en total, aunque entonces caben más plazas repartiendo la memoria y cada job puede quedar más pequeño. Y el «no iniciar por debajo de» es un suelo de admisión: el techo de un job queda congelado al crearse su pod, así que una bajada pasajera de memoria libre puede darle a un build de dos horas un límite con el que no termina. Por debajo del suelo el nodo no ofrece plazas y el job espera en la cola: tarde es mejor que lisiado.

La reserva tiene además un suelo absoluto: al menos 2 núcleos y 3 GiB se quedan con el control plane, diga lo que diga el porcentaje (en hosts diminutos el suelo se encoge por sí solo). Un nodo dedicado a runners, sin plataforma encima, puede poner ese suelo a cero vía EQS_RUNNER_MIN_PLATFORM_RESERVE_CPU / EQS_RUNNER_MIN_PLATFORM_RESERVE_MEMORY_GI.

Logs y retención#

Un solo step puede almacenar hasta 50.000 líneas de log (EQS_RUNNER_MAX_LOG_LINES_PER_STEP; 0 elimina el tope). Superado el tope, el step sigue ejecutándose hasta su conclusión real: se escribe un marcador de truncado bien visible y el resto de la salida se descarta, lo que protege la base de datos y el stream en vivo de un set -x desbocado.

Los logs de step caducan a los 90 días (EQS_CI_LOG_RETENTION_DAYS; 0 los conserva para siempre). Las ejecuciones, los jobs, las conclusiones y las anotaciones se mantienen — el historial sigue siendo navegable, solo expira la transcripción en bruto. El recolector de basura de blobs del registry y el ejecutor de retención también vienen activados por defecto (cada EQS_REGISTRY_*_ENABLED=false los desactiva): los blobs sin referencias se recuperan solos, y una política de retención guardada en la pantalla de Artefactos simplemente se ejecuta.

La porción de la propia plataforma#

La plataforma dimensiona sus propios pods a partir del host: base de datos, api y web declaran resource requests derivadas en la instalación (y rellenadas a posteriori por las actualizaciones), de modo que bajo carga el kernel arbitra a favor de la plataforma en lugar de tratar a un job de CI y a la base de datos como iguales. Se puede sobrescribir por componente con variables del estilo EQS_PG_CPU_REQUEST cuando conoces tu máquina mejor que la fórmula.