multi-instantiating services via systemd

[Colin Walters]

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140225/ef8531c1/attachment.html>