Comment by tdicola | Hacker News Reader

Comment by tdicola | Hacker News Reader

I've been using Ansible a bit recently (and _really_ enjoying it) and agree that YAML can be a little wonky at times, like having to escape any template line with :{ in quotes because YAML interprets it as a dictionary. However I don't think Ansible wants you to code all your logic in YAML. You can easily write a plugin with Python and have all the proper syntax and capabilities of a programming language.

Where Ansible really shines is giving you a huge library of quality plugins/components and a simple YAML-based DSL for composing those plugins. Want to spin up an EC2 instance, copy over your code, and ensure a service is started? No problem, it's a 4 or 5 line Ansible script. When you want to do something more advanced, look at the extension points Ansible provides to plugin your own code: http://docs.ansible.com/developing_plugins.html

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.

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