Installiamo un runner personalizzato per GitLab
Una delle caratteristiche più interessanti di GitLab è la disponibilità di un sistema di CI/CD (Continuous Integration / Continuous Delivery) da tempi immemorabili, a cui si aggiunge la possibilità di avere infiniti repository privati.
Ok, ma anche altri provider come Bitbucket o GitHub consentono di fare le stesse cose o quasi.
Perchè dovrei scegliere GitLab?
Perchè tra le altre cose offre la possibilità di installare l'intera infrastruttura sui propri server, in locale o nel cloud, avendo in tutto e per tutto il controllo dei propri dati. E senza dover imparare ad usare un tool differente.
Ma torniamo all'oggetto del post.
Per utilizzare le funzionalità descritte abbiamo bisogno di predisporre un file .gitlab-ci.yml in cui descrivere i job che desideriamo eseguire.
La sola presenza di questo file attiverà il processo di CI/CD ad ogni push sul repository.
Una descrizione dettagliata va oltre lo scopo di questo post, quindi ne parleremo in un'altra occasione.
Inoltre ci server un Dockerfile per impacchettare la nostra applicazione e simulare un ambiente di produzione. In fin dei conti l'obiettivo è assicurarci che tutto funzioni correttamente e non avere brutte sorprese quando rilasceremo il codice.
Il lavoro sporco viene svolto dai runner che lo stesso GitLab mette a disposizione.
Sono appunto definiti shared runner perchè condivisi tra tutti gli utenti.
Ciò rappresenta una limitazione perchè potrebbero crearsi dei colli di bottiglia in presenza di un elevato carico di lavoro da parte dell'intero sistema. Se non ci sono runner disponibili il nostro task può essere posticipato, i tempi di completamento possono allungarsi sensibilmente e così via.
Se a questo aggiungiamo il fatto che nel piano free sono disponibili solo (si fa per dire) 2000 minuti di elaborazione al mese, ecco che potrebbe risultare utile predisporre un proprio runner personalizzato.
Dunque mettiamoci all'opera.
Per prima cosa abbiamo bisogno di un server Ubuntu (la scelta non è obbligatoria ma l'utilizzo degli snap semplifica l'installazione di Docker) su una macchina locale o su un VPS.
Nel mio caso ho utilizzato il prodotto entry level di Hetzner con 1 CPU e 1 GB di RAM, caratteristiche più che sufficienti per il test.
In coda all'articolo c'è un link per provare gratuitamente il servizio
Ognuno può scegliere la configurazione più idonea alle proprie esigenze considerando
- carico di lavoro previsto (numero di progetti da gestire)
- numero di build giornaliere
- tempi medi di esecuzione delle build (più è potente la macchina meno tempo occorrerà per terminare il task)
- numero di utenti
- varie ed eventuali
Cominciamo installando il runner
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash sudo apt-get install gitlab-runner
ed avviamo il servizio
sudo gitlab-runner start
Ora dobbiamo registrare la pipeline con
sudo gitlab-runner register
e rispondere ad ad alcune domande di seguito riportate (in neretto la risposta da fornire)
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
Please enter the gitlab-ci token for this runner:
in questo caso dobbiamo recuperare il token associato al nostro progetto visitando il link https://gitlab.com/
Please enter the gitlab-ci description for this runner:
inseriamo una qualsiasi descrizione o lasciamo il campo vuoto
Please enter the gitlab-ci tags for this runner (comma separated):
possiamo anche lasciare il campo vuoto
Please enter the executor: ssh, virtualbox, kubernetes, docker, docker-ssh, shell, docker+machine, docker-ssh+machine, custom, parallels:
shell
In sostanza abbiamo impostato il sito di GitLab come coordinatore in modo che ad ogni push sia quest'ultimo ad avviare la procedura servendosi del runner personalizzato.
Chiaramente se si dispone di una infrastruttura on premise andremo ad indicare l'indirizzo della macchina su cui è presente GitLab CE.
Ora che il runner è registrato passiamo all'installazione di Docker che possiamo effettuare facilmente con
sudo snap install docker
Impostiamo i permessi necessari creando un gruppo docker
sudo groupadd docker
e aggiungendo il nostro utente a tale gruppo
sudo usermod -aG docker $USER
Riavviamo con
reboot
poi eseguiamo nuovamente il login ed aggiungiamo al gruppo docker anche il runner
sudo usermod -aG docker gitlab-runner
Quest'ultimo va inserito anche nella lista degli utenti con privilegi di root, modificando il relativo file con
sudo nano /etc/sudoers
In coda al file aggiungiamo la seguente riga
gitlab-runner ALL=(ALL) NOPASSWD: ALL
Salviamo e chiudiamo l'editor.
Siamo quasi arrivati alla fine della procedura.
Apriamo il file di configurazione del runner con
sudo nano /etc/gitlab-runner/config.toml
ed aggiungiamo il blocco
[runners.ssh] user = "<SERVER ACCOUNT USERNAME>" host = "<SERVER IP ADDRESS>"
dove username e ip address fanno riferimento proprio alla macchina su cui gira il runner.
A questo punto aggiorniamo il nostro repository con una push oppure avviamo manualmente la pipeline (dal menu CI/CD -> Pipelines -> Run Pipeline), seguendo tutte le operazioni attraverso i log messi a disposizione da GitLab.
Non resta altro che provare sul campo.
Un suggerimento? Mettiamo tutto in uno script per automatizzare ulteriormente la procedura.
Alla prossima!
CODICI SCONTOUtilizzate il seguente link per ottenere un credito free di $200 su DigitalOcean da spendere in 60 giorni Utilizzate il seguente link per ottenere un credito free di €20 su Hetzner
[VIDEO]
[LINKS]
Soluzioni personalizzate per le vostre esigenze
