AW: Einstieg in Docker-Container auf dem Raspberry Pi für Anfänger (Theorie + Praxis, Text + Video)
Ich würde gerne RaspberryMatic, Home Assistant, den Unifi Controller und Pi hole containern. Ich weiß aber nicht, ob ich die RaspberryMatic Platine gezielt dem einen Container und den Conbee II gezielt einem anderen Container zuordnen kann. Hat da jemand Erfahrungen?
Kommentar geschrieben von Martin.
AW: Einstieg in Docker-Container auf dem Raspberry Pi für Anfänger (Theorie + Praxis, Text + Video)
Bist du mit der klassischen Installation von Software vertraut? Also ein System mit komplettem Betriebssystem, auf das man dann verschiedene Programme entweder über die Paketverwaltung oder manuell installiert? Ob nun auf dem Raspberry Pi, einer VM oder einer physischen x86 Maschine spielt dabei keine Rolle, im Grunde ist das hinsichtlich des Aufbaus ziemlich ähnlich. Grundsätzlich hilft das bei einigen Punkten fürs Verständnis, was Container/Docker dort besser machen und wieso das Sinn macht.
AW: Einstieg in Docker-Container auf dem Raspberry Pi für Anfänger (Theorie + Praxis, Text + Video)
Gute Idee, falls danach noch Fragen offen sind kannst du sie gerne stellen. Primär geht es vereinfacht gesagt darum, eine Abstraktionsschicht zwischen OS und deinen Anwendungen zu haben. So lassen sie sich einfacher isolieren und aktualisieren. Das wird um so interessanter, je mehr man auf einer Maschine laufen hat bzw. laufen lassen möchte. Denn damit steigt das Risiko von Konflikten durch z.B. Abhängigkeiten. Klassischerweise hat man das gelöst, in dem auf mehrere Maschinen skaliert wird. Durch VMs im Vergleich zu physischen Maschinen ist der Overhead zwar gesunken. Aber er ist immer noch da, weil auch in jeder VM ein eigenes Betriebssystem läuft.
Das ist natürlich etwas verallgemeinert und kommt immer etwas auf die Infrastruktur, teils auch Philosphie an. Beispielweise kann man auch z.B. mehrere PHP-Anwendungen in der gleichen Instanz von z.B. Apache + PHP betreiben. Hier liegen die Vorteile dann eher in Isolation und/oder Unabhängigkeit: Eine Sicherheitslücke in einer der Anwendungen kann Auswirkungen auf die anderen haben. Wenn man Updates einspielen will, müssen alle Anwendungen kompatibel sein. Zwar ist auch ein Mischbetrieb von z.B. PHP 7 und 8 möglich, aber da wird es komplex.
Mit dem Docker/Container Ansatz würde man in diesem Beispiel jeder Anwendung einen eigenen Webserver mit PHP bereitstellen. Anwendung A kannst du aktualisieren, ohne B und C zu beeinflussen. Das heißt auch: Wenn man z.B. einen Fehler macht und der Apache2 wegen einer ungültigen Konfiguration nicht mehr startet, ist in dieser Zeit nur Anwendung A nicht erreichbar. Die anderen zwei laufen normal weiter. Habe ich dagegen einen klassischen Apache2 ohne Container für alles, wäre in dem Szenario alles down, bis das Problem korrigiert wurde.
Wichtig ist noch zu wissen, dass Containertechnologie keine Magie ist, mit der auf einmal etwas völlig neues möglich gemacht wird. Man kann im Grunde alles auch auf klassischem Wege umsetzen, zumindest mit Workarounds. Aber das ist tendenziell komplexer, fehleranfälliger und mehr Aufwand in der Wartung. Klassische Probleme, wie z.B. dass sich ein Container in der Testumgebung anders verhält als in Staging, kann man damit deutlich reduzieren: Weil der Container immer gleich gebaut wird. Zwei klassische Maschinen exakt gleich zu halten ist dagegen schwierig. Vor allem Testsysteme, wo man bewusst mal was ausprobiert, was man nicht immer auch produktiv umsetzen möchte. Selbst wenn man das wieder rückgängig macht kann es passieren, dass dieses System sich dann doch anders verhält wie das Produktive, wo das nicht stattfand.