GitLab Runner: Docker-images bouwen

Bouw en push Docker-images vanuit uw GitLab CI/CD-pipelines met uw Stackhero-runner 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

Wanneer u een Stackhero GitLab Runner gebruikt, voert deze jobs uit met de Docker executor. Dit betekent dat elke job start in een nieuwe container op basis van de door u opgegeven image. Als u uw eigen Docker-images wilt bouwen als onderdeel van uw pipeline, kunt u gebruikmaken van Docker-in-Docker (DinD). Met deze setup draait er een Docker-daemon naast uw job, zodat u direct binnen uw pipeline commando's als docker build en docker push kunt uitvoeren.

Een groot voordeel hiervan is dat uw runner beschikt over onbeperkte CI/CD-minuten. U kunt dus zo vaak als u wilt images bouwen. Bovendien, omdat uw build-cache zich op de dedicated schijf van de runner bevindt, kunnen herhaalde builds eerdere lagen hergebruiken, waardoor uw pipelines aanzienlijk sneller afronden.

Een Docker-image bouwen met Docker-in-Docker

Hieronder vindt u een voorbeeld van een .gitlab-ci.yml die u aan uw repository kunt toevoegen. Deze configuratie bouwt het Dockerfile dat zich in de root van uw project bevindt:

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

In deze configuratie start de service docker:27-dind de Docker-daemon. De variabele DOCKER_TLS_CERTDIR: "/certs" zorgt voor een beveiligde TLS-verbinding tussen uw job en de Docker-daemon.

Pushen naar de GitLab container registry

GitLab stelt verschillende vooraf gedefinieerde variabelen beschikbaar (CI_REGISTRY, CI_REGISTRY_USER, CI_REGISTRY_PASSWORD, CI_REGISTRY_IMAGE) zodat uw pipeline kan inloggen en images kan pushen naar de container registry van het project, zonder dat u extra secrets hoeft toe te voegen.

Hieronder een voorbeeldjob die uw image bouwt en pusht:

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"
    # Als u zich op de default branch bevindt, 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

Als u uw images naar een andere registry wilt pushen (zoals Docker Hub of een private registry), kunt u deze inloggegevens als CI/CD-variabelen opslaan en ze op vergelijkbare wijze gebruiken met docker login.

Herhaalde builds versnellen

Omdat de schijf van uw runner persistent is tussen pipelines, kunt u builds versnellen door eerdere imagelagen als cache te hergebruiken. Zo stelt u dat in:

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:
    # Probeer het laatste image te pullen om de cache te vullen (geen probleem als deze nog niet bestaat):
    - 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"

Deze aanpak zorgt ervoor dat uw pipelines na verloop van tijd sneller afronden door optimaal gebruik te maken van Docker's layer caching.

Jobs parallel uitvoeren

Uw abonnement bepaalt hoeveel jobs er gelijktijdig kunnen draaien. Jobs binnen dezelfde stage starten tegelijk, tot aan uw ingestelde limiet voor gelijktijdigheid. Dit betekent dat een stage met meerdere onafhankelijke jobs klaar is zodra de langzaamste job is afgerond, in plaats van dat alle jobs na elkaar worden uitgevoerd.

Hieronder een eenvoudig 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 instelt op 3 of hoger, zullen de jobs unit, integration en e2e allemaal tegelijk worden uitgevoerd.

Wilt u meer diepgaande informatie over het bouwen van Docker-images in CI? Bekijk dan gerust de officiële GitLab-documentatie.