This gets all of the apps in the stack running identically as they were, though based upon the upstream docker images from Dockerhub.
This is true, with the exception of Grafana, which I noticed you copy in a preconfigured grafana.db.
Using SQL commands in docker-compose to run when the container is started could be a manner by which we provision small things such as the organization name, however this is not replicated in this PR, so the default name is main_org for now until we figure out a way to provision that.
I think it's preferable to leave Grafana as a blank configurable slate, unless we want to have configurations such as #BALENA_SENSE=1 which would copy in the grafana.db from earlier.
I have used the aforementioned documentation to have influxdb configure itself as http://influxdb:8006.
I have set the provisioning information to use the variable database name $MING_INFLUX_DATABASE as a database, so we can begin using this convention around the stack to refer to things that can be modified in the balena dashboard or cli.
I've also changed the volume sense-data to influxdb-data to fit in with the convention of the rest of the names. This will break any existing installations influxdb, unless the volume is renamed manually.
I've specified explicit versions in the dockerfile for each service, avoiding using :master or :latest for safety.
This gets all of the apps in the stack running identically as they were, though based upon the upstream docker images from Dockerhub.
This is true, with the exception of Grafana, which I noticed you copy in a preconfigured grafana.db.
Using SQL commands in docker-compose to run when the container is started could be a manner by which we provision small things such as the organization name, however this is not replicated in this PR, so the default name is main_org for now until we figure out a way to provision that.
I think it's preferable to leave Grafana as a blank configurable slate, unless we want to have configurations such as #BALENA_SENSE=1 which would copy in the grafana.db from earlier.
This is planned to be updated in the future, as Grafana themselves admit it's not ideal that this has to be done directly in the DB in this documentation. https://grafana.com/docs/administration/provisioning/
I have used the aforementioned documentation to have influxdb configure itself as
http://influxdb:8006.I have set the provisioning information to use the variable database name $MING_INFLUX_DATABASE as a database, so we can begin using this convention around the stack to refer to things that can be modified in the balena dashboard or cli.
I've also changed the volume
sense-datatoinfluxdb-datato fit in with the convention of the rest of the names. This will break any existing installations influxdb, unless the volume is renamed manually.I've specified explicit versions in the dockerfile for each service, avoiding using :master or :latest for safety.
The .sane dockerfiles are referencing https://forums.balena.io/t/balena-cloud-cli-builder-is-still-not-able-to-interpret-image-manifests/43203, an issue relating to the balena builder.