Odprtokodni DevOps v velikem obsegu: GitLab v lastni režiji

laptop screen showing code in a busy room

Izvorna koda je edino premoženje, za katero se skoraj vsa tehnološka podjetja strinjajo, da je ključno, in hkrati tisto, ki ga večina hrani na infrastrukturi, ki je nima v lasti, v jurisdikciji, ki je ni izbrala, po pogodbi, ki je ni skrbno prebrala. Običajno je ta ureditev povsem v redu. Vseeno je vredno vedeti, koliko stane alternativa, saj GitLab že več kot desetletje omogoča, da je gostovanje celotnega razvojnega cikla pri sebi resnično izvedljivo.

Je tudi izdelek, katerega brezplačna stopnja je radodarnejša, breme obratovanja pa težje, kot večina pričakuje. Oboje je treba razumeti pred odločitvijo, zato ta vodnik govori o tem, kaj GitLab v lastni režiji v resnici je, kaj brezplačna stopnja zares da in katere tri operativne težave prinesejo večino bolečine.

Kaj je GitLab

Ne gostovanje Gita s privijačenimi dodatki. Aplikacija v Railsih, PostgreSQL, Redis, Gitaly za shranjevanje repozitorijev, Sidekiq za opravila v ozadju in register vsebnikov, zapakirani skupaj kot en sistem, ki pokriva nadzor različic, pregled kode, sledenje zahtevkom, CI/CD, registre paketov in vsebnikov, varnostno pregledovanje in nameščanje.

Prav ta širina je celoten argument. GitHub plus Actions plus Dependabot plus register paketov plus orodje za sledenje projektu dajo primerljiv nabor funkcij, sestavljen iz delov. GitLab je ena aplikacija z enim modelom pravic in eno bazo. To je bodisi natanko tisto, kar želite, bodisi več, kot potrebujete, kaj od tega pa je odvisno od tega, kolikšen del cikla resnično nameravate voditi na enem mestu.

Arhitekturno pomembno dejstvo je isto kot pri gostovanju analitike z Matomom, avtomatizaciji trženja z Mautic ali timskem klepetu z Mattermost: teče tam, kamor ga postavite. Vaši repozitoriji, vaši dnevniki CI, vaši artefakti, vaša baza.

Licenčna slika, povedano naravnost

To res zmede in si zasluži natančnost, saj gre zmeda v nasprotno smer od pričakovane.

Obstajata dve distribuciji izvorne kode. Community Edition je pod licenco MIT. Enterprise Edition ima lastno, strožjo licenco, ki pokriva imenik ee/ v repozitoriju. Doslej zveni kot običajni model odprtega jedra.

Preseneti tole: paket za Linux, ki ga namesti skoraj vsak, je gradnja Enterprise Edition, in brez vnesenega licenčnega ključa teče kot stopnja Free ter se vede kot Community Edition. Torej ne poganjate distribucije pod licenco MIT, razen če ste namenoma izbrali paket CE. V praksi to redko šteje, a če je vaš razlog za lastno gostovanje stroga odprtokodna politika in ne nadzor nad podatki, potem šteje zelo, in skoraj nihče tega ne preveri.

Komercialne stopnje so Free, Premium po 29 dolarjev na uporabnika mesečno ob letnem obračunu in Ultimate po ceni na povpraševanje. Premium doda napredni CI/CD, boljše vodenje projektov in prednostno podporo. Ultimate doda paket varnosti in skladnosti: testiranje varnosti aplikacij, varnost dobavne verige, pregledovanje odvisnosti. Obe plačljivi stopnji zdaj vključujeta GitLab Credits za funkcije umetne inteligence, 12 dolarjev na uporabnika mesečno pri Premiumu in 24 pri Ultimatu.

In tu je dejstvo, ki večini ekip spremeni račun, ter natanko obratno od položaja pri Mattermostu: stopnja Free v lastni režiji nima omejitve uporabnikov. Meja petih uporabnikov, o kateri so ljudje slišali, velja samo za zasebne skupine na GitLab.com. Samostojno gostovan Free vam da neomejeno uporabnikov, nadzor različic, CI/CD in registre, hrambo in izvajalce pa prinesete sami. Organizacija stotih inženirjev lahko v celoti teče na njem.

Odpoveste se varnostnemu pregledovanju, poročanju o skladnosti, naprednim pravilom odobritev in podpori. Če ste zavezani aktu o kibernetski odpornosti in želite pregledovanje odvisnosti in ustvarjanje SBOM vgrajeno v cevovode namesto sestavljeno iz ločenih orodij, je to pogovor o Ultimatu. Za večino drugih ekip Free ni preizkus. Je vzdržen trajen odgovor.

Postavitev

Majhna namestitev

GitLab je težji, kot je videti. Dokumentirana osnova za eno vozlišče je 8 vCPU in 16 GB pomnilnika, in za razliko od večine proizvajalčevih minimumov je ta številka poštena in ne optimistična. Stlačiti ga je mogoče v 8 GB, a se to pozna, izmenjevalni prostor pa naj bo izklopljen, saj je izmenjevanje te aplikacije slabše, kot če pomnilnika ne bi bilo.

PostgreSQL je edina podprta baza. Katera različica, je odvisno od vaše različice GitLaba: 17.x hoče PostgreSQL od 14.14 do 16.x, 18.x hoče od 16.5 do 17.x, 19.x pa hoče 17.x. Priporočen je Redis 7.2, najmanj 7.0, Valkey 7.2 pa deluje kot nadomestek. Samo samostojne instance, saj gruče in brezstrežniške različice Redisa niso podprte.

Namestite s paketom za Linux. Obstajajo grafikoni Helm, operator, slike Docker in pot iz izvorne kode, a paket za Linux je najzrelejša možnost in prav na njem teče GitLab.com. Prinese PostgreSQL, Redis in Sidekiq, tako da en stroj in ena konfiguracijska datoteka dasta delujočo instanco.

# /etc/gitlab/gitlab.rb
external_url 'https://git.example.com'

# Let's Encrypt, on by default when external_url is https
letsencrypt['enable'] = true
letsencrypt['contact_emails'] = ['ops@example.com']

# Keep Puma and Sidekiq honest on a small box
puma['worker_processes'] = 2
sidekiq['max_concurrency'] = 9

# Move artefacts and uploads off local disk early
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
  'provider' => 'AWS',
  'region' => 'eu-central-1',
  'aws_access_key_id' => 'REPLACE_ME',
  'aws_secret_access_key' => 'REPLACE_ME'
}

En gitlab-ctl reconfigure pozneje imate instanco. external_url nastavite pravilno že prvič, saj ta vrednost konča vpečena v naslove za kloniranje, kljuke in naslove registra.

Produkcijska namestitev

GitLab objavlja referenčne arhitekture od 1.000 do 50.000 uporabnikov in vredno jih je prebrati, tudi če nobene ne boste izvedli, saj pokažejo, katera komponenta prva postane ozko grlo.

Nasvet, ki prihrani največ denarja, prihaja od GitLaba samega in govori proti zapletenosti: pod 3.000 uporabniki priporočajo trdno strategijo varnostnih kopij namesto visoke razpoložljivosti. Dokumentacija je pri tem nenavadno odkrita in pripomni, da ima pristop z varnostnimi kopijami sicer počasnejši čas obnove, a pomeni precej manjšo arhitekturo in nižje stroške vzdrževanja. Nad 3.000 uporabniki ali tam, kjer izpad res ustavi podjetje, postane priporočilo visoka razpoložljivost.

Vzemite to resno. Eno dobro varovano vozlišče s preizkušeno obnovitvijo je v praksi zanesljivejše od napol razumljene gruče visoke razpoložljivosti in precej cenejše.

Artefakte, naložene datoteke, predmete LFS in slike registra od začetka preselite v objektno hrambo. Isto razmišljanje kot povsod drugod: vozlišče ostane brez stanja, varnostne kopije obvladljive, selitev pa mogoča.

Tri stvari, ki gredo narobe

Vse zgoraj piše v dokumentaciji. Tole pa povzroča incidente.

Vaša varnostna kopija ne vsebuje tistega, kar jo odklene

To je najpomembnejši odstavek v tem članku.

gitlab-backup create zajame precej: bazo, repozitorije, predmete LFS, artefakte CI in dnevnike opravil, slike registra, wikije, naložene datoteke, vsebino Pages, stanje Terraform, izrezke. Česar ne zajame, je konfiguracijski imenik, in zlasti /etc/gitlab/gitlab-secrets.json.

Ta datoteka hrani šifrirni ključ baze. Dokumentacija je glede posledice neposredna: če jo izgubite, aplikacija GitLab ne bo mogla odšifrirati nobene šifrirane vrednosti v bazi. To pomeni spremenljivke CI/CD, žetone, skrivnosti za dvostopenjsko prijavo in poverilnice integracij. Imeli bi varnostno kopijo, ki se obnovi v instanco, ki ne zna prebrati lastnih skrivnosti.

Izpuščeni so tudi /etc/gitlab/gitlab.rb, ključi in potrdila TLS, gostiteljski ključi SSH ter vsebina objektne hrambe, ko je ta nastavljena. Zadnje ujame prav tiste, ki so arhitekturno naredili pravo stvar in nato predpostavili, da varnostna kopija to pokriva.

Zato /etc/gitlab varujte posebej, hranite ga drugje kot arhiv, saj je ključ do arhiva, potem pa celoto obnovite na stroj za enkratno uporabo in preverite, ali se lahko prijavite in preberete spremenljivko CI. Nepreizkušena kopija ni kopija, pri GitLabu pa je nepreizkušena obnova običajno pokvarjena.

Nadgraditi ni mogoče v enem skoku

GitLab ima obvezne vmesne postaje pri nadgradnji in to ni nasvet. Preskočiti jih ni mogoče. Od 17.5 so postaje predvidljive in padejo na x.2, x.5, x.8 in x.11, tako da prehod z 18.0 na 19.2 pomeni pot čez 18.2, 18.5, 18.8, 18.11 in 19.0.

Vsaka postaja prinese migracije v ozadju, ki se morajo v celoti dokončati, preden greste naprej. Zagnati naslednjo nadgradnjo, medtem ko migracije še tečejo, je način, kako instance končajo v stanjih, ki jih razpleta samo podpora. Na veliki instanci lahko te migracije trajajo ure.

Dve praktični posledici. Nadgrajujte redno, saj je leto odloženih nadgradenj en vikend zaporednih. In vedno vzemite zadnjo popravkovno izdajo ciljne manjše različice namesto prve, kar dokumentacija izrecno pove. GitLab vzdržuje orodje, ki vam izračuna pot nadgradnje, in bolje ga je uporabiti kot razmišljati sam.

Pravi strošek je pri izvajalcih

Strežnik GitLab ne izvaja vašega CI. GitLab Runner je ločena komponenta, ki jo namestite, nastavite in plačate, na infrastrukturi, ki jo priskrbite sami. Free v lastni režiji ne vključuje nobenih računskih minut, ker vključene računske moči preprosto ni: stroje prinesete sami.

Običajno je to dobra kupčija, saj namenski izvajalec stane manj na minuto od gostovanega CI, brž ko je obseg resen, vsakemu gradnji pa lahko date strojno opremo, ki jo potrebuje. A to je pravo infrastrukturno delo. Odločali se boste o izvajalnikih, ali lupina, Docker ali Kubernetes; o samodejnem skaliranju, da izvajalci ob treh zjutraj ne tečejo v prazno; in o predpomnjenju, ki je razlika med cevovodom štirih in cevovodom štirinajstih minut.

Floto izvajalcev vključite v proračun kot svojo postavko. Ekipe, ki strošek lastnega gostovanja modelirajo samo po vozlišču GitLab, ga močno podcenijo, primanjkljaj pa nato odkrijejo kot vrsto čakajočih opravil.

Odhod z GitHuba

Uvoznik GitHuba je dober, precej boljši od večine migracijskih orodij ponudnikov, in prinese podatke repozitorija, veje, predmete LFS, zahtevke in zahtevke za združitev s komentarji, pregledi in odgovori v razpravah, wiki strani, izdaje in priloge, oznake, mejnike, pravila zaščite vej ter sodelavce s preslikavo vlog.

Dokumentirane vrzeli velja načrtovati. Organizacije in skupine ne preidejo, zato strukturo skupin zasnujete sami, namesto da bi jo podedovali, kar je običajno izboljšava. Poteki GitHub Actions se ne pretvorijo v GitLab CI. Komentarji k zahtevkom za združitev izpred leta 2017 pridejo kot ločene niti zaradi omejitev API-ja GitHub, repozitoriji z več kot približno 30.000 komentarji pa zahtevajo vklop nadomestne metode uvoza komentarjev.

Ker GitHub uporablja # tako za zahtevke kot za zahtevke za združitev, GitLab pa ju ločuje, se nekatera navzkrižna sklicevanja ne bodo razrešila. Nič ni izgubljeno, a povezave v starih razpravah lahko kažejo na napačno stvar.

Prepis CI načrtujte kot pravi projekt, ker to tudi je. Vse ostalo je uvoz, ki ga zaženete in preverite.

Evropski zorni kot

Za podjetja, ki delujejo v Evropi, se stroškom pridruži razsežnost skladnosti. Izvorna koda, cevovodi za gradnjo in artefakti sodijo med najobčutljivejše, kar tehnološko podjetje ima, in kje živijo, je vse bolj vprašanje, ki vam ga zastavijo, ne pa tisto, na katerega se odločite odgovoriti.

Lastno gostovanje jih postavi znotraj meje, ki jo nadzorujete, kar v enem zamahu poenostavi analizo prenosov po GDPR in vprašanja dobavne verige iz NIS2, in to je isti argument suverenosti, okoli katerega je zgrajen Cloud and AI Development Act.

Ostrejša povezava je akt o kibernetski odpornosti. Kdor daje programsko opremo na trg EU, bo potreboval popise odvisnosti, obravnavo ranljivosti in usklajen postopek razkritja. Te obveznosti izpolnite v cevovodu za gradnjo in ne v dokumentu, imeti cevovod, register in pregledovanje v enem sistemu, ki ga vodite sami, pa naredi izdelavo dokazil precej manj mučno, kot je zbiranje od štirih ponudnikov.

Kdaj se ne splača

Če vas je manj kot dvajset inženirjev, ni regulatornega pritiska in nihče nima močnega mnenja o tem, kje živi koda, vzemite SaaS. GitLab.com in GitHub sta oba odlična, obratovalno delo pa bo stalo več kot naročnina.

Če je vaša organizacija globoko v ekosistemu GitHuba, pošteno preštejte, kaj bi izgubili. Actions, tržnica in preprosta domačnost platforme pri vsakem kandidatu, ki ga zaposlite, so resnične vrednote, in odgovor ni samodejno, da zmaga GitLab.

In če instance ne bo nihče prevzel, sploh ne začnite. GitLab nagradi tistega, ki ga krpa, spremlja floto izvajalcev in preizkuša obnovitev. Brez te osebe se sprevrže v nezakrpan zaboj, v katerem je vaše najdragocenejše premoženje, kar je slabše od SaaS-a, ki ste ga hoteli zapustiti.

Kako lahko pomagamo

Postavljamo in vodimo lastno gostovano razvojno infrastrukturo za podjetja, ki delujejo v Evropi, vključno z deli, ki jih nihče ne mara: zaporedji nadgradenj skozi obvezne postaje, flotami izvajalcev s pravilnim samodejnim skaliranjem, selitvami v objektno hrambo in shemami varnostnih kopij, ki so bile dejansko že obnovljene.

Če želite pošteno odmerjeno instanco GitLaba, selitev z GitHuba, ki jo načrtuje nekdo, ki je prepis CI že izpeljal, ali pregled, ali bi vaša trenutna kopija preživela stik z resnično okvaro, pišite na office@c9group.dev. Več o našem delu z infrastrukturo na strani o optimizaciji stroškov AWS.

Če sestavljate celoten sklad v lastni režiji, isto razmišljanje velja za analitiko, avtomatizacijo trženja in timsko sporočanje.

Objavljeno: 8. avgust 2026 Kategorije: DevOps, Odprta koda, Zasebnost