GitLab: CI/CD

Cómo utilizar GitLab CI/CD

👋 ¡Bienvenido a la documentación de Stackhero!

Stackhero ofrece una solución GitLab cloud lista para usar, diseñada para equipos que necesitan un entorno rápido, seguro y escalable:

Usuarios, repositorios, transferencias de datos y tiempo de procesamiento CI/CD ilimitados para una flexibilidad total.

Actualizaciones sencillas con un solo clic, para que su entorno esté siempre actualizado sin interrupciones.

Nombre de dominio personalizado protegido con HTTPS (por ejemplo, https://git.su-empresa.com) para una imagen profesional y mayor seguridad.

Rendimiento constante y seguridad reforzada en su propia infraestructura privada y dedicada. Sin vecinos ruidosos y con aislamiento total.

Elección de la ubicación de alojamiento: 🇪🇺 Europa o 🇺🇸 USA según sus necesidades de cumplimiento o latencia.

Empiece rápidamente y concéntrese en su código. La solución de GitLab cloud hosting de Stackhero está lista para usar en unos 5 minutos.

Introducción

GitLab CI/CD es una funcionalidad potente e integrada de GitLab, una plataforma open source muy popular para el control de versiones y la colaboración. Esta herramienta le permite optimizar y automatizar las etapas clave de construcción, pruebas y despliegue de su software, garantizando una entrega más rápida y fiable de aplicaciones de alta calidad.

Por ejemplo, con GitLab CI/CD puede configurar tests unitarios automatizados que se ejecutan cada vez que se realiza un nuevo commit en un repositorio de GitLab. Tras superar estos tests con éxito, su código puede ser construido y desplegado en un entorno de staging para su evaluación. Una vez superadas todas las pruebas en staging, el sistema puede promocionar el código al entorno de producción, poniéndolo a disposición de los usuarios finales.

Una de las principales ventajas de GitLab CI/CD es su integración directa dentro de GitLab. Esto le permite definir y gestionar sus pipelines de CI/CD directamente en los repositorios de sus proyectos, simplificando la orquestación y el seguimiento de todo su flujo de trabajo.

GitLab CI/CD es compatible con una amplia variedad de lenguajes de programación, frameworks y herramientas, lo que lo hace lo suficientemente versátil para adaptarse a diferentes tipos de proyectos. Su sistema de pipelines personalizables le permite adaptar cada etapa del proceso CI/CD a sus necesidades, ya sea para construir, probar o desplegar en múltiples entornos.

En resumen, GitLab CI/CD es una solución integral diseñada para automatizar y mejorar los procesos de entrega de software. Permite a los desarrolladores centrarse en escribir y mejorar el código mientras la plataforma gestiona de forma eficiente las tareas operativas.

Cómo construir imágenes Docker en su GitLab CI

Si el repositorio de su proyecto incluye archivos Dockerfile, puede automatizar el proceso de construcción, ejecución y, si lo necesita, publicación de imágenes Docker en un registro.

Paso 1: Activar el soporte Docker in Docker (DinD)

Para empezar, active el soporte "Docker in Docker" (DinD) en su panel de Stackhero.

Activar el soporte DinD implica un riesgo de seguridad, especialmente si desea aislar a sus usuarios y evitar que accedan a los proyectos de otros.

Paso 2: Configurar el pipeline de GitLab CI

A continuación, actualice su archivo gitlab-ci.yml para incluir una configuración de pipeline que construya su Dockerfile utilizando DinD. A continuación se muestra un ejemplo de configuración:

image: docker:29

build:
  stage: build
  services:
    - name: docker:29-dind
      alias: docker
  variables:
    # Indica al CLI de Docker que utilice el servicio Docker-in-Docker, a través de su puerto
    # sin cifrar (no-TLS). Consulte la nota más abajo sobre la importancia de DOCKER_HOST.
    DOCKER_HOST: "tcp://docker:2375"
    DOCKER_TLS_CERTDIR: ""
  before_script:
    - docker info
  script:
    # Sustituya "my-docker-image" por el nombre de la imagen que desee:
    - docker build -t my-docker-image .
    # Opcionalmente, pruebe la imagen Docker:
    # - docker run my-docker-image /script/to/run/tests

El servicio docker:29-dind inicia un daemon Docker junto a su job, y DOCKER_HOST indica al CLI de docker que lo utilice. Debe establecer siempre DOCKER_HOST cuando declare un servicio docker:dind: si lo omite, el CLI se conecta silenciosamente a otro daemon y su build puede completarse incluso si el servicio está mal configurado, ocultando problemas reales. DOCKER_TLS_CERTDIR: "" utiliza el puerto 2375 sin cifrar en la red interna del job.

Como alternativa más sencilla, puede eliminar por completo el bloque services y ambas variables: el runner de Stackhero ya expone un daemon Docker listo para usar a través de un socket montado, por lo que un simple docker build funciona directamente.

Para más información sobre cómo construir imágenes Docker con GitLab CI, consulte la documentación oficial de GitLab.

Ejecutar sus tests con Testcontainers

Si su suite de tests utiliza Testcontainers, una librería que lanza servicios reales (bases de datos, brokers de mensajes y más) como contenedores Docker desechables durante la ejecución de los tests, la configuración anterior ya cubre este caso. Mantenga el servicio docker:29-dind y ambas variables: Testcontainers utiliza DOCKER_HOST para acceder al daemon Docker y conectarse a los contenedores que inicia, por lo que no se requiere ninguna otra configuración.

Omitir DOCKER_HOST es la causa más común de fallos de Testcontainers en CI. En ese caso, la librería recurre al socket Docker montado por el runner y no puede acceder a sus propios contenedores de test, lo que normalmente se manifiesta como un timeout del contenedor auxiliar Ryuk.