Die meisten Teams landen am Ende dabei, ihren Quellcode in einer US-Cloud zu haben, ihre Container-Images in einer zweiten und ihre Benutzerkonten in einer dritten. Jede davon ist ein eigener Vertrag, ein eigener Ausfall und eine eigene Antwort auf die Frage „wer kann unseren Code lesen?“
Den gesamten Entwickler-Stack betreiben wir selbst, in der EU, und wir betreiben ihn als Dienstleistung. Versionsverwaltung, CI/CD, die Image-Registry und Single Sign-on kommen aus einer Hand - von Infrastruktur, die wir in Deutschland administrieren, nicht von weiterverkaufter Kapazität eines Hyperscalers.
Woraus der Stack besteht
- GitLab CE auf einem dedizierten Hetzner-VPS in Nürnberg, Debian 12, HTTPS mit Let's-Encrypt-Zertifikaten, die automatisch erneuert werden.
- Container-Registry, mit GitLab ausgeliefert, erreichbar auf Port 5050 desselben Hosts, mit Aufbewahrungsregeln, die deployte Images am Leben lassen und den Rest aufräumen.
- GitLab Runner mit dem Docker-Executor - jeder CI-Job läuft in seinem eigenen Container.
- Keycloak als Identity Provider, der Benutzer aus LDAP föderiert, mit OIDC-Clients für die einzelnen Anwendungen.
- Ausgehende Mail über unseren eigenen Mailserver, damit Pipeline-Benachrichtigungen und Merge-Request-E-Mails nicht über einen fremden Absender laufen.
Keine dieser Komponenten ist exotisch. Genau das ist der Punkt: Es ist Standard-Open-Source-Software, ordentlich betrieben, von Leuten, die das Telefon abnehmen.
Single Sign-on, das Ihre Organisation kennt
Interessant ist nicht, dass Keycloak existiert. Interessant ist, was der Login über die Person weiß, die sich anmeldet.
Die Benutzer leben in LDAP. Keycloak föderiert sie in einen Realm und mappt LDAP-Gruppen in OIDC-Group-Claims. GitLab übernimmt diese Claims über den Standard-Provider openid_connect mit PKCE, sodass die Gruppenmitgliedschaft über die Zugriffsstufe entscheidet - wer in der Admin-Gruppe ist, ist Administrator in GitLab, ohne dass jemand eine zweite Liste pflegen muss, wer wer ist.
Derselbe Realm stellt Tokens für alles andere aus, was Sie betreiben - Wiki, Dashboards, ERP, Monitoring. Der Eintritt eines Entwicklers schrumpft damit auf einen LDAP-Eintrag und eine Gruppenmitgliedschaft. Der Austritt schrumpft auf eine Löschung, und die schließt alle Türen gleichzeitig. Das ist das eigentliche Argument für SSO, und es gilt nur, wenn ein Betreiber sowohl das Verzeichnis als auch die Anwendungen betreibt.
An der Registry zeigt sich operative Disziplin
Eine Container-Registry läuft voll. Teams, die mehrmals täglich bauen, merken das auf die harte Art, meist genau dann, wenn ein Push im ungünstigsten Moment fehlschlägt. Die Registry hat deshalb eine Aufräumregel - und diese Regel hat eine Invariante, die wir nicht brechen: das Aufräumen darf niemals ein Image löschen, das gerade deployt ist.
In der Praxis heißt das: Die Aufbewahrungszahl muss jeden einzelnen Tag abdecken, der gleichzeitig läuft, nicht nur die neuesten paar. Bei einer einmal deployten Anwendung sind zehn bis zwanzig Tags reichlich. Bei einer Anwendung, die in zehn auseinanderlaufenden Instanzen läuft, muss die Zahl alle zehn plus Historie abdecken. Die robustere Variante markiert deployte Images mit einem geschützten Marker und behält sie unabhängig von der Zahl.
Ein verwandtes Detail, das Leute ein Wochenende kostet: Das Pull-Secret in Ihrem Cluster muss ein dauerhaftes Deploy-Token mit Nur-Lese-Rechten sein, nicht das flüchtige Token aus einem CI-Job. Das Job-Token verfällt mit dem Job, und der nächste frische Pull scheitert mit einem 401, der wie ein Registry-Ausfall aussieht und keiner ist.
Vom Commit in den Cluster
CI baut ein Image, taggt es mit dem unveränderlichen Commit-SHA und pusht es in die Registry. Die Deployment-Stage holt Helm-Chart und Values aus dem Infrastruktur-Repository und upgradet das Release. Anwendungs-Repositories tragen keine eigenen Kopien von Charts oder Manifesten.
Das ist eine bewusste Einschränkung. Git ist die Quelle der Wahrheit darüber, was läuft; in einem laufenden Produktionssystem wird nichts von Hand geändert. Wenn Cluster und Repository sich widersprechen, gewinnt beim nächsten Rollout das Repository - was nur eine sichere Regel ist, wenn in der Zwischenzeit niemand direkt an der Produktion herumgepatcht hat.
Für wen das ist
- Teams von fünf bis fünfzig Entwicklern, die Versionsverwaltung, CI und eine Registry brauchen und dafür nicht drei separate SaaS-Verträge verwalten wollen.
- Organisationen mit Anforderungen an EU-Datenhaltung - DSGVO, NIS2, DORA - wo die Frage „wo liegt unser Quellcode, und wer kann ihn gerichtlich anfordern?“ eine belegbare Antwort haben muss.
- Open-Source-orientierte Häuser, die schon Linux, Postgres und Keycloak betreiben und einen Anbieter wollen, der denselben Stack spricht.
- Unternehmen, die einen Hyperscaler-Devstack ersetzen und die Migration betrieben haben wollen, nicht nur beraten.
Was wir nicht vorgeben
Das beschriebene Deployment läuft auf einem einzelnen Knoten. Es ist für ein Team dimensioniert und überwacht, nicht für ein Unternehmen mit tausend Arbeitsplätzen, und einen hochverfügbaren GitLab-Cluster bieten wir derzeit nicht an. Wenn Ihre Recovery Time in Minuten statt in Stunden gemessen wird, sagen Sie es früh, und wir sagen Ihnen ehrlich, ob wir der richtige Partner sind.
Instanzen werden von außen überwacht: Uptime-Probes, Alerts auf ablaufende TLS-Zertifikate, Alerts auf Platte und Queue. Die Keycloak-Daten sichern wir in EU-Objektspeicher und prüfen jede Nacht, dass das Backup tatsächlich existiert; GitLab und die Registry laufen auf einer eigenen Maschine mit täglichen Block-Snapshots.
Wie Sie anfangen
Sagen Sie uns, wie viele Entwickler, was Sie heute betreiben und was während des Umzugs weiterlaufen muss. Wir kommen mit einem Migrationsplan und einem Angebot zurück - der Preis hängt von der Teamgröße ab und davon, wie viel des bestehenden Setups wir übernehmen.
Schreiben Sie an info@cybermindnet.eu oder nutzen Sie das Kontaktformular.