.png)
Hola, soy Maneshwar. Estoy construyendo LiveReview, una herramienta privada de revisión de código con IA que funciona usando tu propia clave de LLM como OpenAI o Gemini, con precios muy competitivos y pensada para equipos pequeños. Échale un vistazo y pruébala.
Nuestro GitLab se ejecutaba en una VM fuera de GCP como OVH o AWS y, aunque funcionaba, se sentía lento.
Poniéndolo detrás de Google Cloud CDN con un balanceador de carga HTTPS global, reducimos los tiempos de carga de páginas aproximadamente un 50 por ciento gracias al caché, a la compresión y a la red de borde de Google. Y lo mejor es que no tuvimos que tocar la configuración HTTPS existente de GitLab ni nada más en el servidor de origen.
Esta guía te muestra exactamente cómo lo conseguimos, por qué cada paso es necesario y los errores sutiles que evitamos en el camino como bucles DNS, elección incorrecta de backend y similares.
Antes GitLab lento y después 50 por ciento más rápido, los gráficos comparativos se omitieron en esta versión sin imágenes.
Resumen rápido
Pusimos un Global External HTTPS Load Balancer de Google Cloud con Cloud CDN delante de la VM externa de GitLab. El balanceador termina el TLS del cliente con un certificado gestionado por Google y luego proxifica el tráfico al origen por HTTPS. Para hacerlo de forma segura primero creamos un nombre DNS auxiliar que apunta a la IP del origen para que el NEG no resuelva la IP del balanceador y evitar bucles, después creamos un Internet NEG que apunta a ese origen en el puerto 443, luego un servicio de backend HTTPS con Cloud CDN activado, y por último construimos el balanceador global y configuramos las reglas de host y ruta. Añadimos un frontend HTTPS con certificado de Google para gitlab.apps.dev.to y actualizamos el DNS para que gitlab.apps.dev.to apunte a la IP pública del balanceador.
Toda la caché e invalidación se configura en el servicio de backend Cloud CDN y en el mapa de URL del balanceador.
Visión de arquitectura
Origen una VM en la IP 111.0.113.50 ejecutando GitLab Omnibus y gestionando su propio HTTPS. DNS el subdominio comodín apps.dev.to gestionado en Cloud DNS. CDN y SSL con el balanceador de Google Cloud con Cloud CDN activado.
Paso 0 Preparación por qué esto no es solo otro balanceador
Objetivo poner Cloud CDN el caché global de borde delante de una VM remota sin cambiar el HTTPS de GitLab en la VM. Cloud CDN se sienta en el borde de Google, en el balanceador. Para que el balanceador envíe tráfico a un origen fuera de GCP debes usar un Internet NEG o un backend que apunte a esa IP o FQDN externo. Si apuntas a un bucket de GCS o si por error configuras el NEG con el mismo hostname que estará publicado en el balanceador, crearás un bucle DNS o de enrutamiento. Planifica y prueba con cuidado.
Paso 1 DNS de apoyo crear un nombre de origen auxiliar
Crearmos un registro A auxiliar en Cloud DNS como gl.apps.dev.to que apunta a 00.105.05.200 que es la IP de la VM de origen. El NEG necesita saber llegar al origen. Si le das al NEG el mismo hostname que después apuntará al balanceador, cuando cambies ese hostname al IP del balanceador el NEG empezará a apuntar al propio balanceador provocando un bucle. El registro auxiliar apunta directamente al origen y solo se usa en la configuración interna del balanceador. El nombre público gitlab.apps.dev.to más tarde apuntará a la IP del balanceador. Consejo elige un nombre auxiliar que deje claro que es solo para origen para que nadie lo use públicamente por accidente.
Paso 2 Crear un Internet NEG Network Endpoint Group
Crearmos gitlab-ovh-neg-https, un Internet NEG que incluye un único endpoint 00.105.05.200 en el puerto 443. Un NEG es el conjunto de endpoints a los que el balanceador puede enviar tráfico. Para orígenes externos usa un Internet NEG, que permite al balanceador global apuntar a IPs o FQDNs externos. Es el puente entre el frontend global de Google y tu origen remoto.
Errores comunes crear un NEG que apunta al mismo hostname público lo que causa bucle o intentar usar un backend bucket o un instance group para una VM externa, que no es válido.
Paso 3 Crear el servicio de backend y adjuntar el NEG
Crearmos gitlab-ovh-backend-service con protocolo HTTPS y adjuntamos el NEG gitlab-ovh-neg-https. Activamos Cloud CDN en este backend y dejamos desactivada la verificación TLS del backend para aceptar el certificado existente del origen incluso si es autofirmado.
El servicio de backend es el destino lógico del balanceador define protocolo, tiempos de espera, política de balanceo y si Cloud CDN cachea la respuesta. Activar Cloud CDN aquí es el interruptor que indica que se cacheen respuestas estáticas en el borde de Google. Desactivar la validación del certificado del backend es práctico si el origen usa un certificado interno o autofirmado y evita tener que reemitir certificados durante la migración.
Decisiones clave Protocolo HTTPS porque GitLab Omnibus sirve HTTPS y no lo tocamos. Cloud CDN activado con modo Caché de contenido estático recomendado para apps como GitLab. Verificación TLS de backend desactivada inicialmente para evitar fallos por certificados autofirmados.
Paso 4 Crear el Global External HTTPS Load Balancer
Este es el punto de acceso de los clientes una IP global con un frontend HTTPS y reglas de enrutamiento hacia el backend. Creamos gitlab-cdn-1 un Application Load Balancer global, inicialmente con frontend en 33.149.6.84 puerto 80 para redirección y después añadimos HTTPS en el 443 con el certificado. Las reglas de enrutamiento envían gitlab.apps.dev.to al backend gitlab-ovh-backend-service.
Paso 4a Configuración del frontend HTTPS
El frontend es la forma en que los clientes se conectan. Queremos que https://gitlab.apps.dev.to presente un certificado gestionado por Google para que los clientes no vean el certificado del origen. El balanceador termina TLS, ofrece HTTP2 o QUIC y luego reenvía las solicitudes al backend.
Ejemplo de parámetros Nombre git-frontend-lb. Protocolo HTTPS con HTTP2. IP gl-https-frontend reservada global. Puerto 443. Certificado gitlab-frontend-loadbalancer-created-certificate. Política SSL predeterminada de GCP. Redirección HTTP a HTTPS opcional nosotros la usamos.
Paso 4b Vinculación del backend
Selecciona el servicio de backend creado anteriormente como gitlab-dev-backend-service y adjúntalo.
Paso 4c Reglas de enrutamiento
El mapa de URL decide cómo se enrutan hostnames y prefijos de ruta. Puedes usar backends distintos por rutas, por ejemplo assets estáticos desde un bucket y tráfico dinámico a la VM, pero aquí lo mantuvimos simple todo el tráfico para gitlab.apps.dev.to va al servicio respaldado por el NEG.
Paso 5 Certificados y frontend HTTPS
Se creó y adjuntó un certificado durante la actualización del balanceador porque el certificado gestionado automáticamente no aparecía en el desplegable. Ese certificado está asociado al frontend HTTPS para que los clientes vean un certificado válido para gitlab.apps.dev.to. El balanceador gestiona el TLS del cliente y el tramo balanceador a origen sigue siendo HTTPS.
Por qué hacer TLS en el balanceador los clientes reciben un certificado de Google confiable, Google puede ofrecer HTTP2 o QUIC en el borde y si el balanceador reenvía a https con el origen en el 443, mantienes cifrado extremo a extremo sin tocar el SSL interno de GitLab.
Paso 6 Cambio final de DNS el hostname público al IP del balanceador
Actualizamos el registro A público para gitlab.apps.dev.to a 33.149.6.84 la IP del frontend del balanceador. Mantenemos el registro auxiliar gl.apps.dev.to apuntando a 00.105.05.200 para uso del NEG. Esto redirige el tráfico público al borde global y luego hacia el origen vía el NEG y evita que el NEG resuelva al balanceador.
Checklist de pruebas Ejecuta curl -I https://gitlab.apps.dev.to y comprueba cabeceras como Via 1.1 google o indicadores de Cloud CDN. Prueba git ls-remote sobre una URL HTTPS de GitLab. Si algo falla, revierte el A de gitlab.apps.dev.to a la IP del origen para restaurar servicio inmediato.
Paso 7 Configuración de caché y CDN lo que elegimos y por qué
Modo de caché Cachear contenido estático respetando Cache-Control del origen y así cachear CSS, JS e imágenes dejando las páginas dinámicas intactas. TTL de 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. Caché negativa desactivada. GitLab sirve contenido dinámico y privado, no fuerces caché de todo o puedes servir páginas obsoletas o privadas. Deja que el origen marque el caché de assets estáticos con Cache-Control y que Cloud CDN lo respete. Los TTL de 1 hora equilibran frescura y rendimiento, y el fingerprinting de assets permite actualizaciones seguras.
Paso 8 Estrategia de invalidación cómo purgar cachés con seguridad
Cloud CDN permite invalidar por host y ruta o por etiquetas de caché si el origen las emite. GitLab no emite etiquetas por defecto, así que invalidamos por ruta cuando hace falta. Ejemplos tras actualizar assets invalida el patrón de rutas de assets, si avatares no se actualizan invalida uploads o la ruta concreta y como último recurso invalida todo con barra asterisco aunque es costoso. Ejemplo CLI gcloud compute url-maps invalidate-cdn-cache gitlab-url-map --path /assets/* --host gitlab.apps.dev.to
Paso 9 Health checks, monitorización y registros no los omitas
Crea un health check HTTPS que apunte a una ruta como usuarios sign_in en el puerto 443 y asócialo al backend para que el balanceador marque el origen sano o no. Activa registros en el backend y en el balanceador con un muestreo bajo si quieres para diagnosticar fallos de caché o errores del backend. Sin un health check adecuado el balanceador puede marcar el backend como no saludable o no te enteras si el origen cae. Los logs muestran si el tráfico es caché hit o va al origen y si hay errores.
Paso 10 Resolución de problemas y plan de rollback rápido
Si algo falla tras cambiar DNS, revierte el A de gitlab.apps.dev.to a la IP del origen 00.105.05.200 para enviar el tráfico directamente a GitLab y restaurar el servicio. Revisa los logs del balanceador y del backend para ver códigos de estado y posibles problemas en el handshake con el origen. Culpables comunes endpoint del NEG mal configurado apuntando al IP del balanceador provocando bucle, protocolo del backend incorrecto backend HTTP mientras el origen requiere HTTPS o al revés, verificación SSL del backend activada mientras el origen usa un certificado autofirmado. Corrige asegurando que el NEG usa IP o FQDN del origen, ajustando el protocolo del backend o desactivando la verificación del certificado en el backend o instalando un certificado de confianza en el origen.
Notas finales, consejos e ideas avanzadas
Limpieza futura opcional cuando estés listo, termina TLS en el balanceador y sirve HTTP sin cifrar en el origen cambiando GitLab a puerto 80. Es más simple y eficiente sin doble cifrado, pero requiere tocar la configuración de GitLab. Cloud Armor si quieres protección tipo WAF añade políticas de Cloud Armor al balanceador. Certificados en origen a largo plazo usa un certificado válido en el origen y activa la verificación TLS en backend para cifrado estricto extremo a extremo. Logging y métricas activa los registros y métricas del balanceador para ratio de aciertos de caché, latencia de backend y errores 5xx.
Checklist completo en orden para copiar mentalmente 1 crea el A auxiliar gl.apps.dev.to hacia 00.105.05.200 con TTL corto. 2 crea el Internet NEG gitlab-ovh-neg-https apuntando a 00.105.05.200 puerto 443. 3 crea el backend gitlab-ovh-backend-service con protocolo HTTPS adjunta el NEG activa Cloud CDN y desactiva la verificación TLS del backend por ahora. 4 crea el balanceador global gitlab-cdn-1 con mapa de URL que envía gitlab.apps.dev.to al backend y frontend HTTPS con certificado gestionado y redirección HTTP a HTTPS si prefieres. 5 actualiza Cloud DNS para que gitlab.apps.dev.to apunte a la IP del balanceador y mantén gl.apps.dev.to al IP del origen. 6 configura health check HTTPS en el puerto 443 ruta usuarios sign_in. 7 prueba con curl -I y con git ls-remote sobre gitlab.apps.dev.to. 8 invalida cachés si hace falta por ejemplo assets. 9 activa logging del balanceador y monitoriza errores.
Reflexión final Poner un GitLab externo detrás del CDN de Google es como construir un peaje amable en la autopista que verifica tickets y reparte mapas gratis a los turistas los usuarios viajan más rápido, tú obtienes analítica y el servidor de origen recibe menos llamadas nocturnas. El coste es pequeño algo de configuración NEG, backend, certificado pero la recompensa es velocidad global y una experiencia más fluida al clonar, hacer push y navegar por tus repos.
LiveReview te ayuda a obtener gran feedback en tus PR o MR en pocos minutos, ahorrando horas por cada petición de cambio gracias a revisiones automáticas rápidas.
