Schreibrechte auf grafana.ini in Docker

legro

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

@legro

Also zunächst mal ein paar Worte zu Docker:

Das ist mir bereits soweit alles klar.

Um die Einstellungen für "Panels in Vis" vorzunehmen, passt man üblicherweise die grafana.ini an ... das stimmt schon.
Aber nicht in Docker-Containern!
Hier werden die Einstellungen über Umgebungsvariablen vorgenommen, die man über das Compose als environment mitgibt.
services:
  grafana:
    image: grafana/grafana
    container_name: grafana
    restart: unless-stopped
    ports:
      - '3000:3000'
    environment:
      - GF_SECURITY_COOKIE_SAMESITE=disabled
      - GF_SECURITY_ALLOW_EMBEDDING=true
    volumes:
      - /volume1/docker/grafana:/var/lib/grafana
Damit kann man das Zeug immer wieder starten, verwerfen und komplett neu bauen, ohne dass man nach dem Start noch an Dateien im Container rumfummeln muss.

In der Tat, das ist sehr praktisch und ich bin froh, dass ich das mit dem compose verstanden habe.

Nun zu den Einstellungen, die ich in der grafana.ini immer durchführe ..

[auth.anonymous]
enabled = true
org_name = org_galegro
org_role = Viewer

[security]
allow_embedding = true

Wie sieht die compose.yaml für diesen Fall aus?

OliverIO

Lies dir das nochmal (sorgfältig) durch (inklusive link) und stelle dann die Frage nochmal

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

@codierknecht

Ja leider ist an dem Punkt die Dokumentation nicht so gut.
Auch wissen wir nicht was er genau da ändern will.
Wenn man auf folgender Seite die Beschreibung zur grafana.ini liest, sollte man tatsächlich jede Einstellung auch nur über Environment variablen verändern können.
Das wäre dann noch einfacher wie die grafana.ini nach außen zu legen.
Am Anfang der Seite sind ein paar wenige Beispiele von denen sich das Schema ableiten lässt

alles Großbuchstaben

beginnt immer mit GF

an 2. Position dann der sektionsname aus der ini

dann der eigentliche konfigurationsname

Trennung immer mit underscore _
https://grafana.com/docs/grafana/latest/setup-grafana/configure-grafana/#configure-with-environment-variables

Hier habe ich mal ein Beispiel einer docker-compose/stacks wo man sieht wie das aussehen kann.

Spätestens hier würde ich den Container nicht mehr über einen Shell Befehl konfigurieren und starten, sondern nur noch über docker compose, sonst wird das unübersichtlich

https://volkovlabs.io/blog/using-environment-variables-for-configuration-provisioning-and-dashboards-in-grafana-279661733416/#docker

Codierknecht

@legro

Embedding in Vis aus einem Grafana-Container:

services:
  grafana:
    image: grafana/grafana-oss
    container_name: grafana
    restart: unless-stopped
    ports:
      - '3000:3000'
    environment:
      - GF_SECURITY_COOKIE_SAMESITE=disabled
      - GF_SECURITY_ALLOW_EMBEDDING=true
      - GF_AUTH_ANONYMOUS_ENABLED=true
      - GF_AUTH_ANONYMOUS_ORG_NAME=Main Org.
      - GF_AUTH_ANONYMOUS_ORG_ROLE=Viewer
    volumes:
      - /volume1/docker/grafana/data:/var/lib/grafana

legro

@oliverio

Tut mir leid, aber vermutlich habe ich das noch immer nicht so richtig verstanden.

Ich habe /etc/grafana1 zu /etc/grafana in compose.yaml geändert. Anschließend habe ich einen Neustart des Containers ausgelöst.

Schaue ichanschließend in die Eigenschaften des Containers ..

.. so ist das Mapping unverändert zu /etc/grafana1.

Codierknecht

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

Ich habe /etc/grafana1 zu /etc/grafana in compose.yaml geändert. Anschließend habe ich einen Neustart des Containers ausgelöst.

Warum per externer Datei? Nimm doch den eingebauten Editor.

Das Projekt muss danach neu erstellt werden.

legro

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

Warum per externer Datei? Nimm doch den eingebauten Editor.

Das Projekt muss danach neu erstellt werden.

Wir müssen aufpassen, den Überblick nicht zu verlieren. Dein Vorschlag, alles über Umgebungsvariablen zu regeln, ist eine Lösung; der Vorschlag von @OliverIO beruht m.E. auf dem Versuch, /etc/grafana auf mein externes Verzeichnis ../grafana2/data zu mappen.

Wenn wir all das umgesetzt bekämen, hätten wir am Ende gar gleich zwei Lösungen für mein Problem.

OliverIO

@legro
Na das mit den umgebungsvariablen hatte codierknecht und ich ziemlich am Anfang schon vorgeschlagen. Darauf bist du aber nicht eingegangen, weil ich davon ausgegangen bin das es dir nicht gefallen hat, bin ich dann den anderen Weg mit dir gegangen.

Ich gehe davon aus, das man den Text immer vollständig liest und bei Dingen die man da nicht versteht nachfragt.

legro

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

.., weil ich davon ausgegangen bin das es dir nicht gefallen hat, bin ich dann den anderen Weg mit dir gegangen.

Ich wusste zu dem Zeitpunkt noch nichts damit anzufangen.

Ich gehe davon aus, das man den Text immer vollständig liest und bei Dingen die man da nicht versteht nachfragt.

Dann hoffe ich mal, dass du auch meine letzte Antwort gelesen hast.😉

Warum sollte ich die Datei compose.yaml ändern? Nach der von dir vorgeschlagenen Änderung und dem Neustart des Containers ist noch immer /etc/grafana1 gemappt.

Muss/soll ich den Container löschen und neu erstellen?

Codierknecht

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

Muss/soll ich den Container löschen und neu erstellen?

Nimm dieses Docker-Compose:

services:
  grafana:
    image: grafana/grafana-oss
    container_name: grafana
    restart: unless-stopped
    ports:
      - '3000:3000'
    environment:
      - GF_SECURITY_COOKIE_SAMESITE=disabled
      - GF_SECURITY_ALLOW_EMBEDDING=true
      - GF_AUTH_ANONYMOUS_ENABLED=true
      - GF_AUTH_ANONYMOUS_ORG_NAME=Main Org.
      - GF_AUTH_ANONYMOUS_ORG_ROLE=Viewer
    volumes:
      - /volume1/docker/grafana/data:/var/lib/grafana

pack das in den Editor in der GUI, passe den Pfad an und beim Speichern wählst Du die Option "neu erstellen".

Man muss da gar nicht an Dateien rumeditieren. Geht alles über das UI.

legro

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

Nimm dieses Docker-Compose: ..

Nachdem ich nun um die Verwendung von Umgebungsvariablen weiß, will ich das Ganze auch verstehen. Was ich glaube verstanden zu haben ..

Alle Variablen beginnen mit dem Präfix GF_.
Danach folgt der Bereich oder Abschnitt aus der grafana.ini-Konfigurationsdatei, der verändert werden soll, in Großbuchstaben (z.B. SECURITY, SERVER, AUTH).
Anschließend folgt der Name der Option aus der grafana.ini (ebenfalls in Großbuchstaben!) angefügt mit Unterstrichen.
Alle Elemente werden stets mit Unterstrichen von einander getrennt notiert.

Beispiel: Somit sollte das Admin-Passwort in der Sektion [security] der grafana.ini heißen: GF_SECURITY_ADMIN_PASSWORD=<mein Passwort>

Ist das so richtig?

Codierknecht

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

Ist das so richtig?

So verstehe ich das auch. Die Doku ist da ein bisschen unübersichtlich.

Gib mir ein paar Minuten ... ich probiere das aus.

Edit
Sieht so aus, als würde das funktionieren :grin:

legro

@oliverio

Nun möchte ich auch deinen Lösungsvorschlag verstehen. Könntest du mich bitte dabei unterstützen?

Wenn ich das Ganze richtig verstanden habe ..

Es ist (warum auch immer) nicht möglich das Docker interne Verzeichnis /etc/grafana auf ein externes Verzeichnis auf der Synology (../grafana2/config) zu mappen.
Daher wird das in Docker nicht existierende interne Verzeichnis /etc/grafana1 auf das externe ../grafana2/config gemappt.
Nun kann man im Terminal mittels ..
sudo docker exec -it grafana2 /bin/bash
cp -r /etc/grafana/* /etc/grafana1/ den Inhalt in das externe Verzeichnis ../grafana2/config kopieren.
Im der Terminal der Synology kann ich nun grafana.ini nach Belieben anpassen.

So weit, so gut. Und nun?

Ich sehe nun nur die Möglichkeit erneut im Terminal intern den Inhalt des externen Verzeichnisses nun umgekehrt nach /etc/granfana zu kopieren, wobei es in meinem Fall ausreicht, grafana.ini zu überschreiben/kopieren.

Ich sehe keine Möglichkeit durch Änderungen von compose.yml das externe Verzeichnis auf das interne /etc/grafana zu mappen.

Was habe ich ggf. noch immer nicht verstanden?.

OliverIO

@legro

in /etc/grafana liegen für grafana wichtige dateien ohne die das system nicht startet
wenn du nun ein leeres verzeichnis auf deinem LOKALEN dateisystem mappst, dann ist das verzeichnis IM container ebenfalls leer, ergo system startet nicht
der zwischenschritt mit /etc/grafana1 legt das zunächst leere verzeichnis unter diesem namen IN DEN container, du kopierst die dateien, änderst das mapping wieder auf /etc/grafana, so sind nun alle notwendigen dateien für grafana unter /etc/grafana verfügbar + sie liegen auch in deinem LOKALEN verzeichnis in dem du die bearbeiten kannst.

ein docker image besteht aus verschiedenen schichten/layers, die sich der reihe nach ergänzen aber auch überlagern können, so das am ende für das betriebssystem aber nur eine einzige sicht darauf besteht.

ich habe mal einen blogartikel gefunden, der das etwas visuell darstellt
https://iammathew.com/blog/understanding-docker-images/filesystem

das verzeichnis /etc/grafana mit seinen dateien ist nachdem du dein lokales verzeichnis da drauf gemountet hast immer noch da, da es aber von dem mount zu deinem lokalen leeren verzeichnis überlagert wird, halt für das betriebssystem leer und ohne die dateien mag grafana halt nicht starten.

um notwendige dateien vollautomatisch auch in einem leeren gemounteten Verzeichnis nach aussen bereitzustellen, müsste der imageersteller etwas machen (bei container start prüfen ob alle notwendigen dateien da sind und die fehlenden kopieren) das machen aber viele nicht.

wie schon gesagt, die grafana leute haben eher den environment weg eingeschlagen.

legro

@oliverio

Vielen Dank für deine Rückmeldung.

Mittlerweile konnte ich anhand einiger Quellen ebenfalls eine Antwort finden - durch die hier geführte Diskussion wusste ich schließlich, nach was ich suchen muss. Demnach darf das externe Verzeichnis, das auf das interne /etc/grafana gemappt werden soll, nicht leer sein, sondern muss bereits die korrekte Struktur beinhalten.

Damit wird die oben ausgegebene Fehlermeldung (grafana.ini nicht gefunden) verständlich.

Dein Vorschlag ist also goldrichtig. Indem man /etc/grafana auf das externe Verzeichnis kopiert, kann bei einer Neuinstallation das externe Verzeichnis auf das interne /etc/grafana gemappt werden.

OliverIO

@legro

genau

legro

@Alle

Hier nun eine kleine Zusammenfassung aus all den hier im Thread zusammengetragenen Ideen. Vielen Dank an alle, die hier tatkräftig mitgeholfen haben.

Die Installation von Grafana im Container Manager (Docker) einer Synology erfordert einige Vorkehrungen. Der bevorzugte Weg sollte die Verwendung einer sog. compose.yml Datei sein, die im Wesentlichen eine Art Bauanleitung für die gewünschte Installation darstellt. Im Folgenden wird auch nur diese Lösung beschrieben. Die Installationen über compose.yml werden als Projekte realisiert.

Da nach jedem Neustart der Synology oder des Containers alle Daten verloren gehen, muss man dafür Sorge tragen, dass die Konfigurationsdaten in /etc/grafana (insbesondere grafana.ini) und die in /var/lib/grafana mit den Panels und Dashboards außerhalb des Containers in einem externen Verzeichnis auf der Synology gesichert werden. Dabei sind drei Fälle zu unterscheiden ..

Nur die Daten in /var/lib/grafana werden persistent in einem externen Verzeichnis auf der Synology gespeichert. Der Inhalt der Datei grafana.ini wird über Umgebungsvariablen angepasst.
Sowohl das Verzeichnis mit den Konfigurationsdaten /etc/grafana als auch jenes mit den Daten /var/lib/grafana werden in externen Verzeichnissen auf der Synology persistent gespeichert.
Statt das gesamte interne Verzeichnis /etc/grafana zu mappen, wird nur die Datei grafana.ini gemappt. (Wird hier nicht dokumentiert)

Die im Folgenden vorausgesetzte Verzeichnisstruktur auf der Synology, welche die persistente Daten aufnehmen soll, sieht folgendermaßen aus ..

.. /docker/grafana/config
.. /docker/grafana/data

Diese Verzeichnisse sollten mit Zugriffsrechten für Everyone für Lesen und Schreiben versehen sein. Der oft zu findende Hinweis, chown -R 472:472 /volume2/docker/grafana zu verwenden, ist leider nicht zielführend.

1.Methode:

Das nachfolgende Beispiel zeigt die nötigen Anpassungen für die Einbindung der Panels und Dashboards in die VIS von ioBroker, wobei ggf. nötige Anpassungen der Datei grafana.ini über Umgebungsvariablen bereitgestellt werden ..

services:
  grafana:
    image: grafana/grafana-oss
    container_name: grafana
    restart: unless-stopped
    ports:
      - '3000:3000'
    environment:
      - GF_SECURITY_COOKIE_SAMESITE=disabled
      - GF_SECURITY_ALLOW_EMBEDDING=true
      - GF_AUTH_ANONYMOUS_ENABLED=true
      - GF_AUTH_ANONYMOUS_ORG_NAME=Main Org.
      - GF_AUTH_ANONYMOUS_ORG_ROLE=Viewer
    volumes:
      - /volume2/docker/grafana/data:/var/lib/grafana

Die Syntax zum Aufbau der Umgebungsvariablen ..

Alle Variablen beginnen mit dem Präfix GF_.
Danach folgt der Bereich oder Abschnitt aus der grafana.ini-Konfigurationsdatei, der verändert werden soll, in Großbuchstaben (z.B. SECURITY, SERVER, AUTH).
Anschließend folgt der Name der Option aus der grafana.ini (ebenfalls in Großbuchstaben!) angefügt mit Unterstrichen.
der Wert der jeweiligen Variable wird mit = eingefügt.
Alle Elemente werden stets mit Unterstrichen von einander getrennt notiert.

ein Beispiel: Das Admin-Passwort in der Sektion [security] der grafana.ini wird gesetzt mit: GF_SECURITY_ADMIN_PASSWORD=<mein Passwort>

2.Methode

Hier lautet die compose.yml wie folgt ..

services:
  grafana:
    image: grafana/grafana-oss
    container_name: grafana
    restart: unless-stopped
    ports:
      - '3000:3000'
    volumes:
      - /volume2/docker/grafana/data:/var/lib/grafana
      - /volume2/docker/grafana/config:/etc/grafana

Leider funktioniert das Ganze so nicht ohne Weiteres. Das externe Verzeichnis ../grafana/config darf nicht leer sein, sondern muss bereits eine gültige Struktur, wie sie in einem internen Verzeichnis /etc/grafana vorliegt, enthalten.

Bleibt die Frage, wie man das config Verzeichnis korrekt gefüllt bekommt. Hier ein mögliches Vorgehen ..

Man verwendet für eine temporäre Installation die compose.yml mit folgendem Inhalt ..

services:
  grafana:
    image: grafana/grafana-oss
    container_name: grafana
    restart: unless-stopped
    ports:
      - '3000:3000'
    volumes:
      - /volume2/docker/grafana/data:/var/lib/grafana
      - /volume2/docker/grafana/config:/etc/grafana0

Das Verzeichnis /etc/grafana0 ist (normalerweise) in keinem Image von Grafana vorhanden. Es dient sozusagen als Vorlagenspeicher für das spätere /etc/grafana. Obwohl das Verzeichnis intern nicht existiert, kann es im externen Verzeichnis config auf der Synology gefüllt werden. Hierzu ..

verbindet man sich über das Terminal via ..
sudo docker exec -it grafana /bin/bash
.. mit Grafana im Container Manager, wobei grafana dem Namen des Grafana-Containers entspricht.
Im Terminal kopiert man nun mittels
cp -r /etc/grafana/* /etc/grafana0/ den Inhalt von ../grafana/config in das externe Verzeichnis.

Der letzte Schritt sorgt dafür, dass das externe Verzeichnis ../docker/grafana/config mit korrekten Daten der Standardkonfiguration von Grafana gefüllt wurde.

Nun gilt es den Grafana-Container wieder zu löschen und man kann anschließend mittels ..

services:
  grafana:
    image: grafana/grafana-oss
    container_name: grafana
    restart: unless-stopped
    ports:
      - '3000:3000'
    volumes:
      - /volume2/docker/grafana/data:/var/lib/grafana
      - /volume2/docker/grafana/config:/etc/grafana

.. die gewünschte Installation erzeugen, bei der nun das interne Verzeichnis /var/bin/grafana auf das externe ../docker/grafana/data und das interne /etc/grafana auf das externe Verzeichnis ../docker/grafana/config gemappt wurde.

Meine Empfehlung

Ich bevorzuge grundsätzlich die 2. Methode, die es erlaubt, die Datei grafana.ini komfortabel mit dem Editor der Synology zu bearbeiten.

legro

@Homoran

Wäre diese kleine Anleitung nicht an anderer Stelle besser aufgehoben?

Homoran

@legro Ich habe keine Zeit mich da jetzt reinzuarbeiten.
Das einzige was ich in diesem Thread festgestellt habe, ist dass es eigentlich um Docker geht.
Dein Grafana ist nur ein Beispiel

Codierknecht

@legro

Beim Verfahren über das extern gemappte Verzeichnis für /etc/grafana sollte man aber im Hinterkopf behalten:
Das funktioniert nur, solange sich am Aufbau von z.B. der grafana.ini nix ändert.
Wenn die auf die Idee kommen, die Struktur zu ändern oder auch nur neue Einträge vorzunehmen die für den Start notwendig sind, gibt's Ärger.

Aus genau diesem Grund ist der Weg über die Umgebungsvariablen eindeutig vorzuziehen!

legro

@codierknecht

Dann sollte ich besser meine Empfehlung nochmals überdenken und die dritte Methode priorisieren.:face_with_rolling_eyes:

Community Forum

NEWS

Schreibrechte auf grafana.ini in Docker

Support us

492

32.5k

81.6k

1.3m