
Wrangling Grafana and InfluxDB into a Docker Image - sjbx
http://simonjbeaumont.com/posts/docker-dashboard
======
recuter
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.

Docker doesn't get you anything in this instance.

~~~
sjbx
Yeah, I was a bit disappointed with the upgrade methods for InfluxDB, but I've
noticed the leak of the _internal DB
[https://github.com/influxdata/influxdb/issues/5290](https://github.com/influxdata/influxdb/issues/5290).
I'll probably upgrade soon.

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
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?

~~~
sjbx
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 :)

~~~
rodionos
Good to know compose is on your roadmap. We're guilty of bending the container
dogma ourselves, mostly due to lack of time to decompose parts of our own
stack.

------
txutxu
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...

------
KaiserPro
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....

~~~
sjbx
You're probably right. To be honest, just an opportunity to play around with
Docker and make it easier to duplicate for others in our team.

------
LinuXY
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](http://pastebin.com/4a9wRfBJ) included are some
hooks for systemd journald.

~~~
sjbx
@LinuXY thanks for this. Looks pretty useful!

------
pcocko
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.

