Docker — isolierte Container für stabile Websites
Die gesamte Plattform 4buildsite — der Editor, die API, die Rendering-Engine und der Dienst, der die veröffentlichten Websites ausliefert — läuft in Docker-Containern: isolierten Paketen, die alles enthalten, was der jeweilige Dienst braucht. Ihre Website wird statisch gerendert und als vollständige Version ausgeliefert, die bei jeder Veröffentlichung atomar umgeschaltet wird. Das Ergebnis, allgemein verständlich: Wenn etwas nicht stimmt, kehren Sie in Sekunden zur vorherigen Version zurück.
Was ein Container ist — und warum er für Ihre Website zählt
Ein Container ist ein standardisiertes Paket, das die Anwendung und alles enthält, was sie zum Laufen braucht: Runtime, Bibliotheken, Konfiguration. Der Container läuft isoliert vom übrigen Server, nutzt aber direkt den Linux-Kernel des Hosts — ohne ein eigenes Betriebssystem je Anwendung. Docker, 2013 veröffentlicht, hat diese Technologie in einen zugänglichen Standard verwandelt; das Image-Format ist heute als OCI (Open Container Initiative) standardisiert und läuft auf jedem Linux-Server und in jeder Cloud identisch.
Die klassische Analogie ist der Seecontainer: Was immer er transportiert, er hat stets dieselbe genormte Form und lässt sich auf jedes Schiff, jeden Zug und jeden Lkw verladen. Ebenso sind die Dienste von 4buildsite, die Ihre Website bauen und ausliefern — der Editor, die FastAPI-API, die Rendering-Engine — in Standard-Images verpackt, die auf dem Testserver genauso laufen wie in der Produktion. Für Sie als Website- oder Shopbetreiber bedeutet das Berechenbarkeit: Was Sie in der Vorschau gesehen haben, ist genau das, was Ihre Besucher bekommen.
- Container = die Anwendung und ihre Abhängigkeiten, in einem einzigen isolierten Paket
- Standardformat OCI — dasselbe Image läuft auf jedem Server und in jeder Cloud
- Kein eigenes Betriebssystem je Dienst — Start in Sekunden, nicht in Minuten
- Auf 4buildsite übernimmt die Plattform die Containerisierung — Sie veröffentlichen nur
Isolation: Ihre Website hängt nicht von den Nachbarn ab
Auf klassischem Shared Hosting teilen sich Hunderte Websites denselben Server, dieselben Prozesse und oft dieselbe PHP-Installation. Erhält ein Nachbar eine Trafficwelle oder frisst ein schlecht geschriebenes Skript den gesamten Prozessor, wird Ihre Website langsamer — das Phänomen des „lauten Nachbarn“. 4buildsite geht das Problem von zwei Seiten an. Erstens: Veröffentlichte Websites werden statisch gerendert — auf den ausliefernden Servern läuft kein Code je Website (PHP, Plugins, Skripte), es gibt also kein schlecht geschriebenes Nachbarskript, das den Prozessor auslastet. Zweitens: Die Plattformdienste laufen jeweils in ihrem eigenen Container, mit getrennten Prozessen und Dateien (über Namespaces) und mit der Möglichkeit von CPU- und Speichergrenzen (über cgroups, die Mechanismen des Linux-Kernels).
Isolation zählt ebenso sehr für die Sicherheit. Auf Shared Hosting kann eine kompromittierte Website zum Einfallstor für die Nachbarwebsites auf demselben Server werden. Auf 4buildsite ist die veröffentlichte Website ein Satz statischer Dateien — es läuft kein Code, der über Plugins oder Themes kompromittiert werden könnte — und die Plattformdienste, die Daten verarbeiten (Bestellungen, Zahlungen, Editor), liegen in getrennten Containern: Das Dateisystem ist isoliert, und ein etwaiger Zwischenfall bleibt im jeweiligen Container eingeschlossen.
- Veröffentlichte Website = statische Dateien — null Code je Website, der kompromittiert werden könnte
- Plattformdienste: getrenntes Dateisystem und getrennte Prozesse je Container
- Statische Auslieferung der veröffentlichten Version
Überall dieselbe Version: kein „bei mir läuft es, live nicht“
Die häufigste Fehlerquelle im klassischen Web ist der Unterschied zwischen der Umgebung, in der die Website getestet wurde, und dem Server, auf dem sie live läuft: eine andere Sprachversion, eine fehlende Erweiterung, eine abweichende Konfiguration. Ein Docker-Image beseitigt diese ganze Fehlerklasse: Das Image wird ein einziges Mal gebaut, mit allen Abhängigkeiten fixiert, und genau dasselbe Artefakt läuft im Test und in der Produktion. Es gibt kein „auf dem Server von Hand konfiguriert“.
Für Sie übersetzt sich das unmittelbar in Stabilität. Wenn Sie die Website im visuellen Editor unter panel.4buildsite.net ändern und auf Veröffentlichen klicken, hat die Version, die bei den Besuchern ankommt, jedes Mal dieselben Schritte und dieselben containerisierten Dienste durchlaufen. Weniger Überraschungen nach der Veröffentlichung — und für einen Onlineshop bedeutet jede Ausfallstunde verlorene Bestellungen.
Veröffentlichungen mit Rollback in Sekunden
Auf 4buildsite bedeutet eine Veröffentlichung nicht „Website anhalten, Dateien kopieren, hoffen“. Jede Veröffentlichung erzeugt eine neue, vollständige Version Ihrer Website — statisch gerendert, getrennt von der derzeit aktiven — und die Umschaltung darauf erfolgt atomar: In einem einzigen Vorgang beginnt der Auslieferungsdienst, die neue Version zu servieren. Dasselbe Prinzip gilt für die Plattformdienste: Die neue Version eines Containers startet neben der alten und übernimmt den Verkehr erst nach den Health Checks.
Ebenso wichtig ist der Weg zurück. Jede veröffentlichte Version der Website bleibt unversehrt erhalten, sodass die Rückkehr zur vorherigen Version schlicht ein Zurückschalten ist — eine Sache von Sekunden, keine stundenlange Wiederherstellung aus dem Backup. Führt eine Veröffentlichung ein Problem ein, bleibt Ihr Shop nicht auf der fehlerhaften Version hängen. Die einzige ehrliche Einschränkung: Die Daten (Bestellungen, Produkte, Inhalte) leben in der Datenbank, getrennt von den veröffentlichten Versionen — deshalb werden sie auf persistenten Volumes verwaltet, getrennt von den Dateien der Website.
- Jede Veröffentlichung = eine neue, vollständige Version, atomar umgeschaltet
- Rollback = Zurückschalten auf die vorherige Version, in Sekunden
- Sie veröffentlichen Änderungen jederzeit, auch mitten in der Verkaufssaison
Effizienz und Kosten: mehr Leistung für dasselbe Geld
Eine klassische virtuelle Maschine betreibt für jede Anwendung ein komplettes Betriebssystem — Gigabytes an Arbeitsspeicher und Minuten Startzeit, die allein für die „Verpackung“ draufgehen. Container teilen sich den Kernel des Hosts, sodass auf denselben Server weit mehr Websites passen, jede mit ihrer eigenen Isolation. Diese Dichte ist der Grund, warum 4buildsite Hosting und SSL im Abo enthalten kann, ohne separate Infrastrukturkosten je Website.
Für Ihre veröffentlichte Website ist die Skalierung bei Traffic noch einfacher: Da es sich um statische Dateien handelt, ist ihre Auslieferung extrem günstig — eine Besucherspitze bedeutet mehr ausgelieferte Dateien, nicht zusätzliche Prozesse, die einander in die Quere kommen. Und die Plattformdienste können als Container, die in Sekunden starten, bei Bedarf zusätzliche Instanzen erhalten. Sie zahlen ein berechenbares Abo statt einer Infrastruktur, die dauerhaft auf den geschäftigsten Tag des Jahres ausgelegt ist. Wie wir diese Container tatsächlich betreiben — Orchestrierung, Proxy, CI/CD, Monitoring — lesen Sie auf der Seite Cloud & DevOps.
Vorteile und Grenzen
Vorteile
- Die veröffentlichte Website wird statisch ausgeliefert, und die Plattform läuft in isolierten Containern — ein überlasteter oder kompromittierter Nachbar berührt sie nicht.
- Dieselben Plattform-Images im Test und in der Produktion — kein „bei mir läuft es, live nicht“.
- Veröffentlichungen: Die neue Version der Website wird separat erzeugt und atomar umgeschaltet.
- Sofortiges Rollback auf die zuvor veröffentlichte Version, falls eine Änderung nicht funktioniert.
- Container starten in Sekunden — die Plattformdienste skalieren bei Trafficspitzen.
- Hohe Dichte je Server — Hosting im Abo enthalten, ohne separate Kosten.
Grenzen
- Die Isolation nutzt den geteilten Kernel des Hosts — schwächer als die Hardware-Isolation einer dedizierten virtuellen Maschine.
- Der Container ist flüchtig: Persistente Daten (Datenbank, hochgeladene Dateien) verlangen separat verwaltete Volumes und Backups.
- Images und ihre Layer belegen Speicherplatz — ohne regelmäßiges Aufräumen sammeln sie sich an.
- Für Teams, die es selbst administrieren, hat Docker eine echte Lernkurve — auf 4buildsite übernimmt das vollständig die Plattform.
Kurzes Fazit
Die Containerisierung mit Docker ist der De-facto-Industriestandard für den Betrieb von Webanwendungen: Isolation, Übereinstimmung von Test und Produktion und sofortiges Rollback. Auf 4buildsite läuft die Plattform, die Ihre Website baut und ausliefert, containerisiert, und die Veröffentlichungen Ihrer Website sind versioniert, werden atomar umgeschaltet und lassen sich in Sekunden zurücknehmen — wie die Infrastruktur betrieben wird (Orchestrierung, Proxy, CI/CD), beschreibt die Seite Cloud & DevOps.
Technische Daten
| Fähigkeit | Grenze / Schwelle | Typischer Einsatz | |
|---|---|---|---|
| Ressourcenisolation | CPU-/RAM-Grenzen je Container (cgroups, Namespaces) | Geteilter Kernel — keine Hardware-Isolation wie bei einer VM | Websites und Shops auf geteilter Infrastruktur |
| Start / Deployment | Der Container startet in Sekunden | Der erste Download des Images dauert länger | Häufige Veröffentlichungen und Updates |
| Rollback | Rückkehr zu jedem früheren Image in Sekunden | Die Daten in der Datenbank werden nicht mit dem Image zurückgerollt | Sofortige Rückkehr, wenn ein Update nicht funktioniert |
| Portabilität | OCI-Image — läuft auf jedem Linux-Host und in jeder Cloud | Images sind architekturgebunden (x86/ARM) | Umzug zwischen Servern, ohne die Anwendung neu zu schreiben |
| Dichte / Kosten | Dutzende isolierter Container auf einem einzigen Server | Alle teilen sich Kernel und Festplatte des Hosts | Geringe Kosten je Website — Hosting im Abo enthalten |
Docker, virtuelle Maschinen und Shared Hosting (cPanel) im Vergleich
| Kriterium | Docker (Container) | Virtuelle Maschinen | Shared Hosting (cPanel) |
|---|---|---|---|
| Isolation | Je Container (Prozesse, Dateien, Ressourcen) | Vollständig (virtualisierte Hardware) | Schwach — Hunderte Websites auf demselben Server |
| Start- und Deployment-Geschwindigkeit | Sekunden | Minuten (vollständiger Betriebssystemstart) | Änderungen direkt auf dem Live-Server (FTP) |
| Ressourcenverbrauch | Minimal — kein eigenes Betriebssystem je Anwendung | Hoch — ein komplettes Betriebssystem je Maschine | Gering, aber unkontrolliert unter den Nachbarn geteilt |
| Rollback | Sofort — Sie starten das vorherige Image neu | Aus einem Snapshot — langsamer | Manuell, aus dem Backup |
| Sicherheit | Ein Zwischenfall bleibt auf den Container begrenzt | Die stärkste Isolation | Eine kompromittierte Website kann die Nachbarn beeinträchtigen |
| Kosten je Website | Gering — hohe Dichte auf dem Server | Hoch — Sie zahlen die ganze Maschine | Sehr gering, aber unberechenbare Leistung |
Häufige Fragen
Beeinträchtigt Docker die Geschwindigkeit meiner Website?
Nein. Container laufen nativ auf dem Linux-Kernel, ohne eine Schicht Hardwarevirtualisierung, der Mehraufwand ist also vernachlässigbar. Die Geschwindigkeit der Website ergibt sich aus Code, Cache und Netzwerk — und die Ressourcenisolation macht sie sogar berechenbarer als auf Shared Hosting.
Warum kein klassisches Hosting mit cPanel, wie bei WordPress?
Auf klassischem Shared Hosting teilen sich Hunderte Websites denselben Server ohne strikte Grenzen: Ein überlasteter Nachbar bremst Sie aus, ein kompromittierter kann Sie in Mitleidenschaft ziehen. Auf 4buildsite wird die veröffentlichte Website statisch ausgeliefert — es läuft kein Code je Website, der kompromittiert werden könnte — und die Plattformdienste laufen isoliert in Containern, mit atomar umgeschalteten Veröffentlichungen. Dinge, die cPanel nicht bietet.
Was passiert, wenn eine Veröffentlichung meine Website beschädigt?
Die zuvor veröffentlichte Version besteht weiterhin unversehrt, die Rückkehr dauert also Sekunden: Der Auslieferungsdienst schaltet einfach auf sie zurück. Der Shop bleibt nicht auf einer fehlerhaften Version hängen, und die Daten in der Datenbank bleiben unberührt.
Muss ich Docker beherrschen, um 4buildsite zu nutzen?
Nein. Die Containerisierung übernimmt vollständig die Plattform: Sie bauen die Website im visuellen Editor unter panel.4buildsite.net und veröffentlichen. Docker arbeitet „unter der Haube“ — die Vorteile (Isolation, Rollback) erhalten Sie ohne jede Konfiguration.
Ist Docker für einen Onlineshop sicher?
Ja. Die Isolation von Prozessen und Dateien begrenzt die Reichweite eines etwaigen Zwischenfalls auf den jeweiligen Container statt auf den ganzen Server. Kartendaten laufen ohnehin nicht durch den Container — die Zahlungen werden von Stripe auf der zertifizierten Stripe-Infrastruktur verarbeitet.
Ist Docker dasselbe wie eine virtuelle Maschine?
Nein. Eine virtuelle Maschine virtualisiert die komplette Hardware und betreibt ein eigenes Betriebssystem — sie startet in Minuten und verbraucht viel. Ein Container teilt sich den Kernel des Hosts: Er startet in Sekunden, verbraucht einen Bruchteil der Ressourcen und wahrt die Isolation der Anwendung.