[Debian] Docker install inkl. Container von einem PC auf einen anderen transferieren

Hallo,

ich würde einen Rat benötigen.

Ich habe hier mein NAS mit OpenMediaVault (Debian basis) laufen und hab mir ein neues gebaut ebenfalls mit OMV. Die Daten selbst hab ich schon transferiert.

ABER ich hab auf dem alten OMV noch eine Docker installation mit mehreren Containern.
Da läuft, Unbound, Pihole, Sabnzbd, Radarr, Sonarr und Plex.

Gibt es eine einfache Variante wie ich das komplett auf das neue NAS transferieren kann ohne die container neu einrichten zu müssen, vor allem wegen den ganzen Daten die bereits vorhanden sind (pihole gravity Daten, Plex - Metadaten der Mediathek, die ganzen Indexer usw. in Sabnzbd) ?

Die ganze OMV installation zu clonen ins neue System is keine option, da ganz andere Hardware UND am alten NAS ist noch OMV 5 und am neuen bereits OMV 6.

In den Containern selbst wird in der Regel nix gespeichert. Das Volume, wo die Container alle nötigen Daten speichern, kannste eigentlich auf das neue NAS kopieren. Wenn du dort die Container startest und die das kopierte Volume verwenden, sollte alles so sein wie vorher.

Um das richtig beantworten zu können, müsste man wissen wie die Container gestartet wurden. Wurde beim Start nicht dafür gesorgt, dass die im Container laufende Applikation ihre Daten in Volumes legt, werden die Daten nach dem Entfernen des Containers verschwinden.

Wenn alle Container Volumes hatten, dann reicht es die Volumes zu übertragen und am neuen System die Container wieder zu starten. Die Images kommen wahrscheinlich ohnehin von docker-hub. Wenn nicht, können die Images mit docker-save aus der lokalen Registry exportiert und mit docker-load wieder importiert werden.

sicher sollen daten immer außerhalb des containers gespeichert werden, aber wie kommt man auf die idee dass container "immer wieder mal hin werden" können sollen?
ist jetzt nicht speziell auf davebastard bezogen, aber das liest man immer wieder, begründung dazu aber nie.

nur weil etwas mehr oder weniger disposable ist weil halbwegs automatisiert erzeugt und es keine daten behält, ist es doch bitte nicht selbstverständlich dass es "kaputt" geht, das ist ja ein armutszeugnis was qualität betrifft.

aktiv replacen und geht einfach mal kaputt sind 2 paar schuhe

ja war schlecht formuliert. war eh eher so gemeint wie nexus schreibt. es ist einfach vom konzept her so gedacht dass es wurscht sein muss wenn man recreaten muss. und kaputt werden selbst hatte ich auch schon, vor allem bei docker daemon updates.

wenn man es weiterdenkt und z.B: kubernetes verwendet dann werden container am laufenden band neu created oder verworfen

Zitat aus einem Post von meepmeep

Die werden ja nicht nach belieben vom Orchestrator/Daemon ohne Grund gekillt und neu erstellt.

Ohne Grund nicht, aber wenn du z.B. Services via Docker in Kubernetes deployest mit Deplyoment-Limits und automatischer Skalierung ists gang und gäbe, dass Container gekillt/gestartet werden

Aber das ufert ein wenig aus: Das Grundprinzip von Docker ist eben, dass Container und persistierte Daten (z.B. eben auch die configs, DB, etc.) getrennt sind und Container jederzeit und willkürlich gekillt werden können, ohne dass den persistierten Daten etwas passiert.

Zitat aus einem Post von meepmeep

Was macht ihr denn mit euren Containern? Wenn nicht grad ein node evakuiert werden muss, eine Probe schiefgeht oder ein Deployment daherkommt laufen Container "ewig". Die werden ja nicht nach belieben vom Orchestrator/Daemon ohne Grund gekillt und neu erstellt.

Aber grundsätzlich habt ihr ja eh recht, Container sind wegwerf-Einheiten. Aber wenn jemand fragt wie er seine Container auf ein neues System migrieren kann, dann sind fehlende Volumes einfach ein Fallstrick auf den man achten sollte. Der Einstieg ist für Anfänger ja relativ leicht. Ein docker-run command aus dem how-to ist schnell kopiert und wenn da keine Volume-Mounts dabei waren dann sind die Daten weg.

"ewig" laufende Container bedeutet halt arbiträr altes image mit beliebigen Sicherheitslücken.
klar, es ist immernoch ein Container, aber gewartet gehörts trotzdem.

Jedes pimperldeployment kann mit einem zusätzlichen Watchtower Container, der per Cron in sinnvollen Zeitabständen aufgerufen wird, automagisch up-to-date sein... das ist literally ein docker run befehl im Cronjob, muss halt als root rennen (aber stoppt dann nach dem Update automatisch wieder, also kein dauerhafter Angriffsvektor)

Aber halt nur, wenn die Container eben wie per Design unverändert bleiben und jederzeit weggeschmissen werden können (dH alle Daten in Volumes oder externen Datenbanken)... denn nichts anderes macht watchtower. Wenns ein neues image gibt, holt ers, und erstellt den Container neu.

@Ovaron: ich würde mir jeden der Container neu erstellen (diesmal mit Volumes), dann die Config vom alten Container in die jeweiligen Volume-Ordner kopieren, und testweise umswitchen. Wenn alles klappt, hast saubere neue Container, die du viel besser warten (und jederzeit wegschmeißen) kannst.