Re: [PLUG] Interesting thoughts on virtualized service containers

[Rich Freeman <r-plug@thefreemanclan.net>]

On Wed, Apr 22, 2015 at 1:25 PM, Anthony Martin
<anthony.j.martin142@gmail.com> wrote:
> Figured some of you may find this interesting.
>
> http://www.vitavonni.de/blog/201503/2015031201-the-sad-state-of-sysadmin-in-the-age-of-containers.html
>

That stuff drive me nuts.

Docker wants you to: curl -sSL https://get.docker.com/ | sh.  I'll
pass, thanks.

I think Docker is a great tool, and can be used to improve your
control over your environment.  However, it can just as easily be used
to turn your environment into a mess.  It is no different from
virtualization.  You can use VM snapshots and such to control your
installation baselines and take a lot of work out of maintenance.  Or,
you can just go and download a bunch of random VM "appliance" files
off the web and install who-knows-what into your environment.

We've been struggling with this at Gentoo since the start, and I'd say
a lot of projects have actually gotten better.  Every Gentoo package
install is a scripted install from source, and we let our users
install against fairly diverse dependencies (for example, right now
Gentoo has glibc versions 2.13-r4 2.14.1-r3 2.15-r3 2.16.0 2.17
~2.18-r1 ~2.19 2.19-r1 ~2.20 ~2.20-r1 2.20-r2 and 2.21 available - and
packages are expected to build against any of them unless they
explicitly indicate otherwise).  When upstream uses a clean build
system, our install scripts (called ebuilds) can be just a few lines
long.  When they aren't, they're a mess of patching, sed, and so on.
We try to get upstream to clean up anytime we can.

Systemd was starting to talk about creating container-like solutions
per-application.  The idea is that you'd build your application
against "Gnome" and then you would have a "Gnome framework" on your
box which is kept up-to-date, and then when your application launches
when it looks at /usr it would see the Gnome framework.  The concept
is to try to reduce package interdependency, and minimize the amount
of effort to keep everything up to date.  However, I see it suffering
from the problems mentioned in this blog.  I also think that it
oversimplifies things.  They point to Android as a success story, but
I think Android only works because people only use Android
applications as a presentation layer.  Stuff running on your server or
desktop has a MUCH more diverse set of dependencies.  Maybe your
package needs geoip and Gnome to work - so now either the Gnome
framework needs to include geoip, your package has to bundle it
internally, or you need to support multiple frameworks in which case
the whole thing reduces to what we already have (and the proponents of
this solution did not want to allow multiple frameworks anyway).

I get the goal of simplification.  The problem is that sometimes
they're trying to put too much behind the black box.  If they want to
replace your distro, then they have to do it as well as Debian or
Redhat or whatever, and I don't think that is as easy a job as most of
these projects think it is.  Beating Debian at what Debian does best
just isn't easy at all.

--
Rich
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug