GitLab: CI/CD

Come utilizzare GitLab CI/CD

👋 Benvenuto nella documentazione di Stackhero!

Stackhero offre una soluzione GitLab cloud pronta all'uso, pensata per i team che necessitano di un ambiente veloce, sicuro e scalabile:

Utenti, repository, trasferimenti di dati e tempo di elaborazione CI/CD illimitati per la massima flessibilità.

Aggiornamenti semplici con un solo clic, così il tuo ambiente resta sempre aggiornato senza tempi di inattività.

Nome di dominio personalizzato protetto con HTTPS (ad esempio, https://git.tua-azienda.com) per un'immagine professionale e maggiore sicurezza.

Prestazioni costanti e sicurezza elevata sulla tua infrastruttura privata e dedicata. Nessun "vicino rumoroso" e isolamento totale garantito.

Possibilità di scegliere la posizione dell'hosting: 🇪🇺 Europa oppure 🇺🇸 USA in base alle tue esigenze di conformità o latenza.

Inizia rapidamente e concentrati sul tuo codice. La soluzione GitLab cloud hosting di Stackhero è pronta all'uso in circa 5 minuti.

Introduzione

GitLab CI/CD è una funzionalità potente e integrata di GitLab, una piattaforma open source molto diffusa per il controllo di versione e la collaborazione. Questo strumento consente di ottimizzare e automatizzare le fasi fondamentali di build, test e deployment del software, garantendo una consegna più rapida e affidabile di applicazioni di alta qualità.

Ad esempio, con GitLab CI/CD è possibile configurare test unitari automatici che si attivano ogni volta che viene effettuato un nuovo commit su un repository GitLab. Dopo il superamento di questi test, il codice può essere costruito e distribuito in un ambiente di staging per ulteriori verifiche. Una volta superati tutti i test in staging, il sistema può promuovere il codice in produzione, rendendolo disponibile agli utenti finali.

Uno dei principali punti di forza di GitLab CI/CD è la sua stretta integrazione all'interno di GitLab stesso. Questo permette di definire e gestire le pipeline CI/CD direttamente nei repository di progetto, semplificando l'orchestrazione e il monitoraggio dell'intero flusso di lavoro.

GitLab CI/CD supporta un'ampia gamma di linguaggi di programmazione, framework e strumenti, risultando così sufficientemente versatile per adattarsi a diversi tipi di progetti. Il sistema di pipeline personalizzabili consente di adattare ogni fase del processo CI/CD alle proprie esigenze, sia per la build, i test o il deployment su più ambienti.

In sintesi, GitLab CI/CD è una soluzione completa progettata per automatizzare e migliorare i processi di delivery del software. Permette agli sviluppatori di concentrarsi sulla scrittura e sul miglioramento del codice, mentre la piattaforma gestisce in modo efficiente le attività operative.

Come costruire immagini Docker nel proprio GitLab CI

Se il repository del progetto contiene file Dockerfile, è possibile automatizzare il processo di build, esecuzione e, se necessario, pubblicazione delle immagini Docker su un registry.

Passo 1: Abilitare il supporto Docker in Docker (DinD)

Per iniziare, abilitate il supporto "Docker in Docker" (DinD) dal vostro dashboard Stackhero.

L'abilitazione del supporto DinD comporta un rischio per la sicurezza, soprattutto se desiderate isolare gli utenti ed evitare che possano accedere ai progetti altrui.

Passo 2: Configurare la pipeline GitLab CI

Successivamente, aggiornate il file gitlab-ci.yml per includere una configurazione di pipeline che costruisca il vostro Dockerfile utilizzando DinD. Di seguito un esempio di configurazione:

image: docker:29

build:
  stage: build
  services:
    - name: docker:29-dind
      alias: docker
  variables:
    # Indirizza la CLI Docker verso il servizio Docker-in-Docker, tramite la sua porta
    # non protetta (non-TLS). Vedi la nota sotto sull'importanza di DOCKER_HOST.
    DOCKER_HOST: "tcp://docker:2375"
    DOCKER_TLS_CERTDIR: ""
  before_script:
    - docker info
  script:
    # Sostituite "my-docker-image" con il nome dell'immagine desiderata:
    - docker build -t my-docker-image .
    # Facoltativamente, testate l'immagine Docker:
    # - docker run my-docker-image /script/to/run/tests

Il servizio docker:29-dind avvia un demone Docker accanto al vostro job, e DOCKER_HOST indica alla CLI docker di utilizzarlo. Impostate sempre DOCKER_HOST quando dichiarate un servizio docker:dind: se lo omettete, la CLI si collega silenziosamente a un altro demone e la build può andare a buon fine anche se il servizio è configurato in modo errato, nascondendo problemi reali. DOCKER_TLS_CERTDIR: "" utilizza la porta interna 2375 non protetta della rete del job.

In alternativa, potete eliminare completamente il blocco services e le due variabili: il runner Stackhero espone già un demone Docker pronto all'uso tramite un socket montato, quindi un semplice docker build funziona immediatamente.

Per ulteriori informazioni sulla build di immagini Docker con GitLab CI, consultate la documentazione ufficiale di GitLab.

Eseguire i test con Testcontainers

Se la vostra suite di test utilizza Testcontainers, una libreria che avvia servizi reali (database, message broker e altro) come container Docker temporanei durante l'esecuzione dei test, la configurazione sopra riportata è già adatta. Mantenete il servizio docker:29-dind e le due variabili: Testcontainers utilizza DOCKER_HOST per raggiungere il demone Docker e collegarsi ai container che avvia, quindi non è necessaria alcuna configurazione aggiuntiva.

Omettere DOCKER_HOST è la causa più comune di errori di Testcontainers in CI. In tal caso, la libreria utilizza il socket Docker montato dal runner e non riesce a raggiungere i propri container di test, il che di solito si manifesta come un timeout del container helper Ryuk.