GitLab: Come costruire immagini Docker nel proprio GitLab CI

Questa documentazione fa parte della guida CI/CD. Consulta la guida completa qui: 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.

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.