PP
🚀 Platform Engineer Lektion 33/50 ~6 Min. Fortgeschritten

CI/CD Build Platform und Shared Infrastructure

Shared Runners, Caching, Artifact-Registry und Pipeline-Standards.

#cicd #build
📝 Meine Notizen

Lernziele

Nach dieser Lektion kannst du erklären, warum eine zentrale CI/CD Build Platform mehr ist als „wir haben GitLab Runner”, wie Shared Runners, Caching und Artifact-Registries zusammenspielen und welche Pipeline-Standards du als Plattform-Capability durchsetzt. Du kannst Build vs. Buy abwägen, Noisy-Neighbor-Risiken benennen und typische Skalierungsfehler erkennen.

Das Problem: 50 Teams, 50 Pipeline-Inseln

Jedes Stream-Team richtet sich seine CI ein: eigene Runner auf einem alten VM, Docker-in-Docker ohne Cache, Secrets als Base64 in der Pipeline-Variable, Images nach Docker Hub ohne Scanning. Montags dauert ein Build 12 Minuten, freitags 40 — weil der Shared-Laptop-Runner überlastet ist. Wenn die Registry Credentials rotiert werden, brechen 30 Pipelines gleichzeitig ab, weil niemand weiß, wo überall das alte Passwort steht.

CI/CD ist der Engpass zwischen Code und dem Environment aus Lektion 31. Eine langsame oder fragile Pipeline vernichtet jeden Gewinn aus Compute-Abstraktion und Observability: Du kannst in Sekunden deployen, aber erst nach 45 Minuten Build. Eine CI/CD Build Platform löst das, indem sie Build-Infrastruktur als Shared Service bereitstellt — mit Standards, die nicht verhandelbar sind, und Flexibilität, wo sie nötig ist.

Die vier Bausteine der Build Platform

Shared Runners sind das Herzstück. Ob GitLab Runner, GitHub Actions self-hosted, Tekton oder Jenkins-Agenten — das Prinzip ist gleich: zentrale, vom Platform-Team betriebene Execution-Umgebung statt Team-eigener Hardware. Vorteile: einheitliche Base-Images, zentrale Patches, Skalierung per Autoscaler (Karpenter, Cluster Autoscaler). Risiko: Noisy Neighbor — ein Team mit 200 parallelen Jobs verdrängt alle anderen. Deshalb: Concurrency-Limits pro Team, Resource-Quotas auf Runner-Pods und separate Runner-Pools für schwere Builds (GPU, große Maven-Repos).

Remote Caching entscheidet über Build-Zeit. Ohne Cache lädt jeder Job Dependencies neu — npm, Maven, Go-Module, Docker-Layer. Ein zentraler Cache (S3-kompatibel, Registry-Cache, dedizierter Buildkit-Cache) reduziert Builds von Minuten auf Sekunden. Die Plattform stellt den Cache bereit und dokumentiert, wie Teams ihn anbinden; sie erzwingt ihn im Golden-Path-Template.

Artifact-Registry ist mehr als Image-Storage. Sie hält Container-Images, Helm-Charts (OCI), Build-Artefakte (JARs, Binaries) und — wenn konfiguriert — SBOMs und Signatures. Eine Registry pro Organisation mit RBAC, Vulnerability-Scanning und Retention-Policies ersetzt zehn Team-Registries mit unterschiedlichen URLs und Auth-Mechanismen. GitOps aus Lektion 30 zieht Images und Charts aus derselben Registry — ein Ausfall stoppt Build und Deploy.

Pipeline-Standards sind der unterschätzte vierte Baustein. Nicht jeder Schritt muss identisch sein, aber bestimmte Stufen sind Pflicht: Lint, Test, Build, Image-Push, Vulnerability-Scan, Signierung. Das Platform-Team liefert wiederverwendbare Pipeline-Templates (GitLab include, GitHub Reusable Workflows, Tekton Tasks) — Teams fügen nur Service-spezifische Schritte ein. Secrets kommen aus dem Vault-Service (Lektion 34), nicht aus Klartext-Variablen.

Golden Path Pipeline vs. Custom Pipeline

Der Golden Path ist ein Pipeline-Template, das für 80 % der Services reicht:

# Vereinfachtes Golden-Path-Muster — konkrete Syntax je nach CI-System
stages: [lint, test, build, scan, push, deploy-trigger]
build:
  image: $PLATFORM_BUILD_IMAGE
  cache: $PLATFORM_CACHE_CONFIG
  script: [make build]
scan:
  script: [trivy image --exit-code 1 $IMAGE]
push:
  script: [crane push $IMAGE $REGISTRY/$TEAM/$SERVICE:$TAG]

Teams liefern Makefile oder Build-Skript, nicht die gesamte Pipeline-Infrastruktur. Custom Pipelines sind erlaubt — aber nur mit dokumentierter Begründung und ohne Bypass von Scan- und Sign-Schritten. Wer den Security-Gate umgeht, deployt nicht.

Skalierung und Isolation

Shared Infrastruktur skaliert nur mit bewusster Isolation:

  • Runner-Pools nach Workload-Typ: Leichte Node.js-Builds auf Spot-Instanzen, schwere Java-Builds auf On-Demand mit mehr RAM.
  • Namespace-Isolation der Runner: Jeder Job läuft in einem ephemeral Pod mit begrenzten Rechten — kein Zugriff auf den Host, kein privilegierter Modus.
  • Netzwerk-Policies: Runner erreichen Registry und Cache, aber nicht Produktions-Cluster direkt. Deploy passiert über GitOps, nicht über kubectl aus der Pipeline.
  • Observability der Pipeline selbst: Build-Dauer, Queue-Länge, Fehlerrate pro Team — Metriken, die du in Lektion 32 als SLI-Kandidaten kennst.

Praxis: Build-Zeit vor und nach Platform-Migration

Nimm einen realen Service mit einem typischen Build (Docker-Image, drei Minuten Dependency-Download bei jedem Lauf):

  1. Baseline messen: Aktuelle Build-Zeit, Cache-Hit-Rate (meist 0 %), Anzahl paralleler Jobs im Peak.
  2. Auf Shared Runner umstellen: Golden-Path-Template einbinden, Team-Secrets in Vault migrieren.
  3. Remote Cache aktivieren: Docker-Layer-Cache und Dependency-Cache konfigurieren — zweiter Build-Lauf sollte unter 60 Sekunden liegen.
  4. Scan-Gate prüfen: Absichtlich ein Image mit bekannter CVE bauen — Pipeline muss fehlschlagen, bevor Push.
  5. Metriken aufsetzen: Dashboard mit p50/p95 Build-Dauer und Queue-Wartezeit pro Team.

Der Vergleich vorher/nachher ist dein stärkstes Argument gegenüber Skeptikern, die „ihre eigene Pipeline schneller” finden.

Typische Stolperfallen

Docker-in-Docker ohne Cache: Jeder Build zieht die Base-Image-Layer neu. Lösung: Kaniko oder Buildkit mit Registry-Cache — nicht DinD auf DinD.

Secrets in CI-Variablen: Base64 ist keine Verschlüsselung. Rotation wird zum Albtraum. Secrets gehören in Vault mit kurzlebigen Tokens.

Kein Concurrency-Limit: Ein Team startet 500 Jobs, alle anderen warten. Per-Team-Limits sind Pflicht, nicht Kür.

Registry als Afterthought: Ohne zentrale Registry hast du Images auf Docker Hub, ghcr.io und einer internen Harbor-Instanz — Scanning und Retention sind unmöglich.

Pipeline-Drift: Teams kopieren das Template einmal und pflegen es nie. Zentrale include-Mechanismen mit Version-Pinning halten alle auf dem aktuellen Security-Stand.

Interview-Vorbereitung

Auf „Wie würdest du eine CI/CD Build Platform aufbauen?” antwortest du: Problem (Pipeline-Inseln, langsame Builds, Secret-Chaos) → Bausteine (Shared Runners, Remote Cache, zentrale Registry, Pipeline-Templates) → Guardrails (Scan-Gates, Concurrency-Limits, kein Deploy aus der Pipeline) → Metriken (Build-Dauer, Queue, Fehlerrate als Platform-SLI).

Follow-ups:

  • „Build vs. Buy?” — Managed (GitHub Actions, GitLab SaaS) für kleine Orgs; self-hosted wenn Compliance, Netzwerk-Isolation oder Kosten bei Scale es erfordern.
  • „Wie isolierst du Teams auf Shared Runners?” — Ephemeral Pods, RBAC, Namespace-Quotas, separate Pools.
  • „Was passiert, wenn die Registry ausfällt?” — Kein Build, kein Deploy; deshalb HA, Replikation und Pull-Through-Cache — und ein SLO.

Zusammenfassung

Die CI/CD Build Platform zentralisiert Runner, Caching, Registry und Pipeline-Standards als Shared Capability. Teams nutzen Golden-Path-Templates mit eingebauten Security-Gates; das Platform-Team skaliert und betreibt die Infrastruktur. Remote Caching und Concurrency-Limits sind keine Optimierung, sondern Voraussetzung für Shared Infrastructure. Ohne zentrale Registry und Secret-Integration (Vault) bleibt die Pipeline das schwächste Glied zwischen Code und Production.

In der nächsten Lektion sichern wir die Identität hinter all diesen Pipelines und Deployments: SSO, Secrets-Management und Workload Identity als Plattform-Service.