Artifact Registry

Bekannte Beispiele:

• Docker Hub: Öffentliche Registry für Container.
• JFrog Artifactory / Sonatype Nexus: Der Industriestandard (On-Premise).
• AWS ECR / Google Artifact Registry: Cloud-Lösungen.

In der CI/CD-Pipeline:

1. Build: Der CI-Server kompiliert den Code (npm build).
2. Push: Er lädt das Ergebnis hoch (docker push my-registry.com/app:v1).
3. Deploy: Der Produktionsserver lädt es runter (docker pull my-registry.com/app:v1).

1. Proxy & Caching

Firmen wollen nicht, dass jeder Entwickler npm install react direkt aus dem Internet lädt.

1. Sicherheit: Was, wenn jemand das Paket löscht (Left-Pad Incident)?

   Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Bekannte Beispiele: Docker Hub: Öffentliche Registry für Container. JFrog Artifactory / Sonatype Nexus: Der Industriestandard (On-Premise). AWS ECR / Google Artifact Registry: Cloud-Lösungen.
2. Performance: Internet ist langsam. Die Artifact Registry fungiert als Proxy. Der Entwickler fragt die interne Registry. Die Registry lädt es einmal von npmjs.org und cached es. Alle weiteren Requests kommen aus dem Cache. "Golden Source of Truth".

2. Immutable Tags & Layers

In Docker Registries werden Images in Layern gespeichert (Content Addressable Storage). Wenn 10 Images alle auf ubuntu:latest basieren, speichert die Registry den Ubuntu-Layer nur einmal (Deduplizierung). Das spart Terabytes an Speicher. Wichtig: Immutability. Ein Tag v1.0.0 darf niemals überschrieben werden. Wenn du den Code änderst, musst du v1.0.1 bauen. Sonst weißt du nie, was in Produktion läuft.

3. Vulnerability Scanning

Moderne Registries (Harbor, AWS ECR) scannen Artefakte automatisch. Sobald du ein Image hochlädst, prüft ein Scanner die Datenbank auf CVEs (Sicherheitslücken). "Achtung: Dein Image enthält openssl in einer Version mit kritischer Lücke." -> Deployment Block.

Content Addressable Storage (CAS)

Eine moderne Artifact Registry (wie Docker Registry V2) speichert Images nicht als monolithische Dateien, sondern nutzt Content Addressable Storage. Wenn du einen Layer hochlädst, berechnet die Registry den SHA256-Hash des Inhalts. Dieser Hash wird der Dateiname. Das bedeutet: Wenn Team A und Team B exakt dieselbe node:18 Base-Layer nutzen, liegt diese physikalisch nur ein einziges Mal auf der Festplatte des Servers (/blobs/sha256/a1b2c3...). Das Manifest (die "Stückliste" des Images) verweist nur noch auf die Hashes der Layer. Das macht Registries extrem speichereffizient, erfordert aber Garbage Collection, um "verwaiste" Blobs später aufzuräumen.

Software Supply Chain: Signaturen & Provenance

Ein Image in der Registry zu scannen reicht heute oft nicht mehr ("SolarWinds Attacke"). Woher weißt du, dass das hochgeladene Image wirklich von deiner CI-Pipeline gebaut wurde und nicht von einem Hacker, der API-Keys gestohlen hat? Hier kommen Tools wie Cosign (Sigstore) ins Spiel. Die CI-Pipeline baut das Image, signiert es kryptografisch mit einem kurzlebigen Key (gebunden an die OIDC-Identität des CI-Runners) und pusht Image sowie Signatur in die Artifact Registry. Beim Deployment prüft der Kubernetes Admission Controller (z.B. Kyverno) in der Registry, ob die Signatur gültig ist. Fehlt sie, wird der Start des Containers knallhart verweigert.

OCI Artifacts (Mehr als nur Docker)

Früher war der Docker Hub nur für Docker-Images. Heute ist der Standard die OCI (Open Container Initiative) Registry. Diese Registries sind generisch genug gebaut, dass sie alles speichern können. Du kannst Helm Charts (Kubernetes-Pakete), Terraform Module oder sogar normale kompilierte Binaries (WASM) als "OCI Artifact" in AWS ECR oder Google Artifact Registry pushen. Die Registry fungiert dann als universeller "Single Point of Truth" für jegliche gebaute Software.