GitLab Runner: Crear imágenes Docker

Crea y publica imágenes Docker de forma eficiente desde tus pipelines de GitLab CI/CD utilizando runners de Stackhero y Docker-in-Docker

👋 ¡Bienvenido a la documentación de Stackhero!

Stackhero le ofrece una solución GitLab Runner cloud fácil de usar, diseñada para gestionar sus trabajos de GitLab CI/CD de manera eficiente. Esto es lo que puede esperar:

Minutos CI/CD ilimitados: no hay facturación por minuto, así que sus pipelines pueden ejecutarse siempre que lo necesite.

Múltiples trabajos concurrentes: ejecute varios trabajos al mismo tiempo para acelerar todo su pipeline.

Docker executor con soporte para Docker-in-Docker: simplifique la construcción y el push de sus imágenes de contenedor.

Compatible con GitLab.com y cualquier instancia GitLab autogestionada.

Una VM privada y dedicada impulsada por discos NVMe/SSD rápidos para builds consistentes y fiables.

Disponible en las regiones de 🇪🇺 Europa y 🇺🇸 USA.

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

Introducción

Con un Stackhero GitLab Runner, cada job se ejecuta dentro de un contenedor nuevo utilizando el ejecutor Docker. Puedes construir tus propias imágenes Docker directamente en tu pipeline habilitando Docker-in-Docker (DinD). Esta configuración lanza un daemon de Docker junto a tu job, permitiéndote ejecutar los comandos docker build y docker push como parte de tu proceso CI/CD.

Cada ejecución disfruta de minutos CI/CD ilimitados: puedes construir tantas veces como necesites, sin preocuparte por límites de uso. Tu caché de compilación se almacena en el disco dedicado del runner, lo que permite reutilizar capas de builds anteriores en ejecuciones repetidas. Esto reduce significativamente los tiempos de compilación y acelera la finalización de tus pipelines.

Crear una imagen Docker con Docker-in-Docker

Puedes añadir el siguiente ejemplo de .gitlab-ci.yml a tu repositorio. Esta configuración construye el Dockerfile que se encuentra en la raíz de tu proyecto:

build-image:
  stage: build
  image: docker:29
  services:
    - docker:29-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  before_script:
    - docker info
  script:
    # Sustituye "my-image" por el nombre que desees:
    - docker build -t my-image .
    # Opcionalmente, ejecuta una prueba rápida sobre la imagen construida:
    # - docker run --rm my-image /path/to/tests

En este ejemplo estamos usando la versión 29 de la imagen Docker. Puedes utilizar una versión más reciente si está disponible. Consulta las etiquetas más recientes en la página oficial de imágenes Docker.

En esta configuración, el servicio docker:29-dind inicia el daemon de Docker. Al establecer DOCKER_TLS_CERTDIR: "/certs" se habilita una conexión TLS segura entre tu job y el daemon de Docker.

Publicar en el registro de contenedores de GitLab

GitLab proporciona variables predefinidas (CI_REGISTRY, CI_REGISTRY_USER, CI_REGISTRY_PASSWORD, CI_REGISTRY_IMAGE) para que tu pipeline pueda autenticarse y publicar imágenes en el registro de contenedores de tu proyecto de forma segura. No se requieren secretos adicionales.

Aquí tienes un ejemplo de job que construye y publica tu imagen:

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"
    # Si estás en la rama principal, también puedes etiquetar y publicar "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

Para publicar tus imágenes en otro registro (como Docker Hub o un registro privado), puedes almacenar las credenciales como variables CI/CD y usarlas con docker login de la misma manera.

Acelerar builds repetidos

El disco de tu runner se mantiene entre pipelines, permitiendo reutilizar las capas de imagen como caché de compilación. Esto puede hacer que los builds repetidos sean mucho más rápidos. Aquí tienes un ejemplo de configuración:

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:
    # Descarga la última imagen para inicializar la caché (si existe):
    - 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"

Este enfoque permite que tus builds aprovechen la caché de capas de Docker, de modo que solo se reconstruyen las capas nuevas o modificadas.

Ejecutar jobs en paralelo

Tu plan determina cuántos jobs pueden ejecutarse de forma concurrente. Los jobs en la misma etapa se inician juntos, hasta el límite de concurrencia que tengas configurado. Esto significa que varios jobs independientes pueden ejecutarse en paralelo y finalizar tan pronto como termine el más lento, en lugar de esperar a que cada uno termine en secuencia.

Ejemplo:

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

Si configuras la concurrencia en 1 o superior, los jobs unit, integration y e2e se ejecutarán al mismo tiempo.

Para más información sobre cómo construir imágenes Docker en pipelines de GitLab CI/CD, puedes consultar la documentación oficial de GitLab sobre el uso de builds Docker.