Servidores dedicados para GitLab™
GitLab autogestionado y ejecutores de CI/CD en metal desnudo
Ejecute GitLab Self-Managed en un servidor dedicado con almacenamiento NVMe y traslade los trabajos de CI/CD a servidores runner independientes conectados a través de una VLAN privada. Los mismos servidores runner funcionan para GitLab Runner y para runners autohospedados de GitHub Actions.
GITLAB es una marca comercial de GitLab Inc. en Estados Unidos y otros países y regiones.
-
Almacenamiento NVMe para repositorios -
CPU de alta frecuencia para CI -
VLAN privada a 10–25 Gbit/s -
Acceso root y IP-KVM
AMD Zen 5 hasta 5.7 GHz
Tráfico ilimitado
Unidades NVMe empresariales
Memoria DDR5 ECC
Requisitos de hardware de GitLab y GitLab Runner
La base para una instancia de GitLab de un solo nodo es de 8 vCPU y 16 GB de memoria: una CPU de 4–6 núcleos con 8–12 hilos en un servidor dedicado. El uso de swap bajo carga ralentiza GitLab, por lo que 32 GB dejan margen para trabajos en segundo plano y crecimiento.
Planifique 40 GB para el sistema y PostgreSQL, además del tamaño total de todos los repositorios. Gitaly, el servicio de repositorios, es intensivo en E/S y necesita almacenamiento SSD en lugar de sistemas de archivos de red, por lo que dos unidades NVMe en RAID 1 son la configuración estándar.
Las instancias y los discos en la nube con rendimiento variable no son una buena opción para GitLab: su velocidad disminuye una vez que se agota una cuota de uso. Un servidor dedicado no tiene cuotas ni vecinos en el mismo hardware, por lo que sus núcleos y unidades NVMe nunca son limitados por un proveedor.
Los trabajos de CI/CD se ejecutan mejor en un servidor separado en lugar de en la instancia de GitLab. Así, una compilación pesada no puede ralentizar Git, la interfaz web ni las revisiones de código, y el código de la canalización nunca se ejecuta junto a tus repositorios.
Los compiladores, las pruebas y las compilaciones de imágenes dependen de la velocidad de un solo núcleo, por lo que una alta frecuencia de reloj acorta cada tarea, y los núcleos determinan cuántas tareas se ejecutan en paralelo. Cada tarea necesita su propia memoria, y las capas y cachés de Docker residen en el NVMe del runner.
Los runners obtienen código, imágenes y artefactos de la instancia a través de una VLAN privada a hasta 25 Gbit/s: una imagen completa de Docker llega en segundos, no en minutos. El puerto público queda libre para tu equipo: los push de Git, las solicitudes de fusión y la interfaz web nunca esperan detrás de una canalización.
Precios de servidores dedicados para GitLab y runners
Ver todas las configuraciones
Alquile un servidor dedicado para GitLab
de INTROSERV
Cómo pedir un servidor dedicado
Seleccione una configuración, añada unidades NVMe, elija el sistema operativo, espere hasta que el servidor esté listo e instale GitLab.
Lee la documentación
Instalar y asegurar una instancia de GitLab de un solo nodo
Instalación paso a paso de GitLab Self-Managed desde el paquete oficial de Linux, con HTTPS y el primer inicio de sesión.
Lee el tutorialServidores e infraestructura para GitLab de un único proveedor
-
1
Instala GitLab en el servidor de la instancia
Instale GitLab Self-Managed desde el paquete oficial para Linux en almacenamiento NVMe, con PostgreSQL y Redis incluidos. Luego configure HTTPS, el correo saliente y el registro de contenedores.
-
2
Conectar servidores runner a través de la VLAN
Ordena servidores runner en el mismo centro de datos y únelos a una VLAN privada a velocidades de hasta 25 Gbit/s. Los trabajos extraen código, imágenes y artefactos a través de la VLAN, no del puerto público.
-
3
Registrar a los corredores
Instala GitLab Runner con el ejecutor de Docker y regístralo en tu instancia. Para los repositorios en GitHub, los mismos servidores ejecutan runners autohospedados de GitHub Actions.
-
4
Haz una copia de seguridad con INTROSERV Backup
Haga una copia de seguridad de toda la instancia del servidor con el Servicio de Copia de Seguridad de INTROSERV: software NAKIVO y almacenamiento en un solo servicio listo para usar. Restaure todo el servidor o un solo archivo cuando sea necesario.
Licencias y soporte de GitLab
Licencia
GitLab Enterprise Edition es la instalación recomendada: sin una licencia funciona en el plan gratuito, y Premium o Ultimate se desbloquean más tarde con un código de activación, sin necesidad de reinstalar. Community Edition es la alternativa de código abierto bajo la licencia MIT, con las mismas funciones gratuitas. Las suscripciones se venden por GitLab Inc. o sus socios, no por INTROSERV.
Soporte
El soporte para GitLab en sí proviene del foro y la documentación de GitLab, o de GitLab Inc. con una suscripción de pago. INTROSERV se encarga de los servidores Linux en los que se ejecuta GitLab: supervisión, seguridad, actualizaciones del sistema operativo y correcciones de incidencias con un plan de gestión de servidores, y tareas puntuales como administración de sistemas por horas.
FAQ
-
¿Qué tan rápido se entrega el servidor?
Las configuraciones instantáneas están listas dentro de 3 a 6 horas después del pago; las configuraciones personalizadas suelen tardar hasta 24 horas. El plazo de entrega se muestra en cada configuración del catálogo.
-
¿Se puede probar primero el servidor?
Sí. Hay disponible un período de prueba de pago de hasta 5 días, suficiente para instalar GitLab, enviar un repositorio y ejecutar la primera canalización.
-
¿Qué sistema operativo debería elegir?
Una distribución Linux compatible con el paquete oficial de GitLab, como Ubuntu LTS o Debian. El paquete incluye PostgreSQL, Redis y el servidor web, por lo que el sistema no necesita nada más instalado.
-
¿Puedo usar mi propio dominio y certificado HTTPS?
Sí. Apunta un registro DNS al servidor, y el paquete de GitLab puede solicitar y renovar por sí solo un certificado de Let's Encrypt. En su lugar, también se puede instalar un certificado de otra autoridad.
-
¿Puede GitLab Pages ejecutarse en el mismo servidor?
Sí. Pages se ejecuta como un servicio independiente y necesita un registro DNS comodín. Los dominios personalizados para Pages también necesitan una segunda dirección IP, que se puede añadir al servidor.
-
¿Qué sucede cuando falla una unidad NVMe?
Con dos unidades en RAID 1, GitLab sigue funcionando en la unidad restante. Usted abre un ticket de soporte, INTROSERV reemplaza la unidad en el centro de datos y el arreglo se reconstruye.
-
¿Se pueden agregar más servidores runner más adelante?
Sí. Pida otro servidor runner en el mismo centro de datos, agréguelo a la VLAN existente y regístrelo en su instancia. Los pipelines empezarán a usarlo en cuanto esté en línea.
-
¿Se puede ampliar el almacenamiento más adelante?
En las configuraciones DC1, DC2 y DC3, sí: las unidades para las ranuras libres se añaden mediante un ticket de soporte, y el precio mensual cambia en consecuencia. Para otras configuraciones, es mejor elegir el diseño de unidades con algo de margen al hacer el pedido.
