I've proposed last October the development of something that I called:
The idea began something like the Hubitat Package Manager, where users could add "packages" e.g. NodeRed and so on. Then, @dman2306 came up with a comment that what I was trying to develop would be something like Docker containers. Bingo! That's it!!!!
Since I never worked/used Docker, it has been a very slooooowwwww development and I must confess that between my regular work - 12 hours shifts that are killing me - and the preparation to - hopefully - moving from Brazil to Portugal, I have little to none time to work on the idea.
Docker is the king right now on getting multiple applications running on a OS where there dependency conflicts with software stacks and networking. I have a new motto "if they don't offer it in a docker container I don't use it'.
Looking at what you are trying to approach here I would say having a list of known stable implementations of "Companion" services that work in Docker and on the Pi would be great. One thing for sure that all docker images need to be open with their sources on Github and published into the Docker Hub. Additionally they should support both a classic docker CLI and Docker-Compose implementations.
Certain core services such as SAMBA, WSDD, Time, etc are core the OS but everything else Docker.
I think it so - it could be very useful, wouldn't it?
See, I'm not a "Linux" guy, and a lot of HE users I think are not too, so, having an easy way of installing "companion" services on a RPi would be a really nice addition to HE itself.
One of my worries was on how to manage Docker images - install, update, remove, configure and so on - so it could be easy for a Linux newbie - like me! - to work with Docker images. But I saw a comment in one of the posts here that there is already something available to do that: Portainer! It seems to be perfect for that.
One of the feasible and I believe easy to implement Docker images would be:
It would solve the problem that so many HE users talk about: getting HE backups out of the HE itself, periodically and automatically.
What I'd like to do is to get the attention of someone versed in Docker and take the lead on this. I hope I'll do.
Even a newbie with Docker needs to get their feet wet with the command line. Portainer only fills a small part of managing Docker applications and their components. Yes you can download a image, create volumes, and networks. But you still need to provide the "configuration" to glue them together. Portainer is great for having a view of what is going on inside of Docker but as a tool for implementation of containers I still go for Docker-Compose and yaml files.
If you look at many Docker images and their documentation they also provide the command line and/or compose deployment. They also document the use of persistent storage and environment configuration which will be unique to the device/os being deployed on.
The learning curve isn't too steep since the person using docker has already invested somewhat in Linux configuration if they purchased a Pi.
But if we had a Wiki on "Companion" images and sample configurations that would be a start. Someone would have to take on the curation of such a list.
Well, the idea would be to provide to developers a "roadmap" to create Docker images and they, by their part, would develop such images and made them available for everyone.
I've created a basic Pi configuration with Docker installed - as a trained monkey, to tell the truth ... just typing what the instructions told me to do !
Well, that I could do. I could propose and run a process of Docker "Companion" images submission, "peer evaluation" and management.
Seems like a chicken vs egg problem if no one is stepping up offering to create and maintain the tailored containers (I'm definitely not).
I really don't see much value in this initiative, really. For example, the benefit of a node-red container that comes 'pre-loaded' with the hubitat nodes is of very limited benefit over a generic node-red container + a 1 liner telling people how/where to go add the node and configure it. End user still needs to understand how to use node-red - this doesn't lower the technical bar for anyone.
But at the same time if you get enough people interested and willing to push this forward, kudos.
