Atvirojo kodo DevOps dideliu mastu: GitLab savo infrastruktūroje

nešiojamojo kompiuterio ekranas su kodu pilnoje patalpoje

Išeitinis kodas yra tas turtas, kurį beveik kiekviena technologijų įmonė sutinka laikyti kritiniu, ir tas, kurį dauguma jų laiko ne savo infrastruktūroje, ne savo pasirinktoje jurisdikcijoje ir pagal sutartį, kurios atidžiai neperskaitė. Paprastai tokia tvarka tinka. Vis dėlto verta žinoti, kiek kainuoja alternatyva, nes GitLab jau daugiau nei dešimtmetį leidžia realiai talpinti visą kūrimo ciklą savo infrastruktūroje.

Be to, tai produktas, kurio nemokama versija dosnesnė, o eksploatavimo našta sunkesnė, nei dauguma tikisi. Abu dalykus verta suprasti prieš įsipareigojant, todėl šiame vadove aptariame, kas iš tikrųjų yra savarankiškai valdomas GitLab, ką iš tikrųjų duoda nemokama versija ir tris eksploatavimo problemas, kurios sukelia daugiausia rūpesčių.

Kas yra GitLab

Ne Git talpykla su priklijuotais priedais. Tai Rails programa, PostgreSQL, Redis, Gitaly repozitorijoms saugoti, Sidekiq foniniams darbams ir konteinerių registras, supakuoti į vieną sistemą, apimančią versijų valdymą, kodo peržiūrą, užduočių sekimą, CI/CD, paketų ir konteinerių registrus, saugumo skenavimą ir diegimą.

Būtent šis platumas ir yra visas argumentas. GitHub kartu su Actions, Dependabot, paketų registru ir projektų sekimo įrankiu yra panašus funkcijų rinkinys, sudėtas iš dalių; GitLab yra viena programa su vienu teisių modeliu ir viena duomenų baze. Tai arba būtent tai, ko jums reikia, arba daugiau, nei reikia, o kuris variantas tinka, priklauso nuo to, kokią ciklo dalį iš tikrųjų ketinate vykdyti vienoje vietoje.

Svarbus architektūrinis faktas tas pats, kaip savarankiškai talpinant analitiką su Matomo, rinkodaros automatizavimą su Mautic ar komandos pokalbius su Mattermost: sistema veikia ten, kur ją pastatote. Jūsų repozitorijos, jūsų CI žurnalai, jūsų artefaktai, jūsų duomenų bazė.

Licencijos, paaiškintos paprastai

Tai iš tiesų painu, ir verta kalbėti tiksliai, nes painiava veikia priešinga kryptimi, nei žmonės tikisi.

Yra du išeitinio kodo paskirstymai. Community Edition licencijuojamas pagal MIT. Enterprise Edition turi savą, griežtesnę licenciją, taikomą repozitorijos katalogui ee/. Kol kas tai skamba kaip įprastas atvirojo branduolio (open core) modelis.

Kas žmones nustebina: Linux paketas, kurį diegia beveik visi, yra Enterprise Edition versija, ir be licencijos rakto ji veikia kaip Free planas, elgdamasi kaip Community Edition. MIT licencijuoto paskirstymo nenaudojate, nebent sąmoningai pasirinkote CE paketą. Praktiškai tai retai svarbu, tačiau jei savarankiško talpinimo priežastis yra griežta atvirojo kodo politika, o ne duomenų kontrolė, tai labai svarbu, ir beveik niekas to netikrina.

Komerciniai planai yra Free, Premium už 29 dolerius vienam naudotojui per mėnesį, mokant už metus, ir Ultimate su individualia kaina. Premium prideda pažangų CI/CD, geresnį projektų valdymą ir prioritetinę pagalbą. Ultimate prideda saugumo ir atitikties rinkinį: programų saugumo testavimą, tiekimo grandinės saugumą, priklausomybių skenavimą. Abu mokami planai šiuo metu apima GitLab Credits DI funkcijoms: 12 dolerių vienam naudotojui per mėnesį Premium ir 24 Ultimate plane. GitLab kainų puslapyje šie įtraukti kreditai vadinami ribotos trukmės reklaminiu pasiūlymu, kurį GitLab savo nuožiūra gali keisti.

Štai faktas, kuris daugumai komandų keičia skaičiavimą, ir tiksliai priešingas Mattermost situacijai: savarankiškai valdomo Free plano naudotojų skaičius neribojamas. Penkių naudotojų riba, apie kurią žmonės girdėjo, taikoma tik privačioms grupėms GitLab.com. Savo infrastruktūroje Free duoda neribotą naudotojų skaičių, versijų valdymą, CI/CD ir registrus, o saugyklą ir vykdykles (runners) pasirūpinate patys. Šimto inžinierių organizacija gali dirbti vien su juo.

Ko netenkate: saugumo skenavimo, atitikties ataskaitų, pažangių patvirtinimo taisyklių ir pagalbos. Jei jums taikomas Kibernetinio atsparumo aktas ir norite, kad priklausomybių skenavimas ir SBOM generavimas būtų integruoti į jūsų procesus, o ne surinkti iš atskirų įrankių, tai pokalbis apie Ultimate. Daugumai kitų komandų Free nėra bandomoji versija. Tai tinkamas nuolatinis sprendimas.

Diegimas

Nedidelis diegimas

GitLab sunkesnis, nei atrodo. Dokumentuotas bazinis lygis vienam mazgui yra 8 vCPU ir 16 GB RAM, ir, kitaip nei dauguma tiekėjų minimumų, šis skaičius sąžiningas, o ne optimistinis. Galima sutilpti ir į 8 GB, bet tai pajusite, o apkeitimą (swap) reikėtų išjungti, nes šios programos apkeitimas blogiau nei atminties trūkumas.

PostgreSQL yra vienintelė palaikoma duomenų bazė. Versija priklauso nuo GitLab versijos: 17.x reikia PostgreSQL nuo 14.14 iki 16.x, 18.x reikia nuo 16.5 iki 17.x, o 19.x reikia nuo 17.x iki 18.x. Rekomenduojama Redis 7.2, minimali versija 7.0, o Valkey 7.2 tinka kaip pakaitalas. Tik atskiri egzemplioriai, nes klasterinės ir serverless Redis versijos nepalaikomos.

Diekite Linux paketu. Yra Helm diagramos, Operator, Docker atvaizdai ir diegimas iš išeitinio kodo, tačiau Linux paketas yra brandžiausias variantas, ir būtent juo veikia pats GitLab.com. Jame yra PostgreSQL, Redis ir Sidekiq, todėl viena mašina ir vienas konfigūracijos failas duoda veikiantį egzempliorių.

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

Paleiskite gitlab-ctl reconfigure, ir egzempliorius veikia. external_url nustatykite teisingai iš pirmo karto, nes jis įsirašo į klonavimo URL, žiniatinklio kabliukus (webhooks) ir registro adresus.

Gamybinis diegimas

GitLab skelbia etalonines architektūras nuo 1 000 iki 50 000 naudotojų, ir jas verta perskaityti, net jei nė vienos neįgyvendinsite, nes jos parodo, kuris komponentas pirmasis tampa kliūtimi.

Daugiausia pinigų sutaupantis patarimas yra paties GitLab, ir jis nukreiptas prieš sudėtingumą: iki 3 000 naudotojų rekomenduojama patikima atsarginių kopijų strategija, o ne didelis prieinamumas (HA). Dokumentacija neįprastai atvira: pažymima, kad atsarginėmis kopijomis grindžiamas būdas „atkuria lėčiau“, tačiau „reiškia, kad architektūra daug mažesnė, o priežiūros išlaidos mažesnės“. Viršijus 3 000 naudotojų arba ten, kur sutrikimas iš tikrųjų sustabdo įmonę, rekomenduojamas HA.

Vertinkite tai rimtai. Vienas mazgas su gerai padarytomis atsarginėmis kopijomis ir išbandytu atkūrimu praktiškai patikimesnis nei iki galo nesuprastas HA klasteris, ir gerokai pigesnis.

Artefaktus, įkeltus failus, LFS objektus ir registro atvaizdus nuo pat pradžių perkelkite į objektų saugyklą. Priežastis ta pati kaip visur: mazgas lieka be būsenos, atsarginės kopijos valdomos, o migracija įmanoma.

Trys dalykai, kurie sugenda

Viskas, kas aprašyta aukščiau, yra dokumentacijoje. Toliau aptariami dalykai, kurie sukelia incidentus.

Jūsų atsarginėje kopijoje nėra to, kas ją iššifruoja

Tai pati svarbiausia šio straipsnio pastraipa.

gitlab-backup create užfiksuoja daug ką: duomenų bazę, repozitorijas, LFS objektus, CI artefaktus ir užduočių žurnalus, registro atvaizdus, vikius, įkeltus failus, Pages turinį, Terraform būseną, fragmentus (snippets). Ko ji neužfiksuoja, tai konfigūracijos katalogo, o konkrečiai /etc/gitlab/gitlab-secrets.json.

Šiame faile laikomas duomenų bazės šifravimo raktas. Dokumentacija pasekmes nurodo tiesiai: „Jei jį prarasite, GitLab programa negalės iššifruoti jokių užšifruotų duomenų bazės reikšmių.“ Tai reiškia CI/CD kintamuosius, prieigos raktus, dviejų veiksnių autentifikavimo paslaptis ir integracijų prisijungimo duomenis. Turėsite atsarginę kopiją, kuri atkuriama į egzempliorių, negalintį perskaityti savo paties paslapčių.

Taip pat neįtraukiami: /etc/gitlab/gitlab.rb, TLS raktai ir sertifikatai, SSH mazgo raktai ir objektų saugyklos turinys, kai objektų saugykla sukonfigūruota. Pastarasis užklumpa tuos, kurie architektūriškai pasielgė teisingai, o paskui manė, kad atsarginė kopija tai apima.

Todėl /etc/gitlab kopijuokite atskirai, laikykite kitur nei archyvą (juk tai archyvo raktas), tada visa tai atkurkite bandomojoje mašinoje ir patikrinkite, ar galite prisijungti ir perskaityti CI kintamąjį. Neišbandytas atkūrimas nėra atsarginė kopija, o GitLab atveju neišbandytas atkūrimas paprastai yra sugedęs.

Atnaujinti vienu šuoliu negalima

GitLab turi privalomus atnaujinimo sustojimus, ir tai ne rekomendacija. Jų praleisti negalima. Nuo 17.5 versijos sustojimai nuspėjami ir būna ties x.2, x.5, x.8 ir x.11, todėl atnaujinant nuo 18.0 iki 19.2 pirmiausia reikia sustoti ties 18.2, 18.5, 18.8 ir 18.11. 19.0 nėra sustojimas, todėl nuo 18.11 einate tiesiai į 19.2.

Kiekviename sustojime vykdomos foninės migracijos, kurios turi visiškai baigtis prieš pereinant prie kito. Pradėję kitą atnaujinimą, kol migracijos dar vyksta, egzempliorių galite įvaryti į būseną, kurią išpainioti prireiks pagalbos tarnybos. Dideliame egzemplioriuje šios migracijos gali trukti valandas.

Dvi praktinės pasekmės. Atnaujinkite reguliariai, nes metus atidėti atnaujinimai virsta savaitgaliu, praleistu juos diegiant vieną po kito. Ir visada imkite naujausią tikslinės mažosios versijos pataisų leidimą, o ne pirmąjį, kaip aiškiai nurodo dokumentacija. GitLab palaiko atnaujinimo kelio įrankį, kuris apskaičiuoja seką už jus, ir verta juo naudotis, užuot svarsčius patiems.

Tikrosios išlaidos slypi vykdyklėse

GitLab serveris jūsų CI nevykdo. GitLab Runner yra atskiras komponentas, kurį įdiegiate, sukonfigūruojate ir už kurį mokate patys, jūsų pačių infrastruktūroje. Savarankiškai valdomas Free neapima jokių skaičiavimo minučių, nes nėra įtrauktų skaičiavimo išteklių, kuriuos būtų galima duoti: mašinas atsinešate patys.

Paprastai tai geras sandoris, nes dedikuota vykdyklė esant bet kokiai rimtesnei apimčiai kainuoja mažiau už minutę nei talpinamas CI, ir galite prijungti bet kokią aparatinę įrangą, kurios reikia kompiliavimui. Tačiau tai tikras infrastruktūros darbas. Teks spręsti dėl vykdymo aplinkų (executors), ar tai bus shell, Docker, ar Kubernetes; dėl automatinio mastelio keitimo, kad vykdyklės nestovėtų be darbo trečią valandą nakties; ir dėl podėlio, nuo kurio priklauso, ar procesas truks keturias minutes, ar keturiolika.

Vykdyklių parkui numatykite atskirą biudžeto eilutę. Komandos, kurios savarankiško talpinimo kainą vertina žiūrėdamos tik į GitLab mazgą, ją gerokai nuvertina, o trūkumą atranda kaip laukiančių užduočių eilę.

Perėjimas iš GitHub

GitHub importavimo įrankis geras, gerokai geresnis už daugumą tiekėjų migracijos įrankių, ir perkelia repozitorijų duomenis, šakas, LFS objektus, užduotis ir pull request su jų komentarais, peržiūromis ir atsakymais į diskusijas, vikio puslapius, leidimus ir priedus, žymas, etapus, šakų apsaugos taisykles ir bendradarbius su vaidmenų susiejimu.

Dokumentuotas spragas verta įtraukti į planą. Organizacijos ir grupės neperkeliamos, todėl grupių struktūrą kuriate patys, o ne paveldite, ir paprastai tai pagerinimas. GitHub Actions darbo eigos nekonvertuojamos į GitLab CI. Pull request komentarai, senesni nei 2017 m., dėl GitHub API apribojimų importuojami kaip atskiros gijos, o repozitorijoms, turinčioms daugiau nei maždaug 30 000 komentarų, reikia įjungti alternatyvų komentarų importavimo būdą.

Kadangi GitHub ženklą # naudoja ir užduotims, ir pull request, o GitLab juos skiria, dalis kryžminių nuorodų neveiks. Niekas neprarandama, tačiau nuorodos senose diskusijose gali rodyti ne į tą objektą.

CI perrašymą planuokite kaip tikrąjį projektą, nes jis toks ir yra. Visa kita yra importavimo užduotis, kurią galite paleisti ir patikrinti.

Europos aspektas

Europoje veikiančioms įmonėms be išlaidų yra ir atitikties aspektas. Išeitinis kodas, kompiliavimo procesai ir artefaktai yra vieni jautriausių technologijų įmonės turimų dalykų, o tai, kur jie laikomi, vis dažniau yra klausimas, kurį jums užduoda, o ne tas, į kurį nusprendžiate atsakyti patys.

Savarankiškas talpinimas juos laiko jūsų kontroliuojamose ribose, todėl vienu žingsniu supaprastėja BDAR duomenų perdavimo analizė ir NIS2 tiekimo grandinės klausimai, o tai tas pats suvereniteto argumentas, kuriuo grindžiamas Debesijos ir DI plėtros aktas.

Dar tiesesnis ryšys yra su Kibernetinio atsparumo aktu. Jei tiekiate programinę įrangą ES rinkai, jums reikės priklausomybių sąrašų, pažeidžiamumų tvarkymo ir koordinuoto atskleidimo proceso. Šios pareigos vykdomos jūsų kompiliavimo procese, o ne dokumente, o kai procesai, registras ir skenavimas yra vienoje jūsų valdomoje sistemoje, įrodymus parengti gerokai lengviau nei renkant juos iš keturių tiekėjų.

Kada neverta vargti

Jei turite mažiau nei dvidešimt inžinierių, jums nėra reguliavimo spaudimo ir jums nelabai rūpi, kur laikomas kodas, naudokite SaaS. GitLab.com ir GitHub abu puikūs, o eksploatavimo darbas kainuos daugiau nei prenumerata.

Jei jūsų organizacija giliai įsitvirtinusi GitHub ekosistemoje, sąžiningai suskaičiuokite, ko netektumėte. Actions, prekyvietė ir tai, kad platforma pažįstama kiekvienam samdomam kandidatui, yra tikras turtas, ir GitLab automatiškai nelaimi.

O jei egzemplioriaus niekas neprižiūrės, nepradėkite. GitLab atsilygina savininkui, kuris jį atnaujina, stebi vykdyklių parką ir tikrina atkūrimą. Be tokio žmogaus jis virsta neatnaujinamu serveriu, kuriame laikomas vertingiausias jūsų turtas, o tai blogiau nei SaaS, iš kurio bandėte išeiti.

Pagalba

Diegiame ir eksploatuojame savarankiškai talpinamą kūrimo infrastruktūrą Europoje dirbančioms įmonėms, įskaitant dalis, kurių niekas nemėgsta: atnaujinimų sekas per privalomus sustojimus, tinkamai automatiškai besiplečiančius vykdyklių parkus, objektų saugyklos migracijas ir atsarginių kopijų schemas, kurios iš tikrųjų buvo atkurtos.

Jei norite sąžiningai įvertintų dydžių GitLab egzemplioriaus, GitHub migracijos, kurią suplanuotų žmogus, jau perrašęs CI, arba patikros, ar jūsų dabartinė atsarginė kopija atlaikytų tikrą gedimą, rašykite adresu office@c9group.dev. Daugiau apie mūsų infrastruktūros darbus rasite AWS išlaidų optimizavimo puslapyje.

Jei kuriate visą savarankiškai talpinamą rinkinį, tas pats principas taikomas analitikai, rinkodaros automatizavimui ir komandos pokalbiams.

Paskelbta: 2026 m. rugpjūčio 8 d. (atnaujinta 2026 m. spalio 10 d.) Kategorijos: DevOps, atvirasis kodas, privatumas