On Tue, 2014-02-25 at 19:59 +0000, Colin Walters wrote:
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
The benefit of this level of indirection would be that you could do:
$ ln -s /usr/lib/systemd/system/httpd.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
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.
It's unclear to me how you'd share the same port between all these
vhosts in a systemd world. Would the unit run a script that
enables/disables the various configs and then just reload the main
apache process configuration ?
Simo Sorce * Red Hat, Inc * New York