[systemd-devel] systemd config recipes for namespace-isolated webapps

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jul 02, 2013 at 05:18:57PM -0400, Martin Langhoff wrote:
> Hi folks!
> 
> At OLPC, I got an early chance to use and abuse systemd, and I like it
> quite a bit.
> 
> We currently have ~500 identical VMs (created from kickstarts, kept
> almost in sync via satellite), each hosts apache/mysql daemons, and 2
> installs of the same PHP webapp (production, test).
> 
> Goal is to reduce the number of VMs radically, as memory and storage
> overheads are killing us.
> 
> I am now looking at systemd (under F-19, RHEL7 later) and wondering
> whether there are any recipes that can guide me a bit through setting
> up webapps in CGs with suitable namespaces.
> 
> What I _think_ I need is
> 
> 0 - one target per "customer", which in turn pulls in
> 1 - apache
> 2 - mysql
> 3 - cronjobs
> 4 - apache/tomcat/java setup {for some customers}
> 5 - sftp -- namespace-aware?
> 
> with 1,2 and 3 set to use the same CG. And stopping the target should
> ensure all the CG is down/dead.
> 
> If possible, I prefer to avoid containers (and the associated chroot
> maintenance).
Hi,
I haven't really tried anythng like what you describe, but in general
both container and container-less approaches should work.

with a container: you can have socket activated systemd-nspawn
instance, which boots to a default target containing your services
1-5 + whatever special you want for that "customer". It is currently
not possible to launch a systemd-nspawn container directly from /,
but you can do a bind mount to somewhere else. If by "chroot
maintanance" you mean the need to copy stuff between / and the
container, then it can be avoided this way. Launching systemd-nspawn
containers directly from / is on the list of planned things.
systemd-nspawn at .service already provides part of the installation.

container-less: a bunch of template units with dependencies on one
another should do what you need (instance units can refer to each
other). You can use InaccessibleDirectories= and other settings to
limit what those units can "see".

The version with containers is probably slightly more flexible
and will allow more customizations for each "customer". The other
one has probably lower overhead. But both should work.

HTH,
Zbyszek