GitLab Runner: Construir imagens Docker

Construa e envie imagens Docker de forma eficiente a partir dos seus pipelines GitLab CI/CD utilizando runners Stackhero e Docker-in-Docker

👋 Bem-vindo à documentação da Stackhero!

A Stackhero oferece-lhe uma solução GitLab Runner cloud fácil de utilizar, concebida para executar os seus jobs GitLab CI/CD de forma eficiente. Eis o que pode esperar:

• Minutos CI/CD ilimitados: não existe faturação por minuto, por isso os seus pipelines podem correr sempre que precisar.
• Vários jobs em simultâneo: execute vários jobs ao mesmo tempo para acelerar todo o seu pipeline.
• Docker executor com suporte para Docker-in-Docker: simplifique a criação e o envio das suas imagens de containers.
• Compatível com GitLab.com e também com qualquer instância GitLab self-managed.
• Uma VM privada e dedicada alimentada por discos NVMe/SSD rápidos para builds consistentes e fiáveis.
• Disponível nas regiões 🇪🇺 Europa e 🇺🇸 USA.

Poupe tempo: pode ligar o seu primeiro GitLab Runner e começar a executar pipelines em apenas alguns minutos!

Introdução

Com um Stackhero GitLab Runner, cada job é executado dentro de um novo contentor utilizando o executor Docker. Pode construir as suas próprias imagens Docker diretamente no pipeline ao ativar o Docker-in-Docker (DinD). Esta configuração inicia um daemon Docker em paralelo com o seu job, permitindo-lhe executar comandos docker build e docker push como parte do seu processo CI/CD.

Cada execução beneficia de minutos CI/CD ilimitados: pode construir quantas vezes forem necessárias, sem preocupações com limites de utilização. O seu cache de build é armazenado no disco dedicado do runner, o que significa que builds repetidos podem reutilizar camadas anteriores. Isto reduz significativamente o tempo de build e acelera a conclusão dos seus pipelines.

Construir uma imagem Docker com Docker-in-Docker

Pode adicionar o seguinte exemplo de .gitlab-ci.yml ao seu repositório. Esta configuração constrói o Dockerfile localizado na raiz do seu projeto:

build-image:
  stage: build
  image: docker:29
  services:
    - docker:29-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  before_script:
    - docker info
  script:
    # Substitua "my-image" pelo nome pretendido:
    - docker build -t my-image .
    # Opcionalmente, execute um teste rápido na imagem construída:
    # - docker run --rm my-image /path/to/tests

Neste exemplo estamos a utilizar a versão 29 da imagem Docker. Pode optar por uma versão mais recente à medida que ficam disponíveis. Consulte as tags mais recentes na página oficial da imagem Docker.

Nesta configuração, o serviço docker:29-dind inicia o daemon Docker. Definir DOCKER_TLS_CERTDIR: "/certs" ativa uma ligação TLS segura entre o seu job e o daemon Docker.

Enviar para o registo de contentores do GitLab

O GitLab fornece variáveis predefinidas (CI_REGISTRY, CI_REGISTRY_USER, CI_REGISTRY_PASSWORD, CI_REGISTRY_IMAGE) para que o seu pipeline possa autenticar-se e enviar imagens para o registo de contentores do seu projeto de forma segura. Não são necessários segredos adicionais.

Aqui está um exemplo de job que constrói e envia a sua imagem:

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"
    # Se estiver na branch principal, pode também marcar e enviar "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 enviar as suas imagens para outro registo (como Docker Hub ou um registo privado), pode guardar as credenciais como variáveis CI/CD e utilizá-las com o docker login da mesma forma.

Acelerar builds repetidos

O disco do seu runner é persistente entre pipelines, permitindo reutilizar camadas de imagem como cache de build. Isto pode tornar builds repetidos muito mais rápidos. Eis um exemplo de configuração:

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:
    # Puxe a imagem mais recente para alimentar o cache (se existir):
    - 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"

Esta abordagem permite que os seus builds tirem partido do cache de camadas do Docker, reconstruindo apenas as camadas novas ou alteradas.

Executar jobs em paralelo

O seu plano determina quantos jobs podem ser executados em simultâneo. Jobs na mesma etapa iniciam ao mesmo tempo, até ao limite de concorrência definido. Isto significa que vários jobs independentes podem correr em paralelo, terminando assim que o job mais lento acabar, em vez de esperar que cada um termine sequencialmente.

Exemplo:

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

Se definir a sua concorrência para 1 ou superior, os jobs unit, integration e e2e serão executados em simultâneo.

Para mais detalhes sobre como construir imagens Docker em pipelines GitLab CI/CD, consulte a documentação oficial do GitLab sobre builds Docker.