Hi,
So we haven't talked a huge amount about Docker here, but one of the key advantages I see that it brings to the table is "multi-instantiating" services. This is where the RPM model for things like apache is weak.
RPM encourages a one-to-one relationship between the package (binaries) and its datastore. For example, httpd and /var/www/html.
Of course many services that it makes sense to "multi-instantiate" can be easily configured to do so - but you're more "on your own" if you do so. Again for example with httpd, you have to carefully label your new directories as httpd_sys_content_t.
So here's the idea (and this also plays into how I am dealing with /var with OSTree) - what if we patched services like httpd to read an environment variable that systemd set (say SYSTEMD_UNIT), and assume they find data named after that environment variable?
With apache, it would look in
/var/www-$(SYSTEMD_UNIT)/html
The benefit of this level of indirection would be that you could do:
$ ln -s /usr/lib/systemd/system/httpd.service /etc/systemd/system/httpd-mycustomer01.service $ systemctl start httpd-mycustomer-01.service
Now if we get to the ideal where all directories in /var are generated via systemd-tmpfiles, when you started this unit systemd would precreate /var/www-$(SYSTEMD_UNIT) and also take care of SELinux labeling.
We'd like also want to read /etc/httpd-$(SYSTEMD_UNIT) instead of the default as well.
If we took this to the ultimate conclusion, we'd probably discourage these services from having any default configuration at all. You wouldn't start httpd.service, you'd always make unit files after vhosts.