3 ms·
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 lo
by doxcf434 12y ago
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.
- dj-wonk 12y agoDoes this work well in practice? I'm new to Ansible.
- walrus 12y agoIt works okay. One shortcoming, as mentioned at https://news.ycombinator.com/item?id=7831680 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.
- doxcf434 12y agoIt 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.
- crdoconnor 12y agoWorks 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.