Hosting GitLab Runner, su una macchina che è vostra
Un runner autogestito a Praga o Covilhã con tutto il disco per sé, così la cache dei layer Docker è ancora lì alla seconda pipeline della giornata e la fattura non si muove quando si muove la build.
Per chi è
Un team che compra minuti di calcolo
La suite di test è cresciuta, quindi la pipeline si è allungata, quindi la fattura è salita - e l'unica leva che il piano offre è comprare ancora più esattamente degli stessi minuti.
Una pipeline che vuole due volte la stessa macchina
Ogni job parte da un disco vuoto. L'immagine di base viene scaricata di nuovo, le dipendenze vengono recuperate di nuovo, e caricare la cache dura più a lungo del passo che avrebbe dovuto far risparmiare.
Un repository soggetto a una regola di residenza
Il codice, gli artefatti e le chiavi di deploy passano tutti dal runner, e "una flotta condivisa, da qualche parte" è la risposta che il vostro auditor continua a cerchiare in rosso.
Che cosa vi restituisce un runner autogestito
- Una cache dei layer Docker calda su NVMe locale, così la seconda pipeline della giornata riparte da dove è finita la prima invece che da un disco vuoto.
- Qualsiasi executor vogliate - docker, shell, docker-autoscaler, instance o kubernetes - scelto per runner anziché assegnato da un piano.
- La vostra parallelizzazione, impostata come numero in config.toml invece di comprata come scalino successivo.
- La modalità privilegiata quando vi serve davvero Docker-in-Docker, cosa che nessuna flotta condivisa vi darà mai.
- Un IPv4 statico in uscita da AS204057, così una destinazione di deploy, un mirror di pacchetti o il firewall di un database può autorizzare il runner per indirizzo.
- Quello che la build serve davvero sull'host: una toolchain vecchia, un SDK con licenza, o un set di fixture che nessuno vuole scaricare una volta per job.
Dimensionato su quello che la pipeline fa davvero
GitLab non pubblica requisiti hardware per il runner in sé, e non è una dimenticanza: il processo del runner è piccolo, la build no. Il numero che conta è il job. Partite dal job più pesante che eseguite oggi, moltiplicate per la parallelizzazione che volete e siate generosi col disco - la cache dei layer e lo spazio di lavoro sono ciò che lo riempie, e un disco pieno fa fallire una pipeline in un modo che sembra un test rotto. Una cosa che un host mensile fisso non fa è sparire in una settimana tranquilla: i minuti ospitati non costano nulla quando nessuno fa push, e questo costa lo stesso. Conviene dal punto in cui la pipeline gira quasi tutti i giorni.
Come installare GitLab Runner su un host nuovo
Debian o Ubuntu, da un server pulito, nell'ordine in cui GitLab lo documenta. Tutto quanto segue è la loro sequenza, non la nostra.
-
Aggiungere il repository ufficiale dei pacchetti
curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" -o script.deb.sh less script.deb.sh sudo bash script.deb.shGitLab distribuisce il repository come script di installazione e chiede di leggerlo prima di eseguirlo: per questo le loro stesse istruzioni lo scaricano prima invece di passarlo direttamente a una shell.
-
Installare il runner
sudo apt install gitlab-runnerIl pacchetto crea un utente di sistema gitlab-runner la cui home viene creata vuota, senza file di skeleton. Per fissare una versione, installate gitlab-runner e gitlab-runner-helper-images insieme nella stessa versione - dalla 17.7.1 vanno in coppia, e nominarne uno solo fallisce con un errore di dipendenze.
-
Installare Docker, se i job girano in container
sudo apt install docker.io sudo systemctl enable --now dockerL'executor docker parla con un Docker Engine locale tramite API v1.25, quindi il demone deve stare sull'host del runner stesso. Il pacchetto della distribuzione basta per iniziare; il repository di Docker porta le versioni più recenti se una build ne ha bisogno.
-
Registrare il runner
sudo gitlab-runner register \ --non-interactive \ --url "https://gitlab.com/" \ --token "$RUNNER_TOKEN" \ --executor "docker" \ --docker-image alpine:latest \ --docker-pull-policy "if-not-present" \ --description "docker-runner"Create prima il runner in GitLab, sotto Settings, poi CI/CD, poi Runners: vi restituisce un token di autenticazione che comincia con glrt- e va in --token. I tag del job e l'opzione per i job senza tag si impostano in quello stesso modulo: con i token di autenticazione appartengono al runner, non al comando register. Il vecchio flusso con --registration-token è deprecato e previsto per la rimozione in GitLab 20.0.
-
Impostare la parallelizzazione e avviarlo
sudo sed -i "s/^concurrent = .*/concurrent = 4/" /etc/gitlab-runner/config.toml sudo gitlab-runner restart sudo gitlab-runner statusconfig.toml si trova in /etc/gitlab-runner quando il runner gira come root. concurrent è un tetto su tutti i runner registrati su questo host, non un'impostazione per runner, e ogni runner può portare sotto un proprio limite più basso.
-
Verificarlo con un job
stages: [test] smoke: stage: test tags: [docker-runner] script: - cat /etc/os-release - echo "built on $CI_RUNNER_DESCRIPTION"Fate il commit come .gitlab-ci.yml, fate push, e il job dovrebbe atterrare sul vostro host in pochi secondi. Se resta in coda, i tag non corrispondono a quelli impostati nell'interfaccia, oppure il runner è vincolato a un altro progetto.
Verificato sulla documentazione ufficiale il 2026-08-15 — leggi la fonte
Cosa non siamo
- Non siamo GitLab. GitLab, GitLab CI/CD e GitLab Runner sono loro, e nulla in questa pagina è approvato da loro. Quello che vendiamo è la macchina su cui gira un runner.
- Questa pagina non parla di ospitare GitLab stesso. Un'istanza GitLab autogestita è una macchina più grande e un discorso diverso - chiedete e la dimensioniamo, ma non è ciò che qui ha un prezzo.
- Non scriviamo il vostro .gitlab-ci.yml. La pipeline è vostra; l'host, la rete e l'indirizzo sono nostri.
- Il runner non viene gestito per voi se non lo chiedete. Lo installate voi, oppure aggiungete il nostro servizio di amministrazione e lo teniamo aggiornato, registrato e sorvegliato.
- Il vostro abbonamento GitLab resta di GitLab. Un runner autogestito non consuma i loro minuti di calcolo, ed è il punto, ma non sostituisce nemmeno le licenze utente.
Le parti che i team scoprono in ritardo
- Il flusso con il token di registrazione è in uscita di scena. Un runner creato nell'interfaccia restituisce un token di autenticazione glrt- che gitlab-runner register accetta come --token, e --registration-token è previsto per la rimozione in GitLab 20.0.
- I tag lo hanno seguito. Con un token di autenticazione, i tag del job, l'opzione senza tag e il vincolo appartengono all'oggetto runner creato nell'interfaccia, quindi le opzioni che una volta li impostavano da riga di comando non decidono più nulla.
- Fissare una versione significa fissare due pacchetti. Dalla 17.7.1, una versione esplicita di gitlab-runner richiede anche gitlab-runner-helper-images nella stessa versione, altrimenti apt rifiuta l'installazione.
- check_interval è a 3 secondi per impostazione predefinita. Su un host con molti runner registrati è moltissimo polling; alzatelo prima di dare la colpa alla rete.
- Docker-in-Docker richiede la modalità privilegiata, che di fatto consegna al job il root dell'host. Se la pipeline costruisce solo immagini, un builder senza root come Kaniko o Buildah è lo scambio più conveniente.
- Artefatti e cache continuano a viaggiare verso GitLab finché non puntate la cache al vostro bucket compatibile con S3. Su un runner che avete spostato nell'UE apposta, quello è di solito l'ultimo salto rimasto da spostare.
Minuti di CI ospitati contro un runner vostro
| Minuti di CI ospitati dal fornitore | Un runner su DCXV | |
|---|---|---|
| Che cosa pagate | Ogni minuto di ogni job, finché il progetto esiste | Un host mensile fisso, qualunque cosa faccia la pipeline quel mese |
| Una build che rallenta | Costa di più ogni mese in cui resta lenta | Non costa nulla in più - la macchina è già pagata |
| Cache dei layer Docker | Fredda a ogni job, se non la caricate e la riscaricate voi stessi | Calda su NVMe locale, tra i job e tra i giorni |
| Parallelizzazione | Uno scalino di piano che si aumenta | Un numero che impostate nel vostro file di configurazione |
| Dove atterra il checkout | Una flotta condivisa, spesso in una regione che non potete fissare | Una macchina a Praga o Covilhã, con contratto cipriota |
| Indirizzo in uscita | Un vasto intervallo condiviso che nulla può autorizzare | Un IPv4 statico da AS204057, vostro da autorizzare |
| Che cosa può contenere la macchina | Quello che l'immagine del runner porta per caso | Qualsiasi toolchain, licenza o set di fixture installato una volta sola |
Come si mette in moto sul vostro host
Diteci che cosa fa la pipeline
Il job più pesante che eseguite oggi, quanti ne volete in parallelo e se costruisce immagini di container. Basta questo per dimensionare un host senza tirare a indovinare.
Vi consegniamo la macchina
Praga o Covilhã, accesso root e un IPv4 statico, in meno di dieci minuti. Portate la vostra immagine se il runner è già dentro.
Seguite la procedura di questa pagina
È la sequenza del produttore, presa dalla sua documentazione attuale e non da un post di blog, e su un host pulito richiede pochi minuti.
Fate uno snapshot, poi aggiungete il secondo
Fate uno snapshot appena la prima pipeline è verde, così la macchina successiva è un ripristino e non una ricostruzione. Un pool cresce aggiungendo host, non rendendone uno enorme.
Perché sceglierci
- Strutture certificate Tier III, SLA della struttura 99,982 %
- Rete propria, AS204057, IPv4 e IPv6
- Supporto 24/7/365 con circa 10 minuti di risposta media
- Società cipriota, giurisdizione UE, conforme al GDPR dal 2007
FAQ
- Qual è la differenza tra un runner condiviso e uno autogestito?
Un runner condiviso è la macchina di GitLab e voi pagate i minuti che dedica al vostro job. Un runner autogestito è la vostra macchina: ci installate gitlab-runner, lo registrate sul vostro progetto, gruppo o istanza, e non consuma alcun minuto di calcolo. I namespace del piano gratuito di GitLab ricevono 400 minuti di calcolo al mese, e una pipeline attiva li consuma in pochi giorni
- Come installo e registro GitLab Runner?
Aggiungete il loro repository apt dallo script di installazione su packages.gitlab.com, installate il pacchetto gitlab-runner, poi eseguite gitlab-runner register in modalità non interattiva con il token di autenticazione che GitLab vi dà quando create il runner nell'interfaccia. La sequenza completa con i comandi esatti è su questa pagina, presa dalla loro documentazione e non da un post di blog
- Un runner si registra ancora con il token di registrazione?
No, ed è il cambiamento che rompe la maggior parte delle guide vecchie. Create prima il runner nell'interfaccia GitLab e vi restituirà un token di autenticazione che comincia con glrt-, che gitlab-runner register accetta come --token. Il vecchio flusso con --registration-token è deprecato e previsto per la rimozione in GitLab 20.0. I tag del job, l'opzione senza tag e il vincolo appartengono ora all'oggetto runner creato nell'interfaccia, non al comando register
- Che dimensione di server serve a un GitLab Runner?
GitLab non pubblica requisiti hardware per il runner in sé, perché il processo del runner è piccolo e la vostra build no. Dimensionate sul job più pesante moltiplicato per la parallelizzazione che volete. In pratica 4 vCPU, 8 GB e 120 GB di NVMe reggono due o tre job alla volta; 8 vCPU, 16 GB e 240 GB ne reggono da sei a otto. Siate generosi col disco - la cache dei layer Docker e lo spazio di lavoro sono ciò che lo riempie
- Mi serve Docker sull'host del runner?
Solo se usate l'executor docker, come fa quasi tutti. Parla con un Docker Engine locale tramite API v1.25, quindi il demone deve essere installato sull'host del runner stesso. L'executor shell non ha bisogno di Docker, e gli executor instance e docker-autoscaler creano macchine altrove
- Più runner possono condividere un host?
Sì, ed è la forma normale. Registratene quanti volete sulla stessa installazione; l'impostazione concurrent in /etc/gitlab-runner/config.toml è un tetto complessivo, e ogni runner può portare sotto un proprio limite più basso. Attenzione a check_interval, che è a 3 secondi per impostazione predefinita e diventa moltissimo polling appena un host porta una dozzina di runner
Se hai bisogno di assistenza o hai domande aggiuntive, contatta i manager o scrivi al team di supporto a support@dcxv.com
Pronto per iniziare?
Fatturazione mensile, nessun costo di attivazione, nessun vincolo