Training Module

GitLab & Container-Registry selbst hosten mit Docker

In diesem 3-Stunden-15-Minuten-Aufbaumodul baut ihr eine vollständige, selbstgehostete GitLab-CE-Instanz statt SaaS: einen Microservice-Stack aus Traefik, GitLab, externem PostgreSQL/Redis, CI/CD-Runner und Mailpit per compose.yaml, mit eigener Container-Registry unter registry.dev.local. Ihr legt den Admin-Account bewusst über die Rails-Konsole an (statt euch auf das automatische Root-Passwort zu verlassen), baut Personal Access Tokens statt Passwörtern in den Alltag ein und liefert den Beweis am eigenen Rechner: einmal, dass ein eigenes Image über die Registry gepusht, gelöscht und wieder gepullt exakt denselben Container liefert, einmal, dass ein vollständiges Backup samt gitlab-secrets.json ein komplett neu aufgesetztes System originalgetreu wiederherstellt. Die komplette Session – auch beide Hands-on-Übungen – läuft vollständig lokal auf eurem eigenen Rechner, ohne Cloud-Account und ohne Kostenwirkung.

Academy Briefing vereinbaren

Oder sofort per Mail an kontakt@codecraft.academy

Format

3 Stunden 15 Minuten, live (remote oder vor Ort), Input & zwei vollständige Hands-on-Blöcke

Teilnehmende

Absolvent:innen von “Docker Fortgeschritten” oder gleichwertige Vorkenntnisse in Docker Compose

Voraussetzungen

Sicherer Umgang mit compose.yaml (services/volumes/networks) und dem _FILE-Secrets-Pattern aus “Docker Fortgeschritten”, eine lauffähige Docker-Umgebung mit Docker Compose (6–8 GB RAM/4 CPU verfügbar) und Git-Grundkenntnisse. Keine Cloud-/AWS-Kostenwirkung – alles läuft lokal.

Warum dieses Training für deine Organisation wirkt

Eine echte Microservice-Architektur, keine Blackbox

Traefik, GitLab, PostgreSQL, Redis, Runner und Mailpit als eigenständige Compose-Services statt eines vorkonfigurierten All-in-one-Images – ihr versteht jedes Teil des Stacks und wie es geroutet, verbunden und initialisiert wird.

Registry und CI/CD im Alltag, nicht nur in der Theorie

Ein eigenes Image bauen, mit korrektem Namensschema in die selbstgehostete Registry pushen, löschen und zurückpullen, danach einen GitLab-Runner registrieren und eine echte, grüne Pipeline im Browser sehen – der komplette Weg vom Code bis zum laufenden Container.

Backup/Restore vor dem ersten Ernstfall geübt

gitlab-rake gitlab:backup:create reicht allein nicht – ohne separat gesicherte gitlab-secrets.json sind verschlüsselte CI/CD-Variablen nach einem Restore auf einem neuen System unbrauchbar. Ihr übt den vollständigen, korrekten Ablauf einmal echt durch, mit Datenintegritäts- Beweis am Ende.

Was Teilnehmende mitnehmen

Einen vollständigen GitLab-CE-Stack (Traefik, GitLab, externes PostgreSQL/Redis, Runner, Mailpit) per compose.yaml selbst aufsetzen und über Hostnamen wie gitlab.dev.local und registry.dev.local erreichen.
Verstehen, warum der Admin-Account bewusst über die Rails-Konsole angelegt wird: GitLabs Passwort-Policy blockiert das automatische Root-Passwort oft still, ohne sichtbare Fehlermeldung.
Personal Access Tokens mit den passenden Scopes (read_api, read_repository, write_repository, read_registry, write_registry) statt Passwort im Alltag verwenden.
Ein eigenes Image bauen, nach dem Schema registry.dev.local:5000/<user>/<projekt>/<image>:<tag> taggen, in die eigene Registry pushen, lokal löschen und wieder pullen – mit laufendem, erreichbarem Container als Beweis.
Einen GitLab Runner mit Docker-Executor registrieren und eine einfache .gitlab-ci.yml mit Build/Test-Stages als grüne Pipeline im Browser beobachten.
Ein vollständiges Backup/Restore-Verfahren durchführen, inklusive der kritischen, oft vergessenen gitlab-secrets.json, und per gitlab-rake gitlab:check SANITIZE=true sowie wiederhergestelltem Testprojekt und Container-Image die Datenintegrität nachweisen.

Für wen dieses Modul ideal ist

• Docker-erfahrene Admins/Entwickler:innen, die eine selbstgehostete GitLab-CE-Instanz statt SaaS betreiben wollen
• Absolvent:innen von “Docker Fortgeschritten” oder Entwickler:innen mit gleichwertigen Compose-, Volume- und Netzwerk-Vorkenntnissen
• Teams, die vor dem ersten produktiven GitLab-Betrieb ein verlässliches Backup/Restore-Verfahren einmal komplett durchgespielt haben wollen

Rahmendaten

• Dauer: 3 Stunden 15 Minuten live (remote oder vor Ort)
• Format: Input, Live-Demo, zwei vollständige Hands-on-Blöcke
• Voraussetzungen: abgeschlossenes Modul “Docker Fortgeschritten” oder gleichwertige Compose-/Volume-/Netzwerk-Vorkenntnisse; “Git Versionskontrolle” für Git-Basics empfohlen, aber keine Pflicht; lauffähige Docker-Umgebung mit 6–8 GB RAM/4 CPU; keine Cloud-Kostenwirkung

Modulaufbau & Agenda

Vorbereitung & Architekturüberblick (15 min): Docker-Desktop-Ressourcen (6–8 GB RAM/4 CPU), insecure-registries konfigurieren, Traefik/GitLab/PostgreSQL/Redis/Runner/Mailpit als Microservice-Architektur im Überblick.
Hosts-Datei einrichten (15 min): gitlab.dev.local, registry.dev.local, mailpit.dev.local auf 127.0.0.1 eintragen.
compose.yaml-Walkthrough (30 min): vollständiger Stack mit Ports 80/8080 (Traefik), 5000+2222 (GitLab Registry/SSH), externe PostgreSQL 17 + Redis 7, SMTP via Mailpit, registry_external_url, Traefik-Labels für das Routing.
Start/Init + Erstlogin (30 min): docker compose up -d, Migrationen abwarten, Admin-Account über die Rails-Konsole anlegen, öffentliche Registrierung deaktivieren, SSH-Key hinterlegen, Testprojekt klonen/pushen/löschen/restore als Datenintegritäts-Beweis.
Personal Access Tokens (15 min): Scopes read_api/read_repository/write_repository/read_registry/write_registry statt Passwort im Alltag.
Hands-on 1: Registry Push/Pull (30 min): eigenes Image bauen, nach Schema taggen, docker login, pushen, lokal löschen, aus der Registry pullen und starten, Cleanup-Policy einrichten (keep 5 / älter als 14 Tage löschen).
CI/CD: Runner registrieren (15 min): GitLab Runner mit Docker-Executor (–docker-privileged) registrieren, danach eine einfache .gitlab-ci.yml mit Build/Test-Stages pushen und die grüne Pipeline im Browser beobachten.
Hands-on 2: Backup/Restore (30 min): gitlab-rake gitlab:backup:create, gitlab-secrets.json und gitlab.rb separat sichern, Restore-Ablauf mit Stop/chown/Restore/Reconfigure, Beweis per wiederhergestelltem Testprojekt und Container-Image.
Aufräumen (10 min): docker compose down -v, Testordner löschen, docker system prune -a –volumes.
Abschluss/Q&A (5 min): offene Fragen, Einordnung in die weiteren Docker- und Kubernetes-Aufbaumodule.

Hands-on Inhalte (Auszug)

Hands-on 1: Registry Push/Pull

Eigenes Image (schlankes, nicht-root-laufendes Nginx-Basisimage + eigene index.html) bauen und nach Schema registry.dev.local:5000/<user>/<projekt>/<image>:<tag> taggen
docker login localhost:5000, pushen, lokales Image löschen
Aus der Registry pullen und starten – Beweis: Container läuft, Webseite erreichbar, plus Cleanup-Policy (keep 5 / älter als 14 Tage)

Hands-on 2: Backup/Restore

gitlab-rake gitlab:backup:create plus separat gesicherte gitlab-secrets.json und gitlab.rb
Restore-Ablauf: Puma/Sidekiq stoppen, chown auf git:git, gitlab-rake gitlab:backup:restore, gitlab-ctl reconfigure && gitlab-ctl start
gitlab-rake gitlab:check SANITIZE=true – Beweis: Testprojekt und Container-Image nach Restore wieder vorhanden

Architektur & Erstlogin

Traefik/GitLab/PostgreSQL/Redis/Runner/Mailpit als eigenständige Compose-Services mit Traefik-Labels für gitlab.dev.local und registry.dev.local
Admin-Account bewusst über die Rails-Konsole anlegen, da GitLabs Passwort-Policy das automatische Root-Passwort oft still blockiert
Personal Access Tokens mit passenden Scopes statt Passwort im Alltag

CI/CD: Runner registrieren

GitLab Runner mit Docker-Executor (–docker-privileged) über einen Token aus der GitLab-UI registrieren
Einfache .gitlab-ci.yml mit Build/Test-Stages pushen
Grüne Pipeline live im Browser beobachten

Dieses Modul ist Teil unserer Pilotphase. Gemeinsam mit euch definieren wir passende Metriken (z. B. Zeit bis zur grünen Pipeline, Ergebnis der beiden Hands-on-Übungen) und werten sie im Anschluss transparent aus. Ergebnisse veröffentlichen wir, sobald sie belastbar sind.

Explizit nicht Teil dieses Kurses

• Kubernetes-Deployment von GitLab und Cluster-Betrieb – vertieft im Aufbaumodul GitLab auf Kubernetes betreiben — Helm-Deployment, Backup/Restore & Runner-Skalierung.
• Monitoring und Log-Aggregation des Stacks – Thema von Docker Betrieb.
• Verteilung über mehrere Nodes – Thema von Docker Swarm Hands-on.
• Bitbucket-Pipelines im Vergleich bleibt ein eigenständiges Thema – siehe Bitbucket Pipeline Grundwissen.
• Vertiefte CI/CD-Build-Theorie jenseits der hier geübten Runner-Kopplung – Thema von CI: Continuous Integration & der Build-Prozess.
• Security-Hardening und Image-Scanning der Registry – Thema von Docker Sicherheit & Orchestrierung mit Swarm.

Bereit, das Modul zu buchen?

Wir passen die Hands-on-Übungen auf euren Erfahrungsstand und eure Zielumgebung an.

Academy Briefing anfragen