Container Exportieren - Was wird gesichert ?

  • Moin,

    ich hatte schon gesucht, aber leider nichts gefunden, was wird exakt beim Exportieren eines Containers gesichert ?

    Im Idealfall möchte ich die Container Einstellungen Sichern/Exportieren um diese dann für die Aktualisierung eines Containers (neues Image) nutzen.

    Gruß

  • Es wird der Container 1 zu 1 gesichert. Daten abhängig davon ob sie intern oder über ein Volume eingebunden sind. Wenn die Daten in einem gemounteten Volume (auf dem Host) sind dann werden diese nicht gesichert.

    Damit kannst du schnell einen Container wiederherstellen.


    Für dein Vorhaben, Container aktualisieren(neues Image), ist eigentlich das Dockerfile gedacht, die Container selbst bleiben statisch bis auf die Daten.

  • Danke, in meine Fall liegen die Userdaten "extern". Ich hatte gehofft, via GUI die die EInstellungen des Containers zu Sichern, unter Synology geht das.

    Werde das nun händisch übertragen bzw. via Putty.

    Gruß

  • Welche Einstellungen meinst du denn genau? Config files? Vielleicht gibt es ja eine bessere Idee wenn wir mehr Details haben.

  • Hi Puffi,


    ich hab mich etwas umständlich ausgedrückt, in den Einstellungen des Containers kann definiert werden zb: Fixe IP, welche verzeichnisse verlinkt sind, Zugriff auf externe Devices etc. Mir geht es bei einem Image Update darum, derlei Einstellungen nicht jedes mal manuell vor zu nehmen.

  • OK, das sind die Settings des Containers wie er gestartet werden soll. Ich habe dies gelöst in dem ich die Container nicht über das Web Interface erstelle sondern via einem .sh Script welches ich per SSH starte. Dort stehen alle Parameter drin, das Script erstellt das Image (via Dockerfile) wenn es nicht existiert und startet dann den Container mit allen Parametern und Mount Points.

    So habe ich in Summe nur zwei Dateien: Dockerfile + Create Script.

    Daten werden ausserhalb des Containers gespeichert.

    Updates oder Wiederherstellung der Container ist damit eine Sache von Minuten und ich bin unabhängig von dem teilweise unzuverlässigen QNAP Web Interface für Container.

    Wenn du dir das zutraust wäre es genau deine Lösung.

    Wenn Interesse besteht kann ich auch mal so ein Script hier zur Verfügung stellen.

  • Hier ist das simple Script für das erstellen eines Images + Container.

    Diese macht nur Sinn wenn die Daten außerhalb des Containers liegen, also über ein Volume oder Mount Point auf dem Host. Wenn das nicht der Fall sein sollte sind die Daten auch gleich weg also bitte vorsichtig;)




    Das Script muss im selben Pfad liegen wie das Dockerfile und muss auch von dort aufgerufen werden.

    Kann man natürlich noch komfortabler gestalten aber mir reichte es so.

    Ich habe auch noch Container die ich via CRON starten lasse und die nur solange laufen bis sie Ihre Aufgabe erledigt haben. Das ist der Situation geschuldet das ich

    1. unabhängig vom QNAP System bleiben will
    2. Es eigene Scripte mit Abhängigkeiten sind welche QNAP nicht abbildet



    Unterschied zum vorherigen Script ist das ich die Container nicht erstelle und dann starte sondern direkt starte und sie dann automatisch wieder gelöscht werden wenn sie Ihren Job erledigt haben.


    Ich hoffe das hilft die Grundidee dahinter zu verstehen.

    Einmal editiert, zuletzt von puffi ()

  • Fixe IP, welche verzeichnisse verlinkt sind, Zugriff auf externe Devices etc.

    Genau das sollte eigentlich alles mit gesichert werden, wenn du einen Container exportierst. Ich habe es gerade mal mit einem Alpine Container getestet: nach dem Export und anschließendem Import waren zumindest die Verzeichnisse (Volumes) die ich vorher reingereicht habe wieder da. Ich denke da wird im Hintergrund einfach ein docker export aufgerufen.

    direkt starte und sie dann automatisch wieder gelöscht werden wenn sie Ihren Job erledigt haben.

    Erscheint mir ein wenig umständlich. Zunächst mal ist es bei Docker standardmäßig so, dass sich die Container wieder beenden, sobald es nichts mehr zu tun gibt. Weiterhin gibt es für diesen Zweck einfach das --rm Flag. Damit wird der Container automatisch nach Beendigung gelöscht. Und was soll es denn bringen, ständig auch das Image mittels docker build neuzubauen? Und dann auch noch so, dass der Hauptvorteil von OverlayFS und inkrementellen Intermediate Containern durch das --force-rm Flag verloren geht. Je nach Container muss er doch da jedes mal das halbe Internet herunterladen...

  • Ich habe bei (fast) jeder Version den Export getestet und es wurde immer etwas vergessen (speziell im Netzwerk Bereich), wahrscheinlich weil QNAP noch zusätzlich eigene configs verwendet. So bin ich jetzt unabhängig.


    Das Image wird nicht immer neu erzeugt sondern nur wenn es nicht existiert und dann werden eventuell existierende abhängige Container gelöscht.

    Damit kann ich einfach ein Image löschen und beim nächsten Start erstellt er das Image neu ohne Caching (inkrementelle container) Probleme gegen die ich immer gelaufen bin.

    Warum ich das so mache liegt daran daß sich während der Entwicklung vielleicht zusätzliche Abhängigkeiten ergeben und ich so den Aufwand auf das anpassen des Dockerfile und Löschen des Images beschränke.

    Die Container werden bereits mit -rm gelöscht.

  • @puffi

    Danke nochmals für Deine Scripte.


    Ich habe jetzt mal Testweise follgende Schritte durchgeführt

    - Container stop

    - Container Export

    - Image gelöscht

    - Neueste Version des Images herunter geladen

    - Import Container


    Ergebnis, nur die Geräte Einstellungen wurden übernommen, alles andere ist nicht vorhanden. bzw. hat die Default Werte.

    Ich werde diesen Testcontainer jetzt wieder löschen und den Conatiner manuell mit den alten Werten anlegen.

    Für spätere Aktualisierungen werden ich mir noch ein Prozedur basteln.

    Kurzer Nachtrag, das manuelle setzen der Container EInstellungen hat wie erwartet ohne Probleme funktioniert