Container 101 (2): So hängen Image und Registry zusammen

Ein Image ist die fertige, eingefrorene Vorlage deiner Anwendung. Es enthält alles, was der Container zum Laufen braucht: das Grundgerüst, die Laufzeitumgebung (z. B. Node.js oder PHP), deine Bibliotheken und deinen Code. 

Der Unterschied zum Container: 

• Das Image ist die Vorlage – statisch, unveränderlich, gespeichert. 
• Der Container ist die laufende Instanz, die aus dem Image gestartet wird. 

Vergleich: Das Image ist der Bauplan und die vorgefertigten Teile, der Container das fertig aufgebaute Haus. Aus einem Image kannst du beliebig viele identische Container starten. 

Ein Image fängt selten bei null an. Es basiert fast immer auf einem Basis-Image – etwa node:26, php:8.5 oder nginx:latest. Darauf legst du nur noch deine projektspezifischen Schichten (Code, Konfiguration). Das spart Arbeit und sorgt dafür, dass Tausende Projekte auf bewährten, gepflegten Grundlagen aufsetzen. 

Eine Registry ist das Lager bzw. der Umschlagplatz für Images. Du baust ein Image lokal oder in einer Pipeline, lädst es in die Registry hoch (push) – und der Server, auf dem es laufen soll, lädt es von dort wieder herunter (pull). 

Die bekannteste öffentliche Registry ist Docker Hub. Dort liegen auch die offiziellen Basis-Images. Für eigenen, nicht-öffentlichen Code nutzt man eine private Registry – z. B. die in GitLab oder GitHub integrierte. 

• Öffentliche Registry: ideal für Basis-Images und Open-Source-Software (z. B. das offizielle n8n-Image). 
• Private Registry: für deinen Kundencode, der nicht öffentlich sein soll. Zugriff nur mit Login. 

So sieht der typische Weg eines Images aus: 

1. Bauen: Aus dem Dockerfile entsteht per docker build ein Image. 
2. Hochladen: docker push legt es in einer Registry ab. 
3. Herunterladen: Der Zielserver holt es per docker pull. 
4. Starten: Aus dem Image wird ein laufender Container. 

In der Praxis automatisiert eine CI/CD-Pipeline die Schritte 1–3: Du pushst Code nach GitLab/GitHub, die Pipeline baut das Image und legt es in der Registry ab – fertig fürs Deployment. 

Der konkrete Nutzen für Agenturen: 

• Wiederholbare Auslieferung: Genau das Image, das ihr getestet habt, geht in Produktion – kein erneutes Bauen in der Hoffnung, dass dasselbe herauskommt. 
• Versionierung & Rollback: Images bekommen Tags (z. B. v1.4.0). Ein Rollback heißt dann einfach: das vorherige Image wieder starten. 
• Trennung von Code und Auslieferung: Code liegt in Git, das auslieferbare Artefakt in der Registry. 

Beim mittwald Container Hosting kannst du jede beliebige Container Registry hinterlegen – egal ob öffentlich oder privat. Private Registries bindest du einfach über Zugangsdaten an. Docker Hub und GitHub sind dabei im Standard bereits hinterlegt, sodass du deren Images sofort nutzen kannst. 

Klingt nach viel Handarbeit? Geht auch einfacher: Die zerodeploy-action fürs mittwald Container Hosting erkennt deinen Anwendungscode und baut daraus automatisch das passende Image – zero config, ganz ohne selbst geschriebenes Dockerfile. 

• Volumes, Envs & Portfreigaben – was ein Image zum laufenden, konfigurierten Container macht.