[fit2rule]

I'd love to use this .. but who has time to learn yet another configuration and provisioning management tool? I mean, I can make the time - and will - but since this is just another docker management tool, lets use this moment to pick on it, a little bit..

What this needs is the ability to be pointed at a working VM - lets say, Ubuntu 13.10 server - and then just figure out whats different about it, compared to the distro release.

Something like the blueprint tool, in fact.

[jcurbo]

When I first looked at the Dockerfile format, my thought was, hey, another provisioning file format to learn. I guess you could just call chef/puppet/ansible/etc in your Dockerfile and call it a day though? I have not heavily used any of these tools so my perception of their overlap might be off.

[jamtur01]

I did exactly that with Puppet as an experiment: http://kartar.net/2013/12/building-puppet-apps-inside-docker.... Works reasonably well. I will say though that the Dockerfile syntax is, IMHO, much easier to use than Puppet/Chef/etc.

Disclaimer: I work at Docker and previously worked at Puppet Labs.

[jfroma]

I've tried this and it is not that easy, docker containers are meant to run one and only one process. So, for instance my puppet started an upstart job, and this crashes the docker build process.

I'm a docker newbie, though.

[Intermernet]

The Dockerfile shouldn't run any processes that need to persist between 2 stages as each stage will be created in a new instance. You can either do fancy one-liner bash scripts (my favorite) to configure simple service / app startup scripts, or include a configuration file from elsewhere using the `ADD` directive. The only non ephemeral command should be the final `CMD` or `ENTRYPOINT` as far as I can work out.

I too am just learning this stuff, but that should hopefully help you out!

[eli]

I don't have a ton of experience with any of them, but fig.yaml looks dramatically simpler and easier to learn than Chef or Puppet. (It also solves a much narrower problem, but I think the point remains.)

What this needs is the ability to be pointed at a working VM - lets say, Ubuntu 13.10 server - and then just figure out whats different about it, compared to the distro release.

It sounds like you want Blueprint (https://github.com/devstructure/blueprint). But careful what you ask for... I found this to not actually be a very useful approach in practice.

[amirmc]

> I found this to not actually be a very useful approach in practice.

Could you expand on this, please? I'm curious to know what the problems were (just so I know what I'm letting myself in for)

[eli]

(Disclaimer: I haven't found any solution I really like... so the problem may be me.)

It turns out that installing and configuring services on a server touches many files and only some of them are important. Even the basic assumption that Ubuntu is the same everywhere wasn't quite right. Linode has some of its own packages installed and I think they tweaked the kernel. Running it in VMWare, you probably have the guest additions installed, etc. These things aren't important, but Blueprint doesn't know that. So I ended up with this massive number of changed files and the tooling for filtering through them to get just the important bits wasn't so hot (or at least it wasn't a year ago).