Hacker News Reader

Comment by jeffbr13 | Hacker News Reader

I currently have an ansible script which can set up a web-service on any Debian/Ubuntu box, and can be invoked

1) over SSH, or 2) by Vagrant when provisioning a VM.

Docker, on the other hand, provisions it's containers from a rather simplistic Dockerfile, which is just a list of commands. The current solution to provision a container through ansible is rather messy[1], and shows that Docker's configuration doesn't display the same separation-of-responsibilities as Vagrant's does.

Luckily, this lets me use Docker as another provider through the Vagrant API. Woooo!

http://www.ansible.com/blog/2014/02/12/installing-and-buildi...

View on HN

I paused integrating Ansible with Docker for the moment until I'm happy with my Ansible repo and Docker is stable.

I still think Ansible inside Docker is feasible, by * using it to generate the initial base image * receiving some sort of signal inside the container to update its playbook and run.

So when you want to update the container, you're not tearing it down but instead telling the container to perform some sort of "soft reset".

Using ansible inside of Dockerfile's means that you do a full rebuild of your image for every minor change, and when shipping images, you ship the full image every time instead of a small delta.

What do you gain by using ansible inside of your Dockerfile? I find ansible pretty useful to set up a bunch of Docker images on a server, but I haven't found it very useful to actually build the images.

I've not used Docker before, so this is all postulation: Dockerfiles don't look great for complex software setup processes, being just a list of commands to run on the machine.

We already have provisioning tools which attempt to solve this problem, so I'd much rather write one definition which can be applied everywhere, whether to virtual machines, Linux containers, or hosts running on physical machines.

Maybe I'm just trying to use Docker incorrectly? My particular use-case is setting up software (CKAN[1]) in an Ubuntu environment, but the server I have access to is Arch Linux, and the software is I/O-heavy, so I imagine that a container would probably be better than a VM.

"just a list of commands to run on the machine."

A provisioning script is essentially just a list of idempotent commands to run on the machine. But given the way that docker works, idempotence is not required -- if you change a command, Docker rolls back to a known state and runs the command.

A provisioning script might be slightly "higher-level" than a Dockerfile or shell script, but I find the difference is minimal, that the number of lines of code required are similar. Many provisioning tools provide libraries of pre-built recipes you can utilize; Docker provides a repository of pre-built images.

Dockerfiles are designed to give you all the primitives you need to compose arbitrarily complex build processes, and no more.

A Dockerfile is not a replacement for your favorite build script: it's a reliable foundation for defining, unambiguously, in which context to run your script. The Dockerfile's defining feature is that it has no implicit dependency: it only needs a working Docker install. Unlike your favorite build script, which may require "python" (but which version exactly?), ssh (but which build exactly?), gcc ( but...), openssl ( but...) and so on.

Of course I'm biased but I consider it a significant regression in your usage of Docker to build images from a vagrantfile instead of a Dockerfile.

I'm curious why you feel Docker doesn't offer separation of respinsibilities? In my experience the opposite is true, and a recurring theme in why people switch from Vagrant to Docker.

Reply on news.ycombinator.com