GitLab Runner: Creazione di un'immagine Docker con Docker-in-Docker

Questa documentazione fa parte della guida Creazione di immagini Docker. Consulta la guida completa qui: Crea e pubblica immagini Docker in modo efficiente dalle tue pipeline GitLab CI/CD utilizzando i runner Stackhero e Docker-in-Docker.

👋 Benvenuto nella documentazione di Stackhero!

Stackhero offre una soluzione GitLab Runner cloud semplice che rende l'esecuzione dei tuoi job GitLab CI/CD efficiente e senza complicazioni. Ecco cosa puoi aspettarti:

• Minuti CI/CD illimitati: esegui le tue pipeline tutte le volte che vuoi, senza costi al minuto o spese impreviste.
• Più job in contemporanea: accelera lo sviluppo eseguendo diversi job in parallelo.
• L'executor Docker con supporto Docker-in-Docker: costruisci e pubblica facilmente immagini container come parte del tuo processo CI/CD.
• Funziona perfettamente sia con GitLab.com che con istanze GitLab self-managed.
• Un'infrastruttura privata e dedicata con storage NVMe/SSD veloce garantisce prestazioni di build stabili e prevedibili.
• Disponibile nelle regioni 🇪🇺 Europa e 🇺🇸 USA per soddisfare le esigenze del tuo team.

Risparmia tempo: puoi collegare il tuo primo GitLab Runner e iniziare a eseguire pipeline in pochi minuti!

Puoi aggiungere il seguente esempio di .gitlab-ci.yml al tuo repository. Questa configurazione costruisce il Dockerfile presente nella root del progetto:

build-image:
  stage: build
  image: docker:29
  services:
    - name: docker:29-dind
      alias: docker
  variables:
    DOCKER_HOST: "tcp://docker:2375"
    DOCKER_TLS_CERTDIR: ""
  before_script:
    - docker info
  script:
    # Sostituisci "my-image" con il nome desiderato:
    - docker build -t my-image .
    # Facoltativamente, esegui un test rapido sull'immagine appena creata:
    # - docker run --rm my-image /path/to/tests

In questo esempio utilizziamo la versione 29 dell'immagine Docker. Puoi scegliere una versione più recente non appena disponibile. Trovi i tag più aggiornati sulla pagina ufficiale Docker image.

In questa configurazione, il servizio docker:29-dind avvia un demone Docker accanto al job, e DOCKER_HOST: "tcp://docker:2375" indica alla CLI docker di utilizzarlo. Imposta sempre DOCKER_HOST quando dichiari un servizio docker:dind: senza questa variabile, la CLI si collega silenziosamente a un altro demone, quindi la build può andare a buon fine anche se il servizio è configurato in modo errato, nascondendo problemi reali (e interrompendo strumenti come Testcontainers che dipendono dal servizio). DOCKER_TLS_CERTDIR: "" permette la connessione tramite la porta non-TLS 2375 sulla rete interna del job.

In alternativa, puoi omettere il blocco services e le due variabili: il runner Stackhero espone anche un demone Docker già pronto tramite un socket montato, quindi un semplice docker build funziona senza configurazioni aggiuntive.