[{"data":1,"prerenderedAt":815},["ShallowReactive",2],{"/de-de/blog/using-gitlab-container-virtual-registry-with-docker-hardened-images":3,"navigation-de-de":39,"banner-de-de":453,"footer-de-de":463,"blog-post-authors-de-de-Tim Rizzi":699,"blog-related-posts-de-de-using-gitlab-container-virtual-registry-with-docker-hardened-images":713,"blog-promotions-de-de":753,"next-steps-de-de":805},{"id":4,"title":5,"authorSlugs":6,"authors":8,"body":10,"category":11,"categorySlug":11,"config":12,"content":16,"date":20,"description":17,"extension":25,"externalUrl":26,"featured":13,"heroImage":19,"isFeatured":13,"meta":27,"navigation":28,"path":29,"publishedDate":20,"rawbody":30,"seo":31,"slug":15,"stem":35,"tagSlugs":36,"tags":37,"template":14,"updatedDate":26,"__hash__":38},"blogPosts/de-de/blog/using-gitlab-container-virtual-registry-with-docker-hardened-images.yml","GitLab Container Virtual Registry mit Docker Hardened Images einrichten",[7],"tim-rizzi",[9],"Tim Rizzi","Wer im Plattformteam arbeitet, kennt solche Gespräche:\n\n*„Security sagt: Wir müssen gehärtete Base-Images verwenden.\"*\n\n*„Prima – wo trage ich jetzt die Credentials für noch eine weitere Registry ein?\"*\n\n*„Und wie stellen wir sicher, dass alle sie auch wirklich nutzen?\"*\n\nOder diese hier:\n\n*„Warum sind unsere Builds so langsam?\"*\n\n*„Wir pullen dasselbe 500-MB-Image in jedem einzelnen Job neu von Docker Hub.\"*\n\n*„Kann man die nicht irgendwo cachen?\"*\n\nIch arbeite bei GitLab an der [Container Virtual Registry](https://docs.gitlab.com/user/packages/virtual_registry/container/) – einem Pull-Through-Cache, der vor den vorgelagerten Registries sitzt: Docker Hub, dhi.io (Docker Hardened Images), MCR und Quay. Teams erhalten einen einzigen Endpunkt zum Pullen. Images werden beim ersten Abruf gecacht; alle nachfolgenden Pulls kommen aus dem Cache. Das Entwicklungsteam muss nicht wissen, aus welchem Upstream ein bestimmtes Image stammt.\n\nDieser Artikel zeigt die Einrichtung der Container Virtual Registry – mit Docker Hardened Images als konkretem Anwendungsfall, da diese Kombination für Teams mit Sicherheitsanforderungen besonders naheliegt.\n\n## Das Problem: Registry-Wildwuchs im Plattformteam\n\nDie Plattformteams, mit denen ich spreche, verwalten Container-Images über drei bis fünf Registries:\n\n- **Docker Hub** für die meisten Base-Images\n- **dhi.io** für Docker Hardened Images (sicherheitskritische Workloads)\n- **MCR** für .NET- und Azure-Tooling\n- **Quay.io** für das Red-Hat-Ökosystem\n- **Interne Registries** für proprietäre Images\n\nJede davon hat eigene Authentifizierungsmechanismen, unterschiedliche Netzwerklatenz und eine eigene Pfadstruktur für Images.\n\nCI/CD-Konfigurationen füllen sich mit registry-spezifischer Logik. Credential-Management wird zum eigenständigen Projekt. Und jeder Pipeline-Job lädt dieselben Base-Images erneut über das Netz – obwohl sie sich seit Wochen nicht geändert haben.\n\nContainer Virtual Registry konsolidiert das: eine Registry-URL, ein Authentifizierungsfluss über GitLab, gecachte Images aus GitLab-Infrastruktur statt wiederholter Internet-Traversierung.\n\n## Funktionsweise\n\nDas Modell ist geradlinig:\n\n```text\n\nPipeline ruft ab:\n gitlab.com/virtual_registries/container/1000016/python:3.13\n\nVirtual Registry prüft:\n 1. Im Cache vorhanden? → Direkt zurückgeben\n 2. Nein? → Vom Upstream laden, cachen, zurückgeben\n\n\n```\n\nUpstreams werden in Prioritätsreihenfolge konfiguriert. Bei einem eingehenden Pull-Request durchsucht die Virtual Registry die Upstreams der Reihe nach, bis das Image gefunden wird. Das Ergebnis wird für einen konfigurierbaren Zeitraum gecacht – standardmäßig 24 Stunden.\n\n\n```text\n\n┌─────────────────────────────────────────────────────────┐ │ CI/CD Pipeline │ │ │ │ │ ▼ │ │ gitlab.com/virtual_registries/container/\u003Cid>/image │ └─────────────────────────────────────────────────────────┘\n │\n ▼\n┌─────────────────────────────────────────────────────────┐ │ Container Virtual Registry │ │ │ │ Upstream 1: Docker Hub ────────────────┐ │ │ Upstream 2: dhi.io (Hardened) ────────┐│ │ │ Upstream 3: MCR ─────────────────────┐││ │ │ Upstream 4: Quay.io ────────────────┐│││ │ │ ││││ │ │ ┌─────────────────┴┴┴┴──┐ │ │ │ Cache │ │ │ │ (manifests + layers) │ │ │ └───────────────────────┘ │ └─────────────────────────────────────────────────────────┘\n\n```\n\n## Was das konkret bringt – besonders mit Docker Hardened Images\n\n[Docker Hardened Images](https://docs.docker.com/dhi/) zeichnen sich durch minimale Angriffsfläche, nahezu keine bekannten CVEs, vollständige Software Bills of Materials (SBOMs) und SLSA-Provenance aus. Für Teams, die Base-Images für sicherheitskritische Workloads evaluieren, gehören sie auf die Shortlist.\n\nDer Wechsel zu dhi.io erzeugt jedoch dieselbe operative Reibung wie jede neue Registry:\n\n- **Credential-Verteilung**: Docker-Credentials müssen auf alle Systeme verteilt werden, die Images von dhi.io abrufen.\n- **CI/CD-Anpassungen**: Jede Pipeline muss für die Authentifizierung mit dhi.io aktualisiert werden.\n- **Akzeptanzproblem**: Ohne zentrale Steuerung greifen Teams weiterhin auf reguläre Images zurück.\n- **Fehlende Transparenz**: Ob Teams tatsächlich die gehärteten Varianten nutzen, ist kaum nachvollziehbar.\n\nDie Virtual Registry löst jeden dieser Punkte:\n\n**Einzelne Credential**: Teams authentifizieren sich bei GitLab. Die Virtual Registry übernimmt die Upstream-Authentifizierung. Docker-Credentials werden einmalig auf Registry-Ebene konfiguriert und gelten für alle Pulls.\n\n**Keine per-Team-CI/CD-Änderungen**: Pipelines auf die Virtual Registry zeigen lassen – fertig. Die Upstream-Konfiguration ist zentralisiert.\n\n**Schrittweise Einführung**: Da Images mit ihrem vollständigen Pfad gecacht werden, ist im Cache sichtbar, was tatsächlich abgerufen wird. Wird `library/python:3.11` statt der gehärteten Variante gepullt, ist das erkennbar.\n\n**Audit-Trail**: Der Cache zeigt exakt, welche Images aktiv genutzt werden – nachvollziehbar für Compliance-Zwecke und als Grundlage für das Verständnis der tatsächlichen Infrastruktur-Abhängigkeiten.\n\nWer das Konzept verstanden hat und die Einrichtung zu einem späteren Zeitpunkt in Angriff nimmt: Die wesentlichen Konzepte sind damit abgedeckt. Die technische Konfiguration folgt im nächsten Abschnitt.\n\n## Einrichtung\n\nDie folgende Einrichtung nutzt den Python-Client aus dem Demo-Projekt.\n\n### Virtual Registry erstellen\n\n```python\nfrom virtual_registry_client import VirtualRegistryClient\nclient = VirtualRegistryClient()\nregistry = client.create_virtual_registry(\n group_id=\"785414\", # ID der obersten Gruppe\n name=\"platform-images\",\n description=\"Cached container images for platform teams\"\n)\nprint(f\"Registry ID: {registry['id']}\") # Diese ID wird für die Pull-URL benötigt\n```\n\n### Docker Hub als Upstream hinzufügen\n\nFür offizielle Images wie Alpine, Python usw.:\n\n```python\n\ndocker_upstream = client.create_upstream(\n registry_id=registry['id'],\n url=\"https://registry-1.docker.io\",\n name=\"Docker Hub\",\n cache_validity_hours=24\n)\n\n```\n\n### Docker Hardened Images (dhi.io) hinzufügen\n\nDocker Hardened Images werden auf `dhi.io` gehostet – einer separaten Registry mit Authentifizierungspflicht:\n\n```python\n\ndhi_upstream = client.create_upstream(\n registry_id=registry['id'],\n url=\"https://dhi.io\",\n name=\"Docker Hardened Images\",\n username=\"your-docker-username\",\n password=\"your-docker-access-token\",\n cache_validity_hours=24\n)\n\n```\n\n### Weitere Upstreams hinzufügen\n\n```python\n\n# MCR für .NET-Teams client.create_upstream(\n registry_id=registry['id'],\n url=\"https://mcr.microsoft.com\",\n name=\"Microsoft Container Registry\",\n cache_validity_hours=48\n)\n# Quay für das Red-Hat-Ökosystem client.create_upstream(\n registry_id=registry['id'],\n url=\"https://quay.io\",\n name=\"Quay.io\",\n cache_validity_hours=24\n)\n\n```\n\n### CI/CD aktualisieren\n\nEine `.gitlab-ci.yml`, die über die Virtual Registry pullt:\n\n```yaml\n\nvariables:\n VIRTUAL_REGISTRY_ID: \u003Cyour_virtual_registry_ID>\n\n \nbuild:\n image: docker:24\n services:\n - docker:24-dind\n before_script:\n # Authentifizierung bei GitLab – Upstream-Auth wird übernommen\n - echo \"${CI_JOB_TOKEN}\" | docker login -u gitlab-ci-token --password-stdin gitlab.com\n script:\n # Alle Pulls laufen über die zentrale Virtual Registry\n \n # Offizielle Docker Hub Images (library/-Präfix erforderlich)\n - docker pull gitlab.com/virtual_registries/container/${VIRTUAL_REGISTRY_ID}/library/alpine:latest\n \n # Docker Hardened Images von dhi.io (kein Präfix nötig)\n - docker pull gitlab.com/virtual_registries/container/${VIRTUAL_REGISTRY_ID}/python:3.13\n \n # .NET von MCR\n - docker pull gitlab.com/virtual_registries/container/${VIRTUAL_REGISTRY_ID}/dotnet/sdk:8.0\n\n\n```\n\n### Image-Pfadformate\n\nVerschiedene Registries verwenden unterschiedliche Pfadkonventionen:\n\n| Registry | Beispiel-Pull-URL |\n|----------|-------------------|\n| Docker Hub (offiziell) | `.../library/python:3.11-slim` |\n| Docker Hardened Images (dhi.io) | `.../python:3.13` |\n| MCR | `.../dotnet/sdk:8.0` |\n| Quay.io | `.../prometheus/prometheus:latest` |\n\n### Funktionsprüfung\n\nNach einigen Pulls lässt sich der Cache überprüfen:\n\n```python\n\nupstreams = client.list_registry_upstreams(registry['id']) for upstream in upstreams:\n entries = client.list_cache_entries(upstream['id'])\n print(f\"{upstream['name']}: {len(entries)} cached entries\")\n\n\n```\n\n## Messergebnisse\n\nTestergebnisse beim Pullen über die Virtual Registry:\n\n| Messgröße | Ohne Cache | Mit warmem Cache |\n|-----------|------------|-----------------|\n| Pull-Zeit (Alpine) | 10,3 s | 4,2 s |\n| Pull-Zeit (Python 3.13 DHI) | 11,6 s | ~4 s |\n| Netzwerk-Roundtrips zum Upstream | Jeder Pull | Nur Cache-Misses |\n\nDer erste Pull hat dieselbe Dauer – das Image muss vom Upstream geladen werden. Jeder weitere Pull innerhalb der Cache-Gültigkeitsdauer kommt direkt aus GitLab-Storage: kein Netzwerk-Hop zu Docker Hub, dhi.io, MCR oder einer anderen Registry.\n\nBei Teams mit vielen Pipeline-Jobs pro Tag summiert sich das zu einem messbaren Gewinn bei den Build-Laufzeiten.\n\n## Praktische Hinweise\n\n### Cache-Gültigkeit\n\nDer Standard sind 24 Stunden. Für sicherheitskritische Images, bei denen Patches schnell verfügbar sein sollen, empfiehlt sich ein kürzeres Intervall:\n\n```python\n\nclient.create_upstream(\n registry_id=registry['id'],\n url=\"https://dhi.io\",\n name=\"Docker Hardened Images\",\n username=\"your-username\",\n password=\"your-token\",\n cache_validity_hours=12\n)\n\n```\n\nFür stabile Images mit fixen Versions-Tags ist ein längeres Intervall problemlos.\n\n### Upstream-Priorität\n\nUpstreams werden der Reihe nach geprüft. Bei gleichnamigen Images in verschiedenen Registries gewinnt der erste passende Upstream.\n\n### Limits\n\n- Maximal 20 Virtual Registries pro Gruppe\n- Maximal 20 Upstreams pro Virtual Registry\n\n## Konfiguration über die Oberfläche\n\nVirtual Registries und Upstreams lassen sich auch direkt in der GitLab-Oberfläche einrichten – ohne API-Aufrufe. Unter **Einstellungen > Pakete und Registries > Virtual Registry** der jeweiligen Gruppe stehen folgende Optionen zur Verfügung:\n\n- Virtual Registries erstellen und verwalten\n- Upstreams hinzufügen, bearbeiten und neu anordnen\n- Cache anzeigen und verwalten\n- Überblick, welche Images abgerufen werden\n\n## Ausblick\n\nIn Entwicklung:\n\n- **Allow/Deny-Listen**: Regex-basierte Steuerung, welche Images aus welchen Upstreams abgerufen werden dürfen.\n\nContainer Virtual Registry befindet sich in der Beta-Phase. Die Funktion wird produktiv eingesetzt und wird weiterentwickelt – Feedback fließt direkt in die Priorisierung ein.\n\n## Feedback\n\nWer als Plattformteam mit Registry-Wildwuchs zu kämpfen hat: Ich möchte verstehen, wie die aktuelle Situation aussieht.\n\n- Wie viele Upstream-Registries werden verwaltet?\n- Wo liegt der größte Schmerzpunkt?\n- Würde ein solcher Ansatz helfen – und falls nicht: Was fehlt?\n\nErfahrungen und Rückmeldungen gerne im [Container Virtual Registry Feedback-Issue](https://gitlab.com/gitlab-org/gitlab/-/work_items/589630) teilen.\n\n## Weiterführende Ressourcen\n\n- [Neue GitLab-Metriken und Registry-Funktionen zur Optimierung von CI/CD-Pipelines](https://about.gitlab.com/de-de/blog/new-gitlab-metrics-and-registry-features-help-reduce-ci-cd-bottlenecks/)\n- [Container Virtual Registry – Dokumentation](https://docs.gitlab.com/user/packages/virtual_registry/container/)\n- [Container Virtual Registry – API](https://docs.gitlab.com/api/container_virtual_registries/)\n\n## Für deutsche Unternehmen könnte dies folgende Themen betreffen\n\nTeams, die sicherheitsgehärtete Base-Images mit vollständigen SBOMs und SLSA-Provenance einsetzen, haben möglicherweise auch Compliance-Überlegungen – beispielsweise in Bereichen wie Sicherheit der Software-Lieferkette, Nachvollziehbarkeit von Image-Abhängigkeiten und zentralem Audit-Trail.\n\nRegulatorische Frameworks wie NIS2 und der Cyber Resilience Act adressieren ähnliche Themen rund um Software-Lieferketten und SBOM-Transparenz. Für konkrete Compliance-Anforderungen empfiehlt sich Rücksprache mit entsprechender Fachberatung.","engineering",{"featured":13,"template":14,"slug":15},false,"BlogPost","using-gitlab-container-virtual-registry-with-docker-hardened-images",{"title":5,"description":17,"authors":18,"heroImage":19,"date":20,"body":10,"category":11,"tags":21},"Mehrere Registries hinter einem Endpunkt – GitLab Container Virtual Registry mit Docker Hardened Images, Caching und Audit-Trail.",[9],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772111172/mwhgbjawn62kymfwrhle.png","2026-03-12",[22,23,24],"tutorial","product","features","yml",null,{},true,"/de-de/blog/using-gitlab-container-virtual-registry-with-docker-hardened-images","seo:\n config:\n noIndex: false\n title: Container Virtual Registry mit Docker Hardened Images\n description: 'Mehrere Container-Registries zu einem Endpunkt konsolidieren: GitLab Container Virtual Registry mit Docker Hardened Images, Caching und Audit-Trail.'\ncontent:\n title: GitLab Container Virtual Registry mit Docker Hardened Images einrichten\n description: 'Mehrere Registries hinter einem Endpunkt – GitLab Container Virtual Registry mit Docker Hardened Images, Caching und Audit-Trail.'\n authors:\n - Tim Rizzi\n heroImage: https://res.cloudinary.com/about-gitlab-com/image/upload/v1772111172/mwhgbjawn62kymfwrhle.png\n date: '2026-03-12'\n body: >-\n Wer im Plattformteam arbeitet, kennt solche Gespräche:\n\n\n *„Security sagt: Wir müssen gehärtete Base-Images verwenden.\"*\n\n\n *„Prima – wo trage ich jetzt die Credentials für noch eine weitere Registry ein?\"*\n\n\n *„Und wie stellen wir sicher, dass alle sie auch wirklich nutzen?\"*\n\n\n Oder diese hier:\n\n\n *„Warum sind unsere Builds so langsam?\"*\n\n\n *„Wir pullen dasselbe 500-MB-Image in jedem einzelnen Job neu von Docker Hub.\"*\n\n\n *„Kann man die nicht irgendwo cachen?\"*\n\n\n Ich arbeite bei GitLab an der [Container Virtual Registry](https://docs.gitlab.com/user/packages/virtual_registry/container/) – einem Pull-Through-Cache, der vor den vorgelagerten Registries sitzt: Docker Hub, dhi.io (Docker Hardened Images), MCR und Quay. Teams erhalten einen einzigen Endpunkt zum Pullen. Images werden beim ersten Abruf gecacht; alle nachfolgenden Pulls kommen aus dem Cache. Das Entwicklungsteam muss nicht wissen, aus welchem Upstream ein bestimmtes Image stammt.\n\n\n Dieser Artikel zeigt die Einrichtung der Container Virtual Registry – mit Docker Hardened Images als konkretem Anwendungsfall, da diese Kombination für Teams mit Sicherheitsanforderungen besonders naheliegt.\n\n\n ## Das Problem: Registry-Wildwuchs im Plattformteam\n\n\n Die Plattformteams, mit denen ich spreche, verwalten Container-Images über drei bis fünf Registries:\n\n\n - **Docker Hub** für die meisten Base-Images\n\n - **dhi.io** für Docker Hardened Images (sicherheitskritische Workloads)\n\n - **MCR** für .NET- und Azure-Tooling\n\n - **Quay.io** für das Red-Hat-Ökosystem\n\n - **Interne Registries** für proprietäre Images\n\n\n Jede davon hat eigene Authentifizierungsmechanismen, unterschiedliche Netzwerklatenz und eine eigene Pfadstruktur für Images.\n\n\n CI/CD-Konfigurationen füllen sich mit registry-spezifischer Logik. Credential-Management wird zum eigenständigen Projekt. Und jeder Pipeline-Job lädt dieselben Base-Images erneut über das Netz – obwohl sie sich seit Wochen nicht geändert haben.\n\n\n Container Virtual Registry konsolidiert das: eine Registry-URL, ein Authentifizierungsfluss über GitLab, gecachte Images aus GitLab-Infrastruktur statt wiederholter Internet-Traversierung.\n\n\n ## Funktionsweise\n\n\n Das Modell ist geradlinig:\n\n\n ```text\n\n\n Pipeline ruft ab:\n gitlab.com/virtual_registries/container/1000016/python:3.13\n\n Virtual Registry prüft:\n 1. Im Cache vorhanden? → Direkt zurückgeben\n 2. Nein? → Vom Upstream laden, cachen, zurückgeben\n\n\n ```\n\n\n Upstreams werden in Prioritätsreihenfolge konfiguriert. Bei einem eingehenden Pull-Request durchsucht die Virtual Registry die Upstreams der Reihe nach, bis das Image gefunden wird. Das Ergebnis wird für einen konfigurierbaren Zeitraum gecacht – standardmäßig 24 Stunden.\n\n\n\n ```text\n\n\n ┌─────────────────────────────────────────────────────────┐\n │ CI/CD Pipeline │\n │ │ │\n │ ▼ │\n │ gitlab.com/virtual_registries/container/\u003Cid>/image │\n └─────────────────────────────────────────────────────────┘\n │\n ▼\n ┌─────────────────────────────────────────────────────────┐\n │ Container Virtual Registry │\n │ │\n │ Upstream 1: Docker Hub ────────────────┐ │\n │ Upstream 2: dhi.io (Hardened) ────────┐│ │\n │ Upstream 3: MCR ─────────────────────┐││ │\n │ Upstream 4: Quay.io ────────────────┐│││ │\n │ ││││ │\n │ ┌─────────────────┴┴┴┴──┐ │\n │ │ Cache │ │\n │ │ (manifests + layers) │ │\n │ └───────────────────────┘ │\n └─────────────────────────────────────────────────────────┘\n\n\n ```\n\n\n ## Was das konkret bringt – besonders mit Docker Hardened Images\n\n\n [Docker Hardened Images](https://docs.docker.com/dhi/) zeichnen sich durch minimale Angriffsfläche, nahezu keine bekannten CVEs, vollständige Software Bills of Materials (SBOMs) und SLSA-Provenance aus. Für Teams, die Base-Images für sicherheitskritische Workloads evaluieren, gehören sie auf die Shortlist.\n\n\n Der Wechsel zu dhi.io erzeugt jedoch dieselbe operative Reibung wie jede neue Registry:\n\n\n - **Credential-Verteilung**: Docker-Credentials müssen auf alle Systeme verteilt werden, die Images von dhi.io abrufen.\n\n - **CI/CD-Anpassungen**: Jede Pipeline muss für die Authentifizierung mit dhi.io aktualisiert werden.\n\n - **Akzeptanzproblem**: Ohne zentrale Steuerung greifen Teams weiterhin auf reguläre Images zurück.\n\n - **Fehlende Transparenz**: Ob Teams tatsächlich die gehärteten Varianten nutzen, ist kaum nachvollziehbar.\n\n\n Die Virtual Registry löst jeden dieser Punkte:\n\n\n **Einzelne Credential**: Teams authentifizieren sich bei GitLab. Die Virtual Registry übernimmt die Upstream-Authentifizierung. Docker-Credentials werden einmalig auf Registry-Ebene konfiguriert und gelten für alle Pulls.\n\n\n **Keine per-Team-CI/CD-Änderungen**: Pipelines auf die Virtual Registry zeigen lassen – fertig. Die Upstream-Konfiguration ist zentralisiert.\n\n\n **Schrittweise Einführung**: Da Images mit ihrem vollständigen Pfad gecacht werden, ist im Cache sichtbar, was tatsächlich abgerufen wird. Wird `library/python:3.11` statt der gehärteten Variante gepullt, ist das erkennbar.\n\n\n **Audit-Trail**: Der Cache zeigt exakt, welche Images aktiv genutzt werden – nachvollziehbar für Compliance-Zwecke und als Grundlage für das Verständnis der tatsächlichen Infrastruktur-Abhängigkeiten.\n\n\n Wer das Konzept verstanden hat und die Einrichtung zu einem späteren Zeitpunkt in Angriff nimmt: Die wesentlichen Konzepte sind damit abgedeckt. Die technische Konfiguration folgt im nächsten Abschnitt.\n\n\n ## Einrichtung\n\n\n Die folgende Einrichtung nutzt den Python-Client aus dem Demo-Projekt.\n\n\n ### Virtual Registry erstellen\n\n\n ```python\n\n from virtual_registry_client import VirtualRegistryClient\n\n client = VirtualRegistryClient()\n\n registry = client.create_virtual_registry(\n group_id=\"785414\", # ID der obersten Gruppe\n name=\"platform-images\",\n description=\"Cached container images for platform teams\"\n )\n\n print(f\"Registry ID: {registry['id']}\")\n # Diese ID wird für die Pull-URL benötigt\n\n ```\n\n\n ### Docker Hub als Upstream hinzufügen\n\n\n Für offizielle Images wie Alpine, Python usw.:\n\n\n ```python\n\n\n docker_upstream = client.create_upstream(\n registry_id=registry['id'],\n url=\"https://registry-1.docker.io\",\n name=\"Docker Hub\",\n cache_validity_hours=24\n )\n\n\n ```\n\n\n ### Docker Hardened Images (dhi.io) hinzufügen\n\n\n Docker Hardened Images werden auf `dhi.io` gehostet – einer separaten Registry mit Authentifizierungspflicht:\n\n\n ```python\n\n\n dhi_upstream = client.create_upstream(\n registry_id=registry['id'],\n url=\"https://dhi.io\",\n name=\"Docker Hardened Images\",\n username=\"your-docker-username\",\n password=\"your-docker-access-token\",\n cache_validity_hours=24\n )\n\n\n ```\n\n\n ### Weitere Upstreams hinzufügen\n\n\n ```python\n\n\n # MCR für .NET-Teams\n client.create_upstream(\n registry_id=registry['id'],\n url=\"https://mcr.microsoft.com\",\n name=\"Microsoft Container Registry\",\n cache_validity_hours=48\n )\n\n # Quay für das Red-Hat-Ökosystem\n client.create_upstream(\n registry_id=registry['id'],\n url=\"https://quay.io\",\n name=\"Quay.io\",\n cache_validity_hours=24\n )\n\n\n ```\n\n\n ### CI/CD aktualisieren\n\n\n Eine `.gitlab-ci.yml`, die über die Virtual Registry pullt:\n\n\n ```yaml\n\n\n variables:\n VIRTUAL_REGISTRY_ID: \u003Cyour_virtual_registry_ID>\n\n \n build:\n image: docker:24\n services:\n - docker:24-dind\n before_script:\n # Authentifizierung bei GitLab – Upstream-Auth wird übernommen\n - echo \"${CI_JOB_TOKEN}\" | docker login -u gitlab-ci-token --password-stdin gitlab.com\n script:\n # Alle Pulls laufen über die zentrale Virtual Registry\n \n # Offizielle Docker Hub Images (library/-Präfix erforderlich)\n - docker pull gitlab.com/virtual_registries/container/${VIRTUAL_REGISTRY_ID}/library/alpine:latest\n \n # Docker Hardened Images von dhi.io (kein Präfix nötig)\n - docker pull gitlab.com/virtual_registries/container/${VIRTUAL_REGISTRY_ID}/python:3.13\n \n # .NET von MCR\n - docker pull gitlab.com/virtual_registries/container/${VIRTUAL_REGISTRY_ID}/dotnet/sdk:8.0\n\n\n ```\n\n\n ### Image-Pfadformate\n\n\n Verschiedene Registries verwenden unterschiedliche Pfadkonventionen:\n\n\n | Registry | Beispiel-Pull-URL |\n\n |----------|-------------------|\n\n | Docker Hub (offiziell) | `.../library/python:3.11-slim` |\n\n | Docker Hardened Images (dhi.io) | `.../python:3.13` |\n\n | MCR | `.../dotnet/sdk:8.0` |\n\n | Quay.io | `.../prometheus/prometheus:latest` |\n\n\n ### Funktionsprüfung\n\n\n Nach einigen Pulls lässt sich der Cache überprüfen:\n\n\n ```python\n\n\n upstreams = client.list_registry_upstreams(registry['id'])\n for upstream in upstreams:\n entries = client.list_cache_entries(upstream['id'])\n print(f\"{upstream['name']}: {len(entries)} cached entries\")\n\n\n ```\n\n\n ## Messergebnisse\n\n\n Testergebnisse beim Pullen über die Virtual Registry:\n\n\n | Messgröße | Ohne Cache | Mit warmem Cache |\n\n |-----------|------------|-----------------|\n\n | Pull-Zeit (Alpine) | 10,3 s | 4,2 s |\n\n | Pull-Zeit (Python 3.13 DHI) | 11,6 s | ~4 s |\n\n | Netzwerk-Roundtrips zum Upstream | Jeder Pull | Nur Cache-Misses |\n\n\n Der erste Pull hat dieselbe Dauer – das Image muss vom Upstream geladen werden. Jeder weitere Pull innerhalb der Cache-Gültigkeitsdauer kommt direkt aus GitLab-Storage: kein Netzwerk-Hop zu Docker Hub, dhi.io, MCR oder einer anderen Registry.\n\n\n Bei Teams mit vielen Pipeline-Jobs pro Tag summiert sich das zu einem messbaren Gewinn bei den Build-Laufzeiten.\n\n\n ## Praktische Hinweise\n\n\n ### Cache-Gültigkeit\n\n\n Der Standard sind 24 Stunden. Für sicherheitskritische Images, bei denen Patches schnell verfügbar sein sollen, empfiehlt sich ein kürzeres Intervall:\n\n\n ```python\n\n\n client.create_upstream(\n registry_id=registry['id'],\n url=\"https://dhi.io\",\n name=\"Docker Hardened Images\",\n username=\"your-username\",\n password=\"your-token\",\n cache_validity_hours=12\n )\n\n\n ```\n\n\n Für stabile Images mit fixen Versions-Tags ist ein längeres Intervall problemlos.\n\n\n ### Upstream-Priorität\n\n\n Upstreams werden der Reihe nach geprüft. Bei gleichnamigen Images in verschiedenen Registries gewinnt der erste passende Upstream.\n\n\n ### Limits\n\n\n - Maximal 20 Virtual Registries pro Gruppe\n\n - Maximal 20 Upstreams pro Virtual Registry\n\n\n ## Konfiguration über die Oberfläche\n\n\n Virtual Registries und Upstreams lassen sich auch direkt in der GitLab-Oberfläche einrichten – ohne API-Aufrufe. Unter **Einstellungen > Pakete und Registries > Virtual Registry** der jeweiligen Gruppe stehen folgende Optionen zur Verfügung:\n\n\n - Virtual Registries erstellen und verwalten\n\n - Upstreams hinzufügen, bearbeiten und neu anordnen\n\n - Cache anzeigen und verwalten\n\n - Überblick, welche Images abgerufen werden\n\n\n ## Ausblick\n\n\n In Entwicklung:\n\n\n - **Allow/Deny-Listen**: Regex-basierte Steuerung, welche Images aus welchen Upstreams abgerufen werden dürfen.\n\n\n Container Virtual Registry befindet sich in der Beta-Phase. Die Funktion wird produktiv eingesetzt und wird weiterentwickelt – Feedback fließt direkt in die Priorisierung ein.\n\n\n ## Feedback\n\n\n Wer als Plattformteam mit Registry-Wildwuchs zu kämpfen hat: Ich möchte verstehen, wie die aktuelle Situation aussieht.\n\n\n - Wie viele Upstream-Registries werden verwaltet?\n\n - Wo liegt der größte Schmerzpunkt?\n\n - Würde ein solcher Ansatz helfen – und falls nicht: Was fehlt?\n\n\n Erfahrungen und Rückmeldungen gerne im [Container Virtual Registry Feedback-Issue](https://gitlab.com/gitlab-org/gitlab/-/work_items/589630) teilen.\n\n\n ## Weiterführende Ressourcen\n\n\n - [Neue GitLab-Metriken und Registry-Funktionen zur Optimierung von CI/CD-Pipelines](https://about.gitlab.com/de-de/blog/new-gitlab-metrics-and-registry-features-help-reduce-ci-cd-bottlenecks/)\n\n - [Container Virtual Registry – Dokumentation](https://docs.gitlab.com/user/packages/virtual_registry/container/)\n\n - [Container Virtual Registry – API](https://docs.gitlab.com/api/container_virtual_registries/)\n\n\n ## Für deutsche Unternehmen könnte dies folgende Themen betreffen\n\n\n Teams, die sicherheitsgehärtete Base-Images mit vollständigen SBOMs und SLSA-Provenance einsetzen, haben möglicherweise auch Compliance-Überlegungen – beispielsweise in Bereichen wie Sicherheit der Software-Lieferkette, Nachvollziehbarkeit von Image-Abhängigkeiten und zentralem Audit-Trail.\n\n\n Regulatorische Frameworks wie NIS2 und der Cyber Resilience Act adressieren ähnliche Themen rund um Software-Lieferketten und SBOM-Transparenz. Für konkrete Compliance-Anforderungen empfiehlt sich Rücksprache mit entsprechender Fachberatung.\n category: engineering\n tags:\n - tutorial\n - product\n - features\nconfig:\n featured: false\n template: BlogPost\n slug: using-gitlab-container-virtual-registry-with-docker-hardened-images\n",{"config":32,"title":33,"description":34},{"noIndex":13},"Container Virtual Registry mit Docker Hardened Images","Mehrere Container-Registries zu einem Endpunkt konsolidieren: GitLab Container Virtual Registry mit Docker Hardened Images, Caching und Audit-Trail.","de-de/blog/using-gitlab-container-virtual-registry-with-docker-hardened-images",[22,23,24],[22,23,24],"rB2sO9HXKGsBvqKlCOAYQOhUqPhbvvVrZpkliB3tbn0",{"data":40},{"logo":41,"freeTrial":46,"sales":51,"login":56,"items":61,"search":371,"minimal":405,"duo":423,"switchNav":432,"pricingDeployment":443},{"config":42},{"href":43,"dataGaName":44,"dataGaLocation":45},"/de-de/","gitlab logo","header",{"text":47,"config":48},"Kostenlose Testversion anfordern",{"href":49,"dataGaName":50,"dataGaLocation":45},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de&glm_content=default-saas-trial/","free trial",{"text":52,"config":53},"Vertrieb kontaktieren",{"href":54,"dataGaName":55,"dataGaLocation":45},"/de-de/sales/","sales",{"text":57,"config":58},"Anmelden",{"href":59,"dataGaName":60,"dataGaLocation":45},"https://gitlab.com/users/sign_in/","sign in",[62,89,186,191,292,352],{"text":63,"config":64,"cards":66},"Plattform",{"dataNavLevelOne":65},"platform",[67,73,81],{"title":63,"description":68,"link":69},"Die intelligente Orchestrierungsplattform für DevSecOps",{"text":70,"config":71},"Die Plattform erkunden",{"href":72,"dataGaName":65,"dataGaLocation":45},"/de-de/platform/",{"title":74,"description":75,"link":76},"GitLab Duo Agent Platform","Agentische KI für den gesamten Software-Lebenszyklus",{"text":77,"config":78},"Lerne GitLab Duo kennen",{"href":79,"dataGaName":80,"dataGaLocation":45},"/de-de/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":82,"description":83,"link":84},"Warum GitLab?","Erfahre, warum sich Unternehmen für GitLab entscheiden",{"text":85,"config":86},"Mehr erfahren",{"href":87,"dataGaName":88,"dataGaLocation":45},"/de-de/why-gitlab/","why gitlab",{"text":90,"left":28,"config":91,"link":93,"lists":97,"footer":168},"Produkt",{"dataNavLevelOne":92},"solutions",{"text":94,"config":95},"Alle Lösungen anzeigen",{"href":96,"dataGaName":92,"dataGaLocation":45},"/de-de/solutions/",[98,123,146],{"title":99,"description":100,"link":101,"items":106},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":102},{"icon":103,"href":104,"dataGaName":105,"dataGaLocation":45},"AutomatedCodeAlt","/de-de/solutions/delivery-automation/","automated software delivery",[107,111,114,119],{"text":108,"config":109},"CI/CD",{"href":110,"dataGaLocation":45,"dataGaName":108},"/de-de/solutions/continuous-integration/",{"text":74,"config":112},{"href":79,"dataGaLocation":45,"dataGaName":113},"gitlab duo agent platform - product menu",{"text":115,"config":116},"Quellcodeverwaltung",{"href":117,"dataGaLocation":45,"dataGaName":118},"/de-de/solutions/source-code-management/","Source Code Management",{"text":120,"config":121},"Automatische Softwarebereitstellung",{"href":104,"dataGaLocation":45,"dataGaName":122},"Automated software delivery",{"title":124,"description":125,"link":126,"items":131},"Sicherheit","Entwickle Code schneller ohne Abstriche bei der Sicherheit",{"config":127},{"href":128,"dataGaName":129,"dataGaLocation":45,"icon":130},"/de-de/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[132,136,141],{"text":133,"config":134},"Anwendungssicherheitstests",{"href":128,"dataGaName":135,"dataGaLocation":45},"Application security testing",{"text":137,"config":138},"Schutz der Software-Lieferkette",{"href":139,"dataGaLocation":45,"dataGaName":140},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":142,"config":143},"Software-Compliance",{"href":144,"dataGaName":145,"dataGaLocation":45},"/de-de/solutions/software-compliance/","software compliance",{"title":147,"link":148,"items":153},"Auswertung",{"config":149},{"icon":150,"href":151,"dataGaName":152,"dataGaLocation":45},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[154,158,163],{"text":155,"config":156},"Sichtbarkeit und Auswertung",{"href":151,"dataGaLocation":45,"dataGaName":157},"Visibility and Measurement",{"text":159,"config":160},"Wertstrommanagement",{"href":161,"dataGaLocation":45,"dataGaName":162},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":164,"config":165},"Analysen und Einblicke",{"href":166,"dataGaLocation":45,"dataGaName":167},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":169,"items":170},"GitLab für",[171,176,181],{"text":172,"config":173},"Enterprise",{"href":174,"dataGaLocation":45,"dataGaName":175},"/de-de/enterprise/","enterprise",{"text":177,"config":178},"Kleinunternehmen",{"href":179,"dataGaLocation":45,"dataGaName":180},"/de-de/small-business/","small business",{"text":182,"config":183},"Öffentlicher Sektor",{"href":184,"dataGaLocation":45,"dataGaName":185},"/de-de/solutions/public-sector/","public sector",{"text":187,"config":188},"Preise",{"href":189,"dataGaName":190,"dataGaLocation":45,"dataNavLevelOne":190},"/de-de/pricing/","pricing",{"text":192,"config":193,"link":195,"lists":199,"feature":279},"Ressourcen",{"dataNavLevelOne":194},"resources",{"text":196,"config":197},"Alle Ressourcen anzeigen",{"href":198,"dataGaName":194,"dataGaLocation":45},"/de-de/resources/",[200,233,251],{"title":201,"items":202},"Erste Schritte",[203,208,213,218,223,228],{"text":204,"config":205},"Installieren",{"href":206,"dataGaName":207,"dataGaLocation":45},"/de-de/install/","install",{"text":209,"config":210},"Kurzanleitungen",{"href":211,"dataGaName":212,"dataGaLocation":45},"/de-de/get-started/","quick setup checklists",{"text":214,"config":215},"Lernen",{"href":216,"dataGaLocation":45,"dataGaName":217},"https://university.gitlab.com/","learn",{"text":219,"config":220},"Produktdokumentation",{"href":221,"dataGaName":222,"dataGaLocation":45},"https://docs.gitlab.com/","product documentation",{"text":224,"config":225},"Best-Practice-Videos",{"href":226,"dataGaName":227,"dataGaLocation":45},"/de-de/getting-started-videos/","best practice videos",{"text":229,"config":230},"Integrationen",{"href":231,"dataGaName":232,"dataGaLocation":45},"/de-de/integrations/","integrations",{"title":234,"items":235},"Entdecken",[236,241,246],{"text":237,"config":238},"Kundenerfolge",{"href":239,"dataGaName":240,"dataGaLocation":45},"/de-de/customers/","customer success stories",{"text":242,"config":243},"Blog",{"href":244,"dataGaName":245,"dataGaLocation":45},"/de-de/blog/","blog",{"text":247,"config":248},"Remote",{"href":249,"dataGaName":250,"dataGaLocation":45},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":252,"items":253},"Vernetzen",[254,259,264,269,274],{"text":255,"config":256},"GitLab Services",{"href":257,"dataGaName":258,"dataGaLocation":45},"/de-de/services/","services",{"text":260,"config":261},"Community",{"href":262,"dataGaName":263,"dataGaLocation":45},"/community/","community",{"text":265,"config":266},"Forum",{"href":267,"dataGaName":268,"dataGaLocation":45},"https://forum.gitlab.com/","forum",{"text":270,"config":271},"Veranstaltungen",{"href":272,"dataGaName":273,"dataGaLocation":45},"/events/","events",{"text":275,"config":276},"Partner",{"href":277,"dataGaName":278,"dataGaLocation":45},"/de-de/partners/","partners",{"background":280,"textColor":281,"text":282,"image":283,"link":287},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":284,"config":285},"The Source Promo-Karte",{"src":286},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":288,"config":289},"Aktuelles",{"href":290,"dataGaName":291,"dataGaLocation":45},"/de-de/the-source/","the source",{"text":293,"config":294,"lists":296},"Unternehmen",{"dataNavLevelOne":295},"company",[297],{"items":298},[299,304,310,312,317,322,327,332,337,342,347],{"text":300,"config":301},"Über",{"href":302,"dataGaName":303,"dataGaLocation":45},"/de-de/company/","about",{"text":305,"config":306,"footerGa":309},"Karriere",{"href":307,"dataGaName":308,"dataGaLocation":45},"/jobs/","jobs",{"dataGaName":308},{"text":270,"config":311},{"href":272,"dataGaName":273,"dataGaLocation":45},{"text":313,"config":314},"Geschäftsführung",{"href":315,"dataGaName":316,"dataGaLocation":45},"/company/team/e-group/","leadership",{"text":318,"config":319},"Team",{"href":320,"dataGaName":321,"dataGaLocation":45},"/company/team/","team",{"text":323,"config":324},"Handbuch",{"href":325,"dataGaName":326,"dataGaLocation":45},"https://handbook.gitlab.com/","handbook",{"text":328,"config":329},"Investor Relations",{"href":330,"dataGaName":331,"dataGaLocation":45},"https://ir.gitlab.com/","investor relations",{"text":333,"config":334},"Trust Center",{"href":335,"dataGaName":336,"dataGaLocation":45},"/de-de/security/","trust center",{"text":338,"config":339},"AI Transparency Center",{"href":340,"dataGaName":341,"dataGaLocation":45},"/de-de/ai-transparency-center/","ai transparency center",{"text":343,"config":344},"Newsletter",{"href":345,"dataGaName":346,"dataGaLocation":45},"/company/contact/#contact-forms","newsletter",{"text":348,"config":349},"Presse",{"href":350,"dataGaName":351,"dataGaLocation":45},"/press/","press",{"text":353,"config":354,"lists":355},"Kontakt",{"dataNavLevelOne":295},[356],{"items":357},[358,361,366],{"text":52,"config":359},{"href":54,"dataGaName":360,"dataGaLocation":45},"talk to sales",{"text":362,"config":363},"Support-Portal",{"href":364,"dataGaName":365,"dataGaLocation":45},"https://support.gitlab.com","support portal",{"text":367,"config":368},"Kundenportal",{"href":369,"dataGaName":370,"dataGaLocation":45},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":372,"login":373,"suggestions":380},"Schließen",{"text":374,"link":375},"Um Repositorys und Projekte zu durchsuchen, melde dich an bei",{"text":376,"config":377},"gitlab.com",{"href":59,"dataGaName":378,"dataGaLocation":379},"search login","search",{"text":381,"default":382},"Vorschläge",[383,385,390,392,397,402],{"text":74,"config":384},{"href":79,"dataGaName":74,"dataGaLocation":379},{"text":386,"config":387},"Codevorschläge (KI)",{"href":388,"dataGaName":389,"dataGaLocation":379},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":108,"config":391},{"href":110,"dataGaName":108,"dataGaLocation":379},{"text":393,"config":394},"GitLab auf AWS",{"href":395,"dataGaName":396,"dataGaLocation":379},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":398,"config":399},"GitLab auf Google Cloud",{"href":400,"dataGaName":401,"dataGaLocation":379},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":82,"config":403},{"href":87,"dataGaName":404,"dataGaLocation":379},"Why GitLab?",{"freeTrial":406,"mobileIcon":411,"desktopIcon":416,"secondaryButton":419},{"text":407,"config":408},"Kostenlos testen",{"href":409,"dataGaName":50,"dataGaLocation":410},"https://gitlab.com/-/trials/new/","nav",{"altText":412,"config":413},"GitLab-Symbol",{"src":414,"dataGaName":415,"dataGaLocation":410},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":412,"config":417},{"src":418,"dataGaName":415,"dataGaLocation":410},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":201,"config":420},{"href":421,"dataGaName":422,"dataGaLocation":410},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de/get-started/","get started",{"freeTrial":424,"mobileIcon":428,"desktopIcon":430},{"text":425,"config":426},"Mehr über GitLab Duo erfahren",{"href":79,"dataGaName":427,"dataGaLocation":410},"gitlab duo",{"altText":412,"config":429},{"src":414,"dataGaName":415,"dataGaLocation":410},{"altText":412,"config":431},{"src":418,"dataGaName":415,"dataGaLocation":410},{"button":433,"mobileIcon":438,"desktopIcon":440},{"text":434,"config":435},"/Option",{"href":436,"dataGaName":437,"dataGaLocation":410},"#contact","switch",{"altText":412,"config":439},{"src":414,"dataGaName":415,"dataGaLocation":410},{"altText":412,"config":441},{"src":442,"dataGaName":415,"dataGaLocation":410},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":444,"mobileIcon":449,"desktopIcon":451},{"text":445,"config":446},"Zurück zur Preisübersicht",{"href":189,"dataGaName":447,"dataGaLocation":410,"icon":448},"back to pricing","GoBack",{"altText":412,"config":450},{"src":414,"dataGaName":415,"dataGaLocation":410},{"altText":412,"config":452},{"src":418,"dataGaName":415,"dataGaLocation":410},{"title":454,"button":455,"config":460},"Sieh dir an, wie agentische KI die Softwarebereitstellung transformiert",{"text":456,"config":457},"GitLab Transcend jetzt ansehen",{"href":458,"dataGaName":459,"dataGaLocation":45},"/de-de/events/transcend/virtual/","transcend event",{"layout":461,"icon":462,"disabled":28},"release","AiStar",{"data":464},{"text":465,"source":466,"edit":472,"contribute":477,"config":482,"items":487,"minimal":690},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":467,"config":468},"Quelltext der Seite anzeigen",{"href":469,"dataGaName":470,"dataGaLocation":471},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":473,"config":474},"Diese Seite bearbeiten",{"href":475,"dataGaName":476,"dataGaLocation":471},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":478,"config":479},"Beteilige dich",{"href":480,"dataGaName":481,"dataGaLocation":471},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":483,"facebook":484,"youtube":485,"linkedin":486},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[488,533,586,628,655],{"title":187,"links":489,"subMenu":504},[490,494,499],{"text":491,"config":492},"Tarife anzeigen",{"href":189,"dataGaName":493,"dataGaLocation":471},"view plans",{"text":495,"config":496},"Vorteile von Premium",{"href":497,"dataGaName":498,"dataGaLocation":471},"/de-de/pricing/premium/","why premium",{"text":500,"config":501},"Vorteile von Ultimate",{"href":502,"dataGaName":503,"dataGaLocation":471},"/de-de/pricing/ultimate/","why ultimate",[505],{"title":353,"links":506},[507,509,511,513,518,523,528],{"text":52,"config":508},{"href":54,"dataGaName":55,"dataGaLocation":471},{"text":362,"config":510},{"href":364,"dataGaName":365,"dataGaLocation":471},{"text":367,"config":512},{"href":369,"dataGaName":370,"dataGaLocation":471},{"text":514,"config":515},"Status",{"href":516,"dataGaName":517,"dataGaLocation":471},"https://status.gitlab.com/","status",{"text":519,"config":520},"Nutzungsbedingungen",{"href":521,"dataGaName":522,"dataGaLocation":471},"/terms/","terms of use",{"text":524,"config":525},"Datenschutzerklärung",{"href":526,"dataGaName":527,"dataGaLocation":471},"/de-de/privacy/","privacy statement",{"text":529,"config":530},"Cookie-Einstellungen",{"dataGaName":531,"dataGaLocation":471,"id":532,"isOneTrustButton":28},"cookie preferences","ot-sdk-btn",{"title":90,"links":534,"subMenu":543},[535,539],{"text":536,"config":537},"DevSecOps-Plattform",{"href":72,"dataGaName":538,"dataGaLocation":471},"devsecops platform",{"text":540,"config":541},"KI-unterstützte Entwicklung",{"href":79,"dataGaName":542,"dataGaLocation":471},"ai-assisted development",[544],{"title":545,"links":546},"Themen",[547,551,556,561,566,571,576,581],{"text":108,"config":548},{"href":549,"dataGaName":550,"dataGaLocation":471},"/de-de/topics/ci-cd/","cicd",{"text":552,"config":553},"GitOps",{"href":554,"dataGaName":555,"dataGaLocation":471},"/de-de/topics/gitops/","gitops",{"text":557,"config":558},"DevOps",{"href":559,"dataGaName":560,"dataGaLocation":471},"/de-de/topics/devops/","devops",{"text":562,"config":563},"Versionskontrolle",{"href":564,"dataGaName":565,"dataGaLocation":471},"/de-de/topics/version-control/","version control",{"text":567,"config":568},"DevSecOps",{"href":569,"dataGaName":570,"dataGaLocation":471},"/de-de/topics/devsecops/","devsecops",{"text":572,"config":573},"Cloud-nativ",{"href":574,"dataGaName":575,"dataGaLocation":471},"/de-de/topics/cloud-native/","cloud native",{"text":577,"config":578},"KI für das Programmieren",{"href":579,"dataGaName":580,"dataGaLocation":471},"/de-de/topics/devops/ai-for-coding/","ai for coding",{"text":582,"config":583},"Agentische KI",{"href":584,"dataGaName":585,"dataGaLocation":471},"/de-de/topics/agentic-ai/","agentic ai",{"title":587,"links":588},"Lösungen",[589,592,594,599,603,606,609,612,614,616,618,623],{"text":133,"config":590},{"href":128,"dataGaName":591,"dataGaLocation":471},"Application Security Testing",{"text":120,"config":593},{"href":104,"dataGaName":105,"dataGaLocation":471},{"text":595,"config":596},"Agile Entwicklung",{"href":597,"dataGaName":598,"dataGaLocation":471},"/de-de/solutions/agile-delivery/","agile delivery",{"text":600,"config":601},"SCM",{"href":117,"dataGaName":602,"dataGaLocation":471},"source code management",{"text":108,"config":604},{"href":110,"dataGaName":605,"dataGaLocation":471},"continuous integration & delivery",{"text":159,"config":607},{"href":161,"dataGaName":608,"dataGaLocation":471},"value stream management",{"text":552,"config":610},{"href":611,"dataGaName":555,"dataGaLocation":471},"/de-de/solutions/gitops/",{"text":172,"config":613},{"href":174,"dataGaName":175,"dataGaLocation":471},{"text":177,"config":615},{"href":179,"dataGaName":180,"dataGaLocation":471},{"text":182,"config":617},{"href":184,"dataGaName":185,"dataGaLocation":471},{"text":619,"config":620},"Bildungswesen",{"href":621,"dataGaName":622,"dataGaLocation":471},"/de-de/solutions/education/","education",{"text":624,"config":625},"Finanzdienstleistungen",{"href":626,"dataGaName":627,"dataGaLocation":471},"/de-de/solutions/finance/","financial services",{"title":192,"links":629},[630,632,634,636,639,641,643,645,647,649,651,653],{"text":204,"config":631},{"href":206,"dataGaName":207,"dataGaLocation":471},{"text":209,"config":633},{"href":211,"dataGaName":212,"dataGaLocation":471},{"text":214,"config":635},{"href":216,"dataGaName":217,"dataGaLocation":471},{"text":219,"config":637},{"href":221,"dataGaName":638,"dataGaLocation":471},"docs",{"text":242,"config":640},{"href":244,"dataGaName":245,"dataGaLocation":471},{"text":237,"config":642},{"href":239,"dataGaName":240,"dataGaLocation":471},{"text":247,"config":644},{"href":249,"dataGaName":250,"dataGaLocation":471},{"text":255,"config":646},{"href":257,"dataGaName":258,"dataGaLocation":471},{"text":260,"config":648},{"href":262,"dataGaName":263,"dataGaLocation":471},{"text":265,"config":650},{"href":267,"dataGaName":268,"dataGaLocation":471},{"text":270,"config":652},{"href":272,"dataGaName":273,"dataGaLocation":471},{"text":275,"config":654},{"href":277,"dataGaName":278,"dataGaLocation":471},{"title":293,"links":656},[657,659,661,663,665,667,669,674,679,681,683,685],{"text":300,"config":658},{"href":302,"dataGaName":295,"dataGaLocation":471},{"text":305,"config":660},{"href":307,"dataGaName":308,"dataGaLocation":471},{"text":313,"config":662},{"href":315,"dataGaName":316,"dataGaLocation":471},{"text":318,"config":664},{"href":320,"dataGaName":321,"dataGaLocation":471},{"text":323,"config":666},{"href":325,"dataGaName":326,"dataGaLocation":471},{"text":328,"config":668},{"href":330,"dataGaName":331,"dataGaLocation":471},{"text":670,"config":671},"Nachhaltigkeit",{"href":672,"dataGaName":673,"dataGaLocation":471},"/sustainability/","Sustainability",{"text":675,"config":676},"Vielfalt, Inklusion und Zugehörigkeit",{"href":677,"dataGaName":678,"dataGaLocation":471},"/de-de/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":333,"config":680},{"href":335,"dataGaName":336,"dataGaLocation":471},{"text":343,"config":682},{"href":345,"dataGaName":346,"dataGaLocation":471},{"text":348,"config":684},{"href":350,"dataGaName":351,"dataGaLocation":471},{"text":686,"config":687},"Transparenzerklärung zu moderner Sklaverei",{"href":688,"dataGaName":689,"dataGaLocation":471},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":691},[692,694,697],{"text":519,"config":693},{"href":521,"dataGaName":522,"dataGaLocation":471},{"text":695,"config":696},"Cookies",{"dataGaName":531,"dataGaLocation":471,"id":532,"isOneTrustButton":28},{"text":524,"config":698},{"href":526,"dataGaName":527,"dataGaLocation":471},[700],{"id":701,"title":9,"body":26,"config":702,"content":704,"description":26,"extension":25,"meta":708,"navigation":28,"path":709,"seo":710,"stem":711,"__hash__":712},"blogAuthors/en-us/blog/authors/tim-rizzi.yml",{"template":703},"BlogAuthor",{"name":9,"config":705},{"headshot":706,"ctfId":707},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749661866/Blog/Author%20Headshots/trizzi-headshot.jpg","trizzi",{},"/en-us/blog/authors/tim-rizzi",{},"en-us/blog/authors/tim-rizzi","ADPqrpcnKveFJS0m_zFV0VLtb_h_txu59QVgz_YwKMc",[714,726,739],{"content":715,"config":724},{"title":716,"description":717,"authors":718,"heroImage":720,"date":721,"body":722,"category":11,"tags":723},"CI/CD-Observability im Unternehmensmaßstab aufbauen","Dieser Praxisleitfaden zu GitLab Pipeline Analytics hilft Self-Managed-Nutzern, mit Prometheus und Grafana operationale Insights zu gewinnen.",[719],"Paul Meresanu","https://res.cloudinary.com/about-gitlab-com/image/upload/v1774465167/n5hlvrsrheadeccyr1oz.png","2026-04-28","CI/CD-Optimierung beginnt mit Transparenz. Eine erfolgreiche DevOps-Plattform\nim Unternehmensmaßstab umfasst das Verständnis von Pipeline-Performance,\nJob-Ausführungsmustern und quantifizierbaren operationalen Insights – insbesondere\nfür Unternehmen, die GitLab Self-Managed betreiben.\n\nUm GitLab-Kund(inn)en dabei zu helfen, den vollen Nutzen ihrer Plattform\nauszuschöpfen, haben wir die GitLab CI/CD Observability-Lösung als Teil unseres\nPlatform Excellence-Programms entwickelt. Sie verwandelt rohe Pipeline-Metriken\nin handlungsrelevante operationale Erkenntnisse.\n\nEin führendes Finanzdienstleistungsunternehmen hat gemeinsam mit GitLabs Customer\nSuccess Architect Transparenz über seine GitLab Self-Managed-Deployments\ngewonnen. Gemeinsam haben wir eine containerisierte Observability-Lösung\nimplementiert, die den Open-Source-gitlab-ci-pipelines-exporter mit\nunternehmensgerechter Prometheus- und Grafana-Infrastruktur kombiniert.\n\nIn diesem Artikel werden die Herausforderungen beim Pipeline-Management im\nUnternehmensmaßstab erläutert – und wie GitLab CI/CD Observability diese mit\neiner praxisnahen End-to-End-Implementierung adressiert.\n\n\n## Die Herausforderung: CI/CD-Performance messen\n\nVor der Implementierung einer Observability-Lösung sollte die\nMessdimension klar definiert sein:\n\n* **Welche Metriken sind relevant?** Pipeline-Dauer, Job-Erfolgsraten,\n Queue-Zeiten, Runner-Auslastung\n* **Wer braucht Transparenz?** Entwickler(innen), DevOps-Engineers,\n Plattformteams, Führungsebene\n* **Welche Entscheidungen werden damit getroffen?** Infrastrukturinvestitionen,\n Engpass-Behebung, Kapazitätsplanung\n\n\n## Lösungsarchitektur: Ein vollständiges Dashboard-Set für Observability\n\nNach dem Deployment stellt der Observability-Stack ein Set von\nGrafana-Dashboards bereit, das Echtzeit- und historische Transparenz über die\nCI/CD-Plattform bietet. Ein typisches Deployment umfasst:\n\n* **Pipeline Overview Dashboard:** Eine übergeordnete Ansicht mit Gesamtzahl\n der Pipeline-Läufe, Erfolgs-/Fehlerquoten über die Zeit (als gestapelte\n Balken- oder Zeitreihencharts) und Trends bei der durchschnittlichen\n Pipeline-Dauer. Panels verwenden farbcodierte Statusindikatoren (Grün für\n Erfolg, Rot für Fehler, Gelb für Abbruch), damit Plattformteams\n Verschlechterungen auf einen Blick erkennen.\n* **Job Performance Dashboard:** Drill-down-Panels mit Verteilungen der\n einzelnen Job-Dauern (Histogramm), den 10 langsamsten Jobs nach\n Durchschnittsdauer und Job-Fehler-Heatmaps nach Projekt und Stage. Hier\n identifizieren Teams konkrete Engpass-Jobs, die sich zu optimieren lohnen.\n* **Runner & Infrastructure Dashboard:** Kombiniert Node-Exporter-Host-Metriken\n (CPU, Arbeitsspeicher, Disk) mit Pipeline-Queue-Zeit-Daten, um\n Infrastruktur-Sättigung mit Pipeline-Wartezeiten zu korrelieren. Nützlich\n für Kapazitätsplanungsentscheidungen wie die Skalierung von Runner-Pools oder\n das Upgrade von Instanzgrößen.\n* **Deployment Frequency Dashboard:** Verfolgt Deployment-Anzahl und\n -Dauer über die Zeit pro Umgebung, abgestimmt auf DORA-Metriken. Hilft\n der Engineering-Führungsebene, Lieferdurchsatz und Environment-Drift\n (Commits hinter main) zu bewerten.\n\nJedes Dashboard wird automatisch über Grafanas dateibasiertes Provisioning\nbereitgestellt, sodass es konsistent über alle Umgebungen hinweg deployed wird.\nDie Dashboards lassen sich über Grafana-Variablen weiter anpassen, um nach\nProjekt, Ref/Branch oder Zeitraum zu filtern.\n\n![Lösungsarchitektur](https://res.cloudinary.com/about-gitlab-com/image/upload/v1777382608/Blog/Imported/blog-building-ci-cd-observability-stack-for-gitlab-self-managed/image1.png)\n\nDie Lösung benötigt zwei Exporter:\n\n* **Pipeline Exporter:** Erfasst CI/CD-Metriken über die GitLab API\n (Pipeline-Dauer, Job-Status, Deployments)\n* **Node Exporter:** Erfasst Host-Metriken (CPU, Arbeitsspeicher, Disk)\n für die Infrastruktur-Korrelation\n\n**Voraussetzungen:**\n\n* GitLab Self-Managed Version 18.1+\n* **Container-Orchestrierungsplattform:** Ein Kubernetes-Cluster (empfohlen\n für Unternehmens-Deployments) oder eine Container-Runtime wie Docker/Podman\n für kleinere Umgebungen oder Proof-of-Concept-Deployments. Die primäre\n Deployment-Anleitung unten zielt auf Kubernetes; eine Docker-Compose-Alternative\n ist im Anhang für lokales Testen und Evaluation verfügbar\n* GitLab Personal Access Token (Scope **read_api**)\n\nDie vollständige Implementierungsanleitung mit allen Kubernetes-Manifesten\nfolgt direkt im Anschluss.\n\n\n## Kubernetes-Deployment (empfohlen)\n\nFür Unternehmensumgebungen wird jede Komponente als separates Deployment in\neinem dedizierten Namespace deployed. Dieser Ansatz integriert sich in\nbestehende Cluster-Infrastruktur, Secrets-Management und Network-Policies.\n\n### 1. Namespace und Secret erstellen\n\n```bash\nkubectl create namespace gitlab-observability\n\n# GitLab-Token-Secret erstellen (siehe Abschnitt Secrets-Management\n# für unternehmensgerechte Ansätze mit externen Secret-Operatoren)\nkubectl create secret generic gitlab-token \\\n --from-literal=token=glpat-xxxxxxxxxxxx \\\n -n gitlab-observability\n```\n\n### 2. Pipeline Exporter deployen\n\n```yaml\n# exporter-deployment.yaml\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: gitlab-ci-pipelines-exporter\n namespace: gitlab-observability\nspec:\n replicas: 1\n selector:\n matchLabels:\n app: gitlab-ci-pipelines-exporter\n template:\n metadata:\n labels:\n app: gitlab-ci-pipelines-exporter\n spec:\n containers:\n - name: exporter\n image: mvisonneau/gitlab-ci-pipelines-exporter:latest\n ports:\n - containerPort: 8080\n env:\n - name: GCPE_GITLAB_TOKEN\n valueFrom:\n secretKeyRef:\n name: gitlab-token\n key: token\n - name: GCPE_CONFIG\n value: /etc/gcpe/config.yml\n volumeMounts:\n - name: config\n mountPath: /etc/gcpe\n volumes:\n - name: config\n configMap:\n name: gcpe-config\n---\napiVersion: v1\nkind: Service\nmetadata:\n name: gitlab-ci-pipelines-exporter\n namespace: gitlab-observability\nspec:\n selector:\n app: gitlab-ci-pipelines-exporter\n ports:\n - port: 8080\n targetPort: 8080\n```\n\n### 3. Node Exporter deployen (DaemonSet)\n\n```yaml\n# node-exporter-daemonset.yaml\napiVersion: apps/v1\nkind: DaemonSet\nmetadata:\n name: node-exporter\n namespace: gitlab-observability\nspec:\n selector:\n matchLabels:\n app: node-exporter\n template:\n metadata:\n labels:\n app: node-exporter\n spec:\n containers:\n - name: node-exporter\n image: prom/node-exporter:latest\n ports:\n - containerPort: 9100\n---\napiVersion: v1\nkind: Service\nmetadata:\n name: node-exporter\n namespace: gitlab-observability\nspec:\n selector:\n app: node-exporter\n ports:\n - port: 9100\n targetPort: 9100\n```\n\n### 4. Prometheus deployen\n\n```yaml\n# prometheus-deployment.yaml\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: prometheus\n namespace: gitlab-observability\nspec:\n replicas: 1\n selector:\n matchLabels:\n app: prometheus\n template:\n metadata:\n labels:\n app: prometheus\n spec:\n containers:\n - name: prometheus\n image: prom/prometheus:latest\n ports:\n - containerPort: 9090\n volumeMounts:\n - name: config\n mountPath: /etc/prometheus\n volumes:\n - name: config\n configMap:\n name: prometheus-config\n---\napiVersion: v1\nkind: Service\nmetadata:\n name: prometheus\n namespace: gitlab-observability\nspec:\n selector:\n app: prometheus\n ports:\n - port: 9090\n targetPort: 9090\n```\n\n### 5. Grafana deployen\n\nDas folgende Grafana-Deployment startet mit deaktivierter Authentifizierung\n(`GF_AUTH_ANONYMOUS_ENABLED: true`) für den einfachen Einstieg.\n\n**Diese Einstellung erlaubt jedem mit Netzwerkzugang, alle Dashboards ohne\nAnmeldung einzusehen.** Für Produktions-Deployments diese Variable entfernen\noder auf false setzen und einen geeigneten Authentifizierungs-Provider\n(LDAP, SAML/SSO oder OAuth) konfigurieren, um den Zugriff auf autorisierte\nNutzende zu beschränken.\n\n```yaml\n# grafana-deployment.yaml\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: grafana\n namespace: gitlab-observability\nspec:\n replicas: 1\n selector:\n matchLabels:\n app: grafana\n template:\n metadata:\n labels:\n app: grafana\n spec:\n containers:\n - name: grafana\n image: grafana/grafana:10.0.0\n ports:\n - containerPort: 3000\n env:\n # Für Produktion ENTFERNEN oder auf 'false' setzen.\n # Bei 'true' können alle Nutzenden mit Netzwerkzugang\n # Dashboards ohne Authentifizierung einsehen.\n - name: GF_AUTH_ANONYMOUS_ENABLED\n value: 'true'\n volumeMounts:\n - name: dashboards-provider\n mountPath: /etc/grafana/provisioning/dashboards\n - name: datasources\n mountPath: /etc/grafana/provisioning/datasources\n - name: dashboards\n mountPath: /var/lib/grafana/dashboards\n volumes:\n - name: dashboards-provider\n configMap:\n name: grafana-dashboards-provider\n - name: datasources\n configMap:\n name: grafana-datasources\n - name: dashboards\n configMap:\n name: grafana-dashboards\n---\napiVersion: v1\nkind: Service\nmetadata:\n name: grafana\n namespace: gitlab-observability\nspec:\n selector:\n app: grafana\n ports:\n - port: 3000\n targetPort: 3000\n```\n\n### 6. Network Policy setzen\n\nDen Inter-Pod-Traffic auf die erforderlichen Kommunikationspfade beschränken:\n\n```yaml\n# network-policy.yaml\napiVersion: networking.k8s.io/v1\nkind: NetworkPolicy\nmetadata:\n name: observability-policy\n namespace: gitlab-observability\nspec:\n podSelector: {}\n policyTypes:\n - Ingress\n ingress:\n # Prometheus scrapt Exporter und Node-Exporter\n - from:\n - podSelector:\n matchLabels:\n app: prometheus\n ports:\n - port: 8080\n - port: 9100\n # Grafana fragt Prometheus ab\n - from:\n - podSelector:\n matchLabels:\n app: grafana\n ports:\n - port: 9090\n```\n\n### 7. Validieren\n\n```bash\nkubectl get pods -n gitlab-observability\nkubectl port-forward svc/grafana 3000:3000 -n gitlab-observability\ncurl http://localhost:3000/api/health\n```\n\n\n## Konfigurationsreferenz\n\n### Exporter-Konfiguration\n\n```yaml\n# gitlab-ci-pipelines-exporter.yml (ConfigMap: gcpe-config)\nlog:\n level: info\ngitlab:\n url: https://gitlab.your-domain.com\n maximum_requests_per_second: 10\nproject_defaults:\n pull:\n pipeline:\n jobs:\n enabled: true\nwildcards:\n - owner:\n name: your-group-name\n kind: group\n archived: false\n```\n\n### Prometheus-Konfiguration\n\n```yaml\n# prometheus.yml (ConfigMap: prometheus-config)\nglobal:\n scrape_interval: 15s\nscrape_configs:\n - job_name: 'gitlab-ci-pipelines-exporter'\n static_configs:\n - targets: ['gitlab-ci-pipelines-exporter:8080']\n - job_name: 'node-exporter'\n static_configs:\n - targets: ['node-exporter:9100']\n```\n\n### Grafana-Datenquellen\n\n```yaml\n# datasources.yml (ConfigMap: grafana-datasources)\napiVersion: 1\ndatasources:\n - name: Prometheus\n type: prometheus\n access: proxy\n url: http://prometheus:9090\n isDefault: true\n# dashboards.yml (ConfigMap: grafana-dashboards-provider)\napiVersion: 1\nproviders:\n - name: 'default'\n folder: 'GitLab CI/CD'\n type: file\n options:\n path: /var/lib/grafana/dashboards\n```\n\n\n## Wichtige Metriken\n\n### Pipeline-Exporter-Metriken\n\n| Metrik | Beschreibung |\n| :---- | :---- |\n| `gitlab_ci_pipeline_duration_seconds` | Pipeline-Ausführungszeit |\n| `gitlab_ci_pipeline_status` | Pipeline-Erfolg/-Fehler nach Projekt |\n| `gitlab_ci_pipeline_job_duration_seconds` | Einzelne Job-Ausführungszeit |\n| `gitlab_ci_pipeline_job_status` | Job-Erfolgs-/-Fehlerstatus |\n| `gitlab_ci_pipeline_job_artifact_size_bytes` | Artifact-Speicherverbrauch |\n| `gitlab_ci_pipeline_coverage` | Code-Coverage-Prozentsatz |\n| `gitlab_ci_environment_deployment_count` | Deployment-Häufigkeit |\n| `gitlab_ci_environment_deployment_duration_seconds` | Deployment-Ausführungszeit |\n| `gitlab_ci_environment_behind_commits_count` | Environment-Drift gegenüber main |\n\n### Node-Exporter-Metriken\n\n| Metrik | Beschreibung |\n| :---- | :---- |\n| `node_cpu_seconds_total` | CPU-Auslastung |\n| `node_memory_MemAvailable_bytes` | Verfügbarer Arbeitsspeicher |\n| `node_filesystem_avail_bytes` | Verfügbarer Festplattenspeicher |\n| `node_load1` | 1-Minuten-Lastdurchschnitt |\n\n\n## Fehlerbehebung\n\n### Grafana-Plugin-Installation in Air-gapped-Umgebungen\n\nFür Offline-Umgebungen Plugins manuell installieren. Beispiel für Kubernetes:\n\n```bash\n# Plugin-ZIP in den Grafana-Pod kopieren\nkubectl cp grafana-polystat-panel-2.1.16.zip \\\n gitlab-observability/grafana-\u003Cpod-id>:/tmp/\n# Plugin entpacken\nkubectl exec -it -n gitlab-observability deploy/grafana -- \\\n sh -c \"unzip /tmp/grafana-polystat-panel-2.1.16.zip -d /var/lib/grafana/plugins/\"\n# Grafana-Pod neu starten\nkubectl rollout restart deployment/grafana -n gitlab-observability\n# Installation prüfen\nkubectl exec -it -n gitlab-observability deploy/grafana -- \\\n ls -al /var/lib/grafana/plugins/\n```\n\n\n## Unternehmensaspekte\n\nFür regulierte Branchen gilt:\n\n* **Token-Sicherheit:** GitLab Personal Access Tokens in einem dedizierten\n Secrets-Manager speichern, nicht hartcodiert in ConfigMaps. Token-Rotation\n durchsetzen und den Scope auf **read\\_api** beschränken.\n* **Netzwerksegmentierung:** Hinter einem Reverse Proxy mit TLS-Terminierung\n deployen. In Kubernetes einen Ingress-Controller mit automatisierter\n Zertifikatsbereitstellung verwenden.\n* **Authentifizierung:** Grafana mit dem Identity Provider der Organisation\n konfigurieren (SAML, LDAP oder OAuth/OIDC), um rollenbasierte\n Zugriffskontrolle auf Dashboards durchzusetzen.\n\n\n## Warum GitLab?\n\nGitLabs API-First-Design ermöglicht individuelle Observability-Lösungen, die\nnative Funktionen wie Value Stream Analytics und DORA-Metriken ergänzen. Die\noffene Architektur erlaubt es Unternehmen, bewährte Open-Source-Werkzeuge –\nwie den gitlab-ci-pipelines-exporter – direkt in bestehende\nUnternehmensinfrastruktur zu integrieren, ohne etablierte Workflows zu\nunterbrechen.\n\nMit wachsender Observability-Reife bieten GitLabs eingebaute\nObservability-Funktionen einen natürlichen nächsten Schritt – tiefere,\nintegrierte Transparenz ohne zusätzliche Werkzeuge. Mehr zu den nativen\nPlattformfunktionen unter\n[GitLab Observability](https://docs.gitlab.com/operations/observability/observability/).\n",[108,23,22],{"featured":13,"template":14,"slug":725},"how-to-build-ci-cd-observability-at-scale",{"content":727,"config":737},{"body":728,"title":729,"description":730,"authors":731,"heroImage":733,"date":734,"category":11,"tags":735},"## Abschnitt 1: Das Modell verstehen\n*Für Engineering-Leads und Entscheidungsträger: Konzept, Anwendungsfälle und Architekturprinzipien. Konfigurationsdetails folgen in Abschnitt 2.*\n\nDie meisten CI/CD-Werkzeuge können einen Build ausführen und ein Deployment anstoßen. Der Unterschied zeigt sich erst dann, wenn die Delivery-Anforderungen komplexer werden: ein Monorepo mit einem Dutzend Services, Microservices über mehrere Repositories verteilt, Deployments in Dutzende von Umgebungen gleichzeitig – oder ein Platform-Team, das organisationsweite Standards durchsetzen will, ohne dabei zum Engpass zu werden.\n\nGitLabs Pipeline-Modell wurde für genau diese Komplexität entwickelt. Parent-Child-Pipelines, DAG-Execution, dynamische Pipeline-Generierung, Multi-Project-Trigger, Merge-Request-Pipelines mit Merged-Results-Verarbeitung und CI/CD Components lösen jeweils eine eigene Klasse von Problemen. Da sich diese Bausteine kombinieren lassen, erschließt das vollständige Modell mehr als nur kürzere Pipeline-Laufzeiten.\n\nDieser Artikel beschreibt die fünf Muster, bei denen das Modell seine Stärken deutlich zeigt – jeweils zugeordnet zu einem konkreten Engineering-Szenario. Konfigurationen und Implementierungsdetails folgen in Abschnitt 2.\n\n### 1. Monorepos: Parent-Child-Pipelines und DAG-Execution\n\n**Das Problem:** Ein Monorepo enthält Frontend, Backend und Dokumentation. Jeder Commit löst einen vollständigen Rebuild aller Komponenten aus – auch wenn sich nur eine README-Datei geändert hat.\n\nGitLab kombiniert zwei sich ergänzende Mechanismen: [Parent-Child-Pipelines](https://docs.gitlab.com/ci/pipelines/downstream_pipelines/#parent-child-pipelines) ermöglichen es einer übergeordneten Pipeline, isolierte Child-Pipelines zu starten. [DAG-Execution via `needs`](https://docs.gitlab.com/ci/yaml/#needs) bricht die starre Stage-Reihenfolge auf und startet Jobs, sobald ihre Abhängigkeiten abgeschlossen sind – nicht erst, wenn alle Jobs einer Stage fertig sind.\n\nEine Parent-Pipeline erkennt, welche Teile des Repos sich geändert haben, und löst ausschließlich die betroffenen Child-Pipelines aus. Jeder Service verwaltet seine eigene Pipeline-Konfiguration; Änderungen in einem Service können keine anderen beeinflussen. Damit bleibt die Komplexität beherrschbar, während das Repository und das Team wachsen.\n\nEinen technischen Aspekt gilt es dabei zu kennen: Wenn mehrere Dateien an einen einzelnen `trigger: include:`-Block übergeben werden, fusioniert GitLab sie zu einer einzigen Child-Pipeline-Konfiguration. Jobs aus diesen Dateien teilen denselben Pipeline-Kontext und können sich gegenseitig per `needs:` referenzieren – das ist die Voraussetzung für die DAG-Optimierung. Werden die Dateien stattdessen auf separate Trigger-Jobs aufgeteilt, entsteht jeweils eine isolierte Pipeline, und dateiübergreifende `needs:`-Referenzen funktionieren nicht.\n\nIn großen Monorepos lassen sich Pipeline-Laufzeiten durch DAG-Execution deutlich reduzieren, da Jobs nicht mehr auf unabhängige Arbeitsschritte in derselben Stage warten.\n\n### 2. Microservices: Cross-Repo-Pipelines über mehrere Projekte\n\n**Das Problem:** Frontend und Backend leben in separaten Repositories. Wenn das Frontend-Team eine Änderung ausliefert, ist nicht erkennbar, ob sie die Backend-Integration beeinträchtigt – und umgekehrt.\n\n[Multi-Project-Pipelines](https://docs.gitlab.com/ci/pipelines/downstream_pipelines/#multi-project-pipelines) ermöglichen es, aus einem Projekt heraus eine Pipeline in einem anderen Projekt auszulösen und auf das Ergebnis zu warten. Das auslösende Projekt sieht die verknüpfte Downstream-Pipeline direkt in seiner eigenen Pipeline-Ansicht.\n\nIn der Praxis erstellt die Frontend-Pipeline ein API-Contract-Artifact und veröffentlicht es, bevor die Backend-Pipeline ausgelöst wird. Das Backend ruft dieses Artifact über die [Jobs API](https://docs.gitlab.com/api/jobs/#download-a-single-artifact-file-from-specific-tag-or-branch) ab und validiert es, bevor weitere Schritte erlaubt sind. Wird eine Breaking Change erkannt, schlägt die Backend-Pipeline fehl – und mit ihr die Frontend-Pipeline. Probleme, die bisher erst in der Produktion sichtbar wurden, werden damit im Pipeline-Prozess abgefangen. Die Abhängigkeit zwischen Services wird sichtbar, nachvollziehbar und aktiv verwaltbar.\n\n![Cross-project pipelines](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775738762/Blog/Imported/hackathon-fake-blog-post-s/image4_h6mfsb.png \"Cross-project pipelines\") *Cross-project pipelines*\n\n### 3. Multi-Tenant/Matrix-Deployments: Dynamische Child-Pipelines\n\n**Das Problem:** Dieselbe Anwendung wird in 15 Kundenumgebungen, drei Cloud-Regionen oder den Stages Dev/Staging/Prod deployed. Manuelle Anpassungen je Umgebung führen zu Konfigurationsdrift. Eine separate Pipeline pro Umgebung ist von Anfang an nicht wartbar.\n\n[Dynamische Child-Pipelines](https://docs.gitlab.com/ci/pipelines/downstream_pipelines/#dynamic-child-pipelines) generieren die Pipeline-Struktur zur Laufzeit. Ein Job führt ein Skript aus, das eine YAML-Datei erzeugt – und diese YAML-Datei wird zur Pipeline für den nächsten Schritt. Die Pipeline-Struktur selbst wird damit zu Daten.\n\nDas Generierungsskript iteriert über eine `ENVIRONMENTS`-Variable, statt jede Umgebung fest zu kodieren. Eine neue Umgebung lässt sich durch Anpassen der Variable hinzufügen – ohne Änderungen an der Pipeline-Konfiguration selbst. Trigger-Jobs erben mit `extends:` eine gemeinsame Template-Konfiguration, sodass `strategy: depend` einmal definiert und nicht für jeden Trigger-Job wiederholt wird. Ein `when: manual`-Gate für das Produktions-Deployment ist direkt in den Pipeline-Graph integriert.\n\nPlatform-Teams nutzen dieses Muster, um Dutzende von Umgebungen zu verwalten, ohne Pipeline-Logik zu duplizieren.\n\n![Dynamic pipeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775738765/Blog/Imported/hackathon-fake-blog-post-s/image7_wr0kx2.png \"Dynamic pipeline\")\n\n### 4. MR-First-Delivery: Merge-Request-Pipelines, Merged-Results und Workflow-Routing\n\n**Das Problem:** Die Pipeline läuft bei jedem Push auf jeden Branch. Aufwändige Tests werden auf Feature-Branches ausgeführt, die nie gemergt werden. Gleichzeitig gibt es keine Garantie, dass das Getestete dem entspricht, was nach dem Merge auf `main` tatsächlich landet.\n\nGitLab kombiniert drei ineinandergreifende Mechanismen: [Merge-Request-Pipelines](https://docs.gitlab.com/ci/pipelines/merge_request_pipelines/) laufen ausschließlich dann, wenn ein Merge Request existiert – nicht bei jedem Branch-Push. Allein dadurch entfällt ein erheblicher Anteil unnötiger Compute-Ausführungen. [Merged-Results-Pipelines](https://docs.gitlab.com/ci/pipelines/merged_results_pipelines/) gehen einen Schritt weiter: GitLab erstellt einen temporären Merge-Commit aus dem Branch und dem aktuellen Ziel-Branch und führt die Pipeline dagegen aus. Getestet wird damit das tatsächliche Ergebnis des Merges – nicht der Branch in Isolation. [Workflow-Rules](https://docs.gitlab.com/ci/yaml/workflow/) definieren schließlich, welcher Pipeline-Typ unter welchen Bedingungen ausgeführt wird. Die `$CI_OPEN_MERGE_REQUESTS`-Guard verhindert dabei, dass für einen Branch mit offenem MR doppelte Pipelines ausgelöst werden.\n\nDas Ergebnis ist ein Pipeline-Verhalten, das sich je nach Kontext unterscheidet: Ein Push auf einen Feature-Branch ohne offenen MR führt nur Lint und Unit-Tests aus. Sobald ein MR geöffnet wird, wechseln die Workflow-Rules auf eine MR-Pipeline mit der vollständigen Test-Suite gegen das Merged-Result. Ein Merge auf `main` stellt ein manuelles Produktions-Deployment in die Warteschlange. Der Nightly-Scan läuft einmalig als geplante Pipeline – nicht bei jedem Commit.\n\nMerged-Results-Pipelines fangen dabei die Klasse von Fehlern ab, die erst nach einem Merge sichtbar werden – bevor sie `main` erreichen.\n\n### 5. Governed Pipelines: CI/CD Components\n\n**Das Problem:** Das Platform-Team hat den richtigen Weg für Build, Test und Deploy definiert. Jedes Anwendungsteam pflegt jedoch eine eigene `.gitlab-ci.yml` mit subtilen Abweichungen. Security-Scanning wird übersprungen. Deployment-Standards driften. Audits werden aufwändig.\n\n[CI/CD Components](https://docs.gitlab.com/ci/components/) ermöglichen es Platform-Teams, versionierte, wiederverwendbare Pipeline-Bausteine zu veröffentlichen. Anwendungsteams binden sie mit einer einzigen `include:`-Zeile ein – kein Copy-Paste, kein Drift. Components sind über den [CI/CD Catalog](https://docs.gitlab.com/ci/components/#cicd-catalog) auffindbar, sodass Teams bewährte Bausteine finden und übernehmen können, ohne das Platform-Team direkt einschalten zu müssen.\n\nDrei Zeilen `include:` ersetzen hunderte von duplizierten YAML-Zeilen. Das Platform-Team kann einen Security-Fix in einer neuen Komponentenversion veröffentlichen – Teams steigen auf ihrem eigenen Zeitplan um, oder das Platform-Team fixiert alle auf eine Mindestversion. In beiden Fällen propagiert eine Änderung organisationsweit, statt repo-für-repo angewendet zu werden.\n\nKombiniert mit [Resource Groups](https://docs.gitlab.com/ci/resource_groups/) zur Vermeidung konkurrierender Deployments und [Protected Environments](https://docs.gitlab.com/ci/environments/protected_environments/) für Freigabe-Gates entsteht eine governed Delivery-Plattform, auf der **Compliance der Standard ist, nicht die Ausnahme**. Platform-Teams setzen Vorgaben durch, ohne zum Engpass zu werden.\n\n![Component pipeline (imported jobs)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775738776/Blog/Imported/hackathon-fake-blog-post-s/image2_pizuxd.png \"Component pipeline (imported jobs)\")\n\n## Das Modell als Ganzes\n\nKeines dieser Muster existiert isoliert. Der Wert von GitLabs Pipeline-Modell liegt in der Kombinierbarkeit seiner Bausteine:\n\n- Ein Monorepo nutzt Parent-Child-Pipelines, und jede Child-Pipeline nutzt DAG-Execution.\n- Eine Microservices-Plattform nutzt Multi-Project-Pipelines, und jedes Projekt nutzt MR-Pipelines mit Merged-Results.\n- Eine governed Plattform nutzt CI/CD Components, um die obigen Muster organisationsweit zu standardisieren.\n\nDie meisten Teams entdecken eines dieser Muster, wenn sie auf ein konkretes Problem stoßen. Teams, die das vollständige Modell verstehen, entwickeln daraus eine Delivery-Infrastruktur, die tatsächlich abbildet, wie ihre Engineering-Organisation arbeitet – und mit ihr wächst.\n\n## Weitere Muster\n\nDas Pipeline-Modell geht über die fünf vorgestellten Muster hinaus:\n\n- [Review Apps mit dynamischen Umgebungen](https://docs.gitlab.com/ci/environments/) erstellen für jeden Feature-Branch eine Live-Vorschau und räumen sie automatisch auf, wenn der MR geschlossen wird.\n- [Caching- und Artifact-Strategien](https://docs.gitlab.com/ci/caching/) sind nach der strukturellen Arbeit häufig der direkteste Weg zur weiteren Laufzeitoptimierung – ohne die Pipeline-Struktur zu verändern.\n- [Geplante und API-ausgelöste Pipelines](https://docs.gitlab.com/ci/pipelines/schedules/) eignen sich für Workloads, die nicht bei jedem Code-Push laufen sollten: Nightly-Security-Scans, Compliance-Reports und Release-Automatisierung lassen sich als geplante oder [API-ausgelöste](https://docs.gitlab.com/ci/triggers/) Pipelines mit `$CI_PIPELINE_SOURCE`-Routing modellieren.\n\n> [GitLab Ultimate kostenlos testen](https://about.gitlab.com/de-de/free-trial/) und Pipeline-Logik ab heute einsetzen.\n\n## Für deutsche Unternehmen: Regulatorischer Kontext\n\nTeams, die Pipeline-Governance nach Muster 5 einführen, adressieren dabei möglicherweise auch Anforderungen, die regulatorische Frameworks an sichere Softwareentwicklungsprozesse stellen.\n\nCI/CD Components mit erzwungenen Security-Gates könnten Anforderungen an sichere Entwicklungsprozesse betreffen – beispielsweise in Bereichen, die Frameworks wie NIS2, ISO 27001 oder BSI IT-Grundschutz an den Software-Entwicklungslebenszyklus adressieren. Protected Environments und Resource Groups betreffen ähnliche Themen im Bereich Änderungskontrolle und Umgebungstrennung, wie sie in Governance-Frameworks typischerweise explizit formuliert sind.\n\nMulti-Project-Pipelines mit API-Contract-Validierung (Muster 2) schaffen Sichtbarkeit über Service-Abhängigkeiten hinweg – ein Aspekt, den Frameworks zur Lieferkettensicherheit adressieren.\n\nMerged-Results-Pipelines (Muster 4) dokumentieren automatisch, dass das tatsächliche Merge-Ergebnis getestet wurde, nicht nur der Feature-Branch in Isolation. Dies könnte Anforderungen an nachvollziehbare Änderungsprozesse betreffen, wie sie in Change-Management-Kontrollen verschiedener Sicherheitsframeworks formuliert sind.\n\nFür konkrete Compliance-Anforderungen im eigenen regulatorischen Umfeld empfiehlt sich Rücksprache mit entsprechender Fachberatung.\n\n## Abschnitt 2: Konfiguration und Implementierung\n\n*Für Entwicklungsteams und DevOps-Praktiker: ausgewählte Konfigurationsbeispiele zu den Mustern 1, 4 und 5. Für vollständige Konfigurationen aller Muster: [englischer Originalartikel](https://about.gitlab.com/blog/5-ways-gitlab-pipeline-logic-solves-real-engineering-problems/).*\n\nDie folgenden Konfigurationen sind illustrativ aufgebaut. Die Skripte verwenden `echo`-Befehle, um das Wesentliche sichtbar zu halten. Für den produktiven Einsatz werden die `echo`-Befehle durch die tatsächlichen Build-, Test- und Deploy-Schritte ersetzt.\n\n### Muster 1: Parent-Child-Pipelines und DAG-Execution\n\nEine Parent-Pipeline erkennt Änderungen und löst nur die betroffenen Child-Pipelines aus:\n\n```yaml # .gitlab-ci.yml stages:\n - trigger\n\ntrigger-services:\n stage: trigger\n trigger:\n include:\n - local: '.gitlab/ci/api-service.yml'\n - local: '.gitlab/ci/web-service.yml'\n - local: '.gitlab/ci/worker-service.yml'\n strategy: depend\n```\n\nInnerhalb der Child-Pipeline ermöglicht `needs:` DAG-Execution – der Test startet, sobald der Build abgeschlossen ist, ohne auf andere Jobs in derselben Stage zu warten:\n\n```yaml # .gitlab/ci/api-service.yml stages:\n - build\n - test\n\nbuild-api:\n stage: build\n script:\n - echo \"Building API service\"\n\ntest-api:\n stage: test\n needs: [build-api]\n script:\n - echo \"Running API tests\"\n```\n\n![Local downstream pipelines](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775738759/Blog/Imported/hackathon-fake-blog-post-s/image3_vwj3rz.png \"Local downstream pipelines\")\n\n### Muster 4: MR-First-Delivery\n\nWorkflow-Rules, MR-Pipelines und Merged-Results zusammen ergeben ein kontextabhängiges Pipeline-Verhalten:\n\n```yaml # .gitlab-ci.yml workflow:\n rules:\n - if: $CI_PIPELINE_SOURCE == \"merge_request_event\"\n - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS\n when: never\n - if: $CI_COMMIT_BRANCH\n - if: $CI_PIPELINE_SOURCE == \"schedule\"\n\nstages:\n - fast-checks\n - expensive-tests\n - deploy\n\nlint-code:\n stage: fast-checks\n script:\n - echo \"Running linter\"\n rules:\n - if: $CI_PIPELINE_SOURCE == \"push\"\n - if: $CI_PIPELINE_SOURCE == \"merge_request_event\"\n - if: $CI_COMMIT_BRANCH == \"main\"\n\nunit-tests:\n stage: fast-checks\n script:\n - echo \"Running unit tests\"\n rules:\n - if: $CI_PIPELINE_SOURCE == \"push\"\n - if: $CI_PIPELINE_SOURCE == \"merge_request_event\"\n - if: $CI_COMMIT_BRANCH == \"main\"\n\nintegration-tests:\n stage: expensive-tests\n script:\n - echo \"Running integration tests (15 min)\"\n rules:\n - if: $CI_PIPELINE_SOURCE == \"merge_request_event\"\n - if: $CI_COMMIT_BRANCH == \"main\"\n\ne2e-tests:\n stage: expensive-tests\n script:\n - echo \"Running E2E tests (30 min)\"\n rules:\n - if: $CI_PIPELINE_SOURCE == \"merge_request_event\"\n - if: $CI_COMMIT_BRANCH == \"main\"\n\nnightly-comprehensive-scan:\n stage: expensive-tests\n script:\n - echo \"Running full nightly suite (2 hours)\"\n rules:\n - if: $CI_PIPELINE_SOURCE == \"schedule\"\n\ndeploy-production:\n stage: deploy\n script:\n - echo \"Deploying to production\"\n rules:\n - if: $CI_COMMIT_BRANCH == \"main\"\n when: manual\n```\n\n![Conditional pipelines (within a branch with no MR)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775738768/Blog/Imported/hackathon-fake-blog-post-s/image6_dnfcny.png \"Conditional pipelines (within a branch with no MR)\")\n\n![Conditional pipelines (within an MR)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775738772/Blog/Imported/hackathon-fake-blog-post-s/image1_wyiafu.png \"Conditional pipelines (within an MR)\")\n\n![Conditional pipelines (on the main branch)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775738774/Blog/Imported/hackathon-fake-blog-post-s/image5_r6lkfd.png \"Conditional pipelines (on the main branch)\")\n\n### Muster 5: CI/CD Components\n\nEine Komponentendefinition aus einer gemeinsamen Bibliothek:\n\n```yaml # templates/deploy.yml spec:\n inputs:\n stage:\n default: deploy\n environment:\n default: production\n--- deploy-job:\n stage: $[[ inputs.stage ]]\n script:\n - echo \"Deploying $APP_NAME to $[[ inputs.environment ]]\"\n - echo \"Deploy URL: $DEPLOY_URL\"\n environment:\n name: $[[ inputs.environment ]]\n```\n\nSo bindet ein Anwendungsteam die Komponenten ein:\n\n```yaml # Application repo: .gitlab-ci.yml variables:\n APP_NAME: \"my-awesome-app\"\n DEPLOY_URL: \"https://api.example.com\"\n\ninclude:\n - component: gitlab.com/my-org/component-library/build@v1.0.6\n - component: gitlab.com/my-org/component-library/test@v1.0.6\n - component: gitlab.com/my-org/component-library/deploy@v1.0.6\n inputs:\n environment: staging\n\nstages:\n - build\n - test\n - deploy\n```\n\n### Orientierung zu den Mustern 2 und 3\n\n**Muster 2 (Multi-Project-Pipelines):** Das Frontend-Repository publiziert ein API-Contract-Artifact und löst anschließend die Backend-Pipeline aus. Das Backend ruft das Artifact über die GitLab Jobs API ab und validiert es. Der `integration-test`-Job läuft dabei nur dann, wenn er von einer Upstream-Pipeline ausgelöst wurde (`$CI_PIPELINE_SOURCE == \"pipeline\"`), nicht bei einem eigenständigen Push. Die Frontend-Projekt-ID wird als CI/CD-Variable gesetzt, um Hardcoding zu vermeiden. Vollständige Konfigurationen beider Repositories: [englischer Originalartikel](https://about.gitlab.com/blog/5-ways-gitlab-pipeline-logic-solves-real-engineering-problems/#2-microservices-cross-repo-multi-project-pipelines).\n\n**Muster 3 (Dynamische Child-Pipelines):** Ein `generate-config`-Job erzeugt zur Laufzeit environment-spezifische YAML-Dateien. Trigger-Jobs nutzen `extends:` für gemeinsam genutzte Konfiguration und `needs:` für sequenzielle Promotion (dev → staging → prod mit manuellem Gate). Vollständige Konfiguration: [englischer Originalartikel](https://about.gitlab.com/blog/5-ways-gitlab-pipeline-logic-solves-real-engineering-problems/#3-multi-tenant--matrix-deployments-dynamic-child-pipelines).\n\n## Weiterführende Artikel\n\n- [Variable and artifact sharing in GitLab parent-child pipelines](https://about.gitlab.com/blog/variable-and-artifact-sharing-in-gitlab-parent-child-pipelines/)\n- [CI/CD inputs: Secure and preferred method to pass parameters to a pipeline](https://about.gitlab.com/blog/ci-cd-inputs-secure-and-preferred-method-to-pass-parameters-to-a-pipeline/)\n- [Tutorial: How to set up your first GitLab CI/CD component](https://about.gitlab.com/blog/tutorial-how-to-set-up-your-first-gitlab-ci-cd-component/)\n- [How to include file references in your CI/CD components](https://about.gitlab.com/blog/how-to-include-file-references-in-your-ci-cd-components/)\n- [FAQ: GitLab CI/CD Catalog](https://about.gitlab.com/blog/faq-gitlab-ci-cd-catalog/)\n- [Building a GitLab CI/CD pipeline for a monorepo the easy way](https://about.gitlab.com/blog/building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way/)\n- [A CI/CD component builder's journey](https://about.gitlab.com/blog/a-ci-component-builders-journey/)\n- [CI/CD Catalog goes GA: No more building pipelines from scratch](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/)","5 GitLab-Pipeline-Muster für komplexe Engineering-Herausforderungen","Wie Parent-Child-Pipelines, DAG-Execution, MR-Pipelines und CI/CD Components komplexe Delivery-Probleme lösen – von Monorepos bis zur governed Plattform.",[732],"Omid Khan","https://res.cloudinary.com/about-gitlab-com/image/upload/v1772721753/frfsm1qfscwrmsyzj1qn.png","2026-04-09",[108,736,22,24],"DevOps platform",{"featured":28,"template":14,"slug":738},"5-ways-gitlab-pipeline-logic-solves-real-engineering-problems",{"content":740,"config":751},{"category":11,"tags":741,"body":743,"date":744,"heroImage":745,"authors":746,"title":749,"description":750},[22,742,108],"git","Enterprise-Migrationen in regulierten Branchen wie Finanzwesen und Automobilindustrie erfordern systematisches Risikomanagement gemäß NIS2-Richtlinie Artikel 21. Die mehrstufige Migrationsstruktur mit Testläufen vor Produktions-Wellen und kontrollierten Change-Freezes demonstriert Business-Continuity-Management in der Praxis. GitLab Professional Services organisiert Migrationen in Wellen von 200-300 Projekten, um Komplexität zu managen und API-Rate-Limits zu respektieren.\n\n## Überblick\n\nGitLab bietet [Congregate](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/) (maintained by GitLab Professional Services) und [eingebauten Git-Repository-Import](https://docs.gitlab.com/user/project/import/repo_by_url/) für Migrationen von Azure DevOps (ADO). Beide Optionen unterstützen Repository-basierte oder Bulk-Migration und erhalten Git-Commit-History, Branches und Tags. Mit Congregate werden zusätzliche Assets wie Wikis, Work Items, CI/CD-Variablen, Container-Images, Packages und Pipelines migriert (siehe [Feature-Matrix](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/customer/ado-migration-features-matrix.md)).\n\nEnterprises folgen typischerweise einem mehrstufigen Ansatz:\n\n- Repositories von ADO zu GitLab migrieren (Congregate oder eingebauter Import)\n- Pipelines von Azure Pipelines zu GitLab CI/CD migrieren\n- Verbleibende Assets wie Boards, Work Items und Artifacts zu GitLab Issues, Epics und Package/Container Registries migrieren\n\nMehrstufige Migrationsphasen (siehe [Diagramm](https://about.gitlab.com/blog/migration-from-azure-devops-to-gitlab/#overview)):\n\n- Prerequisites (IdP, Runners, Change Management)\n- Migration Phase (Source Code, History, Work Items)\n- Post-Migration (Pipelines, Assets, Security)\n\n## Migration planen\n\n**Zentrale Planungsfragen:**\n\n- Wie schnell muss die Migration abgeschlossen werden?\n- Was genau wird migriert?\n- Wer führt die Migration durch?\n- Welche Organisationsstruktur wird in GitLab benötigt?\n- Welche Einschränkungen, Limitierungen oder Fallstricke müssen berücksichtigt werden?\n\nDie Timeline bestimmt weitgehend den Migrationsansatz. Identifizierung von Champions oder Teams mit ADO- und GitLab-Erfahrung unterstützt Adoption und Guidance.\n\n**Inventar erstellen:**\n\nDas GitLab Professional Services [Evaluate](https://gitlab.com/gitlab-org/professional-services-automation/tools/utilities/evaluate#beta-azure-devops)-Tool produziert ein vollständiges Inventar der Azure DevOps Organisation: Repositories, PR-Counts, Contributors, Pipelines, Work Items, CI/CD-Variablen. Bei Professional Services Engagements wird dieser Report mit Engagement Manager oder Technical Architect geteilt für Migrationsplanung.\n\nMigrations-Timing wird primär bestimmt durch Pull-Request-Count, Repository-Größe und Contribution-Menge. Beispiel: 1.000 kleine Repositories mit wenigen PRs migrieren schneller als wenige Repositories mit Zehntausenden PRs. Inventar-Daten ermöglichen Aufwands-Schätzung und Test-Run-Planung.\n\nIn Professional Services Engagements werden Migrationen in Wellen von 200-300 Projekten organisiert, um Komplexität zu managen und API-Rate-Limits zu respektieren (sowohl [GitLab](https://docs.gitlab.com/security/rate_limits/) als auch [ADO](https://learn.microsoft.com/en-us/azure/devops/integrate/concepts/rate-limits?view=azure-devops)).\n\n**Tool-Auswahl:**\n\nGitLabs [eingebauter Repository-Importer](https://docs.gitlab.com/user/project/import/repo_by_url/) migriert Git-Repositories (Commits, Branches, Tags) einzeln. Congregate erhält Pull Requests (in GitLab: Merge Requests), Kommentare und Metadata; der eingebaute Import fokussiert auf Git-Daten (History, Branches, Tags).\n\nAssets die typischerweise separate Migration oder manuelle Neuerstellung erfordern:\n\n- Azure Pipelines → GitLab CI/CD Pipelines (siehe [CI/CD YAML](https://docs.gitlab.com/ci/yaml/) oder [CI/CD Components](https://docs.gitlab.com/ci/components/)). Alternativ: AI-basierte Pipeline-Konvertierung in Congregate.\n- Work Items und Boards → GitLab Issues, Epics, Issue Boards\n- Artifacts, Container-Images (ACR) → GitLab Package/Container Registry\n- Service Hooks, externe Integrationen → in GitLab neu erstellen\n\n[Permissions-Modelle](https://docs.gitlab.com/user/permissions/) unterscheiden sich zwischen ADO und GitLab. Permissions-Mapping planen statt exakter Preservation zu erwarten.\n\n**Organisationsstruktur in GitLab:**\n\nEmpfohlener Ansatz: ADO-Organisationen auf GitLab-Groups mappen (nicht viele kleine Groups). Migration als Gelegenheit nutzen, GitLab-Struktur zu rationalisieren (siehe [Struktur-Diagramm](https://about.gitlab.com/blog/migration-from-azure-devops-to-gitlab/#planning-your-migration)):\n\n- **ADO Organization** → GitLab Top-level Group\n- **ADO Project** → GitLab Subgroup (optional)\n- **ADO Repository** → GitLab Project\n\nWeitere Empfehlungen:\n\n- Subgroups und Project-Level-Permissions für verwandte Repositories nutzen\n- Zugriff über GitLab Groups und Group-Membership managen\n- GitLab [Permissions](https://docs.gitlab.com/user/permissions/) und [SAML Group Links](https://docs.gitlab.com/user/group/saml_sso/group_sync/) für Enterprise-RBAC-Modell evaluieren\n\n**ADO Work Items Migration:**\n\nADO Boards und Work Items mappen zu GitLab Issues, Epics und Issue Boards. ADO Epics und Features werden GitLab Epics. Andere Work-Item-Typen (User Stories, Tasks, Bugs) werden project-scoped Issues. Standard-Felder bleiben erhalten; ausgewählte Custom Fields können migriert werden. Parent-Child-Relationships bleiben erhalten. Links zu Pull Requests werden zu Merge-Request-Links konvertiert.\n\n![Migration eines Work Items zu GitLab Issue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1764769188/ztesjnxxfbwmfmtckyga.png)\n\n**Pipelines-Migration:**\n\nCongregate bietet [AI-basierte Konvertierung](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/merge_requests/1298) für multi-stage YAML-Pipelines von Azure DevOps zu GitLab CI/CD. Die automatisierte Konvertierung funktioniert optimal für einfache Single-File-Pipelines und liefert einen funktionalen Ausgangspunkt, nicht ein produktionsreifes `.gitlab-ci.yml`-File. Das Tool generiert funktional äquivalente GitLab-Pipelines zur weiteren Optimierung.\n\n- Konvertiert Azure Pipelines YAML zu `.gitlab-ci.yml` automatisch\n- Geeignet für straightforward Single-File-Pipeline-Konfigurationen\n- Liefert Boilerplate zur Migrations-Beschleunigung, nicht finales Production-Artifact\n- Erfordert Review und Anpassung für komplexe Szenarien, Custom Tasks oder Enterprise-Requirements\n- Unterstützt keine Azure DevOps Classic Release Pipelines\n\nRepository-Owner sollten [GitLab CI/CD Dokumentation](https://docs.gitlab.com/ci/) konsultieren für weitere Pipeline-Optimierung nach initialer Konvertierung.\n\n## Migrationen durchführen\n\nNach der Planung werden Migrationen in Stages durchgeführt, beginnend mit Trial Runs. Trial Migrations identifizieren organisations-spezifische Issues frühzeitig und ermöglichen Duration-Messung, Outcome-Validierung und Approach-Finetuning vor Production.\n\n**Was Trial Migrations validieren:**\n\n- Ob Repository und Assets erfolgreich migrieren (History, Branches, Tags; plus MRs/Comments bei Congregate)\n- Ob Destination sofort nutzbar ist (Permissions, Runners, CI/CD-Variablen, Integrationen)\n- Wie lange jeder Batch benötigt für Schedule- und Stakeholder-Expectations\n\n**Downtime-Guidance:**\n\nGitLabs eingebauter Git-Import und Congregate erfordern inhärent keine Downtime. Für Production-Wellen: Changes in ADO freezen (Branch-Protections oder Read-only), um verpasste Commits, PR-Updates oder mid-migration Work Items zu vermeiden. Trial Runs erfordern keine Freezes.\n\n**Batching-Guidance:**\n\nTrial-Batches back-to-back durchführen für kürzere elapsed Time. Teams validieren Results asynchron. Geplante Group/Subgroup-Struktur für Batch-Definition nutzen und API-Rate-Limits respektieren.\n\n**Empfohlene Schritte:**\n\n1. Test-Destination in GitLab erstellen (GitLab.com: dedicated Group/Namespace; Self-managed: Top-level Group)\n2. Authentication vorbereiten (Azure DevOps PAT, GitLab Personal Access Token mit api und read_repository Scopes)\n3. Trial Migrations durchführen (Repos only: eingebauter Import; Repos + PRs/MRs: Congregate)\n4. Post-Trial Follow-up (Repo-History, Branches, Tags, Merge Requests, Issues/Epics, Labels, Relationships verifizieren)\n5. Permissions/Roles, Protected Branches, Runners/Tags, Variables/Secrets, Integrations/Webhooks prüfen\n6. Pipelines (`.gitlab-ci.yml`) oder konvertierte Pipelines validieren\n7. User-Validierung für Functionality und Data-Fidelity\n8. Production-Migrationen in Waves durchführen (Change-Freezes in ADO erzwingen, Progress und Logs monitoren)\n\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/ibIXGfrVbi4?si=ZxOVnXjCF-h4Ne0N\" frameborder=\"0\" allowfullscreen=\"true\">\u003C/iframe>\n\u003C/figure>\n\n## Zentrale ADO-zu-GitLab-Mappings\n\nWichtigste Struktur-Mappings für Migrationsplanung:\n\n- **ADO Organization** → GitLab Group (Top-level Namespace)\n- **ADO Project** → GitLab Group oder Subgroup (Permissions-Boundary)\n- **ADO Repository** → GitLab Project (Git-Repo plus Issues, CI/CD, Wiki)\n- **Pull Request** → Merge Request (Code Review, Approvals)\n- **Azure Pipelines** → GitLab CI/CD (`.gitlab-ci.yml`)\n- **Agent Pools** → GitLab Runners (Job-Execution)\n- **Work Items** → GitLab Issues/Epics (Planning-Funktionalität)\n- **Variable Groups** → CI/CD Variables (Project/Group/Instance Level)\n\nFür vollständige Terminologie-Referenztabelle mit allen Mappings siehe [englische Originalversion](https://about.gitlab.com/blog/migration-from-azure-devops-to-gitlab/).\n\n## Professional Services Migrationsmuster\n\nGitLab Professional Services nutzt bewährte Muster für Enterprise-Migrationen:\n\n**Systematische Planung:** Evaluate-Tool liefert vollständiges Inventar (Repositories, PRs, Contributors, Pipelines, Work Items). Klassifikation nach Komplexität (Work Items = Planning-Team-Involvement; Pipelines = Conversion-Requirements) ermöglicht Timeline-Schätzung und Batch-Definition.\n\n**Controlled Execution:** Wellen von 200-300 Projekten managen Komplexität und respektieren API-Rate-Limits. Trial-Migrationen vor Production-Waves identifizieren Issues frühzeitig. Change-Freezes in ADO während Production-Wellen vermeiden mid-migration Updates.\n\n**Risikominimierung:** Multi-Phase-Ansatz (Prerequisites → Migration → Post-migration) mit Validierungs-Checkpoints an jeder Phase. Trial-Runs ermöglichen asynchrone Team-Validierung ohne Production-Impact.\n\n## Praktische Implementierung\n\nFür vollständige Implementierungsdetails, Konfigurationsbeispiele, Pipeline-Konvertierungs-Patterns und detaillierte Post-Migration-Checklisten siehe [englische Originalversion](https://about.gitlab.com/blog/migration-from-azure-devops-to-gitlab/).\n\nWeitere Professional Services Ressourcen:\n\n- [Professional Services Full Catalog](https://about.gitlab.com/professional-services/catalog/)\n- [Congregate Migration Tool](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/)\n- [Evaluate Inventory Tool](https://gitlab.com/gitlab-org/professional-services-automation/tools/utilities/evaluate)\n","2025-12-03","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658924/Blog/Hero%20Images/securitylifecycle-light.png",[747,748],"Evgeny Rudinsky","Michael Leopard","Migration von Azure DevOps zu GitLab systematisch planen","Professional Services Migrationsansatz mit mehrstufiger Struktur, 200-300 Projekt-Wellen und systematischem Risikomanagement für Enterprise-Migrationen.",{"featured":28,"template":14,"slug":752},"migration-from-azure-devops-to-gitlab",{"promotions":754},[755,769,780,792],{"id":756,"categories":757,"header":759,"text":760,"button":761,"image":766},"ai-modernization",[758],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":762,"config":763},"Get your AI maturity score",{"href":764,"dataGaName":765,"dataGaLocation":245},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":767},{"src":768},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":770,"categories":771,"header":772,"text":760,"button":773,"image":777},"devops-modernization",[23,570],"Are you just managing tools or shipping innovation?",{"text":774,"config":775},"Get your DevOps maturity score",{"href":776,"dataGaName":765,"dataGaLocation":245},"/assessments/devops-modernization-assessment/",{"config":778},{"src":779},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":781,"categories":782,"header":784,"text":760,"button":785,"image":789},"security-modernization",[783],"security","Are you trading speed for security?",{"text":786,"config":787},"Get your security maturity score",{"href":788,"dataGaName":765,"dataGaLocation":245},"/assessments/security-modernization-assessment/",{"config":790},{"src":791},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":793,"paths":794,"header":796,"text":797,"button":798,"image":803},"github-azure-migration",[752,795],"integrating-azure-devops-scm-and-gitlab","Is your team ready for GitHub's Azure move?","GitHub is already rebuilding around Azure. Find out what it means for you.",{"text":799,"config":800},"See how GitLab compares to GitHub",{"href":801,"dataGaName":802,"dataGaLocation":245},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":804},{"src":779},{"header":806,"blurb":807,"button":808,"secondaryButton":813},"Beginne noch heute, schneller zu entwickeln","Entdecke, was dein Team mit der intelligenten Orchestrierungsplattform für DevSecOps erreichen kann.\n",{"text":809,"config":810},"Kostenlosen Test starten",{"href":811,"dataGaName":50,"dataGaLocation":812},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/de-de/","feature",{"text":52,"config":814},{"href":54,"dataGaName":55,"dataGaLocation":812},1777493602578]