Categoría: Desarrollo
GitLab self-hosted gestionado
Vuestro GitLab en vuestra infraestructura, actualizado sin sustos, con runners que no se atascan y copias que sabemos que se restauran porque lo comprobamos.
- Dónde se monta
- En vuestra cuenta, a vuestro nombre
- Copias
- Con restauración probada
- Actualizaciones
- Planificadas y documentadas
En resumen
Un GitLab self-hosted gestionado es una instancia de GitLab instalada en vuestra infraestructura de la que se responsabiliza un tercero. Nos encargamos de la instancia, los runners, el registry de contenedores, el almacenamiento de objetos, el inicio de sesión único, las copias con restauración probada, las actualizaciones de versión mayores y la monitorización. Vuestro equipo solo tiene que usarlo.
¿Qué nos encargamos de mantener?
Un GitLab autoalojado no es solo la web donde está el código. Es una base de datos, un almacenamiento de archivos, un registry de imágenes, unos runners que ejecutan cada pipeline y un buen puñado de secretos. Si una de esas piezas falla, el equipo deja de poder desplegar. Esto es lo que vigilamos y mantenemos:
Instancia
Servicios de GitLab, PostgreSQL, Redis y Gitaly, con su configuración en código.
Runners
Caché compartida, límites de recursos, etiquetas por tipo de trabajo y escalado automático.
Registry
Imágenes de contenedor con políticas de limpieza para que el disco no se llene.
Almacenamiento de objetos
Artefactos, paquetes, LFS y copias fuera del disco del servidor.
Inicio de sesión único
Acceso con vuestro proveedor de identidad y bajas que se aplican al momento.
Monitorización
Salud de la instancia, colas de trabajos, disco y certificados, con alertas.
¿Qué arquitectura recomendamos?
No hace falta la arquitectura de referencia para miles de usuarios si sois quince. Elegimos el método de instalación según el tamaño del equipo y lo que ya tengáis montado:
| Tamaño del equipo | Instalación | Runners | Almacenamiento |
|---|---|---|---|
| Hasta unas 50 personas | Omnibus en una máquina, con PostgreSQL y Redis incluidos | En una o dos máquinas aparte, con escalado si hay picos | Almacenamiento de objetos para artefactos, registry y copias |
| Equipos medianos | Omnibus con PostgreSQL gestionado del proveedor | Escalado automático en máquinas o en Kubernetes | Almacenamiento de objetos para todo lo que lo admite |
| Ya tenéis Kubernetes | Chart oficial de Helm, con base de datos y Redis fuera del clúster | Runner de Kubernetes con límites por espacio de nombres | Almacenamiento de objetos obligatorio |
En los tres casos, los runners van separados de la instancia: un pipeline que se come la memoria no debe tumbar el GitLab de todo el equipo.
¿Qué problemas encontramos más a menudo?
Cuando nos hacemos cargo de un GitLab que ya existe, casi siempre aparece alguno de estos:
- El disco se llena: artefactos y imágenes del registry que nadie limpia desde hace años.
- La copia no sirve: se copia la base de datos, pero no los secretos de la instancia, y sin ellos la restauración no arranca.
- Versión muy atrasada: tantas versiones por detrás que hay que encadenar varios saltos, uno detrás de otro.
- Runners compartidos sin límites: un trabajo pesado deja al resto del equipo esperando.
- Usuarios que ya no están: cuentas activas de personas que se fueron, porque no hay inicio de sesión único.
- Certificados caducados: el registry deja de aceptar imágenes un lunes por la mañana.
¿Cómo tratamos las copias y las actualizaciones?
La copia de GitLab tiene dos partes: los datos (repositorios, base de datos, archivos subidos) y los secretos de la instancia. Copiamos ambas, fuera del servidor, y cada mes restauramos la instancia en una máquina de prueba para comprobar que arranca y que los repositorios están completos. El tiempo que lleva queda en el informe.
Las versiones mayores de GitLab llegan una vez al año y cambian cosas. Las planificamos siguiendo la ruta de actualización oficial, con una copia antes de cada salto, una prueba previa si la instancia es grande y una ventana avisada. Las versiones de seguridad se aplican en cuanto salen.
¿En qué cuenta y con qué accesos?
En la vuestra. La máquina, el almacenamiento, la base de datos gestionada y la licencia, si la hay, están a nombre de vuestra empresa en vuestro proveedor: AWS, Google Cloud, Azure, Hetzner, OVH o un servidor propio. Entramos con un usuario nominal y permisos de administración solo donde hacen falta, y la configuración queda en vuestro repositorio, para que otra persona pueda seguir si un día terminamos.
Si buscáis montar algo más que GitLab, como la plataforma completa de despliegue, está en plataforma interna y PaaS. Si lo que queréis es que alguien responda de toda la plataforma cada mes, encaja con el SRE como servicio.
¿Dónde lo montamos?
En vuestra cuenta, en el proveedor que ya uséis o en el que mejor encaje. Si los datos tienen que quedarse en la UE, Hetzner y OVHcloud son las opciones europeas.
Proveedores en los que lo montamos
- Hetzner
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Servidor propio
| Proveedor | Cómo lo montamos | A tener en cuenta |
|---|---|---|
| Hetzner | Servidor cloud con Omnibus y PostgreSQL dentro de la propia instalación, porque Hetzner no ofrece base de datos gestionada. Object Storage de Hetzner, compatible con S3, para artefactos, registry y copias. | Los runners van en servidores aparte que se crean y se destruyen según la carga. |
| AWS | EC2 con Omnibus, RDS for PostgreSQL y S3. Si ya tenéis EKS, chart oficial de Helm con la base de datos en RDS. | Vigilamos la transferencia de salida: los registry con muchas descargas la disparan. |
| Google Cloud | Compute Engine con Omnibus, Cloud SQL para PostgreSQL y Cloud Storage. En GKE, chart de Helm. | Cloud SQL simplifica copias y parches de la base de datos. |
| Azure | Máquina virtual con Omnibus, Azure Database for PostgreSQL y Blob Storage, que GitLab admite como almacenamiento de objetos. En AKS, chart de Helm. | Encaja si el inicio de sesión ya va con Microsoft Entra ID. |
| DigitalOcean | Droplet con Omnibus, PostgreSQL gestionado de DigitalOcean y Spaces, compatible con S3. | |
| OVH | Instancia de Public Cloud con Omnibus, base de datos gestionada de OVHcloud para PostgreSQL y Object Storage compatible con S3. | |
| Servidor propio | Omnibus en vuestro servidor o en una máquina virtual de Proxmox, con PostgreSQL incluido. | La copia sale fuera del edificio, a un almacenamiento S3 en la nube. |
Qué incluye
- Instancia de GitLab CE o EE instalada con el método oficial adecuado a vuestro tamaño: Omnibus, contenedores o Helm.
- Runners con caché, límites y escalado automático, en máquinas o en Kubernetes.
- Registry de contenedores con limpieza automática de imágenes antiguas.
- Almacenamiento de objetos (S3 o compatible) para artefactos, paquetes, LFS y copias.
- Inicio de sesión único con vuestro proveedor de identidad (SAML u OpenID Connect).
- Copias diarias fuera del servidor, con secretos de la instancia incluidos, y restauración de prueba.
- Actualizaciones de versión mayores planificadas, siguiendo la ruta de actualización oficial.
- Monitorización de la instancia, los runners y el espacio en disco, con alertas.
Preguntas frecuentes
¿Qué edición de GitLab gestionáis?
Las dos: Community Edition, gratuita, y Enterprise Edition con o sin licencia. Si tenéis licencia de pago, sigue siendo vuestra y a vuestro nombre; nosotros solo la aplicamos en la instancia.
¿Cuánto tarda una actualización mayor?
Depende de cuántas versiones haya que saltar y del tamaño de la base de datos. Planificamos la ruta oficial de actualización, hacemos una copia antes de cada salto y os avisamos de la ventana. En instancias pequeñas suele ser cuestión de minutos de corte por salto.
¿Podemos migrar de GitLab.com a nuestro servidor, o al revés?
Sí. Se migran grupos, proyectos, incidencias y merge requests con las herramientas de migración de GitLab. Los runners y las variables de CI se revisan aparte, porque no siempre viajan solos.
¿Gestionáis también GitHub o Gitea?
Gitea sí, también autoalojado. Con GitHub no hay instancia que mantener, pero sí podemos ocuparnos de los runners propios y de los pipelines.
Contadnos vuestro caso
En una llamada gratuita de 20 minutos vemos dónde estáis y por dónde empezar. Sin compromiso.
Revisado el