GitLab Runner: Docker-images bouwen

Bouw en push Docker-images efficiënt vanuit uw GitLab CI/CD-pipelines met Stackhero runners en Docker-in-Docker

👋 Welkom bij de Stackhero-documentatie!

Stackhero biedt u een gebruiksvriendelijke GitLab Runner cloud oplossing, speciaal ontworpen om uw GitLab CI/CD-jobs efficiënt uit te voeren. Dit kunt u verwachten:

Onbeperkte CI/CD-minuten: er is geen facturatie per minuut, dus uw pipelines kunnen draaien wanneer u dat nodig heeft.

Meerdere gelijktijdige jobs: voer verschillende jobs tegelijkertijd uit om uw volledige pipeline te versnellen.

De Docker executor met ondersteuning voor Docker-in-Docker: maak het bouwen en pushen van uw container images eenvoudiger.

Compatibel met GitLab.com en elke self-managed GitLab-instantie.

Een privé, dedicated VM aangedreven door snelle NVMe/SSD-schijven voor consistente en betrouwbare builds.

Beschikbaar in zowel 🇪🇺 Europa als 🇺🇸 USA regio's.

Bespaar tijd: u kunt uw eerste GitLab Runner koppelen en binnen enkele minuten pipelines uitvoeren!

Introductie

Met een Stackhero GitLab Runner draait elke job in een verse container via de Docker executor. U kunt uw eigen Docker-images direct in uw pipeline bouwen door Docker-in-Docker (DinD) te activeren. Deze configuratie start een Docker-daemon naast uw job, zodat u docker build- en docker push-commando's kunt uitvoeren als onderdeel van uw CI/CD-proces.

Elke run profiteert van onbeperkte CI/CD-minuten: u kunt zo vaak bouwen als nodig is, zonder u zorgen te maken over limieten. Uw build-cache wordt opgeslagen op de dedicated schijf van de runner, waardoor herhaalde builds eerdere lagen kunnen hergebruiken. Dit verkort de buildtijden aanzienlijk en versnelt uw pipelines.

Een Docker-image bouwen met Docker-in-Docker

U kunt het volgende voorbeeld van .gitlab-ci.yml toevoegen aan uw repository. Deze configuratie bouwt de Dockerfile in de root van uw project:

build-image:
  stage: build
  image: docker:29
  services:
    - docker:29-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  before_script:
    - docker info
  script:
    # Vervang "my-image" door de gewenste naam:
    - docker build -t my-image .
    # Optioneel: voer een snelle test uit op het gebouwde image:
    # - docker run --rm my-image /path/to/tests

In dit voorbeeld gebruiken we Docker-image versie 29. U kunt eventueel een nieuwere versie gebruiken zodra die beschikbaar is. De laatste tags vindt u op de officiële Docker image pagina.

In deze setup start de docker:29-dind service de Docker-daemon. Door DOCKER_TLS_CERTDIR: "/certs" in te stellen, wordt een beveiligde TLS-verbinding tussen uw job en de Docker-daemon mogelijk gemaakt.

Pushen naar de GitLab container registry

GitLab stelt vooraf gedefinieerde variabelen beschikbaar (CI_REGISTRY, CI_REGISTRY_USER, CI_REGISTRY_PASSWORD, CI_REGISTRY_IMAGE) zodat uw pipeline veilig kan authenticeren en images kan pushen naar de container registry van uw project. Er zijn geen extra secrets nodig.

Hieronder vindt u een voorbeeldjob die uw image bouwt en pusht:

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"
    # Als u op de default branch zit, kunt u ook "latest" taggen en pushen:
    - |
      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

Om uw images naar een andere registry te pushen (zoals Docker Hub of een private registry), kunt u inloggegevens opslaan als CI/CD-variabelen en deze op dezelfde manier gebruiken met docker login.

Herhaalde builds versnellen

De schijf van uw runner blijft behouden tussen pipelines, waardoor u image-lagen als build-cache kunt hergebruiken. Dit maakt herhaalde builds aanzienlijk sneller. Hieronder een voorbeeldconfiguratie:

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:
    # Pull het laatste image om de cache te vullen (indien aanwezig):
    - 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"

Met deze aanpak kunnen uw builds gebruikmaken van Docker's laag-cache, zodat alleen nieuwe of gewijzigde lagen opnieuw worden opgebouwd.

Jobs parallel uitvoeren

Uw abonnement bepaalt hoeveel jobs er gelijktijdig kunnen draaien. Jobs in dezelfde stage starten samen, tot aan uw ingestelde limiet voor gelijktijdigheid. Dit betekent dat meerdere onafhankelijke jobs parallel kunnen draaien en afronden zodra de langzaamste job klaar is, in plaats van te wachten tot elke job na elkaar is afgerond.

Voorbeeld:

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

Als u uw gelijktijdigheid op 1 of hoger instelt, zullen de jobs unit, integration en e2e tegelijkertijd worden uitgevoerd.

Voor meer informatie over het bouwen van Docker-images in GitLab CI/CD-pipelines kunt u de officiële GitLab-documentatie over Docker builds raadplegen.