Technologie · Infrastruktur

Docker — vom Entwicklungsrechner bis in den Betrieb

Docker löst ein Problem, das jedes Team kennt: Auf dem einen Rechner läuft das Projekt, auf dem anderen nicht. Wir containerisieren Entwicklungsumgebungen, damit PHP-Version, Datenbank und Suchindex überall identisch sind — und betreiben eigene Anwendungen in Containern auf unserer Proxmox-Infrastruktur. Was Docker nicht leistet: aus einer unklaren Architektur eine klare machen.

Standard in Entwicklung und Betrieb

Was ist Docker?

Container machen ein Setup reproduzierbar — ein Architekturproblem lösen sie nicht.

Wofür wir Docker einsetzen

In der Entwicklung: Jedes Projekt bringt seine Umgebung mit. PHP 8 in der Version, die das Projekt verlangt, dazu MariaDB, Redis und bei Bedarf Elasticsearch — beschrieben in einer Compose-Datei, die im Repository liegt. Wer neu ins Projekt kommt, startet die Umgebung und arbeitet. Das ersetzt die halbtägige Einrichtung eines lokalen Systems und die Diskussionen darüber, warum ein Fehler nur auf einem Rechner auftritt.

Im Betrieb setzen wir Container für eigene Anwendungen ein: Node.js-Dienste, Python-Werkzeuge, Schnittstellen zwischen Shop und Warenwirtschaft. Die Trennung nach Diensten ist dabei der eigentliche Gewinn. Datenbank, Cache und Suchindex laufen jeweils für sich, lassen sich einzeln aktualisieren und beeinflussen einander nicht. Klassische Shop- und CMS-Installationen betreiben wir dagegen häufig weiterhin auf einer dedizierten virtuellen Maschine — dazu unten mehr.

Wie wir mit Docker arbeiten

Ein Compose-Setup pro Projekt, versioniert im Git-Repository, mit denselben Diensten wie die Zielumgebung. Images bauen wir aus schlanken Basis-Images und pinnen Versionen fest, statt auf latest zu vertrauen — sonst ändert sich die Umgebung, ohne dass jemand etwas geändert hat. Konfiguration kommt über Umgebungsvariablen hinein, Zugangsdaten liegen nicht im Image. Datenbanken bekommen benannte Volumes, damit ein Neustart keine Daten kostet.

Gebaut und ausgerollt wird über die CI-Strecke: Tests laufen im Container, das Image wird gebaut, in eine Registry geschoben und auf der Zielmaschine gezogen. Die Zielmaschine ist bei uns in der Regel eine virtuelle Maschine im eigenen Proxmox-Cluster, Serverstandort Deutschland. Logs gehen nach außen, nicht in den Container. Und jeder Container bekommt Grenzen für Arbeitsspeicher und CPU, damit ein Ausreißer nicht den Nachbarn mitnimmt.

Grenzen und Alternativen

Container lösen kein Architekturproblem. Wer ein unklares System containerisiert, hat danach ein unklares System in Containern — nur mit mehr beweglichen Teilen. Bevor wir etwas in Container packen, klären wir, welche Dienste es überhaupt gibt, wo Zustand liegt und wie Daten fließen. Fällt diese Klärung aus, verschiebt Docker den Schmerz nur vom Server in die Build-Pipeline. Der zweite Punkt: Nicht jedes System gewinnt dabei.

Kubernetes ist für die allermeisten Mittelstandsprojekte Überbau. Ein Shop, ein CMS, ein paar Hintergrunddienste — dafür brauchen Sie keinen Cluster-Scheduler, sondern eine sauber dimensionierte Maschine. Der Betrieb von Kubernetes kostet Aufmerksamkeit, die im Projekt an anderer Stelle fehlt. Sinnvoll wird es, wenn wirklich viele Dienste zu orchestrieren sind oder mehrere Teams unabhängig ausrollen. Für einzelne TYPO3- oder Shopware-Installationen bleiben wir bei der virtuellen Maschine mit Backup und Snapshot.

Häufige Fragen

Brauchen wir Docker, wenn unser Shop stabil läuft?

Nein — ein stabil laufender Shop ist kein Grund, ihn zu containerisieren. Docker zahlt sich dort aus, wo mehrere Personen am selben System arbeiten, wo Entwicklungs- und Produktivumgebung auseinanderlaufen oder wo eine Installation nach Jahren niemand mehr sauber nachbauen kann. Läuft Ihr System, ist dokumentiert und lässt sich wiederherstellen, gibt es keinen Anlass. Der Nutzen entsteht aus Reproduzierbarkeit, nicht aus der Technik selbst.

Ist Docker im Produktivbetrieb sicher genug?

Docker läuft im Produktivbetrieb sicher, wenn die Betriebspraxis stimmt: aktuelle Basis-Images, feste Versionsstände, keine Zugangsdaten im Image, Container ohne Root-Rechte, Grenzen für Arbeitsspeicher und CPU. Unsicher wird es durch Gewohnheiten, nicht durch die Technik — Images, die seit zwei Jahren niemand neu gebaut hat, oder ein Registry-Zugang, den zu viele kennen. Wir aktualisieren Images im Rahmen der Wartung und bauen sie über die CI-Strecke neu.

Brauchen wir Kubernetes, wenn wir Docker einsetzen?

Nein, für die allermeisten Mittelstandsprojekte ist Kubernetes Überbau. Der Cluster-Scheduler orchestriert viele Dienste über viele Maschinen und verlangt dafür eigenen Betriebsaufwand: Cluster-Updates, Netzwerk, Speicher, Rechteverwaltung. Bei einem Shop, einem CMS und einer Handvoll Hintergrundprozesse übersteigt dieser Aufwand den Nutzen deutlich. Sharpness setzt in solchen Fällen auf Container auf einer klar dimensionierten virtuellen Maschine. Interessant wird Kubernetes, wenn mehrere Teams unabhängig ausrollen oder sehr viele Dienste zusammenspielen.

Docker im Bestand oder im Neubau?

Wir übernehmen auch Systeme, die woanders gebaut wurden — nach einem Blick in Code und Hosting.

Projekt anfragen 0441 21 21 63 0

Womit wir sonst arbeiten

Anrufen Projekt anfragen