Atvērtā koda DevOps lielā mērogā: GitLab savā infrastruktūrā

Pirmkods ir tas aktīvs, kuru gandrīz katrs tehnoloģiju uzņēmums atzīst par kritisku, un tieši to vairums glabā infrastruktūrā, kas tiem nepieder, jurisdikcijā, ko tie nav izvēlējušies, saskaņā ar līgumu, ko tie nav rūpīgi izlasījuši. Parasti šāda kārtība ir pieņemama. Tomēr ir vērts zināt, cik maksā alternatīva, jo GitLab jau vairāk nekā desmit gadus ir padarījis visa izstrādes cikla uzturēšanu savā infrastruktūrā patiešām praktisku.

Tas ir arī produkts, kura bezmaksas līmenis ir dāsnāks un ekspluatācijas slogs smagāks, nekā vairums cilvēku sagaida. Abas šīs lietas ir vērts saprast pirms lēmuma, tāpēc šajā ceļvedī aplūkojam, kas īsti ir pašu pārvaldīts GitLab, ko patiesībā dod bezmaksas līmenis, un trīs ekspluatācijas problēmas, kas rada lielāko daļu sāpju.

Kas ir GitLab

Tas nav Git mitinātājs ar piestiprinātiem papildinājumiem. Tā ir Rails lietotne, PostgreSQL, Redis, Gitaly repozitoriju glabāšanai, Sidekiq fona uzdevumiem un konteineru reģistrs, kas apvienoti vienā sistēmā, kura aptver versiju kontroli, koda pārskatīšanu, problēmu uzskaiti, CI/CD, pakotņu un konteineru reģistrus, drošības skenēšanu un izvietošanu.

Šis plašums arī ir viss arguments. GitHub kopā ar Actions, Dependabot, pakotņu reģistru un projektu uzskaites rīku ir salīdzināms funkciju kopums, salikts no daļām; GitLab ir viena lietotne ar vienu atļauju modeli un vienu datubāzi. Tas ir vai nu tieši tas, kas jums vajadzīgs, vai vairāk nekā vajag, un tas, kurš no abiem, atkarīgs no tā, cik lielu dzīves cikla daļu jūs patiešām plānojat darbināt vienuviet.

Svarīgākais arhitektūras fakts ir tas pats, kas attiecas uz analītikas uzturēšanu pašiem ar Matomo, mārketinga automatizāciju ar Mautic vai komandas tērzēšanu ar Mattermost: tas darbojas tur, kur jūs to novietojat. Jūsu repozitoriji, jūsu CI žurnāli, jūsu artefakti, jūsu datubāze.

Licencēšana, izskaidrota vienkārši

Tas patiešām ir mulsinoši, un ir vērts būt precīziem, jo neskaidrība ir pretēja tam, ko cilvēki sagaida.

Ir divi pirmkoda izplatījumi. Community Edition ir licencēts ar MIT licenci. Enterprise Edition ir sava, stingrāka licence, kas attiecas uz repozitorija ee/ direktoriju. Līdz šim tas izklausās pēc parastā „atvērtā kodola“ modeļa.

Daļa, kas cilvēkus pārsteidz: Linux pakotne, ko instalē gandrīz visi, ir Enterprise Edition būvējums, un bez licences atslēgas tas darbojas kā bezmaksas līmenis (Free), uzvedoties tāpat kā Community Edition. Jūs nedarbināt ar MIT licencēto izplatījumu, ja vien neesat apzināti izvēlējušies CE pakotni. Praksē tam reti ir nozīme, taču, ja jūsu iemesls uzturēt GitLab pašiem ir stingra atvērtā koda politika, nevis datu kontrole, tam ir liela nozīme, un gandrīz neviens to nepārbauda.

Komerciālie līmeņi ir Free, Premium par 29 dolāriem par lietotāju mēnesī ar ikgadēju norēķinu un Ultimate ar individuālu cenu. Premium pievieno paplašinātu CI/CD, labāku projektu pārvaldību un prioritāru atbalstu. Ultimate pievieno drošības un atbilstības komplektu: lietotņu drošības testēšanu, piegādes ķēdes drošību, atkarību skenēšanu. Abos maksas līmeņos pašlaik ir iekļauti GitLab Credits MI funkcijām: 12 dolāri par lietotāju mēnesī Premium un 24 Ultimate līmenī. GitLab cenu lapā šie iekļautie kredīti saukti par ierobežota laika akcijas piedāvājumu, ko GitLab pēc saviem ieskatiem var mainīt.

Lūk, fakts, kas vairumam komandu maina aprēķinu un ir tieši pretējs Mattermost situācijai: pašu pārvaldītā GitLab bezmaksas līmenim nav lietotāju ierobežojuma. Piecu lietotāju ierobežojums, par kuru cilvēki ir dzirdējuši, attiecas tikai uz privātām grupām GitLab.com. Pašu mitināts Free dod neierobežotu lietotāju skaitu, versiju kontroli, CI/CD un reģistrus, bet krātuvi un izpildītājus (runners) jūs nodrošināt paši. Organizācija ar simts inženieriem var pilnībā strādāt uz tā.

Jūs zaudējat drošības skenēšanu, atbilstības pārskatus, paplašinātus apstiprināšanas noteikumus un atbalstu. Ja uz jums attiecas Kibernoturības akts un vēlaties, lai atkarību skenēšana un SBOM ģenerēšana būtu iebūvēta jūsu konveijeros, nevis salikta no atsevišķiem rīkiem, tā ir saruna par Ultimate. Vairumam citu komandu Free nav izmēģinājuma versija. Tas ir dzīvotspējīgs pastāvīgs risinājums.

Ieviešana

Neliels izvietojums

GitLab ir smagāks, nekā izskatās. Dokumentētā bāzes konfigurācija vienam mezglam ir 8 vCPU un 16 GB RAM, un atšķirībā no vairuma piegādātāju minimālajām prasībām šis skaitlis ir godīgs, nevis optimistisks. To var saspiest 8 GB, bet jūs to jutīsiet, un swap jāatslēdz, jo šīs lietotnes pārvietošana uz swap ir sliktāka nekā atmiņas trūkums.

PostgreSQL ir vienīgā atbalstītā datubāze. Versija ir atkarīga no jūsu GitLab versijas: 17.x prasa PostgreSQL no 14.14 līdz 16.x, 18.x prasa no 16.5 līdz 17.x, un 19.x prasa no 17.x līdz 18.x. Ieteicams Redis 7.2, minimālā versija ir 7.0, un kā aizstājējs darbojas Valkey 7.2. Tikai atsevišķas instances, jo klasterizēti un bezservera Redis varianti netiek atbalstīti.

Instalējiet ar Linux pakotni. Ir Helm diagrammas, Operator, Docker attēli un instalēšana no pirmkoda, taču Linux pakotne ir visnobriedušākais variants, un uz tās darbojas pats GitLab.com. Tajā iekļauti PostgreSQL, Redis un Sidekiq, tātad ar vienu mašīnu un vienu konfigurācijas failu jūs iegūstat strādājošu instanci.

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

Palaidiet gitlab-ctl reconfigure, un jums ir instance. Iestatiet external_url pareizi jau pirmajā reizē, jo tas tiek iestrādāts klonēšanas URL, tīmekļa āķos un reģistra adresēs.

Produkcijas izvietojums

GitLab publicē atsauces arhitektūras no 1 000 līdz 50 000 lietotājiem, un tās ir vērts izlasīt, pat ja nekad nevienu neieviesīsiet, jo tās parāda, kurš komponents pirmais kļūst par vājo vietu.

Padoms, kas ietaupa visvairāk naudas, ir paša GitLab, un tas iestājas pret sarežģītību: zem 3 000 lietotājiem viņi iesaka drošu rezerves kopēšanas stratēģiju, nevis augstu pieejamību. Dokumentācija par to ir neparasti atklāta, atzīmējot, ka rezerves kopiju pieejai „atjaunošanas laiks gan ir lēnāks“, taču tā „nozīmē daudz mazāku arhitektūru un mazākas uzturēšanas izmaksas“. Virs 3 000 lietotājiem vai tur, kur dīkstāve patiešām aptur uzņēmuma darbu, ieteikums ir augsta pieejamība.

Uztveriet to nopietni. Viens labi dublēts mezgls ar pārbaudītu atjaunošanu praksē ir uzticamāks nekā līdz galam nesaprasts augstas pieejamības klasteris, un krietni lētāks.

Artefaktus, augšupielādes, LFS objektus un reģistra attēlus pārvietojiet uz objektu krātuvi jau no paša sākuma. Pamatojums tāds pats kā visur citur: mezgls paliek bez stāvokļa, rezerves kopijas ir pārvaldāmas un migrācija iespējama.

Trīs lietas, kas noiet greizi

Viss iepriekš minētais ir dokumentācijā. Šīs ir tās, kas izraisa incidentus.

Jūsu rezerves kopijā nav tā, ar ko to atšifrēt

Šī ir vissvarīgākā rindkopa visā rakstā.

gitlab-backup create saglabā ļoti daudz: datubāzi, repozitorijus, LFS objektus, CI artefaktus un uzdevumu žurnālus, reģistra attēlus, wiki, augšupielādes, Pages saturu, Terraform stāvokli, fragmentus. Tas nesaglabā konfigurācijas direktoriju un konkrēti /etc/gitlab/gitlab-secrets.json.

Šajā failā ir datubāzes šifrēšanas atslēga. Dokumentācija par sekām runā tieši: „Ja jūs to pazaudējat, GitLab lietotne nevarēs atšifrēt nevienu šifrētu vērtību datubāzē.“ Tas nozīmē CI/CD mainīgos, žetonus, divfaktoru noslēpumus un integrāciju akreditācijas datus. Jums būs rezerves kopija, kas atjaunojas instancē, kura nespēj nolasīt savus noslēpumus.

Tāpat netiek iekļauti: /etc/gitlab/gitlab.rb, TLS atslēgas un sertifikāti, SSH resursdatora atslēgas un objektu krātuves saturs, ja objektu krātuve ir konfigurēta. Pēdējais pieķer tos, kuri arhitektūras ziņā rīkojās pareizi un pēc tam pieņēma, ka rezerves kopija to aptver.

Tāpēc dublējiet /etc/gitlab atsevišķi, glabājiet to kaut kur citur, nevis blakus arhīvam, jo tā ir arhīva atslēga, un pēc tam atjaunojiet visu uz testa mašīnas un pārliecinieties, ka varat pieteikties un nolasīt CI mainīgo. Nepārbaudīta atjaunošana nav rezerves kopija, un GitLab gadījumā nepārbaudīta atjaunošana parasti ir salauzta.

Atjaunināt vienā lēcienā nevar

GitLab ir obligātas atjaunināšanas pieturas, un tas nav ieteikums. Tās nevar izlaist. Kopš 17.5 pieturas ir paredzamas, tās iekrīt uz x.2, x.5, x.8 un x.11, tāpēc atjaunināšana no 18.0 uz 19.2 nozīmē vispirms apstāties pie 18.2, 18.5, 18.8 un 18.11. Versija 19.0 nav pietura, tāpēc no 18.11 jūs ejat tieši uz 19.2.

Katrā pieturā ir fona migrācijas, kurām jābūt pilnībā pabeigtām, pirms pārejat uz nākamo. Ja nākamo atjaunināšanu sāk, kamēr migrācijas vēl darbojas, instances nonāk stāvokļos, kuru atšķetināšanai vajadzīgs atbalsts. Lielā instancē šīs migrācijas var ilgt stundām.

Divas praktiskas sekas. Atjauniniet regulāri, jo gads atliktu atjauninājumu ir nedēļas nogale secīgu atjauninājumu. Un vienmēr ņemiet mērķa minorversijas jaunāko labojumu laidienu, nevis pirmo; dokumentācija to norāda skaidri. GitLab uztur atjaunināšanas ceļa rīku, kas aprēķina secību jūsu vietā, un to ir vērts izmantot, nevis spriest pašiem.

Izpildītāji ir tur, kur ir īstās izmaksas

GitLab serveris nedarbina jūsu CI. GitLab Runner ir atsevišķs komponents, ko jūs instalējat, konfigurējat un apmaksājat uz savas infrastruktūras. Pašu pārvaldītajā Free nav iekļautas nekādas skaitļošanas minūtes, jo nav iekļautas skaitļošanas jaudas, ko dot: mašīnas jūs nodrošināt paši.

Parasti tas ir izdevīgi, jo jebkurā nopietnā apjomā atvēlēts izpildītājs uz minūti ir lētāks nekā mitināts CI, un jūs varat pievienot jebkuru aparatūru, kas būvējumam vajadzīga. Taču tas ir īsts infrastruktūras darbs. Jums būs jāpieņem lēmumi par izpildes vidēm (shell, Docker vai Kubernetes), par automātisku mērogošanu, lai izpildītāji nedīkstāvētu trijos naktī, un par kešatmiņu, kas ir atšķirība starp četru minūšu un četrpadsmit minūšu konveijeru.

Izpildītāju parkam budžetā paredziet atsevišķu pozīciju. Komandas, kas pašu mitināšanas izmaksas modelē, skatoties tikai uz GitLab mezglu, tās ievērojami novērtē par zemu un pēc tam iztrūkumu atklāj kā gaidošu uzdevumu rindu.

Pāreja no GitHub

GitHub importētājs ir labs, ievērojami labāks nekā vairums piegādātāju migrācijas rīku, un tas pārnes repozitorija datus, zarus, LFS objektus, problēmas un pull request ar to komentāriem, pārskatiem un atbildēm diskusijās, wiki lapas, laidienus un pielikumus, birkas, atskaites punktus, zaru aizsardzības noteikumus un līdzstrādniekus ar lomu kartēšanu.

Dokumentētos robus ir vērts ņemt vērā plānošanā. Organizācijas un grupas netiek pārnestas, tāpēc grupu struktūru jūs izstrādājat paši, nevis mantojat, un parasti tas ir uzlabojums. GitHub Actions darbplūsmas netiek pārveidotas par GitLab CI. Pull request komentāri, kas ir vecāki par 2017. gadu, GitHub API ierobežojumu dēļ tiek importēti kā atsevišķi pavedieni, un repozitorijiem ar vairāk nekā aptuveni 30 000 komentāriem jāieslēdz alternatīvā komentāru importēšanas metode.

Tā kā GitHub izmanto # gan problēmām, gan pull request, bet GitLab tās nošķir, dažas savstarpējās atsauces neatrisināsies. Nekas netiek zaudēts, taču saites vecās diskusijās var norādīt uz nepareizo objektu.

Plānojiet CI pārrakstīšanu kā īsto projektu, jo tas tāds ir. Viss pārējais ir importa uzdevums, ko varat palaist un pārbaudīt.

Eiropas aspekts

Uzņēmumiem, kas darbojas Eiropā, ir arī atbilstības dimensija, ne tikai izmaksas. Pirmkods, būvēšanas konveijeri un artefakti ir vieni no jutīgākajiem aktīviem, kas tehnoloģiju uzņēmumam pieder, un tas, kur tie atrodas, arvien biežāk ir jautājums, ko jums uzdod, nevis jautājums, uz kuru jūs izvēlaties atbildēt.

Pašu mitināšana tos novieto jūsu kontrolētās robežās, kas vienā solī vienkāršo VDAR datu nosūtīšanas analīzi un NIS2 piegādes ķēdes jautājumus, un tas ir tas pats suverenitātes arguments, uz kura balstīts Mākoņdatošanas un MI attīstības akts.

Ciešāka saikne ir ar Kibernoturības aktu. Ja jūs piegādājat programmatūru ES tirgum, jums būs vajadzīgi atkarību saraksti, ievainojamību apstrāde un koordinētas informācijas atklāšanas process. Šie pienākumi tiek izpildīti jūsu būvēšanas konveijerā, nevis dokumentā, un, ja konveijers, reģistrs un skenēšana ir vienā sistēmā, ko darbināt jūs paši, pierādījumu sagatavošana ir krietni vieglāka nekā to salikšana no četriem piegādātājiem.

Kad nav vērts

Ja jums ir mazāk par divdesmit inženieriem, nav regulatīva spiediena un nav stingra viedokļa par to, kur glabājas kods, izmantojiet SaaS. Gan GitLab.com, gan GitHub ir izcili, un ekspluatācijas darbs izmaksās vairāk nekā abonements.

Ja jūsu organizācija ir dziļi iesakņojusies GitHub ekosistēmā, godīgi saskaitiet, ko zaudētu. Actions, tirgus vieta un tas, ka platformu pazīst katrs kandidāts, kuru pieņemat darbā, ir reāli aktīvi, un atbilde nav automātiski tāda, ka uzvar GitLab.

Un, ja neviens neuzņemsies atbildību par instanci, nesāciet. GitLab atalgo īpašnieku, kurš to labo, pieskata izpildītāju parku un pārbauda atjaunošanu. Bez šī cilvēka tas pārvēršas par nelabotu serveri, kurā glabājas jūsu vērtīgākais aktīvs, un tas ir sliktāk nekā SaaS, no kura mēģinājāt aiziet.

Palīdzība

Mēs ieviešam un uzturam pašu mitinātu izstrādes infrastruktūru uzņēmumiem, kas strādā Eiropā, ieskaitot daļas, kas nevienam nepatīk: atjaunināšanas secības caur obligātajām pieturām, izpildītāju parkus, kas pareizi mērogojas automātiski, objektu krātuves migrācijas un rezerves kopēšanas shēmas, kuras patiešām ir atjaunotas.

Ja vēlaties godīgi dimensionētu GitLab instanci, GitHub migrāciju, ko plāno kāds, kurš CI pārrakstīšanu jau ir veicis, vai pārbaudi, vai jūsu pašreizējā rezerves kopija izturētu īstu kļūmi, rakstiet uz office@c9group.dev. Vairāk par mūsu infrastruktūras darbu lasiet AWS izmaksu optimizācijas lapā.

Ja jūs veidojat pilnu pašu mitinātu rīku komplektu, tas pats pamatojums attiecas uz analītiku, mārketinga automatizāciju un komandas saziņu.

---

Publicēts: 2026. gada 8. augustā · Atjaunināts: 2026. gada 10. oktobrī Kategorijas: DevOps, atvērtais kods, privātums