Before making any request, I’d like to clarify if this is even possible.
When installing software via dietpi-software, by default these apps are installed to the host dietpi system.
If Docker was already installed, would it be feasible or viable to have dietpi-software detect if Docker was installed, check if a docker image exists for the package and then give the option to either HOST install the software or install using Docker instead?
I guess there would be a few extract steps involved installing software via docker, since it would depend on if any bind-mounts are required (they could be defaulted to the same as a normal install for the software, but that would also require a re-check of every dietpi-software package to determine if the default host installs are correctly setup with the correct directory locations for the config files, etc. Then using these and Docker, they’ could be bind-mounted accordingly when installed via Docker)
Is this even feasible? or not even possible given the limitations of how Dockers work and software installs?
Our goal is to install applications directly instead of using Docker. Therefore, your request will most likely not find its way into a DietPi release. Normally, Docker containers are quite easy to set up and the user can perform the installation steps of the image provider themselves. There is not much we could automate here.
ah ok, so it is by design dietpi direct to host and not have any option to install to docker via dietpi-software (not even give admins a choice?)? Then why bother having docker in the dietpi-software list, if not really dietpi-integrated, people can just manually install it anwhow and use dockers…
I guess can fork a docker-pi offshoot for it, …docker containers seem far more secure than host installs and so much easier to clean up cl****cks (esp if pi’s are integrated in a swams, multi-enviro’s, etc.) and a headache to re-install OS often.
We offer Docker, Docker Compose and Portainer for everyone who like to have apps within container.
Feel free to install Docker manually if you wish. As well it’s up to you to use whatever container you like.
However on small SBC, Docker already could be a challenge due to resources requirements. On modern SBC it might be different.
And a Docker swarm is in most of use cases not needed and people even don’t know how to use them.
But this is a general discussion about Docker or native apps. And we decided not to offer Docker container directly as there is basically nothing we can automate on this. As well it’s quite simple to follow the individual container docs to get them up.
Last point is man power. The whole project has 1 developer who is maintaining the entire DietPi stack. Adding an additional layer like Docker would increase complexity and maintenance efforts.
Also note, that even if getting up a Docker container for a particular software title is usually a one-liner, it is still different for each app: Some require volumes, others require forwarded ports, again others require other containers to work with, like for database servers, and hence usually Docker Compose. Also admins may prefer Docker Conpose even when not required, others may prefer a GUI like Portainer, others may want to use Watchtower for updates (which renames old images). Respecting all this requires a lot of code for every of the ~200 software titles.
And last but not least: IMO a container only be used when you know that it really is a benefit for your particular use case, and when you know about the implications and how to manage it. It is easy to install, but it is another layer of complexity and point of failure. And with this knowledge, spinning up the container itself is not a hurdle anymore where we could help, but only possible limitations in how we would set it up for most but not all use cases.
We make it fast and easy and allow to automate the installation of the Docker engine, optionally Compose and Portainer, as well as other container engines (K3s, MicroK8s). But from there, one better manually installs and sets up the container(s) as needed.