Introduzione

Nella precedente puntata è stato presentato il potente strumento DevOps chiamato GitLab, la sua installazione mediante container e la configurazione per l’accesso attraverso il protocollo HTTPS.

In questa nuova puntata verrà affrontata la creazione di un progetto poiché, in fondo, quello che GitLab sa fare meglio è proprio questo: gestire il ciclo di vita del software, utilizzando i principi DevOps come fondamento.

L’interfaccia di GitLab

Se la procedura descritta nel precedente articolo è stata completata con successo dovrebbe essere possibile accedere all’interfaccia di GitLab attraverso un indirizzo simile a https://gitlab.mmul.local presso il quale la prima cosa da fare è quella di scegliere una password per l’utenza amministrativa, in modo che sia possibile effettuare login mediante l’utente “root”.

L’interfaccia sarà quindi accessibile, con la possibilità di scegliere tra una serie di azioni preliminari necessarie ad inizializzare l’ambiente:

Prima di procedere alla creazione di un nuovo progetto, scopo principale di questo articolo, è bene predisporre un utente applicativo, verosimilmente il proprio utente personale, che gestirà i repository creati.

In questo modo verranno divise le competenze e l’utilizzo dell’utenza root sarà limitato alle operazioni amministrative.

Selezionando quindi “Add people” sarà possibile creare una nuova utenza. Da notare come sia impossibile selezionare una password, in quanto questa viene generata automaticamente da GitLab che si preoccupa poi di inviarla all’utente mediante email. Nell’installazione descritta il supporto email non è stato configurato, pertanto l’unica via possibile per effettuare il setup della password per l’utente è quella di, una volta creato, modificarlo nuovamente mediante tasto “Edit“.

A questo punto il campo password sarà compilabile:

Una volta salvati i cambiamenti per l’utente sarà possibile accedere all’interfaccia utilizzando lo username e la password appena impostate. Verrà chiesto un nuovo cambiamento di password (poiché la password, con l’operazione sopra, è stata di fatto resettata) e fatto questo l’utente sarà completamente operativo.

Un ultimo aspetto che tornerà utile nell’immediato è quello relativo alla chiave pubblica ssh: le iterazioni che verranno effettuate dall’utente creato attraverso Git saranno basate su ssh, pertanto nella sezione Settings -> SSH Keys sarà utilissimo aggiungere la propria chiave ssh pubblica:

Nel caso non si disponesse di una chiave pubblica sarà possibile generarla, mediante il comando ssh-keygen che genererà una coppia di file all’interno della cartella .ssh del proprio utente, il contenuto del file .pub sarà quello da riportare nella sezione illustrata dallo screenshot precedente.

Configurare un progetto in GitLab

Predisposta la modalità d’accesso è quindi il momento di creare il primo progetto, che verrà nominato “MyFirstProject”. La modalità per farlo è semplicissima: dal tasto “+” nel menù in alto selezionare “New project” e compilare i campi che appariranno nella schermata:

Alcuni dettagli rilevanti:

• Il “Project slug” è compilato sulla base del “Project name“, solo in minuscolo e senza eventuali caratteri non conformi alle url;
• “Visibility level” verrà impostato a Internal, in modo che il progetto possa essere accessibile da tutti gli utenti configurati all’interno di GitLab;
• Viene spuntato il flag di inizializzazione del repository, in modo che contenga inizialmente un file README e non sia completamente vuoto;

Dalla creazione in poi il progetto sarà quindi accessibile all’indirizzo https://gitlab.mmul.local/rasca/myfirstproject e sarà possibile, da una qualsiasi shell, effettuarne il clone. È verosimile però come, a meno di configurazioni aggiuntive, una qualsiasi operazione di clone sul repository https termini con un errore simile al seguente:

rasca@anomalia [~]> git clone https://gitlab.mmul.local/rasca/myfirstproject
 Cloning into 'myfirstproject'…
 fatal: unable to access 'https://gitlab.mmul.local/rasca/myfirstproject/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

L’errore è del tutto legittimo, ed è relativo alla natura del certificato self-signed, generato in precedenza per l’abilitazione del protocollo https.

Per risolvere questo problema bisognerà includere il certificato del server https gitlab.mmul.local all’interno del proprio sistema, scaricandolo:

rasca@anomalia [~]> echo -n | openssl s_client -connect gitlab.mmul.local:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > gitlab.mmul.local_443.crt
depth=0 CN = gitlab.mmul.local
verify error:num=18:self signed certificate
verify return:1
depth=0 CN = gitlab.mmul.local
verify return:1
DONE

Ed aggiungendolo ai certificati disponibili nel sistema (in questo caso la distribuzione utilizzata è di tipo Debian/Ubuntu):

rasca@anomalia [~]> sudo mv gitlab.mmul.local_443.crt /usr/local/share/ca-certificates/
rasca@anomalia [~]> sudo update-ca-certificates 
Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...

Adding debian:gitlab.mmul.local_443.pem
done.
done.

In questo modo la CA autogenerata di GitLab verrà riconosciuta come valida e sarà possibile clonare il repository senza avere errori:

rasca@anomalia [~]> git clone https://gitlab.mmul.local/rasca/myfirstproject
Cloning into 'myfirstproject'...
Username for 'https://gitlab.mmul.local': rasca
Password for 'https://rasca@gitlab.mmul.local': 
warning: redirecting to https://gitlab.mmul.local/rasca/myfirstproject.git/
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.

Esiste però una modalità più rapida per ovviare all’abilitazione dei certificati (ed al dover immettere costantemente i dati di accesso). Essendo già stata abilitata tanto l’utenza quanto la sua chiave pubblica, sarà possibile effettuare il clone direttamente mediante accesso ssh:

rasca@anomalia [~]> git clone ssh://git@gitlab.mmul.local:2222/rasca/myfirstproject
Cloning into 'myfirstproject'...
The authenticity of host '[gitlab.mmul.local]:2222 ([127.0.1.1]:2222)' can't be established.
ECDSA key fingerprint is SHA256:0mscb00vJJBmhTka/1HJwI7fNo6OFU6HEhooF8U+e1s.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[gitlab.mmul.local]:2222' (ECDSA) to the list of known hosts.
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (3/3), done.

Alcune precisazioni sul comando descritto:

• L’indirizzo utilizzato fa riferimento al nome configurato nel precedente articolo nel file /etc/hosts ed alla porta 2222 mappata mediante docker alla porta 22 del container, cioè l’istanza GitLab stessa;
• Lo username utilizzato per la connessione ssh è (e sempre sarà, per qualsiasi repository configurato) semplicemente “git“. La discriminante sarà costituita chiaramente dalla chiave dell’utente “chiamante”, in questo caso rasca;

Una volta completato il comando si avrà quindi a disposizione una cartella “myfirstproject” contenente la copia del progetto presente in GitLab:

rasca@anomalia [~]> cd myfirstproject/
rasca@anomalia [~/myfirstproject]> ls -la
total 16
drwxrwxr-x  3 rasca rasca 4096 ago 29 18:36 .
drwxr-xr-x 63 rasca rasca 4096 ago 29 18:36 ..
drwxrwxr-x  8 rasca rasca 4096 ago 29 18:36 .git
-rw-rw-r--  1 rasca rasca   18 ago 29 18:36 README.md

Il primo commit

Ora che il repository è localmente accessibile sarà possibile effettuare la prima modifica, simulando operatività classica.

Il progetto idealmente conterrà della documentazione composta da più file markdown, quindi con estensione “.md“, pertanto il primo commit di test riguarderà il file MyFirstFile.md:

rasca@anomalia [~/myfirstproject]> echo "This is my first documentation file" > MyFirstFile.md

Lo stato del repository git sarà quindi:

rasca@anomalia [~/myfirstproject]> git status
On branch master
Your branch is up to date with 'origin/master'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	MyFirstFile.md

nothing added to commit but untracked files present (use "git add" to track)

Infine il commit seguirà il normale flusso operativo di git:

rasca@anomalia [~/myfirstproject]> git add .
rasca@anomalia [~/myfirstproject]> git commit -m "First file of my documentation project"
[master 34400af47fe0] First file of my documentation project
 1 file changed, 1 insertion(+)
 create mode 100644 MyFirstFile.md

Ultima operazione, il push delle modifiche verso il repository remoto:

rasca@anomalia [~/myfirstproject]> git push
Counting objects: 3, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 337 bytes | 337.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To ssh://gitlab.mmul.local:2222/rasca/myfirstproject
   68b961048bd0..34400af47fe0  master -> master

Come è facile notare dall’output illustrato non è stata richiesta alcuna password o informazione di login. Questo perché, in fase di clone, è stata utilizzata la modalità ssh che si basa sulla chiave pubblica dell’utente utilizzato per il commit.

A cose fatte lo stato del repository sull’interfaccia web di GitLab mostrerà qualcosa di simile a questo:

La schermata è densa di informazioni:

• Il progetto ha due commit, il primo era implicito nella creazione del file README.md, il secondo è quello appena effettuato;
• Il progetto ha un solo branch (chiaramente master) e nessun tag;
• Il commit appena effettuato, “First file of my documentation project”, ha identificativo 34400af4 e cliccandone la descrizione è possibile accedere al dettaglio;
• Il banner arancione in alto recita “The Auto DevOps pipeline has been enabled and will be used if no alternative CI configuration file is found.” per ora può essere tranquillamente dismesso, verrà affrontato nella prossima puntata della serie, quando si inizierà a parlare di CI;

Missione compiuta, il commit è ora parte del progetto.

Gestire le issue ed il ciclo di vita

Come ampiamente anticipato, già a questo livello GitLab consente di gestire totalmente il ciclo di vita del software in tutti i suoi aspetti. Ad esempio le issue, che possono essere aperte da tutti quanti hanno accesso al progetto ed assegnate a specifiche persone che ne cureranno l’evoluzione.

Quando un utente riscontra un’anomalia nel progetto, dopo aver cliccato sulla voce “Issue” nel menù a sinistra potrà creare una nuova segnalazione:

Dalla schermata apposita è quindi possibile descrivere la problematica, assegnarla, definire una scadenza ed associare l’issue a due distinti oggetti strettamente correlati alla metodologia DevOps:

• Milestone: definibile a parte (sempre dal menù di sinistra) e rappresenta il risultato dei cosiddetti sprint, ossia brevi cicli di sviluppo destinati a specifiche evoluzioni del progetto. La domanda è quindi più che lecita: le milestone possono corrispondere a delle release del progetto? La risposta è sì, possono;
• Labels: definibile come le milestone ed utile per correlare più issue ad uno stesso ambito, oltre che logicamente anche visivamente in quanto ad ogni label è associabile un colore. Esistono due tipi principali di label associabili ai gruppi ed ai progetti.

Una volta creata la issue questa seguirà la sua storia, con i suoi commenti e le sue contribuzioni. Idealmente una issue termina con quella che viene definita una “merge request” ossia la richiesta da parte di uno sviluppatore dell’integrazione del proprio commit (o della propria serie di commit presente in uno specifico branch) nel progetto.

Conclusioni

È bastato accennare alle specifiche parole chiave del mondo DevOps per rendere l’articolo da lineare e semplice ad articolato e ricco di possibilità di studio. Ed è quello che ci auguriamo: in attesa della prossima puntata (nella quale parleremo di CI e di GitLab Runner) i temi da approfondire certo non mancano.

Buon approfondimento!