GitLab Runner: Creación de imágenes Docker

Construya y suba imágenes Docker desde sus pipelines de GitLab CI/CD utilizando su runner 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

Cuando utiliza un Stackhero GitLab Runner, este ejecuta los jobs con el ejecutor Docker. Esto significa que cada job se inicia en un contenedor nuevo basado en la image que usted especifique. Si desea construir sus propias imágenes Docker como parte de su pipeline, puede aprovechar Docker-in-Docker (DinD). Esta configuración permite que un daemon de Docker se ejecute junto a su job, de modo que puede ejecutar comandos como docker build y docker push directamente dentro de su pipeline.

Una de las grandes ventajas aquí es que su runner dispone de minutos CI/CD ilimitados. Puede construir imágenes tantas veces como lo necesite. Además, dado que el cache de build reside en el disco dedicado del runner, las compilaciones repetidas pueden reutilizar capas anteriores, lo que ayuda a que sus pipelines terminen mucho más rápido.

Construir una imagen Docker con Docker-in-Docker

Aquí tiene un ejemplo de .gitlab-ci.yml que puede añadir a su repositorio. Esta configuración construye el Dockerfile que se encuentra en la raíz de su proyecto:

build-image:
  stage: build
  image: docker:27
  services:
    - docker:27-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  before_script:
    - docker info
  script:
    # Sustituya "my-image" por el nombre que desee:
    - docker build -t my-image .
    # Opcionalmente, puede ejecutar un test rápido sobre la imagen construida:
    # - docker run --rm my-image /path/to/tests

En esta configuración, el servicio docker:27-dind inicia el daemon de Docker. La variable DOCKER_TLS_CERTDIR: "/certs" habilita una conexión TLS segura entre su job y el daemon de Docker.

Subir a GitLab Container Registry

GitLab proporciona varias variables predefinidas (CI_REGISTRY, CI_REGISTRY_USER, CI_REGISTRY_PASSWORD, CI_REGISTRY_IMAGE) para que su pipeline pueda iniciar sesión y subir imágenes al registro de contenedores del proyecto sin necesidad de secretos adicionales.

Aquí tiene un ejemplo de job que construye y sube su imagen:

build-and-push:
  stage: build
  image: docker:27
  services:
    - docker:27-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á en la rama principal, también puede etiquetar y subir "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

Si desea subir sus imágenes a otro registro (como Docker Hub o un registro privado), puede almacenar esas credenciales como variables CI/CD y usarlas con docker login de forma similar.

Acelerar builds repetidos

Como el disco de su runner persiste entre pipelines, puede acelerar las compilaciones reutilizando capas de imágenes anteriores como cache. Así es como puede configurarlo:

build-cached:
  stage: build
  image: docker:27
  services:
    - docker:27-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  before_script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
  script:
    # Intente descargar la última imagen para alimentar el cache (no pasa nada si aún no 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 método ayuda a que sus pipelines terminen más rápido con el tiempo, aprovechando al máximo el cache de capas de Docker.

Ejecutar jobs en paralelo

Su plan determina cuántos jobs pueden ejecutarse al mismo tiempo. Los jobs dentro de la misma etapa se inician juntos, hasta el límite de concurrencia que tenga configurado. Esto significa que una etapa con varios jobs independientes puede finalizar tan pronto como termine el job más lento, en lugar de ejecutar todos los jobs de forma secuencial.

Aquí tiene un ejemplo sencillo:

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 establece su concurrencia en 3 o más, los jobs unit, integration y e2e se ejecutarán todos al mismo tiempo.

Si desea información más detallada sobre cómo construir imágenes Docker en CI, puede consultar la documentación oficial de GitLab.