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, [email protected]
On 5/6/2015 8:31 AM, [email protected] 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
_______________________________________________
bblisa mailing list
[email protected]
http://www.bblisa.org/mailman/listinfo/bblisa
