Avoimen lähdekoodin DevOps suuressa mittakaavassa: GitLab omassa ylläpidossa

laptop screen showing code in a busy room

Lähdekoodi on se yksi omaisuuserä, jota lähes jokainen teknologiayritys pitää kriittisenä, ja samalla se, jota useimmat säilyttävät infrastruktuurilla, jota eivät omista, lainkäyttöalueella, jota eivät valinneet, sopimuksella, jota eivät lukeneet huolellisesti. Yleensä tuo järjestely on aivan kunnossa. Silti kannattaa tietää, mitä vaihtoehto maksaa, sillä GitLab on jo yli vuosikymmenen ajan tehnyt koko kehityskaaren omasta ylläpidosta aidosti toteuttamiskelpoista.

Se on myös tuote, jonka ilmainen taso on antelias ja jonka käyttötaakka on raskaampi kuin useimmat odottavat. Molemmat kannattaa ymmärtää ennen sitoutumista, joten tämä opas kertoo, mitä itse ylläpidetty GitLab oikeasti on, mitä ilmainen taso todella antaa ja mitkä kolme käyttöongelmaa aiheuttavat suurimman osan kivusta.

Mikä GitLab on

Ei Git-hosting johon on pultattu lisukkeita. Rails-sovellus, PostgreSQL, Redis, Gitaly repositorioiden tallennukseen, Sidekiq taustatöihin ja konttirekisteri, paketoituna yhdeksi järjestelmäksi, joka kattaa versionhallinnan, koodikatselmoinnin, tiketöinnin, CI/CD:n, paketti- ja konttirekisterit, tietoturvaskannauksen ja käyttöönoton.

Juuri tuo laajuus on koko argumentti. GitHub plus Actions plus Dependabot plus pakettirekisteri plus projektinseurantaväline antaa vertailukelpoisen ominaisuusjoukon, koottuna osista. GitLab on yksi sovellus yhdellä oikeusmallilla ja yhdellä tietokannalla. Se on joko täsmälleen se mitä haluat tai enemmän kuin tarvitset, ja kumpi näistä, riippuu siitä kuinka suuren osan kaaresta aiot todella ajaa samassa paikassa.

Arkkitehtuurin kannalta olennainen tosiasia on sama kuin analytiikan ylläpidossa Matomolla, markkinoinnin automaatiossa Mauticilla tai tiimiviestinnässä Mattermostilla: se pyörii siellä minne sen laitat. Sinun repositoriosi, sinun CI-lokisi, sinun artefaktisi, sinun tietokantasi.

Lisenssitilanne suoraan sanottuna

Tämä hämmentää aidosti ja ansaitsee täsmällisyyttä, koska sekaannus menee päinvastaiseen suuntaan kuin ihmiset odottavat.

Lähdejakeluja on kaksi. Community Edition on MIT-lisensoitu. Enterprise Editionilla on oma, rajoittavampi lisenssinsä, joka kattaa repositorion ee/-hakemiston. Tähän asti kuulostaa tavanomaiselta avoimen ytimen mallilta.

Yllättävä osa: Linux-paketti, jonka lähes kaikki asentavat, on Enterprise Edition -käännös, ja ilman lisenssiavainta se pyörii Free-tasona ja käyttäytyy kuin Community Edition. Et siis aja MIT-lisensoitua jakelua, ellet ole tietoisesti valinnut CE-pakettia. Käytännössä sillä on harvoin merkitystä, mutta jos syysi omaan ylläpitoon on tiukka avoimen lähdekoodin linjaus eikä datan hallinta, sillä on valtava merkitys, eikä juuri kukaan tarkista sitä.

Kaupalliset tasot ovat Free, Premium 29 dollaria käyttäjältä kuukaudessa vuosilaskutuksella, ja Ultimate hinnalla sopimuksen mukaan. Premium lisää edistyneen CI/CD:n, paremman projektinhallinnan ja etusijaisen tuen. Ultimate lisää tietoturva- ja vaatimustenmukaisuuspaketin: sovellusturvatestauksen, toimitusketjun turvallisuuden ja riippuvuusskannauksen. Molemmat maksulliset tasot sisältävät nykyään GitLab Creditsejä tekoälyominaisuuksiin, 12 dollaria käyttäjältä kuukaudessa Premiumissa ja 24 Ultimatessa.

Ja tässä on se seikka, joka muuttaa useimpien tiimien laskelman, ja Mattermost-tilanteen tarkka käänteisyys: Free-tasolla ei omassa ylläpidossa ole käyttäjärajaa. Viiden käyttäjän katto, josta ihmiset ovat kuulleet, koskee vain yksityisiä ryhmiä GitLab.comissa. Itse ylläpidettynä Free antaa rajattomasti käyttäjiä, versionhallinnan, CI/CD:n ja rekisterit, ja tallennuksen sekä ajurit tuot itse. Sadan insinöörin organisaatio voi pyöriä sillä kokonaan.

Luovut tietoturvaskannauksesta, vaatimustenmukaisuusraportoinnista, edistyneistä hyväksyntäsäännöistä ja tuesta. Jos kuulut kyberkestävyysasetuksen piiriin ja haluat riippuvuusskannauksen ja SBOM-tuotannon rakennettuna putkiin eikä erillisistä työkaluista koottuna, se on Ultimate-keskustelu. Useimmille muille tiimeille Free ei ole kokeilu. Se on kestävä pysyvä vastaus.

Käyttöönotto

Pieni asennus

GitLab on raskaampi kuin miltä näyttää. Dokumentoitu perustaso yhdelle solmulle on 8 vCPU ja 16 gigatavua muistia, ja toisin kuin useimmat valmistajien minimit tuo luku on rehellinen eikä optimistinen. Sen voi puristaa 8 gigatavuun, mutta sen huomaa, ja swap kannattaa ottaa pois päältä, koska tämän sovelluksen swappaaminen on pahempaa kuin muistin puuttuminen.

PostgreSQL on ainoa tuettu tietokanta. Mikä versio, riippuu GitLab-versiostasi: 17.x haluaa PostgreSQL 14.14:stä 16.x:ään, 18.x haluaa 16.5:stä 17.x:ään, ja 19.x haluaa 17.x:n. Redis 7.2 on suositus, 7.0 minimi, ja Valkey 7.2 käy korvaajaksi. Vain itsenäisiä instansseja, koska Redisin klusteroituja ja serverless-muunnelmia ei tueta.

Asenna Linux-paketilla. Saatavilla on Helm-chartteja, Operator, Docker-imaget ja lähdekoodipolku, mutta Linux-paketti on kypsin vaihtoehto ja se on se, jolla GitLab.com itse pyörii. Se tuo mukanaan PostgreSQL:n, Redisin ja Sidekiqin, joten yksi kone ja yksi asetustiedosto antavat toimivan instanssin.

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

Yksi gitlab-ctl reconfigure myöhemmin sinulla on instanssi. Aseta external_url oikein ensimmäisellä kerralla, koska tuo arvo päätyy leivotuksi kloonausosoitteisiin, webhookeihin ja rekisterin osoitteisiin.

Tuotantoasennus

GitLab julkaisee viitearkkitehtuureja tuhannesta viiteenkymmeneentuhanteen käyttäjään, ja niitä kannattaa lukea vaikka ei toteuttaisi yhtäkään, koska ne näyttävät mikä komponentti muuttuu pullonkaulaksi ensimmäisenä.

Eniten rahaa säästävä neuvo tulee GitLabilta itseltään ja puhuu monimutkaisuutta vastaan: alle 3 000 käyttäjän kohdalla he suosittelevat vankkaa varmuuskopiostrategiaa korkean saatavuuden sijaan. Dokumentaatio on tässä epätavallisen suora ja huomauttaa, että varmuuskopioihin nojaavassa lähestymistavassa palautusaika on hitaampi, mutta se merkitsee paljon pienempää arkkitehtuuria ja alempia ylläpitokustannuksia. Yli 3 000 käyttäjän kohdalla, tai siellä missä katko oikeasti pysäyttää yrityksen, korkeasta saatavuudesta tulee suositus.

Ota se tosissasi. Yksi hyvin varmuuskopioitu solmu testattuine palautuksineen on käytännössä luotettavampi kuin puoliksi ymmärretty korkean saatavuuden klusteri, ja huomattavasti halvempi.

Siirrä artefaktit, lataukset, LFS-objektit ja rekisterin imaget objektitallennukseen alusta alkaen. Sama päättely kuin kaikkialla muualla: se pitää solmun tilattomana, varmuuskopiot hallittavina ja siirron mahdollisena.

Kolme asiaa, jotka menevät pieleen

Kaikki edellä oleva on dokumentaatiossa. Nämä tuottavat häiriöitä.

Varmuuskopiosi ei sisällä sitä, mikä purkaa sen salauksen

Tämä on artikkelin tärkein kappale.

gitlab-backup create ottaa talteen paljon: tietokannan, repositoriot, LFS-objektit, CI-artefaktit ja työlokit, rekisterin imaget, wikit, lataukset, Pages-sisällön, Terraform-tilan, snippetit. Mitä se ei ota talteen, on asetushakemisto, ja nimenomaan /etc/gitlab/gitlab-secrets.json.

Tuo tiedosto sisältää tietokannan salausavaimen. Dokumentaatio on tylysti selvä seurauksesta: jos hukkaat sen, GitLab-sovellus ei kykene purkamaan yhtäkään salattua arvoa tietokannassa. Se tarkoittaa CI/CD-muuttujia, tunnuksia, kaksivaiheisen tunnistuksen salaisuuksia ja integraatioiden tunnuksia. Sinulla olisi varmuuskopio, joka palautuu instanssiin, joka ei kykene lukemaan omia salaisuuksiaan.

Ulkopuolelle jäävät myös /etc/gitlab/gitlab.rb, TLS-avaimet ja varmenteet, SSH-isäntäavaimet sekä objektitallennuksen sisältö silloin kun objektitallennus on määritetty. Viimeinen näistä nappaa juuri ne, jotka tekivät arkkitehtonisesti oikein ja sitten olettivat varmuuskopion kattavan sen.

Varmuuskopioi siis /etc/gitlab erikseen, säilytä se muualla kuin arkiston vieressä, koska se on arkiston avain, ja palauta sitten koko paketti kertakäyttökoneelle ja varmista että pääset kirjautumaan sisään ja lukemaan CI-muuttujan. Testaamaton varmuuskopio ei ole varmuuskopio, ja GitLabin tapauksessa testaamaton palautus on yleensä rikki.

Et voi päivittää yhdellä hypyllä

GitLabilla on pakolliset päivityspysäkit, eikä tämä ole suositus. Niitä ei voi ohittaa. Versiosta 17.5 alkaen pysäkit ovat ennustettavia ja osuvat kohtiin x.2, x.5, x.8 ja x.11, joten siirtyminen 18.0:sta 19.2:een tarkoittaa kulkemista 18.2:n, 18.5:n, 18.8:n, 18.11:n ja 19.0:n kautta.

Jokaiseen pysäkkiin liittyy taustamigraatioita, joiden on valmistuttava täysin ennen seuraavaan siirtymistä. Seuraavan päivityksen käynnistäminen migraatioiden yhä pyöriessä on se tapa, jolla instanssit päätyvät tiloihin joita vain tuki saa auki. Suurella instanssilla nuo migraatiot voivat kestää tunteja.

Kaksi käytännön seurausta. Päivitä säännöllisesti, koska vuosi lykättyjä päivityksiä on viikonloppu peräkkäisiä. Ja ota aina kohdeversion viimeisin korjausjulkaisu eikä ensimmäistä, minkä dokumentaatio sanoo suoraan. GitLab ylläpitää työkalua, joka laskee päivityspolun puolestasi, ja sitä kannattaa käyttää sen sijaan että päättelisi itse.

Todellinen kustannus on ajureissa

GitLab-palvelin ei aja CI:täsi. GitLab Runner on erillinen komponentti, jonka asennat, määrität ja maksat, sinun tarjoamallasi infrastruktuurilla. Itse ylläpidetty Free ei sisällä lainkaan laskentaminuutteja, koska mukana ei tule laskentatehoa annettavaksi: tuot omat koneesi.

Yleensä se on hyvä diili, koska oma ajuri maksaa minuutilta vähemmän kuin isännöity CI heti kun volyymi muuttuu vakavaksi, ja voit antaa jokaiselle buildille sen tarvitseman raudan. Mutta se on aitoa infrastruktuurityötä. Teet päätöksiä executoreista, onko se shell, Docker vai Kubernetes; automaattiskaalauksesta, jotta ajurit eivät pyöri tyhjää kolmelta aamuyöllä; ja välimuistista, joka on ero neljän ja neljäntoista minuutin putken välillä.

Budjetoi ajurilaivasto omana rivinään. Tiimit, jotka mallintavat oman ylläpidon kustannuksen katsomalla vain GitLab-solmua, aliarvioivat sen selvästi, ja huomaavat vajeen sitten odottavien töiden jonona.

Pois GitHubista

GitHub-tuoja on hyvä, huomattavasti parempi kuin useimmat valmistajien siirtotyökalut, ja se tuo repositorion datan, haarat, LFS-objektit, tiketit ja pull requestit kommentteineen, katselmointeineen ja keskusteluvastauksineen, wikisivut, julkaisut ja liitteet, tunnisteet, virstanpylväät, haarojen suojaussäännöt sekä osallistujat roolikartoituksineen.

Dokumentoidut aukot kannattaa ennakoida. Organisaatiot ja ryhmät eivät siirry, joten ryhmärakenne on sinun suunniteltavanasi eikä perittävänäsi, mikä on yleensä parannus. GitHub Actions -työnkulut eivät muunnu GitLab CI:ksi. Ennen vuotta 2017 tehdyt pull request -kommentit tuodaan erillisinä ketjuina GitHubin rajapinnan rajoitusten vuoksi, ja yli noin 30 000 kommentin repositoriot vaativat vaihtoehtoisen kommenttien tuontimenetelmän käyttöönottoa.

Koska GitHub käyttää merkkiä # sekä tiketeille että pull requesteille ja GitLab erottaa ne toisistaan, osa ristiviittauksista ei ratkea. Mitään ei katoa, mutta vanhojen keskustelujen linkit voivat osoittaa väärään paikkaan.

Suunnittele CI:n uudelleenkirjoitus varsinaisena projektina, koska se on sitä. Kaikki muu on tuontiajo, jonka käynnistät ja tarkistat.

Eurooppalainen näkökulma

Euroopassa toimiville yrityksille kustannuksen päälle tulee vaatimustenmukaisuuden ulottuvuus. Lähdekoodi, käännösputket ja artefaktit kuuluvat herkimpään mitä teknologiayrityksellä on, ja se missä ne asuvat on yhä useammin kysymys, joka sinulle esitetään eikä sellainen johon valitset vastata.

Oma ylläpito sijoittaa ne rajan sisään, jota sinä hallitset, mikä yhdellä liikkeellä yksinkertaistaa GDPR:n mukaisen siirtoanalyysin ja NIS2:n toimitusketjukysymykset, ja se on sama suvereniteettiperustelu, jonka ympärille Cloud and AI Development Act on rakennettu.

Terävämpi yhteys on kyberkestävyysasetus. Jos tuot ohjelmistoa EU-markkinoille, tarvitset riippuvuusluettelot, haavoittuvuuksien käsittelyn ja koordinoidun julkistamisprosessin. Nuo velvoitteet täytetään käännösputkessa eikä dokumentissa, ja se että putki, rekisteri ja skannaus ovat yhdessä itse ylläpitämässäsi järjestelmässä tekee todisteiden tuottamisesta selvästi vähemmän tuskaista kuin niiden kokoaminen neljältä toimittajalta.

Milloin ei kannata

Jos teitä on alle kaksikymmentä insinööriä, sääntelypainetta ei ole eikä kenelläkään ole vahvaa mielipidettä siitä missä koodi asuu, ottakaa SaaS. GitLab.com ja GitHub ovat molemmat erinomaisia, ja ylläpitotyö maksaa enemmän kuin tilaus.

Jos organisaatiosi istuu syvällä GitHubin ekosysteemissä, laske rehellisesti mitä menettäisit. Actions, marketplace ja alustan pelkkä tuttuus jokaiselle palkkaamallesi hakijalle ovat todellisia arvoja, eikä vastaus ole automaattisesti että GitLab voittaa.

Ja jos kukaan ei ota instanssia omakseen, älä aloita. GitLab palkitsee sen, joka paikkaa sen, seuraa ajurilaivastoa ja testaa palautuksen. Ilman tuota ihmistä se rappeutuu paikkaamattomaksi laatikoksi, jossa on arvokkain omaisuutesi, mikä on pahempaa kuin se SaaS josta yritit päästä eroon.

Näin voimme auttaa

Pystytämme ja ylläpidämme itse hostattua kehitysinfrastruktuuria Euroopassa toimiville yrityksille, mukaan lukien ne osat joista kukaan ei pidä: päivityssarjat pakollisten pysäkkien läpi, ajurilaivastot, jotka skaalautuvat kunnolla, siirrot objektitallennukseen ja varmuuskopiomallit, jotka on oikeasti palautettu.

Jos haluat rehellisesti mitoitetun GitLab-instanssin, GitHub-siirron, jonka on suunnitellut joku, joka on tehnyt CI:n uudelleenkirjoituksen ennenkin, tai arvion siitä, selviäisikö nykyinen varmuuskopiosi todellisesta viasta, kirjoita osoitteeseen office@c9group.dev. Lisää infrastruktuurityöstämme AWS-kustannusoptimoinnin sivulla.

Jos kokoat täyttä itse ylläpidettyä pinoa, sama päättely pätee analytiikkaan, markkinoinnin automaatioon ja tiimiviestintään.

Julkaistu: 8. elokuuta 2026 Kategoriat: DevOps, Avoin lähdekoodi, Yksityisyys