Software & Collaboration
GitLab
GitLab ist eine selbstgehostete DevOps-Plattform rund um Git: Repos, Issues, Merge Requests, CI/CD-Pipelines, Container Registry und Security-Scanning in einer App.
- DevOps-Plattform um Git
- Integrierte CI/CD-Pipelines
- Container- und Package-Registry
- SSO, Security-Scanning
- Self-managed, Datenhoheit
GitLab ist mehr als Git-Hosting: Es bündelt Repository-Verwaltung, Issues, Merge Requests mit Code-Review, CI/CD-Pipelines, Container- und Package-Registry, Wiki und Security-Scanning in einer einzigen Anwendung, der „single application“ für den ganzen DevOps-Lebenszyklus. Self-managed betrieben bleibt alles im eigenen Haus.
Dieser Artikel erklärt den Funktionsumfang und die Architektur, das Open-Core-Modell aus Community Edition und Enterprise-Tiers, die CI/CD über GitLab Runner, die Anmeldung über SSO, die Installations- und Backup-Eigenheiten sowie den Ressourcenbedarf und die Tier-Abhängigkeit der Sicherheitsfunktionen.
1. Eine Anwendung für die ganze Kette
GitLabs Anspruch ist die Integration: Statt Git-Hosting, CI-Server, Registry, Ticketsystem und Security-Tools getrennt zu betreiben, deckt eine Plattform alles ab, mit einheitlicher Zugriffskontrolle und durchgehenden Verknüpfungen von Issue über Merge Request bis zur Pipeline. Das senkt Reibung und Werkzeugbrüche, bringt aber einen entsprechend großen, vielteiligen Dienst mit sich.
2. Architektur
Unter der Oberfläche arbeiten viele Komponenten zusammen: der Applikationsserver Puma (Ruby on Rails), Gitaly als dedizierter Dienst für alle Git-Operationen, PostgreSQL für Metadaten, Redis für Cache und Queues, Sidekiq für Hintergrundjobs und Workhorse als vorgelagerter Proxy für große Uploads. Für Hochverfügbarkeit repliziert Praefect die Git-Daten über mehrere Gitaly-Knoten (Gitaly Cluster).
3. CI/CD über GitLab Runner
Die Pipelines beschreibt eine Datei .gitlab-ci.yml im Repository; ausgeführt werden die Jobs von separaten GitLab Runnern, die sich bei der Instanz registrieren. Als Ausführungsumgebung sind der Docker- und der Kubernetes-Executor die gängigen (isolierte Container je Job); die Shell-Ausführung befindet sich im Maintenance-Modus (Sicherheitsupdates, keine neuen Features).
Minimale .gitlab-ci.yml
stages: [build, test]
build-job:
stage: build
script:
- make build
test-job:
stage: test
script:
- make test4. Anmeldung und Verzeichnis
GitLab self-managed bindet sich an bestehende Identitäten an: LDAP/Active Directory, SAML (mit automatischer Kontoanlage) und OpenID Connect sind direkt konfigurierbar (jeweils eigene Artikel). Die Zwei-Faktor-Authentifizierung lässt sich instanzweit erzwingen. So fügt sich GitLab in eine vorhandene SSO-Landschaft ein.
5. Installation, Backup, Upgrade
Installiert wird GitLab meist über das Omnibus-Paket (alle Abhängigkeiten gebündelt), per Docker oder per Helm-Chart auf Kubernetes. Zwei Betriebsfallen sind wichtig: Erstens erfasst das eingebaute Backup die Konfiguration und die Secrets-Datei nicht (gitlab-secrets.json und gitlab.rb müssen separat gesichert werden, sonst sind verschlüsselte Datenbankfelder nach einem Restore unbrauchbar). Zweitens erlaubt GitLab keine beliebigen Versionssprünge: Bei größeren Upgrades sind bestimmte Zwischenversionen als Pflicht-Stopps einzuhalten.
Das GitLab-Backup ohne die separat gesicherte Secrets-Datei ist im Ernstfall wertlos. Wer das nicht weiß, hält ein Backup in der Hand, das verschlüsselte Daten nicht wiederherstellt.
6. Editionen und Sicherheitsfunktionen
GitLab ist open-core: Der Code außerhalb des ee/-Verzeichnisses steht unter der MIT-Lizenz (Community Edition), die wertvollen Enterprise-Funktionen sind proprietär und in den Stufen Free, Premium und Ultimate gestaffelt. Für Sicherheit heißt das konkret: Basis-Scans (SAST, Container-Scanning) gibt es bereits ab Free, die unternehmensrelevante Tiefe (Dependency Scanning, DAST, ein Vulnerability-Dashboard) liegt aber im teuersten Tier Ultimate. Diese Tier-Zuordnung verschiebt GitLab gelegentlich.
7. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Integrierte DevOps-Kette in einer Anwendung | ressourcenhungrig (viele Komponenten, viel RAM) |
| Self-managed, volle Datenhoheit; CE-Kern MIT | hoher Betriebsaufwand, anspruchsvolle Upgrades |
| LDAP/SAML/OIDC und 2FA out of the box | Backup erfasst Secrets-/Konfig-Datei nicht automatisch |
| Container-Scanning bereits ab Free | tiefe Security-Suite (DAST, Dependency-Scan) erst in Ultimate |
| Reife HA-Architektur (Gitaly Cluster) | für schlanke Anforderungen überdimensioniert |
Häufige Fragen zu GitLab
GitLab folgt einem Open-Core-Modell aus einer Codebasis. Der Code außerhalb des ee/-Verzeichnisses ist MIT-lizenziert und bildet die Community Edition; der ee/-Code ist proprietär und liefert die Enterprise-Funktionen in den Stufen Free, Premium und Ultimate. In der Praxis wird stets das EE-Artefakt ausgeliefert; wer ohne bezahlte Subscription betreibt, nutzt den Free-Tier. Viele unternehmensrelevante Sicherheitsfunktionen liegen erst in Ultimate.
Das eingebaute Backup sichert Datenbank, Repositories und Anhänge, aber nicht die Konfigurationsdatei und die Secrets-Datei (gitlab-secrets.json). Diese enthalten die Schlüssel für verschlüsselte Datenbankfelder und müssen separat gesichert werden, sonst lässt sich nach einem Restore ein Teil der Daten nicht entschlüsseln. Außerdem ist vor jedem Upgrade ein Backup Pflicht, und größere Versionssprünge erfordern definierte Zwischenstopps.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
GitLab im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.