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.
On Tue, 2014-02-25 at 19:59 +0000, Colin Walters wrote:
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.
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.
On Tue, Feb 25, 2014 at 4:16 PM, Simo Sorce simo@redhat.com wrote:
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 ?
vhosts are a bad example I guess since stock httpd supports them well. But with httpd you still may want one instance that's acting as a static frontend + proxy, and then perhaps you have "app servers" behind it which link in perl or whatever into the server.
Databases may be a better example - while I imagine a lot of people dedicate machines to a single database, there are valid reasons to have separate multi-instantiated instances too.
On Tue, 2014-02-25 at 21:37 +0000, Colin Walters wrote:
On Tue, Feb 25, 2014 at 4:16 PM, Simo Sorce simo@redhat.com wrote:
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 ?
vhosts are a bad example I guess since stock httpd supports them well. But with httpd you still may want one instance that's acting as a static frontend + proxy, and then perhaps you have "app servers" behind it which link in perl or whatever into the server.
Databases may be a better example - while I imagine a lot of people dedicate machines to a single database, there are valid reasons to have separate multi-instantiated instances too.
An example of application that already handle smulti instance configurations is 389-ds-base, I suggest people look at how they manage multiple instances via systemd and figure out if it is sufficient or needs changing and uniform on some other method.
I would like to have a unified guideline for these scenarios too.
Simo.
On Tue, Feb 25, 2014 at 11:59 AM, Colin Walters walters@verbum.org 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.
I personally think *all services* should be multi-instantiated. If you only need one, then just use one.
server@lists.fedoraproject.org
-
Colin Walters -
David Timothy Strauss -
Simo Sorce