Come ospitare un repository di immagini Docker e creare immagini Docker con un'istanza GitLab Self-Managed su Ubuntu 20.04

Tecnologia di containerizzazione ha fatto grandi progressi nello spazio tecnologico dello sviluppo software come metodo più accettato per il packaging e il deployment di applicazioni in ambienti cloud. Ciò è stato reso necessario dall'esigenza di integrazione continua (CI) e deployment continuo (CD), che sono aspetti caratterizzanti di DevOps. Gli sviluppatori e gli ingegneri software utilizzano i container per realizzare l'aspetto CI/CD dell'architettura software. Un container è essenzialmente una piattaforma informatica portatile, completamente pacchettizzata e autosufficiente. Sebbene esistano diverse piattaforme di container sul web, Docker risulta essere la più comune.

Docker è una piattaforma di container open-source che rende lo sviluppo efficiente e prevedibile. Docker offre un repository pubblico di immagini Docker disponibile su Docker Hub. Contiene molte immagini Docker open-source per le implementazioni più comuni che puoi scaricare e utilizzare. Poiché si tratta di un repository pubblico, sei anche libero di aggiungere le tue immagini Docker da condividere con il pubblico. Se invece possiedi codice privato/proprietario, potresti dover pagare per un repository di immagini privato o creare il tuo servizio di repository di immagini. È qui che entra in gioco GitLab.

GitLab è un repository Git basato sul web che è molto più di un semplice strumento di controllo versione. Fornisce strumenti DevOps per l'integrazione e il deployment continui, il tracciamento dei problemi (issue-tracking), registri di immagini Docker e altro ancora. Offre tre opzioni: GitLab Community Edition (CE), GitLab Enterprise Edition (EE) e GitLab SaaS. GitLab CE e GitLab EE sono soluzioni autogestite che ti consentono di scaricare, installare e gestire autonomamente l'istanza di GitLab. GitLab SaaS è ospitato da GitLab Inc. e non devi preoccuparti di installare nulla per utilizzarlo.

In un precedente tutorial, ti abbiamo mostrato come configurare un'istanza GitLab su un server CloudSigma e ospitare il tuo repository Git. Ti abbiamo anche mostrato come implementare pipeline di integrazione continua con GitLab runner per compilare ed eseguire automaticamente i tuoi test ogni volta che c'è un nuovo commit. Se non hai seguito i tutorial menzionati, ti invitiamo a farlo poiché costituiscono le basi per questo tutorial.

In questo tutorial, mostreremo come creare una semplice immagine Docker e ospitarla con un'istanza self-hosted di GitLab (sia che tu stia utilizzando la Community Edition o la Enterprise Edition – la sequenza dei passaggi è la stessa).

Prerequisiti

Per seguire ogni passaggio di questo tutorial, assicurati di avere un GitLab CI runner e un server GitLab self-hosted come spiegato di seguito.

1. Un server GitLab sicuro

Lo useremo per memorizzare il codice sorgente, eseguire attività CI/CD e ospitare il registro delle immagini Docker. Dovresti avere un server con almeno 2 CPU core e 4GB di RAM come raccomandato da GitLab per installare un'istanza GitLab autogestita. Avrai anche bisogno di un nome di dominio registrato da puntare al server, poiché lo utilizzeremo per ottenere un certificato SSL da Let’s Encrypt per proteggere il server. Di seguito sono riportati alcuni link che puoi seguire per configurare un'istanza self-hosted di GitLab.

• Registra un nome di dominio con un registrar di tua scelta e puntalo su CloudSigma.
• Segui questo tutorial per la configurazione iniziale del server Ubuntu, aggiungere un utente non root, e abilitare il firewall UFW di Ubuntu.
• Enfin, segui questo tutorial per installare e configurare un'istanza GitLab self-hosted.

2. Un GitLab CI runner

Un GitLab CI runner è necessario per eseguire job automatizzati sui tuoi casi di test. Il tutorial su come configurare le pipeline di integrazione continua di GitLab su Ubuntu 20.04 ti offre una panoramica del server GitLab CI e ti mostra come attivare i job. Segui i passaggi nel tutorial per configurare il servizio GitLab CI runner se non l'hai fatto. Il tutorial include un' app demo Node.js con casi di test – la utilizzeremo in questo tutorial.

Ora iniziamo!

Passo 1: Configurazione di un GitLab CI Runner privilegiato

Nel tutorial su come configurare un GitLab CI Runner, abbiamo configurato un runner GitLab utilizzando il comando sudo gitlab-runner register comando che ci ha permesso di aggiungere in modo interattivo i parametri richiesti. Sebbene questo abbia funzionato per il nostro caso d'uso precedente, ovvero l'esecuzione di build e test in container Docker isolati, potrebbe non gestire la creazione di immagini Docker. La creazione di immagini Docker richiede che il runner abbia pieno accesso al servizio Docker. È possibile ottenere questa configurazione utilizzando l'immagine ufficiale docker-in-docker per eseguire i job. Tale configurazione comporta la concessione al runner di una modalità di esecuzione privilegiata di esecuzione.

Sebbene la concessione della modalità privilegiata sia necessaria per la creazione di immagini Docker, essa comporta problemi di sicurezza. Questo perché comporta l'eliminazione dei vantaggi in termini di sicurezza dei container. Si potrebbe pensare che gli altri runner Docker siano sicuri, ma presentano gli stessi problemi spiegati nella documentazione ufficiale di Docker.

Creeremo un altro runner con la modalità di esecuzione privilegiata. Si tratterà di un runner specifico per il progetto a causa delle implicazioni di sicurezza sopra menzionate. Accetterà i job dal progetto Node Pipeline che abbiamo creato nel tutorial su come configurare pipeline CI continue con GitLab.

La prima cosa da fare è verificare che i Runner condivisi siano disabilitati sul progetto. Dalla pagina del progetto Node Pipeline , fai clic su Settings nel menu in basso a sinistra e seleziona CI/CD nel sottomenu:

Trova il pulsante Expand nella sezione Runners e fai clic su di esso per mostrare i dettagli sui runner disponibili:

Fai clic sull'interruttore per disabilitare i Runner condivisi per questo progetto. Se avevi aggiunto un runner specifico per il progetto nella sezione precedente, disabilita anche quello. Aggiungeremo un runner specifico per il progetto privilegiato per eseguire i job di questo progetto. Questo garantisce che non si verifichino errori di build nel caso in cui GitLab assegni in modo casuale i job a runner che non sono stati registrati con una modalità di esecuzione privilegiata. Nello screenshot qui sopra, nella scheda Specific runners, dovresti vedere il token di registrazione token del tuo progetto. Prendine nota perché lo userai in seguito.

Nota: un runner specifico per il progetto può anche essere assegnato ad altri progetti dalla sezione Admin panel > Runners. Quando selezioni un runner dall'elenco dei runner, accedi alla pagina di configurazione del runner. Scorri verso il basso per visualizzare la sezione Restrict projects for this runner:

È il momento di aprire il terminale. Se non hai eseguito i passaggi del tutorial su come configurare le pipeline di integrazione continua di GitLab su Ubuntu 20.04, fai una pausa da questo tutorial e segui i passaggi in modo da avere un server con il servizio runner di GitLab CI. In caso contrario, accedi in SSH al server del runner GitLab CI con il tuo utente sudo per i passaggi successivi.

Per configurare il runner privilegiato specifico per il progetto, inserisci il seguente comando nel terminale, sostituendo il nome del tuo dominio e il token di registrazione copiati sopra:

Questo output mostra che la registrazione è avvenuta con successo:

Per verificarne che la tua istanza GitLab abbia rilevato il runner, torna al browser e aggiorna la pagina Settings > CI/CD. Espandi la sezione Runners e dovresti vedere il tuo runner sotto Specific Runners:

Facoltativamente, se vai al Admin Panel (facendo clic sul pulsante Menu nella barra superiore e selezionando Admin), quindi seleziona Runners nelle opzioni del menu:

Dovresti arrivare su questa pagina che mostra tutti i runner disponibili collegati alla tua istanza GitLab, sia i runner condivisi che quelli specifici per il progetto:

Fino a questo punto, hai configurato con successo un runner in grado di creare immagini Docker.

Passo 2: Configurazione del Docker Registry di GitLab

Alcuni flussi di lavoro cruciali richiedono l'indipendenza da servizi esterni. È qui che entra in gioco il Docker Registry self-managed di GitLab. Non solo è sicuro, ma garantisce anche la flessibilità di adattare i job e le pipeline in base alle proprie esigenze. Per configurare il Docker Registry, modificherai il file di configurazione di GitLab. Innanzitutto, accedi tramite SSH all'istanza di GitLab, quindi apri il file con il seguente comando:

Scorri verso il basso fino a quando non vedi Container Registry Settings:

Decommenta la riga con registry_external_url e impostalo sul nome di dominio dell'istanza di GitLab, specificando la porta 8888 alla fine:

Successivamente, dobbiamo specificare dove il registry troverà i certificati Let's Encrypt aggiungendo le seguenti righe. Ricorda di modificarle con il nome di dominio effettivo della tua istanza GitLab:

Una volta terminato, salva e chiudi il file. Inserisci il seguente comando nel terminale per riconfigurare GitLab:

Successivamente, attendi qualche secondo affinché il comando termini l'esecuzione. In caso di successo, dovresti vedere il seguente output:

Successivamente, dobbiamo assicurarci che il firewall (ufw) consenta il traffico verso la porta del registry che abbiamo assegnato utilizzando il comando:

Quindi, devi verificare che il Docker Registry sia in esecuzione accedendovi da un'altra macchina su cui è installato Docker utilizzando il comando docker login. Se non hai configurato Docker sul tuo ambiente locale, puoi accedere tramite SSH al server del runner GitLab CI poiché ha già Docker installato. Successivamente, esegui il seguente comando, specificando ovviamente il nome di dominio della tua istanza GitLab:

Il tuo output mostrerà il messaggio Login Succeeded in questo modo:

Questo significa che il registry è stato configurato correttamente e funziona. Quando crei le immagini, queste verranno memorizzate localmente nel filesystem del server GitLab. Questo va bene per un registry aziendale privato. Tuttavia, se prevedi di lasciare il tuo registry aperto al pubblico, potresti aver bisogno di uno spazio di archiviazione più grande. Fortunatamente, GitLab offre opzioni per connettersi a bucket di archiviazione. Puoi leggere di più nella documentazione ufficiale del GitLab container registry per vedere come configurare un bucket di archiviazione per la tua istanza GitLab.

Passo 3: Modifica il file gitlab-ci.yml e compila un'immagine Docker

Per procedere con questo passaggio, dovresti avere il progetto Node Pipeline sulla tua istanza GitLab. Ecco la visualizzazione del progetto su GitLab:

Abbiamo parlato di gitlab-ci.yml come il file che il runner di GitLab CI legge quando viene attivato per sapere come compilare la tua applicazione ed eseguire test automatizzati. Dobbiamo modificare questo file per aggiungere le istruzioni per la compilazione delle immagini Docker. Puoi scegliere di modificare questo file direttamente all'interno dell'interfaccia di GitLab. Puoi anche clonarlo sulla tua macchina locale e modificarlo con il tuo editor preferito, quindi fare un commit e un git push su GitLab. Per brevità, utilizzeremo l'interfaccia di GitLab.

Fai clic sul file per aprirlo, quindi fai clic sul Modifica pulsante:

Questo apre il file pronto per la modifica. Elimina tutto dal file e aggiungi il seguente codice:

Mentre aggiungi lo snippet di codice sopra, ricordati di aggiornare la parte evidenziata con i tuoi dettagli effettivi. Quando hai finito, salva le modifiche premendo il pulsante Commit changes . Se hai lavorato al di fuori di GitLab, esegui il commit e il push delle tue modifiche.

Capiamo cosa fa il codice che abbiamo aggiunto al file .gitlab-ci.yml. La prima riga dice a GitLab di usare l'immagine ufficiale Docker-in-Docker image e la collega al servizio docker-in-docker (docker:dind). Definiamo quindi gli stage per build, test, e release. Lo stage build compila l'immagine utilizzando le istruzioni nel Dockerfile e poi la carica nel Docker Registry che abbiamo configurato in un passaggio precedente.

Quando lo stage build ha successo, lo stage test scarica l'immagine, la esegue come container ed esegue il comando npm test per eseguire test automatizzati al suo interno. Se lo stage test ha successo, subentra lo stage release. Nello stage di release, l'immagine viene scaricata e taggata come node_pipeline:latest. Viene quindi reinviata al registry.

Questa è solo una configurazione di base per un progetto demo. Per i tuoi progetti reali, potresti avere altri stage, ad esempio staging, production, ecc. Quando salvi il file dopo averlo modificato, viene avviata una pipeline. Questa inizia quindi a eseguire i job. Torna alla pagina Node Pipeline. Dovresti vedere che il job è attualmente in esecuzione:

Fai clic sull'icona dell'indicatore CI per visualizzare i vari stage del job:

Come puoi vedere dallo screenshot sopra, tutti gli stage sono andati a buon fine, come indicato dalle icone di spunta verdi. Puoi fare clic su ciascuno stage per visualizzare l'output del job:

Nel menu a sinistra, fai clic su Packages & Registries e seleziona Container Registry:

Questo aprirà una pagina con l'elenco delle immagini Docker disponibili per il progetto selezionato. L'immagine che abbiamo compilato e rilasciato dovrebbe apparire nell'elenco con il tag assigned:

Fai clic per mostrare i vari tag dell'immagine:

Se hai Docker installato nel tuo ambiente locale, puoi scaricare l'immagine e verificare che funzioni come previsto. Fai clic sull'icona Copy accanto al nome del tag dell'immagine. Verrà copiato negli appunti il nome completo dell'immagine che puoi utilizzare con il comando docker pull:

I comandi sopra scaricheranno l'immagine e la eseguiranno all'interno di un container:

The app is now being served on port 8090. Se apri il tuo browser e navighi su your-IP-address:8090 dovresti vedere la pagina visualizzata:

Se riesci a vedere una pagina del genere nel tuo browser, significa che hai creato con successo un'immagine Docker e l'hai condivisa su un Docker Registry. In futuro, se apporti modifiche al master branch, gli stage definiti nel file .gitlab-ci.yml verranno eseguiti e, se hanno successo, una nuova immagine Docker con il tag latest verrà ricreata e caricata nel registro.

Conclusione

In questo progetto, hai imparato come aggiungere un privileged runner GitLab alla tua istanza self-managed di GitLab in modo da poter creare immagini Docker. Hai anche configurato un registro privato di immagini Docker per ospitare le tue immagini. Utilizzando il Node pipeline progetto, sei stato in grado di testare ogni componente della configurazione e assicurarti che si connettessero e comunicassero come previsto. Una volta che la tua immagine è stata resa disponibile nel registro, sei stato in grado di scaricarla e confermare che funzionasse all'interno di un container.

Questo è un tutorial introduttivo, che ti fornisce le basi su cui costruire. Segui la documentazione ufficiale di GitLab per saperne di più su GitLab. Questo link può fornire informazioni su GitLab Container Registry.

Per ulteriori risorse sull'utilizzo di Docker, potresti voler consultare altri tutorial sul nostro blog:

• Condivisione di dati tra container Docker
• Configurazione di un registro Docker privato su Ubuntu 18.04
• Come condividere dati tra un container Docker e un host
• Pulizia delle risorse Docker – Immagini, container e volumi

Buona programmazione!