OpenProject Container wird nicht erstellt??

[exFile]

Hallo,
auf meiner DS-1819+ habe ich Docker über das Paketmanagement von Synology installaiert.
Dann das unter Registrierung "openproject/community:last" gewählt und die 2GB geladen.
Konfiguriert habe ich es wie auf der Seite von doktorerp beschrieben.
https://www.doktorerp.de/openproject-synology-nas/

Allerdings kann ich nicht genau nachvollziehen was er mit Klicke auf der linken Seite auf “Container” meint.
Bei mir sehe ich weder eine Reiter "Container" und habe dann auf übernehmen gedrückt.
Nach weiter erhalte ich Einsicht in die gemachten Einstellungen. Container und Button Details kann ich nirgends finden.
Wenn ich dann auf fertigstellen klicke erhalte ich die Fehlermeldung: Docker-API ist fehlgeschlagen.
Weitere Infotmationen im Docker Protokoll.

Und dort steht: Create container openproject failed: {"message":"error creating overlay mount to /volume1/@docker/overlay2/eineLangeNummerdac39-init/merged: invalid argument"}.
Es will einfach nicht gelingen.
Wäre super wenn mir jemand helfen könnte.

Danke

 

[haydibe]

Wenn Du Screenshots Deiner Aktionen beifügst, haben andere eher eine Chance Dir zu helfen... Magst Du die ergänzen?

Die Fehlermeldung mit "overlay2" finde ich irritierend. Mir ist bis dato keine Syno bekannt, die overlay2 unterstützt.
Kannst Du auf der Shell als root mal `docker info | grep -i "storage"` ausführen und schauen, ob da wirklich overlay2 steht?

Update nach hinzufügen der Screenshots:
Die Konfiguration sieht gut aus, Den Schritt der in der Anleitung unter "Container" steht hast Du schon direkt im Tab "Port-Einstellung" gelöst, wobei Du hier auch andere lokale Ports hättest nehmen können - die Container Ports sollten immer gemäß Anleitung bleiben. Deine Einstellungen sehen korrekt aus. Hier liegt die Ursache für das Problem mit der Container-Erzeugung nicht.

Zum Overlay2-Problem:
Hast Du Dein Docker-Paket in irgendeiner Form modifiziert? In den englischsprachigen Foren ging da vor kurzem eine entsprechende Anleitung (die Aktion bricht mit Sicherheit die integration zwischen Syno Docker-UI und Docker-Engine und ist imho nicht empfehlenswert). Bitte den Befehl oben ausprobieren und die Antwort posten.

 

[haydibe]

Allerdings kann ich nicht genau nachvollziehen was er mit Klicke auf der linken Seite auf “Container” meint.
Bei mir sehe ich weder eine Reiter "Container" und habe dann auf übernehmen gedrückt.
Nach weiter erhalte ich Einsicht in die gemachten Einstellungen. Container und Button Details kann ich nirgends finden.

Gemeint ist das Navigations-Element "Container", dass auch auf deinem letzten Bild zu sehen ist. Was er geschrieben hat ergibt nur Sinn, wenn der Container gestartet wurde.
Dann kannst Du ihn in der List auswählen und oben den Knopf "Details" anklicken. Wenn man die lokalen Ports nicht angibt, dann werden diese dynamisch vergeben. In den Details solltest Du diese "nachschauen", was sich dadürch erledigt hat das Du diese schon selbst konfiguriert hast.

 

[exFile]

Wenn ich im Reiter Umgebung die letzte Einstellung überprüft habe und übernehmen drücke, dann erhalte ich nochmal die Übersicht und kann "weiter" klicken.
Dann erhalte ich schon die Fehlermeldung. Wenn ich dann nochmal "Starten" drücke sind alle angaben wieder zurückgesetzt.

So habe jetzt mal nachgelesen wie ich zur Synology verbinden kann um den Shell Befehl ab zu setzen.



Ob ich es jetzt mit den Port-Einstellungen direkt definiere oder es automatisch malchen lasse indem ich die Option "Dasselbe Netzwerk wie Docker Host verwenden"
in Netzwerk deklariere. Ich bekomme immer diese Fehlermeldung

Ich sehe gerade, das hier das gleiche Problem schon mal aufgetreten ist?!?!?
https://www.synology-forum.de/showthread.html?73395-Docker-API-ist-fehlgeschlagen-Beim-Start-eines-Abbildes%21&p=844765&viewfull=1#post844765

 

[haydibe]

Wie oben geschrieben muss der Befehl als root ausgeführt werden. root!=admin. Mit `sudo -i` kann der admin user zu root werden.

"Dasselbe Netwerk wie Docker Host" bindet die Netzwerkkarte der Syno direkt. Sobald es auch nur einen Port-Konflikt gibt (weil diese von der DS schon anderweitig gebunden ist), kommt der Container nicht hoch.

Ich hab das ganze mal in eine docker-compose.yml gekippt (mir its die UI zu umständlich) und probiert. Bei mir ist Docker auf einem ext4 volume und es verwendet aufs... läuft!

version: '2.2'
services:
  openproject:
    image: openproject/community:latest
    ports:
      - 35432:5432
      - 38080:80
    volumes:
      - /volume1/docker/haydibe/openproject/pgdata:/var/openproject/pgdata
      - /volume1/docker/haydibe/openproject/assets:/var/openproject/assets
    environment:
      SECRET_KEY_BASE: irgendeinebeliebigezeichenkette

Das einzige Manko das ich erkennen kann ist, dass das Image nicht nach Docker Bestpractice die Anwendung von der Datenbank trennt.
Auf der Github Seite gibt es vom Hersteller dann auch noch eine vernüftige docker-compose.yml, die sich an den Bestpractices orientiert.

 

[exFile]

Danke für die Info mit den Root Recheten.
Habe jetzt nochmal einen Screen gemacht


Ich habe die Platten auch unter ext4 am laufen.
Kann ich irgendwo nachsehen ob es am Portkonflikt liegt?
Auch bei der automatischen Verwaltung kam der Container nicht?

Leider muss ich die GUI verwenden, da ich mit zwar immer vorgenommen hatte mich mit Linux auseinander zu setzen,
aber immer etwas dazwischen kommt.
Ich kenne mich das sonst nicht wirklich gut genug aus.

 

[haydibe]

Einen Port-Konflikt würde man sofort erkennen, da es einen entsprechenden Hinweis bekommen.
Wenn man "Dasselbe Netzwerk wie Docker Host" verwendet gibt es kein Port-Mapping - es wird die Netzwerkkarte vom Host(!) verwendet.
Nur wenn man das nicht anhakt kann man Ports mappen.

Zu Overlay2: Ich fress nen Besen.. hier wird tatsächlich overlay2 verwendet - nur funktioniert es nicht richtig.
Bisher ist mir noch keine DS mit overlay2-Support untergekommen. Ich tippe darauf, dass die Package Maintainer das schlichtweg nicht getestet haben und Overlay2 auf der Syno kaputt ist. Wäre nicht das erste mal *hüstel*. Das Docker-Paket ist seit den 18.09.x nicht mehr wirklich sauber (Client+Server mit unterschiedlichen Versionen; ENV für docker-compose gefixed und für Swarm Mode kaputt),.

Ich würde empfehlen ein Support-Ticket bei Syno aufzumachen!

In der Zwischenzeit könnte man als Workaround auf den AUFS-Treiber umstellen:
Dazu muss die Datei /var/packages/Docker/etc/dockerd.json um folgenden Zeile ergänzt werden:

{
...,
"storage-driver": "aufs"
}

Danach muss das Package neu durchgestartet werden.

Die drei Punkte und das Komma stehen für Zeilen die bereits in der Datei stehen. Wichtig ist hinten bei der letzten existierenden Zeile ein Komma einzutragen und in der nächsten Zeile den storage-driver zu konfigurieren.

Warnung: alle images und container sind danach für Docker nicht mehr sichtbar. Nachdem ein Bugfix erzeugt wurde und man das auf overlay2 zurückstellt ist es leider auch wieder so. Daten die der UI über Volumes gemapped wurden, sind davon nicht betroffen.

 

[exFile]

Synology hat mein Ticket bearbeitet und den Storagetreiber von OverlayFS zu AuFS konfiguriert.
Die Entwickler wissen von dem Problem und wollen es in Aktualisierungen beheben.

Bin froh, das es jetzt funktioniert und nochmals vielen Dank.

 

[haydibe]

Gerne!

Denk daran, dass eine spätere Umstellung des Storage-Treibers, dazu führen wird, dass die bisherigen Images (siehe: docker image ls), Container (siehe: docker container ls) und Named Volumes (siehe: docker volume ls) dann für einen anderen Storage-Treiber unsichtbar sind. Solange man die Container-Konfiguration vorher exportiert und brav bind-mounts (aka Volumes über die Syno UI) nutzt um die Bewegdaten ausserhalb des Containers zu speichern, kann man die Container durch einen import der Konfiguration meistens problemlos wiederbeleben.