Avatud lähtekoodiga DevOps suures mahus: GitLab oma serveris

Lähtekood on see üks vara, mida peaaegu iga tehnoloogiaettevõte peab kriitiliseks, ja ühtlasi see, mida enamik neist hoiab taristul, mis ei kuulu neile, jurisdiktsioonis, mida nad ei valinud, lepingu alusel, mida nad hoolikalt ei lugenud. Tavaliselt on selline korraldus täiesti normaalne. Siiski tasub teada, mida alternatiiv maksab, sest GitLab on juba üle kümne aasta teinud kogu arenduse elutsükli isemajutamise tõeliselt praktiliseks.

See on ka toode, mille tasuta pakett on heldem ja mille käitamise koormus on raskem, kui enamik inimesi ootab. Mõlemat tasub mõista enne otsustamist, seega käsitleb see juhend, mis on GitLab self-managed tegelikult, mida tasuta pakett päriselt annab ja kolme käitamisprobleemi, mis põhjustavad suurema osa vaevast.

Mis on GitLab

Mitte Giti majutus, millele on lisad külge poltitud. Rails-rakendus, PostgreSQL, Redis, Gitaly repositooriumide salvestamiseks, Sidekiq taustatööde jaoks ja konteineriregister, pakendatuna üheks süsteemiks, mis katab versioonihalduse, koodiülevaatuse, ülesannete jälgimise, CI/CD, paketi- ja konteineriregistrid, turvaskaneerimise ja juurutamise.

Kogu argument seisnebki selles laiuses. GitHub koos Actionsi, Dependaboti, paketiregistri ja projektihaldusvahendiga on võrreldav funktsioonide komplekt, mis on kokku pandud osadest; GitLab on üks rakendus ühe õiguste mudeli ja ühe andmebaasiga. See on kas täpselt see, mida vajate, või rohkem, kui vajate, ja kumb neist, sõltub sellest, kui suure osa elutsüklist kavatsete tegelikult ühes kohas hoida.

Oluline arhitektuurne fakt on sama, mis kehtib analüütika isemajutamisel Matomoga, turundusautomaatika puhul Mauticuga või meeskonnavestluse puhul Mattermostiga: see töötab seal, kuhu selle panete. Teie repositooriumid, teie CI logid, teie artefaktid, teie andmebaas.

Litsentsid lihtsalt öelduna

See on tõesti segane ja siin tasub olla täpne, sest segadus on vastupidine sellele, mida inimesed ootavad.

Lähtekoodi distributsioone on kaks. Community Edition on MIT-litsentsiga. Enterprise Edition on oma piiravama litsentsiga, mis katab repositooriumi kataloogi ee/. Siiani kõlab see nagu tavaline open core mudel.

Osa, mis inimesi üllatab: Linuxi pakett, mille peaaegu kõik paigaldavad, on Enterprise Editioni build ja ilma litsentsivõtmeta töötab see Free paketina, käitudes nagu Community Edition. Te ei kasuta MIT-litsentsiga distributsiooni, kui te pole teadlikult CE paketti valinud. Praktikas on sellel harva tähtsust, kuid kui teie põhjus isemajutamiseks on range avatud lähtekoodi poliitika, mitte andmete üle kontrolli hoidmine, on sellel väga suur tähtsus ja peaaegu keegi seda ei kontrolli.

Kommertspaketid on Free, Premium hinnaga 29 dollarit kasutaja kohta kuus aastase arveldusega ning Ultimate individuaalse hinnaga. Premium lisab täiustatud CI/CD, parema projektihalduse ja prioriteetse toe. Ultimate lisab turvalisuse ja vastavuse komplekti: rakenduste turvatestimise, tarneahela turvalisuse, sõltuvuste skaneerimise. Mõlemad tasulised paketid sisaldavad praegu tehisintellekti funktsioonide jaoks GitLab Creditsi: Premiumis 12 dollarit kasutaja kohta kuus ja Ultimate'is 24. GitLabi hinnaleht nimetab neid kaasasolevaid krediite ajutiseks sooduspakkumiseks, mida GitLab võib oma äranägemisel muuta.

Siin on fakt, mis muudab enamiku meeskondade arvutuse, ja täpne vastand Mattermosti olukorrale: isehallatava Free paketi kasutajate arv ei ole piiratud. Viie kasutaja piir, millest inimesed on kuulnud, kehtib ainult GitLab.com-i privaatsetele gruppidele. Isemajutatud Free annab piiramatu arvu kasutajaid, versioonihalduse, CI/CD ja registrid ning salvestusruumi ja runnerid toote ise. Saja arendajaga organisatsioon võib töötada täielikult sellel.

Loobute turvaskaneerimisest, vastavusaruandlusest, täiustatud kinnitusreeglitest ja toest. Kui teile kehtib küberkerksuse määrus (Cyber Resilience Act) ja soovite, et sõltuvuste skaneerimine ja SBOM-i genereerimine oleksid teie pipeline'idesse sisse ehitatud, mitte eraldi tööriistadest kokku pandud, on see Ultimate'i teema. Enamiku teiste meeskondade jaoks ei ole Free prooviversioon. See on toimiv püsilahendus.

Paigaldamine

Väike paigaldus

GitLab on raskem, kui paistab. Dokumenteeritud baastase ühe sõlme jaoks on 8 vCPU-d ja 16 GB RAM-i ning erinevalt enamikust tarnijate miinimumnõuetest on see number aus, mitte optimistlik. Selle saab mahutada ka 8 GB sisse, kuid see on tunda ning swap peaks olema välja lülitatud, sest selle rakenduse swap'imine on hullem kui mälu puudumine.

PostgreSQL on ainus toetatud andmebaas. Versioon sõltub teie GitLabi versioonist: 17.x vajab PostgreSQL 14.14 kuni 16.x, 18.x vajab 16.5 kuni 17.x ja 19.x vajab 17.x kuni 18.x. Soovitatav on Redis 7.2, miinimum on 7.0, ning asendajana töötab Valkey 7.2. Ainult eraldiseisvad instantsid, sest klasterdatud ja serverita Redise variante ei toetata.

Paigaldage Linuxi paketiga. Olemas on Helmi chartid, Operator, Dockeri tõmmised ja lähtekoodist paigaldamine, kuid Linuxi pakett on kõige küpsem valik ja just sellel töötab ka GitLab.com ise. See sisaldab PostgreSQL-i, Redist ja Sidekiqi, mis tähendab, et üks masin ja üks konfiguratsioonifail annavad töötava instantsi.

# /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'
}

Käivitage gitlab-ctl reconfigure ja instants ongi olemas. Seadistage external_url kohe esimesel korral õigesti, sest see jääb sisse kirjutatuks kloonimise URL-idesse, veebihaakidesse ja registri aadressidesse.

Tootmispaigaldus

GitLab avaldab viitearhitektuure 1000 kuni 50 000 kasutajale ning neid tasub lugeda ka siis, kui te ühtegi neist kunagi ellu ei vii, sest need näitavad, milline komponent muutub esimesena kitsaskohaks.

Nõuanne, mis säästab kõige rohkem raha, on GitLabi enda oma ja see räägib keerukuse vastu: alla 3000 kasutaja puhul soovitavad nad kõrgkäideldavuse asemel korralikku varundusstrateegiat. Dokumentatsioon on selles osas ebatavaliselt avameelne, märkides, et varunduspõhisel lähenemisel „on küll aeglasem taastumisaeg“, kuid see „tähendab palju väiksemat arhitektuuri ja väiksemaid hoolduskulusid“. Üle 3000 kasutaja puhul või siis, kui katkestus tõesti peatab ettevõtte töö, muutub soovituseks kõrgkäideldavus.

Võtke seda tõsiselt. Üks hästi varundatud sõlm testitud taastamisega on praktikas töökindlam kui pooleldi mõistetud kõrgkäideldav klaster ja palju odavam.

Viige artefaktid, üleslaadimised, LFS-objektid ja registri tõmmised algusest peale objektisalvestusse. Põhjendus on sama mis mujal: sõlm jääb olekuta, varukoopiad hallatavaks ja migratsioon võimalikuks.

Kolm asja, mis lähevad valesti

Kõik ülaltoodu on dokumentatsioonis kirjas. Need kolm on aga need, mis tekitavad intsidente.

Teie varukoopia ei sisalda seda, mis selle dekrüpteerib

See on selle artikli kõige olulisem lõik.

gitlab-backup create salvestab palju: andmebaasi, repositooriumid, LFS-objektid, CI artefaktid ja tööde logid, registri tõmmised, vikid, üleslaadimised, Pagesi sisu, Terraformi oleku, koodijupid. Mida see ei salvesta, on konfiguratsioonikataloog, täpsemalt /etc/gitlab/gitlab-secrets.json.

Selles failis on andmebaasi krüpteerimisvõti. Dokumentatsioon ütleb tagajärje kohta otse: „Kui kaotate selle, ei suuda GitLabi rakendus andmebaasis ühtegi krüpteeritud väärtust dekrüpteerida.“ See tähendab CI/CD muutujaid, tokeneid, kaheastmelise autentimise saladusi ja integratsioonide mandaate. Teil on varukoopia, mis taastub instantsiks, mis ei suuda oma saladusi lugeda.

Samuti jäävad välja: /etc/gitlab/gitlab.rb, TLS-võtmed ja sertifikaadid, SSH hostivõtmed ning objektisalvestuse sisu, kui objektisalvestus on seadistatud. Viimane püüab kinni need, kes tegid arhitektuuriliselt õigesti ja eeldasid seejärel, et varukoopia katab selle.

Seega varundage /etc/gitlab eraldi, hoidke seda mujal kui arhiivi kõrval, sest see on arhiivi võti, ning taastage siis kõik tühjale testmasinale ja kontrollige, et saate sisse logida ja CI muutujat lugeda. Testimata taastamine ei ole varukoopia ja GitLabi puhul on testimata taastamine tavaliselt katkine.

Uuendada ei saa ühe hüppega

GitLabil on kohustuslikud uuendamispeatused ja see ei ole soovitus. Neid vahele jätta ei saa. Alates versioonist 17.5 on peatused ennustatavad, versioonidel x.2, x.5, x.8 ja x.11, seega tähendab uuendamine 18.0-lt 19.2-le, et kõigepealt tuleb peatuda versioonidel 18.2, 18.5, 18.8 ja 18.11. Versioon 19.0 ei ole peatus, nii et 18.11-lt lähete otse 19.2-le.

Iga peatusega kaasnevad taustamigratsioonid, mis peavad täielikult lõpule jõudma, enne kui järgmise juurde liigute. Järgmise uuenduse alustamine ajal, mil migratsioonid veel käivad, on see, kuidas instantsid jõuavad olekusse, mille lahtiharutamiseks on vaja tuge. Suurel instantsil võivad need migratsioonid kesta tunde.

Kaks praktilist järeldust. Uuendage regulaarselt, sest aasta jagu edasilükatud uuendusi tähendab nädalavahetust järjestikuste uuendustega. Ja võtke alati sihtversiooni viimane paranduskomplekt, mitte esimene, nagu dokumentatsioon selgesõnaliselt ütleb. GitLab haldab uuendamistee tööriista, mis arvutab järjestuse teie eest, ja seda tasub kasutada, mitte ise järeldada.

Tegelik kulu on runnerites

GitLabi server ei käita teie CI-d. GitLab Runner on eraldi komponent, mille paigaldate, seadistate ja eest maksate teie, enda pakutud taristul. Isehallatav Free ei sisalda üldse arvutusminuteid, sest anda ei ole midagi: masinad toote ise.

Tavaliselt on see hea tehing, sest oma runner on igasuguse tõsisema mahu juures minuti kohta odavam kui hallatud CI ja sinna saab ühendada mis tahes riistvara, mida build vajab. Kuid see on päris taristutöö. Peate otsustama executorite üle (shell, Docker või Kubernetes), automaatse skaleerimise üle, et runnerid ei seisaks kell kolm öösel jõude, ning vahemälu üle, mis teeb vahe neljaminutilise ja neljateistminutilise pipeline'i vahel.

Planeerige runnerite park eelarves eraldi reana. Meeskonnad, kes hindavad isemajutamise kulu ainult GitLabi sõlme järgi, alahindavad seda tublisti ja avastavad puudujäägi hiljem ootel tööde järjekorrana.

Üleminek GitHubist

GitHubi importija on hea, tunduvalt parem kui enamik tarnijate migratsioonitööriistu, ning toob üle repositooriumi andmed, harud, LFS-objektid, ülesanded ja pull requestid koos kommentaaride, ülevaatuste ja aruteluvastustega, vikilehed, väljalasked ja manused, sildid, verstapostid, harude kaitsereeglid ning kaastöötajad koos rollide vastendamisega.

Dokumenteeritud lünkadega tasub plaanis arvestada. Organisatsioonid ja grupid üle ei tule, seega on grupistruktuur teie kujundada, mitte pärida, mis on tavaliselt paranemine. GitHub Actionsi töövood GitLab CI-ks ei teisendu. Enne 2017. aastat tehtud pull requestide kommentaarid imporditakse GitHubi API piirangute tõttu eraldi lõimedena ning repositooriumid, kus on üle umbes 30 000 kommentaari, vajavad alternatiivse kommentaaride impordi meetodi sisselülitamist.

Kuna GitHub kasutab # nii ülesannete kui ka pull requestide jaoks, GitLab aga eristab neid, ei lahendu osa ristviiteid. Midagi ei lähe kaduma, kuid vanade arutelude lingid võivad osutada valele asjale.

Planeerige CI ümberkirjutamine tegeliku projektina, sest see ongi seda. Kõik muu on impordi töö, mida saab käivitada ja kontrollida.

Euroopa vaatenurk

Euroopas tegutsevate ettevõtete jaoks on lisaks kulule ka vastavuse mõõde. Lähtekood, build-pipeline'id ja artefaktid on tehnoloogiaettevõtte kõige tundlikumate varade hulgas ning see, kus need asuvad, on üha sagedamini küsimus, mida teilt küsitakse, mitte küsimus, millele otsustate ise vastata.

Isemajutamine paneb need teie kontrollitava piiri sisse, mis lihtsustab ühe sammuga nii isikuandmete kaitse üldmääruse (GDPR) edastamisanalüüsi kui ka NIS2 tarneahela küsimusi, ning see on sama suveräänsuse argument, millele on üles ehitatud Cloud and AI Development Act.

Teravam seos on küberkerksuse määrusega. Kui tarnite tarkvara ELi turule, vajate sõltuvuste inventuuri, haavatavuste käsitlemist ja koordineeritud avalikustamise protsessi. Need kohustused täidetakse teie build-pipeline'is, mitte dokumendis, ning kui pipeline, register ja skaneerimine on ühes süsteemis, mida ise käitate, on tõendite esitamine tunduvalt lihtsam kui nende kokkupanek nelja tarnija juurest.

Millal mitte vaeva näha

Kui teil on alla kahekümne arendaja, regulatiivset survet ei ole ja teil ei ole kindlat seisukohta selle kohta, kus kood asub, kasutage SaaS-i. GitLab.com ja GitHub on mõlemad suurepärased ning käitamistöö läheb maksma rohkem kui tellimus.

Kui teie organisatsioon on sügavalt GitHubi ökosüsteemis, arvestage ausalt kokku, mida kaotaksite. Actions, marketplace ja platvormi tuttavlikkus igale kandidaadile, kelle tööle võtate, on päris väärtused ning vastus ei ole automaatselt see, et GitLab võidab.

Ja kui keegi instantsi eest ei vastuta, ärge alustage. GitLab tasub ära omanikule, kes paigab seda, jälgib runnerite parki ja testib taastamist. Ilma selle inimeseta muutub see paikamata masinaks, kus on teie kõige väärtuslikum vara, ja see on halvem kui SaaS, millest püüdsite lahkuda.

Abi saamine

Paigaldame ja käitame isemajutatud arendustaristut Euroopas tegutsevatele ettevõtetele, sealhulgas neid osi, mis kellelegi ei meeldi: uuendusjärjestused läbi kohustuslike peatuste, korralikult skaleeruvad runnerite pargid, objektisalvestuse migratsioonid ja varundusskeemid, mida on päriselt taastatud.

Kui soovite ausalt dimensioneeritud GitLabi instantsi, GitHubist üleminekut, mille planeerib keegi, kes on CI ümberkirjutamise varem läbi teinud, või ülevaatust selle kohta, kas teie praegune varukoopia peaks päris rikkele vastu, kirjutage aadressil office@c9group.dev. Rohkem meie taristutööst leiate AWS-i kulude optimeerimise lehelt.

Kui panete kokku täielikku isemajutatud tehnoloogiakomplekti, kehtib sama loogika ka analüütika, turundusautomaatika ja meeskonnasuhtluse kohta.

---

Avaldatud: 8. august 2026 · Uuendatud: 10. oktoober 2026 Kategooriad: DevOps, avatud lähtekood, privaatsus