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.

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/):

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/<username>/<project>/settings/ci_cd (ovvero la sezione Settings -> CI / CD)

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 il runner è registrato per cui 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.

Ora non ci resta che aggiornare il nostro repository con una push oppure rieseguire una pipeline (dal menu CI/CD -> Pipelines -> Run Pipeline), seguendo tutte le operazioni attraverso il log messo 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!

Lascia una risposta

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati *

Utilizzando il sito, accetti l'invio dei cookies da parte nostra. Maggiori informazioni

Questo sito utilizza i cookies per fornire la migliore esperienza di navigazione possibile. Continuando ad utilizzarlo senza modificare le impostazioni o cliccando su "Accetta" acconsenti al loro utilizzo.

Chiudi