Server dedicati per GitLab™
GitLab autogestito e runner CI/CD su bare metal
Esegui GitLab Self-Managed su un server dedicato con storage NVMe e sposta i job CI/CD su server runner separati connessi tramite una VLAN privata. Gli stessi server runner funzionano sia per GitLab Runner sia per i runner self-hosted di GitHub Actions.
GITLAB è un marchio di GitLab Inc. negli Stati Uniti e in altri paesi e regioni.
-
Archiviazione NVMe per i repository -
CPU ad alta frequenza per build CI -
Private VLAN a 10–25 Gbit/s -
Accesso root e IP-KVM
AMD Zen 5 fino a 5,7 GHz
Traffico illimitato
Unità NVMe enterprise
Memoria DDR5 ECC
Requisiti hardware di GitLab e GitLab Runner
La configurazione di base per un'istanza GitLab a nodo singolo è 8 vCPU e 16 GB di memoria – una CPU a 4–6 core con 8–12 thread su un server dedicato. Lo swap sotto carico rallenta GitLab, quindi 32 GB lasciano spazio ai job in background e alla crescita.
Pianifica 40 GB per il sistema e PostgreSQL, più le dimensioni complete di tutti i repository. Gitaly, il servizio dei repository, è intensivo in termini di I/O e necessita di storage SSD invece di file system di rete, quindi due unità NVMe in RAID 1 sono la configurazione standard.
Le istanze e i dischi cloud burstable sono poco adatti a GitLab: la loro velocità diminuisce una volta esaurita la quota di utilizzo. Un server dedicato non ha quote né vicini sullo stesso hardware, quindi i suoi core e le unità NVMe non vengono mai limitati da un provider.
I job CI/CD è meglio eseguirli su un server separato anziché sull’istanza GitLab. Una build pesante non può quindi rallentare Git, l’interfaccia web o le revisioni del codice, e il codice della pipeline non viene mai eseguito accanto ai tuoi repository.
I compilatori, i test e le build delle immagini si basano sulla velocità di un singolo core, quindi una frequenza elevata riduce la durata di ogni lavoro, mentre i core determinano quanti lavori possono essere eseguiti in parallelo. Ogni lavoro necessita della propria memoria, e i layer di Docker e le cache risiedono sull’NVMe del runner.
I runner prelevano codice, immagini e artefatti dall’istanza tramite una VLAN privata fino a 25 Gbit/s: un’immagine Docker completa arriva in pochi secondi, non in minuti. La porta pubblica resta libera per il tuo team: i push Git, le richieste di merge e l’interfaccia web non restano mai in attesa dietro una pipeline.
Prezzi dei server dedicati per GitLab e runner
Visualizza tutte le configurazioni
Noleggia un server dedicato per GitLab
da INTROSERV
Come ordinare un server dedicato
Seleziona una configurazione, aggiungi unità NVMe, scegli il sistema operativo, attendi che il server sia pronto e installa GitLab.
Leggi la documentazione
Installa e proteggi un'istanza GitLab a singolo nodo
Installazione passo passo di GitLab Self-Managed dal pacchetto Linux ufficiale, con HTTPS e il primo accesso.
Leggi il tutorialServer e infrastruttura per GitLab da un unico fornitore
-
1
Installa GitLab sul server dell'istanza
Installa GitLab Self-Managed dal pacchetto Linux ufficiale su storage NVMe, con PostgreSQL e Redis inclusi. Quindi configura HTTPS, l'email in uscita e il registry dei container.
-
2
Collega i server runner tramite la VLAN
Ordina server runner nello stesso data center e collegali a una VLAN privata fino a 25 Gbit/s. I job scaricano codice, immagini e artefatti tramite la VLAN, non tramite la porta pubblica.
-
3
Registra i corridori
Installa GitLab Runner con l'executor Docker e registralo nella tua istanza. Per i repository su GitHub, gli stessi server eseguono runner self-hosted di GitHub Actions.
-
4
Esegui il backup con il servizio di backup INTROSERV
Esegui il backup dell'intero server istanza con il servizio di backup INTROSERV – software NAKIVO e spazio di archiviazione in un unico servizio pronto all'uso. Ripristina l'intero server o un singolo file quando necessario.
Passando da GitLab.com a un’installazione self-hosted?
Licenza e supporto di GitLab
Licenza
GitLab Enterprise Edition è l’installazione consigliata: senza licenza funziona con il livello gratuito, e Premium o Ultimate si sbloccano in seguito con un codice di attivazione, senza bisogno di reinstallare. Community Edition è l’alternativa open source sotto licenza MIT, con le stesse funzionalità gratuite. Gli abbonamenti sono venduti da GitLab Inc. o dai suoi partner, non da INTROSERV.
Supporto
Il supporto per GitLab stesso proviene dal forum e dalla documentazione di GitLab, oppure da GitLab Inc. con un abbonamento a pagamento. INTROSERV si occupa dei server Linux su cui gira GitLab: monitoraggio, sicurezza, aggiornamenti del sistema operativo e risoluzione degli incidenti con un piano di gestione del server, e attività una tantum come amministrazione di sistema a tariffa oraria.
FAQ
-
Quanto velocemente viene consegnato il server?
Le configurazioni istantanee sono pronte entro 3-6 ore dal pagamento; le configurazioni personalizzate di solito richiedono fino a 24 ore. Il tempo di consegna è indicato per ogni configurazione nel catalogo.
-
Il server può essere testato prima?
Sì. È disponibile un periodo di prova a pagamento fino a 5 giorni, sufficiente per installare GitLab, caricare un repository ed eseguire la prima pipeline.
-
Quale sistema operativo dovrei scegliere?
Una distribuzione Linux supportata dal pacchetto ufficiale di GitLab, come Ubuntu LTS o Debian. Il pacchetto include PostgreSQL, Redis e il server web, quindi il sistema non richiede nient’altro installato.
-
Posso usare il mio dominio e il mio certificato HTTPS?
Sì. Punta un record DNS al server e il pacchetto GitLab può richiedere e rinnovare autonomamente un certificato Let's Encrypt. È possibile installare invece un certificato di un'altra autorità.
-
GitLab Pages può essere eseguito sullo stesso server?
Sì. Pages funziona come un servizio separato e necessita di un record DNS wildcard. Anche i domini personalizzati per Pages necessitano di un secondo indirizzo IP, che può essere aggiunto al server.
-
Cosa succede quando si guasta un’unità NVMe?
Con due unità in RAID 1, GitLab continua a funzionare sull'unità rimanente. Apri un ticket di supporto, INTROSERV sostituisce l'unità nel data center e l'array viene ricostruito.
-
È possibile aggiungere altri runner server in seguito?
Sì. Ordina un altro server runner nello stesso data center, aggiungilo alla VLAN esistente e registralo con la tua istanza. Le pipeline inizieranno a usarlo non appena sarà online.
-
È possibile espandere lo spazio di archiviazione in seguito?
Sulle configurazioni DC1, DC2 e DC3, sì: le unità per gli slot liberi vengono aggiunte tramite un ticket di assistenza e il prezzo mensile cambia di conseguenza. Per le altre configurazioni, è meglio scegliere al momento dell'ordine un layout dei dischi con un certo margine di capacità.
