Hacker News Reader

Comment by doxcf434 | Hacker News Reader

Right, if you need more complex logic, then you write a module in a normal programming language. The YAML is intended to keep the intention and orchestration logic simple and readable.

View on HN

Does this work well in practice? I'm new to Ansible.

It works okay. One shortcoming, as mentioned at https://news.ycombinator.com/item?id=7831680, is that there is no clear model for state transitions. Let's say that on day 1, you want to use Apache:

  - apt: name=apache2 state=present

Then, on day 2, you realize that Apache isn't hip, so you switch to nginx instead:

  - apt: name=apache2 state=absent
  - apt: name=nginx state=present

It works, but you're stuck with entries in your playbook that are there for purely historical reasons.

It depends on your deployment model to a degree. In the case where you build a new image for your web server on every deployment, then this isn't an issue. For longer running systems, like databases, it would still be an annoyance.

I think that Ansible is still a transitional glue tech though, and projects like flynn.io may move things forward by making the CM part of the infrastructure a developer task vs. a devops one.

Works very well for me. I have some pretty complex configurations and they're all done declaratively with a bit of template logic. I think it's pretty rare to need a custom module (not that it's hard to write one).

Ansible is 100% intended for configuration management. Configuration is by its very nature declarative, so in any case if you were doing a lot of custom procedural code for configuration you're probably doing something a bit wrong.

Reply on news.ycombinator.com