Hacker News Reader

Comment by okso | Hacker News Reader

When facing this duality a few years ago, I had to look at the facts that encourage Config Management in favour of a Dockerfile approach:

* Dockerfiles do not work for configuring host systems, only Cfg Management is applicable

* Configuration management systems usually have a very declarative approach, easier to extend and maintain that Dockerfiles and bash scripts

* Dockerfiles contain too many arbitrary choices that do not work for everyone, starting with the choice of the distribution and OS version: companies like standardizing around one distribution and would have to fork Dockerfiles based on other systems, every single time.

The best solution I see at the moment is to use setup containers using configuration management.

View on HN

I'd add the Dockerfiles only allow extension by inheritance, leading to a lot of cases where people extend for construction.

Put another way: you can't safely compose Dockerfiles. If you want clean, narrow, special-purpose containers, you have two alternatives:

1. Build Dockerfiles for each use case precisely. This will lead to duplicated code and all the excitement thereof.

2. Build a giant shaky tower of Dockerfiles with FROMs, of which most are essentially 'abstract' Dockerfiles, not intended to be actually used. This will lead to documentation and all the excitement thereof.

Stackable filesystems are a triumph in some regards, but they create ugly backpressure on the design of libraries of Dockerfiles.

In this respect I see configuration management tools as vastly superior, as they generally have a concept of assembling goals and converging to them, rather than a concrete stacking logic.

2 does not work for many scenarios. You end up having to build all the FROM combinations which quickly grows out of practicality.

3. use any templating system you like

For example, I make mixins out of little bash scripts (mostly heredocs) that outputs Dockerfile lines. Mixins are shared between projects via git submodules. Voilà.

I don't like configuration management mainly because the syntax is plain stupid, making it difficult to read. Check out Ansible and you'll know what I mean... although I do I have some hope in Terraform once they roll out their feature of "write out the config files out of whatever I already have in that AWS account" (not having to write the config scripts from scratch gives me a tailored example to learn from).

Whenever some bash script gets big (say, 100LOC), it gets rewritten in ruby.

I feel that writing a code-generator for Dockerfiles is a strong smell that they are insufficiently expressive for their task.

And nor should they be, given the unavoidable constraints of the design.

> Whenever some bash script gets big (say, 100LOC), it gets rewritten in ruby.

100? You have patience I lack.

I think of Dockerfiles as a very static piece of code, it urges you to use templates on it.

Just like for a nginx.conf

And 100LOC, well, I've gotten very much used to bash. It is so comfortable when the terminal is your REPL. To tell you the truth my main deploy script is actually 500LOC of bash. It reads top to bottom with a lot of conventions (I was suprised to follow google's bash conventions), and short circuiting abuse.

> their feature of "write out the config files out of whatever I already have in that AWS account"

Whenever I tell people about my own config mgmt solution (http://holocm.org), this is the immediately most-requested feature. They say "I would like to start using configuration management for my system, but I don't want to reinstall my system." So there needs to be some way to serialize all the changes one has made to the system since its installation.

I understand the point about Ansible being hard to read, I find SaltStack much more decent regarding syntax, or PyInfra regarding new kids in the game.

Regarding building Dockerfiles using bash scripts or Ruby, I find the concept interesting but using 'scripts' feels wrong. Building a 'standard' library to generate Dockerfiles on the other hand might be an interesting project that would allow collaboration.

Reply on news.ycombinator.com