Schreibrechte auf grafana.ini in Docker

[legro]

@codierknecht sagte in Schreibrechte auf grafana.ini in Docker:

Wie bereits erwähnt: Am besten gar nicht! ..

Wie gesagt, das ist mir klar.

Zeig doch mal, wie Du den Container konfiguriert hast.

Ich habe Grafana wie die übrigen oben genannten Programme über die GUI des Container Managers versucht zu installieren. Konnte ich etwa bei InfluxDB problemlos Verzeichnisse mappen, so gelingt mir dies bei Grafana einfach nicht.

Das geht übrigens am einfachsten mit Docker-Compose, oder in Synology-Sprech "Projekte".

Damit kenne ich mich erst recht nicht aus. Bevor ich mich nun auch noch in dieses Abenteuer stürze, möchte ich den (einfachen) Weg versuchen, der ja doch wohl bei anderen Anwendern zu funktionieren scheint.

[Codierknecht]

@legro sagte in Schreibrechte auf grafana.ini in Docker:

Bevor ich mich nun auch noch in dieses Abenteuer stürze, möchte ich den (einfachen) Weg versuchen

Projekte sind noch einfacher, als den ganzen Salat einzeln zusammenzuklöppeln.
Mit ein paar Zeilen Yaml konfiguriert man alles, was man sonst mühsam zusammenklicken müsste.
Da kann man sich auch 'nen schönen Katalog zusammenstellen. Mit allem was man an Containern so gebrauchen kann. Mach ich mit "SiYuan" (was selbst auch als Container läuft). Siehe unten.

services:
  grafana:
    image: grafana/grafana
    container_name: grafana
    restart: unless-stopped
    ports:
      - '3000:3000'
    volumes:
      - /volume1/docker/grafana:/var/lib/grafana

Läuft

Meine Container-Sammlung in SiYuan:

[OliverIO]

@codierknecht
Ich verstehe nicht warum man dann nicht ins logfile reinschaut.
Ist das bei synology schwierig?
Da steht meistens drin wo das Problem ist.

@legro
Kleiner glitch beim Mappen von Verzeichnissen mit einem leeren Verzeichnis ist, das das Verzeichnis dann leer ist. Wenn da was ist was das System braucht, dann startet das System nicht.

Wenn es das docker compose/stacks auch unter synology gibt und sich dort Projekte heißt dann definitiv das nehmen.

@Codierknecht
Hast du ihm nicht eine Vorlage dafür mit einem Pfad zum Mappen?
Das er erstmal ein lauffähiges System hinbekommt?

[Codierknecht]

@oliverio sagte in Schreibrechte auf grafana.ini in Docker:

Hast du ihm nicht eine Vorlage dafür mit einem Pfad zum Mappen?

Mein Yaml enthält doch ein Mapping.

[OliverIO]

@codierknecht

Hups, ok,

[legro]

@codierknecht

Ich habe mir deinen Vorschlag an meine Gegebenheiten angepasst. Das Ganze müsste nei mir dann wohl wie folgt aussehen ..

Diese Datei habe ich mit dem Editor auf meiner Synology erstellt und in mein Dockerverzeichnis kopiert. Wie sollte/muss diese Datei benannt werden?

Was ich noch nicht verstehe, ist die Zeile 3. Woher weiß das System, welches Image installiert werden soll. Ich möchte das garafana-oss verwenden.

[OliverIO]

@legro

Das ist die Angabe von Image

Aktuell hast du das folgende referenziert
https://hub.docker.com/r/grafana/grafana
Und du willst aber das folgende haben
https://hub.docker.com/r/grafana/grafana-oss

Also einfach bei Image das Folgen notieren
grafana/grafana-oss

Standardmäßig schaut docker immer bei Doktor Hub nach

[Codierknecht]

@legro sagte in Schreibrechte auf grafana.ini in Docker:

Was ich noch nicht verstehe, ist die Zeile 3. Woher weiß das System, welches Image installiert werden soll. Ich möchte das garafana-oss verwenden.

Wenn Du als Registry "Docker-Hub" verwendest, kommt da der Name rein wie er in der Registry angegeben ist.

In Deinem Fall also grafana/grafana-oss

[legro]

@codierknecht @OliverIO

Vielen Dank.

Muss die Installationsdatei das Suffix yaml haben?

[OliverIO]

@legro

Ich gehe davon aus, dass deine aktuelle Konfiguration nicht starten wird, da du nach /etc/grafana getappt hast.
Wenn in deinem lokalen Ordner nicht alle Dateien aus /etc/grafana vorhanden sind, fehlen die auch im Image und höchstwahrscheinlich wird es deswegen nicht starten

[Codierknecht]

@legro sagte in Schreibrechte auf grafana.ini in Docker:

Wie sollte/muss diese Datei benannt werden?

Kann ich gerade nicht (mehr) nachsehen, weil ich meine Syno-VM schon wieder heruntergefahren habe.
Müsste aber grafana.yml lauten.

Wenn Du den Assistenten zum Erstellen nutzt, kannst Du als Quelle ja wählen "docker-compose.yml erstellen".
Dann erscheint unten ein Editor, in den das Compose einfach eingefügt wird.

[legro]

@codierknecht

Ich habe eure Vorschläge in die Tat umzusetzen versucht. Das Ergebnis ist wie gehabt: Der Container startet nicht. Hier das Protokoll ..

In der 3. Zeile habe ich die für voran gegangenen Versuche gelöscht.

[OliverIO]

@legro

Ich glaube, das ist das Log file des Container Managers
Schau mal in dieser Anleitung nach.
Wir brauchen das Log File des Containers selbst
https://mariushosting.com/synology-how-to-check-your-docker-container-logs/

Washast du mit meinem letzten Hinweis zum Mappen unternommen?

[legro]

@oliverio

Ich kann euch kein anderes Log bieten. Das Register Details ist ausgegraut.

[OliverIO]

@legro

ok dann liegt es wahrscheinlich am 2.volume

mache bitte aus
/etc/grafana
dann
/etc/grafana1

und startest den container. er dürfte dann ganz normal starten.
dann gehst du in die details zu deinem container und drückst den knopf mit dem >_ Zeichen bei Action

dann befindest du dich auf der shell IM container.
dort kopierst du den inhalt von /etc/grafana nach /etc/grafana1

im anschluss änderst du im docker-compose das
/etc/grafana1
nach
/etc/grafana

und startest den container neu

dann müsste er normal starten.
dann kannst du die datei grafana.ini die sich in deinem lokalen verzeichnis auf der synology befindet bearbeiten.

da diese datei die rechte vom innerhalb des container hat, wundere dich nicht, das da ggfs komische user/group anzeigen kommen.
auch kann es sein, das du diese dateien mit sudo bearbeiten muss.

der von grafana für docker vorgesehene weg wäre das setzen der environment variablen in einem zusätzlichen abschnitt des docker compose files

[legro]

@oliverio

Langsam aber sicher verstehe ich überhaupt nichts mehr. Was die user und group Rechte betrifft, habe ich selbstverständlich sudo chown -R 472:472 /volume2/docker/grafana2 ausgeführt (was ich jedoch hier im Thread noch nicht erwähnte). Sollte damit die von dir vorgeschlagene Akrobatik nicht mehr nötig sein?

[legro]

@oliverio sagte in Schreibrechte auf grafana.ini in Docker:

ok dann liegt es wahrscheinlich am 2.volume

Ich fürchte: nein

Ich habe das Ganze bereits mit zwei, einem und keinem gemappt Volume ausgeführt. Nur bei letzterem konnte ich den Container starten.

[OliverIO]

@legro

woher hast du diese Anweisung?

evtl mal ein kurzabriss zu docker.
docker ist zu applikations abstraktion da.
d.h. in einem image ist alles enthalten, was eine applikation benötigt, inklusive dem jeweiligen betriebssystem + evtl weitere tools.
meist werden da seeeehr kleine betriebssysteme verwendet, die nur wenig mehr als den kernel + wirklich die notwendigsten dienste enthalten.
das standard image ohne zusätzlichen tag angaben verwendet alpine

wenn du ein volume mountest, dann ist das wie ein guckfenster auf das dateisystem in deinem container. das betriebssystem/applikation liest schreibt/liest da ganz normal drauf (zumindest was normal für das betriebssystem IM container ist).

durch das kopieren von /etc/grafana nach /etc/grafana1 sind eigentlich auch alle berechtigungen inklusive user/group/owner mitkopiert worden.
daher hättest du eigentlich nix machen müssen.

hat es den geklappt, nachdem du die dateien kopiert hast?

[OliverIO]

@legro sagte in Schreibrechte auf grafana.ini in Docker:

Ich fürchte: nein
Ich habe das Ganze bereits mit zwei, einem und keinem gemappt Volume ausgeführt. Nur bei letzterem konnte ich den Container starten.

existieren die lokalen verzeichnisse, die du da angegeben hast?

da /etc/grafana1 IM container definitv nicht exitiert, dürfte das eigentlich kein problem sein. dann muss das problem auf der lokalen seite des mappings liegen

bitte den aktuellen stand deines docker compose als text nochmal posten

[legro]

@oliverio

Mit dieser von dir vorgeschlagenen Änderung startet der Container ebenfalls nicht, sodass ich alle weiteren Vorschläge gar nicht erst angehen konnte.