Container 101 (1): Was ist ein Container? Und was ist Docker?
Was ist ein Container?
Ein Container verpackt deine Anwendung zusammen mit allem, was sie zum Laufen braucht – Code, Laufzeitumgebung, Bibliotheken, Konfiguration – in ein abgeschlossenes Paket. Dieses Paket läuft auf jedem System gleich: auf deinem Laptop, beim Testen und auf deinem Server.
Die Analogie: der Schiffscontainer
Der Name ist kein Zufall. Der genormte Schiffscontainer hat die Logistik revolutioniert: Egal ob Bananen oder Maschinenteile drin sind – die Box ist außen immer gleich und passt auf jedes Schiff, jeden LKW, jeden Kran. Software-Container machen dasselbe für Anwendungen. Egal ob eine Next.js-App, eine n8n-Instanz oder eine alte PHP-Anwendung drinsteckt: Von “außen” betrachtet, ist es ein Container, und die Infrastruktur muss nichts über den Inhalt wissen.
Das Problem, das Container lösen
„Bei mir läuft’s doch!" kennt jede Agentur. Lokal funktioniert alles, auf dem Server nicht – andere PHP-Version, fehlende Bibliothek, andere Konfiguration. Ein Container nimmt seine Umgebung mit: Was lokal im Container läuft, läuft auf dem Server genauso.
Container vs. virtuelle Maschine (vServer)
Beides isoliert Anwendungen – aber unterschiedlich:
Virtuelle Maschine / vServer
- Eigenes Betriebssystem (vollständige Linux- oder Windows-Installation)
- Vollständig von anderen VMs isoliert
- Mehr Ressourcenbedarf (RAM, Speicher, CPU)
- Startet in wenigen Minuten
Container
- Teilt sich den Kernel des Host-Betriebssystems
- Enthalten nur die Anwendung und ihre benötigten Abhängigkeiten
- Sehr ressourcenschonend und kompakt
- Startet in wenigen Sekunden
- Deutlich mehr Container auf derselben Hardware möglich
- Ideal für moderne Anwendungen, Microservices und schnelle Deployments
Faustregel: Eine VM virtualisiert einen ganzen Rechner, ein Container nur eine Anwendung.
Was ist Docker?
Kurz zur Einordnung, weil das oft durcheinandergeht:
- Container ist das Konzept – das Paket mit deiner Anwendung.
- Docker ist die Software, mit der die meisten Container gebaut und gestartet werden.
Docker hat Container für die breite Masse nutzbar gemacht. Drei Begriffe reichen für den Einstieg:
1. Dockerfile – der Bauplan. Eine simple Textdatei mit Anweisungen, wie der Container gebaut wird:
# Basis-Image: konkrete Version statt nur "26"
FROM node:26.5-slim
WORKDIR /app
# Benötigte Abhängigkeiten reinkopieren
COPY package.json package-lock.json ./
# Installation der Abhängigkeiten
RUN npm ci --omit=dev
# Danach der restliche Code
COPY . .
CMD ["npm", "start"]2. Image – das fertige Paket. Arbeitet Docker das Dockerfile ab, entsteht ein Image: die eingefrorene Vorlage deiner Anwendung.
3. Container – die laufende Instanz. Startest du ein Image, läuft daraus ein Container. Aus einem Image kannst du beliebig viele identische Container starten.
Der Bauplan liegt als Datei im Projekt und wandert mit in Git – die Umgebung ist damit versionierbar wie Code.
Die Vorteile von Containern auf einen Blick
- Gleiche Umgebung überall – kein „läuft nur bei mir".
- Schnell startklar – neue Projekte und Testumgebungen in Sekunden.
- Sauber isoliert – jedes Kundenprojekt für sich.
- Portabel & reproduzierbar – dasselbe Image läuft überall gleich.
Und wo lasse ich die Container laufen?
Container selbst zu betreiben heißt: Server aufsetzen, absichern, Updates fahren, überwachen. Das kannst du selbst übernehmen – auf einem vServer oder Dedicated Server bei mittwald – oder dir den Betrieb von einem managed Container Hosting im mStudio abnehmen lassen. Welches Modell wann sinnvoll ist (und welche Komfort-Features du dabei geschenkt bekommst), klären wir demnächst in einem eigenen Artikel.
Wie geht’s weiter?
- Image & Container Registry – woher ein Container „kommt" und wofür du eine Registry brauchst.
- Volumes, Envs & Portfreigaben – was ein Image zum laufenden, konfigurierten Container macht.
