by Josef Spillner
Operating system process management has traditionally been an activity at the system level. An init system starts processes at boot time, at random events, and at the user’s (well, root’s) request. Well-known init systems are systemd, openrc and the venerable sysvinit. Without the boot-time component, supervisor processes such as supervisord, runit, daemontools or r6 form another related set of applications with emphasis on automated restart which we have covered already in previous blog posts.
In PaaS environments, multi-tenancy is crucial and process managers need to support it beyond just showing the users owning the processes. While multiple tenants can be perfectly mapped to multiple system users, and information from these users can be aggregated with automation tools, the permission management can quickly become complex and, first and foremost, already requires root permissions to create new users. Therefore, we have explored in the context of the cloud robotics research initiative how to manage processes purely as an ordinary user, but still for multiple tenants. A real need to do so is the fact that by running applications on ROS, dozens of ROS nodes get spawned quickly, many spawning further subprocesses and, due to early terminations, additionally causing fully detached and zombie processes which, when also changing their process group id, do not share a relation anymore to the original application.
In one of our projects, GEYSER, we were looking into a way of packaging customized code for a pilot test. Generally, we developed µservices which communicate with key Openstack components and we have specifically modified Openstack Horizon code by adding a new dashboard. These µservices as well as Openstack Horizon are quite decoupled from the core Openstack system meaning that communication is done mostly through external API calls rather than a message bus. A number of packaging options were considered: basic packaging python code is relatively straightforward but does not offer the flexibility we require, specifically around rollback. Other solutions include virtual environments or virtual machines, but ultimately, we decided to use Docker containers they are all the rage these days. This blog post describes step-by-step how to containerize Horizon in docker, noting any particular issues we observed in the process. Continue reading
In the context of the Cloud Native Applications (CNA) Seed Project we are working on migrating an open source CRM application into to the cloud. After enabling horizontal scalabilty of the original application and moving it onto our OpenStack cloud with the help of CoreOS (etcd, fleet) and docker we’ve now just finished adding the monitoring / logging / log-collection functionality – a blog post describing this process in its detail will follow – which is needed for the next part of the project: enabling automatic scaling. As part of this process we’ve learnt some lessons concerning the process management in docker containers which we’d like to share in this post.