Re: [Userops] Why is it hard to move from one machine to another? An analysis.

[Dave Crossland]

Post to group oops

On 8 Apr 2015 4:16 pm, "Dave Crossland" <address@hidden> wrote:

On 8 Apr 2015 2:11 pm, "Christopher Allan Webber" <address@hidden> wrote:
>
> Dave Crossland writes:
>
> > On 8 April 2015 at 11:22, Christopher Allan Webber <address@hidden>
> > wrote:
> >
> >> running 80 heavy and expensive Docker images
> >
> >
> > Huh? The entire purpose of contains is that they are light and cheap.
>
> Are they?  Certainly compared to a VM as in terms of execution, they are
> a lot smaller.  As in terms of size of the image itself, they seem to
> often be just as large:
>
>   http://stackoverflow.com/questions/24394243/why-are-docker-container-images-so-large

Here's another nickel ;)

Micro services.

What if GMG ran on a container that contained nothing but python?

https://us.pycon.org/2015/schedule/presentation/378/

But what about the non python parts, transcoding? Do it on a similar container that is as little as possible to take files and put files out.

Rust and Go are pointing this way.

Recently I wondered that to understand what Docker people are doing, I should look at people who envisioned os level virtualization. Solaris Zones is to Docker as Netscape is to Chrome.

"Docker will do to apt what apt did to tar" is a great quote from Brian Canterill, currently CTO of Joyent and previously engineer at Sun.

He also makes the case that micro services are continuing the Unix tradition in the current network computing epoch.

RancherOS and CoreOS and SmartOS look to be like what even desktops will be....

https://mobile.twitter.com/jperkin/status/520352024249249792

> Astute Docker fans may point out that new images can be based off of a
> lightweight image, and at that point your image is essentially a diff,
> which is true!  Unfortunately, I don't think it remains that way
> usually.  You need to upgrade packages on your derived image, and this
> means either you need to migrate away from the base image, or maybe the
> *base image* upgrades something, but regardless now you're out of sync.

Easy: Make the container contain less.

> In the git world, we might do a merge or a rebase to bring things back
> inline, but it does not always seem to be easy to do that with a lot of
> binary stuff, and at any rate, I think while the initial install may
> save you time, you haven't saved time in the long run if using prebuilt
> images.
>
> Hence my snark: Docker is the land of one gigabyte per binary.  (Yes,
> here's a nickel, you're right. :))
>
> This is especially a problem if the container is set up in such a way to
> encourage mutation of application-specific data to happen *inside* the
> container... at that point, you now can't just drop your container and
> start over, it's vital you know how to extract and preserve that data.

Data shouldn't live in the program container filesystem! It should be in an object store. In another container.

> Again, reproducibly built images which separate out the mutable data
> don't suffer this.  But at that point, the tool you use to reproduce the
> container might as well be generic, not tied to your container system at
> all.  Which means the container system isn't helping solve deployability
> on the whole, but it may help solve other things or smaller parts of it.
>
> My snark on containers isn't that they can't be useful, it's that they
> don't on their own solve the deployment problems people are having.

I'm sorry I don't have time to fully formulate my thoughts about what I think you are missing in detail; but I think you are not grokking what containerisation means for computing culture. I think your thinking is still rooted in bare metal thinking. Bare metal is dead.