Docker – ein sehr spannendes Thema zum Nachdenken

Die neue Container-Technologie Docker wird in Unternehmen heiß diskutiert. Sie birgt unzählige Möglichkeiten aber auch einige Gefahren. Das Problem mit Docker ist, dass die Technologie relativ jung ist (auch wenn Container in Linux generell schon älter sind). Die Software und die Tools rund um die Software sind noch nicht ausgereift, Security-Fragen müssen noch geklärt werden und das allgemeine Verständnis rund um Container und Docker ist auch wenig verbreitet. Immer noch gibt es den Mythos: “man programmiert eine Anwendung in einem Container und schiebt diesen dann in Produktion”. Das wird zwar funktionieren, aber folgende Punkte zeigen, dass man sich für einen Docker-Container im produktiven Betrieb Gedanken machen muss:

 

11 Punkte zum Nachdenken

 

*

Breaking changes


Docker befindet sich noch relativ am Anfang seiner Entwicklung. In letzter Zeit kam jede Docker-Version mit Änderungen welche Probleme verursacht haben. Außerdem haben sich die Namen der Installations-Pakete geändert von docker.io zu docker-engine zu docker-ce. Das erschwert ein Upgrade.

*

Firewalling schwierig


Docker ändert für das Forwarding IPTables-Regeln. Hat man eine Firewall auf seinem Server kann es sein, dass die Docker-Regeln damit gelöscht werden.

Ein Beispiel dazu: Shorewall leert beim Start die IPTables-Regeln und schreibt eigene Regeln. Docker benötigt wiederum seine eigenen Regeln die es beim Start anlegt. Wird Docker vor der Shorewall gestartet überschreibt diese die Docker Regeln. Fügt man die Docker-Regeln nachträglich hinzu, funktioniert zwar der Betrieb, allerdings werden diese Regeln beim nächsten Neustart der Shorewall wieder rausgelöscht. Es scheint so als ob hier mit einem Workaround gearbeitet werden muss.

*Nicht alle Applikationen funktionieren

Kolab 3.4 konnten wir in einem Docker-Container auch nach vielen Versuchen nicht installieren. . Ein ähnliches Problem hatte jemand mit Erlang-Programmen:

https://thehftguy.com/2016/11/01/docker-in-production-an-history-of-failure/

*Pflege der Images mühsam

Bei Images ist oft nicht klar gekennzeichnet ob sie in Verwendung sind und wozu sie überhaupt da sind:

Außerdem gibt es noch kein Docker-Command zum Löschen alter Images.
(https://thehftguy.com/2016/11/01/docker-in-production-an-history-of-failure/)

*Security:
Update-Workflow

“Früher hatte man eine veraltete Applikation, jetzt hat man eine veraltete Applikation und ein veraltetes System.” – Dieses Szenario kann sich daraus ergeben, dass man nicht mehr auf traditionelle Weise updaten kann.

Im Sinne von Docker gibt es ein “Basis”-Image, welches die Plattform/Umgebung anbietet und indem dann Sicherheitsupdates eingespielt werden können. Dieses Basis-Image wird in einem Dockerfile verwendet um ein Applikations-Image zu erstellen. Ein Update könnte dann so aussehen, dass man zuerst das Basis-Image rebuilded (und dabei aktualisiert) und danach das Applikationsimage.

*Wartung: Fertige Images / Customized settings

Passen die Images die jemand anderer zur Verfügung stellt auch für den eigenen Gebrauch? Falls nicht, wer erstellt die Images?

Sehr schnell passiert es, dass ein Image nicht von einem erfahrenen Administrator erstellt wird. Im Betrieb stellt sich dann heraus, dass viele Einstellungen fehlen oder sogar gefährlich konfiguriert sind und dadurch Sicherheitslücken entstehen.

 

*Neue Technologie: Tools & Libraries noch jung

Tools und Libraries rund um Docker sind noch sehr jung und teilweise noch am Entstehen. Junge Projekte müssen sich häufig noch am Markt durchsetzen. Außerdem leiden sie häufig an Kinderkrankheiten (bzw Bugs).
https://www.iron.io/docker-in-production-what-weve-learned/

*

Update-Problematik


Kann man die Docker-Images upgraden? Was passiert mit den Daten die upgegraded werden? (z.B: redmine-upgrade mit plugins). Ein Container kann viele Jahre ohne Updates laufen (was wir bei toscom absolut nicht anraten). Doch was passiert, wenn die Anwendung mit vielen Daten gefüttert wurde? Kann man dann den Container auch noch upgraden? Selbst wenn die Daten auf einem persistenten Volume liegen, kann es sein, dass diese bei einem Upgrade angepasst werden müssen weil sich Strukturen geändert haben. Upgrades können oft komplexer sein und benötigen häufig manuelle Eingriffe. Docker kann den Applikations-Update-Vorgang erschweren.

*Problem mit dem Filesystem
  • AUFS: nicht fix im Kernel und kein Patch für den aktuellen Kernel
  • Overlayfs: nicht alle Features von AUFS und nicht kompatibel mit alten Installationen (AUFS, Overlayfs1)
  • BTRFS: auch noch relativ jung und nicht 100%ig stabil
* Docker-Registry: hub.docker.com bedenklich

Auch wenn es schon “trusted” Container auf hub.docker.com gibt, bedeutet das nicht automatisch, dass folgende Punkte positiv beantwortet werden:

  • Images gewartet oder nicht aktuell?
  • Images können bugs oder gar backdoors enthalten

Natürlich können immer noch selbst Audits geführt und Container gescannt werden. Zum Beispiel mit
https://github.com/OpenSCAP/container-compliance

* Security und das Container-konzept

Wenn es um eine besonders sicherheitskritische Anwendung geht würde ich diesen Punkt in Erwägung ziehen. Container sind leichtgewichtig da sie den Kernel und Resourcen des Systems ohne einer Schicht dazwischen mitverwenden. Ein Container entsteht hauptsächlich durch Namespaces. Der Kernel setzt einen Container-Prozess in einen eigenen Namespace wodurch dieser Prozess isoliert wird. Ohne zusätzlichen Schutz, könnten die Container trotzdem noch auf Resourcen des Wirtssystems zugreifen. Es gibt unterschiedlichste Schutzmechanismen:

  • Capabilities mit denen man bestimmte Features in Containern abdrehen kann (z.B.: dass der Container seine Macadresse ändern kann, oder dass der Container keine Kernel-Module laden kann)
  • Seccomp mit denen Prozesse (und Unterprozesse) sehr fein eingeschränkt werden können (Welche Systemcalls darf ein Prozess im Container durchführen)
  • Selinux/Apparmor mit denen auch sogenanntes “Mandatory Access Control” für Container bereitgestellt werden kann

Folgende Probleme bleiben aber durch dieses Konzept offen:

  • Eine fehlerhafte Konfiguration kann die Sicherheit des ganzen Systems gefährden (und damit auch andere Container auf diesem System)
  • Eine Sicherheitslücke im Kernel (der ja geteilt wird) die im Container ausgenutzt wird, kann zu einem Ausbruch aus dem Container führen.

 

Conclusio

 

Die Container-Technologie ist ein sehr spannendes Thema. Neue Möglichkeiten werden dadurch eröffnet, allerdings ist die Technologie noch neu und steckt doch noch in den Kinderschuhen. Die Probleme von Docker werden in den nächsten Jahren bestimmt noch gelöst und es werden bestimmt noch viele neue Tools rund um die Docker-Infrastruktur entwickelt. Aber letztendlich muss man sich derzeit noch fragen, ob man Docker wirklich produktiv einsetzen will, oder ob man nicht auf andere Technologien (zB: LXC/LXD) ausweicht.

Wir von toscom sind Spezialisten für Open Source und beraten Sie gerne zu bestehender oder geplanter Webinfrastruktur. Unsere Provider-Unabhängigkeit ist dabei ein Garant für unsere Objektivität.

 

 

Durch die weitere Nutzung der Seite stimmst du der Verwendung von Cookies zu. Weitere Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.

Schließen