[openstack-dev] Fwd: Have you guys considered...

Dmitry Ilyin dilyin at mirantis.com
Fri Jun 20 19:12:51 UTC 2014


Speaking about the idea of running everything inside containers...

First, this idea is no the new one and have been around for a very long
time. People were running their services inside a simple chroot, then
OpenVZ and now LXC containers with variable success. Usually the ideas
behind this are following:


   -

   Isolation. Misbehaving or hacked service will not impact other services.
   -

   Granular maintenance. Services can be updated without accidentally
   messing other ones.
   -

   Personal environments. Each service can have it's own libraries,
   dependencies and environment if it's required.
   -

   Modular architecture. Each service can be thinked of as an "application"
   this application can be installed, upgraded, stopped, started and shared
   separately.


Sometimes, such approach is used even without any form of containers:


   -

   Mac OS's Applications when programs are packed in special folders with
   everything they needs to run except basic system libraries and latest
   versions try to add sandbox as well.
   -

   Windows' Program Files has very close functions if used correctly.
   -

   Such linuces as http://nixos.org/ and http://crux.nu/ implement various
   ways to use filesystem as a package manger and make updates easy, reliable
   and able to be rolled back - something we desire too.
   -

   PC-BSD, pbi packages are also an example of containers without actual
   containerization.
   -

   Popular Python's and Ruby's virtualenv and rvm can be added to the end
   of this list too.


There are some OSes that make running every application in it's own
container the core of their design:


   -

   The CoreOS https://coreos.com/ is well-known to be a very good host for
   docker containers. It has minimal footprint and very convenient REST
   interface. We should really consider using it as a host system for a Fuel
   master node.
   -

   OSv http://osv.io/ goes much farther down the road of minimalisation of
   the containers by developing thei rown specialized kernel. Each instance
   can be thinked of as a wrapper around the application and the application
   should work without ability to fork and extensive file system. This
   containers can be deployed in a cloud in masse very fast.
   -

   There are also projects to use this approach on desktop with full-scale
   virtualization insead of containers as well http://qubes-os.org/


On the contrary traditional BSD and Linux approach is based upon having a
single “tree” of software. All programs should use the same libraries as
others, have no conflicts and work in a single filesystem namespace and can
depend on each other. This approach have been around for a lot of years and
has some advantages like saving disk space and ram by using same libraries
or making a distribution to be consistent. Linux community have been
mercilessly smiting everyone who ever said that this approach has it
downsides like problems with adding and maintaining custom software and
maintaining different library versions as well as dependency on upstream
repository.

Using containers can actually solve a lot of problems we have been having
for a long time if done right especially for a complex system like
OpenStack. We can have every service packaged as a pre-built container that
can be just downloaded, extracted and started on a target node. Updates can
just replace this container with newer version keeping the old one stored.

We have already moved Fuel Master node to this architecture, but we have
not done it the right way. Master system should be very thin and contain as
little services and things to configure as possible to the point of only
entering the IP address. And containers should be also very thin focused
only on their job with small amount of configuration up to being stateless
if possible. Such configuration would require very little configuration
making configuration management tools like Puppet redundant. Everything
should be already configured inside the container.

By all means, we should go for a container based architecture for every
OpenStack node, but we should not make it look like having many operating
systems to administer on a single node instead of the only one. Containers
are not like cheap VPS hosting where you can order you instance of CentOS
inside an OpenVZ container and they should be thinked of as the
applications not as the operating systems like instances that are started
in the OpenStack cloud. Yes, it's a large paradigm shift but it's definitly
worth it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140620/31ab7aa3/attachment.html>


More information about the OpenStack-dev mailing list