Categoria: Desenvolupament
SonarQube gestionat: qualitat i seguretat del codi en el vostre pipeline
Anàlisi estàtica de codi en cada pipeline, amb un servidor que no cau per memòria, una base de dades amb còpies i actualitzacions que segueixen la ruta oficial.
- On es munta
- Al vostre compte, a nom vostre
- Còpies
- Amb restauració provada
- Actualitzacions
- Planificades i documentades
- Llicència
- Community Build: LGPLv3. Developer i Enterprise: comercial
En resum
SonarQube és una plataforma d'anàlisi estàtica que revisa el codi a la recerca d'errors, vulnerabilitats i deute tècnic abans que arribe a producció. L'instal·lem al vostre compte sobre PostgreSQL, ajustem el sistema per al seu Elasticsearch intern, el connectem amb el vostre GitLab CI o una altra integració contínua i ens ocupem de les còpies i de les actualitzacions.
De què ens encarreguem?
SonarQube sol instal·lar-se un divendres per a provar i quedar-se amb la base de dades H2 de sèrie, l’usuari admin amb la contrasenya inicial i un pipeline que ningú no mira. L’anàlisi estàtica de codi només serveix si el servidor respon sempre i la porta de qualitat té conseqüències. Això és el que mantenim:
Servidor web
La interfície, l’API que fan servir els escàners i l’inici de sessió, darrere d’un proxy amb HTTPS.
Motor de càlcul
Processa en cua els informes que envien els pipelines; vigilem que la cua no s’acumule.
PostgreSQL
Projectes, regles, historial i usuaris. És l’únic que cal copiar per a recuperar el servidor.
Elasticsearch intern
Límits del sistema, memòria i disc ràpid per a l’índex, que es reconstrueix sol si cal.
Integració contínua
Escàner, tokens i porta de qualitat en cada pipeline, amb plantilles reutilitzables.
Regles
Perfils de qualitat per llenguatge, acordats amb l’equip i versionats.
Quina arquitectura recomanem?
Per a la gran majoria d’equips, un sol node ben dimensionat. L’alta disponibilitat amb diversos nodes només existeix en Data Center Edition i rarament compensa en un equip xicotet.
Pipeline
L’escàner s’executa en el vostre runner de CI, analitza el codi i envia l’informe al servidor.
Servidor SonarQube
Rep l’informe, el processa en el seu motor de càlcul i actualitza l’índex de cerca.
PostgreSQL
Fora del servidor si el proveïdor l’ofereix gestionada, amb baixa latència entre tots dos.
Porta de qualitat
El pipeline consulta el resultat i s’atura si el codi nou no la supera.
L’escàner no s’executa en el servidor: consumeix CPU en els vostres runners. Per això dimensionem tots dos alhora i, si les anàlisis tarden, mirem primer els runners.
Quins problemes trobem en un SonarQube self-hosted?
- Base de dades H2 en producció: la de sèrie és per a proves i no té ruta d’actualització.
- Servidor que no arranca després de reiniciar: el valor de vm.max_map_count es va posar a mà i no va sobreviure al reinici.
- Contenidor executat com a root: Elasticsearch es nega a arrancar així.
- Porta de qualitat decorativa: l’anàlisi s’executa, però el pipeline continua encara que falle.
- Tokens personals en la CI: si aquesta persona se’n va i s’esborra el seu usuari, tots els pipelines deixen d’analitzar.
- Actualització saltant esglaons: s’intenta passar d’una versió antiga a l’última i la migració de la base de dades s’atura.
Com fem les còpies i les actualitzacions?
El que cal conservar és en PostgreSQL: projectes, historial, regles i configuració. L’índex d’Elasticsearch es regenera a partir de la base de dades, així que no el copiem. Fem una còpia diària de la base de dades fora del servidor, guardem a part la configuració i els plugins, i de tant en tant aixequem un SonarQube de prova a partir de la còpia per a comprovar que apareixen els projectes i que una anàlisi nova es processa.
En les edicions de pagament seguim la ruta oficial d’actualització entre versions LTA, amb una còpia abans de cada salt i una prova sobre una rèplica de la vostra base de dades, perquè la migració de l’esquema pot tardar en instàncies amb molt d’historial. Community Build no té LTA i trau versions sovint; la mantenim al dia per a no acumular salts. En tots dos casos revisem que els plugins de tercers siguen compatibles abans de tocar res.
Com protegim el servidor?
SonarQube guarda una descripció molt detallada dels punts febles del vostre codi, així que no el tractem com una eina menor. Canviem el compte d’administració inicial, connectem l’inici de sessió amb el vostre GitLab o el vostre proveïdor d’identitat, fem servir tokens de projecte o d’anàlisi en lloc de tokens personals i restringim qui veu cada projecte. Si no cal accés des de fora, el servidor queda només en la xarxa interna o darrere de la VPN, accessible per als runners.
Com el posem en marxa sense frenar l’equip?
No activem la porta de qualitat bloquejant el primer dia sobre codi antic, perquè tot fallaria. Comencem mesurant, apliquem la porta només al codi nou i l’endurim quan l’equip s’hi acostuma. Si ja teniu un SonarQube vell amb H2, migrem els projectes a una instal·lació nova sobre PostgreSQL i exportem els perfils de regles per a conservar-los.
Encaixa amb la feina de pipelines de CI/CD i infraestructura com a codi i, si busqueu una revisió més àmplia, amb l’auditoria de fiabilitat i seguretat.
On ho muntem?
Al vostre compte, al proveïdor que ja feu servir o al que encaixe millor. Si les dades s'han de quedar a la UE, Hetzner i OVHcloud són les opcions europees.
Proveïdors on ho muntem
- Hetzner
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Servidor propi
| Proveïdor | Com ho muntem | A tindre en compte |
|---|---|---|
| Hetzner | Servidor cloud amb SonarQube i PostgreSQL gestionat per nosaltres en la xarxa privada, i còpies a Object Storage de Hetzner, compatible amb S3. | Hetzner no ofereix base de dades gestionada. Triem un servidor amb memòria folgada, perquè Elasticsearch és el que més consumeix. |
| AWS | SonarQube en EC2 o ECS sobre EC2, amb RDS for PostgreSQL i l'accés darrere d'un balancejador d'aplicació. | En ECS l'amfitrió necessita els ajustos de vm.max_map_count; Fargate no permet canviar-los, així que l'evitem. |
| Google Cloud | Compute Engine o GKE amb Cloud SQL per a PostgreSQL. | En GKE ajustem el paràmetre del nucli en els nodes amb un contenidor d'inici o un DaemonSet. |
| Azure | Màquina virtual o AKS amb Azure Database for PostgreSQL. | L'inici de sessió es connecta amb Microsoft Entra ID per SAML en les edicions que ho inclouen. |
| DigitalOcean | Droplet amb SonarQube i una base de dades PostgreSQL gestionada de DigitalOcean. | Suficient per a equips xicotets; dimensionem la memòria del Droplet abans que la CPU. |
| OVH | Instància de Public Cloud amb la base de dades gestionada d'OVHcloud per a PostgreSQL. | |
| Servidor propi | SonarQube i PostgreSQL en una màquina virtual o en contenidors en els vostres servidors. | Els runners de la CI han d'arribar al servidor; si tot és intern, no cal publicar-lo a internet. |
Què inclou
- SonarQube al vostre compte del núvol o al vostre servidor, a nom de la vostra empresa, amb la configuració al vostre repositori.
- PostgreSQL com a base de dades, mai la H2 integrada, amb còpies diàries i restauració de prova.
- Límits del sistema i memòria ajustats per a l'Elasticsearch intern, persistents després dels reinicis.
- Integració amb GitLab CI, GitHub Actions, Jenkins o una altra CI, amb tokens per projecte i porta de qualitat que bloqueja el pipeline.
- Inici de sessió amb el vostre GitLab, el vostre proveïdor d'identitat o SAML, segons l'edició.
- Perfils i portes de qualitat acordats amb l'equip, en lloc dels valors per defecte sense revisar.
- Actualitzacions seguint la ruta oficial entre versions LTA, provades abans en una còpia.
- Alertes de servidor caigut, cua d'anàlisi encallada, disc i certificats.
Preguntes freqüents
N'hi ha prou amb SonarQube Community Build o cal una edició de pagament?
Per a començar, moltes vegades n'hi ha prou. Community Build és gratuïta i analitza la branca principal dels llenguatges més comuns. Si voleu analitzar branques i veure els resultats dins de cada merge request, o necessiteu llenguatges com C o C++, cal Developer Edition o superior. Aquesta llicència la contracteu vosaltres amb SonarSource, a nom de la vostra empresa; nosaltres l'apliquem i operem el servidor.
Com s'integra SonarQube amb GitLab CI?
Afegim un treball d'anàlisi al pipeline amb l'escàner corresponent, un token per projecte guardat com a variable protegida i l'espera a la porta de qualitat, perquè el pipeline falle si el codi nou no la supera. Amb Developer Edition o superior, els resultats apareixen també com a comentaris en la merge request.
Per què SonarQube no arranca o cau en indexar?
Quasi sempre, pel seu Elasticsearch intern. Si el nucli té vm.max_map_count en el valor per defecte, 65530, Elasticsearch s'atura amb l'error «max virtual memory areas vm.max_map_count [65530] is too low». La documentació oficial demana almenys 524288, a més d'un mínim de descriptors de fitxer i de fils. El deixem en /etc/sysctl.d perquè el valor sobrevisca als reinicis.
Què és una versió LTA i per què importa?
LTA vol dir versió activa de llarg termini: la que SonarSource manté amb correccions durant més temps. En les edicions de pagament és la referència per a actualitzar: es va de LTA en LTA seguint la ruta oficial, sense saltar esglaons. Community Build no té LTA; s'actualitza a la versió més recent.
Podem passar de SonarQube Cloud a un servidor propi?
Sí, però l'historial d'anàlisi no viatja: es tornen a configurar els projectes, els perfils i les portes de qualitat, i l'historial es torna a construir amb les anàlisis següents. Abans exportem els perfils de regles per a no refer-los a mà.
Expliqueu-nos el vostre cas
En una trucada gratuïta de 20 minuts veiem on sou i per on començar. Sense compromís.
Documentació oficial consultada
Les dades tècniques d'aquesta pàgina es basen en:
- SonarQube Server Docs: Linux pre-installation (límits del sistema)
- SonarQube Server Docs: Determining the update path
Revisat el