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:

  - 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,

I like this model.

OpenStack-dev mailing list

OpenStack-dev mailing list

Reply via email to