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

Michael Scherer misc at zarb.org
Fri Jul 5 03:59:13 PDT 2013

Le mardi 02 juillet 2013 à 17:18 -0400, Martin Langhoff a écrit :
> 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).
> High on the list of goals is to protect customers from data leakage,
> so guidelines towards effective use of namespaces are sought here.
> Pointers, hints, anyone else working in a similar direction?

I would take a look at openshift, since that's exactly what the product
is doing. ( http://openshift.github.io/ )

Each user is isolated into a a specific part of the system, separated by
selinux and regular linux namespace. There is quota, support for apache,
mysql, cron and tomcat. And you can access your space with ssh/sftp.

You can also take a look virt-sandbox-service, who can start a service
or a set of service in a isolated minimal container, and no headache on
upgrade due to bind mounts ( ie, everything use the same code ). And
this is using systemd. 
See https://fedoraproject.org/wiki/Features/Securecontainers and various
others pages on the web.

Michael Scherer

More information about the systemd-devel mailing list