GitLab Runner: Creazione di immagini Docker

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 ti offre una soluzione GitLab Runner cloud facile da usare, progettata per gestire in modo efficiente i tuoi job GitLab CI/CD. Ecco cosa puoi aspettarti:

Minuti CI/CD illimitati: nessuna fatturazione al minuto, le tue pipeline possono essere eseguite ogni volta che ne hai bisogno.

Job concorrenti multipli: esegui più job contemporaneamente per velocizzare l'intera pipeline.

Docker executor con supporto Docker-in-Docker: semplifica la creazione e il push delle tue immagini container.

Compatibile sia con GitLab.com che con qualsiasi istanza GitLab self-managed.

Una VM privata e dedicata alimentata da dischi NVMe/SSD veloci per build affidabili e costanti.

Disponibile sia nelle regioni 🇪🇺 Europa che 🇺🇸 USA.

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

Introduzione

Con uno Stackhero GitLab Runner, ogni job viene eseguito all'interno di un container isolato tramite il Docker executor. Puoi costruire le tue immagini Docker direttamente nella pipeline abilitando Docker-in-Docker (DinD). Questa configurazione avvia un demone Docker accanto al tuo job, consentendoti di eseguire i comandi docker build e docker push come parte del processo CI/CD.

Ogni esecuzione beneficia di minuti CI/CD illimitati: puoi effettuare build tutte le volte che vuoi, senza preoccuparti di limiti di utilizzo. Il build cache viene memorizzato sul disco dedicato del runner, il che significa che le build ripetute possono riutilizzare i layer precedenti. Questo riduce notevolmente i tempi di build e accelera il completamento delle pipeline.

Creazione di un'immagine Docker con Docker-in-Docker

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:
    - docker:29-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  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 viene utilizzata la versione 29 dell'immagine Docker. Puoi scegliere una versione più recente se disponibile. Trovi i tag più aggiornati sulla pagina ufficiale Docker image.

In questa configurazione, il servizio docker:29-dind avvia il demone Docker. Impostando DOCKER_TLS_CERTDIR: "/certs" abiliti una connessione TLS sicura tra il job e il demone Docker.

Push verso il container registry di GitLab

GitLab mette a disposizione variabili predefinite (CI_REGISTRY, CI_REGISTRY_USER, CI_REGISTRY_PASSWORD, CI_REGISTRY_IMAGE) che permettono alla pipeline di autenticarsi e pubblicare immagini nel container registry del progetto in modo sicuro. Non sono necessari segreti aggiuntivi.

Ecco un esempio di job che costruisce e pubblica la tua immagine:

build-and-push:
  stage: build
  image: docker:29
  services:
    - docker:29-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  before_script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
  script:
    - docker build -t "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA" .
    - docker push "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA"
    # Se sei sul branch di default, puoi anche taggare e pubblicare "latest":
    - |
      if [ "$CI_COMMIT_BRANCH" = "$CI_DEFAULT_BRANCH" ]; then
        docker tag "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA" "$CI_REGISTRY_IMAGE:latest"
        docker push "$CI_REGISTRY_IMAGE:latest"
      fi

Per pubblicare le immagini su un altro registry (come Docker Hub o un registry privato), puoi salvare le credenziali come variabili CI/CD e utilizzarle con docker login nello stesso modo.

Accelerare le build ripetute

Il disco del runner persiste tra le pipeline, consentendo di riutilizzare i layer delle immagini come cache di build. Questo può velocizzare notevolmente le build successive. Ecco un esempio di configurazione:

build-cached:
  stage: build
  image: docker:29
  services:
    - docker:29-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  before_script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
  script:
    # Recupera l'immagine più recente per inizializzare la cache (se esiste):
    - docker pull "$CI_REGISTRY_IMAGE:latest" || true
    - docker build --cache-from "$CI_REGISTRY_IMAGE:latest" -t "$CI_REGISTRY_IMAGE:latest" .
    - docker push "$CI_REGISTRY_IMAGE:latest"

Questo approccio permette alle build di sfruttare la cache dei layer Docker, ricostruendo solo i layer nuovi o modificati.

Esecuzione di job in parallelo

Il tuo piano determina quanti job possono essere eseguiti contemporaneamente. I job appartenenti allo stesso stage partono insieme, fino al limite di concorrenza previsto. Questo significa che più job indipendenti possono essere eseguiti in parallelo e terminare non appena il più lento si conclude, senza dover attendere la fine sequenziale di ciascun job.

Esempio:

stages:
  - test

unit:
  stage: test
  image: node:22
  script: npm run test:unit

integration:
  stage: test
  image: node:22
  script: npm run test:integration

e2e:
  stage: test
  image: node:22
  script: npm run test:e2e

Se imposti la concorrenza a 1 o superiore, i job unit, integration ed e2e verranno eseguiti contemporaneamente.

Per ulteriori dettagli sulla creazione di immagini Docker nelle pipeline GitLab CI/CD, puoi consultare la documentazione ufficiale GitLab sull'utilizzo dei Docker build.