Closed MatthewCroughan closed 3 years ago
The reason for this is that /var/lib/grafana/grafana.db
contains everything relating to Grafana, so the application is inherently stateful. This includes dashboards, database configuration, plugins and more. We can only set this up during the first runtime, anything included in /etc/provisioning at runtime will be built into grafana.db, but this would require us every single time we build the container to make sure we have backed up our dashboards and put these dashboards into /etc/provisioning somehow, which would require modification of the build directories on the machine running balena push
or docker build
If we don't somehow do this, all the dashboards, plugins and other data will be removed on the next build and will have to be reimported via the grafana dashboard.
We already automate the provisioning of the intercontainer influxdb connection like so:
COPY ./datasources/datasources.yaml /etc/grafana/provisioning/datasources/datasources.yaml
where the contents of datasources.yaml are as follows:
lines (12 sloc) 233 Bytes
apiVersion: 1
datasources:
- name: influxdb
type: influxdb
access: proxy
database: ming_default
user: admin
url: http://influxdb:8086
jsonData:
timeInterval: "15s"
secureJsonData:
password:
There's no other solution. We need to map /var/lib/grafana, otherwise every time the container restarts we'll lose that DB, however I think my previous comments about being unable to manage other parts of the app are false, since I tried making the DB persistent, and changing GF_AUTH_ANONYMOUS_ENABLED=true
to false
, applying that change, and that seemed to work.
For some reason all of its data isn't stored in /data, just noting this down so I can fix it later.