DevOps open source su larga scala: gestire GitLab in proprio

Il codice sorgente è l'unico bene che quasi tutte le aziende tecnologiche concordano nel considerare critico, ed è anche quello che la maggior parte tiene su un'infrastruttura che non possiede, in una giurisdizione che non ha scelto, sotto un contratto che non ha letto con attenzione. Di solito la cosa funziona. Vale comunque la pena sapere quanto costa l'alternativa, perché GitLab da oltre dieci anni rende davvero praticabile ospitare in casa l'intero ciclo di sviluppo.

È anche un prodotto il cui piano gratuito è più generoso e il cui carico operativo è più pesante di quanto quasi chiunque si aspetti. Entrambe le cose vanno capite prima di impegnarsi, quindi questa guida spiega che cos'è davvero GitLab self-managed, che cosa dà realmente il piano gratuito e i tre problemi operativi che concentrano quasi tutto il dolore.

Che cos'è GitLab

Non un hosting Git con qualche extra avvitato sopra. Un'applicazione Rails, PostgreSQL, Redis, Gitaly per l'archiviazione dei repository, Sidekiq per i job in background e un container registry, impacchettati insieme come un unico sistema che copre controllo di versione, revisione del codice, gestione delle issue, CI/CD, registry di pacchetti e container, analisi di sicurezza e deploy.

Quell'ampiezza è tutto l'argomento. GitHub più Actions più Dependabot più un registry di pacchetti più un tracker di progetto danno un insieme di funzioni paragonabile, assemblato da pezzi. GitLab è un'applicazione con un modello di permessi e un database. O è esattamente ciò che volete, o è più di quanto vi serva, e quale delle due dipende da quanta parte del ciclo intendete davvero far girare nello stesso posto.

Il fatto architetturale che conta è lo stesso dell'analytics self-hosted con Matomo, della marketing automation con Mautic o della chat aziendale con Mattermost: gira dove lo mettete voi. I vostri repository, i vostri log di CI, i vostri artefatti, il vostro database.

Il quadro delle licenze, detto chiaro

Questo punto confonde davvero e merita precisione, perché la confusione va nella direzione opposta a quella che ci si aspetta.

Ci sono due distribuzioni del sorgente. La Community Edition è sotto licenza MIT. La Enterprise Edition ha una licenza propria, più restrittiva, che copre la directory ee/ del repository. Finora sembra il solito modello open core.

La parte che sorprende: il pacchetto Linux che installano quasi tutti è la build della Enterprise Edition, e senza chiave di licenza applicata gira come piano Free, comportandosi come la Community Edition. Non state eseguendo la distribuzione sotto MIT, a meno che non abbiate scelto deliberatamente il pacchetto CE. In pratica raramente conta, ma se la vostra ragione per autogestirvi è una politica open source rigorosa e non il controllo dei dati, allora conta moltissimo, e quasi nessuno lo verifica.

I piani commerciali sono Free, Premium a 29 dollari per utente al mese con fatturazione annuale, e Ultimate a prezzo su richiesta. Premium aggiunge CI/CD avanzata, migliore gestione dei progetti e supporto prioritario. Ultimate aggiunge la suite di sicurezza e conformità: test di sicurezza applicativa, sicurezza della supply chain, analisi delle dipendenze. Entrambi i piani a pagamento includono ormai i GitLab Credits per le funzioni di IA, 12 dollari per utente al mese su Premium e 24 su Ultimate.

Ed ecco il dato che cambia i conti per la maggior parte dei team, esattamente l'inverso della situazione di Mattermost: il piano Free in self-managed non ha limite di utenti. Il tetto di cinque utenti di cui molti hanno sentito parlare vale solo per i gruppi privati su GitLab.com. In self-hosted, Free vi dà utenti illimitati, controllo di versione, CI/CD e registry, e storage e runner li portate voi. Un'organizzazione da cento ingegneri può girarci interamente sopra.

Quello a cui rinunciate è l'analisi di sicurezza, la reportistica di conformità, le regole di approvazione avanzate e il supporto. Se ricadete sotto il Cyber Resilience Act e volete analisi delle dipendenze e generazione di SBOM dentro le pipeline invece che assemblate da strumenti separati, quella è una conversazione da Ultimate. Per quasi tutti gli altri team, Free non è una prova. È una risposta permanente e sostenibile.

L'installazione

Un rilascio piccolo

GitLab pesa più di quanto sembri. La base documentata per un singolo nodo è 8 vCPU e 16 GB di RAM, e a differenza della maggior parte dei minimi dichiarati dai produttori quel numero è onesto e non ottimistico. Si può comprimere in 8 GB, ma si sente, e lo swap andrebbe disattivato, perché mandare in swap questa applicazione è peggio che non avere la memoria.

PostgreSQL è l'unico database supportato. Quale versione dipende dalla vostra versione di GitLab: la 17.x vuole PostgreSQL da 14.14 a 16.x, la 18.x vuole da 16.5 a 17.x, la 19.x vuole 17.x. Redis 7.2 è consigliato, 7.0 è il minimo, e Valkey 7.2 va bene come sostituto. Solo istanze autonome, perché le varianti in cluster e serverless di Redis non sono supportate.

Installate con il pacchetto Linux. Ci sono chart Helm, un Operator, immagini Docker e una strada dai sorgenti, ma il pacchetto Linux è l'opzione più matura ed è ciò su cui gira GitLab.com stesso. Include PostgreSQL, Redis e Sidekiq, quindi una macchina e un file di configurazione bastano per avere un'istanza funzionante.

# /etc/gitlab/gitlab.rb
external_url 'https://git.example.com'

# Let's Encrypt, on by default when external_url is https
letsencrypt['enable'] = true
letsencrypt['contact_emails'] = ['ops@example.com']

# Keep Puma and Sidekiq honest on a small box
puma['worker_processes'] = 2
sidekiq['max_concurrency'] = 9

# Move artefacts and uploads off local disk early
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
  'provider' => 'AWS',
  'region' => 'eu-central-1',
  'aws_access_key_id' => 'REPLACE_ME',
  'aws_secret_access_key' => 'REPLACE_ME'
}

Un gitlab-ctl reconfigure dopo avete un'istanza. Impostate external_url correttamente la prima volta, perché quel valore finisce inciso negli URL di clone, nei webhook e negli indirizzi del registry.

Un rilascio di produzione

GitLab pubblica architetture di riferimento da 1.000 a 50.000 utenti, e vale la pena leggerle anche se non ne implementerete nessuna, perché mostrano quale componente diventa per primo il collo di bottiglia.

Il consiglio che fa risparmiare di più viene da GitLab stessa e argomenta contro la complessità: sotto i 3.000 utenti raccomandano una solida strategia di backup invece dell'alta disponibilità. La documentazione è insolitamente franca al riguardo, notando che l'approccio a backup ha sì un tempo di ripristino più lento, ma comporta un'architettura molto più piccola e minori costi di manutenzione. Sopra i 3.000 utenti, o dove un fermo blocca davvero l'azienda, l'alta disponibilità diventa la raccomandazione.

Prendetela sul serio. Un singolo nodo ben salvato, con un ripristino testato, è nella pratica più affidabile di un cluster in alta disponibilità capito a metà, e costa parecchio meno.

Spostate artefatti, upload, oggetti LFS e immagini del registry su object storage fin dall'inizio. Stesso ragionamento di sempre: tiene il nodo senza stato, i backup gestibili e la migrazione possibile.

Le tre cose che vanno storte

Tutto quanto sopra sta nella documentazione. Queste sono quelle che generano incidenti.

Il vostro backup non contiene ciò che lo decifra

Questo è il paragrafo più importante dell'articolo.

gitlab-backup create cattura parecchio: database, repository, oggetti LFS, artefatti di CI e log dei job, immagini del registry, wiki, upload, contenuti Pages, stato Terraform, snippet. Ciò che non cattura è la directory di configurazione, e in particolare /etc/gitlab/gitlab-secrets.json.

Quel file contiene la chiave di cifratura del database. La documentazione è netta sulla conseguenza: se lo perdete, l'applicazione GitLab non sarà in grado di decifrare alcun valore cifrato nel database. Vuol dire variabili CI/CD, token, segreti a due fattori e credenziali delle integrazioni. Avreste un backup che si ripristina in un'istanza incapace di leggere i propri segreti.

Sono esclusi anche /etc/gitlab/gitlab.rb, chiavi e certificati TLS, chiavi host SSH e i contenuti dell'object storage quando l'object storage è configurato. Quest'ultimo punto colpisce proprio chi ha fatto la scelta architetturale giusta e poi ha dato per scontato che il backup lo coprisse.

Quindi salvate /etc/gitlab a parte, tenetelo altrove rispetto all'archivio, dato che ne è la chiave, e poi ripristinate il tutto su una macchina usa e getta e verificate di riuscire ad accedere e a leggere una variabile di CI. Un backup non testato non è un backup, e nel caso di GitLab un ripristino non testato di solito è rotto.

Non potete aggiornare in un solo salto

GitLab ha tappe obbligatorie di aggiornamento, e non è un consiglio. Non potete saltarle. Dalla 17.5 le tappe sono prevedibili e cadono su x.2, x.5, x.8 e x.11, per cui passare da 18.0 a 19.2 significa attraversare 18.2, 18.5, 18.8, 18.11 e 19.0.

Ogni tappa comporta migrazioni in background che devono completarsi del tutto prima di procedere alla successiva. Avviare l'aggiornamento seguente mentre le migrazioni sono ancora in corso è il modo in cui le istanze finiscono in stati che solo il supporto sbroglia. Su un'istanza grande quelle migrazioni possono richiedere ore.

Due conseguenze pratiche. Aggiornate con regolarità, perché un anno di aggiornamenti rimandati è un fine settimana di aggiornamenti in sequenza. E prendete sempre l'ultima patch della minor di destinazione anziché la prima, cosa che la documentazione dice esplicitamente. GitLab mantiene uno strumento che calcola il percorso di aggiornamento per voi, e conviene usarlo invece di ragionarci da soli.

Il costo vero sta nei runner

Il server GitLab non esegue la vostra CI. GitLab Runner è un componente separato che installate, configurate e pagate, su infrastruttura che fornite voi. Free self-managed non include alcun minuto di calcolo, perché non c'è calcolo incluso da dare: le macchine le portate voi.

Di solito è un buon affare, perché un runner dedicato costa meno al minuto di qualsiasi CI ospitata quando il volume è serio, e potete dare a ogni build l'hardware che le serve. Ma è vero lavoro infrastrutturale. Deciderete sugli executor, se shell, Docker o Kubernetes; sull'autoscaling, perché i runner non girino a vuoto alle tre di notte; e sulla cache, che è la differenza tra una pipeline da quattro minuti e una da quattordici.

Mettete la flotta di runner a budget come voce a sé. I team che stimano il costo dell'autogestione guardando solo al nodo GitLab lo sottovalutano di parecchio, e poi scoprono il buco sotto forma di coda di job in attesa.

Uscire da GitHub

L'importatore GitHub è buono, nettamente migliore di gran parte degli strumenti di migrazione dei fornitori, e porta dati del repository, branch, oggetti LFS, issue e pull request con commenti, revisioni e risposte nelle discussioni, pagine wiki, release e allegati, etichette, milestone, regole di protezione dei branch e collaboratori con mappatura dei ruoli.

Le lacune documentate vanno pianificate. Organizzazioni e gruppi non passano, quindi la struttura dei gruppi è vostra da progettare invece che da ereditare, il che di solito è un miglioramento. I workflow di GitHub Actions non si convertono in GitLab CI. I commenti alle pull request precedenti al 2017 arrivano come thread separati per vincoli dell'API di GitHub, e i repository oltre i 30.000 commenti circa richiedono l'attivazione del metodo alternativo di import dei commenti.

Poiché GitHub usa # sia per le issue sia per le pull request e GitLab le distingue, alcuni riferimenti incrociati non si risolveranno. Non si perde nulla, ma i link nelle vecchie discussioni possono puntare alla cosa sbagliata.

Pianificate la riscrittura della CI come il progetto vero, perché lo è. Tutto il resto è un import che lanciate e verificate.

L'angolo europeo

Per le aziende che operano in Europa al costo si aggiunge una dimensione di conformità. Codice sorgente, pipeline di build e artefatti sono tra le cose più sensibili che un'azienda tecnologica possieda, e dove risiedono è sempre più una domanda che vi viene posta anziché una a cui scegliete di rispondere.

L'autogestione li mette dentro un confine che controllate voi, il che semplifica in un colpo solo l'analisi dei trasferimenti secondo il GDPR e le domande sulla catena di fornitura di NIS2, ed è lo stesso argomento di sovranità attorno a cui è costruito il Cloud and AI Development Act.

Il legame più netto è il Cyber Resilience Act. Chi immette software sul mercato europeo avrà bisogno di inventari delle dipendenze, gestione delle vulnerabilità e un processo di divulgazione coordinata. Quegli obblighi si soddisfano nella pipeline di build e non in un documento, e avere pipeline, registry e scansioni in un unico sistema che gestite voi rende la produzione delle evidenze molto meno faticosa che raccoglierle da quattro fornitori.

Quando lasciar perdere

Se siete meno di venti ingegneri, senza pressione normativa né opinioni forti su dove viva il codice, prendete il SaaS. GitLab.com e GitHub sono entrambi ottimi, e il lavoro di gestione costerà più dell'abbonamento.

Se la vostra organizzazione è immersa nell'ecosistema GitHub, contate onestamente che cosa perdereste. Actions, il marketplace e la semplice familiarità della piattaforma per ogni candidato che assumete sono beni reali, e la risposta non è automaticamente che vince GitLab.

E se nessuno prenderà in carico l'istanza, non cominciate. GitLab premia chi applica le patch, sorveglia la flotta di runner e prova il ripristino. Senza quella persona degrada in una macchina non aggiornata che contiene il vostro bene più prezioso, il che è peggio del SaaS da cui volevate andarvene.

Come possiamo aiutarvi

Installiamo e gestiamo infrastruttura di sviluppo self-hosted per aziende che operano in Europa, comprese le parti che non piacciono a nessuno: sequenze di aggiornamento attraverso le tappe obbligatorie, flotte di runner con autoscaling che funziona, migrazioni verso object storage e schemi di backup che sono stati davvero ripristinati.

Se volete un'istanza GitLab dimensionata onestamente, una migrazione da GitHub pianificata da chi la riscrittura della CI l'ha già fatta, o una verifica se il vostro backup attuale sopravviverebbe a un guasto vero, scrivete a office@c9group.dev. Altro sul nostro lavoro infrastrutturale nella pagina sull'ottimizzazione dei costi AWS.

Se state mettendo insieme uno stack self-hosted completo, lo stesso ragionamento vale per l'analytics, la marketing automation e la messaggistica di squadra.

---

Pubblicato: 8 agosto 2026 Categorie: DevOps, Open Source, Privacy