On 10/14/2014 01:12 PM, Clint Byrum wrote:
Excerpts from Lars Kellogg-Stedman's message of 2014-10-14 12:50:48 -0700:
On Tue, Oct 14, 2014 at 03:25:56PM -0400, Jay Pipes wrote:
I think the above strategy is spot on. Unfortunately, that's not how the
Docker ecosystem works.
I'm not sure I agree here, but again nobody is forcing you to use this
tool.
operating system that the image is built for. I see you didn't respond to my
point that in your openstack-containers environment, you end up with Debian
*and* Fedora images, since you use the "official" MySQL dockerhub image. And
therefore you will end up needing to know sysadmin specifics (such as how
network interfaces are set up) on multiple operating system distributions.
I missed that part, but ideally you don't *care* about the
distribution in use. All you care about is the application. Your
container environment (docker itself, or maybe a higher level
abstraction) sets up networking for you, and away you go.
If you have to perform system administration tasks inside your
containers, my general feeling is that something is wrong.
Speaking as a curmudgeon ops guy from "back in the day".. the reason
I choose the OS I do is precisely because it helps me _when something
is wrong_. And the best way an OS can help me is to provide excellent
debugging tools, and otherwise move out of the way.
When something _is_ wrong and I want to attach GDB to mysqld in said
container, I could build a new container with debugging tools installed,
but that may lose the very system state that I'm debugging. So I need to
run things inside the container like apt-get or yum to install GDB.. and
at some point you start to realize that having a whole OS is actually a
good thing even if it means needing to think about a few more things up
front, such as "which OS will I use?" and "what tools do I need installed
in my containers?"
What I mean to say is, just grabbing off the shelf has unstated
consequences.
The biggest gain of containers is they are hermetically sealed. They
turn hundreds of packages (the dependencies and OS files) into 1
interface with one operation:
Start with a defined variatic environment.
This idea rocks if you can put up with the pain that debugging something
that is busted is very difficult. Accessing logs is not tidy and
debugging in the ways that true experienced folk know how to (with gdb
attach for example) just isn't possible.
It also requires that you rely on a completely stateless model (until
persistent storage is implemented in k8s I guess) and completely
idempotent model. I really like the idea of "time to upgrade, lets roll
new images across the cluster". This model is very powerful but comes
with some pain.
Regards
-steve
Sure, Docker isn't any more limiting than using a VM or bare hardware, but
if you use the "official" Docker images, it is more limiting, no?
No more so than grabbing a virtual appliance rather than building a
system yourself.
In other words: sure, it's less flexible, but possibly it's faster to
get started, which is especially useful if your primary goal is not
"be a database administrator" but is actually "write an application
that uses a database backend".
I think there are uses cases for both "official" and customized
images.
In the case of Kolla, we're deploying OpenStack, not just some new
application that uses a database backend. I think the bar is a bit
higher for operations than end-user applications, since it sits below
the abstractions, much closer to the metal.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
