GitLab: CI/CD

Kaip naudoti GitLab CI/CD

👋 Sveiki atvykę į Stackhero dokumentaciją!

Stackhero siūlo paruoštą naudoti GitLab cloud sprendimą, sukurtą komandoms, kurioms reikalinga greita, saugi ir lengvai plečiama aplinka:

Neribotas naudotojų, saugyklų, duomenų perdavimų ir CI/CD apdorojimo laikas – visiška lankstumo laisvė.

Paprasti atnaujinimai vienu paspaudimu – jūsų aplinka visada bus naujausia be prastovų.

Individualus domeno vardas su HTTPS apsauga (pavyzdžiui, https://git.jusu-imone.lt) – profesionaliam įvaizdžiui ir saugumui.

Nuoseklus veikimas ir aukštas saugumo lygis jūsų privačioje, dedikuotoje infrastruktūroje. Jokio triukšmingų kaimynų poveikio, visiška izoliacija.

Galimybė pasirinkti talpinimo vietą: 🇪🇺 Europa arba 🇺🇸 USA pagal jūsų atitikties ar vėlinimo poreikius.

Pradėkite greitai ir susitelkite į savo kodą. Stackhero GitLab cloud hosting sprendimas paruoštas naudoti maždaug per 5 minutes.

Įvadas

GitLab CI/CD yra galinga ir integruota GitLab funkcija – tai populiari atvirojo kodo platforma versijų valdymui ir komandiniam darbui. Šis įrankis leidžia automatizuoti ir optimizuoti svarbiausius programinės įrangos kūrimo, testavimo ir diegimo etapus, užtikrinant greitesnį ir patikimesnį aukštos kokybės aplikacijų pristatymą.

Pavyzdžiui, naudodami GitLab CI/CD galite sukonfigūruoti automatinius vienetinius testus, kurie bus paleidžiami kiekvieną kartą, kai į GitLab repozitoriją bus įkeltas naujas commit. Sėkmingai praėjus šiems testams, jūsų kodas gali būti sukompiliuotas ir įdiegtas į staging aplinką tolimesniam vertinimui. Atlikus visus testus staging aplinkoje, sistema gali perkelti kodą į production aplinką, padarydama jį prieinamą galutiniams naudotojams.

Viena iš pagrindinių GitLab CI/CD savybių – glaudi integracija pačiame GitLab. Tai leidžia CI/CD pipeline'us apibrėžti ir valdyti tiesiogiai jūsų projekto repozitorijose, supaprastinant viso darbo srauto organizavimą ir stebėjimą.

GitLab CI/CD palaiko platų programavimo kalbų, karkasų (frameworks) ir įrankių spektrą, todėl yra pakankamai universalus įvairiems projektams. Lanksti pipeline sistema leidžia kiekvieną CI/CD proceso etapą pritaikyti pagal jūsų poreikius – ar tai būtų kūrimas, testavimas, ar diegimas į kelias aplinkas.

Apibendrinant, GitLab CI/CD yra visapusiškas sprendimas, skirtas automatizuoti ir pagerinti programinės įrangos pristatymo procesus. Tai leidžia programuotojams susitelkti į kodo rašymą ir tobulinimą, o platforma efektyviai pasirūpina operacinėmis užduotimis.

Kaip kurti Docker atvaizdus su GitLab CI

Jei jūsų projekto repozitorijoje yra Dockerfile failų, galite automatizuoti Docker atvaizdų kūrimą, paleidimą ir, jei reikia, publikavimą į registrą.

1 žingsnis: Įjunkite Docker in Docker (DinD) palaikymą

Pirmiausia Stackhero valdymo skydelyje įjunkite "Docker in Docker" (DinD) palaikymą.

DinD palaikymo įjungimas kelia saugumo riziką, ypač jei norite izoliuoti naudotojus ir neleisti jiems pasiekti vieni kitų projektų.

2 žingsnis: Konfigūruokite GitLab CI pipeline

Toliau atnaujinkite savo gitlab-ci.yml failą, kad įtrauktumėte pipeline konfigūraciją, kuri naudoja DinD jūsų Dockerfile kūrimui. Žemiau pateiktas pavyzdinis konfigūracijos variantas:

image: docker:29

build:
  stage: build
  services:
    - name: docker:29-dind
      alias: docker
  variables:
    # Nukreipia docker CLI į Docker-in-Docker servisą per jo paprastą
    # (ne-TLS) prievadą. Žr. žemiau esančią pastabą, kodėl svarbus DOCKER_HOST.
    DOCKER_HOST: "tcp://docker:2375"
    DOCKER_TLS_CERTDIR: ""
  before_script:
    - docker info
  script:
    # Pakeiskite "my-docker-image" į norimą atvaizdo pavadinimą:
    - docker build -t my-docker-image .
    # Papildomai, galite patikrinti Docker atvaizdą:
    # - docker run my-docker-image /script/to/run/tests

docker:29-dind servisas paleidžia Docker daemon'ą šalia jūsų darbo, o DOCKER_HOST nurodo docker CLI naudoti būtent jį. Visada nustatykite DOCKER_HOST, kai deklaruojate docker:dind servisą: jei to nepadarysite, CLI tyliai prisijungs prie kito daemon'o, ir jūsų build'as gali pavykti net jei servisas sukonfigūruotas neteisingai, taip paslepiant tikrąsias problemas. DOCKER_TLS_CERTDIR: "" leidžia naudoti paprastą, nešifruotą 2375 prievadą vidiniame darbo tinkle.

Kaip paprastesnę alternatyvą, galite visiškai pašalinti services bloką ir abi kintamąsias: Stackhero runner'is jau pateikia paruoštą naudoti Docker daemon'ą per prijungtą socket'ą, tad paprasta docker build komanda veikia iš karto.

Daugiau informacijos apie Docker atvaizdų kūrimą su GitLab CI rasite oficialioje GitLab dokumentacijoje.

Testų paleidimas su Testcontainers

Jei jūsų testų rinkinys naudoja Testcontainers – biblioteką, kuri testų metu paleidžia realias paslaugas (duomenų bazes, žinučių brokerius ir kt.) kaip laikinas Docker konteinerius – aukščiau pateikta konfigūracija jau yra tinkama. Palikite docker:29-dind servisą ir abu kintamuosius: Testcontainers naudoja DOCKER_HOST, kad pasiektų Docker daemon'ą ir prisijungtų prie paleistų konteinerių, tad papildomos konfigūracijos nereikia.

Dažniausia Testcontainers gedimų CI aplinkoje priežastis – nenustatytas DOCKER_HOST. Tuomet biblioteka bando naudoti runner'io prijungtą Docker socket'ą ir negali pasiekti savo testavimo konteinerių, o tai dažniausiai pasireiškia Ryuk helper konteinerio timeout'u.