[Frank Fischer]

Hallo, der Serveradmin möchte, das ich anstatt der von Docker verwalteten Volumes Pfade nehme.
Er hat mir dafür 2 Disks zur Verfügung gestellt:

/opt/otobo-sql und /opt/otobo-data

Unter otobo-data habe ich dann noch  folgende Verzeichnisse angelegt:
otobo_elasticsearch_data  otobo_opt_otobo  otobo_redis_data

In der otobo-base.yml habe ich dann die Volumes gegen die Pfade ausgetauscht:
volumes:
– ‘/opt/otobo-sql:/var/lib/mysql’
volumes:
– ‘/opt/otobo-data/otobo_opt_otobo:/opt/otobo’
volumes:
– ‘/opt/otobo-data/otobo_opt_otobo:/opt/otobo’
volumes:
– ‘/opt/otobo-data/otobo_elasticsearch_data:/usr/share/elasticsearch/data’
volumes:
– ‘/opt/otobo-data/otobo_redis_data:/data’

Den Teil mit:
# no volumes need to be exposed across services
habe ich komplett entfernt.

Wenn ich jetzt das ganze mit docker-compose uo -d starte, bekomme ich Fehler vom Typ Access Denied, wie diesen:
tacktrace”: [“org.elasticsearch.bootstrap.StartupException: ElasticsearchException[failed to bind service]; nested: AccessDeniedException[/usr/share/elasticsearch/data/nodes];”,

Ich habe mal die Berechtigungen der Verzeihnisse auf 777 geändert, dann fuhr zumnedestens die DB hoch, der Rest hat aber immer noch Probleme mit den Berechtigungen.

Ist diese Art der Installation nicht vorgesehen?

Gruß
Frank

 

 

 

[Frank Fischer]

Hm, das scheint an cap_drop: – ALL zu liegen, dadurch haben die Container keine Berechtigungen mehr in den Pfaden so einfach zu schreiben.  Mal schauen welche UID/GID die Volumes in der Testumgebung haben, vielleicht kann ich die User sanlegen und dann auf die einzelnen Bereiche berechtigen

[Frank Fischer]

Mit
cap_add:
– CAP_SYS_CHROOT
– CAP_SETUID
– CAP_SETGID
Problem gelöst, nur ist das dann noch sicher? Oder ist das ein Kompromiss?

[bes]

Hallo,

wenn ich es richtig verstehe, dann ist die Anforderung dass die Daten nicht einem von Docker erstellten Verzeichnis liegen sollen. Anstatt dessen sollen definierte Verzeichnisse verwendet werden. Diese Anforderung kann man mit Bind-Mounts erreichen. Eine Alternative wäre die Verwendung von externen Volumes. Nach meinen Verständniss müsste man dazu folgendes tun:

1. Mit volume create  die benötigten Volumes erstellen. Beim Driver ‘local’ kann man mount Optionen mitgeben die angeben welches lokales, oder auch remote, Verzeichniss verwendet werden soll. Siehe das  ‘btrfs’ Beispiel in der verlinkten Doku
2. In _otobo-base.yml_ die Volumes, am Ende der Datei, als External markieren, siehe https://docs.docker.com/compose/compose-file/07-volumes/#external

Aber mehrere Wege führen zum Ziel, man kann auch die Volumes direkt in _otobo-base.yml_ konfigurieren, https://docs.docker.com/compose/compose-file/07-volumes/#attributes .

Empfehlenswert ist auch dass man die Compose-Dateien nicht ändert sondern in einer zusätzlichen Compose-Datei ablegt. Diese zusätzliche Datei muss dann in _.env_ an COMPOSE_FILE angehängt werden.

Achtung: Diese Skizze habe ich nicht getestet.

Viele Grüße,

Bernhard

 

 

 

[Autor]

Beiträge