Hier kommen Container-Techniken wie z.B. Docker ins Spiel: Sie isolieren einen Prozess vom Host-System. Der Prozess erh\u00e4lt sein eigenes Dateisystem und eine eigenen Bibliotheken\/Abh\u00e4ngigkeiten – ohne dabei den Host selbst oder andere Container zu beeinflussen. Dadurch k\u00f6nnen problemlos mehrere Versionen von Abh\u00e4ngigkeiten parallel genutzt werden, ohne sich in die Quere zu kommen.<\/p>\n
Welche Vorteile bieten Containertechnologien wie Docker auf dem Raspberry Pi?<\/h2>\n
Im folgenden betrachten wir die Vorteile aus Sicht eines Raspberry Pi. Diese unterscheiden sich in so fern von x86 Servern und Workstations, dass z.B. Docker und andere Containertechnologien oft mit virtuellen Maschinen verglichen werden. Auf dem Raspberry Pi dagegen lassen sich VMs aufgrund der geringen Leistung kaum sinnvoll einsetzen. Hier installiert man seine Anwendungen direkt auf dem Pi, ggf. mit mehreren Pis. Auch ein paar andere Vorteile sind auf dem Pi nicht oder zumindest weniger relevant.<\/p>\n
Reproduzierbarkeit & Flexibilit\u00e4t<\/h3>\n
Zwei klassische, per Hand konfigurierte Systeme sind selten identisch. Schon alleine weil das eine System vielleicht \u00f6fter geupgraded wurde als das andere, unterscheidet es sich minimal – m\u00f6glicherweise treten dadurch eines Tages Probleme auf, die nicht reproduzierbar sind. In einem Docker-Image f\u00fcgen wir aber nur die von uns explizit definierten Programme und Abh\u00e4ngigkeiten hinzu – es ist also klar definiert und reproduzierbar. Jeder Container, der auf Basis unseres Images erzeugt wird, verh\u00e4lt sich gleich. Wir k\u00f6nnen unsere Software also problemlos auf einem anderen Raspberry Pi \u00fcbertragen, sie wird funktionieren und sich gleich verhalten. Au\u00dferdem l\u00e4sst sich ein bestimmter Stand sehr einfach wiederherstellen.<\/p>\n
Sogar \u00fcber verschiedene Distributionen und teils Betriebssysteme hinweg. Wobei letzteres eher f\u00fcr den x86 Bereich relevant ist, beispielsweise wenn man unter Linux seine Docker-Container erstellt und jemand anders unter MacOS. Die Reproduzierbarkeit ist dagegen auch auf dem Pi n\u00fctzlich.<\/p>\n
Dokumentation s\u00e4mtlicher Abh\u00e4ngigkeiten (+ leichte Versionierbarkeit)<\/h3>\n
Dadurch haben wir automatisch alles dokumentiert, was wir f\u00fcr die Anwendung sowie deren Konfiguration brauchen. Zumindest im Vergleich zur h\u00e4ndischen Variante. Denn ohne Docker k\u00f6nnten wir nat\u00fcrlich auch Alternativen wie Ansible oder Shell-Skripte nutzen, um dies zu tun. Erfahrungsgem\u00e4\u00df geschieht dies in der Praxis aber oft nicht, bei Docker machen wir das dagegen automatisch, quasi nebenbei – und haben zus\u00e4tzliche Vorteile, da weder Ansible noch Shell-Skripte unsere Anwendungen ohne weiteres isolieren.<\/p>\n
Legen wir unsere Konfigurationsdateien in eine Versionverwaltung wie Git, sind \u00c4nderungen nachvollziehbar. Sollte es zu Problemen kommen, schauen wir uns den Verlauf an, stellen eine \u00e4ltere Version her. Nach dem Laden des Images bzw. vorherigem bauen entspricht die Umgebung dem jeweiligen \u00e4lteren Stand. Lediglich um externe Programme m\u00fcssen wir uns von Hand k\u00fcmmern, etwa das Schema einer Datenbank, die im Zuge eines Anwendungsupdates ver\u00e4ndert wurde.<\/p>\n
Aktuelle Software, ohne ein instabiles System zu riskieren<\/h3>\n
Klassische Distributionen wie Debian und damit Raspbian aktualisieren die per APT bereitgestellten Pakete oft nur mit Verz\u00f6gerung. Manche Pakete hinken den aktuellen stabilen Versionen der jeweiligen Programme sogar Jahre hinterher. H\u00e4ndisch neuere Pakete zu installieren bringt neue Probleme: M\u00f6glicherweise ist dies nicht mit den globalen Bibliotheken kompatibel, wodurch das System instabil werden kann. Installiert man h\u00e4ndisch ein Paket an der Paketverwaltung vorbei, wird es zudem nicht automatisch aktualisiert – es drohen auf Dauer Sicherheits- und Kompatibilit\u00e4tsprobleme.<\/p>\n
Durch die Isolation erlaubt es uns Docker, einzelne Programme in deutlich aktuelleren Versionen zu installieren. Etwa ein neues PHP-Update. Dies bringt uns neue Funktionen, behebt bekannte Bugs und liefert teils auch sicherheitskritische Updates schneller aus.<\/p>\n
Ein konkretes Beispiel ist der Webserver nginx<\/strong>: Die beim Verfassen des Artikels aktuellste stabile Version ist 1.20. In den Raspberry PI OS Paketquellen erhalten wir dagegen 1.14.2 aus dem Dezember 2018 – also etwa 2 3\/4 Jahre alt.<\/p>\n Auch Experimente sind dadurch leichter und ungef\u00e4hrlicher: Wir bauen ein Image (falls notwendig), erzeugen einen neuen Container und k\u00f6nnen leicht sowie gefahrlos etwas ausprobieren. Beispiel: PHP-Update von 7 auf 8. Den Tag auf 8 \u00e4ndern, das Image bauen und testen. Dies kann gefahrlos in einer zweiten Instanz (neues Image + neuer Container) ausprobiert werden, ohne unser Hauptsystem oder andere Komponenten zu gef\u00e4hrden. Durch den problemlosen Parallelbetrieb lassen sich auch direkte Vergleiche anstellen. Beispielsweise k\u00f6nnen wir das Hauptsystem einer Anwendung vorerst auf PHP 7 laufen lassen, parallel dazu aber eine Testinstanz mit PHP8 starten – und etwa die Geschwindigkeit beider Installationen messen.<\/p>\n Werden mehrere Anwendungen betrieben, m\u00f6chte man diese m\u00f6glichst voneinander isolieren – so hat z.B. eine Sicherheitsl\u00fccke darin nicht die Kompromittierung des gesamten Pis oder gar des Netzwerkes zur Folge. Klassisch ist dies zwar auch mit verschiedenen Techniken wie z.B. einem chroot-Jail m\u00f6glich, jedoch komplexer und aufw\u00e4ndiger als mit Containern – die ja schon von Grund auf daf\u00fcr konzipiert wurden, sich vor anderen Containern und dem Hostsystem zu isolieren. F\u00fcr maximale Sicherheit sollte man jedoch auch hier Best Practices beachten, wie z.B. m\u00f6glichst keine Prozesse dauerhaft als root laufen zu lassen.<\/p>\n Als Grundlage dient immer ein sogenanntes Image<\/strong>. Es besteht aus einem virtuellen Dateisystem, das aus mehreren Schichten aufgebaut wird. Man kann es sich ein wenig wie die Ebenen in Photoshop\/Gimp vorstellen: Auf jeder Ebene befinden sich verschiedene Elemente. \u00dcbereinandergelegt ergeben sie ein komplettes Bild mit dem gew\u00fcnschten Inhalt. Es gibt zwei Arten von Images.<\/p>\n F\u00fcr viele Programme und Anwendungsf\u00e4lle hat bereits jemand (im besten Falle der urspr\u00fcngliche Author\/Entwickler) ein Image erstellt. Dies ist der schnellste und einfachste Weg, ich w\u00fcrde ihn daher bevorzugen, sofern m\u00f6glich.<\/p>\n Wir k\u00f6nnen entweder ein fertiges Image erweitern oder ein komplett eigenes Erstellen. Ersteres ist oft einfacher, schneller und nachhaltiger. Dies ist eine der gr\u00f6\u00dften St\u00e4rken von Docker: Ben\u00f6tigen wir beispielsweise PHP mit bestimmten Erweiterungen, m\u00fcssen wir nicht von 0 auf ein Image mit der kompletten Installation\/Konfiguration von PHP erstellen – sondern erweitern das fertige PHP-Image mit dem, was fehlt bzw. ge\u00e4ndert werden soll. Vergleichbar mit Vererbung in der objektorientierten Programmierung: Statt eine Klasse zu kopieren und zu erweitern, erzeugen wir eine neue Klasse, die von der Basisklasse erbt und damit all deren Funktionen besitzt.<\/p>\n Was davon zum Einsatz kommt, h\u00e4ngt stark vom Anwendungszweck ab. Um Anwendungen von anderen zu Hosten, z.B. Nextcloud oder WordPress), kann man h\u00e4ufig fertige Images verwenden – zumindest wenn keine gr\u00f6\u00dferen Anpassungen gew\u00fcnscht sind. Das selbst Erstellen wird sp\u00e4testens dann notwendig, wenn eigene Anwendungen (z.B. Python-Skripte) dockerisiert werden sollen. Wobei man auch hier im Regelfall nicht von 0 auf anfangen muss, sondern im reichhaltigen Angebot des Docker-Hubs ein Image als Grundlage findet.<\/p>\n Ein wichtiger Unterschied zwischen fertigen und selbst erstellten Images<\/strong>: Fertige Images m\u00fcssen lediglich heruntergeladen werden, anschlie\u00dfend sind sie sofort einsatzbereit. Ein selbst erstelltes Image muss dagegen einmalig (bis zu entsprechenden \u00c4nderungen) gebaut werden. Dies kostet je nach Inhalt und Leistung\/Infrastruktur etwas Zeit, vor allem auf dem Raspberry Pi.<\/p>\n Du ben\u00f6tigst einen Raspberry Pi, am besten ein aktueller Pi 4. \u00c4ltere Modelle sind auch m\u00f6glich, aber langsamer und aufgrund der geringeren Ressourcen (haupts\u00e4chlich des Arbeitsspeichers) nur eingeschr\u00e4nkt nutzbar – wenngleich es prinzipiell auch dort funktioniert. Wie du Docker auf dem Pi installierst, haben wir in folgendem Beitrag bereits erkl\u00e4rt: Docker einfach auf dem Raspberry Pi installieren (Anleitung f\u00fcr Einsteiger)<\/a>.<\/p>\n Wenn docker ps eine leere Tabelle wie im folgenden Beispiel anzeigt, ist dein Raspberry Pi richtig eingerichtet:<\/p>\n Als einfaches Beispiel f\u00fcr den Start m\u00f6chten wir einen einfachen Webserver mit Docker starten. Ich entscheide mich f\u00fcr Nginx, da er aufgrund seiner Leichtgewichtigkeit f\u00fcr den Raspberry Pi gut geeignet ist. Prinzipiell k\u00f6nnten wir aber auch andere Alternativen wie Apache nehmen, dazu an anderer Stelle mehr. <\/p>\n Zuerst suchen wir im Docker-Hub nach einem passenden Image<\/a>. Wichtig ist hierbei, links den Filter bei Architectures<\/strong> auf ARM<\/strong> zu setzen. Der Raspberry Pi nutzt n\u00e4mlich eine andere Prozessorarchitektur, als die von den meisten Computern, Laptops und Servern gewohnte x86. Da diese nicht untereinander kompatibel sind, ben\u00f6tigen wir ARM-Kompatible Images. Ohne den Filter werden uns auch x86 Images angezeigt, die mit dem Pi nicht funktionieren.<\/p>\n Die Architektur k\u00f6nnen wir auf der Konsole mit dem Befehl uname<\/strong> pr\u00fcfen, der Schalter -m (f\u00fcr M<\/strong>achine) gibt uns die Prozessorarchitektur aus:<\/p>\n Auf dem Pi wird dies in den meisten F\u00e4llen armv7l<\/strong> ausgeben, das entspricht der 32-Bit Architektur von ARM. Wie bei x86 gibt es auch hier 32 und 64 Bit. Im Gegensatz dazu ist 32 Bit bei den Pis durch ihren bislang geringen Hauptspeicher noch sehr verbreitet. Das Raspberry Pi OS in 64 Bit ist noch recht jung und macht nur auf den ebenfalls neuen Raspberry Pi 4 mit 8 GB Arbeitsspeicher wirklich Sinn. Dort erhalten wir aarch64 <\/strong>statt armv7l<\/strong>. Unser Pi hat nur 4 GB RAM (Limit f\u00fcr 32 Bit Plattformen) und l\u00e4uft daher auf einem 32 Bit Raspberry Pi OS, weswegen wir in der Suche nur ARM<\/strong> als Filter ankreuzen.<\/p>\n Der erste Treffer ist ein offizielles Image<\/strong>. Es wurde also vom Entwickler\/Eigent\u00fcmer der jeweiligen Software (hier Nginx) selbst angefertigt und ist damit die vertrauensw\u00fcrdigste Quelle. Unter der Beschreibung sehen wir mit der schlagwort\u00e4hnlichen Ansicht, welche Architekturen unterst\u00fctzt werden. Dieses Image kann also unter einem 64 Bit x86 Computer genau so genutzt werden wie auf dem Raspberry Pi mit ARM 32\/64 Bit.<\/p>\n Weiter unten werden sich noch viele weitere Images finden. Das sind Community-Images<\/strong> – jeder kann Images erstellen und diese in den Docker-Hub hochladen. Grunds\u00e4tzlich eine gute Sache. Allerdings sollte man – wie generell bei fremder Software – dem Ersteller Vertrauen. Vorsicht ist auch bei \u00e4lteren Images geboten: Wenn diese seit l\u00e4ngerem keine Aktualisierungen erhalten haben, gibt es wahrscheinlich offene Sicherheitsl\u00fccken – eventuell auch Probleme mit der Software selbst, die in aktuelleren Versionen korrigiert wurden.<\/p>\n Tags kann man am ehesten mit den Versionen eines Programmes vergleichen. Im Regelfall findest du in der Beschreibung eine Liste aller verf\u00fcgbaren Tags. Diese ist am \u00fcbersichtlichsten, sofern vorhanden. Alternativ kannst du auch oben auf den Reiter Tags<\/strong> klicken.<\/p>\n Oft haben wir mit den Tags jedoch nicht nur die Wahl zwischen der bestimmten Version eines Programms, sondern noch mehr: <\/p>\n F\u00fcr den Anfang brauchst du dir dar\u00fcber keine all zu gro\u00dfen Gedanken machen und solltest lediglich den latest<\/strong> Tag meiden. Wir nutzen zur Vereinfachung die derzeit aktuellste, exakte Version 1.21 – damit ist der Vergleich zu einer h\u00e4ndischen Installation am klarsten.<\/p>\n Damit haben wir unser Image nginx:1.21<\/strong> gefunden. Dies besteht im Folgenden immer aus einem Namen (nginx<\/strong>) und Tag (1.21<\/strong>). Mithilfe eines Images kann ein Container gestartet werden. Man kann sich Images \u00e4hnlich wie eine Schablone vorstellen. Es lassen sich also mehrere Container aus einem Image erstellen. Daf\u00fcr kommt im einfachsten Falle der Befehl docker run<\/strong> zum Einsatz:<\/p>\n So einfach l\u00e4sst sich ein Container starten. Ich empfehle, zus\u00e4tzlich immer einen frei w\u00e4hlbaren Name anzugeben. Ansonsten generiert Docker zuf\u00e4llige Namen. Das erschwert die Zuordnung sp\u00e4testens bei mehreren Containern. <\/p>\n Bei einem Webserver ben\u00f6tigen wir zudem mindestens eine Portweiterleitung. Ansonsten kann man den Webserver nicht erreichen, da Docker nicht nur das Dateisystem, sondern auch das Netzwerk des Containers isoliert. Dies geschieht mit dem Schalter -p 80:80. Dabei leiten wir Port 80 des Hosts (erste Angabe) auf Port 80 innerhalb des Containers.<\/p>\n Der erste Start dauert l\u00e4nger, da zun\u00e4chst das Image aus dem Docker-Hub geladen werden muss. Dies ist jedoch nur einmalig notwendig. Nach dem Start k\u00f6nnen wir den Webserver testen, in dem wir http:\/\/<\/strong> gefolgt vom DNS-Hostname des Pi oder seine IP-Adresse im Browser eingeben. Am einfachsten ist der Hostname, der im Regelfall vom Router aufgel\u00f6st wird – also der Name nach pi@<\/strong>, hier etwa testpi<\/strong>. Dort sollte nun die Standard-Willkommensseite des Nginx erscheinen:<\/p>\n Wie kann ich nun eigene Seiten \u00fcber den Nginx Webserver ausliefern, z.B. eine HTML Seite? Man k\u00f6nnte sich mit docker exec<\/strong> in den Container schalten und diese dort erstellen. Davon ist jedoch abzuraten: Container sind kurzlebig, sobald der Container neu erstellt wurde w\u00e4ren diese Daten verloren. Eine andere M\u00f6glichkeit w\u00e4re, ein eigenes Docker-Image zu auf Basis des Nginx zu erstellen. Dies ist ein wenig aufw\u00e4ndiger und wird daher Teil eines eigenen Artikels. An dieser Stelle schauen wir uns die einfachste und flexibelste L\u00f6sung f\u00fcr dieses Problem an: Volumes<\/strong>.<\/p>\n Ein Volume <\/strong>speichert persistente Daten, also jene die wir dauerhaft ben\u00f6tigen. Sie liegen au\u00dferhalb des Containers, sodass ein Volume auch dann bestehen bleibt, wenn wir den Container neu starten oder l\u00f6schen. Es gibt verwaltete (Managed) Volumes und sogenannte Bind Mounts<\/strong>. Letztere sind am einfachsten und f\u00fcr unser einfaches Beispielszenario am besten geeignet: Damit stellen wir einen Ordnerpfad auf dem Host ganz einfach dem Container zur Verf\u00fcgung – er wird im Container an der gew\u00fcnschten Stelle gemountet. Hierzu gibt es den -v Schalter:<\/strong><\/p>\n F\u00fcr unseren Webserver erstellen wir einen Ordner, beispielsweise \/home\/pi\/www<\/strong> und legen darin eine HTML-Seite namens index.html<\/strong> ab:<\/p>\n Damit dieser Ordner \u00fcber ein Bind Mount Volume dem Container zur Verf\u00fcgung steht, m\u00fcssen wir ihn neu erstellen. Zuvor den alten Container (der eben erstellt wurde) mit docker rm <Name><\/strong> f\u00fcr r<\/strong>em<\/strong>ove l\u00f6schen:<\/p>\n Und das Volume im docker run<\/strong> Befehl angeben. Das Ziel lautet \/usr\/share\/nginx\/html<\/strong>, da das Nginx-Image standardm\u00e4\u00dfig diesen Ordner als Webroot nutzt. Mit folgendem Befehl stellen wir den lokalen Ordner \/home\/pi\/www<\/strong> im Container unter \/usr\/share\/nginx\/html<\/strong> zur Verf\u00fcgung:<\/p>\nLeichte Isolation zum Betrieb mehrerer Programme & Gefahrlose Tests<\/h3>\n
Wie funktionieren Docker-Container?<\/h2>\n
Fertige Images (z.B. aus dem Docker-Hub)<\/h3>\n
Selbst erstellte Images<\/h3>\n
Wie nutze ich Docker-Container auf dem Raspberry Pi?<\/h2>\n
pi@ul-pi:~ $ docker ps\nCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES\n<\/code><\/pre>\nBeispielszenario: Starten eines Webservers (Nginx)<\/h3>\n
Finden des passenden Basis-Images<\/h4>\n
![\"\"](\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2021\/08\/grafik-41.png\")
<\/a><\/figure>\n$ uname -m\narmv7l<\/code><\/pre>\n![\"\"](\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2021\/08\/grafik-42-1024x369.png\")
<\/a><\/figure>\nBrauche ich einen Tag?<\/h4>\n
![\"\"](\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2021\/08\/grafik-43.png\")
<\/a><\/figure>\n\n
Starten eines Containers<\/h4>\n
docker run --name webserver -p 80:80 nginx:1.21<\/code><\/pre>\n![\"\"](\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2021\/08\/grafik-44.png\")
<\/a><\/figure>\nOrdner vom Host durch Volumes mit dem Container teilen<\/h4>\n
-v Hostpfad:Containerpfad<\/code><\/pre>\nmkdir \/home\/pi\/www\necho '<h1>Eigene HTML-Seite auf dem Pi per Docker bereitgestellt<\/h1>' > \/home\/pi\/www\/index.html<\/code><\/pre>\ndocker rm webserver<\/code><\/pre>\ndocker run --name webserver -p 80:80 -v \/home\/pi\/www:\/usr\/share\/nginx\/html nginx:1.21<\/code><\/pre>\n
![\"\"](\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2021\/08\/grafik-46.png\")
<\/a><\/figure>\n