Ich habe vor allem bei den Schreiboperationen schlechte Erfahrungen mit Docker gemacht, was aber auch zu erwarten ist, wenn man sich mit dem Overlay-Dateisystem beschäftigt, das zwangsläufig durch die unveränderbaren Images notwendig wird. Aufgefallen ist mir das bei einem Postfix im Container, was an diverse Stellen Cache-Daten und interne Datenbanken nutzt. Durch das Copy-on-Write-Prinzip werden diese Dinge stark ausgebremst. Abhilfe schaffen hier zusätzliche Volumes für diese Dateien, auch wenn diese Daten nicht wirklich persistent sein müssen und von der Anwendung selbstständig wieder aufgebaut werden, um der Copy-on-Write-Bremse zu entgehen und viel direkter mit dem Host-System zu arbeiten. Hier hilft es, wenn ein Container eine Weile läuft mit `docker diff` die Änderungen im Container aufzuspüren.

Eine weitere Sache, die man berücksichtigen sollte, sind die tmpfs Mounts, die die meisten Distributionen für Verzeichnisse, wie /run oder sogar bereitstellen. Docker tut das nicht automatisch und ob ich in den RAM oder in einen Copy-on-Write-Layer schreibe, macht natürlich einen gravierenden Unterschied. Hier sollte man sich nicht wundern, dass der Docker Swarm Mode mit dem Compose File die Eigenschaft „tmpfs“ nicht unterstützt. Diese lässt sich aber über die „Long Syntax“ der Volumes im Compose File nutzen.

Zwei Links dazu und einen für Kernel-Anpassungen, die bei vielen Containern oder wenigen mit viel Ressourcen-Hunger notwendig werden.
Storage Driver: https://docs.docker.com/engine/userguide/storagedriver/selectadriver/
Long Syntax Volumes in Compose File: https://docs.docker.com/compose/compose-file/#long-syntax-3
Kernel Tweaking für Hosts mit vielen vieln Containern: https://blog.codeship.com/running-1000-containers-in-docker-swarm/