Zum Inhalt springen

Docker: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
VisuellWikitext
 
(150 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
'''Docker''' - Beschreibung
'''Docker''' - Isolierung von Anwendungen durch [[Containervirtualisierung|Container-Virtualisierung]]


== Beschreibung ==
== Beschreibung ==
; Schlanke Frorm der Virtualisierungen
[[File:dockerDevelopFaster.png|mini|300px]]
* Prozesse laufen auf dem Kernel des Host-Betriebssystems
* Abschottung durch
** [[cgroups]]
** [[namespaces]]
** …
=== Linzenz ===
[[Docker]] ist [[freie Software]]
[[Docker]] ist [[freie Software]]


; Container sind eine schlanke Virtualisierungslösung
=== Realisierung von Containern ===
Prozesse laufen direkt im Kernel des Host-Betriebssystems
; Linux-Techniken
* abgeschottet von den anderen Prozessen durch Linux-Techniken wie
[[Datei:Docker-linux-interfaces.svg|mini|400px|Schnittstellen, um auf Virtualisierungsfunktionen des Linux-Kernels zuzugreifen.]]
** [[cgroups]]
* [[cgroups]]
** [[namespaces]]
* [[Namespaces]]
** unter Windows kommt dafür der WSL2 zum Einsatz
* Anfänglich [[LXC]]-Schnittstelle des [[Linux (Kernel)|Linux-Kernels]]
** unter macOS wird eine kleine Virtualisierung genutzt
* Mittlerweile eine eigene [[Programmierschnittstelle]] namens ''libcontainer''
* Als Speicher-[[Frontend und Backend|Backend]] verwendet Docker das Overlay-Dateisystem [[aufs]]
** seit Version 0.8 wird auch [[btrfs]] unterstützt
<br clear=all>
 
=== Begriffe ===
{| class="wikitable sortable options big"
|-
! Begriff !! Beschreibung
|-
| [[Docker/Volume|Volume]] || Volumes ermöglichen es, dass Daten erhalten bleiben, auch wenn ein Docker-Container gelöscht wird. Volumes sind auch eine praktische Möglichkeit, Daten zwischen dem Host und dem Container auszutauschen.
|-
| [[Docker/Image|Image]] || Ein Docker-Image ist eine schreibgeschützte Vorlage, die von der Docker-Engine benutzt wird, um einen Container zu erzeugen.
[[Image-Datei|Speicherabbild]] eines Containers
* Das Image selbst besteht aus mehreren Layern, die schreibgeschützt sind und somit nicht verändert werden können
* Ein Image ist portabel, kann in [[Repository|Repositories]] gespeichert und mit anderen Nutzern geteilt werden
* Aus einem Image können immer mehrere Container gestartet werden
|-
| [[Docker/Container|Container]] || Docker-Container sind isolierte Ausführungseinheiten für Anwendungen und ihre Abhängigkeiten
Aktive Instanz eines Images
* Der Container wird also gerade ausgeführt und ist beschäftigt
* Sobald der Container kein Programm ausführt oder mit seinem Auftrag fertig ist, wird der Container automatisch beendet
|-
| [[Docker/Layer|Layer]] || Teil eines Images und enthält einen Befehl oder eine Datei, die dem Image hinzugefügt wurde
* Anhand der Layer kann die ganze Historie des Images nachvollzogen werden
|-
| [[Docker/Dockerfile|Dockerfile]] || Beschreibung zur Erstellung eines Docker-Container
* [[Textdatei]], die mit verschiedenen Befehlen ein Image beschreibt
* werden bei der Ausführung abgearbeitet und für jeden Befehl wird ein einzelner Layer angelegt
|-
| [[Docker/Repository|Repository]] || Satz gleichnamiger Images mit verschiedenen Tags, zumeist Versionen
|-
| [[Docker/Registry|Registry]] || Verwaltung von Repositories (''Docker Hub'', ''Artifactory'', ...)
|}
 
=== Bibliotheken ===
{| class="wikitable options big"
|-
! Begriff !! Beschreibung
|-
| [[Docker/libcontainer|libcontainer]] || Schnittstelle zu den Grundfunktionen von Docker
|-
| [[Docker/libswarm|libswarm]] || Schnittstelle, um Docker-Container zu steuern
|-
| [[Docker/libchan|libchan]] || Einfache („light weighted“) Kommunikation zwischen Prozessteilen und Prozessen
|}
 
== Aufbau und Funktionen ==
; „Build, Ship and Run Any App, Anywhere“
[[Image:01_csm_virtuelle-maschinen-vs-docker-vergleich_2b58cdd628.webp|mini|400px|alt="Bild: Virtuelle Maschinen und Docker-Container im Vergleich"| Während jede virtuelle Maschine ein eigenes Betriebssystem startet, teilen sich Docker-Container den Kernel des Host-Systems ]]
 
Unter diesem Motto bewirbt die quelloffene Container-Plattform Docker eine flexible, ressourcensparende Alternative zur Emulation von Hardware-Komponenten auf Basis virtueller Maschinen (VMs)
* Während die '''klassische Hardware-Virtualisierung''' darauf beruht, mehrere Gastsysteme auf einem gemeinsamen Host-System zu starten, werden Anwendungen bei Docker mithilfe von '''Containern''' als isolierte Prozesse auf ein und demselben System ausgeführt
* Man spricht bei der containerbasierten Server-Virtualisierung daher auch von einer '''Operating-System-Level-Virtualisierung'''
 
Der Vorteil containerbasierter Virtualisierung liegt somit darin, dass sich Anwendungen mit unterschiedlichen Anforderungen isoliert voneinander ausführen lassen, ohne dass dafür der Overhead eines separaten Gastsystems in Kauf genommen werden muss
* Zusätzlich können Anwendungen mit Container '''plattformübergreifend und in unterschiedlichen Infrastrukturen''' eingesetzt werden, ohne dass diese an die Hard- oder Software-Konfigurationen des Hostsystems angepasst werden müssen
 
Docker ist das bekannteste Software-Projekt, das Anwendern und Anwenderinnen eine '''auf Containern basierende Virtualisierungstechnologie''' zur Verfügung stellt
* Die quelloffene Plattform setzt dabei auf drei grundlegende Komponenten: Um Container auszuführen, brauchen Anwender lediglich die '''[[Docker/Engine|Docker-Engine]]''' sowie spezielle '''[[Docker/Image|Docker-Images]]''', die sich über das '''[[Docker/Hub|Docker-Hub]]''' beziehen oder selbst erstellen lassen
 
=== Motivation ===
; Vereinfachte Bereitstellung von Anwendungen
* Container, die alle nötigen Pakete enthalten leicht als Dateien transportieren und installieren lassen
* Geringerer Overhead durch geteilten Host-Kernel
* Schnelle Start- und Stopzeiten
* Hohe Dichte isolierter Instanzen pro Host
* Prozess- und Abhängigkeitsisolation (Namespaces, cgroups)
* Reproduzierbare Laufzeitumgebungen durch unveränderliche Images
* Portabilität über unterschiedliche Hosts und Plattformen
* Feingranulares Ressourcen- und Zugriffsmanagement
* Vereinfachtes Lebenszyklus-Management
 
; Container gewährleisten
Trennung und Verwaltung der auf einem Rechner genutzten Ressourcen
* Code
* Laufzeitmodul
* Systemwerkzeuge
* Systembibliotheken
* alles was auf einem Rechner installiert werden kann
 
=== Container ===
; Sandbox-Prozess
Ein Container ist ein Sandbox-Prozess, der auf einem Host-Computer ausgeführt wird und von allen anderen auf diesem Host-Computer ausgeführten Prozessen isoliert ist
* Diese Isolierung nutzt Kernel-Namespaces und cgroups, Funktionen, die es in Linux schon seit langem gibt
* Docker macht diese Funktionen zugänglich und einfach zu verwenden
* Ein ist Container eine lauffähige Instanz eines Images
 
; Container werden über die Docker-API oder die Befehlszeilenschnittstelle
* erstellt
* gestartet
* angehalten
* verschoben
* gelöscht
 
; Er kann auf lokalen oder virtuellen Maschinen ausgeführt oder in der Cloud bereitgestellt werden
* Er ist portabel (und kann auf jedem Betriebssystem ausgeführt werden)
* Er ist von anderen Containern isoliert und führt seine eigene Software, Binärdateien, Konfigurationen usw
 
; Erweiterte Form von chroot
* Das Dateisystem wird aus einem Image bereitgestellt
* Allerdings bietet der Container eine zusätzliche Isolation, die mit chroot nicht möglich ist


; Vorteile
; Siehe auch
Container sind nützlich, wenn an mehreren Stellen eine identische Arbeitsumgebung benötigt wird
* [[Docker/Container|Container]]
* Man kann dabei entweder die Images (fertige Dateien) oder die Dockerfiles (Anweisungen zum Erzeugen eines Images) im Projekt verteilen
* Tatsächlich ist es nicht unüblich, ein Dockerfile in das Projekt-Repo mit einzuchecken


; Kein Sicherheitsgewinn
=== Bereitstellung ===
Durch Container hat man allerdings im Gegensatz zu herkömmlichen VMs keinen Sicherheitsgewinn, da die im Container laufende Software ja direkt auf dem Host-Betriebssystem ausgeführt wird
; Image oder Dockerfile
* Fertige Images
* Dockerfiles
** Anweisungen zum Erzeugen eines Images (Dockerfiles ) im Projekt verteilen
** Dockerfiles können gut in Projekt-Repositoies bereitgestellt werden


; Fertige Images
=== Fertige Images ===
Es gibt auf DockerHub fertige Images, die man sich ziehen und starten kann
DockerHub bietet fertige Images
* Ein solches gestartetes Image nennt sich dann Container und enthält beispielsweise Dateien, die in den Container gemountet oder kopiert werden
* Ein solches gestartetes Image nennt sich dann Container und enthält beispielsweise Dateien, die in den Container gemountet oder kopiert werden
* Man kann auch eigene Images bauen, indem man eine entsprechende Konfiguration (Dockerfile) schreibt
* Man kann auch eigene Images bauen, indem man eine entsprechende Konfiguration (Dockerfile) schreibt
Zeile 28: Zeile 140:
In der Konfiguration einer Gitlab-CI-Pipeline kann man mit <code>image</code> ein Docker-Image angeben, welches dann in der Pipeline genutzt wird
In der Konfiguration einer Gitlab-CI-Pipeline kann man mit <code>image</code> ein Docker-Image angeben, welches dann in der Pipeline genutzt wird


; VSCode
=== Docker Images ===
VSCode kann über das Remote-Plugin sich (u.a.) mit Containern verbinden und dann im Container arbeiten (editieren, compilieren, debuggen, testen, ...)
Ähnlich wie virtuelle Maschinen basieren Docker-Container auf [[Docker/Image|Images]]


In dieser kurzen Einheit kann ich Ihnen nur einen ersten Einstieg in das Thema geben
; Schreibgeschützte Vorlage
* Wir haben uns beispielsweise nicht Docker Compose oder Kubernetes angeschaut, und auch die Themen Netzwerk (zwischen Containern oder zwischen Containern und anderen Rechnern) und Volumnes habe ich außen vor gelassen
Dieses isolierte Dateisystem wird von einem Image bereitgestellt, und das Image muss alles enthalten, was zur Ausführung einer Anwendung erforderlich ist - alle Abhängigkeiten, Konfigurationen, Skripte, Binärdateien und so weiter.
* Dennoch kommt man in der Praxis bereits mit den hier vermittelten Basiskenntnissen erstaunlich weit


; Videos (YouTube)
; Portables Abbild eines Containers
* VL Einführung in Docker
Als wird ein Docker-Image in Form einer Textdatei beschrieben – man spricht von einem [[Docker/Dockerfile|Dockerfile]]
* Demo Container in der Konsole
* Soll ein Container auf einem System gestartet werden, wird zunächst ein Paket mit dem jeweiligen Image geladen – sofern dieses nicht lokal vorliegt
* Demo GitLab CI/CD und Docker
* Das geladene Image stellt das für die Laufzeit benötigte '''Dateisystem inklusive aller Parameter''' bereit
* Demo GitHub Actions und Docker
* Ein Container kann als laufender Prozess eines Images betrachtet werden
* Demo VSCode und Docker


; Videos (HSBI-Medienportal)
; Siehe auch
* VL Einführung in Docker
* [[Docker/Images selbst definieren|Images selbst definieren]]


; Lernziele
== Docker-Engine ==
* (K2) Unterschied zwischen Containern und VMs
Mit [[Docker/Befehle|Docker-Befehlen]] können Anwenderinnen und Anwender Software-Container direkt aus dem Terminal starten, stoppen und verwalten
* (K2) Einsatzgebiete für Container
* Die Ansprache des Daemon erfolgt über das Kommando dockerund Anweisungen wie build (erstelle), pull (lade herunter) oder run (starte)
* (K2) Container laufen als abgeschottete Prozesse auf dem Host - kein Sandbox-Effekt
* Client und Server können sich dabei auf dem gleichen System befinden
* (K3) Container von DockerHub ziehen
* Alternativ steht Anwendern die Möglichkeit offen, einen Docker-Daemon auf einem anderen System anzusprechen
* (K3) Container starten
* Je nachdem, welche Art von Verbindung aufgebaut werden soll, erfolgt die Kommunikation zwischen Client und Server über die REST-API, über UNIX-Sockets oder eine Netzwerkschnittstelle
* (K3) Eigene Container definieren und bauen
* (K3) Einsatz von Containern in GitLab CI/CD und GitHub Actions
* (K3) Einsatz von VSCode und Containern


=== Motivation ===
=== Komponenten ===
; <nowiki>Motivation CI/CD: WFM (''Works For Me'')</nowiki>
Zusammenspiel der Docker-Komponenten
Auf dem CI-Server muss man eine Arbeitsumgebung konfigurieren und bereitstellen, für Java-basierte Projekte muss beispielsweise ein JDK existieren und man benötigt Tools wie Maven oder Gradle, um die Buildskripte auszuführen
[[Image:03_csm_schematische-darstellung-docker-architektur_0cbba145c8.webp|mini|400px|alt="Bild: Schematische Darstellung der Docker-Architektur"|Die Docker-Architektur basiert auf einem Zusammenspiel aus Client (Terminal), Server (Docker-Daemon) und Registry (Docker-Hub)]]
* Je nach Projekt braucht man dann noch weitere Tools und Bibliotheken
 
* Diese Konfigurationen sind unabhängig vom CI-Server und werden üblicherweise nicht direkt installiert, sondern über eine Virtualisierung bereitgestellt
; Beispiel
* docker build
* docker pull
* docker run


Selbst wenn man keine CI-Pipelines einsetzt, hat man in Projekten mit mehreren beteiligten Personen häufig das Problem "''WFM''" ("works for me")
; docker build
* Jeder Entwickler hat sich auf ihrem Rechner eine Entwicklungsumgebung aufgesetzt und nutzt in der Regel seine bevorzugte IDE oder sogar unterschiedliche JDK-Versionen
Das Kommando docker build weist den Docker-Daemon an, ein Image zu erstellen (gepunktete Linie)
* Dadurch kann es schnell passieren, dass Probleme oder Fehler auftreten, die sich nicht von allen Beteiligten immer nachvollziehen lassen
* Dazu muss ein entsprechendes [[Dockerfile]] vorliegen
* Hier wäre eine einheitliche Entwicklungsumgebung sinnvoll, die in einer "schlanken" Virtualisierung bereitgestellt wird


Als Entwickler kann man zeitgleich in verschiedenen Projekten beteiligt sein, die unterschiedliche Anforderungen an die Entwicklungstools mit sich bringen
Soll das Image nicht selbst erstellt, sondern aus einem Repository im Docker-Hub geladen werden, kommt das Kommando docker pull zum Einsatz (gestrichelte Linie)
* Es könnte beispielsweise passieren, dass man zeitgleich drei bestimmte Python-Versionen benötigt
* Wird der Docker-Daemon via docker run angewiesen, einen Container zu starten, prüft das Hintergrundprogramm zunächst, ob das entsprechende Container-Image lokal vorliegt
* In den meisten Fällen schafft man es (mit ein wenig Aufwand), diese Tools nebeneinander zu installieren
* Ist dies der Fall, wird der Container ausgeführt (durchgezogene Linie)
* Oft ist das in der Praxis aber schwierig und fehleranfällig
* Kann der Daemon das Image nicht finden, leitet dieser automatisch ein Pulling aus dem Repository ein


In diesen Fällen kann eine Virtualisierung helfen
=== Betriebssysteme ===
; Virtualisierung mit [[Linux]]
Docker auf die Virtualisierung mit [[Linux]] ausgerichtet
* Docker-Technologie benötigt einen [[Linux-Kernel]]


=== Container vs.&nbsp;VM ===
== Container und Virtuelle Maschinen ==
Wenn man über Virtualisierung auf dem Desktop spricht, kann man grob zwei Varianten unterscheiden
; Varianten
* In beiden Fällen ist die Basis die Hardware (Laptop, Desktop-Rechner) und das darauf laufende (Host-) Betriebssystem (Linux, FreeBSD, macOS, Windows, ...)
* Hardware
* Darauf läuft dann wiederum die Virtualisierung
* Betriebssystem
** Linux, FreeBSD, macOS, Windows, …
* Virtualisierung


Im rechten Bild wird eine herkömmliche Virtualisierung mit virtuellen Maschinen (''VM'') dargestellt
=== Herkömmliche Virtualisierung ===
<s>Im rechten Bild</s> wird eine herkömmliche Virtualisierung mit virtuellen Maschinen (''VM'') dargestellt
* Dabei wird in der VM ein komplettes Betriebssystem (das "Gast-Betriebssystem") installiert und darin läuft dann die gewünschte Anwendung
* Dabei wird in der VM ein komplettes Betriebssystem (das "Gast-Betriebssystem") installiert und darin läuft dann die gewünschte Anwendung
* Die Virtualisierung (VirtualBox, VMware, ...) läuft dabei als Anwendung auf dem Host-Betriebssystem und stellt dem Gast-Betriebssystem in der VM einen Rechner mit CPU, RAM,  
* Die Virtualisierung (VirtualBox, VMware, ...) läuft dabei als Anwendung auf dem Host-Betriebssystem und stellt dem Gast-Betriebssystem in der VM einen Rechner mit CPU, RAM, zur Verfügung und übersetzt die Systemaufrufe in der VM in die entsprechenden Aufrufe im Host-Betriebssystem
* zur Verfügung und übersetzt die Systemaufrufe in der VM in die entsprechenden Aufrufe im Host-Betriebssystem
* Dies benötigt in der Regel entsprechende Ressourcen: Durch das komplette Betriebssystem in der VM ist eine VM (die als Datei im Filesystem des Host-Betriebssystems liegt) oft mehrere 10GB groß
* Dies benötigt in der Regel entsprechende Ressourcen: Durch das komplette Betriebssystem in der VM ist eine VM (die als Datei im Filesystem des Host-Betriebssystems liegt) oft mehrere 10GB groß
* Für die Übersetzung werden zusätzlich Hardwareressourcen benötigt, d.h
* Für die Übersetzung werden zusätzlich Hardwareressourcen benötigt, d.&nbsp;h.&nbsp;hier gehen CPU-Zyklen und RAM "verloren"  
* hier gehen CPU-Zyklen und RAM "verloren"  
* Das Starten einer VM dauert entsprechend lange, da hier ein komplettes Betriebssystem hochgefahren werden muss
* Das Starten einer VM dauert entsprechend lange, da hier ein komplettes Betriebssystem hochgefahren werden muss
* Dafür sind die Prozesse in einer VM relativ stark vom Host-Betriebssystem abgekapselt, so dass man hier von einer "Sandbox" sprechen kann: Viren o.ä
* Dafür sind die Prozesse in einer VM relativ stark vom Host-Betriebssystem abgekapselt, so dass man hier von einer "Sandbox" sprechen kann: Viren o.ä
* können nicht so leicht aus einer VM "ausbrechen" und auf das Host-Betriebssystem zugreifen (quasi nur über Lücken im Gast-Betriebssystem kombiniert mit Lücken in der Virtualisierungssoftware)
* können nicht so leicht aus einer VM "ausbrechen" und auf das Host-Betriebssystem zugreifen (quasi nur über Lücken im Gast-Betriebssystem kombiniert mit Lücken in der Virtualisierungssoftware)


Im linken Bild ist eine schlanke Virtualisierung auf Containerbasis dargestellt
=== Virtualisierung auf Containerbasis ===
<s>Im linken Bild</s> ist eine schlanke Virtualisierung auf Containerbasis dargestellt
* Die Anwendungen laufen direkt als Prozesse im Host-Betriebssystem, ein Gast-Betriebssystem ist nicht notwendig
* Die Anwendungen laufen direkt als Prozesse im Host-Betriebssystem, ein Gast-Betriebssystem ist nicht notwendig
* Durch den geschickten Einsatz von <code>namespaces</code> und <code>cgroups</code> und anderen in Linux und FreeBSD verfügbaren Techniken werden die Prozesse abgeschottet, d.h
* Durch den geschickten Einsatz von <code>namespaces</code> und <code>cgroups</code> und anderen in Linux und FreeBSD verfügbaren Techniken werden die Prozesse abgeschottet, d.&nbsp;h.&nbsp;der im Container laufende Prozess "sieht" die anderen Prozesse des Hosts nicht
* der im Container laufende Prozess "sieht" die anderen Prozesse des Hosts nicht
* Die Erstellung und Steuerung der Container übernimmt hier beispielsweise Docker
* Die Erstellung und Steuerung der Container übernimmt hier beispielsweise Docker
* Die Container sind dabei auch wieder Dateien im Host-Filesystem
* Die Container sind dabei auch wieder Dateien im Host-Filesystem
Zeile 101: Zeile 214:


In allen Fällen muss die Hardwarearchitektur beachtet werden: Auf einer Intel-Maschine können normalerweise keine VMs/Container basierend auf ARM-Architektur ausgeführt werden und umgekehrt
In allen Fällen muss die Hardwarearchitektur beachtet werden: Auf einer Intel-Maschine können normalerweise keine VMs/Container basierend auf ARM-Architektur ausgeführt werden und umgekehrt
<noinclude>


== Anhang ==
== Anhang ==
=== Siehe auch ===
=== Siehe auch ===
; Kategorien
<div style="column-count:2">
<div style="column-count:2">
<categorytree hideroot=on mode="pages">Docker</categorytree>
<categorytree hideroot=on mode="category">Docker</categorytree>
</div>
</div>
----
; Unterseiten
{{Special:PrefixIndex/{{BASEPAGENAME}}/}}
{{Special:PrefixIndex/Docker/}}


=== Links ===
=== Links ===
==== Weblinks ====
==== Weblinks ====
# https://docs.docker.com
# https://hub.docker.com/search
# https://de.wikipedia.org/wiki/Docker_(Software)
# https://www.hsbi.de/elearning/data/FH-Bielefeld/lm_data/lm_1359639/building/docker.html
# https://www.hsbi.de/elearning/data/FH-Bielefeld/lm_data/lm_1359639/building/docker.html
[[Kategorie:Docker]]
</noinclude>
= TMP =
'''Docker''' - Isolierung von Anwendungen durch [[Containervirtualisierung]]
== Bereitstellung von Anwendungen ==
* Vereinfachung weil sich
* Container, die alle nötigen Pakete enthalten
* leicht als Dateien transportieren und installieren lassen
Container gewährleisten die Trennung und Verwaltung der auf einem Rechner genutzten Ressourcen
* Code
* Laufzeitmodul
* Systemwerkzeuge
* Systembibliotheken
* alles was auf einem Rechner installiert werden kann
<br clear=all>
== Virtualisierung mit Linux ==
Prinzipiell ist Docker auf die Virtualisierung mit [[Linux]] ausgerichtet
* Da die Docker-Technologie einen Linux-Kernel benötigt, muss für die Nutzung unter [[Microsoft Windows]] die Virtualisierung genutzt werden
* Docker kann dort mittels [[Windows-Subsystem für Linux#WSL 2|WSL 2]] (Standard) oder [[VirtualBox]] verwendet werden
* Auf [[macOS]] lässt sich HyperKit oder VirtualBox nutzen
== Ressourcentrennung ==
Da die Ressourcentrennung alleine mit den Docker zugrunde liegenden Techniken wie Namespaces und Cgroups nicht völlig sicher ist
* hat das Unternehmen [[Red Hat]] Unterstützung für die sicherheitsrelevante Kernel-Erweiterung [[SELinux]] implementiert
* welche die Container auf der Ebene des Host-Systems zusätzlich absichert
== Realisierung von Containern ==
[[Datei:Docker-linux-interfaces.svg|mini|500px|Schnittstellen, um auf Virtualisierungsfunktionen des Linux-Kernels zuzugreifen.]]
Linux-Techniken
* [[Cgroups]]
* [[Namespaces]]
* Anfänglich [[LXC]]-Schnittstelle des [[Linux (Kernel)|Linux-Kernels]]
* Mittlerweile eine eigene [[Programmierschnittstelle]] namens ''libcontainer''
* Als Speicher-[[Frontend und Backend|Backend]] verwendet Docker das Overlay-Dateisystem [[aufs]]
** seit Version 0.8 wird auch [[btrfs]] unterstützt
<br clear=all>
== Begriffe ==
{| class="wikitable options big"
|-
! Begriff !! Beschreibung
|-
|  Image ||  [[Image-Datei|Speicherabbild]] eines Containers
* Das Image selbst besteht aus mehreren Layern, die schreibgeschützt sind und somit nicht verändert werden können
* Ein Image ist portabel, kann in [[Repository|Repositories]] gespeichert und mit anderen Nutzern geteilt werden
* Aus einem Image können immer mehrere Container gestartet werden
|-
|  Container ||  Aktive Instanz eines Images
* Der Container wird also gerade ausgeführt und ist beschäftigt
* Sobald der Container kein Programm ausführt oder mit seinem Auftrag fertig ist, wird der Container automatisch beendet
|-
|  Layer ||  Teil eines Images und enthält einen Befehl oder eine Datei, die dem Image hinzugefügt wurde
* Anhand der Layer kann die ganze Historie des Images nachvollzogen werden
|-
|  Dockerfile ||  [[Textdatei]], die mit verschiedenen Befehlen ein Image beschreibt
* Diese werden bei der Ausführung abgearbeitet und für jeden Befehl wird ein einzelner Layer angelegt
|-
|  Repository ||  Satz gleichnamiger Images mit verschiedenen Tags, zumeist Versionen
|-
|  Registry ||  Verwaltung von Repositories (''Docker Hub'', ''Artifactory'', ...)
|-
|  libcontainer ||  eine Schnittstelle zu den Grundfunktionen von Docker
|-
|  libswarm ||  eine Schnittstelle, um Docker-Container zu steuern
|-
|  libchan ||  ermöglicht eine einfache („light weighted“) Kommunikation zwischen Prozessteilen und Prozessen
|}
== Sicherheitsaspekte ==
; Root-Rechte
Docker-Container werden durch einen [[Daemon]] erzeugt, der in der Vergangenheit zwingend ''[[Root-Konto|root]]''-Rechte haben musste, ab Version 19.03 unter bestimmten Umständen aber auch unprivilegiert sein kann
* Läuft der Daemon mit ''root''-Rechten, bedient man sich oft einer eigenen Nutzergruppe, um auch unprivilegierten Nutzern die Erzeugung neuer Docker-Container zu erlauben
; Unprivilegierten Nutzer
Ein möglicher Fallstrick besteht darin, dass alle unprivilegierten Nutzer, die Mitglied einer solchen Nutzergruppe sind, indirekt über volle ''root''-Rechte auf dem [[Hostrechner|Host-System]] verfügen
* Die alternative Software für Containervirtualisierung ''Podman'' verzichtet auf dieses Sicherheitsrisiko, ist zu Docker kompatibel und angepasst auf [[Kubernetes]]
; Format
Die [[Open Container Initiative]] spezifiziert ein Format zur [[Containervirtualisierung]]
* Da es sich um eine internationale und offene Spezifikation handelt, kann prinzipiell jeder diese [[Implementierung#Softwaretechnik|implementieren]]
* So sind sicherere Alternativen zu Docker entstanden, zu denen man vorhandene Images oder Container migrieren kann – etwa ''containerd'' oder ''Podman''
* Trotz Standardisierung gibt es kleinere Unterschiede, etwa im Speicherort von Container und Images
; Unterschiede zu [[Virtuelle Maschine|Virtuellen Maschinen]]
Im Unterschied zu einer [[Virtuelle Maschine|Virtuellen Maschine]] teilen sich Container und Host einen gemeinsamen [[Kernel (Betriebssystem)|Betriebssystem-Kernel]]
* Dies verbessert einerseits die Leistung erheblich, vergrößert andererseits aber auch das Risiko, dass erfolgreiche Angriffe gegen den Kernel auch den Host kompromittieren
Bei richtiger Konfiguration sind selbst ''root''-Rechte innerhalb eines Docker-Containers nicht dazu geeignet, um den Host anzugreifen
* Insbesondere sollte dazu ein neuer ''User Namespace'' erzeugt und der ''root''-Benutzer des Containers auf einen unprivilegierten Benutzer des Hosts abgebildet werden
== Weblinks ==
# https://de.wikipedia.org/wiki/Docker_(Software)
# [https://www.docker.com/ Offizielle Website]
# [https://www.docker.com/ Offizielle Website]
# [http://www.admin-magazin.de/Das-Heft/2014/02/Renaissance-der-Container-Virtualisierung-mit-Docker Renaissance der Container-Virtualisierung mit Docker]
# [http://www.admin-magazin.de/Das-Heft/2014/02/Renaissance-der-Container-Virtualisierung-mit-Docker Renaissance der Container-Virtualisierung mit Docker]
Zeile 219: Zeile 235:


[[Kategorie:Docker]]
[[Kategorie:Docker]]
</noinclude>

Aktuelle Version vom 13. November 2025, 13:27 Uhr

Docker - Isolierung von Anwendungen durch Container-Virtualisierung

Beschreibung

Schlanke Frorm der Virtualisierungen
  • Prozesse laufen auf dem Kernel des Host-Betriebssystems
  • Abschottung durch

Linzenz

Docker ist freie Software

Realisierung von Containern

Linux-Techniken
Schnittstellen, um auf Virtualisierungsfunktionen des Linux-Kernels zuzugreifen.


Begriffe

Begriff Beschreibung
Volume Volumes ermöglichen es, dass Daten erhalten bleiben, auch wenn ein Docker-Container gelöscht wird. Volumes sind auch eine praktische Möglichkeit, Daten zwischen dem Host und dem Container auszutauschen.
Image Ein Docker-Image ist eine schreibgeschützte Vorlage, die von der Docker-Engine benutzt wird, um einen Container zu erzeugen.

Speicherabbild eines Containers

  • Das Image selbst besteht aus mehreren Layern, die schreibgeschützt sind und somit nicht verändert werden können
  • Ein Image ist portabel, kann in Repositories gespeichert und mit anderen Nutzern geteilt werden
  • Aus einem Image können immer mehrere Container gestartet werden
Container Docker-Container sind isolierte Ausführungseinheiten für Anwendungen und ihre Abhängigkeiten

Aktive Instanz eines Images

  • Der Container wird also gerade ausgeführt und ist beschäftigt
  • Sobald der Container kein Programm ausführt oder mit seinem Auftrag fertig ist, wird der Container automatisch beendet
Layer Teil eines Images und enthält einen Befehl oder eine Datei, die dem Image hinzugefügt wurde
  • Anhand der Layer kann die ganze Historie des Images nachvollzogen werden
Dockerfile Beschreibung zur Erstellung eines Docker-Container
  • Textdatei, die mit verschiedenen Befehlen ein Image beschreibt
  • werden bei der Ausführung abgearbeitet und für jeden Befehl wird ein einzelner Layer angelegt
Repository Satz gleichnamiger Images mit verschiedenen Tags, zumeist Versionen
Registry Verwaltung von Repositories (Docker Hub, Artifactory, ...)

Bibliotheken

Begriff Beschreibung
libcontainer Schnittstelle zu den Grundfunktionen von Docker
libswarm Schnittstelle, um Docker-Container zu steuern
libchan Einfache („light weighted“) Kommunikation zwischen Prozessteilen und Prozessen

Aufbau und Funktionen

„Build, Ship and Run Any App, Anywhere“
"Bild: Virtuelle Maschinen und Docker-Container im Vergleich"
Während jede virtuelle Maschine ein eigenes Betriebssystem startet, teilen sich Docker-Container den Kernel des Host-Systems

Unter diesem Motto bewirbt die quelloffene Container-Plattform Docker eine flexible, ressourcensparende Alternative zur Emulation von Hardware-Komponenten auf Basis virtueller Maschinen (VMs)

  • Während die klassische Hardware-Virtualisierung darauf beruht, mehrere Gastsysteme auf einem gemeinsamen Host-System zu starten, werden Anwendungen bei Docker mithilfe von Containern als isolierte Prozesse auf ein und demselben System ausgeführt
  • Man spricht bei der containerbasierten Server-Virtualisierung daher auch von einer Operating-System-Level-Virtualisierung

Der Vorteil containerbasierter Virtualisierung liegt somit darin, dass sich Anwendungen mit unterschiedlichen Anforderungen isoliert voneinander ausführen lassen, ohne dass dafür der Overhead eines separaten Gastsystems in Kauf genommen werden muss

  • Zusätzlich können Anwendungen mit Container plattformübergreifend und in unterschiedlichen Infrastrukturen eingesetzt werden, ohne dass diese an die Hard- oder Software-Konfigurationen des Hostsystems angepasst werden müssen

Docker ist das bekannteste Software-Projekt, das Anwendern und Anwenderinnen eine auf Containern basierende Virtualisierungstechnologie zur Verfügung stellt

  • Die quelloffene Plattform setzt dabei auf drei grundlegende Komponenten: Um Container auszuführen, brauchen Anwender lediglich die Docker-Engine sowie spezielle Docker-Images, die sich über das Docker-Hub beziehen oder selbst erstellen lassen

Motivation

Vereinfachte Bereitstellung von Anwendungen
  • Container, die alle nötigen Pakete enthalten leicht als Dateien transportieren und installieren lassen
  • Geringerer Overhead durch geteilten Host-Kernel
  • Schnelle Start- und Stopzeiten
  • Hohe Dichte isolierter Instanzen pro Host
  • Prozess- und Abhängigkeitsisolation (Namespaces, cgroups)
  • Reproduzierbare Laufzeitumgebungen durch unveränderliche Images
  • Portabilität über unterschiedliche Hosts und Plattformen
  • Feingranulares Ressourcen- und Zugriffsmanagement
  • Vereinfachtes Lebenszyklus-Management
Container gewährleisten

Trennung und Verwaltung der auf einem Rechner genutzten Ressourcen

  • Code
  • Laufzeitmodul
  • Systemwerkzeuge
  • Systembibliotheken
  • alles was auf einem Rechner installiert werden kann

Container

Sandbox-Prozess

Ein Container ist ein Sandbox-Prozess, der auf einem Host-Computer ausgeführt wird und von allen anderen auf diesem Host-Computer ausgeführten Prozessen isoliert ist

  • Diese Isolierung nutzt Kernel-Namespaces und cgroups, Funktionen, die es in Linux schon seit langem gibt
  • Docker macht diese Funktionen zugänglich und einfach zu verwenden
  • Ein ist Container eine lauffähige Instanz eines Images
Container werden über die Docker-API oder die Befehlszeilenschnittstelle
  • erstellt
  • gestartet
  • angehalten
  • verschoben
  • gelöscht
Er kann auf lokalen oder virtuellen Maschinen ausgeführt oder in der Cloud bereitgestellt werden
  • Er ist portabel (und kann auf jedem Betriebssystem ausgeführt werden)
  • Er ist von anderen Containern isoliert und führt seine eigene Software, Binärdateien, Konfigurationen usw
Erweiterte Form von chroot
  • Das Dateisystem wird aus einem Image bereitgestellt
  • Allerdings bietet der Container eine zusätzliche Isolation, die mit chroot nicht möglich ist
Siehe auch

Bereitstellung

Image oder Dockerfile
  • Fertige Images
  • Dockerfiles
    • Anweisungen zum Erzeugen eines Images (Dockerfiles ) im Projekt verteilen
    • Dockerfiles können gut in Projekt-Repositoies bereitgestellt werden

Fertige Images

DockerHub bietet fertige Images

  • Ein solches gestartetes Image nennt sich dann Container und enthält beispielsweise Dateien, die in den Container gemountet oder kopiert werden
  • Man kann auch eigene Images bauen, indem man eine entsprechende Konfiguration (Dockerfile) schreibt
  • Jeder Befehl bei der Erstellung eines Images erzeugt einen neuen Layer, die sich dadurch mehrere Images teilen können

In der Konfiguration einer Gitlab-CI-Pipeline kann man mit image ein Docker-Image angeben, welches dann in der Pipeline genutzt wird

Docker Images

Ähnlich wie virtuelle Maschinen basieren Docker-Container auf Images

Schreibgeschützte Vorlage

Dieses isolierte Dateisystem wird von einem Image bereitgestellt, und das Image muss alles enthalten, was zur Ausführung einer Anwendung erforderlich ist - alle Abhängigkeiten, Konfigurationen, Skripte, Binärdateien und so weiter.

Portables Abbild eines Containers

Als wird ein Docker-Image in Form einer Textdatei beschrieben – man spricht von einem Dockerfile

  • Soll ein Container auf einem System gestartet werden, wird zunächst ein Paket mit dem jeweiligen Image geladen – sofern dieses nicht lokal vorliegt
  • Das geladene Image stellt das für die Laufzeit benötigte Dateisystem inklusive aller Parameter bereit
  • Ein Container kann als laufender Prozess eines Images betrachtet werden
Siehe auch

Docker-Engine

Mit Docker-Befehlen können Anwenderinnen und Anwender Software-Container direkt aus dem Terminal starten, stoppen und verwalten

  • Die Ansprache des Daemon erfolgt über das Kommando dockerund Anweisungen wie build (erstelle), pull (lade herunter) oder run (starte)
  • Client und Server können sich dabei auf dem gleichen System befinden
  • Alternativ steht Anwendern die Möglichkeit offen, einen Docker-Daemon auf einem anderen System anzusprechen
  • Je nachdem, welche Art von Verbindung aufgebaut werden soll, erfolgt die Kommunikation zwischen Client und Server über die REST-API, über UNIX-Sockets oder eine Netzwerkschnittstelle

Komponenten

Zusammenspiel der Docker-Komponenten

"Bild: Schematische Darstellung der Docker-Architektur"
Die Docker-Architektur basiert auf einem Zusammenspiel aus Client (Terminal), Server (Docker-Daemon) und Registry (Docker-Hub)
Beispiel
  • docker build
  • docker pull
  • docker run
docker build

Das Kommando docker build weist den Docker-Daemon an, ein Image zu erstellen (gepunktete Linie)

Soll das Image nicht selbst erstellt, sondern aus einem Repository im Docker-Hub geladen werden, kommt das Kommando docker pull zum Einsatz (gestrichelte Linie)

  • Wird der Docker-Daemon via docker run angewiesen, einen Container zu starten, prüft das Hintergrundprogramm zunächst, ob das entsprechende Container-Image lokal vorliegt
  • Ist dies der Fall, wird der Container ausgeführt (durchgezogene Linie)
  • Kann der Daemon das Image nicht finden, leitet dieser automatisch ein Pulling aus dem Repository ein

Betriebssysteme

Virtualisierung mit Linux

Docker auf die Virtualisierung mit Linux ausgerichtet

Container und Virtuelle Maschinen

Varianten
  • Hardware
  • Betriebssystem
    • Linux, FreeBSD, macOS, Windows, …
  • Virtualisierung

Herkömmliche Virtualisierung

Im rechten Bild wird eine herkömmliche Virtualisierung mit virtuellen Maschinen (VM) dargestellt

  • Dabei wird in der VM ein komplettes Betriebssystem (das "Gast-Betriebssystem") installiert und darin läuft dann die gewünschte Anwendung
  • Die Virtualisierung (VirtualBox, VMware, ...) läuft dabei als Anwendung auf dem Host-Betriebssystem und stellt dem Gast-Betriebssystem in der VM einen Rechner mit CPU, RAM, zur Verfügung und übersetzt die Systemaufrufe in der VM in die entsprechenden Aufrufe im Host-Betriebssystem
  • Dies benötigt in der Regel entsprechende Ressourcen: Durch das komplette Betriebssystem in der VM ist eine VM (die als Datei im Filesystem des Host-Betriebssystems liegt) oft mehrere 10GB groß
  • Für die Übersetzung werden zusätzlich Hardwareressourcen benötigt, d. h. hier gehen CPU-Zyklen und RAM "verloren"
  • Das Starten einer VM dauert entsprechend lange, da hier ein komplettes Betriebssystem hochgefahren werden muss
  • Dafür sind die Prozesse in einer VM relativ stark vom Host-Betriebssystem abgekapselt, so dass man hier von einer "Sandbox" sprechen kann: Viren o.ä
  • können nicht so leicht aus einer VM "ausbrechen" und auf das Host-Betriebssystem zugreifen (quasi nur über Lücken im Gast-Betriebssystem kombiniert mit Lücken in der Virtualisierungssoftware)

Virtualisierung auf Containerbasis

Im linken Bild ist eine schlanke Virtualisierung auf Containerbasis dargestellt

  • Die Anwendungen laufen direkt als Prozesse im Host-Betriebssystem, ein Gast-Betriebssystem ist nicht notwendig
  • Durch den geschickten Einsatz von namespaces und cgroups und anderen in Linux und FreeBSD verfügbaren Techniken werden die Prozesse abgeschottet, d. h. der im Container laufende Prozess "sieht" die anderen Prozesse des Hosts nicht
  • Die Erstellung und Steuerung der Container übernimmt hier beispielsweise Docker
  • Die Container sind dabei auch wieder Dateien im Host-Filesystem
  • Dadurch benötigen Container wesentlich weniger Platz als herkömmliche VMs, der Start einer Anwendung geht deutlich schneller und die Hardwareressourcen (CPU, RAM, ...) werden effizient genutzt
  • Nachteilig ist, dass hier in der Regel ein Linux-Host benötigt wird (für Windows wird mittlerweile der Linux-Layer (WSL) genutzt; für macOS wurde bisher eine Linux-VM im Hintergrund hochgefahren, mittlerweile wird aber eine eigene schlanke Virtualisierung eingesetzt)
  • Außerdem steht im Container üblicherweise kein graphisches Benutzerinterface zur Verfügung
  • Da die Prozesse direkt im Host-Betriebssystem laufen, stellen Container keine Sicherheitsschicht ("Sandboxen") dar!

In allen Fällen muss die Hardwarearchitektur beachtet werden: Auf einer Intel-Maschine können normalerweise keine VMs/Container basierend auf ARM-Architektur ausgeführt werden und umgekehrt

Anhang

Siehe auch

Kategorien
Unterseiten

Links

Weblinks

  1. https://docs.docker.com
  2. https://hub.docker.com/search
  3. https://de.wikipedia.org/wiki/Docker_(Software)
  4. https://www.hsbi.de/elearning/data/FH-Bielefeld/lm_data/lm_1359639/building/docker.html
  5. Offizielle Website
  6. Renaissance der Container-Virtualisierung mit Docker
  7. Einführung und Praxisbeispiele / Übersicht Docker und Container-Virtualisierung


Abgerufen von „https://wiki.foxtom.de/index.php?title=Docker&oldid=157806“