Come Ospitare Autonomamente GitLab CE su un Hosting VPS

È un pomeriggio di venerdì, la pull request del tuo team è in fase di revisione e il tuo laptop emette un segnale con un messaggio familiare: GitHub sta riscontrando problemi di nuovo.

Forse le azioni sono bloccate.

Forse `git push` restituisce un errore 500 per la terza volta questo mese.

Il thread nella tua chat di squadra ha già otto messaggi.

La prima volta che succede, ci si ride su. La seconda volta, qualcuno invia il link alla pagina di stato di GitHub, e tutti andate a prendere un caffè. La terza volta, di solito proprio prima di una finestra di rilascio, qualcuno finalmente digita la domanda ad alta voce: “Dovremmo gestirlo noi stessi?”

Per la maggior parte dei team, la risposta onesta è no. GitLab.com Free copre comodamente i piccoli team, e il carico operativo di gestire il proprio server di controllo versione non è nullo.

È il tipo di scambio che fai solo per un motivo reale.

Se il tuo team ha uno di questi motivi, come un contratto con il cliente che vieta i SaaS di terze parti, un limite di conformità, o una fattura per licenze che sta diventando ridicola, ospitare autonomamente GitLab CE è la mossa più pulita che puoi fare. È open source, funziona su un singolo VPS e, una volta ottimizzato, la manutenzione richiede circa un’ora al mese.

Da DreamHost, abbiamo ospitato innumerevoli server autogestiti, e continuiamo a vedere uno schema: gli sviluppatori che hanno successo con GitLab autogestito scelgono il piano giusto fin dall’inizio, configurano correttamente il Protocollo Secure Shell (SSH) e il sistema di nomi di dominio (DNS), e poi resistono alla tentazione di continuare a modificare una volta che è stabile.

Perché Dovresti Ospitare Personalmente GitLab Invece di Usare GitLab.com?

Tu ospiti autonomamente GitLab quando GitLab.com o GitHub.com non possono soddisfare le tue esigenze di privacy, conformità o controllo dei costi. Per la maggior parte degli altri team, l’opzione ospitata è una scelta migliore.

Tre veri motivi resistono all’analisi:

1. Privacy e Sovranità Dei Dati: Il tuo codice sorgente risiede su un’infrastruttura che gestisci e aggiorni secondo il tuo calendario. Nessun accesso di terze parti, nessuna piattaforma condivisa, nessun rischio di violazione oltre il tuo server.
2. Conformità: Settori regolamentati come la sanità, la finanza e il governo spesso necessitano di controllo della residenza dei dati. GitLab CE auto-ospitato è il modo più semplice per mantenere il codice all’interno di un confine controllato. 
3. Controllo Dei Costi Su Larga Scala: GitLab.com addebita per utente attivo. Secondo la pagina dei prezzi di GitLab, il piano Premium costa $29 per utente al mese, mentre il prezzo del piano Ultimate è disponibile solo su richiesta. Un team di 50 persone con il piano Premium costa $17,400 all’anno prima degli add-on. Un VPS autogestito più un’ora di manutenzione mensile spesso costa meno.

Se sei un team di due persone senza motivi di privacy o conformità, la risposta giusta è il livello gratuito di GitLab. (Sì, sappiamo che suona strano detto da una società di hosting).

Con l’hosting autonomo, stai scambiando una fattura mensile di SaaS con tempo operativo continuo. Questo scambio vale la pena solo se hai un buon motivo per effettuare il cambio.

Ecco dove questa opzione ha senso e dove non ne ha:

Scenario	Migliore opzione
Requisiti di privacy o conformità	GitLab CE auto-ospitato
Team di più di ~30 utenti attivi	L’auto-ospitato è spesso più economico
Il codice è la tua proprietà intellettuale e vuoi che sia locale	GitLab CE auto-ospitato
Team di 2-5 persone, senza necessità di conformità	GitLab.com (gratuito)
Non vuoi gestire l’aggiornamento di un server	GitLab.com

GitLab Community Edition è gratuito sotto una licenza open-source di tipo MIT. Non ci sono limiti di utenti, nessun blocco delle funzionalità di base e nessun invito all’acquisto. L’intera piattaforma è tua da gestire.

Quali Sono i Requisiti Hardware per GitLab CE?

GitLab CE ha soglie hardware ben definite, e stabilirle correttamente fa la differenza tra un’installazione reattiva e una che si dibatte attraverso la memoria di swap (spazio su disco che il tuo sistema operativo utilizza quando la RAM si riempie).

Secondo i requisiti di installazione ufficiali di GitLab, le dimensioni sono espresse in richieste al secondo piuttosto che in livelli fissi per utente. Il baseline pubblicato è di 8 vCPU e 16 GB di RAM per fino a 1.000 utenti (circa 20 richieste al secondo). I team più piccoli possono funzionare con meno, fino a un minimo documentato di 2 GB di RAM più 1 GB di swap per la valutazione, anche se le prestazioni sono inferiori sotto i 4 GB.

Una nuova installazione di GitLab consuma circa 4-6 GB in stato di inattività. Una volta che i lavori di CI/CD iniziano a funzionare, la memoria aumenta rapidamente. Quindi pianifica un margine di manovra — o preparati alla lentezza.

Per quanto riguarda l’archiviazione, il punto di partenza ufficiale di GitLab è 40 GB più la dimensione del repository, ma 50 GB è un punto di partenza più sicuro nella pratica. I repository crescono e gli artifact di build si accumulano. NVMe, un tipo di archiviazione a stato solido più veloce, fa una differenza notevole nelle operazioni Git e nelle letture della cache CI.

Ecco come queste soglie corrispondono ai livelli di hosting VPS di DreamHost:

Caso D’uso	RAM Consigliata	Livello DreamHost VPS
Valutazione / personale	4 GB RAM	Stack 4
Piccolo team, uso leggero	8 GB RAM	Stack 8
Fino a ~1.000 utenti (linea di base pubblicata da GitLab)	16 GB RAM	Stack 16
Utilizzo di runner CI/CD sulla stessa macchina	+ 2-8 GB RAM oltre al tuo livello	Aumenta le dimensioni (ad es. da Stack 16 a Stack 32)

Il punto di partenza giusto per la maggior parte dei team che gestiscono vere pipeline CI/CD è Stack 16. Questo può sembrare eccessivo fino a quando non assisti al primo build che si attiva e Sidekiq, Postgres e un runner aumentano contemporaneamente.

16 GB di RAM ti offrono abbastanza spazio per lo stack di servizi di GitLab (circa 4-6 GB a riposo in un’installazione predefinita) e un paio di lavoratori CI (1-2 GB ciascuno) per funzionare contemporaneamente senza che nessuno nella chat del team se ne accorga.

Come Prepari Il Tuo VPS Prima Di Installare GitLab?

Impiega 10 minuti nella preparazione — ne vale la pena la prima volta che riavvii. Segui semplicemente questi passaggi:

1. Configura il VPS: Scegli Ubuntu 22.04 LTS o 24.04 LTS. Entrambi sono supportati dai pacchetti Omnibus ufficiali di GitLab (il pacchetto installatore tutto-in-uno che GitLab distribuisce) e hanno anni di aggiornamenti di sicurezza gratuiti davanti a loro.
   
2. Collega un dominio all’IP del server: Crea un record A (il tipo di record DNS che mappa un dominio a un indirizzo IP) e lascia che si propaghi per almeno 15-30 minuti prima di installare. Senza di esso, la configurazione automatica SSL fallirà perché l’autorità di certificazione non avrà un luogo dove validare.
   
3. Aggiorna i pacchetti: Connettiti al VPS usando `ssh root@your-server-ip` e esegui `sudo apt update && sudo apt upgrade -y`.
   
4. Installa le dipendenze: Esegui `sudo apt install -y curl openssh-server ca-certificates perl postfix`. Il pacchetto `postfix` è un server di posta che gestisce l’email in uscita così GitLab può inviare notifiche di merge-request e reset delle password.
   Quando l’installer chiede della configurazione della posta, scegli Sito Internet e usa il tuo dominio. Questo permette a GitLab di inviare email immediatamente.
   Per la produzione: salta il postfix locale e configura un relay SMTP in gitlab.rb invece. Gli IP VPS sono frequentemente nelle liste di blocco dello spam, e le email di reset della password inviate tramite il postfix locale finiscono spesso nello spam. SendGrid, Mailgun e il relay in uscita di DreamHost funzionano tutti — vedi la documentazione sulla configurazione SMTP di GitLab.
   
5. Apri le porte corrette: Configura un firewall usando UFW (lo strumento di firewall integrato di Ubuntu) e permetti le porte 80, 443, e 22.

sudo ufw allow http
sudo ufw allow https
sudo ufw allow ssh
sudo ufw enable

Come Si Installa GitLab CE Su Ubuntu Utilizzando Il Pacchetto Omnibus?

Aggiungi il repository GitLab CE:

curl -sSL https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash

Poi, installa GitLab CE con il tuo dominio impostato come URL esterno:

sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ce

Impostare `https://` qui indica a GitLab di richiedere automaticamente un certificato Let’s Encrypt durante l’installazione, purché le porte 80 e 443 siano aperte e il DNS sia configurato correttamente. Se una di queste non è pronta, l’installazione si completa ma SSL fallisce — e trascorrerai i successivi trenta minuti a risolvere un problema che in realtà non è rotto.

Successivamente, attendi il passaggio di riconfigurazione.

GitLab esegue `gitlab-ctl reconfigure` (il comando che applica le modifiche alla configurazione di GitLab) automaticamente al termine dell’installazione. Ci vogliono da cinque a 10 minuti. E sì, la fase di riconfigurazione richiede davvero tutto quel tempo.

Ottieni la password iniziale di Root:

sudo cat /etc/gitlab/initial_root_password

Questo file viene generato automaticamente e verrà cancellato tra 24 ore, quindi prendi la password e accedi. Visita il tuo dominio in un browser, accedi come `root` e cambia subito la password.

Infine, verifica l’installazione.

Dalla schermata di benvenuto di GitLab, crea un progetto di test. Effettua un commit su di esso dalla tua macchina locale. Se il push va a buon fine e il file appare nell’interfaccia web, l’installazione è funzionante.

Se il passaggio di riconfigurazione si blocca, controlla `tail -f /var/log/gitlab/reconfigure/*.log`. È lì che si trova l’errore effettivo.

Come Si Blocca Un’istanza GitLab Auto-ospitata?

GitLab è fornito con impostazioni predefinite ragionevoli, ma sono ottimizzate per un server comunitario aperto, non per la tua istanza privata di team. Dedica un’ora qui.

1. Disabilita l’iscrizione aperta. L’iscrizione aperta è attiva per impostazione predefinita. Nell’Area Amministrativa, vai a Impostazioni > Generali > Restrizioni di iscrizione e disattiva la casella di controllo “Iscrizione abilitata”. Altrimenti, chiunque con l’URL può creare un account.
2. Abilita l’autenticazione a due fattori. Vai a Area Amministrativa > Impostazioni > Generali > Restrizioni di accesso e impone il 2FA a tutti gli utenti. Riduci il periodo di grazia dalle 48 ore predefinite a 8 ore.
3. Limita la creazione di progetti. Imposta Creazione di Progetti Predefinita a Maintainers o Nessuno, a seconda di quanto vuoi che sia restrittivo.
4. Verifica il rinnovo SSL. GitLab rinnova automaticamente i certificati di Let’s Encrypt per impostazione predefinita. Per confermare, esegui `sudo gitlab-ctl renew-le-certs` una volta e controlla l’output.
5. Blocca SSH sul VPS stesso. Disabilita l’accesso con password dell’utente root, permetti solo l’autenticazione con chiave SSH e (se possibile) sposta SSH fuori dalla porta 22. Un server Git auto-ospitato è sicuro solo quanto il server che lo ospita.

Per una versione approfondita, GitLab ha pubblicato una Guida al Rafforzamento che copre autenticazione, crittografia e impostazioni dell’istanza. Leggila una volta, applica ciò che corrisponde al tuo modello di minaccia e vai avanti.

Come Si Esegue il Backup e il Ripristino di un’Instanza GitLab Auto-ospitata?

GitLab include uno strumento di backup integrato. La prima volta che ne avrai bisogno, sarai felice di averlo configurato.

Crea un backup:

sudo gitlab-backup create

Questo inserisce un tarball in `/var/opt/gitlab/backups`. Programma l’operazione giornaliera tramite Cron Job con una finestra di conservazione di sette giorni. Esegui sudo crontab -e e aggiungi queste due righe:

0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1
0 3 * * * find /var/opt/gitlab/backups -name "*.tar" -mtime +7 -delete

Il flag CRON=1 sopprime l’output di progresso in modo che non invii spam ai log di cron.

Consiglio Pro: il backup dei dati non include `/etc/gitlab/gitlab-secrets.json` o `/etc/gitlab/gitlab.rb`.

Questi file contengono la chiave di crittografia del database, i semi a due fattori e le variabili CI/CD. I segreti di configurazione non fanno parte del backup regolare e devono essere salvati separatamente. Ripristina i dati senza il file dei segreti e gli account a due fattori smetteranno di funzionare, le variabili criptate diventeranno incomprensibili e passerai una lunga serata a capire il motivo.

Aggiungi questo allo stesso Cron Job:

sudo cp /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab.rb /var/opt/gitlab/backups/

Un backup può essere ripristinato solo sulla stessa versione e edizione (da CE a CE, non da CE a EE) di GitLab su cui è stato creato.

Aggiorna con attenzione: non ripristinare un vecchio backup su un GitLab appena installato senza prima cambiare il piano dell’installazione per farlo corrispondere.

Testa il processo di ripristino almeno una volta. Un backup che non hai mai testato è solo un file.

È Davvero Utile Auto-Ospitare GitLab per il Tuo Team?

Autogestire GitLab è una decisione di controllo per la maggior parte dei team. I calcoli dei costi possono a volte convenire, ma il motivo per cui le persone continuano con l’autogestione raramente riguarda la voce di bilancio.

Ecco il costo mensile onesto per l’installazione di un piccolo team:

• ~30 minuti di aggiornamenti – aggiornamenti apt, rilasci minori di GitLab
• ~15 minuti di verifica del backup – non fidarti di un backup che non hai ripristinato
• ~15 minuti di controllo della capacità – utilizzo del disco, margine della RAM
• ~2x se CI/CD è eseguito sulla macchina – Un runner impegnato può raddoppiare il carico

Si tratta di circa un’ora al mese in una settimana tranquilla, o due in una settimana intensa.

A circa $150 all’ora, 12 ore di tempo operativo costano circa $1,800 — più o meno cinque posti GitLab.com Premium.

Uno studio di caso pratico di Mad Devs descrive come il loro team risparmia più di $10,000 all’anno utilizzando GitLab CE auto-ospitato invece di pagare per i posti Premium. I risparmi si concretizzano solo quando il team è abbastanza grande che le licenze per postazione dominano il budget.

Detto ciò, l’auto-ospitazione è la scelta sbagliata per:

• Squadre di due o tre persone senza motivi di conformità. GitLab.com Free ti copre. Il tempo operativo è maggiore del costo risparmiato.
• Squadre senza nessuno a suo agio con la linea di comando. “A suo agio” non significa essere un amministratore di sistema. Significa che puoi leggere gli errori in `/var/log/gitlab` senza panico.
• Squadre il cui maggiore ostacolo è l’assunzione, non gli strumenti. L’auto-ospitazione distoglie l’attenzione dal prodotto. Se la velocità del prodotto è la restrizione, l’ospitato è la scelta giusta.

Allora, quando ha senso l’auto-ospitare? Di seguito alcuni scenari:

• Industrie regolamentate con requisiti espliciti di residenza dei dati o catena di custodia
• Team dell’UE/UK con preoccupazioni di sovranità riguardo al codice ospitato negli Stati Uniti
• Team di 30 o più persone dove le licenze per postazione dominano il budget
• Contratti con i clienti che vietano il SaaS di terze parti per il codice sorgente

Se il tuo motivo è “GitHub addebita per posto,” probabilmente ne trarrai vantaggio. Se il tuo motivo è “Voglio sentirmi in controllo,” potresti scoprire che la realtà operativa è meno romantica di quanto ti aspettassi.

Dovresti Eseguire I Runner GitLab CI/CD Sullo Stesso VPS?

Per la valutazione, sì. Per la produzione, no.

Un runner CI sulla stessa macchina sottrae memoria e CPU all’interfaccia utente di GitLab. Il sintomo classico è “GitLab sembra lento alle 9 del mattino”, che di solito si ricollega all’avvio di una build che dà il via alla prima pipeline del mattino e sottrae risorse al frontend web. La configurazione più pulita prevede un piccolo VPS separato (o un’istanza di DreamCompute) per il runner, registrato all’istanza GitLab tramite la rete.

Se devi mantenere i runner sulla stessa scatola, aumenta il VPS a 16 GB.

Secondo i requisiti del sistema runner di GitLab, il processo del runner in sé è leggero. I carichi di lavoro che esegue non lo sono, e condividono la CPU e il disco del box con tutto il resto che GitLab sta facendo.

Pronto a Fare il Cambio?

Torna alla chat di squadra del venerdì pomeriggio.

Se GitHub diventa giallo e il tuo team ride di nuovo e va a prendere un caffè, va bene.

Ma se il malfunzionamento di GitHub inizia a sembrare qualcosa di serio?

Forse sta minacciando un contratto con un cliente? Si presenta in un audit di conformità? O la fattura della licenza per postazione ha finalmente superato il limite?

L’auto-ospitamento di GitLab CE inizia a diventare un’opzione del tutto ragionevole. Tutto ciò che serve è un VPS, un dominio, un’installazione Omnibus e un’ora di rafforzamento.

Entro la prossima volta che si illuminerà la pagina di stato di GitHub, il tuo codice continuerà a funzionare senza problemi.

Domande Frequenti Sull’Hosting Autonomo di GitLab

C’è qualcos’altro che vuoi sapere riguardo l’ospitare autonomamente GitLab su un VPS? Di seguito trovi le risposte ad alcune domande frequenti.

GitLab CE è gratuito per l’auto-hosting?

Sì, GitLab CE è gratuito per l’auto-hosting sotto una licenza open-source in stile MIT. Non ci sono limiti di utenti e nessun prezzo per posto. Gli unici costi sono l’VPS stesso e il tempo operativo per mantenerlo.

Lo Stack 4 VPS di DreamHost è un punto di partenza ragionevole per la valutazione. I team di produzione tipicamente operano su Stack 8 o Stack 16.

Quanta RAM richiede realmente GitLab CE?

Programma 16 GB di RAM per fino a 1.000 utenti, che è la baseline pubblicata di GitLab (circa 20 richieste al secondo). I team più piccoli possono funzionare con meno, fino a un minimo documentato di 2 GB più 1 GB di swap per la valutazione. In ogni caso, se esegui pipeline CI/CD sulla stessa macchina, pianifica per 16 GB.

Posso ospitare autonomamente GitLab su un VPS da 4 GB?

Sì, puoi eseguire GitLab CE su 4 GB, ma sarà lento sotto qualsiasi carico reale. GitLab documenta un fallback di 2 GB + 1 GB di swap per ambienti con limitazioni di memoria — quel percorso è per la valutazione, non per la produzione. Per un team che spinge attivamente codice ed esegue pipeline, 8 GB è il minimo pratico.

Quanto tempo ci vuole per installare GitLab CE su un VPS?

Ci vogliono circa 10-15 minuti per l’installazione del pacchetto, più all’incirca un’ora per la preparazione e il rafforzamento, quindi in totale circa 90 minuti dall’inizio alla fine. L’installazione stessa consiste principalmente nell’attendere la fase di riconfigurazione.

Il passaggio di rafforzamento, che richiede la disabilitazione della registrazione aperta, l’applicazione dell’autenticazione a due fattori e il blocco della creazione di progetti, impiega l’ora rimanente ed è obbligatorio per qualsiasi istanza di produzione.

È conveniente l’autogestione di GitLab per un team di cinque persone?

Probabilmente no, a meno che tu non abbia una ragione di privacy o conformità. GitLab.com Free copre fino a cinque utenti con progetti privati illimitati e 400 minuti al mese di CI/CD. Il tempo operativo dell’hosting autonomo supera il costo per postazione risparmiato per quella dimensione del team.

L’auto-ospitazione inizia a ripagarsi, in termini di costi puri, con circa 30+ utenti attivi.

Qual è la differenza tra GitLab CE e GitLab Community Edition?

GitLab CE e GitLab Community Edition sono lo stesso prodotto. CE è l’abbreviazione standard. Il termine “Self-Managed” si riferisce a dove lo esegui (la tua infrastruttura), non a quale edizione.

GitLab Community Edition è open-source. GitLab Enterprise Edition (EE) aggiunge funzionalità a pagamento sulla stessa base di codice.

In cosa si differenzia GitLab CE da GitLab EE?

GitLab CE è l’edizione gratuita e open-source. GitLab EE utilizza la stessa base di codice, oltre a funzionalità a pagamento che si attivano quando carichi un file di licenza.

La differenza pratica si riduce ai seguenti punti:

• CE è sotto licenza MIT e completamente funzionale. Controllo del codice sorgente, richieste di unione, problemi, CI/CD base, registro dei contenitori, tutto il necessario.
• EE aggiunge funzionalità aziendali dietro una licenza. Pensa a epici, framework di conformità avanzati, analitica del flusso di valore, regole di approvazione multiple e scansione avanzata della sicurezza. Secondo il confronto delle funzionalità autogestite di GitLab, la differenza è significativa soprattutto per le organizzazioni con processi formali di gestione dei cambiamenti.
• Puoi installare EE senza una licenza, e funziona come CE fino a quando non viene licenziata. È così che la maggior parte dei team si tutela contro la futura necessità di aggiornare.
• Non puoi declassare EE a CE in modo pulito. Pianifica di conseguenza.

Per la maggior parte dei team che si auto-ospitano, CE è sufficiente. Se il motivo è la privacy o il costo, le funzionalità di EE raramente modificano il calcolo.

Come mantengo aggiornata la mia istanza GitLab auto-ospitata?

Esegui `sudo apt update && sudo apt upgrade gitlab-ce` per applicare le patch di sicurezza. Una cadenza mensile è il minimo pratico per un’istanza di produzione. Crea sempre un backup prima di aggiornare.

È necessario effettuare gli aggiornamenti di versione principale in modo sequenziale: non è possibile saltare le versioni principali. Passare dalla versione 16.x alla 18.x richiede prima un aggiornamento alla 17.x, poi alla 18.x. Saltare una versione principale interromperà le migrazioni del database. Controlla sempre lo strumento di percorso di aggiornamento di GitLab prima di aggiornare e crea un backup immediatamente prima di ogni passaggio.

Dove si colloca DreamHost nel GitLab auto-ospitato?

L’Hosting VPS di DreamHost fornisce il server Linux con accesso Root su cui viene installato GitLab CE. Il piano Stack 16 (16 GB di RAM) soddisfa il requisito ufficiale di GitLab per fino a 1.000 utenti, con margine per pipeline CI/CD attive.