.png)
Hola, soy Maneshwar. Estoy construyendo LiveReview, una herramienta privada de revisión de código con IA que se ejecuta con tu propia clave de LLM como OpenAI o Gemini y con precios muy competitivos para equipos pequeños. Si te interesa, pruébala. Y ahora, vamos al tema.
Nuestra instancia de GitLab estaba en una VM fuera de GCP y aunque funcionaba, se sentía lenta.
Colocándola detrás de Google Cloud CDN con un balanceador HTTPS global, redujimos los tiempos de carga de página en alrededor del 50 por ciento, gracias a caché en el borde, compresión y la red de Google. Lo mejor es que no tocamos la configuración HTTPS de GitLab ni nada crítico del servidor de origen.
En esta guía te muestro cómo lo hicimos, por qué cada paso importa y las trampas que evitamos como bucles DNS y errores al elegir el tipo de backend.
Resultados de alto nivel TLDR: delante de la VM externa de GitLab pusimos un balanceador global externo HTTPS con Cloud CDN. El balanceador termina el TLS del cliente con un certificado administrado por Google y luego reenvía al origen por HTTPS. Para hacerlo seguro y sin bucles, creamos un nombre DNS auxiliar que apunta a la IP del origen, creamos un Internet NEG que referencia ese origen 443, montamos un servicio backend HTTPS con Cloud CDN activado, creamos el balanceador con reglas de host y path hacia ese backend, añadimos el frontend HTTPS con el certificado para gitlab.apps.dev.to y finalmente apuntamos el registro DNS público de gitlab.apps.dev.to a la IP del balanceador.
Arquitectura en breve: Origen una VM en 111.0.113.50 con GitLab Omnibus y su propio HTTPS. DNS bajo *.apps.dev.to en Cloud DNS. CDN y SSL gestionados por el balanceador global de Google con Cloud CDN activado.
Paso 0 Prechequeo por qué no es un balanceador cualquiera. Objetivo poner Cloud CDN delante de una VM remota sin cambiar el HTTPS de GitLab. Cloud CDN vive en el borde del balanceador, y para llegar a un origen fuera de GCP necesitas un Internet NEG que apunte a una IP o FQDN externo. Si apuntas el NEG al mismo hostname que vas a publicar en el LB, cuando muevas ese hostname al LB crearás un bucle. Así que planifica y prueba con cuidado.
Paso 1 DNS auxiliar crea un nombre de ayuda para el origen. Creamos un A en Cloud DNS gl.apps.dev.to con la IP 00.105.05.200 de la VM. El NEG usará gl.apps.dev.to para alcanzar al origen sin riesgo de que resuelva la IP del LB cuando cambiemos el hostname público gitlab.apps.dev.to. Elige un nombre claramente interno para evitar que se use en público por error.
Paso 2 Crea un Internet NEG. Creamos gitlab-ovh-neg-https con un endpoint 00.105.05.200:443. Un NEG de Internet permite al balanceador global hablar con IPs o FQDN externos. Errores comunes apuntar el NEG al mismo hostname público creando bucle o intentar usar backend bucket o instance group cuando tu origen es una VM externa.
Paso 3 Crea el servicio backend y adjunta el NEG. Creamos gitlab-ovh-backend-service con protocolo HTTPS, adjuntamos el NEG y habilitamos Cloud CDN. Desactivamos la verificación TLS del backend para aceptar el certificado del origen aunque sea autofirmado. Decisiones clave Protocolo HTTPS porque GitLab sirve HTTPS. Cloud CDN activado con modo de caché de contenido estático respetando Cache-Control. Verificación TLS del backend desactivada de inicio para evitar fallos con certificados no confiables.
Paso 4 Crea el balanceador global externo HTTPS. Esto es lo que verán los clientes con IP global y frontend HTTPS. Creamos gitlab-cdn-1, añadimos un frontend inicial HTTP en 33.149.6.84:80 para redirecciones y luego el frontend HTTPS 443 con certificado. En el mapa de URL configuramos que gitlab.apps.dev.to rote hacia gitlab-ovh-backend-service.
Paso 4a Frontend HTTPS. Queremos que https://gitlab.apps.dev.to presente un certificado gestionado por Google. El LB termina TLS, ofrece HTTP2 o QUIC y reenvía al backend. Ejemplo Nombre git-frontend-lb, Protocolo HTTPS con HTTP2, IP global reservada, Puerto 443, Certificado gestionado, Política SSL por defecto, Redirección de HTTP a HTTPS opcional.
Paso 4b Enlace con backend. Selecciona el servicio backend creado y adjúntalo al mapa de URL.
Paso 4c Reglas de enrutamiento. Unificamos todo el tráfico de gitlab.apps.dev.to hacia el servicio con NEG. Si lo necesitas, puedes enrutar paths a backends distintos, por ejemplo assets estáticos a un bucket y dinámico a la VM.
Paso 5 Certificados y frontend HTTPS. Se adjunta un certificado administrado para gitlab.apps.dev.to en el frontend del LB. El LB maneja el TLS del cliente y mantiene cifrado extremo a extremo cuando reenvía a https origen 443, cumpliendo con no tocar el SSL interno de GitLab.
Paso 6 Cambios DNS finales. Actualizamos el A de gitlab.apps.dev.to a la IP pública del LB 33.149.6.84. Mantenemos gl.apps.dev.to apuntando a 00.105.05.200 para que el NEG siempre resuelva la IP real del origen y no la del LB.
Checklist de pruebas. Ejecuta curl -I https://gitlab.apps.dev.to y verifica encabezados como Via 1.1 google o indicadores de Cloud CDN. Prueba git ls-remote https://gitlab.apps.dev.to con operaciones Git sobre HTTPS. Si algo falla, vuelve a apuntar el A de gitlab.apps.dev.to a la IP del origen para recuperar servicio inmediato.
Paso 7 Configuración de caché y CDN. Modo de caché Cachear contenido estático respetando Cache-Control del origen, ideal para CSS JS e imágenes con fingerprinting. TTL cliente 1 hora, TTL por defecto 1 hora, TTL máximo 1 día. Compresión automática. Serve while stale desactivado. Contenido restringido público sin URLs firmadas. Caché negativa desactivada. Razonamiento GitLab sirve contenido dinámico y privado, no fuerces cachear todo para evitar servir páginas privadas o obsoletas. Fingerprinting de assets permite equilibrio entre frescura y rendimiento.
Paso 8 Estrategia de invalidación. Cloud CDN permite invalidar por host y path o por etiquetas de caché. GitLab no emite etiquetas por defecto, así que invalidamos por rutas. Ejemplos tras actualizar assets, invalida host gitlab.apps.dev.to y path /assets/*; si avatares no se actualizan, invalida /uploads/* o la ruta específica; último recurso /*. CLI ejemplo gcloud compute url-maps invalidate-cdn-cache gitlab-url-map --path /assets/* --host gitlab.apps.dev.to
Paso 9 Health checks, monitorización y logging. Crea un health check HTTPS a 443 contra una ruta como users/sign_in y así el LB marca el backend saludable. Activa registros de backend y de LB para entender aciertos de caché, fallos y latencias.
Paso 10 Resolución de problemas y plan de rollback. Si tras el cambio de DNS algo falla, edita el A de gitlab.apps.dev.to de vuelta a 00.105.05.200 para restaurar servicio directo. Revisa logs del LB y backend. Culpables típicos NEG mal apuntado al LB creando bucle, protocolo de backend incorrecto HTTP en lugar de HTTPS o verificación TLS activada con certificado autofirmado. Corrige apuntando al origen real, ajustando protocolo o desactivando la verificación o instalando un certificado confiable.
Notas finales y opciones avanzadas. Limpieza futura opcional terminar TLS en el LB y servir HTTP en el origen para reducir doble cifrado, aunque requiere tocar GitLab. Añade protección tipo WAF con Cloud Armor para reforzar ciberseguridad. A largo plazo, usa certificados válidos en el origen y enciende la verificación TLS en el backend para máxima seguridad. Activa métricas y logging para ratio de aciertos de caché, latencia de backend y errores 5xx.
Checklist ordenado para copiar. 1 Crea A gl.apps.dev.to a 00.105.05.200 con TTL corto. 2 Crea Internet NEG gitlab-ovh-neg-https hacia 00.105.05.200:443. 3 Crea backend gitlab-ovh-backend-service protocolo HTTPS, adjunta NEG, activa Cloud CDN y desactiva verificación TLS del backend inicialmente. 4 Crea balanceador global gitlab-cdn-1 con mapa de URL para host gitlab.apps.dev.to hacia el backend y frontend HTTPS con certificado gestionado y redirección opcional. 5 Cambia Cloud DNS gitlab.apps.dev.to a la IP del LB y conserva gl.apps.dev.to al origen. 6 Configura health check HTTPS a users/sign_in. 7 Prueba con curl -I y git ls-remote. 8 Invalida caché si es necesario con /assets/* y otras rutas. 9 Activa logging y monitoriza.
Conclusión. Poner un GitLab externo detrás de Google Cloud CDN es como construir una estación avanzada en la autopista que acelera el tráfico, protege la ruta y reduce carga en el origen. Con un poco de cuidado al crear el NEG, el backend y el certificado, obtienes velocidad global, menos latencia y una experiencia más fluida al clonar, hacer push y navegar repos.
En Q2BSTUDIO somos una empresa de desarrollo de software y aplicaciones a medida, especialistas en inteligencia artificial e IA para empresas, ciberseguridad, agentes IA, servicios cloud aws y azure, servicios de inteligencia de negocio y power bi, y mucho más. Si quieres diseñar una arquitectura robusta con CDN, balanceadores globales y automatización de despliegue, podemos ayudarte a definir, migrar y operar la plataforma. Descubre cómo optimizamos tu infraestructura y costes en nuestro servicio de servicios cloud aws y azure.
