Hi all, @akbooer asked me to join this community - so far I was only active on MCV. I am the author of the Docker image for openluup that is referred to in this thread.

I quickly read the complete thread. Most of the comments contain valid statements.
Personally I would not avoid containers as the pest - in fact, you can't ;). Containers exist for a long long time (at least in the Linux kernel) and play an important role for isolation of processes/networks/filesystems. Docker has made this system significantly easier to use and understand. By now also Windows supports containers and (in the latest builds even without HyperV virtualization) can even run Linux containers. This begins to fade the most significant difference between VMs and containers away, this being virtualization (for VMs) versus isolation (containers). Opposed to VMs, containers are very lightweight (try creating a VM that runs openLuup in under 7MB :D). A container does not contain a kernel and does not have an operating system. It also cannot run on itself.

Maybe some of you experienced the 'dll hell' - the issue where the installation of an application breaks another application, because one overwrites a shared library of the other. This is what you can prevent by packaging applications and one of the reasons for things like snap, flatpack and docker to emerge.

So as @toggledbits mentioned, a (well written) container indeed does not contain much. A docker container basically provides the 'batteries included' concept. This makes it very easy to get started with a new application like openLuup. In order to get the same experience with a VM, you'd need a pre-build image, or an automation system like Ansible, Puppet or Chef - tools that not every newbee is likely to master.

There is no general 'better' when it comes to VMs verses contains and in many cases both are used, each for their own specific benefits, one of which is personal preference.
When you, like @akbooer, want to consolidate your setup on a not highly powerfull NAS, a container is the way to go.

@akbooer As @RHCPNG said, you can easily do this, once you have a running setup by copying the contents of /etc/cmh-ludl/ to a local folder, restart the container with that folder mounted to /etc/cmh-ludl/.

The difference between using a volume and a folder mount is (amongst other details) how Docker handles this at first startup. When using a volume, Docker copies the contents of e.g. /etc/cmh-ludl/ when it is started with a empty new volume, to that volume. As of that moment all changes are kept in the volume and survive container restarts and updates.
A mounted folder also preserves all settings, but in contrary to volumes, Docker does not copy the original contents of the mount target to the folder at first startup. This means you need to store create the files needed in /etc/cmh-ludl/ yourself, which makes it harder to initially get start (except for one who masters openLuup ).

The latest version of the Docker image vwout/openluup includes LuaJIT 2.1.0-beta3.
OpenLuup is not (yet) automatically run using LuaJIT. In order to use it, you need to manually change openLuup_reload_for_docker and changes the lines lua5.1 openLuup/init.lua $@ to luajit openLuup/init.lua $@, especially if you are using volumes or a mount as source for /etc/cmh-ludl.