Kako postaviti GitLab Continuous Integration (CI) cjevovode na Ubuntu 20.04

Svaki programer razumije koliko je kontrola verzija ključna za životni ciklus razvoja softvera. Ona omogućuje većem broju ljudi da istovremeno rade na jednom projektu, pri čemu svaka osoba održava vlastitu kopiju koda i bira kada će je podijeliti s ostatkom tima. Kako bi to postigli, programeri koriste Git repozitorije kako bi si pomogli s kontrolom verzija. GitLab je web-bazirani Git repozitorij koji je više od alata za kontrolu verzija. Dodatno pruža DevOps alate, praćenje problema, kontinuiranu integraciju i isporuku.

GitLab nudi tri opcije koje možete odabrati: GitLab Community Edition (CE), GitLab Enterprise Edition (EE) i GitLab SaaS. GitLab CE i GitLab EE su self-managed rješenja. To znači da sami preuzimate, instalirate i upravljate GitLab instancom. GitLab SaaS hostira GitLab Inc. Stoga ne morate brinuti o instaliranju bilo čega kako biste ga koristili. Trebate samo izraditi GitLab račun i započeti.

U ovom vodiču, pokazat ćemo vam kako postaviti cjevovode kontinuirane integracije s GitLab CI kako biste pratili promjene u svojim repozitorijima i pokretali automatizirane testove za provjeru novog koda. Započet ćemo postavljanjem Git repozitorija za hostiranje koda. Zatim ćemo konfigurirati CI proces za praćenje commitova u repozitorij i pokrenuti CI runner za izvođenje testova u izoliranom Docker spremniku.

Preduvjeti

Za početak, trebat će vam poslužitelj na kojem se izvodi GitLab softver za kontrolu verzija. I GitLab self-managed i SaaS mogu pokretati automatizirane testove. Međutim, postoje određena ograničenja u pogledu minuta i resursa koji su stavljeni na raspolaganje vašim testovima u besplatnim SaaS opcijama. Imate više slobode ako koristite self-managed opcije jer možete dodijeliti onoliko resursa koliko želite svojoj GitLab instanci. Pratite naš vodič o hostiranju vlastitih Git repozitorija s GitLabom kako biste naučili kako postaviti vlastitu GitLab instancu.

Trebat će vam barem jedan poslužitelj koji ćete koristiti kao GitLab CI runner. Međutim, ako želite, možete imati i više poslužitelja. Ako ste postavili self-managed GitLab instancu, možete koristiti isti poslužitelj, ali mi radije postavljamo drugi poslužitelj za CI runner. Ovaj vodič o Kako postaviti svoj Ubuntu poslužitelj dobar je početak.

Trebat će vam instaliran Docker na vašim GitLab CI runner poslužiteljima kako biste izolirali testna okruženja u Docker spremnicima. Imamo vodič o Kako instalirati i upravljati Dockerom na Ubuntuu koji vam može pomoći da ispunite ovaj zahtjev.

Sada kada imamo sve što nam treba, počnimo!

Korak 1: Izradite projekt na GitLab instanci

Započet ćemo stvaranjem repozitorija projekta na GitLabu. Ovaj ćemo vodič temeljiti na Node.js aplikaciji. Budući da ne želimo stvarati projektne datoteke ispočetka, GitLab nudi alat za uvoz projekata iz drugih repozitorija za kontrolu verzija koji ćemo iskoristiti. Aplikacija koju uvozimo je jednostavna “hello world” aplikacija izgrađena pomoću Express.js – minimalističkog web okvira za Node.js aplikacije. Testove ćemo implementirati koristeći Mocha i Chai – to su JavaScript okviri koji se koriste za jedinično testiranje. Mocha omogućuje asinkrono testiranje, izvješća o pokrivenosti testovima i može se upariti s drugim bibliotekama tvrdnji. Chai je biblioteka tvrdnji. Može se upariti s bilo kojim testnim okvirom, a u našem slučaju uparit ćemo Mochu s Chaijem.

Sada kada znate osnove našeg projekta, prijavite se na svoju GitLab instancu (bilo self-managed ili SaaS), kliknite na ‘plus’ ikonu na gornjoj navigacijskoj traci i odaberite ‘New project’. Opcijski, ako se pomaknete na vrh početne stranice svog računa, možete kliknuti na gumb ‘New project’:

Na stranici novog projekta kliknite na karticu Import project:

Zatim na otvorenoj stranici kliknite na gumb Repo by URL:

Iako postoji opcija uvoza s GitHuba, nećemo je koristiti jer zahtijeva osobni pristupni token. Ne moramo postavljati osobne pristupne tokene jer radimo s javnim repozitorijem, a uvoz samo pomoću URL-a je jednostavan.

Nakon toga kopirajte sljedeći URL i zalijepite ga u polje Git Repository URL:

Trebalo bi izgledati ovako:

Ostavite repozitorij kao Private i kliknite gumb Create project kada završite. Pričekajte nekoliko sekundi da se projekt uveze s GitHuba i on će se pojaviti među vašim GitLab repozitorijima. GitLab uvozi projekt s istim detaljima kao i projekt GitHub repozitorija.

Korak 2: Analiza datoteke .gitlab-ci.yml

GitLab CI pretražuje svaki repozitorij na GitLabu tražeći datoteku pod nazivom .gitlab-ci.yml kako bi znao kako pokrenuti automatizirane testove. U repozitoriju koji smo upravo uvezli možete vidjeti .gitlab-ci.yml datoteku među datotekama projekta. Više informacija o GitLab CI yml možete pronaći na njihovoj službenoj dokumentaciji Keyword reference za .gitlab-ci.yml datoteku.

Dok ste u sučelju GitLab repozitorija, kliknite na .gitlab-ci.yml datoteku kako biste je otvorili u stranici preglednika. Trebala bi izgledati ovako:

Obratite pozornost na uvlačenje redaka. Datoteka slijedi strogu GitLab CI YAML sintaksu konfiguracije kako bi se definirale različite radnje koje treba poduzeti, u određenom redoslijedu pod određenim uvjetima. Kako biste osigurali da su vaše konfiguracijske datoteke ispravne, GitLab nudi testni alat za validaciju. Unutar svoje GitLab instance, u repozitoriju projekta, možete posjetiti sučelje CI lint kako biste validirali svoj .gitlab-ci.yml. Kliknite na CI/CD u lijevom navigacijskom izborniku i kliknite na gumb CI lint na stranici koja se pojavi:

Direktive u konfiguracijskoj datoteci objašnjene su u nastavku.

• Osnovna Docker slika

Prvi redak u konfiguracijskoj datoteci deklarira Docker sliku koja bi se trebala koristiti za pokretanje testova. Budući da gradimo Node.js aplikaciju, koristit ćemo najnoviju Node.js sliku:

• Faze

Zatim definiramo različite faze kroz koje želimo da naši testovi kontinuirane integracije prođu. Imamo samo dvije faze:

Prilikom definiranja naziva faza, nazivi poput build ili test odabrani su proizvoljno – možete odabrati bilo koji naziv koji želite. Međutim, morate ispravno poredati faze jer to određuje tijek izvršavanja. U našem slučaju, poslovi u build fazi izvršavaju se prije poslova u test fazi. GitLab runner će izvršavati poslove u istoj fazi paralelno i pričekat će da svi poslovi završe prije nego što počne izvršavati poslove u sljedećoj fazi.

• Predmemorija

Definicija cache uključena je kako bi se odredile datoteke i direktoriji koji će se predmemorirati ili spremiti za kasniju upotrebu između pokretanja poslova:

Definiranje predmemoriranja pomaže smanjiti vrijeme potrebno za pokretanje poslova koji se oslanjaju na resurse za koje je malo vjerojatno da će se promijeniti između pokretanja. Specificiramo node_modules direktorij za predmemoriranje. To je direktorij u koji npm instalira ovisnosti za projekt.

• Poslovi

Imamo dva posla u konfiguraciji:

• install_dependencies

Prilikom imenovanja poslova, slobodni ste odabrati bilo koji naziv. Međutim, preporučuje se odabrati opisni naziv jer se oni koriste u GitLab sučelju – to može biti korisno tijekom otklanjanja pogrešaka. Naći ćete većinu konfiguracija na webu koje kombiniraju npm install s naredbama u testnoj fazi. Razdvojili smo ih samo kako bismo lakše prikazali kako poslovi međusobno komuniciraju jer se radi o prilično malom projektu. stage direktiva označava ovaj posao kao build – on se izvodi u build fazi.

Direktiva script specificira naredbe koje se izvode u izvršavanju ovog posla. Možete navesti više naredbi dodavanjem redaka unutar script bloka. Naravno, morate paziti na ispravno uvlačenje i imati na umu redoslijed kojim bi se skripte trebale izvršavati.

Direktiva artifacts specificira datoteke ili putanje direktorija koje treba spremiti i dijeliti između faza. Još jednom, podsjetnik da je ispravan redoslijed faza ključan kako bi se osiguralo da druge datoteke imaju ono što im je potrebno za izvršavanje. Naredba npm install instalirat će zavisnosti u node_modules direktoriju. Deklariranjem u artefaktima (artifacts), činimo ga dostupnim poslovima koji se izvršavaju u sljedećim fazama. Datoteke su također dostupne u GitLab sučelju ako ih želite preuzeti.

• test_with_mocha

Ovaj se posao izvodi u test fazi. Budući da se ovaj posao izvodi nakon što se pokrene posao u build fazi, artefakti deklarirani u build fazi (koji su zavisnosti za našu aplikaciju) bit će dostupni test fazi. Blok skripte specificira npm naredbe za pokretanje naših testova. Prvo pokrećemo našu aplikaciju, a zatim pokrećemo testove na aplikaciji. Pokretanje ovih naredbi aktivira naredbe navedene u package.json sekciji bloka skripte:
S time biste trebali imati osnovno razumijevanje .gitlab-ci.yml datoteke. Kažemo osnovno jer je ovo samo statična hello world aplikacija. Zatim, pogledajmo kako možemo pokrenuti novo CI izvršavanje.

Korak 3: Pokretanje GitLab CI izvršavanja

Bit će vam drago znati da kada vaše spremište ima .gitlab-ci.yml datoteku, sve nove predaje koje pošaljete na nju pokrenut će novo Continuous Integration izvršavanje. U slučaju samostalno upravljanih GitLab instanci, ako niste konfigurirali GitLab runner, CI izvršavanje bit će postavljeno na „na čekanju” (pending).

GitLab SaaS korisnicima pruža neke zajedničke runnere koji mogu preuzeti njihove poslove i automatski ih izvršiti. To je moguće samo ako su zajednički runneri slobodni i ako niste premašili svoju kvotu. U GitLab SaaS-u možete odabrati želite li da vaše spremište koristi shared runners ili ne tako da odete na stranicu vašeg projekta Settings > CI / CD kako je prikazano na snimci zaslona u nastavku. Na ovoj stranici također ćete pronaći informacije o uputama za instalaciju GitLab runnera, u što ćemo se detaljnije upustiti u sljedećem koraku:

Sada napravimo malu promjenu kako bismo pokrenuli CI izvršavanje. Vratite se u svoje node_pipeline GitLab projektno spremište:

Kliknite na README.md datoteku istaknutu iznad kako biste je pregledali:

Kliknite na gumb ‘Edit’ kako biste otvorili datoteku za uređivanje u pregledniku i dodali tekst:

Nakon što dodate tekst, pomaknite se prema dolje i kliknite gumb Commit changes kako biste spremili promjene. Poruku predaje možete izmijeniti po želji. Pojavit će se kao naslov u GitLab sučelju kada se cjevovod izvodi. Ostavili smo je kao Update README.md jer je prilično opisna:

Nakon što ste predali promjene, vratite se na glavnu stranicu projekta. Primijetit ćete malu ikonu pauze pridruženu najnovijoj predaji. Ako prijeđete mišem preko ikone, prikazat će se: ‘Pipeline:pending’:

To znači da je CI izvršavanje pokrenuto. Međutim, testovi još nisu pokrenuti. U navigacijskom izborniku s lijeve strane kliknite na CI/CD, a zatim odaberite Pipelines. To će otvoriti stranicu s više pojedinosti o cjevovodu. Možete vidjeti da je CI na čekanju i označen kao zaglavljen:

Da biste dobili više pojedinosti o izvršavanju, kliknite na status pending. Vidjet ćete prikaz u nastavku koji prikazuje različite faze izvršavanja i pojedinačne poslove povezane sa svakom fazom:

Također možete kliknuti na pojedinačne poslove kako biste vidjeli njihove detaljnije pojedinosti, poput onoga što uzrokuje kašnjenja. U slučaju neuspjelih pokretanja, ovdje ćete vidjeti što je uzrokovalo neuspjeh posla:

Poruka ukazuje na to da je posao zapeo jer niste konfigurirali nijedan aktivni runner koji može izvršiti ovaj posao. To ćemo učiniti u sljedećem koraku. Kada omogućite runner, posao će se početi automatski izvršavati. Kada se posao izvršava, vidjet ćete izlaz na ovom sučelju, kao i druge artefakte za preuzimanje generirane tijekom izvođenja posla.

Korak 4: Postavljanje GitLab CI Runner usluge

Sada je vrijeme da iskoristimo drugi poslužitelj koji smo naveli u odjeljku Preduvjeti ovog vodiča. Instalirat ćemo i postaviti GitLab runner uslugu na ovom poslužitelju. Možete implementirati uslugu za pokretanje više instanci runnera za različite projekte na GitLabu.

Imate opciju implementirati runner na istom poslužitelju koji hostira vašu samostalno upravljanu GitLab instancu. Međutim, kako biste osigurali da instanca nije ograničena resursima, poželjno je postaviti zasebnu instancu CI runnera. Koju god konfiguraciju odabrali, Docker mora biti instaliran kako bi se izolirala testna okruženja.

Postupak instalacije GitLab CI runnera usporediv je s onim za instalaciju samostalno upravljane GitLab instance. Počinjemo preuzimanjem skripte za dodavanje službenog GitLab repozitorija u apt izvore pomoću sljedeće naredbe:

Unesite svoju root lozinku kada se to od vas zatraži. Zatim možete pokrenuti naredbu za instalaciju najnovijeg GitLab CI runnera:

Gornja naredba instalira i registrira uslugu runnera spremnu za korištenje u vašim projektima.

Korak 5: Dobivanje registracijskih tokena i povezivanje GitLab Runnera

Da biste postavili GitLab CI runner da počne prihvaćati poslove, potreban vam je GitLab runner token. On je potreban kako bi se runner autentificirao s vašom instancom GitLab poslužitelja. Postoje dvije vrste tokena ovisno o tome kako želite koristiti runner: specifični za projekt i zajednički runner.

Runneri specifični za projekt primjenjivi su ako imate jedinstvene zahtjeve za runner. Na primjer, ako imate definicije implementacije u svojoj gitlab-ci.yml s jedinstvenim tokenima, tada se može preporučiti specifični runner za ispravnu autentifikaciju u okruženju implementacije. Još jedna stvar koju treba uzeti u obzir jest imaju li vaše faze kontinuirane integracije procese koji zahtijevaju mnogo resursa. U tom slučaju, idealno bi bilo odabrati runner specifičan za projekt. Imajte na umu da runner specifičan za projekt ne prihvaća poslove iz drugih projekata.

Zajednički runneri opće su namjene i može ih koristiti više projekata. GitLab SaaS instanca hostirana na GitLab Inc ima neke zajedničke runnere koji će automatski preuzeti vaše cjevovode (pipelines) kao što je objašnjeno u Trećem koraku. Runneri preuzimaju poslove iz vaših konfiguracija na temelju algoritma koji uzima u obzir broj poslova koji se trenutno izvršavaju za svaki projekt. Zajednički runner je fleksibilniji od specifičnog runnera. Može se konfigurirati s administratorskog računa GitLab instance. Pogledajmo kako možemo doći do tokena za oba runnera.

• Registracija runnera specifičnog za projekt

Da biste registrirali runner specifičan za projekt, otvorite svoj projekt u svojoj GitLab instanci ili GitLab SaaS računu. Na navigacijskom izborniku s lijeve strane kliknite stavku Settings i odaberite CI/CD opciju:

Nakon toga se pomaknite prema dolje do odjeljka Runners i kliknite gumb za proširenje odjeljka:

Lijeva strana objašnjava kako registrirati runner specifičan za projekt. Ovo je prikaz GitLab SaaS instance. Također možete konfigurirati automatske runnere s Kubernetesom, ali u ovom vodiču radimo ručni runner:

Zatim se trebate usredotočiti na odjeljak u kojem dobivate token za ovaj projekt. Za samostalno upravljanu instancu GitLaba, URL će prikazati domenu poslužitelja na kojem se izvodi vaša instanca GitLaba:

Možete onemogućiti zajedničke pokretače za ovaj projekt prebacivanjem prekidača u desnom odjeljku pod Shared Runners. Zatim kopirajte prikazani registracijski token u svoju bilježnicu, jer ćemo ga koristiti kasnije.

• Registracija zajedničkog pokretača

Da biste registrirali zajednički pokretač, morate se prijaviti u svoju samostalno upravljanu instancu GitLaba kao administrator. Za pristup administratorskoj ploči, kliknite na ključ ikonu u gornjem navigacijskom izborniku:

U Admin Panel, kliknite na Runners u odjeljku Overview lijevog izbornika. To će otvoriti stranicu s uputama za konfiguraciju Shared Runners:

Kopirajte registracijski token prikazan na desnoj strani pod Set up a shared Runner manually. Koristit ćete token za registraciju pokretača u sljedećem koraku.

• Povezivanje GitLab CI pokretača s GitLab instancom

U ovom koraku povezat ćete svoju GitLab instancu s CI pokretačem. Prijavite se natrag na poslužitelj na kojem ste instalirali uslugu GitLab pokretača u Step Four. Za početak postupka registracije pokretača, unesite sljedeću naredbu u svoj terminal:

Naredba će vam postaviti niz pitanja:

• Enter the GitLab instance URL (for example, https://gitlab.com/):

Navedite naziv domene vaše GitLab instance koristeći https:// za određivanje SSL-a.

• Enter the registration token:

Navedite svoj registracijski token. Ovdje ćete odabrati želite li da ovaj pokretač bude specifičan za projekt ili zajednički. Možete unijeti samo jedan od tokena koje ste prethodno kopirali za bilo koju od opcija.

• Enter a description for the runner:

Odaberite opisni naziv za svoj CI pokretač jer će se on pojaviti u sučelju GitLab instance.

• Enter an executor: custom, docker-ssh, parallels, virtualbox, docker, shell, ssh, docker+machine, docker-ssh+machine, kubernetes:

Ovdje vam nudi opcije za odabir izvršitelja za pokretanje poslova. Unesite Docker.

• Enter tags for the runner (comma-separated):

Ovo je neobavezno. Možete unijeti bilo koje nazive oznaka, poput ovisnosti koje ovaj pokretač uključuje. Za sada možete ostaviti prazno.

• Enter the default Docker image (for example, ruby:2.6):

Ovdje se od vas očekuje da odredite zadanu sliku opće namjene koja se koristi za pokretanje poslova u slučaju da gitlab-ci.yml datoteka ne specificira sliku. Unesite alpine:latest jer je to mala, općenamjenska i sigurna slika. Pritisnite enter i pokretač će se automatski registrirati i pokrenuti:

Za pregled popisa trenutno dostupnih pokretača, unesite sljedeću naredbu:

Korak 6: Potvrda da je CI pokretač uspješno povezan u GitLabu

Zatim se vratite u svoj preglednik i posjetite stranicu svog projekta u GitLab instanci. Ovisno o tome koliko je minuta prošlo otkako ste registrirali pokretač, možda ćete vidjeti da se posao trenutno izvodi:

Ili je možda već završen:

Nakon toga idite na stranicu Pipelines bilo putem lijevog izbornika CI/CD > Pipelines, ili klikom na ikonu running, passed, ili failed (ako je cjevovod naišao na pogreške) kako biste vidjeli stanje CI pokretanja. Ovdje možemo vidjeti da je jedna od faza (build stage) prošla, dok se jedna još uvijek izvodi:

U tablici, pod zaglavljem Stages, kliknite na jednu od ikona faza kako biste vidjeli povezane poslove:

Zatim kliknite na posao u skočnom prozoru za prikaz pojedinosti:

Posao se pokrenuo i možete vidjeti napredak kada je npm naredba instalirala ovisnosti. Na desnoj strani možete vidjeti druge povezane informacije. Imate opciju preuzimanja artefakata iz posla. Također se možete prebacivati između faza kako biste vidjeli druge poslove iz padajućeg izbornika.

Ovdje možete vidjeti naše testne slučajeve koji se prikazuju kada odaberete posao u testnoj fazi:

Available Runners

Na lijevom izborniku, ako kliknete Settings > CI/CD, i proširite Runners sekciji, trebali biste vidjeti runnera kojeg ste upravo registrirali. Ovisno o tome jeste li naveli token specifičan za projekt ili zajednički token, runner će se pojaviti u odgovarajućoj sekciji.

Ovdje možete vidjeti da smo registrirali token specifičan za projekt. Runner se pojavljuje pod Specific Runners:

Zaključak

U ovom vodiču naučili ste kako možete automatizirati svoje testove pomoću GitLab CI-ja. Započeli smo postavljanjem projekta Node.js aplikacije na GitLabu. Projekt je uključivao nekoliko testnih slučajeva i gitlab-ci.yml. Naučili smo da GitLab koristi gitlab-ci.yml datoteku kako bi odredio što učiniti kada se pokrene. gitlab-ci.yml datoteka je samo konfiguracijska datoteka koja sadrži upute o izgradnji i testiranju aplikacija, napisana u YAML formatu koji GitLab CI runner može razumjeti.

Također smo uspjeli postaviti GitLab CI runner na zasebnom hostu. Registrirali smo ga da preuzima poslove s naših GitLab instanci kad god se aktivira okidač. Iako je ovo bio jednostavan projekt, na temelju ovih informacija možete izgraditi pipelineove za složene projekte. Koraci za dodavanje projekta na GitLab i povezivanje GitLab CI runnera ostaju isti. Ono što se mijenja su upute i faze u gitlab-ci.yml datoteci.

Sretno s radom!