[BBLISA] Experience with docker?

[Dewey Sasser]

On 5/6/2015 8:31 AM, couch at cs.tufts.edu wrote:
> I might add that what makes Docker useful for us is that we can deal 
> with rather complex configuration management requirements -- including 
> several version-locked interlocking subsystems -- without changing the 
> host OS.
>
> But I might add that this is “survival of that which fits.”

I think this is one of the double-edge swords of Docker -- as you 
(almost) completely capture configuration, it's far too easy to create a 
non-repeatable "golden image" and pass it around.  Of course, it's 
fairly easy to *NOT* do this as well, but there will be less immediate 
pain to using Docker with a "this one works, go with it" model than 
there is with VM images.

I will add that as most Docker images are fairly well contained (pun 
intended), it's fairly easy to put the whole container through a 
build/validation/deployment pipeline.  You can usually (depending on 
container linkage issues) have high confidence that things work in PROD 
the way they worked in DEV and TEST.  (NOTE:  this is going to be less 
and less true as we move more into inter-container relationships and 
service discovery through e.g. consul or etcd).

> The main reason we use Docker is that it is literally *too difficult 
> *for our developers to build the run/test configuration unassisted. 
> This means that any work we can do for them -- through docker -- is 
> definitely worth it, even though that work can be involved, especially 
> in interfacing host/guest OS resources.

One the one hand, that seems dangerous to me -- using Docker to work 
around a build difficulty problems feels too much like sweeping problems 
under the rug.

On the other hand, Docker *does* allow good separation of concerns. For 
example, "Ops" can own a base image, with proper instrumentation and 
operational features, and "Dev" can simply inherit from that image.

Perhaps the single most powerful pattern in Docker is the similarity to 
OO programming (inheritance and composition).  It works well for a 
Devops mindset to say "this machine is *JUST LIKE* that machine, plus 
this other stuff".  Software Development has spent many years getting 
good at decomposition through inheritance and inclusion. Docker 
(particularly adding Fleet or Compose) allows us to express this at the 
system level.

--
D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.bblisa.org/pipermail/bblisa/attachments/20150506/99cf2258/attachment.html>