VPS para GitLab

Un GitLab propio no es un solo servicio, sino todo un conjunto: la aplicación web en Puma, las tareas en segundo plano de Sidekiq, el almacenamiento de repositorios Gitaly, PostgreSQL, Redis, Nginx y, por defecto, también la monitorización con Prometheus. Todo se instala con un único paquete, pero pide memoria en consonancia. Por eso en la tabla de arriba solo hay planes desde 4 núcleos y 8 GB de memoria: con menos, GitLab arranca, pero trabajar con él es desagradable.

Qué dice la documentación oficial

Para una instalación en un solo servidor, GitLab indica como configuración de referencia 8 vCPU y 16 GB de memoria. El límite inferior para un servidor con poca memoria son 8 GB. Algunos puntos más de los requisitos:

• no se recomiendan los procesadores de rendimiento «acumulable» (burstable), en los que el núcleo solo se da a plena potencia durante poco tiempo: con carga, GitLab tira de CPU de forma constante;
• es mejor desactivar el swap o reducirlo al mínimo: cuando se usa de forma activa, el rendimiento cae en picado;
• los procesadores ARM están soportados;
• disco SSD, sin sistemas de archivos de red para los repositorios.

Hay también una guía aparte para servidores pequeños: desactivar Prometheus y los exportadores, pasar Puma al modo de un solo proceso y reducir los hilos de Sidekiq de 20 a 10. Así GitLab cabe en unos 2,5 GB de memoria y 1 GB de swap, pero es una opción para un servidor personal de una o dos personas, sin pipelines grandes y con retrasos notables en la interfaz. Para un equipo, toma 8 GB como mínimo y 16 GB de memoria como configuración normal.

Disco: en qué se va el espacio

La documentación prevé 40 GB para la propia aplicación, 5–10 GB para la base de datos PostgreSQL (para la edición Ultimate, desde 12 GB) y, para los repositorios, no menos de su volumen total. En la práctica, el espacio no se lo comen tanto el código fuente como:

• los artefactos de build y los registros de los trabajos de CI: fija un plazo de conservación de artefactos por defecto;
• el Container Registry: cada push de una imagen añade capas, y sin una política de limpieza el registro crece sin fin;
• Git LFS y el registro de paquetes;
• las copias de seguridad locales que crea gitlab-backup create.

Empieza con 80–100 GB en NVMe y vigila el crecimiento en la sección de uso de almacenamiento del área de administración. Saca las copias de seguridad del servidor desde el principio: se hace de forma estándar, a un almacenamiento compatible con S3, o a una máquina aparte; tienes planes adecuados en la página VPS para copias de seguridad. Guarda aparte /etc/gitlab/gitlab-secrets.json y gitlab.rb: no entran en la copia estándar, y sin el archivo de secretos el GitLab restaurado no podrá descifrar los tokens ni las variables de CI.

Runners: en una máquina aparte

Es mejor no instalar GitLab Runner en el mismo servidor que GitLab. El build, los tests y docker build ocupan fácilmente todos los núcleos y la memoria, y mientras tanto la interfaz y las operaciones de git empiezan a ir lentas para todo el equipo. Además, los trabajos de CI ejecutan código arbitrario de los repositorios, y tenerlos junto a la base de datos y los secretos de GitLab es un riesgo innecesario. El esquema habitual: un servidor principal con precio fijo y uno o varios runners con executor Docker, que se pueden crear y eliminar según haga falta. Cómo elegir esa máquina se explica en la página VPS para runners de CI/CD; el parámetro concurrent de la configuración del runner no debe superar el número de núcleos.

Dónde ubicar el servidor

Elige una ubicación cerca del equipo y de los runners: git push y clone de repositorios grandes, la subida de imágenes al Container Registry y la descarga de artefactos en cada pipeline son sensibles tanto a la latencia como al ancho de banda. Si los runners y GitLab están en el mismo centro de datos, y mejor aún en la misma red privada del proveedor, los builds reciben la caché y los artefactos más rápido y no consumen tráfico externo. Para código sujeto a requisitos de almacenamiento de datos en Rusia (la legislación rusa obliga a guardar ciertos datos dentro del país), el servidor debe estar en una ubicación rusa.

Instalación y mantenimiento

Lo más sencillo es instalar el paquete oficial para Ubuntu, Debian o AlmaLinux: incluye todos los componentes y se actualiza con el gestor de paquetes. La variante en Docker también está soportada, pero las actualizaciones y las copias de seguridad requieren más atención. Algunos puntos prácticos:

• SSH para git funciona por defecto en el puerto 22: mueve el SSH del sistema a otro puerto o configura uno aparte para GitLab;
• para los correos de merge requests y de restablecimiento de contraseña, conecta un SMTP externo;
• actualiza con regularidad y siguiendo la ruta oficial de actualización: no se pueden saltar varias versiones mayores de golpe, y las versiones intermedias obligatorias están indicadas en la documentación;
• antes de cada actualización, haz una instantánea del disco en el panel del proveedor.