[caw]

How is building a Vagrant box via Ansible configuration any different than building a Docker container with a docker file? You can use both tools to build an image once and then rebuild for the updates. I don't see how the tool in any way violates that constraint.

What is this rule to only build once? I can see not wanting to create multiple artifacts of your codebase, but with machines it is possible to continually update them and sometimes desirable as well. In the "cloud" world, you can arguably rebuild a server every time it needs updates, but at the physical level you don't always have capacity to absorb the hit of rebuilding multiple boxes at once. The physical servers need to get updated and managed post-install.

[grhmc]

> How is building a Vagrant box via Ansible configuration any different than building a Docker container with a docker file?

Unless you're snapshotting that vagrant box and then deploying that to all your servers somehow, you are building multiple times.

> What is this rule to only build once?

I'd recommend reading the book Continuous Delivery. It is a fantastically helpful read.

I prefer not to update my machines, but that is because I follow immutable deployments. But, even if I did update my machines, it is far cleaner (and easier to roll back!) to deploy an asset which has all its dependencies in the box. than to push out code and maybe have to upgrade or install new packages. The gemfile.lock and friends make this a bit less of a problem, but you also get to lock things like libxml version or ffmpeg or...

> In the "cloud" world, you can arguably rebuild a server every time it needs updates, but at the physical level you don't always have capacity to absorb the hit of rebuilding multiple boxes at once.

Totally true, and we don't do this. We build a machine image and do a rolling-deploy replacing existing servers with the new machine image.

> The physical servers need to get updated and managed post-install.

One of the reasons I try not to work with hardware. Physical hardware is hard, and avoiding it makes my life much simpler. I love it.

[crdoconnor]

>Unless you're snapshotting that vagrant box and then deploying that to all your servers somehow, you are building multiple times.

You're also configuring many things in many different potentially complex ways.

The docker method of using environment variables as a configuration hack to get around this is pretty horrible, IMHO. Especially compared to ansible's YAML/jinja2 configuration.

[davexunit]

>Especially compared to ansible's YAML/jinja2 configuration.

YAML/jinja2 is just terrible. When you have to introduce a templating system to programmatically generate your YAML configuration files, what you have really needed the whole time is an actual programming language.

[crdoconnor]

It's a non-turing complete programming language much like excel spreadsheets are non turing complete programming languages.

Taking out the turing completeness restricts the mess which you can make and lets non-programmers do more while still being customizable.

[jessaustin]

Some smart people disagree with that:

http://12factor.net/config

I think the point is not to conflate configuration that is equivalent to code (which, sure, put it in version control) with configuration that is specific to how code is deployed (which your deployment tool should just tell you, via env vars).

[Scarblac]

> I'd recommend reading the book Continuous Delivery. It is a fantastically helpful read.

Which one? The one by Humble and Farley (Addison-Wesley) is from 2010, is it still relevant?

[zeckalpha]

Still? For me, when I hear book recommendations, the older the book is the more likely the book is still relevant. Books get forgotten over time.

The book is excellent. I was surprised that it wasn't older.

[Scarblac]

Some books cover tools in detail, that can be great but those books go out of date. Will put it on the list, thanks.

[grhmc]

Yes, one by Humble. 2010. Still fantastic. Timeless.

[perlgeek]

> What is this rule to only build once?

If your cycle is "build, test, build, deploy", then you are not deploying those artifacts that you tested.

Any number of factors (different dependency version, toolchain difference, environment differences, non-reproducible builds) could lead to the second build being different from the first one, and then you deploy an untested artifact.

Not to mention that rebuild can be resource intenstive.

[beat]

First, not everything produces bitwise identical results from build to build (Websphere ear files, for example). Second, it's time consuming to rebuild from scratch every time. This is especially important if you're in a cloud environment and scaling horizontally for load. You want a way to bring resources online quickly.

[icebraining]

All clouds I've used have snapshots - it's hard to get faster than creating a VM from one. You can just keep an up-to-date template using any config management tool.