[BBLISA] Experience with docker?

[couch at cs.tufts.edu]

Clarification: we do have a build process for docker containers. This is far easier than a build process on the various linuxes our people have, and it does things like pulling releases of the major components from Github. So, we aren't end-running around creating a build process. But this still takes a lot of time to manage. 






Alva L. Couch
Assoc. Prof. of Computer Science
Tufts University
Medford, MA 02155





From: Dewey Sasser
Sent: ‎Wednesday‎, ‎May‎ ‎6‎, ‎2015 ‎10‎:‎53‎ ‎AM
To: Alva Couch, Mark Lamourine
Cc: Dean Anderson, bblisa at bblisa.org





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/a2b24e6e/attachment.html>