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

[Christopher Allan Webber]

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

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.

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.

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.

 - Chris