5 teure Fehler beim Deployen von Docker Containern (und wie du sie wie ein Profi vermeidest 😎)

Docker ist ein großartiges Tool für das Deployment von Webanwendungen, aber nur, wenn du es richtig einsetzt. Es gibt viele Möglichkeiten, sich selbst ins Knie zu schießen. Wenn du dir also schmerzhafte Debugging-Stunden ersparen willst, solltest du diese häufigen Fehler vermeiden.

Nebenbei bemerkt: Wenn du dir das Leben etwas leichter machen möchtest, schau dir sliplane.io an. Es ist eine einfache Docker-Hosting-Lösung, die dir hilft, einige der hier genannten Fallstricke zu vermeiden.

1. Keine Ressourcen-Limits setzen ❌

Dieser Punkt ist besonders wichtig, wenn du mehrere Container auf einem einzigen Server laufen lässt. Ressourcenhungrige Services können die gesamte CPU oder den gesamten Speicher deiner Maschine beanspruchen und anderen Containern keine Ressourcen mehr übrig lassen – oder im schlimmsten Fall den gesamten Server einfrieren.

Verwende die Flags --cpu-quota und --memory, um die Ressourcennutzung deiner Container zur Laufzeit zu begrenzen:

docker run --memory="512m" --cpu-quota=50000 dein-image-name

Weitere Informationen zu diesen Flags findest du in der offiziellen Docker-Dokumentation zu Ressourcenbeschränkungen.

Vermeide wenn möglich, deine Images auf demselben Server zu bauen, auf dem auch deine Container laufen. Builds können viel CPU und Speicher verbrauchen, und wenn du das nicht einplanst, stürzt dein Server schneller ab, als du sagen kannst: "Bitte nicht abstürzen! 😰".

2. Nicht aufräumen ❌

Niemand räumt gerne auf, aber es ist notwendig, wenn du nicht in deinem eigenen 💩 ertrinken willst. Docker Images können riesig sein - manchmal mehrere Gigabyte groß. Wenn du neue Versionen deiner Images deployest und die alten nicht mehr brauchst, solltest du sie loswerden. Das Gleiche gilt für unbenutzte Container und Volumes. Sie summieren sich schnell, und ehe du dich versiehst, schlagen deine Deployments fehl und du verbringst weitere 45 Minuten damit herauszufinden, dass deine Festplatte voll ist...

Entferne ungenutzte (nicht getaggte, nicht verwendete) Docker-Objekte mit:

docker container prune
docker image prune
docker volume prune
docker system prune # das entfernt alle ungenutzten Images, Volumes und Container

Entferne alle ungenutzten Docker-Objekte, indem du das Argument -a hinzufügst (auch getaggte Images):

docker container prune -a
docker image prune -a
docker volume prune -a
docker system prune -a # das entfernt alle ungenutzten Images, Volumes und Container

3. Secrets in deinen Images leaken ❌

Es ist nicht ungewöhnlich, dass Anwendungen während des Build-Prozesses Zugriff auf Secrets benötigen. Was viele nicht verstehen: Ein Image, das Secrets zur Build-Zeit eingebaut hat, muss selbst wie ein Secret behandelt werden! Ein Docker-Image ist kein Tresor. Alles, was du hineinpackst, kann von jedem gelesen werden, der Zugriff auf das Image hat (es sei denn, du würdest etwas Wildes tun und es verschlüsseln). Also veröffentliche niemals Images auf Docker Hub, wenn du Secrets eingebaut hast!

Wenn möglich, vermeide es, Secrets zur Build-Zeit zu übergeben und nutze stattdessen Umgebungsvariablen oder einen Secrets Manager. Wenn das absolut nicht möglich ist, stelle sicher, dass du das Image nur in einer vertrauenswürdigen Umgebung baust, es in einer privaten Registry speicherst, es nur über verschlüsselte Leitungen bewegst und es löschst, sobald du es nicht mehr brauchst...

Schau dir auch diesen Blogpost über Möglichkeiten zum Umgang mit Build-Secrets an.

4. Kein Monitoring vorhanden ❌

Container sind isoliert und kurzlebig, was hervorragend für Sicherheit und Portabilität ist, aber nicht ideal fürs Monitoring.

Jedes Mal docker exec ausführen zu müssen, wenn du die Logdatei überprüfen willst, ist wirklich mühsam. Bereite dich daher im Voraus vor.

Das Einfachste, womit du anfangen kannst, ist ein Volume zu mounten, um deine Logdateien zu speichern, damit sie wenigstens persistent sind. Aber ohne Log-Rotation und idealerweise eine Möglichkeit, Logs zu durchsuchen, stößt dieser Ansatz schnell an seine Grenzen.

Um mehr Sichtbarkeit zu bekommen, kannst du ein Log-Monitoring implementieren, indem du deine Daten an ein externes System streamst und Tools zur Ressourcenüberwachung einrichtest, um CPU- und Speichernutzung deiner Container zu überwachen.

In professionellen Umgebungen wird das Monitoring oft mit dem ELK Stack realisiert.

5. Docker-Images nicht optimieren ❌

Wie bereits erwähnt, können Docker-Images riesig sein (bis zu mehreren Gigabyte!). Der letzte Fehler, den ich hier erwähnen möchte, ist das Versäumnis, deine Docker-Images zu optimieren. Das spart nicht nur jede Menge Speicherplatz, sondern reduziert auch die Angriffsfläche und macht deine Deployments deutlich schneller.

Nimm dieses Beispiel zur Minimierung eines Docker-Images für Nuxt 3. Der Autor, Jonas Scholz, schaffte es, die Image-Größe von 1,4 GB auf nur 160 MB zu reduzieren! Das ist fast eine 10-fache Verbesserung, nur durch Befolgen einiger einfacher Schritte:

• Verwende das kleinstmögliche Basis-Image
• Schließe unnötige Dateien in deiner .dockerignore-Datei aus
• Stelle statische Assets von einem CDN bereit
• Nutze Multi-Stage-Builds

Zusammenfassung

Häufige Fehler beim Deployment mit Docker sind:

1. Ressourcenlimits weglassen,
2. Nicht aufräumen,
3. Sensible Daten in dein Image einbauen,
4. Logging und Monitoring vernachlässigen und
5. Versäumen, Images zu optimieren.

Wenn du dir das Leben etwas leichter machen möchtest, schau dir sliplane.io an. Es ist eine einfache Docker-Hosting-Lösung, die dir hilft, einige der hier genannten Fallstricke zu vermeiden.