GitLab Runner: Docker atvaizdų kūrimas

Kurkite ir įkelkite Docker atvaizdus iš savo GitLab CI/CD pipeline naudodami Stackhero runner ir Docker-in-Docker

👋 Sveiki atvykę į Stackhero dokumentaciją!

Stackhero siūlo lengvai naudojamą GitLab Runner cloud sprendimą, sukurtą efektyviam jūsų GitLab CI/CD užduočių vykdymui. Štai ko galite tikėtis:

  • Neribotos CI/CD minutės: nėra apmokestinimo už kiekvieną minutę, todėl jūsų pipelines gali būti vykdomi bet kada, kai tik reikia.
  • Kelios vienu metu vykdomos užduotys: paleiskite kelis darbus vienu metu, kad pagreitintumėte visą pipeline procesą.
  • Docker executor su Docker-in-Docker palaikymu: supaprastinkite konteinerių atvaizdų kūrimą ir jų įkėlimą (push).
  • Suderinama su GitLab.com ir bet kuria self-managed GitLab instancija.
  • Privati, dedikuota VM, veikianti su greitais NVMe/SSD diskais, užtikrinančiais nuoseklius ir patikimus build'us.
  • Pasiekiama tiek 🇪🇺 Europoje, tiek 🇺🇸 JAV regionuose.

Taupykite laiką: galite prijungti savo pirmąjį GitLab Runner ir pradėti vykdyti pipelines vos per kelias minutes!

Naudojant Stackhero GitLab Runner, užduotys vykdomos su Docker executor. Tai reiškia, kad kiekviena užduotis pradedama naujame konteineryje, pagrįstame jūsų nurodyta image. Jei norite savo pipeline metu kurti Docker atvaizdus, galite pasinaudoti Docker-in-Docker (DinD) galimybėmis. Ši konfigūracija leidžia Docker daemon veikti greta jūsų užduoties, todėl galite tiesiogiai pipeline viduje vykdyti komandas kaip docker build ir docker push.

Vienas iš didžiausių privalumų yra tas, kad jūsų runner turi neribotą CI/CD minučių kiekį. Galite kurti atvaizdus tiek dažnai, kiek reikia. Be to, kadangi jūsų build cache saugomas runner dedikuotame diske, pakartotiniai build'ai gali naudoti ankstesnius sluoksnius, todėl pipeline užbaigiami daug greičiau.

Štai pavyzdinis .gitlab-ci.yml, kurį galite pridėti prie savo repozitorijos. Ši konfigūracija sukuria šakniniame projekte esantį Dockerfile:

build-image:
  stage: build
  image: docker:27
  services:
    - docker:27-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  before_script:
    - docker info
  script:
    # Pakeiskite "my-image" norimu pavadinimu:
    - docker build -t my-image .
    # Papildomai galite atlikti greitą smoke test sukurtam atvaizdui:
    # - docker run --rm my-image /path/to/tests

Šioje konfigūracijoje docker:27-dind servisas paleidžia Docker daemon. Kintamasis DOCKER_TLS_CERTDIR: "/certs" užtikrina saugų TLS ryšį tarp jūsų užduoties ir Docker daemon.

GitLab pateikia keletą iš anksto apibrėžtų kintamųjų (CI_REGISTRY, CI_REGISTRY_USER, CI_REGISTRY_PASSWORD, CI_REGISTRY_IMAGE), todėl jūsų pipeline gali prisijungti ir įkelti atvaizdus į projekto container registry be papildomų slaptažodžių.

Štai pavyzdinė užduotis, kuri sukuria ir įkelia jūsų atvaizdą:

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"
    # Jei esate numatytoje šakoje, galite taip pat pažymėti ir įkelti "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

Jei norite įkelti atvaizdus į kitą registry (pvz., Docker Hub ar privatų registry), galite šiuos prisijungimo duomenis saugoti kaip CI/CD kintamuosius ir naudoti juos su docker login tokiu pačiu principu.

Kadangi runner diskas išlieka tarp pipeline, galite pagreitinti build'us naudodami ankstesnių atvaizdų sluoksnius kaip cache. Štai kaip tai galima nustatyti:

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:
    # Bandykite atsisiųsti naujausią atvaizdą cache'ui (jei jo dar nėra, klaida nesvarbi):
    - 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"

Šis metodas leidžia jūsų pipeline laikui bėgant veikti greičiau, maksimaliai išnaudojant Docker sluoksnių cache.

Jūsų planas nurodo, kiek užduočių gali būti vykdoma vienu metu. Tos pačios stadijos užduotys startuoja kartu, iki jūsų nustatyto lygiagretumo limito. Tai reiškia, kad stadijoje esant kelioms nepriklausomoms užduotims, jos visos baigsis, kai lėčiausia užduotis bus įvykdyta, o ne viena po kitos.

Štai paprastas pavyzdys:

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

Jei nustatysite lygiagretumą 3 ar daugiau, unit, integration ir e2e užduotys bus vykdomos vienu metu.

Jei norite išsamiau susipažinti su Docker atvaizdų kūrimu CI aplinkoje, kviečiame peržiūrėti oficialią GitLab dokumentaciją.