GitLab Runner: Esecuzione dei test con Testcontainers

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!

Testcontainers è una libreria di testing, disponibile per Java, Go, Node.js, Python, .NET e altri linguaggi, che avvia servizi reali come container Docker temporanei durante l'esecuzione dei test. Invece di simulare un database o un message broker, i test di integrazione interagiscono con una vera istanza di PostgreSQL, MySQL, Redis o Kafka, creata prima dei test e rimossa subito dopo. È particolarmente popolare nei progetti Java e Spring.

Testcontainers necessita di un demone Docker, quindi funziona con la stessa configurazione Docker-in-Docker vista sopra. Non sono richieste variabili aggiuntive:

test:
  stage: test
  # Usa l'immagine necessaria per i tuoi test (ad esempio una JDK), non necessariamente l'immagine docker:
  image: gradle:jdk21
  services:
    - name: docker:29-dind
      alias: docker
  variables:
    DOCKER_HOST: "tcp://docker:2375"
    DOCKER_TLS_CERTDIR: ""
  script:
    - gradle test

Testcontainers legge la variabile DOCKER_HOST per individuare il demone, e riutilizza lo stesso hostname docker per raggiungere le porte pubblicate dai container che avvia. Entrambe le funzionalità sono operative perché l'alias docker viene risolto sulla rete del job.

Mantieni DOCKER_HOST nei job che utilizzano Testcontainers. Senza questa variabile, Testcontainers utilizza il socket Docker montato dal runner e poi tenta di raggiungere i container di test tramite l'indirizzo IP host, a cui il job non può connettersi. Il sintomo tipico è il fallimento del container helper Ryuk con Wait strategy failed. Container is removed, oppure Timed out waiting for log output matching '.*Started.*'.