Container oder nicht?

[Einstein67]

Also ich hab auf einem Nuc mit i5 folgendes am laufen:

als LXC:
iobroker: 1Core 2 GiB RAM 4GB SSD
Influx/Grafana: 1Core 1 GiB RAM 2GB SSD
Apache2 mit 5 Websites: 1Core 0,5 GiB RAM 2GB SSD
WeeWx: 0,5Core 0,25 GiB RAM 1GB SSD

und als VM:
BackupServer/MotEye: 1Core 2 GiB RAM 4GB SSD
Docker(12 Container): 1Core 2 GiB RAM 10GB SSD

Ist halt reine Geschmackssache welche Funktion man wo rein packt.

Ich hab halt PBS/MotEye in einer VM am laufen weil sie auf eine externe NMVE problemlos zugreifen können.

Docker hab ich lange in einem LCX am laufen gehabt ... hab aber AdGuard-Home nicht dazu bewegen können, die Namen der Clienten anzuzeigen. Aber sonst ist alles andere auch super im Docker LXC gelaufen ...

Edit: Und das Ding fadisiert sich mit 5% CPU-Auslastung.

[warhammer73]

@haselchen
Raspi 4 / 2GB - Den hab ich da (Ist halt aktuell der Test Raspi um überhaupt mal zu schauen ob iobroker das kann was ich vorhabe) - 4GB wäre mir zwar lieber, aber bei den Preisen... Da eh eine SATA Platte mit dranhängt, kann er auch nen bischen swappen bis sich eingepegelt hat was er an Sachen besser im Speicher hält.
Mein DS220j ist nen bischen schwach auf der Brust um zur Virtualisierung zu dienen

@OliverIO
Im wesentlichen sind das auch so meine Überlegungen, danke.
Vor einer Weiler habe ich meinen Webserver auf Container umgestellt und deswegen bin ich halt gerade bei den Überlegungen.
Mein "Testsystem" habe ich extra nicht so gebaut, weil mir nicht wirklich klar ist wie ich z.B. BT Sensoren in den IOBROKER Container bekommt. Auf der anderen Seite habe ich das bisher dann auch wieder nicht gebraucht...

@Hormoran
Proxmox und den Pi Ableger habe ich erstmal verworfen
Bei einer Handvoll Container lassen die sich auch noch manuell konfigurieren und überwachen, falls sich herausstellt das sich der Raspi langweilt wenn alles läuft kann ich mir die Arbeit für die Zukunft immer noch einfacher machen und eine Verwaltungssoftware drüberbauen

Danke für Eure Anregungen bis hierher!

[Einstein67]

@warhammer73 said in Container oder nicht?:

Raspi 4 / 2GB

Damit wirst bei Virtualisierung, egal ob bei (mehreren) Container oder VirtuellenMaschinen nicht viel Spaß haben ...

[Homoran]

@warhammer73 sagte in Container oder nicht?:

kann er auch nen bischen swappen bis sich eingepegelt hat

ob das eine gute Idee ist?
da geht auf jeden Fall die System Load hoch.
Am Pi4 sollte man sowieso die USB3 Buchse nicht verwenden, da es da zu massiven Störungen komen kann.

USB2 verlangsamt das I/O noch etwas. Außerdem wäre ein aktiver Hub für die Stromversorgung zu empfehlen.

[warhammer73]

@einstein67 said in Container oder nicht?:

@warhammer73 said in Container oder nicht?:

Raspi 4 / 2GB

Damit wirst bei Virtualisierung, egal ob bei (mehreren) Container oder VirtuellenMaschinen nicht viel Spaß haben ...

Abwarten und ausprobieren.
Aktuell kommt der IOBroker mit unter 512MB aus
Grafana wird nicht wirklich dauerhaft viel RAM benötigen, weil die Datenaufbereitung nur eher selten genutzt wird
InfluxDB könnte ein Thema werden
evcc braucht nicht wirklich viel RAM

Aber Korrektur (Habe gerade nachgesehen, der Raspi hat doch 4GB)

[warhammer73]

@homoran said in Container oder nicht?:

@warhammer73 sagte in Container oder nicht?:

kann er auch nen bischen swappen bis sich eingepegelt hat

ob das eine gute Idee ist?
da geht auf jeden Fall die System Load hoch.
Am Pi4 sollte man sowieso die USB3 Buchse nicht verwenden, da es da zu massiven Störungen komen kann.

USB2 verlangsamt das I/O noch etwas. Außerdem wäre ein aktiver Hub für die Stromversorgung zu empfehlen.

Denk schon, zumindest vorläufig. Im Zweifel kann man immer noch Container verschieben.
Wie gerade geschrieben - Dauerhaft braucht der IOBroker Speicher (Aktuell unter 512MB), die InfluxDB (Speicher mal sehen), und evcc (Braucht wohl nicht viel), Grafana kann Speicher fressen - Wird aber nur selten benutzt und wenn er dann anfängt zu swappen und mal langsamer reagiert, damit kann ich leben.

Funktioniert hier bisher problemlos mit USB/SATA Bridge und einer 512GB SSD. Hoffe das bleibt auch so. Aber ich werde da weiter mal ein genaueren Blick drauf werfen. Danke!

... aber da der Raspi nun doch 4GB hat, sollte das Thema swappen auch geringer werden...

[BananaJoe]

Und hier mein Senf:

Ich lese hier viel mit ... insbesondere leide ich immer mit wenn "ein System nicht mehr will", "iobroker startet nicht nach Update", "bootet nicht mehr" usw.

In so einer Installation stecken schnell mal viele hundert Stunden Arbeit (Skripte und Visualisierung).
Klar, es gibt den Backitup Adapter - aber ich freue mich das ich den noch nicht gebraucht habe (nicht weil der schlecht ist).

Denn ich habe Snapshots. Weil mein ioBroker eine VM ist. Vor größeren "Schweinereien" wie Upgrade von Node.js, Admin Adapter aus dem Beta-Bereich, das Upgrade von Ubuntu 20.04 auf 22.04 oder anderen Spielereien mache ich immer einen Snaphot. Da wird der gesamte Status meiner ioBroker VM eingefroren. Wahlweise im laufenden Betrieb mit Arbeitsspeicher oder - so mache ich es am liebsten - ioBroker runterfahren, Snapshot, wieder hochfahren, warten das alles gestartet ist, Installieren oder Updaten.
Update geht schief? Gut, akzeptable Zeit in die Fehlersuche investieren - und wenn es nicht hinhaut mit dem Snapshot zurückspringen. Und später noch mach einen Anlauf nehmen.
Update hat geklappt - Prima, alles einmal testen und Snapshot löschen.

Und meine Backups sind - neben alle 3h per Backitup - eine Sicherung der gesamten VM. Sollte die Hardware, Festplatte etc. kaputt gehen so kann ich das bequem neu aufsetzen, Irgendein Gerät mit der gleichen Virtualisierungssoftware reicht.

Also, ich hoffe die Botschaft kam an: Nimm etwas wo du Snapshots machen kannst. Keine Ahnung ob das die Container können. Jeder normale PC könnte das, z.B. mit Proxmox, VMware ESXi oder auch Windows mit einer Hyper-V VM (immer Linux VM nehmen). Kleine Hardware kann reichen, mein Eigenbau mit 1TB NVMe + 10TB HDD schluckt so um die 16Watt,
ein NUC (und ohne die HDD) geht es auch unter 10W. Und du bist unabhängig von der Hardware,

Und überlege dir wie du ein Backup machst. Auf jeden Fall Backitup, aber auch auf jeden Fall etwas was die ganze VM sichert (beides bitte woanders hin, z.B. auf ein NAS oder USB-Festplatte an der FritzBox).

Ja, es läuft toll auf einem Raspberry. Aber im Fehlerfall ist es mir zu kompliziert. Schön das das Wiederherstellen per Backitup so gut funktioniert. Aber ist beim Wiederherstellen doch schon ein ganz schönes kribbeln, gell?

Zweiter Nebeneffekt: du kannst mehr als eine VM laufen lassen. Zum Beispiel ein Testsystem. Und vieles mehr.

[warhammer73]

@bananajoe
Danke auch Dir für die Hinweise zum Thema Backup.

Mit Virtualisierung und Co. beschäftige ich mit seit Ende der 90er Jahre. Insofern ist mir das was Du beschreibst durchaus geläufig (Auch wenn an Snapshots zu dem Zeitpunkt auf Desktop Systemen nicht ansatzweise zu denken war).

Container per Se können kein Snapshot - Brauchen sie auch nicht.
Warum nicht? Es gibt eine Bauvorschrift mit der man jederzeit einen neuen Container bauen kann. Wenn man das nicht selber machen will, gibt es Repositories mit so ziemlich allem was man sich vorstellen kann als fertige Container die automatisch geladen und gestartet werden (Auch Wunsch auch automatisch durch aktualisierte Container getauscht). Im Endeffekt ist das eine der Ideen hinter Containern: Geht was nicht (mehr): Abschiessen und neu laden/starten.

Wenn Dir Dein Hostsystem stirbt, brauchst Du "nur" die Konfiguration um die Containerumgebung zu beschreiben und kannst auf jedem anderen System das Deine Containerruntime unterstützt sehr schnell wieder online sein.

Warum funktioniert das ganze nun so problemlos:
Weil die Daten (Nutzdaten, Parametrierungen...) grundsätzlich ausserhalb des Containers liegen.
Wichtig ist also diese Daten zu sichern (Plus die Konfiguration Deiner Containerumgebung). Da es sich um reine Filesysteme handelt ist ein Backup entsprechend einfach.
Wenn man das ganze noch etwas weiter treiben will, verwendet man irgendwas wie LVM, oder Filesysteme wie JFS2, BTRFS oder ZFS und erstellt zwischendurch regelmässig Snapshots um zu diesen alten Punkten zurückzukehren wenn nötig.

BTW: Welchen NUC hast Du der mit entsprechendem Speicherausbau (Bei mehreren VMs dann ja sinnvoll irgendwo ab 8 GB aufwärts) und genug Kernen unter 10W bleibt? Danke!

[Einstein67]

@warhammer73 said in Container oder nicht?:

Container per Se können kein Snapshot

Natürlich kann man von LXCs Snapshots erstellen.

[BananaJoe]

@warhammer73 Ich kenne Container. Meist berichtet mir begeistert ein Bekannter/Kollege/Verwandter/Nachbar das er mal eben Nextcloud damit aufgesetzt hat. Meine Lieblingsfrage ist dann immer "und, schon mal geupdated?". Und in 9 von 10 Fällen war die Antwort "ja, da war aber alles weg".

Denn genau, man muss darauf achten das alles an Information außerhalb des Containers abgelegt wird. Die Lücke im System als Beispiel: Nun kommt eine neue MySQL Version ... und Updated die Datenbanken (das Beispiel nehme ich weil ich das nun schon oft gesehen habe).
Schön das die außerhalb des Containers liegen - aber wurden damit verändert, also nützt die alte Containerversion auch nichts.

Ich hab nicht viel Geld, also versuche ich es immer in Sparsam. Mein ESXi Server als Projekt:
https://znil.net/index.php?title=VMware_ESXi_6.7_mit_Biostar_A10N-8800E_Mini_ITX

Wobei ich inzwischen alles auf ein Biostar A10N-9830E umgezogen habe (50% mehr CPU Leistung).
Es gibt jede menge anderer Boards, die Kunst ist eines zu finden wo die Virtualisierungsoptionen auch aktiv sind bzw. sich aktivieren lassen.

Selbstverständlich wird auch Proxmox prima drauf laufen.

Backup mache ich mit der Community-Version von Veeam Backup & Replication. Dafür muss der ESXi lizensiert sein, die freie Version reicht nicht. Die Lizenzen bekommt man aber auch z.B. auch gebraucht bei Insolvenzverkäufern. Oder man nimmt andere Backupsoftware, da gibt es einige.

[OliverIO]

@einstein67 sagte in Container oder nicht?:

Natürlich kann man von LXCs Snapshots erstellen

Nur weil der Befehl gleich heißt ist es nicht das selbe wie bei VM
Bei docker nennt der Befehl sich commit.

Dieser erstellt ein Image auf Basis des aktuellen Zustands des Containers und speichert ihn separat ab.
Da sind aber die volumes nicht dabei.
Das dient eher zum debuggen oder eine schlechte Art und Weise sich sein Image einmalig zu erstellen, in dem man über die Shell im Container Programme nach installiert

Die Definition eines Images sollte aber immer über ein dockerfile (oder wie dies bei anderen Containern auch immer heißt) erfolgen da dann genau nachvollziehbar ist aus was der Container besteht.

Eine regelmäßiges Backup erfolgt genau so wie wenn das Programm nativ installiert ist. Durch definierte volumes ist der Umfang meist genau definiert und man kann schön über inkrementielle Backups in jedem beliebigen Zeitabstand sich Sicherungen ziehen.

Das ist ähnlich wie bei den snapshots einer vm. Der erhöhte speicherplatzbedarf ist ja heute eher kein Thema mehr.

[OliverIO]

@bananajoe sagte in Container oder nicht?:

Schön das die außerhalb des Containers liegen - aber wurden damit verändert, also nützt die alte Containerversion auch nichts.

Bei einem Update sind immer die Hinweise des Anbieters zu beachten. Besonders bei Major versionswechsel

Ansonsten sind Datenbanken auch nur ein oder mehrere Dateien die im filesystem liegen. Ob das nun in einer vm ist
Oder eine volume per overlayFS über das Container filesystem gelegt wird ist relativ egal.

Ich geb dir recht, wenn jemand sich gar nicht richtig auskennt, dann ist der einfache Druck auf einen Snapshot Knopf einfacher, als sich eine Backup Strategie zu überlegen welche Verzeichnisse man genau wegsichern muss.

So wie mir scheint kennt sich @warhammer73 ganz gut aus und hatte nur zu Containern noch ein paar wissenslücken

[warhammer73]

@einstein67

Ja, kann man.
Geht auch z.B. bei Docker.

Hat aber nur bedingt den gewünschten Erfolg eines "Backups um den Systemzustand inkl. der Bewegungsdaten wieder herstellen zu können".

Kein mir bekanntes Containersystem (lasse mich da aber auch gern korrigieren) ist OOTB in der Lage einen Snapshot aller benötigten Bits zu erstellen um daraus ein neues lauffähiges System mit identischen Konfigurationen, Stamm- und Bewegungsdaten zu erzeugen. (Und darum geht es beim Snapshot im Rahmen einer VM - Mit der Lücke das auch hier nicht zwingend alle Daten gesichert werden, abhängig wo und wie diese zur Verfügung gestellt werden und welchen VM Manager man verwendet).
Bisher kenne ich die Snapshots der Container eher als krude Variante mal eben schnell einen Container zu klonen und anderweitig zu verwenden.

Aber wie gesagt, ich lasse mir da gern neues Wissen erklären.

[warhammer73]

@bananajoe
... Du hast natürlich Recht, deswegen u.a. der Verweis auf Filesystem Snapshots.
Einem Watchtower Container beizubringen das er nach dem Stoppen des zu aktualisierenden Containers ein Snapshots der verlinkten Filesysteme macht (Oder ein Backup wenns denn sein muss) bevor er den Container neu startet ist kein Hexenwerk.
Muss ja nichtmal die DB an sich sein, reicht ja wenn ein Anwendungsprogramm beim aktualisieren der Daten beim Update sich verschluckt o.ä.
Ich finde es halt nur einfacher Daten und Programme getrennt zu halten und zu sichern.

[warhammer73]

@oliverio

Niemand ist allwissend.
Aber nur weil es einen Parameter gibt der Snapshot heisst (Und Snapshot vorher im Kontext VM verwendet wurde), heisst es ja nicht das die selbe Funktionalität dahinter steckt.

Wie ist es so schön im Anforderungsmanagement:
Man sollte dringend ein Glossar anlegen, damit alle vom selben reden wenn sie einen Begriff verwenden.

[OliverIO]

@warhammer73
Genau