Container 101 (3): Volumes, Umgebungsvariablen & Portfreigaben
Volumes: Daten, die bleiben
Der wichtigste Aha-Moment beim Einstieg: Ein Container vergisst alles, wenn er neu startet. Alles, was während der Laufzeit im Container geschrieben wird – Datenbankinhalte, hochgeladene Dateien, Logs – ist weg, sobald der Container ersetzt oder neu gestartet wird. Und das passiert bei jedem Deployment.
Das ist kein Bug, sondern Prinzip: Container sollen austauschbar und wegwerfbar sein. Aber manche Daten müssen natürlich bleiben.
Ein Volume ist ein Speicherbereich, der unabhängig vom Container existiert und in ihn „eingehängt" wird. Schreibt die Anwendung dorthin, landen die Daten im Volume und bleiben, auch wenn der Container verschwindet.
Was ins Volume gehört: Datenbanken, Uploads, alles was zur Laufzeit entsteht und überleben muss.
Was nicht: dein Code (steckt im Image) und Zugangsdaten (dazu gleich).
Umgebungsvariablen: Konfiguration ohne den Code anzufassen
Ein Grundgedanke von Containern: Du baust das Image einmal und lässt es überall laufen: lokal, Test, Produktion. Aber die Einstellungen unterscheiden sich (andere Datenbank, andere URLs, andere Zugangsdaten). Stünden die fest im Code, bräuchtest du pro Umgebung ein eigenes Image und der Vorteil wäre dahin.
Die Lösung: Umgebungsvariablen – Name-Wert-Paare, die du dem Container beim Start von außen mitgibst:
DATABASE_HOST=db.example.com
DATABASE_PASSWORD=••••••••
NODE_ENV=productionDer Code liest nur den Namen (process.env.DATABASE_HOST in Node.js, getenv('DATABASE_HOST') in PHP) – den Wert bekommt er erst beim Start gereicht.
Der wichtigste Punkt – Secrets gehören hier rein, nie in Git: Passwörter und API-Keys dürfen niemals im Code oder Image landen. Der Code enthält nur den Variablennamen, den Wert verwaltet die Hosting-Plattform getrennt. So kann derselbe Code öffentlich liegen, ohne dass je ein Geheimnis mitwandert.
Volume vs. Umgebungsvariable – kurz abgegrenzt:
- Volume: Daten, die entstehen und bleiben müssen.
- Umgebungsvariable: Konfigurationswerte, die beim Start feststehen.
Für Agenturen wichtig: Keine Zugangsdaten im Repository – ohne Ausnahme. Test bekommt nie die Produktions-Datenbank. Und: eine Liste der benötigten Variablen (ohne Werte!) ins Projekt legen, damit ein neues Setup kein Ratespiel wird.
Portfreigaben: Wie Anfragen den Container erreichen
Dein Container läuft, aber im Browser kommt nichts an. Sehr oft sind Ports schuld.
Ein Port ist eine nummerierte „Tür", über die ein bestimmter Dienst erreichbar ist (80 = HTTP, 443 = HTTPS, 3306 = MySQL). Ein Container ist nach außen abgeschottet: Ein Dienst, der innen auf Port 3000 lauscht (typisch für Node.js), ist von außen erstmal nicht erreichbar. Das ist Absicht und gut für die Sicherheit.
Eine Portfreigabe (Port Mapping) verbindet außen mit innen: „Anfragen, die außen ankommen, leite an Port 3000 innerhalb des Containers." Du gibst nur frei, was wirklich von außen erreichbar sein soll.
- Freigeben: den Web-Port deiner Anwendung.
- Nicht freigeben: interne Dienste wie die Datenbank – die soll nur dein App-Container erreichen, nicht das halbe Internet.
Gut zu wissen: Im managed Container Hosting nimmt dir die Plattform den größten Teil ab. Beim mittwald Container Hosting wird HTTPS-Traffic erreichbar, indem du eine Domain auf den Container-Port schaltest. Um Zertifikate und die öffentliche Erreichbarkeit kümmert sich die Plattform. Das Freigeben anderer Ports nach außen ist aktuell noch in Arbeit (Feature Request #293).
Zusammenspiel von Volume, Umgebungsvariablen und Portfreigabe
Am Beispiel eines typischen Web-Projekts:
- Volume → die Datenbank-Daten und Uploads bleiben erhalten.
- Umgebungsvariablen → Datenbank-Zugang und Schalter kommen sauber von außen.
- Portfreigabe → der Web-Port ist erreichbar, die Datenbank bleibt zu.
Hast du diese 3 verstanden, kannst du fast jeden Standard-Container (z. B. n8n, eine Next.js-App oder eine alte PHP Anwendung) sinnvoll betreiben.
Häufige Fragen zu Volume, Umgebungsvariablen und Portfreigabe
Warum verliert ein Docker Container seine Daten?
Weil ein Container bei jedem Neustart in seinen Ursprungszustand zurückfällt. Alles, was zur Laufzeit entsteht, ist weg. Damit Datenbanken, Uploads oder Logs bleiben, hängst du ein Volume ein: einen Speicherbereich, der unabhängig vom Container existiert und den Neustart übersteht.
Warum ist mein Docker Container im Browser nicht erreichbar?
Meist fehlt die Portfreigabe. Ein Container ist nach außen abgeschottet. Ein Dienst, der innen z. B. auf Port 3000 lauscht, ist von außen erst erreichbar, wenn du diesen Port nach außen mappst. Freigeben solltest du nur den Web-Port deiner Anwendung. Interne Dienste wie die Datenbank bleiben zu.
Warum gehören Passwörter nicht in den Code?
Weil derselbe Code überall laufen soll, auch öffentlich. Zugangsdaten dürfen deshalb nie im Code oder Image landen, sondern kommen als Umgebungsvariablen von außen: Der Code enthält nur den Variablennamen, den Wert verwaltet die Hosting-Plattform getrennt. So wandert kein Geheimnis mit.
Was ist der Unterschied zwischen Volume und Umgebungsvariable?
Ein Volume speichert Daten, die zur Laufzeit entstehen und bleiben müssen (Datenbank, Uploads). Eine Umgebungsvariable liefert Konfigurationswerte, die beim Start feststehen (Adresse der Datenbank, Zugangsdaten, Schalter). Kurz: Volume = Daten, die bleiben; Umgebungsvariable = Einstellungen, die reinkommen.
Wie geht’s weiter?
- Vom Root-Server zu managed Container Hosting – wer deine Container betreibt, absichert und aktuell hält.
- Container & Docker – zurück zu den Grundlagen.
Kommentar hinzufügen