Servidor dedicado para Jenkins y GitLab CI/CD

¿Por qué usar un servidor dedicado para CI/CD?

Las cargas de trabajo de integración continua y entrega continua consumen muchos recursos porque una sola canalización puede compilar código fuente, crear imágenes de contenedor, ejecutar pruebas, analizar dependencias, empaquetar artefactos y desplegar servicios. Varias canalizaciones ejecutándose juntas pueden consumir todos los hilos de CPU, llenar el almacenamiento temporal y generar una alta E/S de disco.

Un servidor dedicado proporciona a Jenkins o GitLab Runner acceso exclusivo a núcleos físicos de CPU, RAM, almacenamiento NVMe y capacidad de red. Esto mejora la consistencia del tiempo de compilación e impide que un inquilino no relacionado afecte al rendimiento de compilación o pruebas. El bare metal es especialmente útil para canalizaciones con mucho Docker, compilaciones de Android, monorepositorios grandes, pruebas de navegador, paquetes de aprendizaje automático y proyectos que requieren virtualización privilegiada o módulos de kernel personalizados.

VPS frente a servidor dedicado para Jenkins y GitLab Runner

Cuándo basta un VPS

Un VPS funciona bien para un pequeño equipo de desarrollo con canalizaciones cortas y concurrencia limitada. Un VPS de 4 vCPU, 8 GB de RAM y 160 GB NVMe puede gestionar aproximadamente 1–4 trabajos activos cuando las compilaciones son moderadas y el runner no compila varios proyectos grandes simultáneamente.

• De uno a cuatro trabajos simultáneos.
• Proyectos pequeños de Node.js, Python, PHP, Go o Java.
• Pruebas unitarias ligeras y compilaciones de contenedores poco frecuentes.
• Almacenamiento de artefactos inferior a 100 GB.
• Compilaciones que no necesitan virtualización anidada, kernels personalizados ni uso sostenido de CPU en todos los núcleos.

Use runners separados o trabajadores con escalado automático si las credenciales de despliegue de producción, las solicitudes de extracción no confiables y los trabajos de lanzamiento confiables no deben compartir el mismo entorno.

Cuándo el hardware dedicado es la mejor opción

Migre a bare metal cuando las compilaciones saturen regularmente el VPS, el tiempo de cola sea mayor que el tiempo de ejecución o el rendimiento varíe entre ejecuciones. Un servidor dedicado también es preferible cuando el runner ejecuta código no confiable, crea imágenes de contenedor grandes, ejecuta bases de datos de pruebas de integración o procesa muchos trabajos con alta actividad de disco.

• Más de 4–6 trabajos simultáneos de forma habitual.
• Más de 20 minutos de compilación sostenida por trabajo.
• Grandes compilaciones de imágenes Docker u OCI que usan varios gigabytes de capas temporales.
• Compilaciones de Android, Chromium, Rust, C++, Unreal Engine u otras que consumen mucha CPU.
• Bases de datos persistentes de pruebas de integración, clústeres de Kubernetes o máquinas virtuales en el runner.
• Requisitos estrictos de aislamiento para código fuente, secretos o compilaciones de clientes.

Especificaciones recomendadas de servidor dedicado

CPU

Elija hardware reciente AMD EPYC o Intel Xeon de clase servidor con al menos 8 núcleos físicos para un host CI/CD de propósito general. Los núcleos físicos importan más que un alto número de hilos virtuales porque las compilaciones y suites de pruebas suelen ejecutar muchos procesos ligados a CPU a la vez. Un servidor de 16 núcleos es más apropiado para 20–40 trabajos simultáneos o para equipos que necesitan tiempos de cola cortos.

Priorice el rendimiento sostenido en todos los núcleos, una refrigeración suficiente y una asignación de CPU predecible por encima de las puntuaciones máximas de referencia de un solo hilo. Los ejecutores de Jenkins y la concurrencia de GitLab Runner deben basarse en la capacidad física, no simplemente en el número de hilos lógicos.

Memoria

Comience con 32 GB de RAM para un servidor de compilación de 8 núcleos. Asigne aproximadamente 2–4 GB por trabajo normal y luego añada capacidad para el sistema operativo, la caché de páginas de Docker, las bases de datos de pruebas y las cadenas de herramientas de lenguajes. Use 64 GB para 16 núcleos, compilaciones grandes de Java o Android, flotas de pruebas de navegador o varios contenedores por trabajo.

La presión de memoria provoca intercambio, lo que puede hacer que las compilaciones sean varias veces más lentas y puede terminar contenedores mediante el OOM killer de Linux. Supervise los máximos de uso de memoria antes de aumentar la concurrencia del runner.

Almacenamiento

Use almacenamiento NVMe empresarial en lugar de un disco mecánico o SSD SATA de gama baja. CI/CD crea muchos archivos pequeños, extrae dependencias, escribe archivos intermedios del compilador y crea capas de contenedor. Una unidad NVMe de 960 GB es un punto de partida práctico para extracciones de código fuente, imágenes Docker, espacios de trabajo y dependencias en caché.

Use 1,92 TB o más cuando las compilaciones conserven artefactos localmente, los repositorios contengan binarios grandes o las imágenes Docker se reconstruyan con frecuencia. Mantenga al menos el 20–30% del sistema de archivos libre. Para infraestructura de compilación importante, use almacenamiento duplicado como RAID 1 y almacene los artefactos finales en un registro independiente o sistema de almacenamiento de objetos.

Red y ancho de banda

Un puerto de 1 Gbps es adecuado para la mayoría de los equipos, siempre que el servidor incluya al menos 10 TB de transferencia mensual para descargas de dependencias, imágenes de contenedor, tráfico de repositorios y cargas de artefactos. Seleccione redes de 10 Gbps para artefactos binarios grandes, registros de contenedores de alto volumen o más de 25 trabajos simultáneos moviendo datos al mismo tiempo.

El ancho de banda no es lo mismo que la latencia. Un runner ubicado cerca del repositorio Git, el registro de paquetes, el registro de contenedores y los destinos de despliegue puede reducir la duración de la canalización incluso cuando la velocidad máxima de su puerto no cambia.

Elección rápida

¿Necesitas un servidor dedicado?

Bare metal con NVMe en más de 70 ubicaciones: configura y pide en minutos.

Ver servidores

Tabla de escala a especificación de CI/CD

Para hasta 4 trabajos simultáneos, basta un VPS de 4 vCPU; a partir de 10 trabajos, use un servidor dedicado de 8 núcleos y, para 20–40 trabajos, elija 16 núcleos físicos con 64 GB de RAM.

Configuración paso a paso

1. Instale un sistema operativo compatible

Use una versión actual de Ubuntu LTS o Debian con un conjunto mínimo de paquetes. Cree un usuario administrativo independiente, deshabilite el inicio de sesión directo de root y aplique actualizaciones antes de instalar Jenkins o GitLab Runner.

sudo apt update && sudo apt full-upgrade -y
sudo adduser cicd
sudo usermod -aG sudo cicd

2. Configure SSH y el firewall

Instale una clave SSH para la cuenta administrativa y luego deshabilite la autenticación por contraseña después de confirmar el acceso mediante clave. Permita únicamente los servicios necesarios. Jenkins suele usar TCP 8080 detrás de un proxy inverso, mientras que GitLab Runner normalmente necesita acceso saliente y ningún puerto público de entrada.

sudo apt install -y ufw fail2ban
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from YOUR_ADMIN_IP to any port 22 proto tcp
sudo ufw enable

3. Instale Docker para trabajos aislados

Docker hace que los entornos de compilación sean reproducibles, pero añadir un usuario al grupo Docker concede control equivalente a root. Use hosts de runner dedicados, trabajos confiables y agentes de corta duración al procesar código no confiable. Instale Docker desde el repositorio mantenido por el proveedor y verifique su servicio.

sudo apt install -y docker.io
sudo systemctl enable --now docker
sudo docker run --rm hello-world

4. Instale Jenkins o GitLab Runner

Instale un servicio de orquestación principal en el host o dedique nodos separados para el controlador y los trabajadores. Los controladores de Jenkins deben programar trabajo en lugar de ejecutar directamente compilaciones no confiables. GitLab Runner debe usar el ejecutor Docker u otro ejecutor aislado para trabajos repetibles.

sudo apt install -y openjdk-17-jre
sudo systemctl enable --now jenkins
sudo systemctl status jenkins

Para GitLab Runner, registre la máquina con un token de proyecto, grupo o instancia y seleccione el ejecutor Docker. Proteja los tokens de registro y use runners protegidos para canalizaciones de lanzamiento.

sudo apt install -y gitlab-runner
sudo gitlab-runner register
sudo systemctl enable --now gitlab-runner

5. Establezca la concurrencia deliberadamente

No establezca la concurrencia igual a todos los hilos lógicos de CPU. Comience con 6–8 trabajos en una máquina de 8 núcleos y 32 GB, y mida la espera de CPU, el uso de RAM, la espera de E/S y el tiempo de cola. Para un host de 16 núcleos y 64 GB, comience con 12–16 trabajos y aumente solo si las compilaciones siguen respondiendo bien.

sudoedit /etc/gitlab-runner/config.toml
sudo systemctl restart gitlab-runner

En Jenkins, configure el número de ejecutores en los ajustes del nodo y aplique etiquetas como docker, android o release para que los trabajos costosos lleguen a trabajadores adecuados.

6. Añada supervisión y rotación de registros

Instale node-exporter, Netdata, Prometheus u otro agente de supervisión. Controle la utilización de CPU, la carga promedio, la memoria disponible, la actividad de intercambio, la latencia de disco, la capacidad del sistema de archivos, la transferencia de red, los trabajos fallidos y el tiempo de cola. Configure la rotación de registros de journald y de la aplicación para que la salida de diagnóstico no pueda llenar el sistema de archivos raíz.

df -h
free -h
iostat -xz 1 5
uptime

7. Pruebe la recuperación antes del uso en producción

Realice copias de seguridad de la configuración de Jenkins, los metadatos de credenciales, las definiciones de trabajos y la configuración del runner sin exponer valores secretos. Pruebe restaurar el controlador, reconectar trabajadores, reconstruir un proyecto desde un espacio de trabajo limpio y recuperarse después de un disco lleno o un reemplazo de servidor.

Consejos de optimización del rendimiento

Almacene dependencias en caché de forma segura

Almacene en caché dependencias de Maven, Gradle, npm, pip, Go, Composer y Cargo cuando corresponda. Use archivos de bloqueo y claves de caché basadas en el sistema operativo, la arquitectura y la suma de verificación de dependencias. Una caché obsoleta o compartida puede producir compilaciones incorrectas, así que proporcione una ruta para purgar manualmente la caché.

Use espacios de trabajo limpios y desechables

La reutilización de espacios de trabajo ahorra tiempo de descarga, pero puede dejar archivos generados que afecten a trabajos posteriores. Prefiera contenedores efímeros o modos de extracción limpia para canalizaciones de lanzamiento y sensibles a la seguridad. Elimine espacios de trabajo abandonados y capas Docker antiguas mediante una política programada en lugar de borrar datos de compilación activos.

docker system df
sudo docker image prune --filter "until=168h"

Separe las clases de compilación

Use etiquetas y tags de runner para separar compilación intensiva de CPU, pruebas de navegador, trabajos de despliegue y linting de bajo consumo. Esto evita que una gran compilación de C++ deje sin recursos a un trabajo de lanzamiento. Si distintos equipos tienen requisitos de seguridad en conflicto, use trabajadores dedicados separados en lugar de depender solo de etiquetas.

Reduzca el tráfico innecesario de artefactos

Comprima artefactos grandes, cargue únicamente archivos requeridos por etapas posteriores y establezca períodos de retención. Almacene imágenes de contenedor en un registro y salidas de compilación a largo plazo en almacenamiento de objetos en lugar de conservar cada artefacto en el disco NVMe local del runner.

Optimice las compilaciones de contenedores

Use Dockerfiles de varias etapas, fije las versiones de imágenes base, ordene las capas de dependencias estables antes de las capas de código fuente que cambian con frecuencia y habilite BuildKit cuando sea compatible. Mantenga los contextos de compilación pequeños con un archivo .dockerignore preciso. La caché local es rápida, pero las cachés remotas compartidas son más fáciles de reproducir entre varios trabajadores.

Elección rápida

¿Necesitas un servidor dedicado?

Bare metal con NVMe en más de 70 ubicaciones: configura y pide en minutos.

Ver servidores

Errores comunes que se deben evitar

• Ejecutar todo en el controlador: Los controladores de Jenkins no deben ejecutar código arbitrario de solicitudes de extracción. Use agentes con permisos restringidos.
• Comprometer en exceso la concurrencia: Cuarenta trabajos en 8 núcleos físicos pueden aumentar el tiempo de cola y el tiempo total de finalización. Mida el rendimiento en lugar de perseguir un alto número de ejecutores.
• Usar el socket Docker de root para código no confiable: El acceso al socket puede proporcionar control a nivel de host. Use trabajadores aislados, alternativas sin root cuando sea práctico o máquinas desechables.
• Ignorar la capacidad de disco: Las capas Docker, cachés de paquetes, bases de datos de pruebas y espacios de trabajo pueden llenar rápidamente un disco de 160 GB. Genere alertas al 70% de uso y actúe antes del 85%.
• Mantener secretos en registros de trabajos: Oculte las credenciales, restrinja las canalizaciones de solicitudes de extracción, rote los tokens expuestos y evite que los comandos detallados impriman variables de entorno.
• Depender de un servidor sin copias de seguridad: Un host dedicado no es una copia de seguridad. Mantenga la configuración y los artefactos en almacenamiento externo recuperable y pruebe la restauración.
• Omitir la gestión de parches: Programe actualizaciones del sistema operativo, Jenkins, runner, Docker y dependencias. Pruebe las actualizaciones en un trabajador de ensayo antes de modificar el único runner de producción.
• Mezclar compilaciones confiables y no confiables: Las solicitudes de extracción basadas en forks pueden ejecutar definiciones de canalización modificadas. Use etiquetas, permisos, credenciales y, preferiblemente, hosts de trabajadores separados.

Elegir la arquitectura adecuada

Un equipo pequeño puede ejecutar Jenkins o GitLab Runner en un VPS de 4 vCPU con 8 GB de RAM cuando los trabajos son poco frecuentes y las compilaciones ligeras. Un servidor dedicado de 8 núcleos es el punto medio práctico para compilaciones diarias de contenedores, 5–12 trabajos simultáneos y rendimiento predecible. Los equipos con compilaciones móviles, monorepositorios grandes, granjas de navegadores o más de 20 trabajos simultáneos deben usar un host dedicado de 16 núcleos o mayor, potencialmente dividido en trabajadores especializados.

Para el aislamiento más sólido, mantenga el controlador de orquestación separado de los trabajadores de compilación y aprovisione agentes desechables para código no confiable. Esta arquitectura cuesta más que un solo servidor, pero limita la exposición de credenciales y facilita el escalado de capacidad. Comience con datos medidos de las canalizaciones —duración promedio, concurrencia máxima, tiempo de CPU, máximo uso de RAM, tamaño de artefactos y tiempo de cola— y luego ajuste el hardware según la evidencia.