Open Stack

On 10/14/2014 01:28 PM, Lars Kellogg-Stedman wrote:
> On Tue, Oct 14, 2014 at 12:33:42PM -0400, Jay Pipes wrote:
>> Can I use your Dockerfiles to build Ubuntu/Debian images instead of only
>> Fedora images?
>
> Not easily, no.
>
>> Seems to me that the image-based Docker system makes the
>> resulting container quite brittle -- since a) you can't use configuration
>> management systems like Ansible to choose which operating system or package
>> management tools you wish to use...
>
> While that's true, it seems like a non-goal.  You're not starting with
> a virtual machine and a blank disk here, you're starting from an
> existing filesystem.
>
> I'm not sure I understand your use case enough to give you a more
> useful reply.

Sorry, I'm trying hard to describe some of this. I have limited 
vocabulary to use in this new space :)

I guess what I am saying is that there is a wealth of existing 
configuration management provenance that installs and configures 
application packages. These configuration management modules/tools are 
written to entirely take away the multi-operating-system, 
multi-package-manager problems.

Instead of having two Dockerfiles, one that only works on Fedora that 
does something like:

FROM fedora20
RUN yum -y install python-pbr

and one that only works on Debian:

FROM debian:wheezy
RUN apt-get install -y python-pbr

Configuration management tools like Ansible already work cross-operating 
system, and allow you to express what gets installed regardless of the 
operating system of the disk image:

tasks:
   - name: install PBR Debian
     apt: name=python-pbr state=present
     when: ansible_os_family == "Debian"
   - name: install PBR RH
     yum: name=python-pbr state=present
     when: ansible_os_family == "RedHat"

Heck, in Chef, you wouldn't even need the when: switch logic, since Chef 
knows which package management system to use depending on the operating 
system.

With Docker, you are limited to the operating system of whatever the 
image uses.

This means, for things like your openstack-containers Ansible+Docker 
environment (which is wicked cool, BTW), you have containers running 
Fedora20 for everything except MySQL, which due to the fact that you are 
using the "official" [1] MySQL image on dockerhub, is only a 
Debian:Wheezy image.

This means you now have to know the system administrative comments and 
setup for two operating systems ... or go find a Fedora20 image for 
mysql somewhere.

It just seems to me that Docker is re-inventing a whole bunch of stuff 
that configuration management tools like Ansible, Puppet, Chef, and 
Saltstack have gotten good at over the years.

[1] Is there an official MySQL docker image? I found 553 Dockerhub 
repositories for MySQL images...

>> So... what am I missing with this? What makes Docker images more ideal than
>> straight up LXC containers and using Ansible to control upgrades/changes to
>> configuration of the software on those containers?
>
> I think that in general that Docker images are more share-able, and
> the layered model makes building components on top of a base image
> both easy and reasonably efficient in terms of time and storage.

By layered model, are you referring to the bottom layer being the Docker 
image and then upper layers being stuff managed by a configuration 
management system?

> I think that Ansible makes a great tool for managing configuration
> inside Docker containers, and you could easily use it as part of the
> image build process.  Right now, people using Docker are basically
> writing shell scripts to perform system configuration, which is like a
> 20 year step back in time.

Right, I've noticed that :)

 >  Using a more structured mechanism for
> doing this is a great idea, and one that lots of people are pursuing.
> I have looked into using Puppet as part of both the build and runtime
> configuration process, but I haven't spent much time on it yet.

Oh, I don't think Puppet is any better than Ansible for these things.

> A key goal for Docker images is generally that images are "immutable",
> or at least "stateless".  You don't "yum upgrade" or "apt-get upgrade"
> in a container; you generate a new image with new packages/code/etc.
> This makes it trivial to revert to a previous version of a deployment,
> and clearly separates the "build the image" process from the "run the
> application" process.

OK, so bear with me more on this, please... :)

Let's say I build Docker images for, say, my nova-conductor container, 
and I build the image by doing a devstack-style "install from git repos" 
method. Then, I build another nova-conductor container from a newer 
revision in source control.

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?

Genuinely curious and inspired by this new container-the-world vision,
-jay

> I like this model.
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>