Open source DevOps i stor skala: at drive GitLab selv

laptop screen showing code in a busy room

Kildekode er det ene aktiv, som næsten alle teknologivirksomheder er enige om er kritisk, og samtidig det, som de fleste opbevarer på infrastruktur, de ikke ejer, i en jurisdiktion, de ikke har valgt, under en kontrakt, de ikke har læst omhyggeligt. Som regel er den ordning helt fin. Alligevel er det værd at vide, hvad alternativet koster, for GitLab har i over ti år gjort det reelt praktisk at hoste hele udviklingsforløbet selv.

Det er også et produkt, hvis gratis niveau er mere gavmildt, og hvis driftsbyrde er tungere, end de fleste forventer. Begge dele bør man forstå, før man binder sig, så denne guide handler om, hvad selvhostet GitLab faktisk er, hvad gratisniveauet reelt giver, og de tre driftsproblemer, der står for størstedelen af smerten.

Hvad GitLab er

Ikke en Git-hosting med ekstraudstyr skruet på. En Rails-applikation, PostgreSQL, Redis, Gitaly til lagring af repositories, Sidekiq til baggrundsjobs og et containerregister, pakket sammen som ét system, der dækker versionsstyring, kodegennemgang, opgavesporing, CI/CD, pakke- og containerregistre, sikkerhedsscanning og udrulning.

Den bredde er hele argumentet. GitHub plus Actions plus Dependabot plus et pakkeregister plus et projektværktøj giver et sammenligneligt funktionssæt, samlet af dele. GitLab er én applikation med én rettighedsmodel og én database. Det er enten præcis, hvad du vil have, eller mere end du har brug for, og hvilken af delene afhænger af, hvor stor en del af forløbet du faktisk agter at køre samme sted.

Det arkitektonisk vigtige er det samme som ved at hoste sin analytics med Matomo, sin marketingautomatisering med Mautic eller sin teamchat med Mattermost: det kører der, hvor du sætter det. Dine repositories, dine CI-logs, dine artefakter, din database.

Licensbilledet, sagt lige ud

Det her forvirrer faktisk og fortjener præcision, for forvirringen går den modsatte vej af, hvad folk forventer.

Der findes to kildedistributioner. Community Edition er MIT-licenseret. Enterprise Edition har sin egen, mere restriktive licens, der dækker mappen ee/ i repositoriet. Så langt lyder det som den sædvanlige open core-model.

Det, der overrasker: den Linux-pakke, som næsten alle installerer, er Enterprise Edition-bygget, og uden en licensnøgle kører den som Free-niveau og opfører sig som Community Edition. Du kører altså ikke den MIT-licenserede distribution, medmindre du bevidst har valgt CE-pakken. I praksis betyder det sjældent noget, men hvis din grund til at selvhoste er en streng open source-politik snarere end datakontrol, betyder det rigtig meget, og næsten ingen tjekker det.

De kommercielle niveauer er Free, Premium til 29 dollars per bruger om måneden ved årlig betaling, og Ultimate til pris efter aftale. Premium tilføjer avanceret CI/CD, bedre projektstyring og prioriteret support. Ultimate tilføjer sikkerheds- og compliancepakken: applikationssikkerhedstest, forsyningskædesikkerhed, afhængighedsscanning. Begge betalte niveauer indeholder nu GitLab Credits til AI-funktionerne, 12 dollars per bruger om måneden på Premium og 24 på Ultimate.

Og her er det forhold, der ændrer regnestykket for de fleste teams, og den præcise modsætning til Mattermost-situationen: Free-niveauet i selvhostet drift har ingen brugergrænse. Loftet på fem brugere, som folk har hørt om, gælder kun private grupper på GitLab.com. Selvhostet giver Free dig ubegrænsede brugere, versionsstyring, CI/CD og registre, og du medbringer selv lager og runners. En organisation med hundrede ingeniører kan køre fuldt ud på det.

Det, du giver afkald på, er sikkerhedsscanning, compliancerapportering, avancerede godkendelsesregler og support. Er du omfattet af cyberrobusthedsforordningen og vil have afhængighedsscanning og SBOM-generering indbygget i dine pipelines frem for samlet fra separate værktøjer, er det en Ultimate-samtale. For de fleste andre teams er Free ikke en prøveperiode. Det er et holdbart permanent svar.

Opsætningen

En lille installation

GitLab er tungere, end det ser ud. Det dokumenterede udgangspunkt for en enkelt node er 8 vCPU og 16 GB RAM, og i modsætning til de fleste leverandørminimum er det tal ærligt frem for optimistisk. Det kan presses ned i 8 GB, men du vil mærke det, og swap bør være slået fra, for at lade denne applikation swappe er værre end ikke at have hukommelsen.

PostgreSQL er den eneste understøttede database. Hvilken version afhænger af din GitLab-version: 17.x vil have PostgreSQL 14.14 til 16.x, 18.x vil have 16.5 til 17.x, og 19.x vil have 17.x. Redis 7.2 anbefales med 7.0 som minimum, og Valkey 7.2 fungerer som erstatning. Kun selvstændige instanser, da klyngede og serverless varianter af Redis ikke understøttes.

Installer med Linux-pakken. Der findes Helm-charts, en Operator, Docker-images og en vej fra kildekode, men Linux-pakken er den mest modne mulighed, og det er den, GitLab.com selv kører på. Den medbringer PostgreSQL, Redis og Sidekiq, så én maskine og én konfigurationsfil giver 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'
}

Ét gitlab-ctl reconfigure senere har du en instans. Sæt external_url rigtigt første gang, for den værdi ender indbagt i klon-URL'er, webhooks og registeradresser.

En produktionsinstallation

GitLab udgiver referencearkitekturer fra 1.000 til 50.000 brugere, og de er værd at læse, selv hvis du aldrig implementerer nogen af dem, fordi de viser, hvilken komponent der først bliver flaskehalsen.

Det råd, der sparer flest penge, kommer fra GitLab selv og taler imod kompleksitet: under 3.000 brugere anbefaler de en solid backupstrategi frem for høj tilgængelighed. Dokumentationen er usædvanlig ærlig om det og bemærker, at en backup-tilgang ganske vist har en langsommere gendannelsestid, men betyder en langt mindre arkitektur og lavere vedligeholdelsesomkostninger. Over 3.000 brugere, eller hvor et nedbrud reelt standser virksomheden, bliver høj tilgængelighed anbefalingen.

Tag det alvorligt. En enkelt velsikret node med en testet gendannelse er i praksis mere pålidelig end en halvt forstået HA-klynge, og en hel del billigere.

Flyt artefakter, uploads, LFS-objekter og registerbilleder til objektlager fra begyndelsen. Samme ræsonnement som alle andre steder: det holder noden tilstandsløs, backups håndterbare og migreringen mulig.

De tre ting, der går galt

Alt ovenstående står i dokumentationen. Disse producerer hændelser.

Din backup indeholder ikke det, der dekrypterer den

Dette er det vigtigste afsnit i artiklen.

gitlab-backup create fanger en hel del: databasen, repositories, LFS-objekter, CI-artefakter og joblogs, registerbilleder, wikier, uploads, Pages-indhold, Terraform-tilstand, snippets. Det, den ikke fanger, er konfigurationsmappen, og navnlig /etc/gitlab/gitlab-secrets.json.

Denne fil indeholder databasens krypteringsnøgle. Dokumentationen er kontant omkring konsekvensen: mister du den, vil GitLab-applikationen ikke kunne dekryptere nogen krypterede værdier i databasen. Det vil sige CI/CD-variabler, tokens, tofaktorhemmeligheder og integrationsoplysninger. Du ville have en backup, der gendannes i en instans, som ikke kan læse sine egne hemmeligheder.

Også udeladt: /etc/gitlab/gitlab.rb, TLS-nøgler og certifikater, SSH-værtsnøgler, og indholdet af objektlageret, når objektlager er konfigureret. Det sidste rammer netop dem, der gjorde det arkitektonisk rigtige og derefter antog, at backuppen dækkede det.

Så tag backup af /etc/gitlab separat, opbevar den et andet sted end arkivet, eftersom den er nøglen til arkivet, og gendan derefter det hele på en engangsmaskine og bekræft, at du kan logge ind og læse en CI-variabel. En utestet backup er ikke en backup, og i GitLabs tilfælde er en utestet gendannelse som regel en ødelagt en.

Du kan ikke opgradere i ét spring

GitLab har obligatoriske opgraderingsstop, og det er ikke vejledende. Du kan ikke springe dem over. Siden 17.5 er stoppene forudsigelige og ligger på x.2, x.5, x.8 og x.11, så at gå fra 18.0 til 19.2 betyder at passere 18.2, 18.5, 18.8, 18.11 og 19.0.

Hvert stop indebærer baggrundsmigreringer, der skal være helt færdige, før du går videre. At starte den næste opgradering, mens migreringer stadig kører, er sådan instanser ender i tilstande, som kun support kan rede ud. På en stor instans kan de migreringer tage timer.

To praktiske konsekvenser. Opgrader regelmæssigt, for et års udskudte opgraderinger er en weekend med opgraderinger i træk. Og tag altid den nyeste patch-udgivelse af en mål-minorversion frem for den første, hvilket dokumentationen siger eksplicit. GitLab vedligeholder et værktøj, der beregner opgraderingsvejen for dig, og det er bedre at bruge det end at regne den ud selv.

De rigtige omkostninger ligger i runnerne

GitLab-serveren kører ikke din CI. GitLab Runner er en separat komponent, som du installerer, konfigurerer og betaler for, på infrastruktur du leverer. Selvhostet Free indeholder slet ingen beregningsminutter, fordi der ikke er inkluderet beregningskraft at give: du medbringer dine egne maskiner.

Det er som regel en god handel, for en dedikeret runner koster mindre per minut end hostet CI, så snart volumen bliver alvorlig, og du kan give hvert build den hardware, det har brug for. Men det er reelt infrastrukturarbejde. Du skal træffe valg om executors, om det er shell, Docker eller Kubernetes; om autoskalering, så runners ikke kører i tomgang klokken tre om natten; og om caching, som er forskellen på en pipeline på fire minutter og en på fjorten.

Budgettér runnerflåden som sin egen post. Teams, der modellerer omkostningen ved selvhosting ved kun at kigge på GitLab-noden, undervurderer den betydeligt og opdager derefter hullet som en kø af ventende jobs.

Væk fra GitHub

GitHub-importeren er god, betydeligt bedre end de fleste leverandørers migreringsværktøjer, og den bringer repositorydata, brancher, LFS-objekter, issues og pull requests med kommentarer, reviews og diskussionssvar, wikisider, releases og vedhæftninger, labels, milepæle, branch protection-regler og samarbejdspartnere med rollemapping med over.

De dokumenterede huller er værd at planlægge efter. Organisationer og grupper kommer ikke med, så gruppestrukturen skal du designe frem for at arve, hvilket som regel er en forbedring. GitHub Actions-workflows konverteres ikke til GitLab CI. Pull request-kommentarer fra før 2017 importeres som separate tråde på grund af begrænsninger i GitHubs API, og repositories med mere end omkring 30.000 kommentarer kræver, at den alternative kommentarimportmetode slås til.

Da GitHub bruger # til både issues og pull requests, mens GitLab skelner mellem dem, vil nogle krydshenvisninger ikke kunne slås op. Intet går tabt, men links i gamle diskussioner kan pege på det forkerte.

Planlæg CI-omskrivningen som selve projektet, for det er den. Alt andet er et importjob, du kan køre og kontrollere.

Den europæiske vinkel

For virksomheder i Europa lægger der sig en compliancedimension oven på prisen. Kildekode, buildpipelines og artefakter hører til det mest følsomme, en teknologivirksomhed besidder, og hvor de bor er i stigende grad et spørgsmål, du får stillet, snarere end et, du vælger at besvare.

Selvhosting placerer dem inden for en grænse, du kontrollerer, hvilket i ét greb forenkler overførselsanalysen under GDPR og forsyningskædespørgsmålene i NIS2, og det er samme suverænitetsargument, som Cloud and AI Development Act er bygget op omkring.

Den skarpeste forbindelse er cyberrobusthedsforordningen. Sender du software på EU-markedet, får du brug for afhængighedsfortegnelser, sårbarhedshåndtering og en koordineret oplysningsproces. De forpligtelser opfyldes i din buildpipeline og ikke i et dokument, og at have pipeline, register og scanning i ét system, du selv driver, gør det betydeligt mindre pinefuldt at fremskaffe dokumentationen end at samle den fra fire leverandører.

Hvornår du skal lade være

Er I under tyve ingeniører uden regulatorisk pres og uden stærke holdninger til, hvor koden bor, så tag SaaS-løsningen. GitLab.com og GitHub er begge fremragende, og driftsarbejdet vil koste mere end abonnementet.

Sidder din organisation dybt i GitHubs økosystem, så tæl ærligt sammen, hvad du ville miste. Actions, marketplace og platformens rene fortrolighed hos enhver kandidat, du ansætter, er reelle aktiver, og svaret er ikke automatisk, at GitLab vinder.

Og hvis ingen vil eje instansen, så lad være med at begynde. GitLab belønner en, der patcher den, holder øje med runnerflåden og tester gendannelsen. Uden den person forfalder det til en ulappet kasse med dit mest værdifulde aktiv i, hvilket er værre end den SaaS, du forsøgte at slippe væk fra.

Sådan kan vi hjælpe

Vi opsætter og driver selvhostet udviklingsinfrastruktur for virksomheder i Europa, inklusive de dele ingen bryder sig om: opgraderingsforløb gennem de obligatoriske stop, runnerflåder der autoskalerer ordentligt, migreringer til objektlager og backupmodeller, der faktisk er blevet gendannet.

Vil du have en ærligt dimensioneret GitLab-instans, en GitHub-migrering planlagt af nogen, der har lavet CI-omskrivningen før, eller et eftersyn af, om din nuværende backup ville overleve mødet med en rigtig fejl, så skriv til office@c9group.dev. Mere om vores infrastrukturarbejde på siden om AWS-omkostningsoptimering.

Sætter du en fuld selvhostet stak sammen, gælder samme ræsonnement for analytics, marketingautomatisering og teamkommunikation.

Udgivet: 8. august 2026 Kategorier: DevOps, Open Source, Privatliv