On Mon, 2014-06-02 at 12:38 -0700, Colin Walters wrote:
> I fail to see how you do that if you have a lot of data and you
need to
> "migrate data-files".
Best practice is to keep data outside of containers, on Docker volumes,
or on the host filesystem via bind mounts, or network mounted.
> It becomes a lot more complicated than a yum update, what's the gain ?
I personally for a lot of the code I'm writing today am trying to keep
it
working in both the traditional path, while also thinking about how I
could make it easier to deploy in a container itself, or as part of
a larger container.
There are going to be a vast number of administrators who will likely
prefer to deploy (particularly) critical services traditionally, and we
need to continue supporting them.
The advantages of containerizing though are:
1) Stronger isolation by default via namespacing, and for programs
which don't have a targeted SELinux policy already, they'll be
isolated
via SELinux svirt.
2) Ability to easily deploy old code on new systems
3) Easily *multi-instantiate* services (this is quite painful with
traditional)
Among other things.
Right but these are big advantages in a shared/cloud like environment.
In the traditional infrastructure roles though, it looks a lot less
useful.
The 2 roles we have in Fedora Server for now are FreeIPA and Database
server. The 'meat' for both of them is in the data they provide, so I
see little value in trying to use containers for them. Although I can
totally see how we may want to containerize them as an option in F22 as
a way to upgrade the host but keep running the old code.
Simo.
--
Simo Sorce * Red Hat, Inc * New York