Åpen kildekode-DevOps i stor skala: å drifte GitLab selv

Kildekode er den ene eiendelen nesten alle teknologiselskaper er enige om at er kritisk, og samtidig den de fleste oppbevarer på infrastruktur de ikke eier, i en jurisdiksjon de ikke valgte, under en kontrakt de ikke leste nøye. Som regel går den ordningen helt fint. Likevel er det verdt å vite hva alternativet koster, for GitLab har i over ti år gjort det virkelig praktisk å hoste hele utviklingsløpet selv.

Det er også et produkt der gratisnivået er romsligere og driftsbyrden tyngre enn de fleste venter. Begge deler bør du forstå før du binder deg, så denne guiden handler om hva selvhostet GitLab faktisk er, hva gratisnivået virkelig gir, og de tre driftsproblemene som står for mesteparten av smerten.

Hva GitLab er

Ikke en Git-hosting med ekstrautstyr skrudd på. En Rails-applikasjon, PostgreSQL, Redis, Gitaly for lagring av repositorier, Sidekiq for bakgrunnsjobber og et containerregister, pakket sammen som ett system som dekker versjonskontroll, kodegjennomgang, saksoppfølging, CI/CD, pakke- og containerregistre, sikkerhetsskanning og utrulling.

Den bredden er hele argumentet. GitHub pluss Actions pluss Dependabot pluss et pakkeregister pluss et prosjektverktøy gir et sammenlignbart funksjonssett, satt sammen av deler. GitLab er én applikasjon med én rettighetsmodell og én database. Det er enten nøyaktig det du vil ha, eller mer enn du trenger, og hvilken av delene avhenger av hvor mye av løpet du faktisk har tenkt å kjøre på ett sted.

Det arkitektonisk viktige er det samme som ved å hoste analysen din med Matomo, markedsautomatiseringen med Mautic eller teamchatten med Mattermost: det kjører der du setter det. Dine repositorier, dine CI-logger, dine artefakter, din database.

Lisensbildet, sagt rett ut

Dette forvirrer virkelig og fortjener presisjon, for forvirringen går motsatt vei av det folk venter.

Det finnes to kildedistribusjoner. Community Edition er MIT-lisensiert. Enterprise Edition har sin egen, mer restriktive lisens som dekker mappen ee/ i repositoriet. Så langt høres det ut som den vanlige open core-modellen.

Det som overrasker: Linux-pakken nesten alle installerer er Enterprise Edition-bygget, og uten lisensnøkkel kjører den som Free-nivå og oppfører seg som Community Edition. Du kjører altså ikke den MIT-lisensierte distribusjonen med mindre du bevisst har valgt CE-pakken. I praksis betyr det sjelden noe, men er grunnen din til å selvhoste en streng åpen kildekode-policy snarere enn datakontroll, betyr det svært mye, og nesten ingen sjekker det.

De kommersielle nivåene er Free, Premium til 29 dollar per bruker i måneden ved årlig fakturering, og Ultimate til pris etter avtale. Premium legger til avansert CI/CD, bedre prosjektstyring og prioritert støtte. Ultimate legger til sikkerhets- og etterlevelsespakken: applikasjonssikkerhetstesting, forsyningskjedesikkerhet, avhengighetsskanning. Begge betalte nivåer inneholder nå GitLab Credits til AI-funksjonene, 12 dollar per bruker i måneden på Premium og 24 på Ultimate.

Og her er faktumet som endrer regnestykket for de fleste team, og den nøyaktige motsetningen til Mattermost-situasjonen: Free-nivået i selvhostet drift har ingen brukergrense. Taket på fem brukere som folk har hørt om, gjelder bare private grupper på GitLab.com. Selvhostet gir Free deg ubegrenset antall brukere, versjonskontroll, CI/CD og registre, og lagring og runnere tar du med selv. En organisasjon på hundre ingeniører kan kjøre helt på det.

Det du gir slipp på er sikkerhetsskanning, etterlevelsesrapportering, avanserte godkjenningsregler og støtte. Er du omfattet av forordningen om cyberresiliens og vil ha avhengighetsskanning og SBOM-generering bygget inn i pipelinene i stedet for satt sammen av separate verktøy, er det en Ultimate-samtale. For de fleste andre team er Free ikke en prøveperiode. Det er et holdbart permanent svar.

Oppsettet

En liten installasjon

GitLab er tyngre enn det ser ut. Det dokumenterte utgangspunktet for én node er 8 vCPU og 16 GB RAM, og i motsetning til de fleste leverandørminimum er det tallet ærlig snarere enn optimistisk. Det kan presses ned i 8 GB, men du merker det, og swap bør være av, for å la denne applikasjonen swappe er verre enn å ikke ha minnet.

PostgreSQL er den eneste støttede databasen. Hvilken versjon avhenger av GitLab-versjonen din: 17.x vil ha PostgreSQL 14.14 til 16.x, 18.x vil ha 16.5 til 17.x, og 19.x vil ha 17.x. Redis 7.2 anbefales med 7.0 som minimum, og Valkey 7.2 fungerer som erstatning. Kun frittstående instanser, siden klyngede og serverless varianter av Redis ikke støttes.

Installer med Linux-pakken. Det finnes Helm-charts, en Operator, Docker-images og en vei fra kildekode, men Linux-pakken er det mest modne alternativet og er det GitLab.com selv kjører på. Den tar med PostgreSQL, Redis og Sidekiq, så én maskin og én konfigurasjonsfil gir en fungerende instans.

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

Én gitlab-ctl reconfigure senere har du en instans. Sett external_url riktig første gang, for den verdien ender innbakt i klone-URL-er, webhooks og registeradresser.

En produksjonsinstallasjon

GitLab publiserer referansearkitekturer fra 1 000 til 50 000 brukere, og de er verdt å lese selv om du aldri implementerer noen av dem, fordi de viser hvilken komponent som blir flaskehalsen først.

Rådet som sparer mest penger kommer fra GitLab selv og argumenterer mot kompleksitet: under 3 000 brukere anbefaler de en solid sikkerhetskopistrategi framfor høy tilgjengelighet. Dokumentasjonen er uvanlig ærlig om det og bemerker at en sikkerhetskopitilnærming riktignok har lengre gjenopprettingstid, men betyr en langt mindre arkitektur og lavere vedlikeholdskostnader. Over 3 000 brukere, eller der et avbrudd faktisk stopper selskapet, blir høy tilgjengelighet anbefalingen.

Ta det på alvor. Én godt sikkerhetskopiert node med en testet gjenoppretting er i praksis mer pålitelig enn en halvt forstått HA-klynge, og en god del billigere.

Flytt artefakter, opplastinger, LFS-objekter og registerbilder til objektlager fra starten. Samme resonnement som overalt ellers: det holder noden tilstandsløs, sikkerhetskopiene håndterbare og migreringen mulig.

De tre tingene som går galt

Alt over står i dokumentasjonen. Disse produserer hendelser.

Sikkerhetskopien din inneholder ikke det som dekrypterer den

Dette er det viktigste avsnittet i artikkelen.

gitlab-backup create fanger mye: databasen, repositorier, LFS-objekter, CI-artefakter og jobblogger, registerbilder, wikier, opplastinger, Pages-innhold, Terraform-tilstand, snutter. Det den ikke fanger er konfigurasjonsmappen, og særlig /etc/gitlab/gitlab-secrets.json.

Den filen inneholder databasens krypteringsnøkkel. Dokumentasjonen er kontant om konsekvensen: mister du den, vil GitLab-applikasjonen ikke kunne dekryptere noen krypterte verdier i databasen. Det vil si CI/CD-variabler, tokens, tofaktorhemmeligheter og integrasjonsdetaljer. Du ville hatt en sikkerhetskopi som gjenopprettes til en instans som ikke kan lese sine egne hemmeligheter.

Også utelatt: /etc/gitlab/gitlab.rb, TLS-nøkler og sertifikater, SSH-vertsnøkler, og innholdet i objektlageret når objektlager er konfigurert. Det siste tar nettopp dem som gjorde det arkitektonisk riktige og deretter antok at sikkerhetskopien dekket det.

Så ta sikkerhetskopi av /etc/gitlab separat, oppbevar den et annet sted enn arkivet, siden den er nøkkelen til arkivet, og gjenopprett så det hele på en engangsmaskin og bekreft at du kan logge inn og lese en CI-variabel. En utestet sikkerhetskopi er ingen sikkerhetskopi, og i GitLabs tilfelle er en utestet gjenoppretting som regel ødelagt.

Du kan ikke oppgradere i ett sprang

GitLab har obligatoriske oppgraderingsstopp, og det er ikke veiledende. Du kan ikke hoppe over dem. Siden 17.5 er stoppene forutsigbare og ligger på x.2, x.5, x.8 og x.11, så å gå fra 18.0 til 19.2 betyr å passere 18.2, 18.5, 18.8, 18.11 og 19.0.

Hvert stopp innebærer bakgrunnsmigreringer som må være helt ferdige før du går videre. Å starte neste oppgradering mens migreringer fortsatt kjører er slik instanser ender i tilstander bare support klarer å løse opp. På en stor instans kan de migreringene ta timer.

To praktiske konsekvenser. Oppgrader jevnlig, for et år med utsatte oppgraderinger er en helg med oppgraderinger på rad. Og ta alltid siste patch-utgivelse av en mål-minorversjon framfor den første, noe dokumentasjonen sier eksplisitt. GitLab vedlikeholder et verktøy som regner ut oppgraderingsveien for deg, og det er bedre å bruke det enn å resonnere seg fram selv.

Den virkelige kostnaden ligger i runnerne

GitLab-serveren kjører ikke CI-en din. GitLab Runner er en egen komponent som du installerer, konfigurerer og betaler for, på infrastruktur du stiller med. Selvhostet Free inneholder ingen beregningsminutter i det hele tatt, fordi det ikke finnes inkludert beregningskraft å gi: du tar med dine egne maskiner.

Det er som regel en god avtale, for en dedikert runner koster mindre per minutt enn hostet CI så snart volumet blir alvorlig, og du kan gi hvert bygg den maskinvaren det trenger. Men det er reelt infrastrukturarbeid. Du tar valg om executors, om det er shell, Docker eller Kubernetes; om autoskalering, slik at runnere ikke går på tomgang klokka tre om natta; og om caching, som er forskjellen på en pipeline på fire og en på fjorten minutter.

Budsjetter runnerflåten som en egen post. Team som modellerer kostnaden ved selvhosting ved bare å se på GitLab-noden, undervurderer den betydelig og oppdager gapet etterpå som en kø av ventende jobber.

Bort fra GitHub

GitHub-importøren er god, betydelig bedre enn de fleste leverandørers migreringsverktøy, og den henter over repositorydata, brancher, LFS-objekter, saker og pull requests med kommentarer, gjennomganger og diskusjonssvar, wikisider, releaser og vedlegg, etiketter, milepæler, branch protection-regler og samarbeidspartnere med rollekartlegging.

De dokumenterte hullene er verdt å planlegge for. Organisasjoner og grupper følger ikke med, så gruppestrukturen designer du selv i stedet for å arve den, noe som som regel er en forbedring. GitHub Actions-arbeidsflyter konverteres ikke til GitLab CI. Pull request-kommentarer fra før 2017 importeres som separate tråder på grunn av begrensninger i GitHubs API, og repositorier med mer enn omtrent 30 000 kommentarer krever at den alternative kommentarimportmetoden slås på.

Siden GitHub bruker # for både saker og pull requests, mens GitLab skiller dem, vil noen kryssreferanser ikke la seg slå opp. Ingenting går tapt, men lenker i gamle diskusjoner kan peke på feil sted.

Planlegg CI-omskrivingen som selve prosjektet, for det er den. Alt annet er en importjobb du kan kjøre og kontrollere.

Den europeiske vinkelen

For selskaper som opererer i Europa legger det seg en etterlevelsesdimensjon oppå kostnaden. Kildekode, byggpipelines og artefakter hører til det mest følsomme et teknologiselskap har, og hvor de bor er i økende grad et spørsmål du får, snarere enn et du velger å svare på.

Selvhosting plasserer dem innenfor en grense du kontrollerer, noe som i én bevegelse forenkler overføringsanalysen under GDPR og forsyningskjedespørsmålene i NIS2, og det er samme suverenitetsargument som Cloud and AI Development Act er bygget rundt.

Den skarpeste forbindelsen er forordningen om cyberresiliens. Sender du programvare inn på EU-markedet, trenger du avhengighetsoversikter, sårbarhetshåndtering og en koordinert offentliggjøringsprosess. De pliktene oppfylles i byggpipelinen og ikke i et dokument, og å ha pipeline, register og skanning i ett system du selv drifter gjør det betydelig mindre smertefullt å framskaffe dokumentasjonen enn å samle den fra fire leverandører.

Når du bør la det være

Er dere under tjue ingeniører uten regulatorisk press og uten sterke meninger om hvor koden bor, ta SaaS-løsningen. GitLab.com og GitHub er begge utmerkede, og driftsarbeidet vil koste mer enn abonnementet.

Sitter organisasjonen din dypt i GitHubs økosystem, tell ærlig hva du ville mistet. Actions, markedsplassen og plattformens rene fortrolighet hos hver kandidat du ansetter er reelle verdier, og svaret er ikke automatisk at GitLab vinner.

Og hvis ingen vil eie instansen, ikke begynn. GitLab belønner en som lapper den, følger med på runnerflåten og tester gjenopprettingen. Uten den personen forfaller det til en ulappet boks med din mest verdifulle eiendel i, noe som er verre enn SaaS-en du prøvde å forlate.

Slik kan vi hjelpe

Vi setter opp og drifter selvhostet utviklingsinfrastruktur for selskaper som opererer i Europa, inkludert de delene ingen liker: oppgraderingsløp gjennom de obligatoriske stoppene, runnerflåter som autoskalerer skikkelig, migreringer til objektlager og sikkerhetskopiopplegg som faktisk har blitt gjenopprettet.

Vil du ha en ærlig dimensjonert GitLab-instans, en GitHub-migrering planlagt av noen som har gjort CI-omskrivingen før, eller en gjennomgang av om dagens sikkerhetskopi ville overleve møtet med en ekte feil, skriv til office@c9group.dev. Mer om infrastrukturarbeidet vårt på siden om AWS-kostnadsoptimalisering.

Setter du sammen en full selvhostet stakk, gjelder samme resonnement for analyse, markedsautomatisering og teamkommunikasjon.

---

Publisert: 8. august 2026 Kategorier: DevOps, Åpen kildekode, Personvern