InfluxDB up until the recent 0.10 version was quite brittle, sometimes it would crash or leak - other times it would appear to be up but no new points would be written to it (or one of the databases you created in it).
Anyway, Grafana v2.6 and InfluxDB v0.10 seem like a good stable combo that works well together. And both are a simple yum install away.
The motivation to put this into an image was that other teams wanted to deploy this and they'll probably end up on the same host so I was looking for isolation of the databases (mainly to protect our team's working dashboard from other fiddlers).
Dockerizing the entire stack into one single container is convenient in some regards, but goes against the Docker philosophy of one process (service) per container. Have you tried stitching this setup together with docker compose?
Yes. I definitely concede that this is a compromise on the Docker model. I say so in the post and mention using compose. At least I have all the bits playing nicely which would be the first step to splitting them all up anyway :)
Even if we remove docker from the recipe, and we think just about grafana and influxbd, I'm with the other comments:
unless it's just for a test, or for a few personal metrics... separate it.
Eventually, your metrics, sources of metrics, and dashboard users, are going to grow.
Maybe you want even different access level rules for them as soon as your organization is more than one person.
And eventually, different upgrade needs will arise (supported versions, vulnerabilities, etc) do you want your metrics down, because an XSS in your dashboard?
Not really experienced on docker, but all I've read points that this is not recommended practices...
I'd tentatively suggest that this isnt the best way to dockerise.
Now, unless something has changed, there is no init inside your container, which means anything with a wait() in it will never get cleaned up.
Also, with an eye on the future its going to be a massive pain to scale.
I have grafana on a separate machine to the graphite cluster (grafana does almost no work.) apart from the actual data, the whole thing is deployable without manual intervention. (all without docker too)
I'd suggest the same for influxdb, it shards by default....
Have you considered running individual containers with supervisord? It's init system agnostic, and works pretty great. Here's a pastebin to get you started. http://pastebin.com/4a9wRfBJ included are some hooks for systemd journald.
I would like to know whether you believe that there is any possibility of create SCADA systems using InfluxData platform. I was looking for examples in Google but I found only a pair of websites. Nothing serious.
recuter|10 years ago
Anyway, Grafana v2.6 and InfluxDB v0.10 seem like a good stable combo that works well together. And both are a simple yum install away.
Docker doesn't get you anything in this instance.
sjbx|10 years ago
The motivation to put this into an image was that other teams wanted to deploy this and they'll probably end up on the same host so I was looking for isolation of the databases (mainly to protect our team's working dashboard from other fiddlers).
rodionos|10 years ago
sjbx|10 years ago
txutxu|10 years ago
unless it's just for a test, or for a few personal metrics... separate it.
Eventually, your metrics, sources of metrics, and dashboard users, are going to grow.
Maybe you want even different access level rules for them as soon as your organization is more than one person.
And eventually, different upgrade needs will arise (supported versions, vulnerabilities, etc) do you want your metrics down, because an XSS in your dashboard?
Not really experienced on docker, but all I've read points that this is not recommended practices...
KaiserPro|10 years ago
Now, unless something has changed, there is no init inside your container, which means anything with a wait() in it will never get cleaned up.
Also, with an eye on the future its going to be a massive pain to scale.
I have grafana on a separate machine to the graphite cluster (grafana does almost no work.) apart from the actual data, the whole thing is deployable without manual intervention. (all without docker too)
I'd suggest the same for influxdb, it shards by default....
sjbx|10 years ago
LinuXY|10 years ago
sjbx|10 years ago
pcocko|10 years ago