1

Proseminar : Docker
Informatik TU Ilmenau
Leon Paul Kaiser
leon-paul.kaiser@tu-ilmemau.de
03.02.2023

I NHALTSVERZEICHNIS I. A BSTRAKT

I Abstrakt 1 In dieser Arbeit wird der Container Dienst Docker

erläutert und es wird untersucht, ob man Ressourcen
II Einleitung in Docker 1 Limits setzen und messen kann. Weitere Aspekte sind
II-A Warum wird Docker genutzt? . . . 1 der Umgang mit Daten und die Sicherheit, im Bezug auf
II-B Vorteile von Docker . . . . . . . . 2 den Datenverkehr und der Verwundbarkeit durch äußere
II-C Nachteile . . . . . . . . . . . . . . 2 Einflüsse, in Docker. Zu Beginn werden Docker’s Nut-
II-D Docker Alternativen . . . . . . . . 2 zungsgrund, Bestandteile und der Aufbau beschrieben.
Auch die wichtigsten Docker Befehle werden aufgelistet
III Grundlagen zu Docker 3 und erklärt. Nach den Grundlagen wird das Limitieren
III-A Bestandteile von Docker . . . . . 4 von RAM Speicher und der CPU beschrieben. Dies ist
III-A1 Docker-Image . . . . . 4 unter Docker nur beim Starten eines Containers möglich.
III-A2 Docker-Container . . . 4 Nach der Limitierung wird das persistente Speichern von
III-A3 Docker-Layer . . . . . 4 Daten via Volumens, Bind mounts sowie das kurzzei-
III-A4 Docker-Engine . . . . . 4 tige sichere Speichern mit tmpfs mounts oder named
III-A5 Dockerfile . . . . . . . 4 pipes. Nach der Erklärung werden zudem Use Cases
III-A6 Docker Daemon und aufgelistet bzw. beschrieben. Darauf folgend wird die
Client . . . . . . . . . . 4 Messmethode mit Docker stats und dem time Befehl
III-A7 Portainer . . . . . . . . 5 von Linux vorgestellt. Anschließend werden einfache
III-A8 Kubernetes . . . . . . . 5
Tests durchgeführt, welche die gesetzten Limits und das
III-A9 Mikroservices . . . . . 5
Messen testen. Zum Schluss wird noch einmal über
III-A10 Docker-Registry und
Docker und den gewünschten Anwendungsfall evaluiert
Docker-Hub . . . . . . 5
und ein Fazit geschlossen.
III-B Grundbefehle beim Arbeiten mit
Docker . . . . . . . . . . . . . . . 5
III-C Anwendungfälle für Docker . . . . 6 II. E INLEITUNG IN D OCKER
A. Warum wird Docker genutzt?
IV CPU und Speicher Limit 6
IV-A Ressourcen Nutzung . . . . . . . . 6 Docker wird genutzt, um Anwendungen zu kapseln
IV-B RAM Speicher Limit . . . . . . . 6 bzw. in Container umzuwandeln. Dafür läuft Docker auf
IV-C CPU Limit . . . . . . . . . . . . . 7 den großen 3 Betriebssystem : Windows, Macintosh und
Linux. Jedoch läuft die Docker-Engine nur auf Linux
V Docker Umgang mit Daten 7 nativ, da Docker auf den Linux-Kernel mit cgroups und
V-A Volumes . . . . . . . . . . . . . . 8 namespaces angewiesen ist. Für Windows und Macintosh
V-B bind mounts . . . . . . . . . . . . 8 wird Docker Desktop und eine Linux VM als Container
V-C tmpfs mounts und named pipes . . 8 Laufzeitumgebung genutzt. Dadurch ist die Ausführung
des Containers vom Betriebssystem unabhängig. Auf-
VI Verbrauch von Ressourcen 9 grund dieser Gegebenheit ist die Anwendung vom Be-
VII Überlauf-Test 9 triebssystem abgegrenzt und eignet sich hervorragend
für die Entwicklung im Team, da nur kleine Dateien
VIII Fazit 10 ausgetauscht werden müssen und diese selbst bei anderen
Betriebssystemen oder Konfigurationen funktionsfähig
Literatur 12 sind.

B. Vorteile von Docker
Vorteile von Docker sind, wie bereits beschrieben, die
garantierte Ausführung und Funktionalität der Anwen-
dung in jeder Umgebung. Zudem revolutionierte Docker
die Softwareentwicklung, da nun nicht mehr große VM
Dateien ausgetauscht werden müssen, welche lange zum
booten brauchen und viel Speicher in Anspruch nehmen.
Dadurch spart Docker viel Zeit und Ressourcen ein.
In Abbildung 1 wird der Unterschied zwischen Docker
und einer VM mit den Themen der Umgebung und der
Ressourcennutzung verglichen.
Abbildung 1. Vergleich VM und Docker.[1]
Docker-Container sind flexibler, effektiver und viel-
seitiger einsetzbar. Ein weiterer Vorteil, welcher für
diese Arbeit wichtig ist, besteht in der Fähigkeit Ap-
ps voneinander, auch vom grundlegenden System, zu
isolieren. Dadurch ist es möglich den Containern Res-
sourcen zuzuordnen. Es wird sichergestellt, dass Co-
de und Daten getrennt sind. Zudem verbessert Docker
den Umgang mit Microservice-Modellen. Diese bestehen
aus mehreren organisierten separaten Komponenten (ein
sogenanntes Stack). Beispiele für solche Modelle sind
Datenbanken, Webserver oder In-Memory-Cache. Der
Vorteil von Docker-Containern sind die separaten, in
sich geschlossenen Dienste. Diese platzsparenden und
gut austauschbaren Container ermöglichen eine einfache
Erstellung und Pflege von Microservices. Somit sind
viele Komponenten vielseitig, durch Wiederverwendung
nutzbar.
Kurzgesagt ist ein Docker-Container ein Paketformat,
dass den vollständigen Code und die Abhängigkeiten
der Anwendung einheitlich verpackt und diese zu-
verlässig und schnell über Compute-Umgebungen hin-
weg ausführt. So laufen Docker-Anwendungen auf jedem
2
System, wie Laptops bis hin zu Server mit beliebigen
Betriebssystem.
C. Nachteile
2018 und 2020 gab es 2 Skandale in denen Docker-
Pakete, mit Hintertüren und Kryptominern, im Docker-
Hub veröffentlicht wurden. Diese generierten durch das
wiederholte herunterladen und nutzen der Images 58 000
Euro und 36 000 Dollar in der Kryptowährung Monero.
Docker Hub unternahm erst, nachdem kritische Berichte
zum Thema veröffentlicht wurden, etwas gegen die kor-
rupten Pakete. Zudem eignet sich Docker nicht für gra-
fikintensive Anwendungen. Es besteht eine Möglichkeit,
diese ist jedoch umständlich. Bei einer kleineren Anzahl
Apps, die nicht häufig aktualisiert wird, bietet sich die
VM-Umgebung eher an. Diese ist simpler zu verwalten,
so überwiegen die Vorteile dieser Lösung.
Siehe auch[2]. Ein weiteres Problem ist das die Docker-
Engine nur das eigene Docker-Format unterstützt. Wei-
tere Probleme können zum einem die monolithische
Programmdatei (die alle Features enthält) oder die Tei-
lisolierung einzelner Prozesse sein. Docker lässt sich
nicht in Full-System-Container Betrieb nutzen. Somit
sind Container nicht vollständig unabhängig.[3]
D. Docker Alternativen
rkt oder auch Rocket ist der stärkste Konkurrent von
Docker. Anders als bei Docker wird beirkt mehr auf
der Sicherheitsebene geachtet. Dazu zählen Container-
Isolierung auf Basis von KVM, die Unterstützung
der SELinux-Kernel Erweiterung und eine Signatur-
Validierung der Images, welche von den App Container
appc genutzt werden. Es bietet in der Laufzeitumgebung
ein Image-Discovery-Mechanismus, welches durch das
Image-Format: App-Container-Image beschrieben ist.
Zudem lassen sich Multi-Container-Apps in sogenannte
App-Conatiner-Pods gruppieren. rkt ist auch nicht auf
die Linux-Kernel-Funktionen Cgroups und Namespaces
festgelegt. Mit CoreOS als Laufzeitumgebung lassen sich
auf KVM (Kernel-based Virtual Maschines) und Intels
Clear-Container-Technologie als vollständig gekapselte
virtuelle Maschinen starten. Ein großer Nachteil ist aber,
dass rkt nicht den Betrieb in Full-System-Containern
unterstützt.
Weitere Alternativen sind LXC, welches ein Set aus
Tools, Bibliotheken, Templates und weiteren Teilen, die
sich zusammen zu einer Userspace-Schnittstelle für na-
tive Container-Funktionen des Linux Kernels darstellen
lassen. Vorteil hierbei ist das es für den Full-System-
Container Betrieb optimiert ist. Nachteile sind, dass
es nur für Linux Systeme implementiert ist und das
der Betrieb von App-Containern nicht zum Standard-
gehört. LXD ist das Folge-Projekt von LXC und fügt

einen Daemon-Prozess LXD hinzu. Dieser ist eine Art
Container-Hypervisior. Ziele dieser Software ist es, An-
wendern auf Linux-Container-Technologie Basis eine
Nutzererfahrung, ähnlich der Nutzung einer virtuellen
Maschine zu geben. LXD hat fast die selben Vorteile wie
der Vorgänger, hat aber auch die Nachteile, wie das der
Linux-Kernel Voraussetzung ist. [3]
Es gibt noch deutlich mehr Container Software, wie
Linux-VServer, OpenVZ, runC. Die meisten sind aber nur
auf Linux Systemen nutzbar und werden mit GO oder
C programmiert. Die folgende Übersicht 2 zeigt noch
einmal die wichtigsten Eigenschaften und Merkmal auf.
Abbildung 2. Docker Alternativen Übersicht [3]
III. G RUNDLAGEN ZU D OCKER
Docker ist eine Software-Container-Plattform in der
Entwicklung, Versand und Ausführung einer Anwen-
dung mit Hilfe einer Containertechnologie ermöglicht
werden. Docker basiert auf Linux und nutzt den Linux-
Kernel und die Funktionen cgroups und namespaces um
Prozesse unabhängig auszuführen. Dockers Werkzeuge
bauen dabei auf Linux Containern auf. Wichtig hierbei
3
ist, dass Docker nicht dasselbe wie ein Linux Container
ist. Zu Beginn war die Technik hinter Docker auf der
bereits genannten LXC-Technologie aufgesetzt. Jedoch
hat sich Docker von dieser Abhängigkeit gelöst. Docker
bietet mehr als das simple ausführen von Containern.
Mit Docker wird der Prozess von der Erstellung und des
Aufbaus eines Container sowie der Versand von Images
und die Versionierung vereinfacht. Im Vergleich zu der
Linux Grundlage, verfügt Docker über die Fähigkeit der
Aufschlüsselung von Anwendungen in kleinere einzelne
Prozesse. Aber Docker vereint, wie LXC, zwei Ziele:
• Container teilen sich denselben Linux-Kernel, was
zu weniger Ressourcenverbrauch führt
• laufende Container voneinander isolieren und nur
limitierten Zugriff auf die Systemressourcen geben
Daraus ergibt sich, dass Docker bei der Nutzung au-
ßerhalb einer Linux-Distribution auf Hypervisor oder
VM zurückgreifen muss. Diese Zwei garantieren die Be-
reitstellung des Linux-Kernels. Die Kernel-Namespaces
partitionieren die Kernel-Ressourcen und garantieren da-
durch die Abgrenzung von Prozessen untereinander. Ein
Prozess kann somit nur Kernel-Ressourcen des selben
Namespaces sehen. Die genutzten Namespaces sind in
folgender Grafik 3 zu sehen: Control Groups kurz
Abbildung 3. Benutzte Namespaces [4]
cgroups dienen zur hierarchischen Organisation von Li-
nux Prozessen. Den Prozessen wird ein limitierter Betrag
an Systemressourcen zugewiesen. cgroups werden im
Gegensatz zu Namespaces zur Limitierung von Zugriff
auf Systemressourcen genutzt, statt Prozesse von einan-
der zu isolieren. Dadurch wird sichergestellt, dass das
Gesamtsytem mit mehreren Containern Arbeitsfähig ist.
Mehr Informationen findet man unter [4] und [5]. Aber
Docker unterscheidet sich weiterhin grundlegend von
 4

NXC. Im nächsten Abschnitt werden Dockers Bestand- • add: kann Dateien in den Container laden oder
teile genauer erläutert. überschreiben(z.B. bei Config-Dateien)
• expose: Zuordnung eines Port’s zu einen Container
A. Bestandteile von Docker Das Dockerfile enthält alle Anweisungen für die
Die Bestandteile von Docker sind die folgenden: Erstellung eines Docker-Images, denn es enthält die
Betriebssystem-Anweisungen. auf denen die Container
1) Docker-Image: Das Docker-Image ist die Darstel- basieren sollen. Der Ablauf mit einem Dockerfiles wird
lung eines Snapshot’s eines Containers. Mit dem Befehl in 5 aufgezeigt.
build werden Images erstellt. Mit run wird daraus dann
ein Container erzeugt. Images sind in Schichten aus an-
deren Images konzipiert, um beim Hochladen von Images
für eine geringe Datenmenge im Netzwerk zu sorgen.
Images sind im Grunde eine Art Template. Diese können
ein Betriebssystem sein, welches eine NGINX,PHP oder
Node.js Installation beinhaltet. Da Images auch An-
wendungen selbst enthalten können, werden diese bei
Entwicklern, statt der Anwendung selbst, geteilt. Images
können auf jedem System mit Docker laufen, was die
Entwicklung vereinfacht. Sie sind eine Sammlung von
Software, die in Containern ausgeführt wird.
2) Docker-Container: Kurzgefasst ist der Container
die Instanz des Images bzw. ein Laufzeitobjekt. Con-
tainer ermöglichen die Lauffähigkeit auf verschiedenen
Umgebungen. Der Container enthält alles wichtige, was
zur Anwendungscodelaufzeit benötigt wird. Dazu zählen
Programmcode, RunTime-Engines, Systemtools, System-
bibliotheken, Einstellungen, etc.. Der Unterschied zum
Image ist somit, dass das Image der Bauplan ist und
der Container das Erbaute. Der Container hat nur read-
only-Rechte. Da er eine Instanz ist, kann er innerhalb der
Laufzeit verändert werden.
3) Docker-Layer: Das Docker-Layer ist Teil eines
Images. Es enthält einen Befehl oder eine Datei, die
den Image hinzugefügt wird. Das Docker-Layer enthält
somit die History für das jeweilige Image. Nur die Obere
Schicht hat dabei keinen Read-Only Status.
4) Docker-Engine: Die Docker-Engine ist eine Open-
Source-Hostsoftware, in der Container erstellt und aus-
geführt werden. Die Engine wird als Client-Server-
Anwendung bei vielen Windows-Server und Linux-
Betriebssystemen verwendet. Sie muss auf dem Host-
Rechner installiert sein, um Docker-Container nutzen zu Abbildung 4. Dockerfile Aufbau [6]
können.
5) Dockerfile: Für die Erstellung von Docker-Images 6) Docker Daemon und Client: Der Docker-
und Docker-Container ist ein Dockerfile notwendig. Die- Daemon ist ein immer laufender Hintergrundprozess,
ses kann durch den Befehl: welcher Docker Images, Container, Netzwerke
mdir project-name && Dockerfile und Speicher-Volumen verwaltet. Er sorgt für die
Ausführung/Instantiierung von Container/Images. Der
erstellt werden. Einen guten Überblick für die Erstellung Docker Client ermöglicht wiederum die Benutzer-
vom Dockerfile zum Docker-Container sieht man in Container-Interaktion. Er kann auf demselben Host
Abbildung 5. Weitere Befehle für Dockerfiles sind : wie der Daemon sein oder per Verbindung zu einen
• from: enthält das Image, was verwendet wird (dafür anderen Host und dessen Daemon genutzt werden. Den
muss das Image vorher gepullt worden sein) Client nutzt man über CLI (Command Line Interpreter)
• run: beinhaltet ein Linux Befehl für die Shell und die Konsole. Über diesen werden Docker Daemon

Befehle zum Erstellen, Ausführen und Anhalten von
Anwendungen erteilt. Jedoch ist die Hauptaufgabe des
Client, Mittel zur Verfügung stellen, welche Images vom
Registry’s pullen und auf dem Docker-Host ausführen.
Hierbei gibt es wieder die Befehle aus Abbildung 5.
Abbildung 5. Ablauf bei einem Dockerfile [7]
7) Portainer: Für eine einfache Nutzung von Docker-
Befehlen, kann man die GUI Portainer nutzen. Die
Verwaltung und das Management von Docker ist sowohl
für größere als auch kleinere Projekte mit Portainer
möglich. In der GUI werden Hardwareinformationen
(Anzahl Prozessoren, Größe Arbeitsspeicher) sowie auch
Docker-spezifische Informationen (Anzahl Docker Con-
tainer, - Images, - Volumens und - Networks) gut einseh-
bar veranschaulicht. Weiterhin lässt sich der Portainer
auch in einer Weboberfläche für größere Projekte bzw.
Verteilte Projekte nutzen. Er eignet sich somit für eine
einfach Verwaltung und Steuerung der Standard Docker-
Funktionen.
8) Kubernetes: Kubernetes ist ein Open-Source-
Orchestrierungsystem, mit dem sich Docker-Container
ausführen lassen. Sie unterstützen bei der komplexen
Ausführung von Docker-Container, die über verschie-
dene Server hinweg gegeben sind und skaliert wer-
den müssen. Die Kubernetes-Engine koordiniert die
Container-Lebenszyklen und verteilt die verwendeten
Container über das Netzwerk-System. Dabei kann es
den Ressourcen-Anspruch verkleinern oder erweitern.
Kubernetes überwachen den Zustand der Container kon-
tinuierlich, dazu zählen unter anderem die Bereitstellung,
Löschung und Planung.
9) Mikroservices: Mikroservices sind das Gegenstück
zum komplexen, monolithischen Architekturen. Sie bre-
chen eine Anwendung in kleine Teilanwendungen, die
unabhängiger von einander agieren und in APIs koordi-
niert werden. Zudem hat jeder Service seine eigene Da-
tenbank, was Speicherprobleme beim Lesen bzw. Schrei-
ben umgeht. Jede Funktion kann dabei als unabhängiger
5
Service entwickelt werden. Jeder Service arbeitet somit
unabhängig und wird nicht von anderen Services beein-
flusst. Weiterhin ermöglicht die Modularität ein Release
Cycle, indem nahtlos Änderungen am Code gemacht
werden können, ohne Anwendungsausfälle. Auf Anfrage
kann zudem der Services skaliert werden. Kurzgefasst
sind Mikroservices sehr flexibel und umgehen die Nach-
teile, die sich mit monolithischen Anwendungen ergeben.
10) Docker-Registry und Docker-Hub: Wie Git für
die Standard Programmierung zur Versionierung benutzt
wird, kann es auch bei Docker genutzt werden. Jedoch
gibt es auch das Docker eigene Versionierungs- und
Verbreitungstool Docker-Hub. Es wird bei der Entwick-
lung von Docker-Images zudem das Docker-Registry
genutzt. Es ist ein Open-Source-Repository, welches
das Speichern und Verteilen von Docker-Images verein-
facht. Es verbessert die Sicherheit und Zugriffskontrolle
der gespeicherten Docker-Images. Die Docker Registry’s
können im Docker-Hub erstellt und gehosted werden.
Somit gibt es in den Registry’s verschiedene Versionen
eines Containers. Dabei ist das oben genannte Docker-
Hub selbst wieder ein Docker Registry, welches von
Docker verwaltet wird.
B. Grundbefehle beim Arbeiten mit Docker
Die wichtigsten Befehle für das Nutzen von Docker
sind dabei:
docker version
//gibt Docker Version an
docker info
// gibt systemweite Information
// über Docker Installation aus
docker images
// gibt aktuelles Image an
docker ps -a
// auflisten aller Container
// (ohne -a Auflistung von
// laufenden Containern)
docker run --rm <imageName>
// lässt Image ausführen und
// Container wird nach Abschluss
// entfernt
docker exec -it
<containerName> <command>
// lässt neuen Command
// auf laufend Container
// ausführen

docker stop <containerName>
// stoppen eines Containers
docker start <containerName>
// erneutes starten des Containers
docker rm <containerName>
// entfernen des Containers
docker rmi <imageName>
// entfernt ein oder
// mehr Images vom Host
Die Docker Dokumentation dazu [8]
C. Anwendungfälle für Docker
• Mikroservices: Mit den Docker-Containern lassen
sich viele Mikroservices einfach erstellen und ma-
nagen. Jeder Service kann dabei in Form eines
eigenen Containers erstellt und genutzt werden.
Mit Management-Tools wie Docker-Swarm oder
Kubernetes und einem Mesh an Services wie Is-
tio bzw. Tanzu gibt es eine Vielzahl an Benut-
zungsmöglichkeiten. Weiteres auch in III
• Multi-Umgebung-Entwicklung: Wie schon erläutert
lässt sich Docker auf unterschiedlichsten Konfigura-
tionen und Betriebssystemen nutzen. Dadurch läuft
jedes Programm immer gleich, unabhängig von der
Plattform. Das vereinfacht die Entwicklung und das
Testen sowie die Nutzung der fertigen Anwendung.
Aus diesen Grund ist Docker bei der Entwicklung
in größeren Teams mit mehreren Plattform sinnvoll.
• Isolierte Anwendungsinfrastruktur: Da die Docker-
Container unabhängig und getrennt voneinander
sind, ist ein Sicherheitsaspekt bereits vorausgesetzt.
Zudem können die Container eigene Datenbanken
haben, um weitere Speichersicherheit zu garantie-
ren.
• Portable Software: Docker-Images sind einfach
zu verbreiten. Das dafür zuständige Docker Hub
ermöglicht es Images schnell und unkompliziert zu
versionieren und zu veröffentlichen. Weiterhin kann
aus der Sicherheitssicht der Zugriff nur bestimmten
Benutzern gewährt werden. Somit ist die Verbrei-
tung ähnlich, wie der mit Git Hub, nur das Docker-
Hub speziell für Docker- Images und die daraus
folgenden Container ist.
• Tests: In Docker lassen sich einfach Testumgebun-
gen aufbauen, welche die selbe Umgebung wie das
Produkt hat. Somit gibt es keine Konfigurations-
unterschiede zwischen Entwicklungs- und Ender-
gebnis. Weiterhin lassen sich dank Docker, auch
auf Host-Betriebssystemen andere Konfigurationen
testen, die sonst nicht möglich wären. Somit wird
6
das Einrichten einer dedizierten Testumgebung in
den meisten Fällen bzw. bei kleinen Tests, wie
Funktionstests, erspart.
Beispiele:
Es nutzen Paypal, Adobe und General Electrics Docker
für Anfragen, Transaktionen, Server-Management und
Kommunikation zwischen Servern. Die Beispiele zeigen
die Möglichkeiten und Wichtigkeit von Container basier-
ten Programmen wie Docker. Die wichtigsten Container
Management Tools dabei sind :
• Kubernetes
• Amazon EKS / ECS / Fargat
• Google Kubernetes Service
• Azure Kubernetes Service
[9]
IV. CPU UND S PEICHER L IMIT
A. Ressourcen Nutzung
Im Normalfall haben Docker Container vollen Zugang
zu RAM und CPU Ressourcen beim Hostsystem. Da-
durch kann es aber während der Laufzeit zu einen Fla-
schenhals in der Performance kommen oder schlimmer
zum Systemabsturz des Hostsystems. Somit ist es wichtig
für die Ausfall Sicherheit und Performance eines Systems
und dessen Docker Container zu sorgen. In Docker kann
man die RAM und die CPU Nutzung durch ein festes
oder flexibles Limit einschränken. Dabei kann man es
beim Starten der Container oder im Docker-Composefile
vorab festgelegt werden. Eine weitere Möglichkeit wäre
auch dies allgemein in Docker-Desktop einzustellen. Mit
den Command: docker stats kann man überprüfen, ob die
Limits gültig sind.
B. RAM Speicher Limit
Das RAM-Limit kann in Kombination eines run beim
Starten eines Containers individuell festgelegt werden.
Um einen Container X mit einen Limit von 512 Me-
gabyte zu erstellen, fügt man den Parameter -m oder –
memory= hinzu.
docker run -m 512m [docker_image]
Dabei kann man aber auch das Limit flexibel setzen.
Das heißt das, dass Limit nur gilt, wenn nur wenig RAM
Speicher im Hostsystem zur Verfügung steht. Dafür
wird der Parameter –memory-reservation mit den bereits
genannten m zusammen genutzt. Man kann den obigen
Code erweitern, sodass das Limit von 512 Megabyte erst
gilt, wenn nur noch 256 Megabyte im RAM verfügbar
sind.
docker run -m 512m
--memory-reservation=256m
[docker_image]

Wenn man mehr RAM benötigt, kann man swap-
disk Mermory Limit nutzen. Hierbei wird nicht nur der
RAM Speicher genutzt, sondern auch der Disk-Memory
des Host-Systems. Dies kann aber die Performance ver-
langsamen. Um den zusätzlichen Speicher hinzuzufügen,
muss man erst den vollständigen non-swap memory
festlegen. Der swap memory beinhaltet den non-swap
memory und muss daher größer als dieser sein. Um nun
einen Container mit zusätzlichen 500 MB swap memory
zu starten, muss der swap memory auf 1000 MB gesetzt
werden. Der Code hierfür wäre:
docker run --m=500m
--memory-swap=1000m
[docker_image]
Wenn man unbegrenzten swap memory nutzen möchte,
setzt man den Integer Wert auf -1.
docker run --m=500m
--memory-swap=-1
[docker_image]
Wenn man memory swap vermeiden möchte, setzt man
den Integer Wert auf den memory Wert des RAM´s. Dies
ist, da der swap memory den RAM-memory beinhaltet.
C. CPU Limit
Wie auch der RAM lässt sich die CPU durch ein Limit
einschränken. Dabei ist es wieder möglich ein festes oder
flexibles Limit zu setzen. Für das Limit kann man die
CPU mit der Anzahl an Kernen einschränken.
docker run --cpus=2 [docker_image]
Mit –cpu-period oder –cpu-quota können zum einen
die Länge der CPU-Zyklen in Mikrosekunden oder die
Anzahl an Zyklen, die ein Container nutzen darf, gesetzt
werden. Im folgenden Code wird der Container auf 50%
der CPU-Ressource beschränkt.
docker run
--cpu-period=50000
// oder
--cpu-quota=25000
[docker_image]
Hinzu kommt noch die Zuweisungspriorität des Con-
tainers für die CPU-Zyklen. Der Standardwert hierbei ist
1024, man kann mit höheren Werten die Zuweisungsprio-
rität bei begrenzten CPU-Zyklen erhöhen. Somit kann
man auch auf den CPUs den Anteil des Containers pro
CPU-Zyklus festlegen.
docker run --cpus=2
--cpu-shares=2000 [docker_image]
7
Die Docker run Befehle sind unter [10] noch einmal
aufgelistet und erläutert.
Eine visuellere Möglichkeit ist Docker-Desktop. Unter
Einstellungen können per Regler die Anzahl der CPUs,
das Speicher-Limit für Disk und RAM sowie der swap-
Memory eingestellt werden. Falls dies durch das Host
System selbst verwaltet wird, wird auf die jeweilige Datei
verwiesen. Im Falle von Windows 10 ist es die wsl.config
Datei, welche das Subsystem von Linux auf Windows
konfiguriert.
V. D OCKER U MGANG MIT DATEN
Die Standard Einstellung in Docker für Datenspeiche-
rung lässt die Daten auf einer beschreibbaren Container
Schicht speichern. Dadurch geben sich folgende Eigen-
schaften:
• die Daten sind nicht persistent
• es ist schwierig die Daten für andere Prozesse zu
nutzen
• die beschreibbare Schicht ist eng mit dem Host-
system verbunden, dadurch ist es schwer diese zu
verschieben
• für Schreiben auf der Container Schicht wird ein
eigener Speichertreiber benötigt, dieser bietet ein
ein einheitliches Dateisystem, indem der Linux-
Kernel benutzt wird
• der Speichertreiber verringert die Performance in
Vergleich zu Datei volumes, welche direkt vom
Hostdateisystem beschrieben werden
Auf Grund der letzteren Punkte nutzt man in Docker
zwei Optionen zur persistenten Datei Speicherung auf
dem Hostsystem. Diese sind zum einen volumes und
zum anderen bind mounts. Eine dritte Möglichkeiten
Dateien auf dem Hostsystem zu speichern, wenn auch
nicht persistent, ist es die Datei in den RAM memory
via tmpfs mounts (Linux) oder named pipes (Windows)
zu speichern.
In der Grafik 6 werden die Speicherarten noch einmal
grafisch veranschaulicht:
volumes sind Teil vom Hostdateisystem und werden
von Docker verwaltet, dieser Teil sollte nur von Docker
modifiziert werden.
bind mounts können überall im Hostsystem gespeichert
werden, nicht Dockerprozesse oder andere Docker Con-
tainer können diese Dateien jederzeit modifizieren.
tmpfs mounts und named pipes werden nur im RAM des
Systems gespeichert und werden nie ins Hostdateisystem
geschrieben.
In den meisten Fällen werden volumes genutzt. Es gibt
auch Einsatzfälle, in denen die anderen Möglichkeiten
sinnvoller sind. Wenn man mehr dazu erfahren möchte
kann unter [11] die Docker Dokumentation dazu nachle-
sen.

Abbildung 6. Mounting types
[10]
A. Volumes
Werden durch Docker erstellt und verwaltet. Sie
können explizit mit den Command
docker volume create volume-name
oder mit dem Start eines Containers bzw. eines Services
erstellt werden. Volumes sind im Host-Verzeichnis hinter-
legt. Wenn man ein Volume in einen Container mounted,
wird das Verzeichnis in den Container gemounted. Der
Unterschied zu ähnlichen mounts ist, dass diese Ver-
zeichnisse von Docker verwaltet werden und vom Rest
der Kernfunktionalitäten des Hostsystems isoliert sind.
Man kann ein Volume sogar mehren Containern gleich-
zeitig zuweisen oder einen separaten Daten-Container
erstellen und diesen als ein gemeinsames Datenvolume
nutzen. Damit können andere Container diesen spezi-
ellen Container als Speicher-Volume teilen. Die Ordner
können auch für individuelle Container, unterschiedliche
Zugriffsrechte wie read-write oder read-only erteilen.
Schreiben wird durch file-handles wie bei einem norma-
len Datei/Schreibsystem im Host behandelt. Somit kann
es auch zu Problemen beim schreiben kommen. Es ist
deshalb am besten, wenn man in Ordnern mit Daten,
die sich nicht verändern, den read-only-mode aktiviert.
Volumens können benannt oder anonym sein. Anonyme
Volumes werden in einen Container gemountet, mit ei-
nem zufälligen aber einzigartigen Namen, welcher die
Einzigartigkeit für den Docker-Host garantiert, benannt.
Wenn kein Container das Volume nutzt ist es trotzdem für
Docker verfügbar und wird nicht automatisch entfernt.
Man kann Volumens mit dem Befehlen
docker volume rm volume-name
// Entfernung bestimmter Volumens
docker volumen prune
// Entfernung aller nicht genutzten
// Ordner mit Platz
// frei machen
8
entfernen. [12]
Use Cases für volumes:
• Daten zwischen mehreren laufenden Container tei-
len (wenn nicht vorhanden wird es mit ersten Con-
tainer erstellt, muss aber explizit entfernt werden)
• wenn der Docker-Host keinen garantierte
Verzeichnis- oder Dateistruktur hat
• wenn man Container Daten auf einen Remote Host
oder Cloud Dienst speichern möchte
• wenn man Daten absichern oder wiederherstellen
oder Daten von einen Docker-Host zu einen anderen
verschieben möchte
• wenn man hoch performante I/O Anwendungen für
Docker Desktop benötigt
• wenn die Anwendung eine volles natives Dateisys-
tem Verhalten für Docker Desktop benötigt
B. bind mounts
Haben eine begrenzte Funktionalität in Vergleich zu
volumes. Bei einen bind mount wird eine Datei oder
ein Verzeichnis vom Hostsystem direkt in den Container
gemountet. Dabei ist der vollständige Pfad des Hostsy-
tems angegeben. Dabei muss es nicht bereits auf dem
Host liegen, sondern kann auch auf Anforderung er-
stellt werden. Bind mounts sind performant, jedoch vom
jeweiligem Dateisystem der Hostmaschine und dessen
Verzeichnisstruktur abhängig.
Use Cases für bind mounts:
• man nutzt bind mounts zum Teilen von Dateien vom
Hostsystem zum Container, so kann Docker DNS
resolutions zu Containern anbieten (dies kann bei
default oder bei mounting /etc/resolv.conf von der
Hostmaschine in jeden Container geschehen)
• zum teilen von Source-Code oder build artifacts
zwischen einer Entwicklungsumgebung auf einem
Docker-Host und einen Container
• wenn die Datei oder die Verzeichnisstruktur vom
Docker-Host garantiert, dass sie mit den bind
mounts die der Container benötigt konsistent ist
C. tmpfs mounts und named pipes
tmpfs mounts sind nicht persistent, weder auf dem Host
noch in Docker Containern. Sie können während der
Lebenszeit eines Containers genutzt werden und nicht-
persistente Daten bzw. sensitive Informationen speichern.
named pipes können zur Kommunikation zwischen
Docker-Host und einen Container genutzt werden. Ty-
pischerweise können dadurch Drittanbieter Werkzeuge
innerhalb eines Containers genutzt werden und um sich
zur Docker Engine API zu verbinden.
Use Cases für tmpfs: tmpfs nutzt man, wenn man
die Daten nicht persistent haben möchte, sei es auf der
Host Maschine oder innerhalb des Containers. Dafür
 9

sprechen können Sicherheitsgründe oder der Schutz der Nutzung (Menge

Performance bei Container, wenn Anwendungen große
Mengen an nicht persistenten Zustandsdaten schreiben
müssen.
VI. V ERBRAUCH VON R ESSOURCEN
Zum messen des CPU- und RAM-Verbrauchs kann
man im Terminal den Befehl:
an Schreiben/
Lese) eines
Container an
Den Speicherbedarf der Disk kann man unter
/var/lib/docker in den OverlayFS Ordnern weiter
auswerten. Um die Startzeit eines Containers zu messen,
kann man den Sekundenzähler beim Start mit

docker stats [OPTIONS] [container_name] docker compose

nutzen. Dieser gibt eine live Datenausgabe für laufende nutzen oder unter Linux mit dem Command
Container aus. Dabei kann angegeben werden, ob man time
nur bestimmte Container angezeigt bekommt. Weitere z.B:
Optionen sind das angeben, eines eigenen Formats, die time docker run mycontainer
Ausgabe ohne Datenstrom, das ausgeben aller Container
oder eine ungekürzte Ausgabe. Dafür muss man folgen-
des im obigem Code ergänzen: VII. Ü BERLAUF -T EST
--format : printet die Daten In diesem Abschnitt wird das Limit von CPU und
nach einem RAM getestet. Für den CPU Test werden eine bestimmte
angebenen Template Anzahl an CPU’s immer limitiert, um das System nicht
--no-stream : gibt nur das zu überlasten. Nur bei -period und -quota = N wurde
erste Resultat dies nicht gemacht, da es zu Komplikationen mit den
zurück Docker-Daemon kam. Für den Stresstest wurde das Tool
--all , -a : zeigt alle Container progium/stress: docker stress [14]genutzt, da es RAM
--no-trunc : gibt ungekürzte und CPU Last, nach Festlegung, erzeugen kann. Um die
Ausgabe an CPU-Anzahl festzulegen, wurde folgender Befehle mit
N als Anzahl der CPU’s gewählt:
Die Standard Ausgabe sieht folgendermaßen aus:
//CPU
docker stats simple_container
docker run --cpus=N -d
67b2525d8ad1
--rm progrium/stress -c 8 -t 20s
CONTAINER ID NAME Die Last, aufgenommen mit Docker-Stats für 1, 2 und
b95a83497c91 awesome_brattain 4 CPU’s sieht in den Snapshots:
789
CPU % NET I/O Bei einen N kleiner eins, nahmen die Container alle einen
0.28% 916B / 0B ungefähr gleichen Anteil an Leistung ein. Dies wurde
durch das Starten von vier Containern veranschaulicht.
MEM USAGE / LIMIT MEM % Siehe hier den Snapshots:
5.629MiB / 1.952GiB 0.28% 10
Danach wurde N größer als die Anzahl an vorhandenen
BLOCK I/O PIDS Kernen gestellt. Dabei kam es zur einer Fehlermeldung:
147kB / 0B 9 11
Mit den Befehlen:
Weitere Informationen findet man unter der offiziellen
Docker Dokumentation [13]. docker run -d --rm
Die relevantesten Informationen für diese Arbeit sind --cpu-shares 1000
hierbei: --cpus 1.5 progrium/stress -c 8 -t 40s
CPU % : CPU Nutzung wurde bei einen N von 1.5 und cpu-shares von 1000
MEM USAGE / LIMIT : gibt Snapshot getestet. Im folgendem wird die Veränderung der CPU-
der RAM Nutzung Last vor zwei Container, während zwei Containern und
und das RAM nach zwei Container gezeigt. Siehe dabei die Snapshots:
Limit an 12 13 14
BLOCK I/O : gibt Speicher Es scheint, dass shares keinen Einfluss gehabt hat, da
 10

Abbildung 7. Stress mit 1 CPU Abbildung 9. Stress mit 4 CPU’s

Abbildung 8. Stress mit 2 CPU

Abbildung 10. Stress mit 0.3 CPU’s

beide Container, sowie die Einzelnen, 150% Last ver-

ursachen. Anschließend wurde ohne die CPU Anzahl
einzuschränken, folgende Befehle ausgeführt:
//cpu-quota Abbildung 11. Stress Error CPU
docker run -d --rm
--cpu-quota 25000
progrium/stress -c 8 -t 20s

//cpu-period
docker run -d --rm Abbildung 12. CPU-Last bevor 2 Container laufen
--cpu-period 1000000
progrium/stress -c 8 -t 20s
Mit cpu-quota hat jeder Container Maximal nur 25%
der ganzen CPU genutzt. So sieht man in folgenden
Snapshots einen und zwei Container laufen, welche aber Abbildung 13. CPU-Last während 2 Container laufen
nur maximal 25% an CPU Last verursachen:
15 15
Neben quota wurde auch period getestet. Dabei wurde
für einen Container aber fast die ganze CPU genutzt. Erst
bei einen zweiten Container wurde die Last aufgeteilt.
100% Last der Gesamt-CPU war nicht möglich, da Abbildung 14. CPU-Last nachdem 2 Container liefen
noch andere Prozesse im Hostsystem liefen und die
CPU-Anzahl nicht festlegbar, durch das Problem mit den
Docker-Daemon, war. Die folgenden Snapshots zeigen
die hohe Last und die Aufteilung bei zwei Containern.
17 18 Abbildung 15. CPU-quota mit einen Container

Nun fehlt nur noch der RAM-Last Test. Mit den

Command:
docker run -d --rm
-m 512m progrium/stress Abbildung 16. CPU-quota mit zwei Container
--vm 1 --vm-bytes 600M -t 20s
Es wurde wieder mit einen und zwei Container ge-
messen. In beiden Fällen wurde nicht mehr als die
angegebenen 512 MiB pro Container verbraucht.
Abbildung 17. CPU-period mit einen Container
19 20

VIII. FAZIT
Die Limitierung von Speicher und CPU in Docker ist
nur beim Starten eines Containers möglich. Man könnte Abbildung 18. CPU-period mit zwei Container
 11

überlädt. Diese Schwächen sind aber wie bei jeder An-

wendungssoftware vom Entwickler selbst zu behandeln.
Die Nutzung Docker für ein Funknetztsystem ist
möglich, aber es müsste ein Image geben, welches Con-
Abbildung 19. RAM Last mit einem Container
tainer nach den verfügbaren Funknetzen erstellt bzw. die-
se Containern zuordnet. Dafür wird wahrscheinlich auch
eine Datenbank und ein Verwaltungs-Container benötigt,
welche die Netzdaten und die Netz-Container verwalten.
Die Schwachstellen sind wie bei anderen Anwendung
Abbildung 20. RAM Last mit zwei Containern ähnlich bis gleich, was weder für noch gegen Docker
spricht. Ich sehe Docker als eine mögliche Lösung für
die Aufgabe, da es parallel schnell kleine Prozesse laufen
aber über das Linux Prozessmangagement nachträglich lassen kann sowie die Ressourcen limitierbar sind, um
Limits setzen/nehmen. Dieses Vorgehen entspricht aber das Hostsystem nicht zu überlasten.
nicht Anforderung, da diese Limitierung nicht über Do-
cker direkt laufen würde und Docker dafür dann auch
nicht Notwendig wäre. Man könnte Anwendungen auch
ohne Container laufen lassen und diese über Linux selbst
limitieren und durch Docker-Alternativen in parallelen
Container nutzen. Jedoch sehe ich Docker hierbei im
Vorteil, da es eine Gesamtelösung dafür bietet, welche
simpel zu nutzen ist. Das Unterscheiden zwischen An-
wendungsstart in einen Container und das Starten der
Anwendung auf dem System selbst, halte ich hingegen
für nicht sinnvoll, da beide Varianten den selben Kernel
und den selben CPU Scheduler benutzen. Dadurch sollte
kein signifikanter Unterschied zwischen diesen Varianten
entstehen. Das Unterscheiden zwischen leeren Container
und Container mit Anwendung ist überflüssig, da es
einen Container ohne Anwendung nicht geben kann bzw.
dieser nicht lauffähig ist. Man könnte unterscheiden, ob
nur der Docker Dienst an sich läuft und den Verbrauch,
den der Docker Container beim Erstellen, Verwalten und
Überwachen benötigt. So könnte man zwischen idle und
Betrieb unterscheiden und den jeweiligen Verbrauch an
Ressourcen mittels stats messen. IPC kann in Docker am
einfachsten über TCP/IP realisiert werden. Docker baut
für alle Container interne Netzwerke auf, unter docker
compose werden dabei alle Container eines Composefiles
automatisch vernetzt. Via den bind mounts kann zudem
ein Unix Socket gemountet werden, welchen sich dann 2
Container teilen.
Schwachstellen für Docker sind primär die Linux
Schwachstellen, da Docker auf Linuxbasis funktio-
niert und die Linux-Kernel Funktionen cgroups und
namespaces nutzt. Docker ist im Grunde eine An-
wendung wie jede andere auch, somit hat Docker
auch die selben Sicherheitslücken. Mögliche Sicher-
heitslücken wären z.B. Meltdown oder Spectre. Wei-
tere Angriffsmöglichkeiten sind die Verbreitung von
bösartigen Docker-Images über das Docker-Hub oder
DDos-Attacken für Funknetz-Empfänger, wie das Mo-
bilfunknetz von Zügen, bei denen man den Empfänger
mit unterschiedlichsten Netzfrequenzen/-daten den RAM
 12

A BBILDUNGSVERZEICHNIS
1 Vergleich VM und Docker.[1] . . . . . . . 2
2 Docker Alternativen Übersicht [3] . . . . . 3
3 Benutzte Namespaces [4] . . . . . . . . . . 3
4 Dockerfile Aufbau [6] . . . . . . . . . . . . 4
5 Ablauf bei einem Dockerfile [7] . . . . . . 5
6 Mounting types . . . . . . . . . . . . . . . 8
7 Stress mit 1 CPU . . . . . . . . . . . . . . 10
8 Stress mit 2 CPU . . . . . . . . . . . . . . 10
9 Stress mit 4 CPU’s . . . . . . . . . . . . . 10
10 Stress mit 0.3 CPU’s . . . . . . . . . . . . 10
11 Stress Error CPU . . . . . . . . . . . . . . 10
12 CPU-Last bevor 2 Container laufen . . . . 10
13 CPU-Last während 2 Container laufen . . . 10
14 CPU-Last nachdem 2 Container liefen . . . 10
15 CPU-quota mit einen Container . . . . . . . 10
16 CPU-quota mit zwei Container . . . . . . . 10
17 CPU-period mit einen Container . . . . . . 10
18 CPU-period mit zwei Container . . . . . . 10
19 RAM Last mit einem Container . . . . . . 11
20 RAM Last mit zwei Containern . . . . . . 11

L ITERATUR
[1] O. Router. was-ist-docker. [Online]. Available: https://www.
opc-router.de/was-ist-docker/
[2] N.A. Computerweeklysechsanwendungen für docker. [On-
line]. Available: https://www.computerweekly.com/de/ratgeber/
Sechs-Anwendungsfaelle-fuer-die-sich-Docker-eignet
[3] ——. Alternativen zu docker: Container-plattform im Überblick.
[Online]. Available: https://www.ionos.de/digitalguide/server/
knowhow/docker-alternativen-im-ueberblick/
[4] ——. Docker – die revolutionäre container-technologie.
[Online]. Available: https://www.ionos.de/digitalguide/server/
knowhow/was-ist-docker/
[5] ——. Was ist docker? [Online]. Available: https://www.redhat.
com/de/topics/containers/what-is-docker
[6] ——. Fachartikel docker. [Online]. Available: https://aracom.de/
docker/
[7] the native web GmbH. Docker: Erste schritte // deutsch. [Online].
Available: https://www.youtube.com/watch?v=e1BOFzxgQQY
[8] N.A. Docker dokumentation commandline. [Online]. Available:
https://docs.docker.com/engine/reference/commandline/info/
[9] ——, “Clickit docker use cases,” no. 11. [Online]. Available:
https://www.clickittech.com/devops/docker-use-cases/
[10] ——. Runtime options with memory, cpus, and gpus.
[Online]. Available: https://docs.docker.com/config/containers/
resource constraints/
[11] ——. Manage data in docker. [Online]. Available: https:
//docs.docker.com/storage/
[12] ——. Volumens. [Online]. Available: https://docs.docker.com/
storage/volumes/
[13] ——. docker stats. [Online]. Available: https://docs.docker.com/
engine/reference/commandline/stats/
[14] ——. progrium/stress. [Online]. Available: https://hub.docker.
com/r/progrium/stress/