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

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


   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

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

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.


OpenStack-dev mailing list

Reply via email to