OpenEnergyMonitor Development Plan Outline - Base OS and Docker

Organisation
1

Continuing the discussion from OpenEnergyMonitor Development Plan Outline:

[perhaps this should be in Labs?]

You can add DietPi to this list. Installing docker itself is automated via their builtin software management system. I’ve used this method to run HA.

I have yet to be convinced on Docker although I am using it for Home Assistant on Hassio. Having said that it keeps ‘just dying’ - all the outside services seem OK - trying to explore further seems quite tricky (see below).

Whilst integral parts such as Webserver (prefer Lighttpd), database, redis and core are fine, I would not want mosquitto included. With so many systems using MQTT, it is easy to end up with a multitude of Mosquitto brokers.

My other concern is maintenance and trouble shooting. AFAICS, accessing the underlying system is more difficult in Docker. Recent examples of problems that may be more difficult to work through in a Docker environment are REDIS not starting, service-runner cpu time, phpmqtt_input exception issues etc.

I can see the advantages of Docker in theory, but also some pinch points that perhaps should be explored.

It also seems to me this is core only and not EmonHub as well (but I could be wrong).

2 Likes
2

You should be able to mitigate some of the issues around things not starting by e.g. using separate containers per service. Then docker is in charge of making sure things start up, and restarting them if they fail. And if they don’t start up, you can reproduce the problem exactly elsewhere. The counter to this is that it takes up a not-insignificant amount of extra system resources, because you’re running X operating systems instead of 1.

We want to switch our EmonCMS deployment over to Docker at Carbon Coop, so that we have a more reliable deployment pipeline that doesn’t depend on editing configuration or running commands by hand on servers. But that is quite a different situation to running it on end-user Pis.

3 Likes