Docker Container persistente Daten

Heyho zusammen,

Ich beschäftige mich momentan etwas mit Container Technik. Nun habe ich jedoch eine Frage. Ich habe beispielsweise ein x beliebiges Programm in einem docker Container am laufen. Im Programm nehme ich dann Einstellungen vor, gebe Daten ein etc. Dauerhaft werden logischerweise Änderungen gemacht.
Wird der Dockercontainer beendet ist alles weg, mit einem commit könnte ich die Änderungen regelmäßig in einem neuen Image speichern, macht aber nicht wirklich Sinn wenn ständig Daten verändert werden.
Mir scheint nach einem Wochenende Dockern, dass docker nicht wirklich für Anwendungen geeignet ist an denen ständig Änderungen gemacht werden, Bzw User Input gemacht wird. Allerdings gibt es auch ein MySQL Image, wenn der MySQL Container beendet wird sind alle Daten weg (der Sinn einer Datenbank wird dann ja gar nicht erfüllt!?) Welche Mechanismen gibt es hierfür oder sind für solche Anwendungen eher andere Container Arten gedacht? Stichwort Lxd

Ich bin eher der Admin als Entwickler, hierfür scheint docker nicht wirklich geeignet!?

Wäre cool wenn ihr mir etwas Input liefern könntet

persistente daten speichert man auf dem host und bindet diese in die docker-instanz ein:

https://docs.docker.com/engine/admin/volumes/bind-mounts/
https://docs.docker.com/engine/admin/volumes/volumes/

beispiel: ich nutze portainer und starte es mit


die datenbank von portainer liegt auf dem host in "/opt/docker/portainer/" und wird im container nach "/data" gemountet. so kann ich eine neuere version von portainer mit der gleichen datenbank starten und muss nicht immer alles neu konfigurieren.

Für Dinge wie MySQL arbeitet man typischerweise über "Volume Container". Im Prinzip legt man die Daten in einen eigenen Container/Volume den man stoppen kann aber niemals löscht (sonst sind die Daten natürlich weg). Dieses Volume kann man dan im eigentlichen Applikationscontainer an eine bestimmte Stelle in dessen Dateisystem einbinden.

Alternativ wäre die Möglichkeit über sogenannte "bind Mounts" zu arbeiten. Dabei liegen die persistenten Daten auf dem host und werden dann dem Container zur Verfügung gestellt. Macht man gerne bei Build Containern um dessen Build Ergebnisse auf dem Host parat zu haben.

Okey dieses Volume Mounten scheint mächtiger als zunächst gedacht. Werd mich mal den Sonntag auch noch damit rum schlagen und falls ich fragen hab komm ich nochmals zurück
Aber kann es sein dass das handling bei lxd mit persistenten Daten deutlich einfacher ist? So wie ich das verstehe ist der Container dort bereits persistent.

Weil oft ist die Sache deutlich komplizierter als nur eine Datenbank.
Beispielsweise habe ich freepbx am laufen (VOIP Telefonanlage)
Als Basis läuft Asterix, hier sind die Module und config gespeichert. Dann hat freepbx ein Verzeichnis im Apache, zusätzlich noch eine MySQL Datenbank.
Alles davon wird ja ständig verändert, packe ich dann das alles in einen Volume Container?
Mit das alles meine ich natürlich die Verzeichnisse in denen die Anwendungen/Datenbanken liegen.

Dein Vergleich mit LXC/D hinkt. Dort wird der Kernel mit dem Host geteilt aber sonst ist LXC/D eine eigenständige VM. Dort kannst du Anwendungen installieren, Daten persistent speichern und vor allem die Anwendungen aktualisieren. Bei Docker aktualisierst du nicht. Du schmeißt den Container mit der alten Version weg und startest einen Container mit der neuen Version. Config-Dateien etc werden entsprechend in ein Volume abgelegt, die du in den Container mountest.

Nein, in deinem Beispiel mit freepbx "missbrauchst" du Docker, da du ja mehrere Module und Sub-Anwendungen in einem Container hast. Genau das ist nicht das Ziel von Docker.

Bei dem freepbx Beispiel würdest du die mysql ein einen Container packen, den Apache in einen Container usw. usf. Damit du die Module untereinander voneinander unabhängig aktualisieren kannst. Die Kommunikation zwischen den einzelnen Containern muss natürlich sichergestellt sein, sprich die Anwendung muss eine Kommunikation der Module per Netzwerk bzw Unix-Sockets unterstützen. Daher ist Docker keine pauschal gültige Lösung sondern funktioniert eben nur mit hochmodularen Anwendungen.

Okey, macht Sinn. Nur leider wird es einem Anfänger dann bereits falsch, das freepbx Image ist auf dem Docker Hub und hat einige 10K downloads...
Ich will docker nicht schlecht machen, es ist soweit ich das mittlerweile verstehe für andere Anwendungen gedacht, sprich Anwendungen die sich extrem modular aufbauen lassen. Ich könnte jetzt versuchen freepbx so modular zu bauen, nur warten dann noch X andere Anwendungen auf mich und ich müsste mich dann wahrscheinlich nur noch mit dockerbau beschäftigen...

Ich suche die für mich richtige Container Technologie. Ich habe mehrere VPS am laufen. Leider kann ich mit normalen Mitteln nicht alles auf einem, bzw. auf einigen wenigen VPS laufen lassen, da die Anwendungen gegenläufige Abhängigkeiten haben. Deswegen vieles in einer eigenständigen VM.
Jetzt würde ich aber gerne diese Dinge in. Container packen, um den ein oder anderen VPS einzusparen und auch andere Vorteile wie Portabilität nutzen zu können. Ich hab mich bisher nur mit Docker beschäftigt, da am bekanntesten. So wie du es erklärst hab ich LXd auch verstanden und scheint mir für meinen Anwendungsfall die bessere/leichter zu administrierende Lösung zu sein!?

Ja, LXC scheint da definitiv die bessere Wahl. Zur Info: Dir ist hoffentlich bewusst, dass der Docker Hub in keinster Art und Weise einer Qualitätskontrolle etc unterliegt? Das ist einfach ein Sammelsurium von Containern, die Leute dort hochgeladen haben. Lediglich die "Official Repositories" haben eine Qualitätskontrolle bzw Review durch die Firma Docker Inc hinter sich.

Ungepflegte Docker Repos sind die Pest, da kannst auch gleich ein "curl URL | bash" machen wenn du ungeprüften und ungepflegten Code installieren möchtest.
Brauchst dir nur den am häufigsten "gepullten" freepbx Container ansehen: Ubuntu 14.04, LAMP, Asterisk und FreePBX je in Version 13. Aktuell sind bei beiden Anwendungen je Version 14. Wenn der Ersteller Docker komplett verstanden hätte, so hätte er ein Docker Compose anlegen müssen mit mindestens 4 Containern angelegt. Je einer für mysql, apache, freepbx und asterisk damit man eben alle unabhängig voneinander aktualisieren oder anpassen kann. Bei allen müssen dann entsprechend Volumes gemountet werden um die Config-Daten bzw die Datenbank persistent zu halten. So zumindest das Best Practice aber es hindert einen natürlich nichts daran, alles in einen Container zu packen. Aber dann musst du mehrere Volumes dran mounten und du musst jedes mal den gesamten Container webschmeißen und neu bauen wenn sich nur eine Komponente ändert, z.B. durch Sicherheitsaktualisierungen. oder bist drauf angewiesen, dass der Container im Hub aktualisiert wurde. Also bleiben nur zwei Optionen: Alle Container selbst erstellen damit man wenigstens weiß was genau da drin läuft oder nur Container vom Hub nehmen, die in den official repos sind. Nur da hast ansatzweise eine Chance oder Garantie, dass diese auch regelmäßig aktualisiert werden.

Wenn du dazu weitere Grundlagen lesen willst: In der c't 15/17 gab es eine Artikelserie dazu.

Docker ist nun einmal komplizierter als es auf den ersten Blick scheint und die Hauptvorteile sind die komplette Trennung von Anwendung und Daten (wenn man es komplett sauber mit den Volumes macht) und dass man so 100%ig reproduzierbare lauffähige Anwendungen erstellen kann die auch in der Prod-Umgebung laufen wenn sie so identisch in Testing liefen. Das Deployment lässt sich so beschleunigen und verifizierbar machen aber das bringt dir als Privatperson nur etwas, wenn du dich auch selbst darum kümmerst, deine Container stets aktuell zu halten oder wenn du aus div. Gründen nicht willens oder fähig bist die Installationsanleitung einer Anwendung zu lesen und diese schnell ausrollen willst. Aber eben auch mit der Gefahr verbunden, dass du nicht weißt ob und was der Ersteller des Containers da ggf. noch mit reingepackt hat.

Danke für die ausführliche Antwort.
Mir war bewusst dass das Dockerhub keinerlei kontrollmechanismen implementiert hat, ich bin jedoch davon ausgegangen dass es ein gutes Image ist, wenn es "viele" Leute nutzen. Bei freepbx sind es IMHO recht viele im Vergleich zum Verbreitungsgrad der Software.
Nach deinem letzten Post dachte ich mir schon dass ich alles trennen und mit docker Compose + jeweils Volume Container erstellen müsste um das Konzept dahinter korrekt umzusetzen. Wenn das jeder so umsetzen würde wäre docker einfach nur genial. Es löst nämlich ein grundlegendes Problem, Abhängigkeit vom Betriebssystem! Folgender Satz, welcher mir auch ungemein geholfen hat das Konzept dahinter zu verstehen würde es in Zukunft nicht mehr geben: "This Application runs in your machine but not in mine"
Das für die von mir administrierten Anwendungen selbst umzusetzen ist mir definitiv zuviel Arbeitsaufwand, zumal die Entwickler selbst die Abhängigkeiten der jeweiligen Applikation viel besser kennen als ich es tue. Bei mir wäre es eher try & catch, in der Hoffnung ich habe auch wirkliche alle persistente Daten korrekt in Volume Container ausgelagert.
Grundlagen von Docker hatte ich nun glaube ich genug, hab mir bereits 12 Stunden Video tutorials angeschaut.
Werd mir jetzt noch LXD anschauen, aber auf den ersten blick genau das was ich will. Wobei mir docker lieber wäre, alleine wenn ich sehe wie schnell ein solcher Container startet, abhängigkeiten (weitere Images) werden automatisch mit gepullt, "versionierung", etc. Leider wird es von vielen völlig falsch umgesetzt. Und das war jetzt nur ein Image von vielen, bei denen ich das Verhalten festgestellt habe. Was bringt mir ein Container, der jede Einstellung verliert sobald er gestoppt wird, für Tests vielleicht ganz schön, aber halbwegs produktiv ist damit ja unmöglich.
Werd mich mit docker denk ich in ein paar Jahren nochmals befassen, eventuell ist es dann besser mit dem Verbreitungsgrad guter Images.

Du kannst damit wunderbar produktiv arbeiten musst halt nur den Grundsatz verinnerlichen dass du Daten strikt von Anwendung zu trennen hast und das betrifft auch alle Arten von Konfigurationsdaten. Ja, für einen alleine ist das ggf overkill aber es gibt haufenweise sinnvolle Anwendungsfälle. Bestes Beispiel ist meiner Meinung nach immer noch der Webhoster.

Neuer Kunde bucht Webhosting-Paket:
- Per Skript wird ein Volume mit gebuchtem Speicherplatz erstellt + Volume für SQL DB und kleinere für Configs
- Es wird per Compose o.ä. ein zusammen gehörender Verbund aus Webserver und SQL erstellt und was ggf noch nötig ist oder gebucht wurde
- Skript fügt die Volumes an die Container, startet alles und schickt dem Kunden die Logindaten.

Kommt jetzt ein Update für den SQL-Server so werden im nächsten Wartungsfenster und nach natürlich erfolgten Tests *hüstel* alle SQL-Container durch welche mit der neuen Version ersetzt bzw neu gestartet. Alles läuft weiter reibungslos, da die Datenbanken und Configs ja auf dem persistenten Volume liegen.

Oder der Webshop-Betreiber, der aufgrund einer Erwähnung bei mydealz oder ähnlichem einen Besucheransturm erlebt kann so in sehr kurzer Zeit dutzende oder hunderte neue Webserver-Instanzen starten zur Auslieferung der Seite, vernünftigen Loadbalancer oder CDN vorausgesetzt.