On 10/14/2014 03:10 PM, Lars Kellogg-Stedman wrote:
On Tue, Oct 14, 2014 at 02:45:30PM -0400, Jay Pipes wrote:
With Docker, you are limited to the operating system of whatever the image
uses.
See, that's the part I disagree with. What I was saying about ansible
and puppet in my email is that I think the right thing to do is take
advantage of those tools:
FROM ubuntu
RUN apt-get install ansible
COPY my_ansible_config.yaml /my_ansible_config.yaml
RUN ansible /my_ansible_config.yaml
Or:
FROM Fedora
RUN yum install ansible
COPY my_ansible_config.yaml /my_ansible_config.yaml
RUN ansible /my_ansible_config.yaml
Put the minimal instructions in your dockerfile to bootstrap your
preferred configuration management tool. This is exactly what you
would do when booting, say, a Nova instance into an openstack
environment: you can provide a shell script to cloud-init that would
install whatever packages are required to run your config management
tool, and then run that tool.
I think the above strategy is spot on. Unfortunately, that's not how the
Docker ecosystem works. Everything is based on images, and you get the
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.
Once you have bootstrapped your cm environment you can take advantage
of all those distribution-agnostic cm tools.
In other words, using docker is no more limiting than using a vm or
bare hardware that has been installed with your distribution of
choice.
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?
How would I go about essentially transferring the ownership of the RPC
exchanges that the original nova-conductor container managed to the new
nova-conductor container? Would it be as simple as shutting down the old
container and starting up the new nova-conductor container using things like
--link rabbitmq:rabbitmq in the startup docker line?
I think that you would not necessarily rely on --link for this sort of
thing. Under kubernetes, you would use a "service" definition, in
which kubernetes maintains a proxy that directs traffic to the
appropriate place as containers are created and destroyed.
Outside of kubernetes, you would use some other service discovery
mechanism; there are many available (etcd, consul, serf, etc).
But this isn't particularly a docker problem. This is the same
problem you would face running the same software on top of a cloud
environment in which you cannot predict things like ip addresses a
priori.
Gotcha. I'm still reading through the Kubernetes docs to better
understand the role that it plays in relation to Docker. Hopefully I'll
have a better grip on this stuff by summit time :) Thanks again for your
very helpful replies.
Best,
-jay
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
