Categoría: Desarrollo
SonarQube gestionado: calidad y seguridad del código en vuestro pipeline
Análisis estático de código en cada pipeline, con un servidor que no se cae por memoria, una base de datos con copias y actualizaciones que siguen la ruta oficial.
- Dónde se monta
- En vuestra cuenta, a vuestro nombre
- Copias
- Con restauración probada
- Actualizaciones
- Planificadas y documentadas
- Licencia
- Community Build: LGPLv3. Developer y Enterprise: comercial
En resumen
SonarQube es una plataforma de análisis estático que revisa el código en busca de errores, vulnerabilidades y deuda técnica antes de que llegue a producción. Lo instalamos en vuestra cuenta sobre PostgreSQL, ajustamos el sistema para su Elasticsearch interno, lo conectamos con vuestro GitLab CI u otra integración continua y nos ocupamos de las copias y de las actualizaciones.
¿Qué nos encargamos de mantener?
SonarQube suele instalarse un viernes para probar y quedarse con la base de datos H2 de serie, el usuario admin con la contraseña inicial y un pipeline que nadie mira. El análisis estático de código solo sirve si el servidor responde siempre y la puerta de calidad tiene consecuencias. Esto es lo que mantenemos:
Servidor web
La interfaz, la API que usan los escáneres y el inicio de sesión, detrás de un proxy con HTTPS.
Motor de cálculo
Procesa en cola los informes que envían los pipelines; vigilamos que la cola no se acumule.
PostgreSQL
Proyectos, reglas, historial y usuarios. Es lo único que hay que copiar para recuperar el servidor.
Elasticsearch interno
Límites del sistema, memoria y disco rápido para el índice, que se reconstruye solo si hace falta.
Integración continua
Escáner, tokens y puerta de calidad en cada pipeline, con plantillas reutilizables.
Reglas
Perfiles de calidad por lenguaje, acordados con el equipo y versionados.
¿Qué arquitectura recomendamos?
Para la gran mayoría de equipos, un solo nodo bien dimensionado. La alta disponibilidad con varios nodos solo existe en Data Center Edition y rara vez compensa en un equipo pequeño.
Pipeline
El escáner corre en vuestro runner de CI, analiza el código y envía el informe al servidor.
Servidor SonarQube
Recibe el informe, lo procesa en su motor de cálculo y actualiza el índice de búsqueda.
PostgreSQL
Fuera del servidor si el proveedor la ofrece gestionada, con baja latencia entre ambos.
Puerta de calidad
El pipeline consulta el resultado y se detiene si el código nuevo no la supera.
El escáner no se ejecuta en el servidor: consume CPU en vuestros runners. Por eso dimensionamos los dos a la vez y, si los análisis tardan, miramos primero los runners.
¿Qué problemas encontramos en un SonarQube self-hosted?
- Base de datos H2 en producción: la de serie es para pruebas y no tiene ruta de actualización.
- Servidor que no arranca tras reiniciar: el valor de vm.max_map_count se puso a mano y no sobrevivió al reinicio.
- Contenedor ejecutado como root: Elasticsearch se niega a arrancar así.
- Puerta de calidad decorativa: el análisis corre, pero el pipeline sigue adelante aunque falle.
- Tokens personales en la CI: si esa persona se va y se borra su usuario, todos los pipelines dejan de analizar.
- Actualización saltándose escalones: se intenta pasar de una versión antigua a la última y la migración de la base de datos se para.
¿Cómo hacemos las copias y las actualizaciones?
Lo que hay que conservar está en PostgreSQL: proyectos, historial, reglas y configuración. El índice de Elasticsearch se regenera desde la base de datos, así que no lo copiamos. Hacemos una copia diaria de la base de datos fuera del servidor, guardamos aparte la configuración y los plugins, y de vez en cuando levantamos un SonarQube de prueba desde la copia para comprobar que aparecen los proyectos y que un análisis nuevo se procesa.
En las ediciones de pago seguimos la ruta oficial de actualización entre versiones LTA, con una copia antes de cada salto y una prueba sobre una réplica de vuestra base de datos, porque la migración del esquema puede tardar en instancias con mucho historial. Community Build no tiene LTA y saca versiones a menudo; la mantenemos al día para no acumular saltos. En ambos casos revisamos que los plugins de terceros sean compatibles antes de tocar nada.
¿Cómo protegemos el servidor?
SonarQube guarda una descripción muy detallada de los puntos débiles de vuestro código, así que no lo tratamos como una herramienta menor. Cambiamos la cuenta de administración inicial, conectamos el inicio de sesión con vuestro GitLab o vuestro proveedor de identidad, usamos tokens de proyecto o de análisis en lugar de tokens personales y restringimos quién ve cada proyecto. Si no hace falta acceso desde fuera, el servidor queda solo en la red interna o detrás de la VPN, accesible para los runners.
¿Cómo lo ponemos en marcha sin frenar al equipo?
No activamos la puerta de calidad bloqueante el primer día sobre código antiguo, porque todo fallaría. Empezamos midiendo, aplicamos la puerta solo al código nuevo y la endurecemos cuando el equipo se acostumbra. Si ya tenéis un SonarQube viejo con H2, migramos los proyectos a una instalación nueva sobre PostgreSQL y exportamos los perfiles de reglas para conservarlos.
Encaja con el trabajo de pipelines de CI/CD e infraestructura como código y, si buscáis una revisión más amplia, con la auditoría de fiabilidad y seguridad.
¿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 SonarQube y PostgreSQL gestionado por nosotros en la red privada, y copias a Object Storage de Hetzner, compatible con S3. | Hetzner no ofrece base de datos gestionada. Elegimos un servidor con memoria holgada, porque Elasticsearch es lo que más consume. |
| AWS | SonarQube en EC2 o ECS sobre EC2, con RDS for PostgreSQL y el acceso detrás de un balanceador de aplicación. | En ECS el host necesita los ajustes de vm.max_map_count; Fargate no permite cambiarlos, así que lo evitamos. |
| Google Cloud | Compute Engine o GKE con Cloud SQL para PostgreSQL. | En GKE ajustamos el parámetro del kernel en los nodos con un contenedor de inicio o un DaemonSet. |
| Azure | Máquina virtual o AKS con Azure Database for PostgreSQL. | El inicio de sesión se conecta con Microsoft Entra ID por SAML en las ediciones que lo incluyen. |
| DigitalOcean | Droplet con SonarQube y una base de datos PostgreSQL gestionada de DigitalOcean. | Suficiente para equipos pequeños; dimensionamos la memoria del Droplet antes que la CPU. |
| OVH | Instancia de Public Cloud con la base de datos gestionada de OVHcloud para PostgreSQL. | |
| Servidor propio | SonarQube y PostgreSQL en una máquina virtual o en contenedores en vuestros servidores. | Los runners de la CI tienen que llegar al servidor; si todo es interno, no hace falta publicarlo en internet. |
Qué incluye
- SonarQube en vuestra cuenta cloud o en vuestro servidor, a nombre de vuestra empresa, con la configuración en vuestro repositorio.
- PostgreSQL como base de datos, nunca la H2 integrada, con copias diarias y restauración de prueba.
- Límites del sistema y memoria ajustados para el Elasticsearch interno, persistentes tras los reinicios.
- Integración con GitLab CI, GitHub Actions, Jenkins u otra CI, con tokens por proyecto y puerta de calidad que bloquea el pipeline.
- Inicio de sesión con vuestro GitLab, vuestro proveedor de identidad o SAML, según la edición.
- Perfiles y puertas de calidad acordados con el equipo, en lugar de los valores por defecto sin revisar.
- Actualizaciones siguiendo la ruta oficial entre versiones LTA, probadas antes en una copia.
- Alertas de servidor caído, cola de análisis atascada, disco y certificados.
Preguntas frecuentes
¿Basta SonarQube Community Build o hace falta una edición de pago?
Para empezar, muchas veces basta. Community Build es gratuita y analiza la rama principal de los lenguajes más comunes. Si queréis analizar ramas y ver los resultados dentro de cada merge request, o necesitáis lenguajes como C o C++, hace falta Developer Edition o superior. Esa licencia la contratáis vosotros con SonarSource, a nombre de vuestra empresa; nosotros la aplicamos y operamos el servidor.
¿Cómo se integra SonarQube con GitLab CI?
Añadimos un trabajo de análisis al pipeline con el escáner correspondiente, un token por proyecto guardado como variable protegida y la espera a la puerta de calidad, para que el pipeline falle si el código nuevo no la pasa. Con Developer Edition o superior, los resultados aparecen también como comentarios en la merge request.
¿Por qué SonarQube no arranca o se cae al indexar?
Casi siempre, por su Elasticsearch interno. Si el kernel tiene vm.max_map_count en el valor por defecto, 65530, Elasticsearch se para con el error «max virtual memory areas vm.max_map_count [65530] is too low». La documentación oficial pide al menos 524288, además de un mínimo de descriptores de archivo y de hilos. Lo dejamos en /etc/sysctl.d para que el valor sobreviva a los reinicios.
¿Qué es una versión LTA y por qué importa?
LTA significa versión activa de largo plazo: la que SonarSource mantiene con correcciones durante más tiempo. En las ediciones de pago es la referencia para actualizar: se va de LTA en LTA siguiendo la ruta oficial, sin saltar escalones. Community Build no tiene LTA; se actualiza a la versión más reciente.
¿Podemos pasar de SonarQube Cloud a un servidor propio?
Sí, pero el historial de análisis no viaja: se configuran de nuevo los proyectos, los perfiles y las puertas de calidad, y el historial vuelve a construirse con los siguientes análisis. Exportamos antes los perfiles de reglas para no rehacerlos a mano.
Contadnos vuestro caso
En una llamada gratuita de 20 minutos vemos dónde estáis y por dónde empezar. Sin compromiso.
Documentación oficial consultada
Los datos técnicos de esta página se basan en:
- SonarQube Server Docs: Linux pre-installation (límites del sistema)
- SonarQube Server Docs: Determining the update path
Revisado el