GitLab: CI/CD

Hoe GitLab CI/CD te gebruiken

👋 Welkom bij de Stackhero-documentatie!

Stackhero biedt een kant-en-klare GitLab cloud oplossing, speciaal ontworpen voor teams die behoefte hebben aan een snelle, veilige en schaalbare omgeving:

• Onbeperkt aantal gebruikers, repositories, dataverkeer en CI/CD-verwerkingstijd voor maximale flexibiliteit.
• Moeiteloze updates met één klik, zodat uw omgeving altijd up-to-date blijft zonder downtime.
• Eigen domeinnaam beveiligd met HTTPS (bijvoorbeeld https://git.uw-bedrijf.com) voor een professionele uitstraling en optimale beveiliging.
• Consistente performance en sterke beveiliging op uw eigen privé, dedicated infrastructuur. Geen last van andere gebruikers en volledige isolatie.
• Keuze uit hostinglocatie: 🇪🇺 Europa of 🇺🇸 USA afhankelijk van uw compliance- of latency-eisen.

Start snel en focus op uw code. Stackhero's GitLab cloud hosting oplossing is binnen ongeveer 5 minuten klaar voor gebruik.

Introductie

GitLab CI/CD is een krachtige en geïntegreerde functionaliteit van GitLab, een populair open-source platform voor versiebeheer en samenwerking. Met deze tool kunt u de essentiële fasen van het bouwen, testen en uitrollen van uw software stroomlijnen en automatiseren, waardoor u sneller en betrouwbaarder hoogwaardige applicaties kunt leveren.

Met GitLab CI/CD kunt u bijvoorbeeld geautomatiseerde unittests instellen die worden uitgevoerd telkens wanneer er een nieuwe commit naar een GitLab-repository wordt gepusht. Nadat deze tests succesvol zijn doorlopen, kan uw code worden gebouwd en uitgerold naar een staging-omgeving voor verdere evaluatie. Zodra alle staging-tests zijn geslaagd, kan het systeem de code promoten naar een productieomgeving, zodat deze beschikbaar wordt voor eindgebruikers.

Een van de belangrijkste voordelen van GitLab CI/CD is de nauwe integratie binnen GitLab zelf. Hierdoor kunt u CI/CD-pijplijnen direct binnen uw projectrepositories definiëren en beheren, wat de coördinatie en het overzicht van uw volledige workflow vereenvoudigt.

GitLab CI/CD ondersteunt een breed scala aan programmeertalen, frameworks en tools, waardoor het veelzijdig genoeg is voor uiteenlopende projecten. Het aanpasbare pijplijnensysteem stelt u in staat elke fase van het CI/CD-proces af te stemmen op uw behoeften, of het nu gaat om bouwen, testen of uitrollen naar meerdere omgevingen.

Samengevat is GitLab CI/CD een allesomvattende oplossing die is ontworpen om softwareleveringsprocessen te automatiseren en te optimaliseren. Ontwikkelaars kunnen zich zo richten op het schrijven en verbeteren van code, terwijl het platform efficiënt de operationele taken afhandelt.

Docker-images bouwen in uw GitLab CI

Als uw projectrepository Dockerfile-bestanden bevat, kunt u het proces van het bouwen, uitvoeren en – indien nodig – publiceren van Docker-images naar een registry automatiseren.

Stap 1: Docker in Docker (DinD) support inschakelen

Begin met het inschakelen van "Docker in Docker" (DinD) support in uw Stackhero-dashboard.

Het inschakelen van DinD support brengt een beveiligingsrisico met zich mee, vooral als u gebruikers wilt isoleren en wilt voorkomen dat zij toegang krijgen tot elkaars projecten.

Stap 2: De GitLab CI-pijplijn configureren

Werk vervolgens uw gitlab-ci.yml-bestand bij om een pijplijnconfiguratie op te nemen die uw Dockerfile bouwt met behulp van DinD. Hieronder vindt u een voorbeeldconfiguratie:

image: docker:29

build:
  stage: build
  services:
    - name: docker:29-dind
      alias: docker
  variables:
    # Wijs de docker CLI naar de Docker-in-Docker-service via de
    # niet-versleutelde (non-TLS) poort. Zie de opmerking hieronder over het belang van DOCKER_HOST.
    DOCKER_HOST: "tcp://docker:2375"
    DOCKER_TLS_CERTDIR: ""
  before_script:
    - docker info
  script:
    # Vervang "my-docker-image" door de gewenste naam van uw image:
    - docker build -t my-docker-image .
    # Optioneel: test de Docker-image:
    # - docker run my-docker-image /script/to/run/tests

De docker:29-dind-service start een Docker-daemon naast uw job, en DOCKER_HOST geeft aan de docker CLI door dat deze die daemon moet gebruiken. Stel altijd DOCKER_HOST in wanneer u een docker:dind-service declareert: als u dit weglaat, maakt de CLI ongemerkt verbinding met een andere daemon en kan uw build slagen, zelfs als de service verkeerd is geconfigureerd, waardoor echte problemen verborgen blijven. DOCKER_TLS_CERTDIR: "" zorgt ervoor dat poort 2375 (zonder TLS) op het interne jobnetwerk wordt gebruikt.

Als eenvoudig alternatief kunt u het hele services-blok en beide variabelen weglaten: de Stackhero-runner stelt al een kant-en-klare Docker-daemon beschikbaar via een gemounte socket, dus een eenvoudige docker build werkt direct.

Voor meer informatie over het bouwen van Docker-images met GitLab CI, raadpleeg de officiële GitLab-documentatie.

Uw tests uitvoeren met Testcontainers

Als uw testset gebruikmaakt van Testcontainers, een bibliotheek die echte services (zoals databases, message brokers en meer) als tijdelijke Docker-containers opstart tijdens het uitvoeren van tests, dan is bovenstaande configuratie al geschikt. Behoud de docker:29-dind-service en beide variabelen: Testcontainers gebruikt DOCKER_HOST om de Docker-daemon te bereiken en verbinding te maken met de containers die het opstart, dus verdere aanpassingen zijn niet nodig.

Het niet instellen van DOCKER_HOST is de meest voorkomende oorzaak van Testcontainers-fouten in CI. De bibliotheek valt dan terug op de Docker-socket die door de runner is gemount, en kan zijn eigen testcontainers niet bereiken, wat meestal zichtbaar wordt als een timeout van de Ryuk-helpercontainer.