Open Stack

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