GitLab Runner: Ejecutar tus tests con Testcontainers

Esta documentación forma parte de la guía Crear imágenes Docker. Consulte la guía completa aquí: Compila y publica imágenes Docker de forma eficiente desde tus pipelines de GitLab CI/CD utilizando los runners de Stackhero y Docker-in-Docker.

👋 ¡Bienvenido a la documentación de Stackhero!

Stackhero ofrece una solución sencilla de GitLab Runner en la nube que facilita la ejecución de sus trabajos de GitLab CI/CD de manera eficiente y sin complicaciones. Esto es lo que puede esperar:

• Minutos ilimitados de CI/CD: ejecute sus pipelines tantas veces como necesite, sin facturación por minuto ni cargos inesperados.
• Varios trabajos concurrentes: acelere su desarrollo ejecutando varios trabajos en paralelo.
• El ejecutor Docker con soporte para Docker-in-Docker: construya y publique fácilmente imágenes de contenedores como parte de su proceso CI/CD.
• Funciona perfectamente tanto con GitLab.com como con instancias de GitLab autogestionadas.
• Una infraestructura privada y dedicada con almacenamiento NVMe/SSD rápido garantiza un rendimiento de compilación estable y predecible.
• Disponible en las regiones de 🇪🇺 Europa y 🇺🇸 USA para adaptarse a las necesidades de su equipo.

Ahorre tiempo: puede conectar su primer GitLab Runner y empezar a ejecutar pipelines en solo unos minutos.

Testcontainers es una biblioteca de testing, disponible para Java, Go, Node.js, Python, .NET y otros lenguajes, que inicia servicios reales como contenedores Docker desechables mientras se ejecutan tus tests. En lugar de simular una base de datos o un broker de mensajes, tus tests de integración se comunican con una instancia real de PostgreSQL, MySQL, Redis o Kafka, creada antes de los tests y eliminada justo después. Es especialmente popular en proyectos Java y Spring.

Testcontainers necesita un daemon Docker, por lo que funciona exactamente con la misma configuración de Docker-in-Docker que la anterior. No se necesita ninguna variable adicional:

test:
  stage: test
  # Utiliza la imagen que necesiten tus tests (aquí un JDK), no necesariamente la imagen docker:
  image: gradle:jdk21
  services:
    - name: docker:29-dind
      alias: docker
  variables:
    DOCKER_HOST: "tcp://docker:2375"
    DOCKER_TLS_CERTDIR: ""
  script:
    - gradle test

Testcontainers lee DOCKER_HOST para encontrar el daemon, y reutiliza ese mismo hostname docker para acceder a los puertos publicados por los contenedores que inicia. Ambos funcionan por sí solos, ya que el alias docker se resuelve en la red de tu job.

Mantén DOCKER_HOST en tus jobs que usen Testcontainers. Si no lo haces, Testcontainers recurre al socket Docker montado por el runner y luego intenta acceder a tus contenedores de test a través de la dirección IP del host, a la que tu job no puede conectarse. El síntoma habitual es que el contenedor auxiliar Ryuk falla con Wait strategy failed. Container is removed, o Timed out waiting for log output matching '.*Started.*'.