Automatisches erstellen der Export config json files via Skript

[haydibe]

Da hilft dann nur: Browser-Tools anschmeißen und schauen was vom Browser an die DS bei der Aktion übertragen wird.

 

[haydibe]

Mir ist heute aufgefallen, dass nur gestartete Container mit deinem Script exportiert werden. Besteht die Möglichkeit, das Script auf alle Container auszuweiten? Bedeutet version=1 das nur die laufenden Container gesichert werden?

Ich hab mich heute wieder an den Thread erinnert.

Ich weiß nicht welche quatsch mir damals eingefallen ist zu fragen, ob über die UI ausgeschaltete exportiert werden können. Wenn, wäre der umgekehrte Fall eher die Rückfrage Wert gewesen.

<update>Ich vermute mal, ich wollte Dich dazu ermutigen es einfach selbst mit den Browser-Tools herauszufinden. Ansonsten macht die Rückfrage für mich gerade keinen Sinn </update>

Hiermit kann man einen Container samt Zustand speichern:

/usr/syno/bin/synowebapi --exec api=SYNO.Docker.Container method=export version=1 path="${BACKUP_DIR}" name="${container}"

Die erzeugte Datei ist dann unter dem Pfad ${BACKUP_DIR}/${container}.syno.txz zu finden.

Das habe ich sehr ungeschickt geschrieben. ${BACKUP_DIR} muss ab einem Share angegeben sein, bspw.:

 /usr/syno/bin/synowebapi --exec api=SYNO.Docker.Container method=export version=1 path="/docker" name="watchtower"

Während die Variante, die nur die Konfiguration speichert, den Pfad inkl. Volume haben will:

/usr/syno/bin/synowebapi --exec api=SYNO.Docker.Container.Profile method=export version=1 outfile="/volume1/docker/watchtower.json" name="watchtower"

Weder unter DSM7, noch DSM6 macht es bei mir einen Unterschied, ob der Container läuft oder nicht läuft: beides funktioniert.

 

[EDvonSchleck]

Weder unter DSM7, noch DSM6 macht es bei mir einen Unterschied, ob der Container läuft oder nicht läuft: beides funktioniert.

Kann ich so nicht bestätigen. Ich habe jetzt unterschiedliche Anzahl von deaktivierten Containern getestet. Die Container, welche deaktiviert werden nicht gesichert, weder mit Einstellungen noch mit. Image (komplett). Das manuelle exportieren funktioniert. Auch wenn die Container laufen, werden diese exportiert. Es liegt definitiv am Zustand des Containers! Getestet auf DSM 7.1.1 Update 3.

 

[haydibe]

@EDvonSchleck hier die exakten Schritte die ich für meine Tests auf einer DS920+ mit DSM 7.1.1-42962 Update 3, Docker Paket 20.10.3-1308 durchgeführt habe:
- Container erzeugen: docker run -d -t --name test alpine
- Zustand überprüfen: docker ps -a --filter name=test, Erwartung: Container im State Running
- Container exportieren: /usr/syno/bin/synowebapi --exec api=SYNO.Docker.Container method=export version=1 path="/docker" name="test"
- Container Einstellung exportieren: /usr/syno/bin/synowebapi --exec api=SYNO.Docker.Container.Profile method=export version=1 outfile="/volume1/docker/test.json" name="test"
- Sichtprüfung, ob alles da ist: ls -l /volume1/docker, Erwartung: /volume1/docker/test.json und /volume1/docker/test.syno.txz existieren.
- Container stoppen: docker stop test
- Zustand überprüfen: docker ps -a --filter name=test, , Erwartung: Container im State Stopped
- Container exportieren: /usr/syno/bin/synowebapi --exec api=SYNO.Docker.Container method=export version=1 path="/docker" name="test"
- Container Einstellung exportieren: /usr/syno/bin/synowebapi --exec api=SYNO.Docker.Container.Profile method=export version=1 outfile="/volume1/docker/test-1.json" name="test"
- Sichtprüfung, ob alles da ist: ls -l /volume1/docker, Erwartung: zusätzlich existieren /volume1/docker/test-1.json und /volume1/docker/test-1.syno.txz (weil test.syno.txz schon existiert).

Bitte teil doch mal nach genau diesem Muster Deine exakten Befehle (bitte kein: "ich habe exakt gemacht was Du gemacht hast, nur mit anderen Werten") und deren Ausgabe.

Was in jedem Fall nicht funktioniert ist für "name" die Container ID zu verwenden, es muss zwingend der Container Name sein.

 

[luddi]

Was in jedem Fall nicht funktioniert ist für "name" die Container ID zu verwenden, es muss zwingend der Container Name sein.

Nur mal eine kleine Anmerkung am Rande.
Wenn man aber anstelle des Filters name den Filter id verwendet kann auch die ID für diese Zwecke herangezogen werden.

 

[haydibe]

ich meine "name" bei /usr/syno/bin/synowebapi --exec api=SYNO.Docker.Container method=export version=1 path="/docker" name="test". Da funktioniert die ID zumindest bei mir nicht. Ich lasse mich da gerne vom Gegenteil überzeugen. Führ mal aus und zeig mal her

 

[luddi]

Okay dann hatten wir wohl aneinander vorbeigeredet. Ich hatte nämlich interpretiert dass es um das docker command docker ps -a --filter name=test und nicht um das synowebapi.
Ich nehme alles wieder zurück und entschuldige mich für den unqualifizierten Beitrag

 

[Tommes]

Okay dann hatten wir wohl aneinander vorbeigeredet

Das gibt mir langsam echt zu denken

 

[luddi]

Du meinst es liegt wohl doch an meiner Person?

Was in jedem Fall nicht funktioniert ist für "name" die Container ID zu verwenden, es muss zwingend der Container Name sein.

Aber diese Aussage ist ja nicht "eindeutig" bei dem geschriebenen Beitrag, denn es gibt nämlich zwei unterschiedliche Befehle die beschrieben sind in denen "name" verwendet wird.
Ich hoffe ihr seht es mir nach wenn man das auch falsch interpretieren kann wie in meinem Fall.

 

[Tommes]

Du meinst es liegt wohl doch an meiner Person?

Nun ja, ganz von der Hand zu weisen wäre es ja nicht… finde ich… mit einem verschmitzten Lachen im Gesicht. Nein, Quatsch. Alles gut. Mach dir keine Gedanken. Ich muss sowas halt einfach kommentieren, jedoch ohne bösen Hintergedanken. So und nun besser wieder Back to Topic, sonst gibts noch Haue.

 

[luddi]

und nun besser wieder Back to Topic

Wo wir schon bei der api SYNO.Docker.Container sind, gibt es hierzu auch seitens Synology eine offizielle API Dokumentation?
Leider ist diese im Download Center nicht unter den Dokumenten bzw. den White Papers aufgeführt.
Und auch hier unter allen verfügaberen Downloads https://archive.synology.com/download/ ist nichts zu finden.

 

[Tommes]

Ich kenn nur diese hier. Wollte mich immer mal damit auseinandersetze, um es mir für meine 3rdParty Apps nutzbar zu machen. Aber Ich will immer so viel…

Dieses und weitere Dokumente gibt es auf den Seiten von Synology im Developer Bereich

 

[luddi]

Hatten wir wieder aneinander vorbeigeredet? Hatte ich mich wohl wieder nicht verständlich genug ausgedrückt?
Ich fragte explizit nach einer API Dokumentation zu "SYNO.Docker.Container". Und dieses hier welches du verlinkst ist ja quasi "nur" die "DSM Login Web API" und beschreibt nichts mit Docker.
@Tommes Wir beide und Kommunikation...

Ich hatte selbst schon einmal dieses API Dokument gefunden Synology_Virtual_Machine_Manager_API_Guide.pdf. Weshalb nichts explizit zu Docker verfügbar ist wundert mich.

 

[Tommes]

Nein, nein… wir haben nicht aneinander vorbeigeredet. Du sagtest…

Ich fragte explizit nach einer API Dokumentation zu "SYNO.Docker.Container"

… und ich antwortete…

Ich kenn nur diese hier

… wobei die Betonung auf >nur< lag. Es hätte ja sein können, das du dir aus dieser Information irgendwas für die Docker API herauszufiltern vermagst. Ich geh aber nochmal in mich, da ich auch meine, schon mal irgendwas zum Thema Docker API gesehen zu haben.

Wir beide und Kommunikation...

Mittlerweile können wir ja (wieder) drüber lachen. Damals waren wir zwei aber schon leicht gegenseitig angepi**t

 

[blinky911]

Gudem das Thema ist zwar schon älter. Aber kann man da irgendwie einstellen das man nur X Versionen behalten möchte? Sonst würden ja unendliche viele Sicherungen eines Containers gemacht werden.

 

[geimist]

Schieb einfach ein zweites Skript hinterher. Dafür hatte ich mal ArchiveRotate geschrieben. Damit kannst du einstellen, wie viele Versionen in welchen Intervallen erhalten bleiben sollen:
https://github.com/geimist/archive_rotate

 

[EDvonSchleck]

Du kannst auch einfach mit dem Find-Befehl in der untersten Zeile die Dateien nach Tagen X löschen. Hier eingestellt auf 25 Tage.

find /volume1/docker/Docker_BackUps/ -mtime +25 -delete

Die Tage sind natürlich variabel.