In my experience, "simplification" and "Docker" don't really go in the same sentence. Yeah, it's (maybe) simpler if you're just plugging things together that are already Dockerized, but if you're writing your own Dockerfiles, none of the actual complexity really goes away. If anything, you're making things even more complex by containerizing things that don't actually need containerized.
"why isn't there a prepackage wrapper"
Because nobody's gotten around to writing one yet, or perhaps because nobody's felt the need to do so yet. Not much stopping anyone from doing so. That's where the "bit of shell scripting" comes in. Writing an rc.d script [1] (using rc.subr to do away with the boilerplate normally associated with the sorts of initscripts normally strawmanned by systemd advocates) ain't any harder than writing a Dockerfile (in my opinion it's actually much nicer/simpler). Neither is creating a user under which your app will run. Hardest part will probably be around deciding what needs to go in your chroot.
Hell, if you include OpenBSD packaging [2] as part of that development pipeline, then tada, you're pretty much there. Install the package, run "rcctl enable your-app-name && rcctl start your-app-name", and you're good to go.
So the trick here would then be to extend that to install and run multiple isolated copies of that package, each instance having its own configuration and chroot. Or perhaps using a single package and writing your service/app such that it does the forking/chrooting for each isolated environment (which is what quite a few OpenBSD-focused daemons already do, from what I can tell/observe).
The overall point, though, is that comparing Docker to Dropbox is erroneous. Dropbox actually was simpler/easier than the "solution" posed by that comment. Compared to the OpenBSD way of doing things, Docker is not; if anything, it's more complexity.
In my experience, "simplification" and "Docker" don't really go in the same sentence. Yeah, it's (maybe) simpler if you're just plugging things together that are already Dockerized, but if you're writing your own Dockerfiles, none of the actual complexity really goes away. If anything, you're making things even more complex by containerizing things that don't actually need containerized.
"why isn't there a prepackage wrapper"
Because nobody's gotten around to writing one yet, or perhaps because nobody's felt the need to do so yet. Not much stopping anyone from doing so. That's where the "bit of shell scripting" comes in. Writing an rc.d script [1] (using rc.subr to do away with the boilerplate normally associated with the sorts of initscripts normally strawmanned by systemd advocates) ain't any harder than writing a Dockerfile (in my opinion it's actually much nicer/simpler). Neither is creating a user under which your app will run. Hardest part will probably be around deciding what needs to go in your chroot.
Hell, if you include OpenBSD packaging [2] as part of that development pipeline, then tada, you're pretty much there. Install the package, run "rcctl enable your-app-name && rcctl start your-app-name", and you're good to go.
So the trick here would then be to extend that to install and run multiple isolated copies of that package, each instance having its own configuration and chroot. Or perhaps using a single package and writing your service/app such that it does the forking/chrooting for each isolated environment (which is what quite a few OpenBSD-focused daemons already do, from what I can tell/observe).
The overall point, though, is that comparing Docker to Dropbox is erroneous. Dropbox actually was simpler/easier than the "solution" posed by that comment. Compared to the OpenBSD way of doing things, Docker is not; if anything, it's more complexity.
[1]: https://www.openbsd.org/faq/ports/specialtopics.html#RcScrip...
[2]: https://www.openbsd.org/faq/ports/guide.html